ARP Poisoning: The Silent Network Redirect

Every device on a local network trusts a protocol called ARP — the Address Resolution Protocol. ARP translates IP addresses to MAC addresses so devices know where to send packets on the physical network. ARP has no authentication. Any device can claim to be any other device.

That’s the entire vulnerability. ARP trusts everyone. And that trust lets an attacker silently redirect all your network traffic through their machine.

How ARP poisoning works

When your laptop wants to send data to the internet, it needs to know the MAC address of the network gateway (your router). It sends an ARP request: “Who has IP 192.168.1.1?” The router responds: “That’s me, my MAC address is AA:BB:CC:DD:EE:FF.”

ARP poisoning works by sending unsolicited ARP replies. The attacker’s machine broadcasts: “192.168.1.1 is at [attacker’s MAC address].” Your laptop updates its ARP table. Now when it sends traffic destined for the router, it sends it to the attacker instead.

The attacker simultaneously tells the router that your IP address maps to the attacker’s MAC address. Now traffic in both directions flows through the attacker. They forward everything to the real destination so the connection still works. You notice nothing.

The tools are trivial

ARP poisoning is one of the most accessible network attacks. The tools are free, mature, and well-documented:

• Ettercap — GUI-based ARP poisoning with built-in MITM capabilities, packet filtering, and content injection
• arpspoof (part of dsniff) — Command-line ARP spoofing in a single command
• Bettercap — Modern framework for network attacks including ARP poisoning, DNS spoofing, and SSL stripping
• Cain & Abel — Windows-based tool with password recovery, ARP poisoning, and packet capture

A single command — arpspoof -i eth0 -t 192.168.1.100 192.168.1.1 — redirects all of a target’s traffic. The attack takes under five seconds to execute.

Why ARP poisoning is devastating on shared networks

ARP operates at Layer 2 — the data link layer. It is below IP, below TCP, below TLS. Every device on the same network segment is reachable via ARP. This means:

• Coffee shops, hotels, airports: Any device on the WiFi can ARP-poison any other device
• Corporate LANs: Any compromised workstation can redirect traffic from other workstations on the same VLAN
• Co-working spaces: Shared network infrastructure means shared ARP exposure
• University networks: Thousands of devices on flat network segments with no ARP protection

ARP poisoning is the MITM attack that enables other MITM attacks. Once traffic flows through the attacker, they can perform SSL stripping, DNS spoofing, session hijacking, and credential capture.

ARP poisoning is the gateway attack. It positions the attacker in the middle of the network. From that position, every other MITM technique becomes available. If you stop ARP poisoning, you stop the cascade.

Why existing defenses fall short

Static ARP entries

You can manually set static ARP entries that don’t get overwritten by spoofed replies. This works but doesn’t scale. Every device needs static entries for every other device it communicates with. Any network change requires manual updates. On a network with hundreds of devices, this is impractical.

Dynamic ARP Inspection (DAI)

Enterprise switches can validate ARP packets against a DHCP snooping table. This is the correct defense at the infrastructure level. However, DAI requires managed switches, proper DHCP snooping configuration, and doesn’t protect devices on unmanaged networks (which is where most ARP poisoning happens — public WiFi, guest networks, co-working spaces).

VPN

A VPN encrypts traffic in transit, which prevents the ARP poisoner from reading content. But the VPN doesn’t prevent the ARP poisoning itself. The attacker still sees encrypted traffic flowing through their machine. They see connection metadata, timing patterns, and volume. And if the VPN tunnel drops for any reason, traffic reverts to the direct (poisoned) path.

ARP monitoring tools

Tools like ARPwatch monitor ARP tables for changes and alert on suspicious activity. They are reactive — they alert after the poisoning has occurred. By the time the alert fires, the attacker may have already captured credentials.

How ZK Proven detects ARP poisoning

ZK Proven catches ARP poisoning through its network topology proof — the same mechanism that detects evil twins and rogue access points.

The extra hop

ARP poisoning inserts the attacker’s machine into the network path. Your traffic now goes: device → attacker → gateway → internet. That extra hop has measurable consequences:

• Increased hop count: The TTL (time to live) of packets decreases by one additional unit through the attacker’s machine
• Latency increase: The attacker’s machine adds processing time to every packet
• Latency variance: The attacker’s processing time varies based on load, creating jitter that isn’t present on a direct connection
• Routing asymmetry: The network topology profile changes because the first hop is now a different device

ZK Proven’s topology proof detects all four anomalies within the first 200ms proof cycle. The network DNA doesn’t match. The score degrades. If multiple proof streams flag the anomaly simultaneously, the score collapses.

Canary signal detection

ZK Proven’s canary signals pass through the network path and must arrive unmodified. An ARP poisoner running a transparent proxy may inadvertently modify packet timing or ordering, which corrupts the canary response. Even a passive interceptor (one that only copies traffic without modifying it) introduces measurable timing differences that the canary system detects.

The compound attack scenario

ARP poisoning is rarely the attacker’s goal. It is the means to a more valuable end:

1. ARP poison to redirect traffic through the attacker
2. DNS spoof to send the victim to a fake login page
3. SSL strip to downgrade HTTPS to HTTP
4. Capture credentials in plaintext
5. Hijack the session with the stolen cookies

ZK Proven catches this compound attack at step 1. The ARP poisoning changes the network topology. The topology proof fails. The connection is terminated before steps 2 through 5 ever execute.

ARP is broken by design

ARP was designed in 1982 for a network where every device was trusted. That assumption was wrong then and is catastrophically wrong now. The protocol has no authentication, no encryption, and no integrity verification. Every device on a shared network is one command away from being a man-in-the-middle.

ZK Proven doesn’t try to fix ARP. It makes ARP poisoning detectable at the application layer by continuously verifying that the network path matches the expected topology. The poisoned route is wrong — and ZK Proven catches it.