Wireshark ARP Spoofing Detection: Identify MitM Attacks (2026)

ARP spoofing detection in Wireshark is your frontline defense against Man-in-the-Middle (MitM) attacks on your local network.

Here’s how to spot it in the wild:

eth.addr == ff:ff:ff:ff:ff:ff

This filter shows you broadcast ARP requests, the initial stage where a device asks "Who has IP address X? Tell IP address Y." Now, let’s look for the anomaly.

arp.duplicate-address-detected

This is the smoking gun. When a machine on the network receives an ARP reply that claims an IP address is already assigned to a different MAC address, it flags it as a duplicate address detection. This is precisely what an attacker does: they send out ARP replies that say, "Hey, I’m IP address X, and my MAC address is attacker_MAC." All other machines on the network will then update their ARP tables to point to the attacker’s MAC address for that IP.

The core of the problem is that ARP (Address Resolution Protocol) is stateless and trusts blindly. It’s designed for speed, not security. When a device on your network needs to send data to an IP address, it sends an ARP request asking for the MAC address associated with that IP. The device with that IP address is supposed to reply with its MAC address. An attacker intercepts this, or proactively sends out ARP replies, to insert themselves between the sender and receiver.

Let’s imagine a simple network: your computer (IP 192.168.1.100, MAC AA:BB:CC:DD:EE:FF) wants to send data to the gateway (IP 192.168.1.1, MAC 00:11:22:33:44:55).

Your computer broadcasts an ARP request: "Who has 192.168.1.1? Tell 192.168.1.100."
The gateway replies: "192.168.1.1 is at 00:11:22:33:44:55."
Your computer updates its ARP cache: 192.168.1.1 -> 00:11:22:33:44:55.

Now, if an attacker (IP 192.168.1.101, MAC 99:88:77:66:55:44) wants to intercept traffic to the gateway:

The attacker sends an ARP reply to your computer: "192.168.1.1 is at 99:88:77:66:55:44." (This is a spoofed reply, as the gateway’s MAC is actually 00:11:22:33:44:55).
Your computer receives this, and because it’s an ARP reply, it trusts it and updates its ARP cache: 192.168.1.1 -> 99:88:77:66:55:44.
Now, when your computer sends traffic destined for the gateway, it’s sent to the attacker’s MAC address. The attacker then forwards it to the actual gateway (acting as a proxy) and intercepts all data in between.

To detect this with Wireshark, you’re looking for ARP packets that don’t make sense in the context of your network’s known MAC addresses.

Common Causes and Detection/Fixes:

Malicious ARP Spoofer: An attacker is actively running ARP spoofing software.
- Diagnosis: In Wireshark, filter for arp.duplicate-address-detected. You will see packets where a device claims an IP address is already taken by a different MAC. You might also see arp.opcode == 2 (ARP Reply) packets where the sender’s IP is a legitimate IP on your network (e.g., your gateway), but the sender’s MAC address is not the legitimate MAC for that IP.
- Example: You see an ARP reply for 192.168.1.1 (your gateway’s IP) but the sender MAC is 99:88:77:66:55:44 (an unknown MAC).
- Fix: Identify the source MAC address (99:88:77:66:55:44 in the example) and the IP it’s claiming (192.168.1.1). Locate the device with that MAC address on your network and disconnect it immediately. If it’s a managed switch, you can often disable the port associated with that MAC.
- Why it works: This directly removes the source of the malicious ARP packets from the network.
Misconfigured Network Device: A legitimate device on the network has a faulty configuration or is running experimental software that causes it to send out incorrect ARP information.
- Diagnosis: Similar to Cause 1, look for arp.duplicate-address-detected or unexpected ARP replies. The difference is that the "attacker’s" MAC address might belong to a device that should be on the network but is behaving incorrectly. You might also see a pattern of these errors emanating from a specific device.
- Example: Your network printer (IP 192.168.1.200, MAC 11:22:33:AA:BB:CC) starts sending ARP replies claiming 192.168.1.1 is at 11:22:33:AA:BB:CC.
- Fix: Identify the device sending the incorrect ARP information. Reboot the device. Check its network configuration for any static ARP entries or unusual settings. Update its firmware if available.
- Why it works: A reboot can clear transient errors. Correcting configuration or firmware issues ensures the device adheres to proper ARP protocols.
Network Loop or Broadcast Storm: While not directly ARP spoofing, severe network loops can sometimes flood the network with traffic, including malformed or repeated ARP packets, which might trigger duplicate address detection warnings.
- Diagnosis: You’ll see an overwhelming number of ARP packets, often with the same source and destination IPs/MACs, and potentially other broadcast traffic. The arp.duplicate-address-detected flag might appear, but the sheer volume of traffic is the primary indicator.
- Fix: Identify the source of the loop. This usually involves tracing back from a switch port showing high utilization or a device with multiple network connections that shouldn’t have them. Disconnect one of the conflicting links.
- Why it works: A network loop creates a broadcast storm, overwhelming devices and potentially leading to protocol errors. Breaking the loop restores normal network operation.
ARP Cache Poisoning with a Short TTL (Time-To-Live): Some ARP spoofing tools are designed to be less persistent. They send out ARP replies with a very short TTL, meaning your ARP cache entries expire quickly, and the attacker repeatedly refreshes them.
- Diagnosis: You might not see arp.duplicate-address-detected consistently, but you’ll see a very high rate of ARP replies from a specific MAC address for common IPs (like gateway, DNS server). You can filter for arp.opcode == 2 and sort by source MAC, then by time, to see this frequency.
- Example: You see hundreds of ARP replies per second for 192.168.1.1 originating from 99:88:77:66:55:44.
- Fix: Implement static ARP entries on critical machines (servers, workstations) for essential devices like the gateway. This prevents the OS from accepting dynamic, potentially spoofed, ARP updates for those IPs.
- Why it works: Static ARP entries override dynamic (spoofed) ones, ensuring your critical devices always point to the correct MAC address.
DHCP Server Issues: In rare cases, a misbehaving DHCP server might assign an IP address that is already in use, leading to ARP conflicts when both devices respond to ARP requests for that IP.
- Diagnosis: Look for multiple devices reporting the same IP address in your DHCP server logs or on the network. You might see ARP replies for the same IP from different MAC addresses. The arp.duplicate-address-detected flag would likely appear on multiple machines.
- Fix: Check your DHCP server configuration. Ensure it’s not configured to re-issue IPs that are statically assigned or already in use. Restart the DHCP server or investigate its logs for errors.
- Why it works: A correctly functioning DHCP server prevents IP address exhaustion and conflicts, which are the root cause of the ARP issues.
Wireshark Filter Misconfiguration: While not an attack, an overly broad filter or a misunderstanding of ARP packets can lead to false positives.
- Diagnosis: If you’re seeing arp.duplicate-address-detected but cannot correlate it with any suspicious traffic or device behavior, review your display filters. Ensure you’re looking at ARP packets (frame contains "ARP" or arp) and not just any broadcast traffic.
- Fix: Refine your Wireshark filters. For example, use arp.duplicate-address-detected to specifically target the relevant event.
- Why it works: Precise filters ensure you’re analyzing the correct network events, avoiding misinterpretation.

The next error you’ll likely encounter if you’ve successfully blocked an ARP spoofing attack is a deluge of "Destination Net Unreachable" ICMP messages if the attacker was also dropping packets, or simply a return to normal, predictable network traffic patterns.

More Deep Dives in Wireshark