ARP poisoning: four frames move a victim's gateway to the attacker

At 4.6 seconds into this ARP poisoning PCAP, a Hewlett Packard network card, 00:25:b3:bf:91:ee, tells the victim 172.16.0.107 that the gateway 172.16.0.1 lives at its MAC address. Two seconds later the victim's traffic to the outside world starts leaving through that card instead of the Cisco gateway it used before. ARP poisoning is a link-layer man-in-the-middle technique, and it works because ARP has no way to tell a true answer from a false one. A-Packets reads the ARP exchanges from the capture and shows one MAC claiming both the gateway's address and another local IP, the whole mechanism of the attack in a single view.

The capture is only 165 packets over fourteen seconds, a clean demonstration rather than a real incident, but the evidence it contains is exactly what a real ARP poisoning leaves behind: a forged claim in ARP and, more convincing still, a changed Ethernet next hop in the victim's own packets.

Why ARP believes a lie

ARP resolves an on-link IPv4 address to a MAC address, and for anything off the subnet a host resolves its gateway rather than the remote server. Nothing in an ARP message is authenticated: any station can announce that an address lives at its MAC, and most operating systems update their cache from such messages. The attacker never touches the remote server; it only has to win the victim's local answer to the question "where is the gateway".

ARP processing takes sender information from requests as well as replies, so the opcode, the sender IP, the sender MAC and the target fields have to be read together. A monitor that watches only gratuitous replies misses a request with a forged sender, which is exactly how the attack in this capture begins. The opposite mistake is just as easy: legitimate address configuration and gateway failover use ARP announcements too, so the meaning comes from the sequence and from who should own the address.

The giveaway: one MAC answering for the gateway

The ARP view lists each IP and the MAC address that claimed it, and flags a MAC that claims more than one.

Open the ARP view →

Here one hardware address claims two IPs, 172.16.0.105 and the gateway's 172.16.0.1, which is the signature the view is built to expose. A router or a proxy-ARP setup can legitimately answer for several addresses, so check the MAC against the network design; in this capture the change in the victim's Ethernet delivery, below, settles the question. It is the first thing to look for in any capture where a man-in-the-middle is suspected.

The sequence takes four frames. Frame 54, at 4.646389 seconds, is a unicast ARP request from 00:25:b3:bf:91:ee to the victim's MAC, 00:21:70:c0:56:f0, whose sender IP claims 172.16.0.1; frame 55 is the victim's reply, and frame 56 advertises 172.16.0.1 at the same claiming MAC in an ARP reply. Frame 165, the last in the file, uses that MAC with sender IP 172.16.0.105 in a broadcast request for the gateway, which is why the multi-IP row links the two addresses. None of the four is gratuitous, and only one MAC ever advertises the gateway in this window, so a detector that waits for two competing gateway replies would miss the attack entirely.

Seeing the consequence in the victim's traffic

Poisoning is not the goal in itself; it is the setup, and the victim's own packets show it taking effect. Before the ARP exchange the victim sends 28 packets to the gateway's Ethernet address, 00:26:0b:31:07:33, a Cisco interface, and receives 25 from it. After it, all 60 of its outbound IP packets go to 00:25:b3:bf:91:ee and 48 come back from that MAC, starting with frame 57 at 6.553250 seconds, still addressed at the IP layer to an external server. The IP destination never changes; the Ethernet next hop is now the attacker. That is ARP poisoning made visible.

What crosses the attacker's machine is the victim's ordinary browsing: web requests to Google services, the pages they loaded and the DNS lookups behind them, all now open to being read, recorded or modified in transit. That is the payoff of the attack: not the ARP messages, which are only a handful of packets, but the entire conversation they redirect. For a responder, the ARP frames mark the start of the window and the redirected traffic tells you what was exposed while it lasted. Everything the victim sent in the clear during the window is to be treated as observed by the attacker; correctly validated TLS keeps payloads confidential, though the attacker still sees which sites the victim visited, the limit a man-in-the-middle runs into against HTTPS.

What a full man-in-the-middle requires, and what the capture carved

Claiming the gateway's address is only half of a complete man-in-the-middle. To relay traffic transparently, the attacker usually poisons in both directions, telling the victim it is the gateway and telling the gateway it is the victim, so that replies flow back through the attacker too, and enables IP forwarding so the victim's connectivity is not broken. If forwarding is off, the victim simply loses its connection, which turns a stealthy intercept into a denial of service and is itself a reason an unexplained outage on a segment is worth checking for ARP anomalies. This small capture shows the victim's side: the changed next hop and traffic that keeps flowing both ways through it, so the attacker was forwarding. The reverse-direction forgery and the steady re-poisoning cadence of a sustained attack appear in the arpspoof gateway capture.

Because the victim's web traffic here was plain HTTP, A-Packets did more than note the redirection: it carved the page and the search suggestions the victim loaded from Google out of the HTTP responses, which is why the report lists recovered files. That is a concrete illustration of the attacker's view from the middle, not just the list of sites the victim visited but the actual content of anything sent without TLS. The same position against an HTTPS session would have yielded only the server names, which is the boundary a man-in-the-middle hits against encryption and the reason universal TLS is the single most effective mitigation for the data, even though it does not stop the poisoning itself.

Detecting and preventing it

The signal to watch for is exactly what the ARP view surfaces: two MACs answering for one IP, or a single MAC claiming several addresses, or a host sending unsolicited replies for the gateway. In Wireshark, the filter arp.duplicate-address-detected flags conflicting mappings when the capture holds both advertisements, and sorting ARP traffic by sender MAC reveals a host answering for addresses it should not. Keep a baseline of the gateway's real MAC as well: as this capture shows, the change in data-frame next hops can be the clearest evidence. Continuous monitoring tools such as arpwatch alert on a changed IP-to-MAC binding in real time.

The durable prevention is on the network equipment. Dynamic ARP inspection on managed switches validates ARP packets against a trusted binding table and drops forged ones, which stops the attack at the switch port. Static ARP entries for critical gateways remove the ambiguity for the most important addresses, and segmenting the network limits how many hosts an attacker on any one segment can reach. When redirection is confirmed, find the switch port behind the claiming MAC in the forwarding table, disconnect the device, and scope the cleartext exchanges in the affected window. Check the gateway's failover and proxy-ARP configuration first, since both change ARP mappings legitimately, and remember that a vendor prefix names a manufacturer, not a device. In MITRE ATT&CK terms this is T1557.002, Adversary-in-the-Middle by ARP cache poisoning.

This is the small, clear cousin of the arpspoof gateway attack, which shows the same technique run with a tool against a busy, real browsing session; for detecting it step by step, see the ARP spoofing walkthrough. To analyze a capture from your own segment, upload a PCAP.