ARP Spoofing (Man-in-the-Middle)

The scenario (Why you care)

Someone reports “the network feels weird.” HTTPS sessions occasionally reset, DNS answers look inconsistent, a laptop can reach the internet but internal services intermittently fail, or a security team sees suspicious lateral movement. On a flat Ethernet segment, one of the fastest ways to disrupt or intercept traffic is to manipulate ARP (Address Resolution Protocol), because ARP is how hosts map an IPv4 address to a destination MAC address on the local link.

ARP spoofing (also called ARP poisoning) occurs when a device sends forged ARP messages so that other hosts learn an incorrect IP-to-MAC mapping. Often the attacker tries to become a man-in-the-middle by convincing victims that the gateway’s IP address belongs to the attacker’s MAC, and convincing the gateway that the victim’s IP address belongs to the attacker’s MAC. Once traffic is redirected through the attacker, they can sniff, modify, or selectively block packets. The challenge in packet analysis is separating a real attack from normal ARP churn (DHCP renewals, device moves, failovers, VM mobility).

What “good” looks like (Success pattern)

What you see

ARP requests (“Who has X? Tell Y”) are followed by a single matching ARP reply from the expected device. The mapping for key IPs (default gateway, DNS server, printers) is stable over time. If a mapping changes, it has an obvious operational cause like a gateway failover, an interface move, or a short burst during address reassignment.

Why it happens

ARP is local-link discovery. Hosts cache ARP results to avoid flooding the network. Occasional ARP broadcasts are normal: a host boots, the ARP cache expires, a new IP appears, or the gateway announces itself. In healthy networks, ARP traffic is relatively low volume and consistent with real device ownership.

Key clue

The gateway IP consistently resolves to the same MAC (or to a known HA pair), and ARP replies match the request pattern rather than appearing as unsolicited “corrections” from random devices.

What goes wrong (Failure pattern)

What you see

Multiple different MAC addresses claim ownership of the same IPv4 address, especially the default gateway. You may see repeated ARP replies (often unsolicited) advertising “X is at AA:AA:AA...” followed quickly by “X is at BB:BB:BB...”. Endpoints flip-flop between mappings, and application traffic becomes unstable: connections reset, TLS sessions renegotiate, or traffic disappears when sent to the wrong MAC.

Likely causes

A malicious actor is poisoning ARP caches to intercept traffic, or a misconfigured device is incorrectly answering for an IP it does not own (duplicate IP, accidental proxy ARP behavior, virtualization bridge confusion). In some environments, HA gateways can legitimately move a virtual MAC during failover, but those changes should be infrequent and aligned with an outage or failover event.

Key clue

You see unsolicited ARP replies (gratuitous-style announcements) repeatedly changing the gateway IP’s MAC, and the changes correlate with broken or intercepted sessions on the same segment.

Signals & decision table

Use this table to decide whether you are looking at normal ARP behavior, a benign topology event, or a likely poisoning scenario. The fastest checks are: “Does one IP map to multiple MACs?” and “Are ARP replies happening without corresponding requests?”

How it looks in Wireshark

Display filter example:

arp

• Look at ARP opcode (request vs reply) and the sender/target IP/MAC pairs. The key is consistency: “Who claims to own the gateway IP?”
• In a local capture, compare Ethernet destination MAC of normal outbound traffic to the expected gateway MAC. If the Ethernet dst MAC suddenly changes while the IP destination remains remote, a redirection is likely.
• Watch for reply bursts without requests. Occasional gratuitous ARP can be normal, but repeated unsolicited updates for critical IPs are suspicious.

Quick read tip: Track one critical IP (usually the default gateway) and list every MAC that claims it during the incident window.

Fast triage checklist

1. Pick the key IP: start with the default gateway IP used by affected hosts on that segment.
2. Collect claimants: in the capture window, note every sender MAC that claims “gateway IP is at …”.
3. Classify the replies: are they mostly responses to requests, or unsolicited announcements?
4. Correlate with symptoms: do mapping flips align with resets, DNS anomalies, or traffic blackholes?
5. Decide branch: if one stable MAC (or known HA pair) = likely normal; multiple changing MACs = escalate as spoofing/duplicate IP.

Common pitfalls

Assuming any gratuitous ARP is malicious

Gratuitous ARP can be used for legitimate purposes: announcing an IP after DHCP assignment, updating caches after a MAC change, or supporting HA failover. The suspicious pattern is not “a gratuitous ARP exists,” but repeated unsolicited replies that continuously rewrite critical mappings (especially the gateway) without a corresponding operational event.

Ignoring VLAN / capture location

ARP is confined to a broadcast domain. If your capture is taken on a host, you only see ARP on that host’s segment. If you capture on a trunk or SPAN incorrectly, you may see partial traffic and draw wrong conclusions. When possible, confirm that all observed MACs are truly in the same L2 domain as the victim.

Confusing proxy ARP and duplicate IP with spoofing

Some devices legitimately answer ARP on behalf of others (proxy ARP), and duplicate IP configurations can create “two MACs for one IP” without an attacker. The practical way to separate them is correlation: if the mapping changes cause session interception or instability, treat it as high risk until proven benign. If mapping changes are rare and align with known device behavior, it may be an intended design.

Related pages (internal links)

• Back to Topics Index
• Dictionary: ARP overview
• Field: IPv4 TTL (Often used as a clue when paths or origins change — optional)
• Dictionary Index