Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -591,6 +591,67 @@ You could also do this attack using `eaphammer`:
--user-list users.txt
```

### Enterprise client isolation bypasses (AirSnitch primitives)

Recent research showed that **WPA2/WPA3-Enterprise + client isolation is not a reliable MitM boundary**. The weak point is not only over-the-air decryption, but the interaction between **WPA keying**, **AP forwarding**, **switch MAC learning**, and **routing**. This lets an attacker recover **packet injection** or even **full bidirectional MitM** without using classic ARP poisoning first.

#### What to verify during an assessment

- Whether isolation is only enforced at **Layer 2** (`ap_isolate=1` / private VLAN style) but not at **Layer 3**
- Whether **inter-BSSID isolation** is missing between different radios/SSIDs of the same AP or across APs sharing the same wired distribution network
- Whether guest/open/PSK SSIDs can still influence enterprise WPA2/3-Enterprise clients through shared switching or routing
- Whether the environment leaks or reuses **group keys** in ways that permit client-side frame forgery

#### 1. Gateway Bouncing

This is the Wi-Fi version of a routed private-VLAN bypass: send a frame with the **victim IP as L3 destination** but the **gateway MAC as L2 destination**. The AP forwards it because the frame is addressed to the router, and the router then routes it back toward the victim.

- This bypasses **L2-only isolation**
- It is especially relevant when `hostapd` style `ap_isolate=1` is enabled and defenders assume that alone blocks client-to-client delivery
- The real question is whether the gateway/firewall will route **wireless-client-to-wireless-client** traffic back into the same WLAN

#### 2. Port Stealing

By **spoofing the victim MAC** toward another BSSID/AP, the attacker poisons the infrastructure MAC-learning state so switches/APs associate the victim MAC with the attacker-controlled path. Traffic for the victim is then redirected and encrypted to the attacker's **PTK** instead of the victim's.

- This works **below ARP**, so it impacts any higher-layer cleartext protocol carried over Wi-Fi
- Spoofing the **gateway MAC** can also hijack uplink traffic
- In weak enterprise deployments, cross-BSSID port stealing can expose the first **RADIUS/UDP** authentication packet from the AP side and enable offline attacks against the **RADIUS shared secret**

#### 3. GTK Misuse for Direct Injection

The WPA four-way handshake also distributes the **GTK** for downstream multicast/broadcast. If a malicious enterprise client can extract that GTK (for example by modifying `wpa_supplicant`), it can craft **broadcast/multicast 802.11 frames that encapsulate unicast IP payloads** for a victim.

- The victim accepts the frame because it is valid under the BSSID group key
- This restores **direct packet injection** even when the attacker cannot decrypt the victim's PTK traffic
- Some "per-client GTK" hardening is incomplete because standard flows such as **group key**, **FT**, **FILS**, and **WNM-Sleep** may still expose the real group key, and **IGTK** handling can also be abused

#### 4. Broadcast Reflection

If the attacker does **not** know the target BSSID GTK, it can still send a frame that looks like **broadcast at L2** while carrying a **unicast IP payload** for the victim. The AP re-encrypts and rebroadcasts it using the target BSSID GTK, effectively giving the attacker **cross-BSSID injection**.

#### Chaining

The high-value path is to combine primitives:

- **Port stealing** for downlink interception
- **GTK misuse** or **broadcast reflection** for injection back to the victim
- Follow-on attacks such as **DNS/DHCP poisoning**, **ARP cache poisoning**, traffic analysis, or enterprise credential theft once MitM is stable

#### Detection / hardening notes

- Watch for unexpected **MAC-to-port/BSSID mapping** changes in APs or wired switches
- Alert on **broadcast/multicast Wi-Fi frames carrying unicast IP payloads**
- Separate guest and enterprise SSIDs with **real VLAN/firewall isolation**, not only AP-local isolation flags
- Enable **MAC/IP spoofing prevention** where the vendor supports it
- Prefer **per-client randomized GTK** and **DGAF** controls where available
- If feasible, use **MACsec (802.1AE)** between infrastructure nodes/endpoints so interception of bounced or stolen frames does not yield readable payloads

For the generic routed-isolation version of this idea, also see:
{{#ref}}
../pentesting-network/README.md
{{#endref}}

## Client attacks Theory

### Network Selection and Roaming
Expand Down Expand Up @@ -950,9 +1011,10 @@ For persistence, leave the commissioning AP enabled.
- [3GPP TS 33.402 – 3GPP system architecture evolution (SAE); Security aspects of non-3GPP accesses](https://www.3gpp.org/ftp/Specs/archive/33_series/33.402/)
- [Wireless-(in)Fidelity: Pentesting Wi-Fi in 2025 (Synacktiv)](https://www.synacktiv.com/en/publications/wireless-infidelity-pentesting-wi-fi-in-2025.html)
- [PEAP relay attacks with wpa_sycophant (SensePost)](https://sensepost.com/blog/2019/peap-relay-attacks-with-wpa_sycophant/)
- [When Wi-Fi Encryption Fails: Protecting Your Enterprise from AirSnitch Attacks](https://unit42.paloaltonetworks.com/air-snitch-enterprise-wireless-attacks/)
- [AirSnitch: Demystifying and Breaking Client Isolation in Wi-Fi Networks](https://www.ndss-symposium.org/ndss-paper/airsnitch-demystifying-and-breaking-client-isolation-in-wi-fi-networks/)


TODO: Take a look to [https://github.com/wifiphisher/wifiphisher](https://github.com/wifiphisher/wifiphisher) (login con facebook e imitacionde WPA en captive portals)

{{#include ../../banners/hacktricks-training.md}}