ARP Poisoning Concepts — The Chaotic MITM That Makes Switches Cry

"If IP is the address on the mailbox, ARP is the neighbor who tells you which house the mailbox actually belongs to — and ARP poisoning is bribing the neighbor with espresso to lie."

You're already comfortable with NIC modes, tap/mirror concepts, and the basics of packet capture — so you know how to eavesdrop when the network hands you a copy of packets. ARP poisoning is different and sneakier: it creates the copy by tricking devices into sending their traffic through you. This is the classic local-layer man-in-the-middle (MITM) trick used by pen testers and, yes, by malware and RaaS operators who want cheap interception capabilities.

Quick refresher: where ARP fits in the stack

• ARP (Address Resolution Protocol) resolves IPv4 addresses to MAC addresses on a local broadcast domain.
• It's a stateless, unauthenticated protocol: friendly and gullible by design.
• Devices cache ARP replies in an ARP table until entries expire.

Because ARP trusts anyone who shouts, attackers can send forged ARP replies to pollute that table — a.k.a. ARP poisoning / ARP spoofing / ARP cache poisoning.

How ARP poisoning actually works (step-by-step)

1. Attacker and victim are on the same L2 network (same VLAN/LAN). Switch or hub — attacker needs L2 reachability.
2. Attacker enables IP forwarding on their machine so intercepted packets are forwarded to the real gateway.
3. Attacker sends forged ARP replies to the victim claiming: "I am the gateway (MAC X)." Sends forged replies to gateway claiming: "I am the victim (MAC Y)."
4. Both victims and gateway update their ARP caches. Traffic now flows through the attacker (MITM), who forwards it so the conversation continues normally.

Engaging question: why would a switch allow that? Because switches forward based on MAC tables learned from frames — but ARP poisoning manipulates end-host caches, not switch tables. Unless the attacker also poisons MAC tables, typical switching still sees legitimate frames and forwards them.

Attack flow cheatsheet (commands & fundamentals)

Enable IP forwarding (Linux):

# immediate
sudo sysctl -w net.ipv4.ip_forward=1
# persistent in /etc/sysctl.conf: net.ipv4.ip_forward = 1

Common tools and quick commands:

# arpspoof (dsniff suite)
arpspoof -i eth0 -t 192.168.1.10 192.168.1.1  # poison victim (10) claiming to be gateway (1)
arpspoof -i eth0 -t 192.168.1.1 192.168.1.10  # poison gateway claiming to be victim

# bettercap (modern, extensible)
bettercap -iface eth0 -eval "arp.spoof on; set arp.spoof.targets 192.168.1.10"

# ettercap interactive for ARP-based MITM
sudo ettercap -T -q -M arp:remote /192.168.1.10/ /192.168.1.1/

Remember: packet capture fundamentals tell you that once traffic flows through you, tools like tshark/wireshark will happily log everything — unless it's encrypted.

Encrypted traffic? Not a problem — sometimes

Even if traffic is encrypted, ARP poisoning can still be valuable.

• It enables SSL/TLS interception if the attacker can present a trusted certificate or the client ignores warnings (or certificate pinning is absent).
• It enables TLS downgrade/SSL stripping in legacy sites or when users accept warnings.
• It exposes metadata: destination IPs, SNI (Server Name Indication) in many TLS handshakes, packet sizes and timing — great for traffic analysis and exfiltration detection evasion.

Tie-back to malware: modern malware families and RaaS kits sometimes include network interception modules, or rely on ARP poisoning to snoop local devices and harvest credentials or intercept C2. Earlier we studied sandbox evasion; now imagine a malware implant that uses ARP poisoning to test whether it can observe other VMs on the same host network — a straightforward lateral movement enabler.

Detection — how defenders catch ARP poisoning

• Watch for duplicate IPs / changing MACs: arpwatch, ArpON, and IDS signatures can flag suspicious ARP activity.
• Monitor ARP traffic: an unusual rate of gratuitous ARP replies is a red flag.
• Check ARP tables: arp -a or ip neigh show — sudden changes in gateway MACs should alarm you.
• Use network telemetry: switches with CAM table anomalies or CPU spikes during ARP floods.

Snippet: check ARP cache (Linux)

ip neigh show
# or
arp -n

Ask yourself: if the gateway MAC flips overnight for dozens of hosts, who spilled espresso on the neighbor?

Mitigation & hardening (what actually works)

Practical tip: on managed switches, enable DHCP snooping + DAI; it’s the most scalable way to stop ARP lies at the switch.

Legal & ethical corner (don’t be that person)

ARP poisoning is powerful and intrusive. Use it only on networks you own or have express authorization to test. Remember: many of the toolchains that facilitate ARP poisoning are also available in commodity malware — which is why defenders treat it seriously.

Closing — key takeaways

• ARP poisoning exploits trust: ARP has no auth, so forged replies can redirect traffic through an attacker.
• You don't need special hardware: being on the same L2 network + IP forwarding + a few packets is enough.
• Encryption helps but isn’t a panacea: metadata leaks and SSL/TLS interception paths exist.
• Defend at layer 2 and layer 7: combine switch features (DAI, port security) with strong TLS hygiene and VPNs.

Final thought: ARP poisoning is the networking equivalent of a con artist swapping address labels on mailboxes. It’s gloriously low-tech, wildly effective, and a great reminder that always‑on, unauthenticated protocols are legacy liabilities. Use this knowledge responsibly — and if you find yourself tempted to run arpspoof on a coffee shop network, remember: curiosity is great; unauthorized interception is not.

"Learn the trick, then learn the cure" — you're now equipped to both simulate ARP-based MITM for tests and to design defenses that make these attacks headache-inducing for adversaries.