hostapd-wpe: Rogue Enterprise AP Testing

Enterprise WiFi Authentication

Most home and small business WiFi networks use WPA2-Personal (also called WPA2-PSK), where every device shares the same password. Enterprise WiFi - WPA2-Enterprise or WPA3-Enterprise - takes a fundamentally different approach. Each user authenticates individually with their own credentials, typically a username and password verified against a RADIUS server.

You'll find enterprise WiFi in corporations, universities, hospitals, and government buildings. The network name at your office that requires your work login? That's enterprise WiFi. The "eduroam" network at universities worldwide? Enterprise WiFi.

Enterprise authentication is more secure than a shared password in several ways: individual credentials can be revoked, access can be tied to specific user accounts for auditing, and the compromise of one user's password doesn't expose the network key for everyone. But it introduces a different attack surface - one that hostapd-wpe is designed to test.

What Is hostapd-wpe?

hostapd-wpe (Wireless Pwnage Edition) is a patched version of hostapd - the standard Linux software access point daemon - modified to impersonate enterprise WiFi networks and capture user credentials. It was created by Brad Antoniewicz (originally as FreeRADIUS-WPE, later ported to hostapd) and has become the standard tool for testing enterprise wireless security.

The tool creates a rogue access point that mimics a legitimate enterprise network. When devices connect to it, hostapd-wpe performs the server side of the authentication exchange, capturing credential hashes in the process. These hashes can then be cracked offline to recover plaintext passwords.

hostapd-wpe is included in Kali Linux and is one of the attack modules available through the airgeddon wireless auditing framework.

How 802.1X Authentication Works

sequenceDiagram
    participant Client as WiFi Client
    participant AP as Access Point
    participant RADIUS as RADIUS Server
    
    Client->>AP: Association Request
    AP-->>Client: Association Response
    
    Note over Client,RADIUS: EAP Authentication Begins
    
    AP->>Client: EAP-Request/Identity
    Client->>AP: EAP-Response/Identity (username)
    AP->>RADIUS: Access-Request (forwarded)
    
    Note over Client,RADIUS: TLS Tunnel Established (PEAP)
    RADIUS->>AP: EAP-Request (Server Certificate)
    AP->>Client: EAP-Request (Server Certificate)
    Client->>Client: Verify Certificate?
    
    Note over Client,RADIUS: MSCHAPv2 Inside TLS Tunnel
    RADIUS->>Client: Challenge
    Client->>RADIUS: Response (NT hash-based)
    RADIUS->>Client: Success/Failure
    
    RADIUS->>AP: Access-Accept + Session Keys
    AP->>Client: EAP-Success
    Note over Client,AP: 4-Way Handshake + Encrypted Traffic

The 802.1X PEAP/MSCHAPv2 authentication flow - the certificate verification step is where the vulnerability lies.

802.1X is the IEEE standard for port-based network access control. In wireless networks, it works with EAP (Extensible Authentication Protocol) to authenticate users before granting network access.

The most common enterprise WiFi configuration uses PEAP (Protected EAP) with MSCHAPv2 as the inner authentication method. Here's how it works:

1. The client associates with the access point (standard WiFi association, no encryption yet)
2. EAP identity exchange - The client sends its username (either in the clear or anonymized)
3. TLS tunnel establishment - The RADIUS server presents a certificate, and a TLS tunnel is built (similar to HTTPS). This is the PEAP "protected" part.
4. Inner authentication - Inside the TLS tunnel, MSCHAPv2 performs a challenge-response authentication using the user's password hash
5. Session keys are derived - On success, unique encryption keys are generated for this specific session

The critical step is #3 - the TLS tunnel establishment. The client device is supposed to verify the RADIUS server's certificate to ensure it's connecting to the legitimate authentication server. This is where things go wrong.

The Vulnerability

The entire security model of PEAP depends on the client verifying the server certificate. If the client doesn't check the certificate (or accepts any certificate), it will happily establish a TLS tunnel with a rogue server and send its credentials through.

In practice, certificate validation is frequently broken:

• Clients configured to "don't validate" - Many organizations distribute WiFi profiles that disable certificate validation because it's easier to deploy
• Users clicking "accept" on certificate warnings - When prompted about an unknown certificate, most users click through the warning to get connected
• Incomplete validation - Some clients check that the certificate is signed by a trusted CA but don't verify the specific server name, allowing any certificate from a trusted CA to pass
• BYOD devices - Personal devices brought to work rarely have proper certificate profiles installed
• Default OS behavior - Some operating systems default to not validating enterprise WiFi certificates

This isn't a bug in PEAP or MSCHAPv2 per se. The protocol is designed correctly - if certificate validation works, the attack fails. The vulnerability is in the deployment and configuration of client devices.

How hostapd-wpe Works

sequenceDiagram
    participant Client as Victim Client
    participant Rogue as hostapd-wpe (Rogue AP)
    participant Attacker as Attacker Terminal
    
    Note over Rogue: Broadcasting same SSID as target
    Note over Client: Auto-connects or user selects network
    
    Client->>Rogue: Association Request
    Rogue-->>Client: Association Response
    
    Rogue->>Client: EAP-Request/Identity
    Client->>Rogue: EAP-Response/Identity (username)
    Rogue->>Attacker: Logs username
    
    Note over Client,Rogue: TLS Tunnel (with rogue certificate)
    Rogue->>Client: Rogue Server Certificate
    Client->>Client: Certificate not validated!
    Client->>Rogue: TLS tunnel established
    
    Note over Client,Rogue: MSCHAPv2 inside tunnel
    Rogue->>Client: MSCHAPv2 Challenge
    Client->>Rogue: MSCHAPv2 Response (hash)
    Rogue->>Attacker: Logs challenge + response hash
    Rogue->>Client: MSCHAPv2 Success (fake)
    
    Note over Attacker: Crack hash offline with
    Note over Attacker: asleap / hashcat / john

hostapd-wpe attack flow - the rogue AP captures MSCHAPv2 credentials by impersonating the legitimate enterprise network.

hostapd-wpe exploits the certificate validation weakness by creating a rogue access point that:

1. Broadcasts the same SSID as the target enterprise network
2. Presents its own self-signed certificate during the TLS tunnel setup
3. Accepts any credentials during the inner authentication
4. Logs the MSCHAPv2 challenge and response for offline cracking
5. Optionally returns a success to maintain the connection (though the client won't get real network access)

The captured data consists of the MSCHAPv2 challenge (a random value sent by the server), the response (computed by the client using its password hash and the challenge), and the username. With the challenge and response, an attacker can perform offline dictionary attacks to recover the password.

Setting Up hostapd-wpe

On Kali Linux, hostapd-wpe can be installed from the repository:

sudo apt install hostapd-wpe

The main configuration file is at /etc/hostapd-wpe/hostapd-wpe.conf. Key settings to modify:

# Interface configuration
interface=wlan0          # Your wireless interface
driver=nl80211           # Standard Linux wireless driver

# Network configuration
ssid=TargetCorpWiFi      # Match the target network SSID
channel=6                # Match the target channel

# 802.1X configuration
ieee8021x=1
eap_server=1
eap_user_file=/etc/hostapd-wpe/hostapd-wpe.eap_user

# Certificate paths (pre-generated self-signed certs)
ca_cert=/etc/hostapd-wpe/certs/ca.pem
server_cert=/etc/hostapd-wpe/certs/server.pem
private_key=/etc/hostapd-wpe/certs/server.key
private_key_passwd=whatever

# WPE logging
wpe_logfile=/tmp/hostapd-wpe.log

The self-signed certificates are generated during installation. For a more convincing attack (in an authorized test), you could generate certificates that match the organization's naming conventions - though this rarely matters since most vulnerable clients don't inspect certificate details.

Launch the rogue AP:

sudo hostapd-wpe /etc/hostapd-wpe/hostapd-wpe.conf

hostapd-wpe will start broadcasting the configured SSID and waiting for connections. As clients connect and authenticate, their credentials appear in the terminal and the log file.

Capturing Credentials

When a client connects, hostapd-wpe outputs something like this:

mschapv2: Mon Mar 26 10:15:32 2026
  username: jsmith
  challenge: 5a:3b:8c:4d:2e:1f:0a:9b
  response: a1:b2:c3:d4:e5:f6:a1:b2:c3:d4:e5:f6:a1:b2:c3:d4:e5:f6:a1:b2:c3:d4:e5:f6
  jtr NETNTLM: jsmith:$NETNTLM$5a3b8c4d2e1f0a9b$a1b2c3d4e5f6...

The output gives you the username in cleartext, the challenge bytes, the response bytes, and a formatted hash ready for John the Ripper.

Several factors affect how many credentials you capture:

• Signal strength - Your rogue AP needs to be reachable by target clients. Being physically closer to the target area helps.
• Client behavior - Devices configured to auto-connect to known SSIDs will connect automatically. Others require manual selection.
• Deauthentication - Optionally sending deauth frames against the legitimate AP forces clients to reconnect, and some will connect to your rogue AP if it has a stronger signal.
• Channel selection - Matching the legitimate AP's channel or choosing an adjacent one affects which clients see your network.

Cracking the Captured Hashes

MSCHAPv2 hashes can be cracked using several tools:

asleap is purpose-built for cracking MSCHAPv2:

asleap -C [challenge] -R [response] -W /path/to/wordlist.txt

hashcat supports MSCHAPv2 with mode 5500 (NTLMv1) or mode 5600 (NTLMv2):

hashcat -m 5500 captured_hash.txt /path/to/wordlist.txt

John the Ripper can crack the formatted hash directly from hostapd-wpe's output:

john --wordlist=/path/to/wordlist.txt captured_hash.txt

MSCHAPv2 uses NTLM hashes internally, and the challenge-response mechanism doesn't add significant computational cost to cracking. This means cracking speeds are fast compared to WPA2-PSK (which uses PBKDF2 with 4096 iterations). A modest GPU can test hundreds of millions of MSCHAPv2 passwords per second.

The practical implication: even moderately complex passwords fall quickly. An 8-character alphanumeric password that might take months to crack against a WPA2 handshake could fall in minutes against an MSCHAPv2 hash.

Beyond PEAP/MSCHAPv2

While PEAP/MSCHAPv2 is the most common target, hostapd-wpe also supports attacks against:

• EAP-TTLS - Another tunneled EAP method. Similar to PEAP in that it creates a TLS tunnel and then authenticates inside it. hostapd-wpe captures credentials from the inner authentication method (often PAP, which sends passwords in cleartext within the tunnel).
• EAP-FAST - Cisco's Flexible Authentication via Secure Tunneling. Can be attacked similarly if client-side validation is weak.
• EAP-MD5 - A simple challenge-response method with no server authentication. Extremely vulnerable to credential capture.

EAP-TLS (certificate-based authentication where both client and server present certificates) is resistant to this attack because there are no passwords to capture - authentication is based on cryptographic certificates.

Defending Against Rogue Enterprise APs

If hostapd-wpe is an offensive testing tool, what does the defensive side look like?

Enforce certificate validation on all clients. This is the single most important defense. Deploy WiFi configuration profiles (MDM profiles on mobile devices, GPOs on Windows) that specify exactly which certificate authority and server name to trust. Don't give users the option to skip validation.

Use EAP-TLS instead of PEAP/MSCHAPv2. Certificate-based authentication eliminates the password capture attack entirely. It's more complex to deploy (every user needs a client certificate) but dramatically more secure.

Deploy wireless intrusion detection. WIDS (Wireless Intrusion Detection Systems) can detect rogue access points by monitoring for SSIDs that match your network but originate from unknown MAC addresses or unexpected locations.

Implement 802.11w (Management Frame Protection). This prevents deauthentication attacks, making it harder for attackers to force clients off the legitimate network and onto a rogue AP.

Use unique inner and outer identities. Configure clients to use an anonymous outer identity (e.g., "anonymous@corp.com") to prevent username leakage even before the TLS tunnel is established.

Monitor for rogue APs actively. Regular wireless surveys and automated monitoring can detect impersonation attempts. Tools like Kismet can passively monitor the wireless environment for anomalies.

Educate users. Train employees to recognize certificate warnings and to report them instead of clicking through. This is a last line of defense, but it matters.

Building a Practice Environment

To practice enterprise WiFi attacks safely:

Hardware needed:

• A Linux machine (laptop or desktop running Kali Linux)
• A wireless adapter supporting AP mode (most adapters that support monitor mode also support AP mode)
• A second wireless adapter or a separate test client device (phone or laptop)

Set up a legitimate enterprise AP first:

1. Install FreeRADIUS and configure it for PEAP/MSCHAPv2
2. Create test user accounts
3. Configure hostapd (the regular version) to use your RADIUS server
4. Connect a client device to verify the legitimate network works

Then test with hostapd-wpe:

1. Configure hostapd-wpe with the same SSID
2. Run it on a different adapter
3. Observe whether your client connects to the rogue AP
4. Test with and without certificate validation enabled on the client

This gives you both sides of the story: you see how the attack works and what proper certificate validation looks like from the client side. Understanding the defense is just as important as understanding the attack.

For quick wireless reconnaissance before running hostapd-wpe, a device like the BLEShark Nano can scan for nearby enterprise networks, identify their channels and BSSIDs, and help you understand the wireless environment you're testing. This reconnaissance phase is critical - you need to know what you're impersonating before you impersonate it.

Building your enterprise WiFi testing lab? The BLEShark Nano provides the wireless reconnaissance capabilities you need - WiFi scanning, network identification, and signal analysis - to plan and execute effective security assessments.