What Is ARP Spoofing? How the LAN Attack Works

A workstation on the same subnet as your domain controller starts answering for an IP it does not own. It sends a stream of unsolicited ARP replies that say "the gateway is at my MAC address." Within seconds the victim's ARP cache and the gateway's ARP cache both point at the attacker, and every packet between them now takes a detour through a machine that was never supposed to be in the path. No exploit fired. No credential was phished. The attacker just answered a question nobody asked, and the network believed it.

That is ARP spoofing, also called ARP cache poisoning. It is a layer 2 attack against the Address Resolution Protocol, the mechanism every IPv4 host uses to map an IP address to a MAC address on the local network. ARP has no authentication, so a host accepts a reply whether or not it sent a request, and it overwrites whatever it had cached before. This guide covers how ARP works and why that trust-by-default design is the whole problem, how the spoofing attack runs step by step, what it lets an attacker do once traffic flows through them, the real tools that automate it, and how a blue team detects and prevents it. It is written for SOC analysts and network forensics practitioners who have to recognize this in a packet capture and shut it down.

What is ARP spoofing?

ARP spoofing is the act of sending forged ARP messages onto a local network to associate the attacker's MAC address with the IP address of another host, usually the default gateway. Once the forgery lands in the target's ARP cache, the target sends traffic destined for that IP to the attacker instead. The attacker forwards it on, drops it, or reads and rewrites it first. MITRE ATT&CK tracks this as technique T1557.002, ARP Cache Poisoning, a sub-technique of T1557, Adversary-in-the-Middle.

The reason it works is that ARP was designed in 1982, in RFC 826, for a network of trusted machines. ARP carries no signature, no sequence number, and no notion of which host is allowed to speak for which IP. A host that receives an ARP reply simply caches the IP-to-MAC mapping it contains. Worse, most stacks accept a "gratuitous" reply, an ARP reply for which no request was ever sent, and use it to update the cache. An attacker does not need to win a race against a legitimate reply. It can broadcast unsolicited replies continuously and keep the poisoned mapping fresh.

ARP spoofing is a local attack. The attacker has to be on the same broadcast domain as the victim, because ARP traffic does not cross a router. That makes it a post-access technique: it shows up after an attacker already has a foothold on the LAN, as a step toward lateral movement, credential capture, or interception of a specific host's traffic.

How ARP works, and why it trusts by default

To see the attack you have to see the protocol. When host A wants to talk to host B on the same subnet, it knows B's IP address but not B's MAC address, and Ethernet frames are addressed by MAC. So A broadcasts an ARP request: "who has 192.168.1.10? Tell 192.168.1.5." Every host on the segment hears it. The host that owns 192.168.1.10 replies, "192.168.1.10 is at aa:bb:cc:11:22:33." A caches that mapping and starts sending frames to that MAC.

RFC 826 defines two message types, distinguished by the operation field: opcode 1 is a request, opcode 2 is a reply. The packet carries the sender's hardware and protocol addresses and the target's, over a 48-bit Ethernet hardware address. Nothing in the format proves the sender is telling the truth. There is no field that ties a reply back to a request, and no authority that says which MAC is allowed to claim an IP.

Three design choices turn that into a weakness. First, ARP is stateless: a host caches any valid-looking reply, even one it never asked for. Second, the cache is overwritable: a newer reply for the same IP replaces the old mapping with no challenge. Third, replies are unauthenticated: the protocol cannot tell a real owner from an impostor. Put together, they mean any host on the segment can rewrite any other host's idea of where an IP lives. That is not a bug in an implementation. It is the protocol working as specified, on the assumption that everyone on the wire is honest.

How an ARP spoofing attack works

The attack is a short sequence, and once it is running it is mostly maintenance. The attacker has already gained access to the LAN, by plugging into a port, compromising a host, or joining the wireless network.

1. Map the segment. The attacker enumerates live hosts and learns the IP and MAC of the victim and the default gateway, usually with a quick ARP scan or by reading broadcast traffic.
2. Forge the replies. The attacker sends a crafted ARP reply to the victim that says "the gateway's IP is at the attacker's MAC," and a second crafted reply to the gateway that says "the victim's IP is at the attacker's MAC." Both are unsolicited.
3. Poison both caches. The victim and the gateway each overwrite their ARP entry for the other. Now the victim's frames for the gateway go to the attacker, and the gateway's frames for the victim go to the attacker. The attacker sits in the middle of the conversation in both directions.
4. Keep it fresh. ARP caches expire entries after a short timeout, and the real hosts will occasionally re-advertise the correct mapping. The attacker re-sends the forged replies on a fast interval so the poisoned mappings never age out or get corrected.
5. Relay the traffic. The attacker enables IP forwarding so packets keep flowing to their real destination. Without forwarding, the victim loses connectivity and the attack becomes a denial of service instead of a silent intercept.

The result is a man-in-the-middle position established entirely at layer 2, invisible to the victim's application, with no certificate warning and no dropped connection if the attacker forwards cleanly.

What ARP spoofing enables

Sitting in the path is the point. What the attacker does from there determines the impact.

• Traffic interception and sniffing. Every unencrypted packet, credentials in cleartext protocols, internal HTTP, DNS queries, SMB, passes through the attacker and can be captured for offline analysis.
• Man-in-the-middle and session hijacking. The attacker does not just read, it rewrites. It can strip TLS down to cleartext with an SSL-stripping proxy, inject content into unencrypted responses, or steal a session token and ride an authenticated session.
• Denial of service. Point the victim's gateway mapping at a nonexistent MAC, or simply stop forwarding, and the victim is cut off the network. Poison an entire segment and you can black-hole a subnet.
• Pivot for credential capture. Combined with relay attacks, an attacker in the middle of SMB or NTLM traffic can capture and relay authentication, which is why ARP spoofing so often precedes lateral movement and privilege escalation deeper into the environment.

The common thread is that ARP spoofing rarely is the objective. It is the access layer for something else: harvesting data, capturing credentials, or interrupting service.

Tools that automate ARP spoofing

ARP spoofing is mature and fully tooled. A defender should know the names because they show up in attacker tradecraft and in lab exercises.

• arpspoof (dsniff). Dug Song's dsniff suite ships arpspoof, the classic single-purpose tool: one command poisons a target and a gateway. It is the canonical teaching example and still present in Kali and most pentest distributions.
• Ettercap. A long-running man-in-the-middle suite (version 0.8.4.x, still maintained as of 2026) that handles ARP poisoning, protocol dissection, and on-the-fly content filtering through a single interface.
• Bettercap. The modern successor, written in Go, with an arp.spoof module and a scriptable framework that covers wired, wireless, and Bluetooth. It is the tool most current LAN attack workflows reach for.

The takeaway is not the command syntax. It is that this attack requires no novel exploit and no privileged software, just a host on the segment and a few packets, which is exactly why detection and prevention have to be designed in rather than assumed.

How to detect ARP spoofing

ARP spoofing leaves a clear signature if you are watching the right place: the same IP suddenly resolving to a new MAC, or one MAC claiming several IPs.

The fastest tell is a duplicate or changed mapping. On a host, compare the live ARP cache against a known-good baseline; an entry where the gateway's IP now points at an unexpected MAC is the attack. On the wire, network traffic analysis of the ARP exchange shows the symptoms directly. Wireshark flags this with its "duplicate use of address detected" expert info when it sees two MACs answering for one IP, and a burst of unsolicited (gratuitous) replies for the gateway IP is the classic poisoning pattern.

Purpose-built monitors automate the watch. arpwatch records every IP-to-MAC pairing it sees on a segment and alerts on a "flip-flop" when a mapping changes. An intrusion detection system with ARP-aware rules raises an alert on the same anomaly. MITRE's detection guidance for T1557.002 reduces to the same indicators across platforms: multiple IP addresses resolving to a single MAC, and unsolicited or repeated gratuitous ARP replies from a device that should not be answering.

How to prevent ARP spoofing

Detection tells you it happened. Prevention removes the trust the attack abuses. The controls layer, from the switch outward.

Dynamic ARP Inspection is the real fix on an enterprise LAN. The switch holds a table of legitimate IP-to-MAC bindings, learned from DHCP snooping, and drops any ARP packet whose claimed mapping does not match. A forged reply never reaches the victim. Static ARP entries achieve the same protection for a small set of critical hosts but do not scale to a whole network. Encryption does not prevent the attack at all, it removes the reward: an attacker who intercepts only TLS-protected traffic gets ciphertext, which is why MITRE lists "encrypt all traffic" as a mitigation alongside DAI. The defensive posture that holds is DAI plus DHCP snooping on the access switches, static entries for the gateways and critical servers, and end-to-end encryption so interception buys nothing.

The bottom line

ARP spoofing works because the Address Resolution Protocol trusts by default. A host caches any ARP reply it hears, overwrites the old mapping without challenge, and cannot tell a real owner from an impostor, so an attacker on the segment can claim the gateway's IP with a few forged packets and silently sit in the middle of the traffic. MITRE tracks it as T1557.002, ARP Cache Poisoning, under the Adversary-in-the-Middle technique, and the tooling, arpspoof, Ettercap, and Bettercap, makes it a few-keystroke attack.

For a defender the response is layered and concrete. Detect it by watching for one IP mapping to a new MAC, the "duplicate use of address" that Wireshark and arpwatch surface. Prevent it with Dynamic ARP Inspection and DHCP snooping on the switches, static entries for the hosts that matter, and encryption so interception buys nothing. The protocol will not change. The controls around it are what keep an attacker from turning a single foothold on the LAN into a window onto everyone's traffic.