ARP Spoofing

ARP spoofing, also called ARP cache poisoning, is a forty-year-old technique that refuses to die. An attacker sends forged Address Resolution Protocol messages binding their own MAC address to a legitimate IP address, and every device that accepts the forgery starts sending that IP’s traffic to the attacker instead. Nothing crashes, nothing alerts, and the user sees a network that works perfectly.

The standard response in network engineering circles is that this is a Layer 2 problem rather than a wireless one. That is technically defensible and practically misleading, and 2026 made it more so. Research presented at NDSS demonstrated that the wireless infrastructure itself can be manipulated below the layer ARP operates at, which means the preconditions for ARP spoofing are now far easier to meet than the standard threat model assumed. Tracked in MITRE ATT&CK as T1557.002.

This information is provided for general awareness and defense purposes only. It is not intended to be a complete description of the functionality or risks of the identified tools.

Quick Facts

• What it is: Forged ARP messages that bind an attacker’s MAC address to a legitimate IP, redirecting that IP’s traffic through the attacker.
• Why it cannot be patched: ARP is stateless and unauthenticated by design. Devices accept unsolicited replies. The primitive can only be constrained by surrounding infrastructure or observed after the fact.
• The precondition: presence on the same Layer 2 broadcast domain. Every argument about ARP spoofing is ultimately an argument about who can reach that domain.
• What changed in 2026: AirSnitch demonstrated client-isolation bypass across every device tested, making the wireless precondition much easier to satisfy.
• What TLS changed: the payoff per session, not the positioning primitive.
• MITRE ATT&CK: T1557.002, adjacent to DHCP spoofing at T1557.003 and evil twin at T1557.004.

How ARP Spoofing Works

ARP resolves IPv4 addresses to link-layer MAC addresses. When a device does not know the MAC address for a peer on its segment, it broadcasts a request and the owning device replies. The protocol is stateless and requires no authentication, so a device will add or update a cache entry based on an unsolicited or forged reply.

An attacker who replies faster than the legitimate owner, or who sends a gratuitous ARP announcing ownership of an IP to the whole segment, becomes the destination for traffic intended for that address. Because ARP replies are broadcast across the segment, the attacker does not need to elicit a response to poison multiple devices at once. Connectivity continues to work normally throughout, which is precisely why the technique has survived since RFC 826 in 1982.

Two structural facts follow, and they drive every question defenders ask about it: the attack requires presence on the same broadcast domain, and it cannot be removed from ARP itself.

Why Wireless Is a Distinct Conversation

“ARP spoofing isn’t a wireless issue, it’s a Layer 2 issue” has been the standard response since at least 2010, and three things about the wireless case make it incomplete.

• The Layer 2 domain has no physical perimeter. On a wired network, joining the broadcast domain means finding a port. On Wi-Fi it means being in RF range with valid credentials, or on a guest or BYOD network, with credentials worth very little.
• The control everyone recommends is not standardized. Client isolation, the single most-cited wireless mitigation, does not appear in the IEEE 802.11 specification. Every vendor implemented it independently, which means its behavior is a per-product question rather than a checkbox.
• The wireless infrastructure is now an attack surface below ARP. This is the material change since 2025, and most enterprise guidance has not caught up with it.

AirSnitch and the Three Primitives

Researchers from UC Riverside and KU Leuven presented AirSnitch at NDSS 2026, a family of attacks that defeat client isolation and restore adversary-in-the-middle capability against WPA2 and WPA3, Personal and Enterprise alike. Every one of the eleven devices they tested was vulnerable to at least one variant, including enterprise hardware from Cisco and LANCOM. Our full write-up is here: AirSnitch: a new class of Wi-Fi attacks.

Three primitives matter for anyone reasoning about ARP spoofing:

• Port stealing. Each BSSID functions as a virtualized switch port. By associating using a victim’s spoofed MAC on a different BSSID, an attacker causes the access point’s internal switch to redirect the victim’s traffic to the attacker’s port, where it is encrypted with the attacker’s session keys. This operates below ARP, between Layer 1 and Layer 2, which is why every unencrypted protocol carried over Wi-Fi is exposed once it succeeds.
• Gateway bouncing. The attacker sends a packet with the victim’s IP as the Layer 3 destination and the gateway’s MAC as the Layer 2 destination. The gateway routes it back to the victim, stepping around isolation that is enforced at Layer 2 but not at the IP layer.
• Broadcast reflection through the Group Temporal Key. Because the four-way handshake distributes a shared GTK to clients under the same BSSID, an attacker can wrap unicast traffic inside broadcast frames encrypted with that key and inject them directly to victims over the air, where the access point’s isolation cannot intervene.

The conclusion that belongs in any defensive treatment: once bidirectional adversary-in-the-middle is established, the attacker can then poison DNS, redirect via DHCP, or poison ARP caches to maintain long-term control of the victim’s traffic. ARP poisoning is no longer only the way in. It is also the persistence layer after a lower-level wireless compromise.

Two honest qualifiers, because early coverage overstated this. AirSnitch does not decrypt WPA2 or WPA3 keys the way historic WEP attacks did; it bypasses isolation and exploits low-level behavior to enable interception. And an attacker typically needs some level of network access already, even if that access is an open guest SSID. What it changes is not the power of ARP spoofing but how easily its preconditions are met.

What This Is Not: A Disambiguation

Five techniques get conflated constantly, and blurring them costs credibility with the network engineering audience immediately.

Technique	Layer	What the attacker controls	Needs network access?
ARP cache poisoning	L2/L3 binding	The IP-to-MAC mapping in victim caches	Yes, must be on the segment
MAC spoofing	L2 identity	Its own frame source address	Sometimes
Port stealing (wireless)	L1/L2 forwarding	The AP or switch MAC-to-port table	Yes
Evil twin or KARMA	L1/L2 association	Which access point the victim joins	No
Rogue DHCP	L3 configuration	The victim’s gateway and DNS	Yes

The cleanest distinction: an evil twin is an association attack that decides which network a client joins, while ARP spoofing is a binding attack against clients that are already correctly associated.

Did TLS Kill This Attack?

The skeptical case deserves its strongest form: with near-universal HTTPS, HSTS preloading, encrypted DNS, and QUIC, an adversary-in-the-middle position on the LAN yields metadata rather than credentials. Practitioners in the offensive community broadly agree that against high-value internet-facing targets, this is now a situational tool rather than a default move.

Three counterarguments hold up:

• Internal traffic is not the public web. Management interfaces, printers, badge readers, building controls, legacy line-of-business applications, SMB and LDAP flows, and IoT telemetry are the residual plaintext, and they sit on the same wireless segment as the attacker. Google has estimated that between 6 and 20 percent of page loads still occur without HTTPS depending on platform.
• Interception is not the only goal. Selective denial of service, traffic-analysis positioning, and quiet reconnaissance of a segment are all achievable without breaking a single TLS session.
• It is a stepping stone. ARP spoofing rarely happens in isolation; it is a first move toward lateral movement, credential theft, or session hijacking. The 2013 Target breach used ARP spoofing to map the internal network and enable lateral movement after initial access through an HVAC vendor.

The framing that survives scrutiny is that TLS collapsed the payoff per session and did nothing to the positioning primitive.

Detection in Three Layers

No single layer is sufficient, and the useful part of any reference is stating what each layer cannot see.

Layer	What it sees	What it is blind to
Host and endpoint	ARP cache monitoring and IP-to-MAC change alerting through tools such as arpwatch, plus host-level validators	Anything that cannot run an agent, which is most of the IoT, OT, medical, and BYOD estate
Network and NDR	NIDS signatures and behavioral analysis, SIEM correlation, and PCAP forensics combining L2, L3, and L4 into one view	Client-to-client frames bridged inside an access point that never traverse a monitored wired link, and the pre-ARP wireless primitives entirely
RF and wireless airspace	Device identity, presence, association behavior, and physical location	The contents of encrypted frames, and therefore the ARP-layer verdict itself

The indicator list published alongside the AirSnitch research is notably infrastructure-state and RF-derived: unexpected changes in MAC-to-port mappings in the access point’s forwarding table, an attacker device using a spoofed MAC of a legitimate client or gateway, a high volume of multicast or broadcast frames carrying unexpected unicast payloads, and session key or GTK renegotiation outside normal intervals.

Additional airspace-observable indicators relevant to this kill chain: the same MAC associated to multiple BSSIDs or bands simultaneously, which is the direct signature of the port-stealing precondition; a known client MAC appearing at an RF location inconsistent with its history; new unmanaged 802.11 devices appearing in the space at all; deauthentication bursts preceding re-association elsewhere; and device-class anomalies such as an ESP32-class radio or a Wi-Fi Pineapple present where no such asset is inventoried.

Why ARP Alerts Are So Noisy

The objection here is legitimate. ARP traffic is inherently noisy, Layer 3 firewalls are blind to it, and filters such as arp.duplicate-address-detected produce false positives from ordinary network behavior. Published research on host-based and IDS-based approaches consistently reports false-positive rates high enough that detection only works where someone is staffed to triage the events.

The failure, though, is one of correlation rather than signal. Benign duplicate-IP events have a signature: they cluster around DHCP renewal, high-availability failover, VRRP and HSRP transitions, and virtualization live migration, and they are stable over time. Malicious ones look different:

• An IP-to-MAC binding that flips and then persists, rather than settling back.
• A single MAC acquiring bindings for multiple high-value IPs, especially the gateway.
• Unsolicited replies arriving with no matching request.
• A binding change for a device whose physical location, asset record, or wireless association does not support it.

Baselining removes most of the noise. The residual requires business context, which is why the useful question is rarely “is this ARP packet malformed” and usually “is this MAC a known asset, and is it where it should be?”

Controls and What Each One Misses

Control	Stops classic ARP poisoning	Stops wireless port stealing or GTK misuse	Friction
Client isolation	Partially, vendor-dependent	No; bypassed by gateway bouncing	Low, but breaks casting and shared printing
Per-SSID VLAN separation	Yes, within scope	Prevents port-stealing redirection from untrusted BSSIDs	Moderate; core network change
DHCP snooping with Dynamic ARP Inspection	Yes, on inspected paths	No	High in static-IP, non-DHCP, and OT environments
IP Source Guard	Partially	Helps against gateway bouncing	Same DHCP dependency as DAI
Preventing one MAC across multiple BSSIDs	Indirect	Directly prevents cross-BSSID port stealing	Low where supported
Per-client randomized GTK	No	Stops GTK misuse where the AP supports it	Depends on hardware
802.1X and NAC	No; admission is not binding integrity	No	Moderate
MACsec	Yes, cryptographically	Intercepted traffic cannot be read or altered; denial of service remains	High; limited platform coverage
Static ARP entries	Yes, for covered pairs	No	Unmanageable beyond critical hosts
RF and wireless intrusion detection	Detects, does not prevent	Detects device presence and location	Sensor deployment

Two deployment realities worth naming, because they are where practitioner frustration concentrates. Dynamic ARP Inspection depends on the DHCP snooping binding table, so statically addressed hosts have no record and require manually maintained ARP ACLs, which does not scale past a handful of subnets. And when applying DAI to wireless clients, use a DHCP lease time of at least 90 minutes, because devices in standby renew leases erratically.

A useful audit checklist from the AirSnitch guidance: are guest SSIDs strictly separated from enterprise SSIDs, does core firewall policy isolate guest Wi-Fi and block gateway bouncing, are weak RADIUS passphrases in use, are endpoint operating systems patched, is VPN used even for intranet access, and are any legacy or orphaned access points still physically uplinked to the core network despite being out of active management? That last one is the item most organizations fail.

Where This Remains Genuinely Dangerous

The “this is overhyped” objection is correct for a fully modern, fully encrypted, fully segmented office, and wrong nearly everywhere else. The environments that concentrate the risk:

• Flat networks, guest Wi-Fi, and BYOD, where weak segmentation lets one compromised or malicious device affect many others and the entry point can be an open SSID or a shared password.
• IoT, OT, ICS, and medical segments, which combine every aggravating factor: plaintext protocols, no endpoint agents, static addressing that breaks DAI, and long-lived unpatched firmware.
• Environments where the infrastructure is the weak asset. Recent industry analysis has network infrastructure overtaking endpoints as the highest-risk device category, which matters directly because the wireless primitives above target forwarding state in that infrastructure.
• Shared and multi-tenant space, including co-working, conference, campus, retail, and healthcare guest networks, where “authorized user” is a very low bar.
• Virtualized and containerized segments, where the same stateless-ARP problem reappears on the virtual bridge and containers can impersonate each other or the host.

Frequently Asked Questions

What is ARP spoofing?

ARP spoofing is the sending of forged ARP messages that bind an attacker’s MAC address to a legitimate IP address, causing traffic for that IP to be delivered to the attacker. ARP spoofing, ARP cache poisoning, and ARP poison routing all describe the same technique.

Does ARP spoofing work over Wi-Fi?

Yes, between clients on the same Layer 2 segment. Client isolation is the control intended to prevent it, and its effectiveness varies by vendor because it was never standardized in 802.11.

Does WPA3 prevent ARP spoofing?

No. WPA3 protects the over-the-air link. ARP operates above that, binding IP addresses to MAC addresses, and a client authenticated under WPA3 can still poison another client’s cache on the same segment.

Does client isolation stop it?

Partially and inconsistently. It is unstandardized, implementations differ, and in the AirSnitch testing every device examined was bypassable by at least one technique. Treat it as necessary, insufficient, and something to verify per vendor rather than assume from a checkbox.

If my guest SSID is isolated, can a guest attacker still reach corporate clients?

Under the AirSnitch techniques, yes in tested configurations. Researchers demonstrated interception of WPA2-Enterprise traffic from an open guest network where access points shared a wired distribution system, with the intercepted traffic leaking in plaintext through the guest network.

Does TLS make ARP spoofing harmless?

No. It reduces credential harvesting from web sessions and does nothing about positioning, denial of service, reconnaissance, DNS observation, or the internal plaintext protocols that remain common on enterprise segments.

What is port stealing on Wi-Fi?

Spoofing a victim’s MAC address toward a different BSSID so the access point’s internal forwarding table redirects the victim’s traffic to the attacker. It operates below ARP, which is why controls that validate ARP do not address it.

How do I detect ARP spoofing without drowning in false positives?

Baseline the benign causes of duplicate bindings, then alert on bindings that flip and persist, on a single MAC claiming several high-value IPs, and on unsolicited replies with no matching request. Correlate against asset inventory and device location rather than relying on packet filters alone.

Why does Dynamic ARP Inspection break in my environment?

Because it validates ARP against the DHCP snooping binding table. Statically addressed hosts have no entry, so their traffic is dropped unless you maintain ARP ACLs by hand, which becomes unworkable across many subnets and is a common blocker in OT environments.

Does 802.1X or NAC prevent it?

No. Those control admission to the network, not what an admitted device subsequently claims at Layer 2. An authenticated device can still poison caches.

Does a VPN protect me?

For tunneled traffic only. It does not cover pre-tunnel DNS, captive portal interaction, split-tunnel traffic, local segment discovery, or the unmanaged devices on the same SSID that will never run a VPN client.

Does IPv6 have the same problem?

Neighbor Discovery has analogous spoofing exposure, and ARP-specific controls do not transfer to it. Environments running dual stack need to evaluate NDP protections separately.

Can I tell where the attacking device physically is?

Not from packet analysis. Determining the physical position of the transmitting device requires RF localization, which is the specific gap that packet-layer detection cannot close.

How do I protect IoT and OT devices that cannot run an agent?

Not at the endpoint, in most cases. Segmentation, strict guest and BYOD separation, and network plus RF-layer monitoring are the practical controls, since the devices themselves cannot be instrumented and often cannot be patched.

How Bastille Fits, and Where It Does Not

Being precise about scope matters here more than usual, because this is a protocol attack rather than an RF one. Bastille does not detect ARP cache poisoning. That verdict lives in packet and host telemetry, and any wireless vendor claiming otherwise should be asked how.

What Bastille contributes is the layer where packet analysis is structurally blind: the identity, presence, association behavior, and physical location of the wireless devices that make the attack possible. Monitoring is 100% passive across 100 MHz to 7.125 GHz using software-defined radios.

The defensible claim is narrow and worth stating as such: RF monitoring closes the attribution and localization gap, and it does not replace packet-layer detection or the Layer 2 controls above. Where an attacker is a legitimately credentialed laptop already sitting in a conference room, RF monitoring contributes location and device attribution rather than an ARP-layer verdict.

For the wireless research behind the current threat picture, see our write-up of the AirSnitch client isolation bypass and related coverage of rogue access points. See a demo to understand what is operating in your airspace today.