ARP Spoofing

ARP (Address Resolution Protocol) translates IP addresses to MAC addresses within a local network. Its design flaw: it has no authentication, so any machine can claim “I am IP X” and the others believe it. ARP spoofing (or poisoning) abuses this to make a victim’s traffic pass through the attacker, who positions themselves in the middle (man-in-the-middle) of the communication between the victim and the gateway.

flowchart LR
    V[Victim] -->|"traffic"| A["Attacker (MITM)"]
    A -->|"forwards"| G[Gateway]
    A -. "poisons ARP caches<br/>(impersonates the gateway)" .-> V

Threat model

On a switched LAN, each host keeps an ARP table (IP→MAC). If the attacker sends fake ARP replies saying the gateway’s MAC is theirs (and conversely, to the gateway, that the victim’s MAC is theirs), both send their traffic to the attacker. It’s a layer-2 attack: it requires being on the same network segment as the victim.

Red Team

The attack step by step

1. You're on the LAN (physical access, WiFi, compromised host)
2. Enable forwarding so you don't cut the victim's connection
   echo 1 > /proc/sys/net/ipv4/ip_forward
3. Poison: tell the victim "I am the gateway" and the gateway "I am the victim"
4. All victim<->gateway traffic passes through you -> sniffing (see net-sniffing)

Tools

# bettercap (the modern standard)
bettercap -iface eth0
> net.probe on          # discover hosts
> set arp.spoof.targets 10.0.0.5
> arp.spoof on
> net.sniff on          # capture the intercepted traffic
# classics
arpspoof -i eth0 -t 10.0.0.5 10.0.0.1     # (dsniff)
ettercap -T -M arp /10.0.0.5// /10.0.0.1//

What you get in the middle

Sniffing of the victim’s traffic (credentials, cookies, tokens — Network Sniffing).
SSL stripping (downgrade HTTPS→HTTP where possible) and DNS spoofing (redirect to fake hosts — DNS Attacks/Man-in-the-Middle).
Injection of content into unencrypted HTTP traffic.
Capture of Net-NTLMv2 hashes by forcing authentications.

Limitations

It only works on your L2 segment. HTTPS/HSTS, certificates, and encrypted protocols greatly limit what you see (metadata yes, content no). It’s noisy: it duplicates traffic and alters ARP tables detectably.

Blue Team

Detection

ARP table changes: a MAC suddenly associated to the gateway’s IP, or a MAC claiming several IPs.
Anomalous ARP traffic (many unsolicited ARP replies, gratuitous ARP).
Tools: arpwatch (alerts on IP↔MAC changes), XArp, IDS with ARP-spoofing rules.

Hardening

Dynamic ARP Inspection (DAI) on managed switches: validates ARP against DHCP snooping.
Port security (limit MACs per port), 802.1X (authenticate before connecting).
Static ARP entries for critical hosts (gateway, servers).
End-to-end encryption (HTTPS, SSH, VPN): even if intercepted, they don’t see content.
L2 segmentation: fewer hosts per broadcast domain = fewer reachable victims.

Response

Identify the attacker MAC (physical/switch port), isolate it, clear the affected ARP tables, and review what traffic may have been captured (rotate credentials that traveled in the clear).

CVEs and real-world cases

ARP spoofing isn’t a CVE: it’s a protocol weakness (MITRE T1557.002 ARP Cache Poisoning).
The basis of countless MITM attacks on local networks, corporate WiFi, and internal pentest environments.
Combined with DNS spoofing and SSL stripping, historically used for mass credential theft (e.g. Ettercap/bettercap-style tools on open networks).

Testing checklist

Confirm you’re on the same L2 segment as the victim
Enable ip_forward (don’t cut the connection)
Poison victim↔gateway (bettercap/arpspoof)
Capture the intercepted traffic (sniffing)
Try DNS spoofing / SSL stripping over the MITM
Force/capture Net-NTLMv2 hashes
Blue: is there DAI/port security/arpwatch?
Verify what content stays protected by encryption