ARP Spoofing and MITM: Detection, Prevention, and Response

ARP Spoofing and MITM: Detection, Prevention, and Response

Most intrusions that “just appear” on a flat LAN turn out to be old-fashioned address trickery. Address Resolution Protocol (ARP) is simple by design, and that simplicity is what an attacker bends to their advantage to slip in the middle of conversations between hosts and the default gateway.

When ARP is poisoned, devices cache the wrong mapping between an IP address and a MAC address. Packets meant for the gateway are sent to the attacker first, who can relay them (man-in-the-middle), drop them, or modify them. The attack lives at Layer 2, so it’s invisible to most Layer 3 controls unless you’re looking for the right symptoms.

The good news: you can detect it early, prevent it reliably with a few hardened switch features, and respond in minutes. We’ll walk through how the attack works, the signs to watch for, tooling that catches it, and a practical defense and response playbook you can ship into production.

How ARP Spoofing Works

ARP answers the question “who has IP X, tell MAC Y” by broadcasting requests and caching replies for a short time. Spoofing abuses the trust model: an attacker sends forged ARP replies (often gratuitous ARP) that bind the victim’s gateway IP to the attacker’s MAC, and binds the gateway’s ARP cache the other way around. Because ARP has no authentication, the newest reply usually wins and overwrites the cache. This scales to any pair of hosts within the same broadcast domain, so VLAN boundaries define the blast radius.

Poisoning Variants You’ll See

Common patterns include one-way poisoning (victim → attacker → gateway), full-duplex MITM (both victim and gateway poisoned), and denial-of-service where the attacker maps a target IP to a non-existent MAC to blackhole traffic. Tools automate the ARP flood with configurable intervals to keep caches poisoned and avoid timeouts.

Why It Works by Default

Default host stacks accept unsolicited ARP replies and refresh their caches without verifying provenance. Switches forward ARP frames to all ports in a VLAN, so every host sees them. Without Layer 2 validation, the last writer wins.

Telltale Signs and Common Artifacts

Most networks leak indicators before users complain. Watch for these: sudden gateway MAC changes on endpoints, duplicate IP warnings, bursts of gratuitous ARP replies, asymmetric traceroutes from the same host, and TLS errors when the attacker tries and fails to intercept encrypted sessions. On switches, MAC address tables can churn, showing a single MAC hopping between ports or the gateway IP resolving to an unexpected MAC at the edges.

Packet-Level Indicators

Packet captures show clusters of ARP opcode 2 (reply) frames with sender IP equal to the gateway but with a MAC that doesn’t match the gateway interface. Gratuitous ARPs with mismatched source MAC/IP pairs and high reply rates (dozens per second) from a non-gateway port are strong signals.

Host and Switch CLI Clues

On Linux/macOS, “ip neigh” or “arp -a” revealing the gateway IP mapped to a non-vendor MAC is suspicious; on Windows, “arp -a” does the same. On enterprise switches, compare the ARP table and MAC address table; if the gateway IP points to a MAC learned on an access port rather than the uplink, you’ve likely got poisoning.

Network Controls That Prevent Poisoning

Layer 2 is where you win. Implement controls that either prevent forged mappings from taking hold or make them irrelevant by limiting the broadcast domain and the ability to inject ARP.

Static ARP for Crown Jewels

For critical servers and the default gateway, static ARP entries remove ambiguity. Hosts ignore unsolicited changes, and switches that support static IP–MAC bindings enforce them in hardware. It’s not scalable to every endpoint, but it’s effective on choke points.

DHCP Snooping to Build Truth

Enable DHCP snooping on access VLANs so the switch records leases into a binding table keyed by MAC, IP, VLAN, and interface. Mark only uplinks to the trusted DHCP server as “trusted” and all access ports as “untrusted.” This table becomes the source of truth for downstream ARP validation.

Dynamic ARP Inspection (DAI)

With DHCP snooping active, turn on DAI for the same VLANs. DAI intercepts ARP on untrusted ports and validates sender IP/MAC against the snooping table; violations are dropped and can be rate-limited, logged, and counted. Trust only infrastructure ports; keep client ports untrusted.

VLAN Design and Smaller Broadcast Domains

Keep VLANs small and role-oriented so the blast radius is bounded. Put untrusted user segments in separate VLANs from servers; inter-VLAN traffic then crosses routed boundaries where you can apply ACLs, firewalling, and telemetry. Smaller domains reduce the attacker’s audience and make anomalies stand out.

Port Security and 802.1X

Limit the number of MAC addresses per port and enable sticky learning where appropriate; shut or restrict on violation. 802.1X with dynamic VLAN assignment adds identity and per-user isolation, further reducing chances that a rogue device can sit in the same broadcast domain as targets.

Host Hardening (ARP Behavior)

Harden host ARP behavior where practical: reduce ARP cache timeouts on critical systems, prefer static entries for default gateways, set sysctls to mitigate ARP flux on multi-homed Linux hosts (arp_ignore/arp_announce), and monitor for unexpected cache changes.

Detection Tools and Practical Playbook

Combine on-demand verification with continuous watchers. You want low-latency signal when poisoning begins and enough context to point a finger at a port and a MAC.

Wireshark and CLI Quick Checks

On a suspect host, capture with a filter like “arp” and look for frequent unsolicited replies; display filters such as “arp.opcode == 2 and arp.src.proto_ipv4 == GATEWAY_IP and eth.src != GATEWAY_MAC” isolate forged frames. The “arp.duplicate-address-detected” expert info also flags conflicts. Command-line tools like “arping -I IFACE GATEWAY_IP” show who responds; two different MACs responding is a red flag.

Continuous Monitoring with Sensors

Lightweight daemons such as arpwatch or bettercap in passive mode can alert on MAC/IP changes. On switches, enable syslog/SNMP traps for DAI violations and port-security shutdowns; feed them to your SIEM to correlate by VLAN and access port.

Switch Telemetry and Forensics

Use the switch to prove the case: “show ip dhcp snooping binding,” “show ip arp inspection statistics,” and “show mac address-table” reveal the violating port. Rate-limit ARP on access ports to blunt floods without harming normal behavior.

Virtual and Cloud Environments

In hypervisors, enable port isolation/forged transmit protections in virtual switches so VMs can’t spoof MACs or inject ARP widely. In cloud overlays, ARP is often proxied; rely on security groups and microsegmentation rather than trusting L2 broadcasts.

Rapid Response and Recovery

When alerts fire, move fast and be deterministic. First, isolate the suspected port: shut it or move it to a quarantine VLAN. Second, clear poisoned state: on switches, clear ARP and MAC tables for the affected VLANs; on hosts, flush ARP caches (“ip neigh flush all” or “arp -d -a”, “netsh interface ip delete arpcache”). Third, restore correct mappings with static entries on the default gateway and critical hosts. Fourth, validate: ping through the gateway, confirm the MAC matches the vendor OUI you expect, and re-check with live captures for a few minutes. Finally, root-cause by user, device fingerprint, and port history, then decide whether to keep DAI/port-security thresholds tightened permanently.

Limitations, Edge Cases, and False Positives

DAI depends on accurate DHCP snooping data; static IP endpoints need manual bindings or they will hit false positives. Some load balancers or HA pairs send legitimate gratuitous ARPs during failover; whitelist those ports or vendors. Tooling that tunnels or proxies traffic (softphones, VPN clients) can look odd at Layer 2; verify before you swing the hammer. And remember: encrypted protocols still protect confidentiality and integrity even under MITM—spoofing hurts availability and visibility but not well-configured TLS.

Operational Checklist You Can Adopt

Start with a baseline: inventory gateway MACs by VLAN and pin them in documentation; enable DHCP snooping on all user VLANs; enable DAI where snooping is in place; set ARP rate limits on access ports; enforce port-security with sane MAC limits; instrument logs/traps into your SIEM; write a one-page runbook for isolation and cache flush; test it quarterly.

What Not to Do

Don’t rely on endpoint antivirus to catch this—it’s a network-layer problem. Don’t leave giant /16 user VLANs in place; you’re giving the attacker an auditorium. Don’t enable DAI without verifying every static IP device is covered by a static binding. And don’t assume IPv4-only controls help with IPv6; treat them as separate hardening tracks.

ARP Spoofing and MITM: Key Questions (FAQ)

Check the ARP cache for the gateway entry and compare the MAC with a known-good value; if it changed unexpectedly, capture traffic for ARP replies and confirm unsolicited updates, and if needed verify the public address with My IP Address to rule out unrelated routing issues.

IPv6 doesn’t use ARP, but it has Neighbor Discovery and Router Advertisement spoofing risks, so harden IPv6 separately and verify connectivity with an IPv6 Test when you enable defenses.

Start with DHCP snooping to build bindings, turn on dynamic ARP inspection for those VLANs, add port-security MAC limits, and rate-limit ARP on untrusted ports so forged frames are dropped and logged promptly.

Use a fresh resolver path and run a DNS Lookup from a trusted host, then compare the resolved IP with what you see in ARP and your device inventory before taking action.

Yes, you can convert names to addresses using a simple Domain to IP check, then verify that the ARP entry for that address points to the expected MAC on your segment.

Reverse lookups help you spot anomalies like client devices resolving to infrastructure names, so doing a quick Reverse DNS Lookup can highlight mis-registrations during spoofing events.

Keep broadcast domains small and role-based—use a Subnet Calculator to plan subnets so high-value servers don’t share a VLAN with untrusted clients, forcing traffic through routed controls.

Isolate the offending port first, then flush ARP caches on switches and affected hosts in a controlled window, restore static entries on gateways and critical servers, and verify with a short packet capture before reopening access.