ARP Spoofing Explained: LAN Poisoning & DAI Defense
How ARP cache poisoning lets an attacker intercept traffic on a local network, why the protocol is trivial to abuse, and how to shut it down.
Every device on a local network needs to turn IP addresses into hardware addresses before it can send a single frame. The protocol that does this, the Address Resolution Protocol, was designed in an era of trusted networks and it trusts completely. Any host can announce that it owns any IP address, and every other host on the segment will believe it.
ARP spoofing is the abuse of that trust. An attacker on the same local network sends forged ARP messages to reroute traffic through their own machine. It is one of the oldest interception techniques and, on a flat unprotected LAN, one of the most reliable.
How ARP is supposed to work
When a host wants to send a packet to an IP on its local network, it needs the destination's MAC address. It broadcasts an ARP request: who has this IP address? The owner replies with its MAC address, and the asker caches that mapping so it does not have to ask again for a while.
The original protocol, RFC 826, has no notion of proof. A reply is accepted at face value. There is no signature, no challenge, no check that the responder actually owns the address it is claiming. Many implementations will even accept an unsolicited ARP reply, a gratuitous ARP, and update their cache from it without ever having asked.
That design is convenient and fast. It is also exactly what makes the attack possible.
How the poisoning works
An attacker on the same broadcast domain sends forged ARP replies, a technique MITRE ATT&CK tracks as ARP Cache Poisoning (T1557.002). The usual play targets two mappings at once:
- Tell the victim that the gateway's IP now lives at the attacker's MAC address.
- Tell the gateway that the victim's IP now lives at the attacker's MAC address.
With both caches poisoned, the attacker sits between the victim and the gateway. The victim's outbound traffic goes to the attacker, who forwards it to the real gateway. Return traffic comes back the same way. The attacker keeps IP forwarding enabled so the connection keeps working, which is what makes the interception quiet. Nothing appears broken.
From that position the attacker can read everything that is not encrypted, modify requests and responses in flight, redirect connections, or simply drop traffic to cause a denial of service. It is the textbook path into a man-in-the-middle position on a LAN, and it needs nothing more than a foothold on the same network segment.
ARP spoofing does not cross routers, so it is bounded to a single broadcast domain. Inside that boundary the reach is near total. A guest on your Wi-Fi, a compromised laptop in the office, or a rogue device in a network closet can poison the segment and intercept every unencrypted flow on it. Flat networks with many untrusted devices are the ideal target.
What an attacker gains
The value of the position depends entirely on what the traffic looks like once intercepted.
| Traffic type | What the attacker gets | Limiting factor |
|---|---|---|
| Plain HTTP | Full content, cookies, form data | None, fully exposed |
| Unencrypted internal protocols | Credentials, commands, data | None, fully exposed |
| HTTPS with valid TLS | Ciphertext only, plus metadata | TLS authentication and encryption |
| HTTPS reachable via SSL stripping | Downgraded plaintext | HSTS and preload close this |
| Any traffic | Ability to drop or delay it | Availability impact regardless of encryption |
The table points at the real lesson. Poisoning gets the attacker in the middle, but encryption decides whether that position is a jackpot or a dead end. Against plaintext it is a jackpot. Against properly validated TLS the attacker is reduced to seeing encrypted bytes and, at most, disrupting availability.
Why you cannot fix the protocol
There is no patch for ARP that adds authentication and keeps compatibility with the enormous installed base that expects the old behavior. The protocol is doing what it was designed to do. This means the defense cannot live in the protocol. It has to live in the infrastructure that carries it, specifically the switches.
Modern managed switches understand this and offer features built precisely to catch forged ARP traffic before it reaches victims.
How to defend against ARP spoofing
The strongest defenses combine switch-level enforcement with encryption, so that poisoning is both hard to pull off and worthless when it happens.
- Enable Dynamic ARP Inspection (DAI). DAI intercepts ARP packets on untrusted ports and validates them against a trusted table of IP-to-MAC bindings. Forged replies that do not match are dropped. This is the single most effective control on a managed network.
- Turn on DHCP snooping. DAI relies on a binding table, and DHCP snooping builds it by watching legitimate DHCP exchanges. The two features work together; enable them as a pair.
- Use port security. Limiting the number of MAC addresses per switch port and locking ports to expected devices makes it harder for a rogue host to operate freely.
- Segment the network. Smaller VLANs and separated trust zones shrink each broadcast domain, which shrinks the blast radius of any single poisoning. Keep untrusted devices, such as guest Wi-Fi, off segments with sensitive systems. Configuration discipline here follows the spirit of NIST SP 800-128.
- Encrypt everything on the wire. Assume a host on the segment may be malicious and make that assumption survivable. Authenticated TLS turns a successful poisoning into a view of ciphertext.
- Enforce HSTS and preload on web services. This removes the SSL stripping path that an on-path attacker would otherwise use to downgrade HTTPS to HTTP.
- Watch for the signatures. Monitoring for a MAC address suddenly claiming the gateway IP, or for many ARP replies from one host, surfaces active poisoning. Static ARP entries for critical hosts, where practical, refuse to be overwritten at all.
For a broader view of which intrusion sets use LAN interception as part of their playbook, our Threat Group Directory ties adversaries to the on-path techniques they favor.
Treat ARP spoofing as a defense-in-depth problem. Dynamic ARP Inspection stops the forgery at the switch, and encryption makes any forgery that slips through worthless. Rely on the switch alone and an unmanaged segment leaves you exposed; rely on encryption alone and you still hand attackers the ability to disrupt traffic. Do both.
ARP spoofing endures because the protocol underneath it trusts by default and cannot be retrofitted to stop. The answer is to move the trust decision up into the switch with Dynamic ARP Inspection, shrink the segments where poisoning can happen, and encrypt the traffic so that being in the middle stops being valuable. Do that and the oldest LAN interception trick loses most of its bite.
What an ARP packet carries
To see why the attack is so simple, look at what an ARP message actually contains. A reply names four things that matter: the sender's hardware (MAC) address, the sender's IP address, the target's hardware address, and the target's IP address. When a host receives a reply, it reads the sender IP and sender MAC fields and updates its cache so that IP now points to that MAC.
Nothing in the packet proves the sender owns the IP it claims. The fields are just values the sender chose to write. An attacker crafts a reply that says the gateway's IP belongs to the attacker's MAC, sends it to the victim, and the victim's cache dutifully records it. There is no signature to forge, no sequence number to guess, no challenge to answer. The forgery is a matter of setting four fields to the values you want. That is the whole reason the attack needs no sophistication: the protocol accepts assertions as facts.
Two behaviours make it easier still. Many stacks accept a gratuitous ARP, an unsolicited reply announcing a mapping, and will update the cache from it even though they never asked. And many will accept a reply even if they had no outstanding request. Together these mean an attacker does not have to wait for the victim to ask. They can push forged mappings whenever they like and refresh them periodically so the poisoning persists.
A step-by-step walkthrough
Follow the sequence an attacker runs to place themselves between a victim and the gateway. This describes the mechanism so you can recognise and detect it, not a recipe to run.
- The attacker gains a foothold on the same broadcast domain, for example by connecting to the office Wi-Fi or compromising a host on the segment.
- They enable IP forwarding on their machine so that traffic passing through them continues to its real destination and nothing appears broken to the victim.
- They send the victim a forged ARP reply mapping the gateway's IP to the attacker's MAC. The victim's cache now sends gateway-bound traffic to the attacker.
- They send the gateway a forged ARP reply mapping the victim's IP to the attacker's MAC. Return traffic for the victim now comes to the attacker as well.
- They re-send both forgeries on a short interval, so that a legitimate ARP reply from the real gateway does not undo the poisoning for long.
- Traffic now flows victim to attacker to gateway and back, with the attacker able to read, alter, redirect, or drop anything that is not protected by encryption.
The elegance for the attacker is that steps 3 and 4 are ordinary ARP replies, indistinguishable in form from legitimate ones. The only thing wrong with them is that they are untrue, and classic ARP has no way to tell truth from assertion.
Detection signals
Because poisoning leaves the network working, detection depends on watching the ARP layer itself rather than waiting for something to break. Concrete indicators:
- One MAC address suddenly claiming the gateway IP. The gateway's mapping should be stable. A new MAC asserting ownership of it is the clearest sign of an active attack.
- A single MAC mapped to many IP addresses. An attacker impersonating several hosts at once shows up as one hardware address claiming multiple IPs across the segment.
- A burst of gratuitous or unsolicited ARP replies. Legitimate ARP traffic is mostly request and answer. A flood of unsolicited replies, especially repeating on an interval, is abnormal.
- A cached mapping that changes and then flaps. When the attacker's forgery and the real host's genuine reply compete, the mapping can oscillate between two MACs, which monitoring can catch.
- Duplicate-IP or MAC-change warnings. Some hosts and switches log when an IP-to-MAC binding they trusted changes unexpectedly. Those logs are worth collecting and alerting on.
- Dynamic ARP Inspection drop counters climbing. On a managed switch, a rising count of dropped ARP packets on untrusted ports means forgeries are being caught, which is both a defence and a signal.
The hardest thing about detecting ARP spoofing is that a successful attack breaks nothing. The attacker forwards traffic so pages still load and calls still connect. There is no outage to investigate, no error to chase. The only evidence is at the ARP layer: mappings that changed when they should not have, and a host asserting ownership of addresses that are not its own. If you are not watching that layer, a quiet attacker leaves almost no trace a user would notice.
How ARP spoofing compares to related attacks
ARP spoofing is one of several ways to reach a man-in-the-middle position or redirect traffic. Placing it against its neighbours clarifies its scope and its fix.
| Attack | Layer | Scope | Root cause | Primary defence |
|---|---|---|---|---|
| ARP spoofing | Link (2) | One broadcast domain | ARP has no authentication | Dynamic ARP Inspection, encryption |
| DNS spoofing | Application (7) | Depends on the resolver reached | Unauthenticated name resolution | DNSSEC, trusted resolvers, encryption |
| DHCP spoofing | Application on link | One broadcast domain | Any host can answer DHCP | DHCP snooping |
| MAC flooding | Link (2) | One switch | Limited CAM table capacity | Port security |
| Rogue access point | Physical and link | Radio range | Clients trust familiar SSIDs | 802.1X, client validation |
The common thread across the link-layer attacks is that the local network was built to trust its own participants, and the defences all live in the switch and the access layer rather than in the protocols themselves. ARP spoofing is the archetype. See DNS Spoofing Explained and Man-in-the-Middle Attacks Explained for how the same on-path goal is reached at other layers.
Common misconceptions
Several beliefs about ARP spoofing lead to weak defences.
- "HTTPS makes ARP spoofing harmless." Encryption denies the attacker plaintext, which is the biggest prize. It does not stop them from dropping or delaying traffic to cause an outage, and it does not help against any plaintext protocol still on the segment. Encryption is necessary and not by itself sufficient.
- "It can reach across the internet." ARP is confined to a single broadcast domain and does not cross routers. An attacker has to be on the same segment as the victim. That boundary is a real limit on the attack's reach.
- "Static ARP entries everywhere will fix it." Static entries protect the specific mappings you pin, such as the gateway, and they refuse to be overwritten. Maintaining them for every host on a large network is impractical, which is why Dynamic ARP Inspection is the scalable control and static entries are a targeted supplement.
- "A software ARP watcher on each host is enough." Host-based detection can notice a changed mapping, but it acts after the forgery arrived and it does not stop the packet. Switch-level Dynamic ARP Inspection drops the forgery before it reaches the victim, which is a stronger position.
- "Only wired networks are affected." Wireless clients on the same subnet share a broadcast domain and are just as poisonable. Open or lightly protected Wi-Fi is a common launch point precisely because getting a foothold on the segment is easy.
How the attack and its defences evolved
ARP dates to the early 1980s and RFC 826, written for networks where every attached host was trusted. The lack of authentication was a reasonable choice in that setting. As local networks grew, connected untrusted devices, and carried valuable traffic, the same design became a liability, and ARP poisoning became a staple of penetration tests and real intrusions alike. It is attractive because it is reliable on a flat segment and requires only a foothold and ordinary packets.
The defence moved into the switching layer because the protocol could not be changed without breaking the installed base. Managed switches gained DHCP snooping, which watches legitimate DHCP exchanges to learn which IP belongs to which MAC on which port, and Dynamic ARP Inspection, which uses that binding table to validate ARP packets and drop the ones that do not match. In parallel, the broader move to encrypt traffic end to end, HTTPS everywhere, HSTS and preload to close the SSL stripping downgrade, and encrypted internal protocols, reduced the value of an on-path position even where poisoning still succeeds. The result is a layered answer: the switch stops most forgeries, and encryption makes the ones that slip through far less useful. Neither alone is complete, which is why current guidance pairs them.
Responding to an active poisoning
Detection is only useful if it leads somewhere, so it helps to know what to do when the signals fire. The goal is to remove the attacker's foothold and restore trustworthy mappings, in that order.
Start by identifying the rogue MAC. The detection signals point to one hardware address claiming an IP it should not own, usually the gateway. On a managed switch you can map that MAC to the physical port it is arriving on, because the switch knows which port learned which address. That port is the attacker's connection point, whether it is a wall jack, a wireless client association, or an uplink from an unmanaged device.
With the port identified, contain it. Shutting the port, isolating the wireless client, or moving it to a quarantine VLAN cuts the forged replies at the source. Once the attacker stops sending forgeries, the poisoned caches recover as legitimate ARP traffic reasserts the real mappings, though clearing the affected caches speeds this up. Static ARP entries for critical hosts, where you maintain them, will already have refused the forgery for those mappings.
Then close the gap that let it happen. If Dynamic ARP Inspection and DHCP snooping were not enabled on that segment, this is the moment to turn them on, because they would have dropped the forgeries at the switch. If an untrusted device reached a sensitive segment, revisit the segmentation so guest and unmanaged devices cannot share a broadcast domain with systems that matter. The incident is the argument for the controls that would have prevented it.
Frequently asked questions
Does ARP spoofing work over the internet? No. ARP operates within a single broadcast domain and does not cross routers, so an attacker must be on the same local segment as the victim. That is why the attack is associated with shared Wi-Fi, office LANs, and compromised local hosts rather than remote attackers.
If all my traffic is HTTPS, do I still need to care? Yes. Encryption protects the confidentiality and integrity of the traffic it covers, but a poisoning attacker can still drop or delay packets to disrupt availability, and any plaintext protocol left on the segment remains exposed. HSTS and preload also matter, because they close the SSL stripping path an on-path attacker would use to downgrade HTTPS.
What is the single most effective control? On a managed network, Dynamic ARP Inspection paired with DHCP snooping. DHCP snooping builds the trusted table of IP-to-MAC bindings, and Dynamic ARP Inspection uses it to drop forged ARP packets on untrusted ports before they reach a victim. Enable them together, because one depends on the other.
How is ARP spoofing different from DNS spoofing? ARP spoofing operates at the link layer and redirects traffic within a local segment by corrupting IP-to-MAC mappings. DNS spoofing operates at the application layer and redirects traffic by returning false name-to-IP answers. They target different steps of reaching a destination and have different defences, though both aim to put an attacker in the path.
Can I detect it from a normal computer? Partly. Host tools can watch the local ARP cache for a mapping that changes unexpectedly, especially the gateway suddenly resolving to a new MAC. This detects an attack in progress but does not prevent it. Switch-level Dynamic ARP Inspection is the control that actually stops the forged packets.
Why can the ARP protocol not just be fixed? Adding authentication to ARP would break compatibility with the vast installed base of devices that expect the original unauthenticated behaviour. Rather than change the protocol, the industry moved the trust decision into managed switches, which can validate ARP traffic against a known-good binding table without requiring endpoints to change.
Does network segmentation help? Yes. Because ARP spoofing is bounded to a single broadcast domain, smaller VLANs and separated trust zones shrink the blast radius of any one poisoning. Keeping untrusted devices, such as guest Wi-Fi, off segments with sensitive systems limits where an attacker who poisons a segment can reach.
Related guides
Sources & further reading
Related guides
- Man-in-the-Middle: On-Path Interception & TLS Defense
How man-in-the-middle attacks intercept and relay traffic from an on-path position, the techniques attackers use to get there, and how TLS stops them.
- Active Directory Security: Structure, Tiering & Hardening
How Active Directory is built, the tiered administration model, the weaknesses attackers exploit, and a hardening checklist for defenders.
- BGP Hijacking Explained: Route Hijacks, Leaks & RPKI Defense
How BGP route hijacking and route leaks reroute internet traffic, why the protocol trusts by default, and how RPKI and route filtering defend against it.