<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Felix Voigt]]></title><description><![CDATA[Offensive Security Writeups & Research]]></description><link>https://felix-voigt.de</link><generator>RSS for Node</generator><lastBuildDate>Wed, 08 Apr 2026 11:03:06 GMT</lastBuildDate><atom:link href="https://felix-voigt.de/rss.xml" rel="self" type="application/rss+xml"/><language><![CDATA[en]]></language><ttl>60</ttl><item><title><![CDATA[Part 4: WPA2/3-Mixed Mode (Downgrade & Rogue Access Point)]]></title><description><![CDATA[1. Executive Summary
Although WPA3 effectively mitigates the offline dictionary attacks that troubled its predecessor, modern enterprise and home network infrastructures still rely on backward compati]]></description><link>https://felix-voigt.de/part-4-wpa2-3-mixed-mode-downgrade-rogue-access-point</link><guid isPermaLink="true">https://felix-voigt.de/part-4-wpa2-3-mixed-mode-downgrade-rogue-access-point</guid><category><![CDATA[redteaming]]></category><category><![CDATA[offensive-security]]></category><category><![CDATA[802.11]]></category><dc:creator><![CDATA[Felix Voigt]]></dc:creator><pubDate>Fri, 03 Apr 2026 21:24:31 GMT</pubDate><content:encoded><![CDATA[<h2>1. Executive Summary</h2>
<p>Although WPA3 effectively mitigates the offline dictionary attacks that troubled its predecessor, modern enterprise and home network infrastructures still rely on backward compatibility. To accommodate legacy hardware, most access points utilize the WPA2/WPA3-Mixed Mode (Transition Mode). This architectural compromise harbors a critical vulnerability. This technical write-up demonstrates how an attacker can exploit Transition Mode by deploying a targeted Rogue Access Point and coercing a modern, WPA3-capable client to actively downgrade its connection to the deprecated WPA2 protocol.</p>
<p><strong>Business Impact:</strong> By forcing the target infrastructure into downgrading the encryption standard, an attacker completely bypasses the cryptographic improvements of WPA3. The capture of the resulting WPA2 4-Way Handshake reactivates the viability of highly efficient offline dictionary attacks, exposing the network perimeter to total compromise without triggering WPA3 intrusion detection heuristics.</p>
<h2>2. Lab Architecture (RoE)</h2>
<ul>
<li><p><strong>Target (Authenticator)</strong>: TP-Link Archer C6 in WPA2/WPA3-Personal Transition Mode (1.14.30 Build 250729 Rel.74228n(4555))</p>
</li>
<li><p><strong>Target (Supplicant)</strong>: iPhone 13</p>
</li>
<li><p><strong>Attacker Infrastructure</strong>: Virtualbox Kali Linux 2025.4 (RTL8812AU)</p>
</li>
</ul>
<h2>3. Protocol Theory: The End of Offline Cracking</h2>
<p>To understand the necessity of the protocol downgrade attack, one must first analyze why the methods showcased in Part 3 of this series fail against pure WPA3. WPA3 completely replaces the vulnerable Pre-Shared Key (PSK) paradigm with a new authentication mechanism: Simultaneous Authentication of Equals (SAE).</p>
<h3>3.1 SAE and the Dragonfly Key Exchange</h3>
<p>Unlike the WPA2 4-Way Handshake, where the PSK is utilized to derive mathematically verifiable hashes transmitted over the air in EAPOL frames, SAE employs the Dragonfly Key Exchange. This mechanism acts as a Password-Authenticated Key Agreement (PAKA) based on zero-knowledge proofs.</p>
<ul>
<li><p><strong>Interactive Zero-Knowledge Proof:</strong> During the SAE commit and confirm phases, the supplicant and authenticator interactively negotiate a shared secret (the Pairwise Master Key, PMK) based on the passphrase. Crucially, the mathematical parameters transmitted over the air do not contain sufficient cryptographic material to reconstruct, hash, or verify the password offline.</p>
</li>
<li><p><strong>Forward Secrecy:</strong> SAE structurally guarantees forward secrecy. Because the session keys are generated dynamically and independently of the static passphrase, even if an attacker compromises the Wi-Fi password at a later date, they remain mathematically incapable of decrypting previously captured post-handshake traffic.</p>
</li>
<li><p><strong>Mitigation of Dictionary Attacks:</strong> Because capturing an SAE handshake for offline cracking is structurally impossible, an attacker is forced into executing an online brute-force attack directly against the Access Point. This is heavily mitigated by the AP's inherent rate-limiting and anti-clogging mechanisms.</p>
</li>
</ul>
<h3>3.2 Attacking Pure WPA3</h3>
<p>If a network architecture strictly enforces a "WPA3-Only" environment, the WPA2 framework is completely deprecated. By IEEE 802.11 standard mandates, a pure WPA3 network must enforce Protected Management Frames (PMF / 802.11w) as <em>Required</em>. Because Management Frames (such as Deauthentication packets) are cryptographically signed under strict PMF, the active frame injection techniques utilized in Part 3 are completely neutralized. The target client will securely drop forged Deauthentication frames because they lack the valid cryptographic signature of the Authenticator.</p>
<p>Faced with a pure WPA3 environment, the traditional Layer 2 attack surface is dead. A Red Teamer must pivot their operational vectors:</p>
<ul>
<li><p><strong>Layer 1 (Physical / RF):</strong> Utilizing specialized Wi-Fi transceivers to execute Channel Utilization Attacks (e.g., CTS-to-Self flooding) or localized RF jamming, forcing a hard denial of service.</p>
</li>
<li><p><strong>Layer 7 (Social Engineering):</strong> Deploying an Evil Twin combined with a Captive Portal, coercing the human operator into voluntarily surrendering the WPA3 passphrase under the guise of an MDM update.</p>
</li>
</ul>
<h2>4. The Exploitable Reality: Transition Mode</h2>
<p>The operational reality is that corporate and private environments cannot instantly deprecate functional legacy hardware (e.g., warehouse scanners, VoIP phones, older IoT devices) that lack the capability to process the SAE Dragonfly exchange. To solve this dilemma, vendors implemented the WPA2/WPA3 Transition Mode.</p>
<p>In this state, the Access Point broadcasts a single Beacon frame advertising support for both SAE (WPA3) and PSK (WPA2) concurrently. To enable legacy WPA2 devices to connect, the Access Point cannot mandate signed management frames globally; PMF must be set to <em>Optional</em>.</p>
<p>However, while WPA2-only clients remain vulnerable to standard Layer 2 Deauthentication attacks, WPA3-capable clients are protected. The 802.11 standard dictates that if a client connects via SAE, PMF must be negotiated and strictly enforced for <em>that specific session</em>. Consequently, the WPA3 client's kernel will identify unsigned deauthentication packets as spoofing attempts and silently drop them. To successfully disconnect a WPA3 client and trigger a roaming process in a Transition Mode network, an attacker must bypass Layer 2 entirely and pivot to Layer 1 (Physical) disruption tactics.</p>
<h2>5. Execution: The Downgrade Attack</h2>
<p>The objective is to physically disrupt the legitimate WPA3 connection and manipulate the client's internal roaming logic into voluntarily executing a WPA2 handshake against an attacker-controlled infrastructure.</p>
<h3>5.1 Confirming Transition Mode</h3>
<p>First, raw Beacon frames from the target Access Point are captured using a dedicated monitoring interface:</p>
<pre><code class="language-shell">sudo airodump-ng wlan0 --bssid 8C:90:2D:48:2C:9F -c 3 --beacons --write sae
</code></pre>
<img src="https://cdn.hashnode.com/uploads/covers/69b5d77c34db550e2ceee08d/94af7a4b-7ce6-4f6f-8944-964d54398565.png" alt="" style="display:block;margin:0 auto" />

<p><em>Note: While terminal interfaces like</em> <code>airodump-ng</code> <em>are excellent for real-time monitoring, they often summarize the</em> <code>AUTH</code> <em>column to display only the highest supported security protocol (e.g., displaying only</em> <code>SAE</code> <em>instead of</em> <code>SAE/PSK</code><em>). Relying solely on the CLI output can lead to false negatives regarding network vulnerability!</em></p>
<p>To ensure complete accuracy, the resulting <code>.cap</code> file should be analyzed to examine the Cipher Suite broadcasted in the Beacon frames:</p>
<img src="https://cdn.hashnode.com/uploads/covers/69b5d77c34db550e2ceee08d/5e7c8711-5a0e-4a14-9aa5-0fc798b94a74.png" alt="" style="display:block;margin:0 auto" />

<p><strong>Verification Criteria in Wireshark:</strong></p>
<ul>
<li><p><strong>Auth Key Management (AKM) List</strong>: The capture must reveal an AKM Suite Count of 2 or more, listing both <code>PSK (00:0f:ac:2)</code> and <code>SAE (00:0f:ac:8)</code>.</p>
</li>
<li><p><strong>RSN Capabilities</strong>: The hex value <code>0x0080</code> must be present, translating to Bit 7 (MFPC) enabled and Bit 6 (MFPR) disabled. This confirms PMF is Optional.</p>
</li>
</ul>
<h3>5.2 Rogue Access Point Deployment</h3>
<p>The attacker deploys a Rogue Access Point (Evil Twin) designed solely to broadcast a deceptive Beacon frame. To avoid RF interference with the legitimate AP on Channel 3, the Rogue AP is strategically placed on a non-overlapping channel (e.g., Channel 11).</p>
<p>The <code>hostapd-downgrade.conf</code> is explicitly restricted to WPA2-CCMP to force the downgrade:</p>
<pre><code class="language-plaintext">interface=wlp3s0mon
ssid=TP-Link-FV 
hw_mode=g 
channel=11 
macaddr_acl=0 
auth_algs=1 
wpa=2 
wpa_key_mgmt=WPA-PSK 
wpa_pairwise=CCMP 
rsn_pairwise=CCMP 
wpa_passphrase=password123
</code></pre>
<p>The Rogue AP is initialized in the terminal:</p>
<pre><code class="language-shell">sudo hostapd hostapd-downgrade.conf
</code></pre>
<p><em>Note: The</em> <code>wpa_passphrase</code> <em>defined in this configuration is deliberately arbitrary. The attacker does not need to know the true network password to capture the handshake. The goal is merely to coerce the client into initiating the authentication sequence and transmitting its cryptographic response (Message 2).</em></p>
<img src="https://cdn.hashnode.com/uploads/covers/69b5d77c34db550e2ceee08d/9cf8b766-50f7-4fd5-b225-94c6d63279e1.png" alt="" style="display:block;margin:0 auto" />

<p>Once the rogue AP is up (on a different device in this case), it can be discovered using <code>airodump-ng</code>, revealing the duplicated <code>TP-Link-FV</code> network providing the weaker WPA2 PSK security instead of the more secure WPA3 SAE of the legitimate Authenticator.</p>
<img src="https://cdn.hashnode.com/uploads/covers/69b5d77c34db550e2ceee08d/e0ab5a5e-e17d-4abd-aef2-3d1be5d9aff6.png" alt="" style="display:block;margin:0 auto" />

<h3>5.3 Active Disruption (Layer 1 Pivot)</h3>
<p>Since the WPA3 client strictly ignores spoofed Layer 2 Deauthentication frames, the attacker severs the connection at Layer 1. In a real-world scenario, this is achieved through targeted Radio Frequency (RF) jamming to saturate the legitimate AP's channel with noise. In a controlled laboratory environment, this disruption is simulated by temporarily disabling the legitimate Access Point's wireless transmission.</p>
<h3>5.4 Protocol Downgrade and Interception</h3>
<p>To capture the downgraded half handshake, a separate <code>airodump-ng</code> instance is launched, monitoring the Rogue AP's specific channel (Channel 11) and writing the output to a new <code>.cap</code> file:</p>
<pre><code class="language-shell">sudo airodump-ng wlan1 -c 11 --write downgrade_capture
</code></pre>
<p>Once the physical connection to the legitimate AP drops, the victim's operating system is governed entirely by its internal roaming algorithms. The attack successfully exploits three fundamental principles of client OS design:</p>
<ol>
<li><p><strong>SSID Trust (Preferred Network List)</strong>: The OS immediately transmits Probe Requests seeking trusted SSIDs. Because the Rogue AP broadcasts the exact target SSID (<code>TP-Link-FV</code>), it bypasses the user-consent barrier.</p>
</li>
<li><p><strong>SNR Prioritization (Availability)</strong>: Roaming algorithms maximize network availability. The client overwhelmingly prioritizes the Rogue AP on the clean channel over the jammed/dead legitimate channel due to its superior Signal-to-Noise Ratio (SNR).</p>
</li>
<li><p><strong>Connectivity over Security</strong>: Although fully WPA3-capable, the OS detects only WPA2 capabilities on the Rogue AP. Programmed to ensure the user remains connected, the algorithm gracefully falls back to the older supported standard.</p>
</li>
</ol>
<img src="https://cdn.hashnode.com/uploads/covers/69b5d77c34db550e2ceee08d/add76830-72ad-40f4-9cdc-4d67534c9b25.png" alt="" style="display:block;margin:0 auto" />

<p>Satisfying these roaming criteria, the client silently accepts the security downgrade and initiates the legacy 4-Way Handshake against the attacker's infrastructure:</p>
<ul>
<li><p><strong>Message 1 (Attacker to Victim)</strong>: The Rogue AP transmits its ANonce.</p>
</li>
<li><p><strong>Message 2 (Victim to Attacker)</strong>: The victim calculates the Pairwise Transient Key (PTK) using the <em>true</em>, locally stored Wi-Fi password. It transmits Message 2, containing its SNonce and the critical Message Integrity Code (MIC).</p>
</li>
</ul>
<p>The monitoring interface successfully intercepts this exchange. Because Message 2 contains a MIC derived from the real network password, the attacker immediately gracefully shuts down the Rogue AP and transitions to an offline Hashcat dictionary attack to crack the intercepted MIC, utilizing the exact methodology documented in Part 3. The WPA3 architecture has been successfully circumvented.</p>
<p>Note: The success of this roaming coercion heavily depends on the absence or circumvention of the WPA3 'Transition Disable Indication' (TDI). Modern OS implementations (like iOS 14+) cache the security capabilities of a network. If TDI is enforced by the legitimate AP, the target device may pin the WPA3 requirement for this SSID and outright refuse the silent downgrade to WPA2.</p>
<h2>6. Remediation / Blue Team</h2>
<p>Mitigating downgrade attacks requires strict architectural enforcement and the deliberate removal of backward compatibility where possible. The vulnerability stems not from WPA3 cryptography, but from the operational compromises made to accommodate legacy hardware.</p>
<h3><strong>6.1 Deactivating Transition Mode</strong></h3>
<p>The definitive remediation is the complete deactivation of WPA2/WPA3-Mixed Mode. Corporate networks must be configured exclusively as WPA3-SAE. This implicitly forces Management Frame Protection (PMF) to <em>Required</em>, cryptographically immunizing the network against localized Deauthentication and ensuring clients never negotiate downgraded sessions.</p>
<h3><strong>6.2 VLAN Segregation for Legacy Hardware</strong></h3>
<p>Organizations burdened with legacy hardware must embrace strict network segmentation. Devices incapable of SAE authentication should be physically and logically isolated into a dedicated IoT/Legacy VLAN. This network should broadcast a hidden SSID, utilize a separate, highly complex 20+ character WPA2 PSK, and be firewalled from the primary corporate infrastructure.</p>
<h3><strong>6.3 Client-Side Hardening</strong></h3>
<p>Network administrators managing corporate endpoints via Mobile Device Management (MDM) or Group Policy Objects (GPO) should configure wireless profiles to explicitly demand WPA3 for corporate SSIDs. By hardcoding the required security standard directly on the endpoint, the OS is actively prevented from accepting a downgraded WPA2 connection, even if lured by a Rogue AP presenting a stronger signal.</p>
]]></content:encoded></item><item><title><![CDATA[Part 3: WPA2 Deauth & 4-Way Handshake (Frame Injection & Offline Cracking)]]></title><description><![CDATA[1. Executive Summary
While the WPA2-Personal protocol ensures that the Pre-Shared Key (PSK) is never transmitted in plaintext, its architecture harbors a critical vulnerability: standard 802.11 Manage]]></description><link>https://felix-voigt.de/part-3-wpa2-deauth-4-way-handshake-frame-injection-offline-cracking</link><guid isPermaLink="true">https://felix-voigt.de/part-3-wpa2-deauth-4-way-handshake-frame-injection-offline-cracking</guid><category><![CDATA[redteaming]]></category><category><![CDATA[offensive-security]]></category><category><![CDATA[802.11]]></category><dc:creator><![CDATA[Felix Voigt]]></dc:creator><pubDate>Fri, 03 Apr 2026 21:22:54 GMT</pubDate><content:encoded><![CDATA[<h2>1. Executive Summary</h2>
<p>While the WPA2-Personal protocol ensures that the Pre-Shared Key (PSK) is never transmitted in plaintext, its architecture harbors a critical vulnerability: standard 802.11 Management Frames lack cryptographic authentication by default. This technical write-up demonstrates how an attacker can exploit this flaw by injecting forged Deauthentication frames to actively force a legitimate client into reconnecting with the router. By monitoring this forced reconnection, the attacker intercepts the 4-Way Handshake, capturing the plaintext nonces and the cryptographic Message Integrity Code (MIC).</p>
<p><strong>Business Impact</strong>: These intercepted cryptographic variables provide all the necessary parameters to execute a highly efficient offline dictionary attack against the PSK. A successful crack completely neutralizes the network's perimeter defense, granting the attacker unauthorized internal access and laying the groundwork for total infrastructure compromise.</p>
<h2>2. Lab Architecture (RoE)</h2>
<ul>
<li><p><strong>Target (Authenticator)</strong>: TP-Link Archer C6 (1.14.30 Build 250729 Rel.74228n(4555))</p>
</li>
<li><p><strong>Target</strong> <strong>(Supplicant)</strong>: iPhone 13</p>
</li>
<li><p><strong>Attacker Infrastructure</strong>: Virtualbox Kali Linux 2025.4 (RTL8812AU)</p>
</li>
</ul>
<h2>3. Protocol Theory</h2>
<h3>3.1 Pairwise Master Key (PMK)</h3>
<p>Rather than sending the network password over the air, the plaintext password and SSID are used to calculate the Pairwise Master Key (PMK) locally on both the authenticator and supplicant. The aim of this function is to transform a short, human-readable password and network name into a strong, pseudo-random cryptographic key thereby slowing down cryptographic attacks (key stretching). As it is derived from the SSID and password, the PMK itself is not used to encrypt data but rather during the 4-Way Handshakes to calculate the Pairwise Transient Key (PTK), which is then used as a session key to encrypt the data.</p>
<p>$$PMK = PBKDF2(HMAC-SHA1,Passphrase,SSID,4096,256)$$</p>
<ul>
<li><p><strong>PBKDF2</strong> (Password-Based Key Derivation Function 2): The standardized procedure (RFC 2898) employs key stretching by repeatedly performing calculation steps to derive the result.</p>
</li>
<li><p><strong>HMAC-SHA1</strong> (Pseudorandom Function): The mathematical core function used within PBKDF2. HMAC (Hash-based Message Authentication Code) hashes the password and SSID.</p>
</li>
<li><p><strong>Passphrase</strong>: Network password used by the client to authenticate on the network.</p>
</li>
<li><p><strong>SSID</strong>: Name of the network (SSID, Service Set Identifier) is used as salt to prevent the use of rainbow tables.</p>
</li>
<li><p><strong>4096</strong>: Iterations of the HMAC-SHA1-Function, effectively multiplying the expense for calculating the hash per password by 4096.</p>
</li>
<li><p><strong>256</strong>: Key length of 256 Bit the function will return.</p>
</li>
</ul>
<h3>3.2 Pairwise Transient Key (PTK)</h3>
<p>To ensure that the session key for each connection (client to access point) is unique, the Pairwise Transient Key (PTK) is calculated using cryptographic random numbers (Nonces) and the hardware addresses (MACs) with the help of a pseudorandom function (PRF):</p>
<p>$$PTK = PRF(PMK,Authenticator_MAC,Supplicant_MAC,ANonce,SNonce)$$</p>
<ul>
<li><p><strong>PMK</strong>: Proves that both parties know the password without sending it over the air and it is the only parameter that cannot be intercepted in plain text.</p>
</li>
<li><p><strong>Authenticator/Supplicant MAC</strong>: Physical hardware address of the access point and client, binding the cryptographic key to these specific devices (spatial separation), ensuring that different clients on the same network cannot decrypt each other's traffic.</p>
</li>
<li><p><strong>ANonce/SNonce</strong>: Cryptographic random numbers generated by both parties, guaranteeing 'freshness' for every new handshake, ensuring the PTK is unique per session, effectively preventing Replay Attacks</p>
</li>
</ul>
<p>While the Temporal Key (TK) derived from the PTK is responsible for encrypting post-handshake data traffic, a critical sub-key is extracted specifically for the authentication phase: the Key Confirmation Key (KCK). The KCK occupies the first 128 bits of the PTK and is exclusively used to calculate the Message Integrity Code (MIC).</p>
<h3>3.3 Message Integrity Code (MIC)</h3>
<p>The MIC acts as the cryptographic anchor of the 4-Way Handshake. It is appended to the Extensible Authentication Protocol over LAN (EAPOL) frames (starting in Message 2) to fulfill two fundamental security objectives in an untrusted medium like WLAN:</p>
<ol>
<li><p><strong>Data Integrity</strong>: It guarantees that the EAPOL frame (including the critical Nonces and MAC addresses) has not been tampered with during transit.</p>
</li>
<li><p><strong>Proof of Possession</strong>: It serves as a deterministic, zero-knowledge proof. By generating a valid MIC, the supplicant proves to the authenticator that it possesses the correct PMK (and thus the correct passphrase) without ever transmitting the secret over the air.</p>
</li>
</ol>
<p>The MIC is derived as follows:</p>
<p>$$MIC=HMAC(KCK,EAPOL_Frame_with_zeroed_MIC)$$</p>
<ul>
<li><p><strong>HMAC</strong>: The cryptographic algorithm used to generate the checksum.</p>
</li>
<li><p><strong>KCK</strong>: The 128-bit Key Confirmation Key derived directly from the PTK. Since the PTK is calculated using the PMK, the KCK mathematically proves knowledge of the correct network password.</p>
</li>
<li><p><strong>EAPOL_Frame_with_zeroed_MIC</strong>: To solve the logical paradox of hashing an EAPOL frame that must eventually contain the hash (MIC) itself, the protocol dictates a specific sequence. The sender temporarily fills the MIC field within the frame entirely with zeros (<code>0x00</code>) before running the HMAC calculation. The resulting cryptographic checksum is then inserted into the formerly zeroed field, and the frame is transmitted.</p>
</li>
</ul>
<h3>3.4 The Architectural Flaw</h3>
<p>The WPA2 protocol has a fundamental architectural flaw because, by default, only data frames are encrypted and authenticated using the TK derived from the PTK. Management frames, such as Beacons, Probe Requests, and Deauthentication Packets, are sent in plain text and without authentication.</p>
<p>Due to this flaw, any device with an appropriate Wi-Fi adapter and a spoofed MAC address can send Deauthentication Packets to clients, causing a brief disconnection between the client and access point. The client will accept the forged Deauthentication Packet, disconnect, and then reconnect to the same router within milliseconds.</p>
<p>This effectively triggers the 4-Way Handshake, allowing an attacker to intercept and capture legitimate nonces and the MIC. These can then be used to perform an offline brute-force attack on the password involved in deriving the PMK, PTK, KCK, and ultimately the MIC.</p>
<h2>4. The Attack (Execution &amp; OPSEC)</h2>
<p>The attack follows a structured sequence: reconnaissance of the target, locking onto it, injecting the Management Frame, capturing the handshake, and finally cracking the password offline.</p>
<h3>4.1 Interface Preparation (Monitor Mode)</h3>
<p>First, we must set our network adapter to monitor mode to capture all raw frames in the air. The default managed mode discards any packets that don't match the adapter's MAC address.</p>
<p>Ending processes that interfere with packet capture in monitor mode:</p>
<pre><code class="language-shell">sudo airmon-ng check kill
</code></pre>
<p>Activating monitor mode:</p>
<pre><code class="language-shell">sudo airmon-ng start wlan0
</code></pre>
<p>wlan0 is the name of the wireless interface. The interface names can be verified using 'iwconfig' and note that after starting airmon-ng, the mode changes to Mode:Monitor.</p>
<h3>4.2 Passive Reconnaissance</h3>
<p>With the interface in Monitor Mode, passive reconnaissance is conducted to survey the 2.4 GHz and 5 GHz spectrum. The objective is to identify the target's Basic Service Set Identifier (BSSID), its current operating channel, and the MAC address of the connected supplicant (the target client). This phase involves strictly passive listening and leaves no detectable footprint on the target network.</p>
<p>Initiate the scan on the monitoring interface:</p>
<pre><code class="language-shell">sudo airodump-ng wlan0
</code></pre>
<p>(During monitoring, your interface name might change to include 'mon', such as 'wlan0mon'.)</p>
<p>The tool hops through all WLAN channels capturing every raw packet in the air. The terminal splits into 2 logical sections:</p>
<img src="https://cdn.hashnode.com/uploads/covers/69b5d77c34db550e2ceee08d/d7e350fb-906c-4be5-9404-b3ede5e0aaa3.png" alt="" style="display:block;margin:0 auto" />

<p>The upper half (Router / Access Points):</p>
<ul>
<li><p><strong>BSSID</strong>: Routers' MAC addresses.</p>
</li>
<li><p><strong>ESSID</strong>: Network name.</p>
</li>
<li><p><strong>PWR</strong>: Signal strength, the closer to 0 the stronger the signal.</p>
</li>
<li><p><strong>Beacons</strong>: Amount of Management Frames sent by the routers.</p>
</li>
<li><p><strong>CH</strong>: Channel on which the network transmits.</p>
</li>
<li><p><strong>ENC/CIPHER/AUTH</strong>: Encryption.</p>
</li>
</ul>
<p>The lower half (Clients):</p>
<ul>
<li><p><strong>BSSID</strong>: Router to which the client is currently connected and sending packets to.</p>
</li>
<li><p><strong>STATION</strong>: Clients' MAC address.</p>
</li>
<li><p><strong>Frames</strong>: Traffic the client creates.</p>
</li>
</ul>
<h3>4.3 Traffic Interception</h3>
<p>In this view, target parameters are identified: the authenticator BSSID (8C:90:2D:48:2C:9F), its operating channel (5), and a supplicants BSSID (20:04:84:EF:C1:33) connected to our target router. Since this step is purely passive reconnaissance, repeatedly starting and stopping the monitoring does not generate any suspicious or forensically detectable traffic that would compromise OPSEC.<br /><strong>Disclaimer:</strong> The injection of forged 802.11 Management Frames effectively constitutes a localized Denial of Service (DoS) attack. All actions demonstrated in this execution phase were performed within a controlled laboratory environment against owned hardware.</p>
<p>Now that we identified the parameters of our target connection, we narrow our monitoring on this connection and write every captured data to file:</p>
<pre><code class="language-shell">sudo airodump-ng -c 5 --bssid 8C:90:2D:28:4C:9F -w wpa2_handshake wlan0
</code></pre>
<ul>
<li><p><code>-c</code>: Prevents channel hopping and forces the adapter to listen on channel 5.</p>
</li>
<li><p><code>--bssid</code>: Filtering out all connections that are sent or received by the specified router.</p>
</li>
<li><p><code>-w</code>: Writing out every captured packet to file that can later be analyzed in Wireshark.</p>
</li>
</ul>
<h3>4.4 Frame Injection</h3>
<p>With the passive listener securely capturing all traffic on channel 5, a second terminal is utilized to execute the active phase of the attack. Using <code>aireplay-ng</code>, forged Deauthentication Management Frames are injected into the network.</p>
<pre><code class="language-shell">sudo aireplay-ng -0 1 -a 8C:90:2D:48:2C:9F -c 20:04:84:EF:C1:33
wlan0
</code></pre>
<p><code>-0 1</code>: Sending 1 Deauthentication-Frame (code 0).</p>
<p><code>-a</code>: The routers MAC address being spoofed.</p>
<p><code>-c</code>: Our target supplicant (client) being deauthenticated.</p>
<p>Upon receiving the forged frames, the client drops the connection and immediately initiates a reconnection sequence. In the <code>airodump-ng</code> monitoring terminal, a successful capture is verified by the appearance of the <code>[ WPA handshake: &lt;BSSID&gt; ]</code> banner in the top-right corner. This notification confirms that the crucial EAPOL frames containing the plaintext nonces and the client's cryptographic MIC have been successfully intercepted and written to the <code>.cap</code> file.</p>
<img src="https://cdn.hashnode.com/uploads/covers/69b5d77c34db550e2ceee08d/139b875d-123c-47cc-934c-4d8236cb6c15.png" alt="" style="display:block;margin:0 auto" />

<p>From an OPSEC perspective, it is critical to inject the absolute minimum number of forged deauthentication packets required to trigger the handshake. Continuously flooding the network with deauthentication frames (a sustained DoS) causes severe user disruption and creates massive noise in Wireless Intrusion Prevention Systems (WIPS) or router logs, drastically increasing the likelihood of detection.</p>
<h2>5. Packet Analysis (Handshake Verification)</h2>
<p>Before initiating a resource-intensive offline dictionary attack, it is a mandatory operational procedure to cryptographically verify the integrity of the captured <code>.cap</code> file. Blindly attempting to crack a corrupted or incomplete handshake will inevitably lead to false-negative results.</p>
<p>Using a protocol analyzer such as Wireshark, the raw capture file is inspected to confirm that all necessary variables for the PTK and MIC calculation were successfully intercepted.</p>
<p>By applying the display filter <code>eapol</code>, the view is restricted to the Extensible Authentication Protocol over LAN frames—the core of the 4-Way Handshake. A valid, crackable capture must contain at least the first two messages of this sequence:</p>
<ol>
<li><p><strong>Message 1</strong> (Authenticator to Supplicant): This frame is analyzed to extract the ANonce transmitted in plaintext.</p>
</li>
<li><p><strong>Message 2</strong> (Supplicant to Authenticator): This is the most critical frame for the attacker. Inspection of this frame must confirm the presence of the SNonce and, crucially, a populated MIC field.</p>
</li>
</ol>
<img src="https://cdn.hashnode.com/uploads/covers/69b5d77c34db550e2ceee08d/f85e236a-948d-42c0-8044-646d19ae3e04.png" alt="M1 Authenticator nonce" style="display:block;margin:0 auto" />

<img src="https://cdn.hashnode.com/uploads/covers/69b5d77c34db550e2ceee08d/49d648a3-30c1-4bc9-a4f0-dae856b31b27.png" alt="M2 SNonce + Client MIC" style="display:block;margin:0 auto" />

<p>If the packet analysis confirms that both MAC addresses, both nonces (highlighted), and the client-generated MIC (image 2; WPA Key MIC: 0ba9f7...) are present and uncorrupted, the mathematical equation is complete. Only the Pre-Shared Key remains the unknown variable, authorizing the transition to the offline cracking phase.</p>
<h2>6. Offline Cracking (Dictionary / Brute-Force)</h2>
<p>With the integrity of the captured 4-Way Handshake verified, the operation transitions from network interaction to offline cryptographic cracking. This process completely decouples the attacker from the target network, eliminating any further risk of detection.</p>
<h3>6.1 Hash Extraction and Processing</h3>
<p>Modern GPU-accelerated password recovery tools, such as Hashcat, do not parse raw packet capture files efficiently. The <code>.cap</code> file must first be distilled into a standardized cryptographic format that isolates the necessary variables. Using <code>hcxpcapngtool</code>, the raw capture is parsed to extract the Authenticator MAC, Supplicant MAC, both Nonces, and the intercepted MIC into the <code>hc22000</code> hash format.</p>
<pre><code class="language-shell">hcxpcapngtool wpa2_handshake-01.cap -o target_hash.hc22000
</code></pre>
<h3>6.2 Execution of the Dictionary Attack</h3>
<p>The extracted <code>hc22000</code> file is supplied to Hashcat alongside a predefined wordlist (e.g., <code>rockyou.txt</code>) and / or a custom ruleset. Operating in mode 22000, Hashcat's cracking engine systematically iterates through the wordlist, performing the exact cryptographic cascade defined by the WPA2 standard for every single password candidate:</p>
<ol>
<li><p><strong>PMK Derivation</strong>: It computes the Pairwise Master Key using PBKDF2-HMAC-SHA1, hashing the password candidate and the network SSID through 4096 iterations.</p>
</li>
<li><p><strong>PTK Expansion</strong>: Utilizing the intercepted MAC addresses and Nonces, it expands the PMK into the Pairwise Transient Key via the Pseudo-Random Function (PRF).</p>
</li>
<li><p><strong>KCK Extraction</strong>: It isolates the first 128 bits of the PTK to obtain the Key Confirmation Key (KCK).</p>
</li>
<li><p><strong>MIC Calculation and Verification</strong>: Finally, Hashcat calculates a theoretical MIC using the derived KCK and the payload of the intercepted EAPOL Message 2.</p>
</li>
</ol>
<p>If the calculated MIC matches the intercepted MIC, the mathematical equation is solved. Hashcat halts the process and outputs the plaintext passphrase, granting the attacker full cryptographic access to the target network.</p>
<pre><code class="language-shell">hashcat -m 22000 target_hash.hc22000 rockyou.txt
</code></pre>
<h3>6.3 Note on Advanced Cracking Methodologies (Out of Scope)</h3>
<p>The specific intricacies of advanced password cracking—such as generating targeted wordlists, applying rule-based mutations (e.g., Best64), utilizing mask attacks, or optimizing GPU workloads—are beyond the scope of this write-up. Hashcat is a highly complex, standalone cryptographic engine. The methodology behind effective brute-forcing and dictionary attacks warrants its own dedicated analysis and may be covered in a future article. The focus of this execution was strictly the interception and verification of the WPA2 4-Way Handshake.</p>
<h3>6.4 Post-Exploitation Implications (Looking Ahead)</h3>
<p>It is crucial to understand that recovering the WPA2 Pre-Shared Key is rarely the attacker's final objective; rather, it serves as the initial foothold. Once the plaintext password is cracked, the attacker can authenticate to the target Access Point, transitioning from an external observer to an internal network participant.</p>
<p>From this privileged position, the typical next phase in a kill chain involves internal network reconnaissance (e.g., utilizing <code>nmap</code> to identify the default gateway and live hosts). The immediate subsequent target is often the router's administrative web interface. While the specific execution of HTTP/HTTPS brute-forcing or dictionary attacks against the router's login panel (using tools like Hydra or Burp Suite) is beyond the scope of this document, it highlights a critical reality: a compromised Wi-Fi passphrase rapidly paves the way for total infrastructure takeover.</p>
<h2>7. Remediation / Blue Team</h2>
<p>Securing a wireless network requires a defense-in-depth approach. Based on the mechanics of the WPA2 offline dictionary attack demonstrated in this article, the following remediation strategies are recommended to mitigate the risk of unauthorized access.</p>
<h3>7.1 Enforce Passphrase Complexity</h3>
<p>The fundamental weakness exploited in this attack is not the WPA2 cryptography itself, but rather weak user-generated passwords alongside the architectural flaw of unsigned Management Frames. Because Hashcat performs the cracking process entirely offline, traditional account lockout policies or rate-limiting mechanisms do not apply.</p>
<ul>
<li><strong>Recommendation</strong>: Implement a highly complex, pseudo-random Pre-Shared Key (PSK) of at least 16 to 20 characters. A robust passphrase is the simplest mitigation measure, making brute-force and dictionary attacks mathematically improbable within a human lifetime, thus rendering the captured .cap file practically useless.</li>
</ul>
<h3>7.2 Protocol Upgrades: WPA3 and PMF</h3>
<p>To address the architectural flaws of WPA2, the network infrastructure should be upgraded to modern standards wherever hardware permits.</p>
<ul>
<li><p><strong>Enable Protected Management Frames</strong> (PMF / 802.11w): Enforcing PMF ensures that deauthentication and management frames are cryptographically signed. This completely neutralizes the active frame injection attack used to force the 4-Way Handshake.</p>
</li>
<li><p><strong>Migrate to WPA3</strong>: Upgrading to WPA3 replaces the vulnerable PSK exchange with the Simultaneous Authentication of Equals (SAE) handshake. SAE is inherently resistant to offline dictionary attacks; even if an attacker captures the WPA3 handshake, they cannot brute-force the password offline.</p>
</li>
</ul>
<h3>7.3 Defense in Depth: Firmware and Configuration Hygiene</h3>
<p>While not directly preventing deauthentication attacks, overall router hygiene is critical to prevent post-exploitation lateral movement.</p>
<ul>
<li><p><strong>Firmware Updates</strong>: Regularly patch the Access Point's firmware. Once an attacker is on the network, outdated routers are prime targets for known CVEs to gain administrative control.</p>
</li>
<li><p><strong>Disable WPS</strong> (Wi-Fi Protected Setup): As discussed in Part 1 of this series, WPS is a legacy feature known to be highly susceptible to pin-brute-forcing (e.g., Pixie Dust attacks). It should be strictly disabled on the router's administrative panel to close another prominent WPA2 attack vector.</p>
</li>
</ul>
<h2>8. Troubleshooting</h2>
<p>Note on VirtualBox Infrastructure: When passing through high-power USB 3.0 Wi-Fi adapters (like the RTL8812AU), the hypervisor's USB state machine may occasionally stall. Toggling the device off and on via the VirtualBox 'Devices -&gt; USB' menu forcefully reinitializes the connection and allows the Linux kernel to properly probe the interface.<br />Also make sure to enable USB-3.0-Controller (xHCI) in the VirtualBox settings and add a filter for the adapter.</p>
<p>I used and installed the realtek-rtl88xxau-dkms driver with</p>
<pre><code class="language-shell">sudo apt install realtek-rtl88xxau-dkms
</code></pre>
]]></content:encoded></item><item><title><![CDATA[Part 2: WPA2 PMKID 
(Silent & Clientless Attacks)]]></title><description><![CDATA[1. Executive Summary
The PMKID attack represents a significant paradigm shift in 802.11 wireless network exploitation. This vector exploits a historical implementation flaw in the IEEE 802.11i Robust ]]></description><link>https://felix-voigt.de/part-2-wpa2-pmkid-silent-clientless-attacks</link><guid isPermaLink="true">https://felix-voigt.de/part-2-wpa2-pmkid-silent-clientless-attacks</guid><category><![CDATA[redteaming]]></category><category><![CDATA[offensive-security]]></category><category><![CDATA[802.11]]></category><dc:creator><![CDATA[Felix Voigt]]></dc:creator><pubDate>Fri, 03 Apr 2026 21:19:03 GMT</pubDate><content:encoded><![CDATA[<h2>1. Executive Summary</h2>
<p>The PMKID attack represents a significant paradigm shift in 802.11 wireless network exploitation. This vector exploits a historical implementation flaw in the IEEE 802.11i Robust Security Network (RSN) standard. By targeting the Access Point's proactive key caching mechanisms, an attacker can extract the Pairwise Master Key Identifier (PMKID) directly and entirely clientless.</p>
<p>This technical write-up details the cryptographic anatomy of the PMKID, dispels common industry myths regarding its origin, and demonstrates a surgically targeted extraction utilizing kernel-level Berkeley Packet Filters (BPF). Crucially, this execution serves as a practical reality check for modern Red Teaming: empirical packet analysis confirms that contemporary vendor firmware has successfully patched this proactive caching behavior. The report highlights how offensive methodologies must adapt to proactive defense-in-depth measures, pivoting from patched vulnerabilities to active frame injection strategies (as covered in Part 3 of this series) to achieve infrastructure compromise.</p>
<h2>2. Lab Architecture (RoE)</h2>
<ul>
<li><p><strong>Target (Authenticator)</strong>: TP-Link Archer C6 (1.14.30 Build 250729 Rel.74228n(4555))</p>
</li>
<li><p><strong>Attacker</strong> <strong>Infrastructure</strong>: Virtualbox Kali Linux 2025.4 (RTL8812AU)</p>
</li>
</ul>
<h2>3. Protocol Theory (PMKID Anatomy)</h2>
<p>As will be demonstrated in Part 3 of this series, traditional WPA2-PSK attacks need an active client to capture a complete 4-Way Handshake. This clientless PMKID attack eliminates that necessity by taking advantage of built-in key caching mechanisms. To grasp this more discreet attack vector, it's essential to analyze the mechanics of the Pairwise Master Key Identifier (PMKID) to dispel common misconceptions about it.</p>
<h3><strong>3.1 The Reassociation Optimization (802.11i RSN)</strong></h3>
<p>A persistent myth in the cybersecurity community attributes the PMKID vulnerability to the IEEE 802.11r standard (Fast BSS Transition / Roaming). However, protocol analysis reveals that the mechanism exploited here is actually rooted in the foundational IEEE 802.11i-2004 standard, which defines the Robust Security Network (RSN) for WPA2.</p>
<p>When a client first authenticates to an Access Point (AP), they derive a Pairwise Master Key (PMK). To optimize future connections and avoid recalculating this resource-intensive key every time the client temporarily drops off and reconnects to the <em>same</em> AP, the 802.11i standard introduced PMK Caching. The AP assigns this cached PMK a unique identifier: the PMKID.</p>
<h3><strong>3.2 Cryptographic Anatomy of the PMKID</strong></h3>
<p>The PMKID is a cryptographic hash calculated using the HMAC-SHA1 algorithm, binding the PMK to the specific MAC addresses of the entities involved. The formula is defined as:</p>
<p>$$PMKID = HMAC-SHA1-128(PMK, \text{"PMK Name"} \parallel MAC_{AP} \parallel MAC_{STA})$$</p>
<ul>
<li><p><strong>PMK</strong>: The Pairwise Master Key derived from the SSID and Wi-Fi password via PBKDF2.</p>
</li>
<li><p><strong>"PMK Name"</strong>: A static, hardcoded ASCII string.</p>
</li>
<li><p><strong>MAC AP/STA</strong>: MAC address of the access point and connecting client (Station).</p>
</li>
</ul>
<p><em>(Note: True 802.11r networks utilize a different key hierarchy involving PMK-R0/PMK-R1 and calculate the PMKID differently. The attack described here targets the base RSN PMKID).</em></p>
<h3>3.3 The Vulnerability</h3>
<p>In 2018, Jens Steube (the lead developer of Hashcat) discovered a critical flaw in how modern routers implement the 802.11i standard. Many modern access points proactively append the RSN PMKID to the robust security network element within M1 of the 4-Way Handshake.</p>
<p>For an attacker, this means there's no need to wait for a legitimate client or deauthenticate anyone. An attacker can pose as a rogue client, initiate an association request to the AP, and compel the AP to send Message 1. This packet contains the PMKID, the AP's MAC, and the station's MAC.</p>
<p>Because the MAC addresses and the string "PMK Name" are known in plain text, the only unknown variable is the PMK. By extracting the PMKID, an attacker can immediately transition to an offline dictionary attack to reverse-engineer the PMK and the underlying Pre-Shared Key.</p>
<h2>4. The Attack (Execution &amp; OPSEC)</h2>
<p>Unlike traditional Deauthentication attacks through frame injection that rely on passive observation of a forced reconnection, the PMKID attack is an active, clientless exploitation of the roaming protocol. The attacker acts as a rogue supplicant, actively requesting the target Access Point to surrender the PMKID within the first message of the 4-Way Handshake.</p>
<p>To achieve the necessary precision and manipulate raw 802.11 frames, the highly specialized frame injection and capture engine <code>hcxdumptool</code> (v7.0.0) is used.</p>
<h3>4.1 Interface Preparation and OPSEC</h3>
<p>Terminating all interfering processes for monitoring:</p>
<pre><code class="language-shell">sudo airmon-ng check kill
</code></pre>
<p><strong>Note on OPSEC</strong>: In the PMKID attack, active interaction with the router occurs. The AP logs the MAC address of the device requesting the association. To ensure operational security and avoid forensic attribution, spoofing the interface's MAC address is essential before starting the attack.</p>
<p><code>macchanger</code> can be used to change the interface's MAC address after bringing it down temporarily. After the MAC has been changed, the interface mode is set to monitor:</p>
<pre><code class="language-shell">sudo ip link set wlan0 down
sudo macchanger -r wlan0 # -r = assigning random MAC
sudo ip link set wlan0 up

sudo airmon-ng start wlan0
</code></pre>
<p><em>(Note: Enabling monitor mode with airmon-ng might append a '-mon' to the interface's name. Wireless interfaces, states and names can be checked with 'ip a' and 'iwconfig'.)</em></p>
<h3>4.2 Target Isolation (RoE)</h3>
<p><code>hcxdumptool</code> is extremely aggressive by default. If executed without parameters, it will indiscriminately request PMKIDs from every Access Point within physical reach, severely violating Rules of Engagement and creating unnecessary noise across the 2.4 GHz and 5 GHz spectrum.</p>
<p>To execute a surgically targeted attack, a filter list containing only the authorized target must be created by writing the target MAC to a Berkeley Packet Filter (BPF) file:</p>
<pre><code class="language-shell">hcxdumptool --bpfc="wlan addr3 8C:90:2D:48:2C:9F" &gt; target.bpf
</code></pre>
<h3>4.3 Execution: Extracting the PMKID</h3>
<p>With the BPF filter compiled and the target isolated, <code>hcxdumptool</code> is launched. To ensure precision, the interface is locked to the target's operating channel (Channel 5 on the 2.4 GHz band, denoted as <code>5a</code>), and the real-time display (<code>--rds=1</code>) is enabled to monitor incoming Extensible Authentication Protocol over LAN (EAPOL) frames.</p>
<pre><code class="language-shell">sudo hcxdumptool -i wlan0 -w pmkid_capture.pcapng -c 5a --bpf=target.bpf --rds=1
</code></pre>
<p>The tool transmits Association Requests to the target AP, attempting to coerce it into responding with Message 1 of the 4-Way Handshake.</p>
<h3>4.4 Target Resilience &amp; The Reality of this Attack</h3>
<p>During the execution, the captured frames are logged by the real-time display. However, the expected <code>P</code> flag (indicating a successfully extracted PMKID) never appears. Instead, the console outputs indicators like <code>|ep+++ |</code>, signifying that encrypted, pre-shared key EAPOL messages (M1, M2, M3) are being intercepted, but the PMKID itself is missing.</p>
<p>This is not a tool failure, but a demonstration of proactive defense-in-depth. Following the public disclosure of the PMKID vulnerability in 2018, vendor firmware was widely updated. The target device (TP-Link Archer C6, Build 250729) correctly suppresses the proactive transmission of the RSN Information Element in Message 1 unless 802.11r (Fast Roaming) is explicitly configured. In practice, active Access Points are very rarely susceptible to this PMKID since the flawed implementation of the 802.11i-2004 standard was widely patched with firmware updates.</p>
<h2>5. Packet Analysis</h2>
<p>To mathematically confirm the AP's resilience, the <code>.pcapng</code> file is analyzed in Wireshark utilizing the <code>eapol</code> display filter.</p>
<img src="https://cdn.hashnode.com/uploads/covers/69b5d77c34db550e2ceee08d/033cedb2-e4dc-4fb4-86d4-2c5b7881c517.png" alt="" style="display:block;margin:0 auto" />

<p>A look into a captured M1 frame reveals that the <code>WPA KEY DATA LENGTH</code> reads <code>0</code>. This serves as empirical proof that the AP does not cache and transmit the PMKID in standard RSN environments.</p>
<h2>6. Offline Cracking</h2>
<p>The offline cracking methodology for a successfully extracted PMKID is fundamentally identical to the process utilized for a full 4-Way Handshake (MIC) captured via a deauthentication attack. Modern password recovery engines, specifically Hashcat, leverage the unified <code>hc22000</code> hash format to parse both types of cryptographic material seamlessly.</p>
<p>Whether the input is a 16-byte PMKID hash or a complete EAPOL exchange containing a valid Message Integrity Code, the underlying mathematical objective remains the same: systematically deriving the Pairwise Master Key (PMK) from a dictionary of password candidates and comparing the cryptographic output against the intercepted values.</p>
<p>Because the target Access Point in this execution was patched and no valid PMKID could be extracted, the practical demonstration of hash extraction (using <code>hcxpcapngtool</code>) and dictionary attack execution is omitted in this chapter. For a simple cracking-aproach using a dictionary attack via hashcat, refer to Section 6 in Part 3 of this series.</p>
<h2>7. Remediation / Blue Team</h2>
<p>Defending against the clientless PMKID attack requires addressing both the specific protocol implementation flaw (proactive caching) and the underlying cryptographic vulnerability (weak passphrases). The following remediation strategies are recommended to secure WPA2-Personal networks against this vector.</p>
<h3>7.1 Firmware Patch Management</h3>
<p>The primary defense against this specific attack vector is maintaining up-to-date firmware on all network infrastructure. As demonstrated in the execution phase, the vulnerability stems from a specific historical implementation of the 802.11i standard. Modern firmware updates (released post-2018) actively prevent the Authenticator from transmitting the RSN Information Element containing the PMKID in EAPOL Message 1 by default.</p>
<h3>7.2 Disabling Fast BSS Transition (802.11r)</h3>
<p>If the network topology consists of a single Access Point, or if seamless roaming is not a strict operational requirement, the IEEE 802.11r (Fast BSS Transition) feature should be explicitly disabled in the router's administrative interface. When active, 802.11r mandates the transmission of PMKIDs to facilitate fast roaming, effectively re-opening this attack surface even on patched devices.</p>
<h3>7.3 Enforcing Passphrase Complexity</h3>
<p>If an Access Point cannot be patched due to legacy constraints and a PMKID is successfully extracted, the network's security relies entirely on the mathematical entropy of the Pre-Shared Key. Because the attack is executed offline, traditional account lockout and rate-limiting defenses are bypassed entirely. A highly complex, pseudo-random passphrase (minimum 16 to 20 characters) must be enforced to render dictionary and brute-force attacks computationally unfeasible within a practical timeframe.</p>
<h3>7.4 Protocol Migration (WPA3)</h3>
<p>Where hardware permits, migrating the infrastructure to the WPA3 standard provides the ultimate mitigation. WPA3 replaces the WPA2 4-Way Handshake and the PMK derivation process with the Simultaneous Authentication of Equals (SAE) protocol. SAE is inherently resistant to offline dictionary attacks; even if an attacker successfully captures the initial handshake frames, the offline recovery of the password is cryptographically prevented.</p>
]]></content:encoded></item><item><title><![CDATA[Part 1: Pin-based Attacks on 802.11 (Legacy & WPS)]]></title><description><![CDATA[1. Executive Summary
It must be stated upfront that in contemporary red teaming engagements, Wi-Fi Protected Setup (WPS) is largely considered a dead attack vector. The Wi-Fi Alliance has deprecated P]]></description><link>https://felix-voigt.de/part-1-pin-based-attacks-on-802-11-legacy-wps</link><guid isPermaLink="true">https://felix-voigt.de/part-1-pin-based-attacks-on-802-11-legacy-wps</guid><category><![CDATA[redteaming]]></category><category><![CDATA[offensive-security]]></category><category><![CDATA[802.11]]></category><dc:creator><![CDATA[Felix Voigt]]></dc:creator><pubDate>Fri, 03 Apr 2026 21:03:47 GMT</pubDate><content:encoded><![CDATA[<h2>1. Executive Summary</h2>
<p>It must be stated upfront that in contemporary red teaming engagements, Wi-Fi Protected Setup (WPS) is largely considered a dead attack vector. The Wi-Fi Alliance has deprecated PIN-based WPS, and the vast majority of modern hardware is heavily patched against these historical vulnerabilities. Therefore, this article serves primarily as a foundational study of legacy protocol architecture, cryptographic degradation, and the evolution of wireless perimeter defense.</p>
<p>WPS was originally designed to simplify network onboarding, but its PIN-based authentication mechanism introduced a critical cryptographic vulnerability. While traditional WPA2-Personal networks require intercepting a handshake to brute-force a complex passphrase over time, attacking WPS allows an adversary to completely bypass the WPA2 encryption standard. This technical write-up explores the architectural design flaw of the WPS PIN specification and demonstrates the "Pixie Dust" attack (CVE-2015-2204)—a legacy method that exploits weak Pseudorandom Number Generators (PRNG) in specific hardware chipsets to recover the PIN, and subsequently the plaintext network password, through an offline attack requiring only a single packet exchange.</p>
<p><strong>Business Impact</strong>: As an attack vector, WPS is practically obsolete in modern corporate environments. However, on the rare occasion that legacy or misconfigured hardware is encountered, a successful WPS compromise is instantly fatal. It yields the plaintext WPA2 Pre-Shared Key (PSK) regardless of its length or complexity, completely neutralizing the network's perimeter defense and granting unauthorized internal access without triggering prolonged brute-force alarms.</p>
<h2>2. Lab Architecture (RoE)</h2>
<ul>
<li><p><strong>Target</strong>: TP-Link Archer C6 (1.14.30 Build 250729 Rel.74228n(4555))</p>
</li>
<li><p><strong>Attacker</strong> <strong>Infrastructure</strong>: Virtualbox Kali Linux 2025.4 (RTL8812AU).</p>
</li>
</ul>
<h2>3. Protocol Theory</h2>
<h3>3.1 The WPS PIN Architecture</h3>
<p>The WPS PIN is an 8-digit numerical sequence designed to authorize new clients without requiring the complex WPA2 passphrase. However, the protocol does not evaluate the entire 8-digit PIN as a single cryptographic entity. Instead, the authentication sequence divides the PIN into two separate halves:</p>
<ol>
<li><p><strong>First Half</strong>: The first 4 digits are verified (10⁴ = 10,000 possible combinations).</p>
</li>
<li><p><strong>Second Half</strong>: The next 3 digits are verified (10³ = 1,000 possible combinations).</p>
</li>
<li><p><strong>Checksum</strong>: The final 8th digit is a predictable checksum.</p>
</li>
</ol>
<p>Consequently, the cryptographic entropy is drastically reduced from 100 million potential combinations to a maximum of merely 11,000 guesses. This fundamental design flaw enables reliable online brute-force attacks to theoretically recover any PIN within hours.</p>
<h3>3.2 The Pixie Dust Vulnerability (CVE-2015-2204)</h3>
<p>To mitigate online brute-forcing, modern routers implement strict lockout mechanisms after a set number of consecutive failed attempts. The "Pixie Dust" attack circumvents this mitigation entirely by transitioning the attack from an active online state to an offline cryptographic crack.</p>
<p>During a standard WPS transaction, the Access Point (AP) and the client exchange cryptographic random numbers (Nonces), specifically <code>E-S1</code> and <code>E-S2</code>. The vulnerability lies in the hardware's Pseudorandom Number Generator (PRNG). In specific chipsets (such as those manufactured by Ralink, Realtek, and Broadcom), the seed used to generate these nonces is either static, predictable, or lacks sufficient entropy.</p>
<h3>3.3 The Offline Attack Vector</h3>
<p>By initiating a single WPS exchange, the attacker forces the AP to transmit the nonces in the clear. Because the PRNG is predictable, the attacker can extract these values from the captured packets (specifically from the M3 message in the EAP-WSC transaction) and proactively terminate the connection before triggering any AP lockout mechanisms.</p>
<p>Using the intercepted nonces, the attacker computationally reverse-engineers the PRNG seed locally on their own hardware. Once the seed is known, the mathematical sequence that derived the WPS PIN can be replicated offline. After calculating the correct PIN locally in a matter of seconds, the attacker simply reconnects to the AP, supplies the valid PIN, and the AP natively responds by transmitting the plaintext WPA2 Pre-Shared Key.</p>
<h2>4. The Attack (Execution &amp; OPSEC)</h2>
<p>Unlike standard Deauthentication attacks that generate significant noise, the Pixie Dust execution is surgical, relying on brief reconnaissance and a single, aborted connection attempt.</p>
<h3>4.1 Passive Reconnaissance (Target Verification)</h3>
<p>With the interface in Monitor Mode, passive reconnaissance is conducted utilizing <code>wash</code>. <code>wash</code> is a utility specifically designed to parse 802.11 Beacon frames and identify Access Points broadcasting WPS capabilities. The objective is to verify the target's BSSID, its chipset vendor, and most importantly, confirm that the AP is not currently in a WPS locked state.</p>
<p>Initiate the WPS-specific scan on the monitoring interface:</p>
<pre><code class="language-shell">sudo wash -i wlan0
</code></pre>
<img src="https://cdn.hashnode.com/uploads/covers/69b5d77c34db550e2ceee08d/d885284a-c1cf-478e-b937-48a7e565901b.png" alt="" style="display:block;margin:0 auto" />

<p>The terminal output provides critical intelligence:</p>
<ul>
<li><p><strong>Lck (Lockout)</strong>: The value <code>No</code> indicates the router is actively accepting WPS requests and has not triggered a brute-force defense mechanism.</p>
</li>
<li><p><strong>Vendor</strong>: Identifying the chipset as <code>RalinkTe</code> confirms the high probability of a vulnerable PRNG implementation, authorizing the progression to the active Pixie Dust attack phase.</p>
</li>
</ul>
<h3>4.2 Active Execution &amp; Extraction</h3>
<p>With the target verified and seemingly vulnerable (<code>Lck: No</code>), the active phase of the Pixie Dust attack is initiated using <code>reaver</code>. While <code>reaver</code> was originally designed for prolonged online brute-forcing, the addition of the <code>-K 1</code> parameter fundamentally alters its behavior. It instructs the tool to initiate a single WPS transaction, capture the Nonces (E-Hash1, E-Hash2, E-S1, E-S2), immediately drop the connection, and pass the captured variables to <code>pixiewps</code> for local offline cracking.</p>
<pre><code class="language-shell">sudo reaver -i wlan0 -b 8C:90:2D:48:2C:9F -c 3 -Kvv
</code></pre>
<ul>
<li><p><code>-i wlan0</code>: Specifies the monitor mode interface.</p>
</li>
<li><p><code>-b</code>: The BSSID (MAC address) of the target router.</p>
</li>
<li><p><code>-c 3</code>: Locks the interface to the target's specific channel to prevent packet loss from channel hopping.</p>
</li>
<li><p><code>-K</code>: Triggers the Pixie Dust offline attack routine.</p>
</li>
<li><p><code>-vv</code>: Enables very verbose output to monitor the exact EAP-WSC message exchange.</p>
</li>
</ul>
<h3>4.3 The Reality of Modern Mitigation (Blue Team Win)</h3>
<p>In a vulnerable environment, this command would yield the plaintext WPS PIN within seconds. However, the execution against this specific hardware revision of the TP-Link Archer C6 resulted in a critical cryptographic failure:</p>
<img src="https://cdn.hashnode.com/uploads/covers/69b5d77c34db550e2ceee08d/958f6aff-9290-4acb-87c1-b915c7aa6b06.png" alt="" style="display:block;margin:0 auto" />

<h3><strong>4.4 Forensic Analysis of the Failure</strong></h3>
<p>The terminal output perfectly illustrates modern firmware patching in action. The transaction begins normally: <code>reaver</code> sends a standard dummy PIN, and the router responds with the <code>M1</code> message. <code>reaver</code> replies with the <code>M2</code> message and waits for the router to transmit the <code>M3</code> message.</p>
<p>The M3 message is the holy grail of this attack, as it contains the critical nonces generated by the AP's random number generator. However, the router intentionally drops the transaction (<code>code: 0x03</code>) and never transmits M3.</p>
<p><strong>Conclusion:</strong> Although the router utilizes a Ralink chipset and explicitly advertises WPS as active and unlocked, the manufacturer has silently patched the PRNG vulnerability (CVE-2015-2204) at the firmware level. The cryptographic state machine aborts the handshake before the sensitive seed variables can be extracted.</p>
<h2>5. Remediation &amp; Defense</h2>
<p>This execution proves that relying purely on chipset identification (<code>wash</code> output) is insufficient; firmware-level mitigations play a crucial role in modern perimeter defense.</p>
<p>However, despite the failure of the offline Pixie Dust attack, the router remains inherently vulnerable due to its architectural configuration:</p>
<ul>
<li><p><strong>The Residual Risk</strong>: As indicated by <code>Lck: No</code>, the router still allows WPS PIN attempts. While offline cracking was mitigated, the AP could theoretically still fall victim to a classic online brute-force attack (testing all 11,000 combinations) if the attacker manages to bypass or slow-roll the lockout mechanisms.</p>
</li>
<li><p><strong>The Ultimate Fix</strong>: The only definitive remediation for the WPS architectural flaw is to access the router's administrative interface and completely disable the Wi-Fi Protected Setup feature.</p>
</li>
</ul>
<h2>6. Looking Ahead: Moving up the Protocol Stack</h2>
<p>With legacy protocols like WPS effectively mitigated by modern firmware patches, an adversary must pivot their methodology. Instead of attacking the onboarding features, the focus must shift to the core cryptography of the 802.11 standard itself.</p>
<p>In Part 2 and Part 3 of this series, we will abandon WPS and explore how attackers target the WPA2 protocol directly—either silently through PMKID extraction or aggressively via forged Management Frames and the 4-Way Handshake.</p>
]]></content:encoded></item></channel></rss>