Merge pull request #2157 from HackTricks-wiki/update_When_Wi-Fi_Encryption_Fails__Protecting_Your_Enter_20260422_132454

When Wi-Fi Encryption Fails Protecting Your Enterprise from ...

Author: carlospolop

src/generic-methodologies-and-resources/pentesting-wifi/README.md

@@ -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
@@ -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}}
-