ARP Spoofing: Definition, How It Works, Detection, and Mitigation
ARP spoofing is a local-network attack where an adversary sends forged ARP messages to associate their MAC address with another device’s IP address (commonly the default gateway). Once caches are poisoned, the victim may send traffic to the attacker’s device instead of the intended destination—enabling interception, manipulation, redirection, or denial of service within the same broadcast domain.
ARP spoofing (also called ARP poisoning) is a common local-network attack that forges IP→MAC mappings to redirect traffic inside a LAN—often enabling a man-in-the-middle (MITM) position. If you manage Wi‑Fi, office VLANs, or any shared Layer 2 segment, understanding ARP spoofing and deploying the right switch controls (especially Dynamic ARP Inspection + DHCP snooping) is one of the highest-ROI steps you can take to reduce LAN-based interception.
How ARP spoofing works
ARP (Address Resolution Protocol) exists because Ethernet forwards frames using MAC addresses, while applications connect using IP addresses. When a host wants to send traffic to 192.168.1.1 (often the gateway), it broadcasts: “Who has 192.168.1.1?” The device replies with its MAC, and the host typically caches that mapping.
ARP spoofing abuses two common realities:
- ARP is unauthenticated: classic ARP provides no built-in integrity checks.
- Hosts accept updates: many systems will update ARP caches from ARP replies—including unsolicited (“gratuitous”) ARPs—depending on OS behavior and timing.
Typical attack flow (gateway spoof)
- Recon: attacker learns victim IP and gateway IP (from DHCP, ARP tables, scanning).
- Poison the victim: attacker sends ARP replies claiming:
Gateway IP → Attacker MAC - Poison the gateway: attacker sends ARP replies claiming:
Victim IP → Attacker MAC - Interception: victim traffic for off-subnet destinations goes to the attacker’s MAC; return traffic also goes to the attacker’s MAC.
- Forwarding (to stay stealthy): attacker forwards packets between victim and gateway to keep sessions alive (MITM). Without forwarding, this often becomes a DoS.
Why TLS limits impact (but doesn’t eliminate it)
HTTPS/TLS reduces what an attacker can read/modify, but ARP spoofing can still be useful for:
- Credential theft when internal apps are HTTP or poorly configured
- DNS manipulation if DNS is unprotected and clients trust the path
- Capturing legacy protocol data (FTP/Telnet, misconfigured SMB, older mail protocols)
- Traffic analysis (service discovery, internal hostnames, metadata)
- Session hijacking in edge cases where apps mishandle tokens or downgrade protections
What ARP spoofing looks like on the wire (packet captures)
In packet captures, ARP spoofing often appears as repeated ARP replies asserting a mapping that conflicts with reality.
Common indicators: - Multiple MAC addresses claiming the same IP - Frequent ARP replies for the gateway IP - Unexpected gratuitous ARP updates
Useful Wireshark display filters:
arp.opcode == 2
Filter for suspicious “gateway IP” claims (replace the IP):
arp && arp.opcode == 2 && arp.src.proto_ipv4 == 192.168.1.1
Host-side checks (quick validation)
Windows: view ARP cache
arp -a
Linux: neighbor table / ARP
ip neigh show
# or
arp -n
macOS: ARP table
arp -a
What to look for: - The default gateway IP mapped to an unexpected MAC - The same MAC “owning” many IP mappings (sometimes legitimate due to proxy ARP, but worth investigating)
When you’ll encounter ARP spoofing
1) Shared office networks and flat VLANs
Small/mid-sized environments often have: - Large “everything” VLANs - Limited switch security configuration - Guest Wi‑Fi too close to corporate segments
In these setups, a compromised endpoint (or malicious insider) can poison neighbors quickly.
2) Public or semi-public Wi‑Fi (hotels, cafés, events)
If clients can communicate at Layer 2 (or isolation is misconfigured), ARP spoofing becomes a realistic path to: - Intercepting captive portal interactions - Triggering certificate warnings via redirection/downgrade attempts - Observing service-discovery chatter and metadata
If you’re securing a home setup, segmentation and Wi‑Fi hardening matter; see how do i secure my home wi fi network for practical steps that reduce exposure on consumer-grade networks.
3) Incident response: “weird network” symptoms
ARP spoofing can explain: - Intermittent connectivity - Sudden certificate warnings after “nothing changed” - DNS responses changing unexpectedly - Duplicate IP alerts
4) Lab environments and security testing
Red teams use ARP spoofing to validate whether: - Internal apps still use HTTP - East-west traffic is overly trusted - Switch protections (DAI/DHCP snooping/port security) are actually enforced
Detection and mitigation (what works in practice)
Network-side mitigations (best ROI)
1) Enable DHCP snooping + Dynamic ARP Inspection (DAI)
On many managed switches: - DHCP snooping builds a trusted binding table (IP↔MAC↔port). - DAI validates ARP packets against that binding table and drops forged ARP.
Vendor-neutral checklist: - Mark only uplink ports (to DHCP server/router) as trusted - Enable DHCP snooping on user VLANs - Enable DAI on the same VLANs - Rate-limit ARP on access ports to reduce ARP floods
2) Segment your network (reduce L2 blast radius)
- Put guest Wi‑Fi, IoT, and user endpoints into separate VLANs
- Use L3 boundaries + firewall policy to reduce opportunities for ARP-based attacks
3) Use static ARP entries for critical systems (selectively)
This is useful for a small number of fixed systems (certain servers/infrastructure). Use sparingly—static ARP can break during failovers or hardware changes.
Linux (temporary until reboot):
sudo ip neigh replace 192.168.1.1 lladdr aa:bb:cc:dd:ee:ff nud permanent dev eth0
Windows (interface name varies):
netsh interface ipv4 show interfaces
netsh interface ipv4 add neighbors "Ethernet" 192.168.1.1 aa-bb-cc-dd-ee-ff
Monitoring signals worth alerting on
- Gateway IP mapped to a new MAC (change detection)
- High ARP reply rates from a single port/MAC
- Duplicate IP usage events (from DHCP logs, switch logs, endpoint telemetry)
If you have SPAN/TAP capture, correlate: - ARP churn → DNS anomalies → TLS handshake failures/cert warnings → unexpected MAC as a transit point
Practical hardening for endpoints on untrusted networks
If you can’t control the switch (e.g., traveling or using shared Wi‑Fi), prioritize protections that reduce what a LAN MITM can do:
- Prefer HTTPS-only browsing and avoid clicking through certificate warnings
- Use a reputable VPN to reduce local interception of traffic metadata/content
- Keep endpoints patched and remove/disable legacy plaintext services
A VPN can help reduce exposure on hostile LANs; if you’re evaluating providers, options like NordVPN (Check NordVPN pricing →) or Surfshark (Try Proton VPN →) are commonly used for travel and café Wi‑Fi scenarios.
Further reading
- If you’re building a vulnerability management and remediation workflow that reduces the impact of network-layer attacks, see patch management best practices a practitioners guide.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
Related terms
Maps IPv4 addresses to MAC addresses on a local network.
Local storage of recent IP→MAC mappings.
Another name for ARP spoofing; emphasizes corruption of ARP caches.
Attacker intercepts traffic between endpoints.
Unsolicited ARP announcements used for updates or duplicate IP detection; can be abused.
Switch feature that blocks forged ARP packets using trusted bindings.
Switch feature that tracks legitimate DHCP assignments and helps prevent spoofing/rogue DHCP.
Switch control limiting MAC addresses per port; helpful, but not a replacement for DAI.
Legitimate behavior where a router answers ARP on behalf of another host; can resemble spoofing in logs.
IPv6’s analogous risk area; different protocol, similar threat model.