arpspoof against a gateway: a forged reply every two seconds

For 50 seconds near the end of this nine-minute arpspoof PCAP, the MAC 08:00:27:2d:f8:5a sends the victim 192.168.1.104 a forged ARP reply every two seconds, 26 in all, each claiming that the gateway 192.168.1.1 lives at its address. Meanwhile the victim's Firefox keeps browsing Reddit and its advertisers over TLS. The arpspoof utility exists to do exactly this: repeat forged replies for the gateway so that a victim's traffic is relayed through the attacker. A-Packets reads the ARP and the browsing from the 16,285-packet capture, so you can see the mechanism and its limits side by side.

Where the minimal ARP poisoning sample shows the technique in a handful of packets, this one shows a tool holding the position: the cadence that keeps the forged mapping alive, the legitimate gateway competing with it, and how little of a TLS session a man-in-the-middle actually gets.

How the arpspoof tool holds the man-in-the-middle

The ARP view shows the gateway address answered by the attacker's MAC, and the detail that marks this as a tool rather than a one-off is the repetition. A-Packets counts the forged replies, and they arrive at a steady cadence, roughly one every two seconds, during the roughly 50-second poisoning burst near the end of the capture.

Open the ARP view →

The repetition is necessary, and understanding why explains the pattern. ARP caches expire, and the real gateway is still on the network answering legitimately, so a forged mapping that is not refreshed is soon replaced by the true one. arpspoof therefore keeps reasserting its mapping on a short timer, re-poisoning the victim's cache before it can recover. That steady, unsolicited stream of ARP replies for the gateway, from a MAC that is not the gateway's, is the signature of an active tool holding a man-in-the-middle position, and it is far more visible than a single poisoning event.

The MAC addresses in this capture carry their own tell. All three hosts in the exchange share the 08:00:27 prefix registered to PCS Systemtechnik, the range VirtualBox assigns to its virtual network cards, which is how lab demonstrations like this one are usually built. In a real incident the attacker's vendor prefix would be whatever hardware they used, but the same analysis applies: a MAC answering for the gateway that is not the gateway's registered MAC is the host to isolate.

Locating the poisoning burst inside nine minutes of traffic

The file contains 16,285 packets over 543.333 seconds, but the forged gateway replies occupy only a short interval. The real gateway mapping is 192.168.1.1 at 08:00:27:5e:01:7c. Another station, 08:00:27:2d:f8:5a, first appears with its own address, 192.168.1.105. Between frame 3564 at 482.328454 seconds and frame 10340 at 532.410591 seconds, that second MAC sends 26 ARP replies claiming the gateway address to 192.168.1.104, whose MAC is 08:00:27:b8:b7:58, with a median interval of 2.001098 seconds between them.

That gives three roles: the real gateway, the claimant and the target of the repeated replies. To count the forgery in Wireshark, filter on the claimed sender IP and the claimant's sender MAC together, then check the target address; a filter on the gateway IP alone mixes the legitimate replies into the count. The real gateway answers again in frame 13744, at 538.666412 seconds, six seconds after the last forged reply, the moment the victim's cache can recover.

So the exposure window is the poisoning burst and the seconds after it, not the whole file: the first eight minutes of browsing precede the first forged reply. For each HTTP or TLS session, check whether its start and end overlap that window before counting it as intercepted; a whole-file protocol count is context, not the exposure.

What a man-in-the-middle sees of an encrypted session

Because the victim is actively browsing, the capture is full of their traffic: 54 TLS sessions to Reddit, Mozilla and advertising networks, DNS lookups, and the ordinary churn of a real session. During the poisoning window that traffic is the attacker's to see, and this is where the attack meets its limit, which the capture illustrates precisely.

14 more sessions in the interactive report.

Open the SSL/TLS view →

The SSL/TLS view lists the server names the victim reached, because the TLS Client Hello carries the requested hostname in the clear, but it cannot show the contents of any session, because those are encrypted end to end. That is exactly what a man-in-the-middle sees of HTTPS: where the victim went, not what they sent. The browsing history is exposed, the destinations and the pattern of activity, while the actual data, the passwords typed, the pages read, the messages sent, stays sealed. HTTPS does not prevent the man-in-the-middle, but it strictly limits the damage of a successful one, which is why universal TLS matters even on networks where ARP poisoning is possible.

Relaying a busy browsing session also depends on the attacker's machine keeping up. If it drops packets or its forwarding stalls, the victim's connection degrades or fails, so a clumsy ARP-poisoning attack often shows up first as a performance complaint. For a defender, an unexplained slowdown on a segment, combined with any ARP anomaly, is worth treating as a possible active intercept rather than a routing problem, and the ARP view is the place to start.

The SNMP strings broadcast seven minutes before the attack

The capture holds another exposure that has nothing to do with the poisoning. Frames 72, 81, 82 and 84, between 28.13 and 29.88 seconds, are SNMP GetRequests sent to 255.255.255.255, version 2c, each carrying a community string in plain text. They come more than seven minutes before the first forged reply, and because they are broadcast they reach every host in the segment anyway, attacker or not. A-Packets lists them in the Credentials view, one from each of the two hosts.

SNMP versions 1 and 2c authenticate with that community string alone, so a captured one is a credential to whatever agents accept it. These are GetRequests with no SetRequest among them, so the capture shows read access being used, which already discloses inventory and configuration; a read-write community would be worse. Rotate the exposed values and move the devices to SNMPv3 with authentication and privacy: changing the string alone leaves the next one just as readable. The lesson for an exposure review is to cover broadcast management traffic as well as the unicast traffic a man-in-the-middle redirects, each with its own time window.

Defences, and why they are the same at any scale

The defences are identical to those for any ARP poisoning, and this capture shows why they matter at scale: a single spoofer held a busy browsing session in its path. Enable dynamic ARP inspection on managed switches so forged replies are dropped at the port; pin static ARP entries for gateways to remove the ambiguity for the most critical address; and alert on a MAC that begins answering for an address it did not previously hold, which is precisely the repeated-reply pattern the ARP view makes visible. Monitoring tools like arpwatch catch the changed binding in real time.

When you find this in a real capture, treat the claiming host as hostile, scope the victim's exposure by the cleartext traffic that passed through during the window, and remember that TLS destinations were still visible even where contents were not. In MITRE ATT&CK terms this is T1557.002, Adversary-in-the-Middle by ARP cache poisoning, and the exposed browsing maps to collection techniques depending on what the attacker chose to record.

Compare the minimal ARP poisoning sample for the mechanism in isolation, and see the ARP spoofing walkthrough for step-by-step detection. For reading the TLS metadata a capture like this exposes, see how to analyze encrypted traffic in a PCAP, or upload a capture of your own.