EAPHammer Enterprise Wireless Attacks

EAPHammer automates evil twin attacks against WPA Enterprise (802.1X) networks. Where a manual hostapd-mana setup requires writing configuration files, generating certificates, and wiring up RADIUS components by hand, EAPHammer handles all of that in a single command. It spins up a rogue AP with a built-in RADIUS server, generates self-signed certificates on the fly, and captures EAP identities and MSCHAPv2 challenge/response pairs from connecting clients.

Beyond basic credential capture, EAPHammer supports GTC downgrade attacks that force clients to send cleartext passwords, and hostile portal attacks that serve a captive portal page to harvest credentials over HTTPS. Both techniques go further than what hostapd-mana offers out of the box.

Installing EAPHammer

Clone the repository and run the setup script. EAPHammer pulls in its own patched hostapd build and Python dependencies:

The setup script installs system dependencies, compiles the patched hostapd binary, and creates a Python virtual environment. It takes a few minutes. If it fails on missing build dependencies, install libssl-dev and libnl-genl-3-dev first.

Generating Certificates

EAPHammer generates its own certificate authority and server certificates. Run the cert wizard before your first attack:

The wizard prompts for country, state, organization, and CN fields. For a targeted attack, match these to the legitimate certificate details you collected during enumeration. Clients that display certificate details will see something plausible. The generated certs are stored in ./certs/ and reused across attacks unless you regenerate them.

EAPHammer Credential Capture with Evil Twin

The basic attack creates a rogue AP matching the target enterprise SSID. When clients connect and attempt 802.1X authentication, EAPHammer captures the EAP identity and MSCHAPv2 challenge/response pair:

Captured credentials are saved to ./loot/ in addition to console output. The MSCHAPv2 challenge/response pairs can be cracked offline with asleap or hashcat.

EAPHammer handles interface mode switching automatically. Unlike the manual hostapd-mana approach, you do not need to put the interface in managed mode yourself.

GTC Downgrade Attack

Most enterprise networks use PEAP-MSCHAPv2, which sends a hashed challenge/response. The GTC downgrade forces clients to use EAP-GTC instead, which transmits the password in cleartext inside the TLS tunnel. If the client's supplicant accepts the server's proposal to use GTC (many do by default), you get the plaintext password without any cracking.

When the downgrade works, you see the plaintext password directly in the output. No offline cracking needed. This is the highest-value attack EAPHammer offers.

The downgrade fails when the client's supplicant is configured to only accept MSCHAPv2 as the inner method. Windows machines with strict Group Policy, iOS devices, and well-configured wpa_supplicant setups will reject the GTC proposal and disconnect. In that case, fall back to standard MSCHAPv2 credential capture.

Hostile Portal Attack

The hostile portal combines an evil twin AP with a captive portal page served over HTTPS. Instead of relying on the 802.1X exchange, this approach presents a login form to the victim. It is effective against users who are accustomed to captive portals in hotels and airports and will enter domain credentials without hesitation.

EAPHammer redirects HTTP traffic to its built-in HTTPS portal. The portal uses the self-signed certificate generated earlier. Credentials submitted through the form are logged to ./loot/ in cleartext.

The hostile portal can be combined with credential capture so you collect both form submissions and MSCHAPv2 hashes from the same rogue AP:

Cracking Captured MSCHAPv2 Hashes

When using the standard credential capture mode (without GTC downgrade), the captured hashes need offline cracking. EAPHammer saves hashes in a format compatible with both asleap and hashcat.

With asleap:

With hashcat (mode 5500 for MSCHAPv2):

For full cracking methodology and hash format details, see the dedicated MSCHAPv2 cracking page.

OPSEC Considerations

A rogue AP is one of the most detectable wireless attacks. Enterprise environments with Wireless Intrusion Detection Systems (WIDS) will flag a new AP broadcasting the corporate SSID. Cisco, Aruba, and Meraki access points all include rogue AP detection by default.

The self-signed certificate is the second detection vector. Clients configured to validate the RADIUS server certificate will show a warning or refuse to connect entirely. Even without strict validation, security-aware users may notice the certificate prompt.

To reduce exposure:

• Keep the rogue AP active for the shortest time possible. Capture what you need and shut it down.
• Use a directional antenna to limit the AP's broadcast radius to the area near your target clients.
• Run the attack outside business hours when WIDS monitoring may have less active oversight.
• Match the legitimate AP's BSSID, channel, and SSID precisely.

When This Fails

Certificate pinning or validation: if the client's supplicant validates the RADIUS server certificate against a trusted CA or pinned certificate, the connection to the rogue AP is rejected before any credentials are exchanged. This is common in well-managed environments using Group Policy to push certificate trust settings.

EAP-TLS (mutual certificate authentication): when the network requires client certificates in addition to server certificates, there is nothing for EAPHammer to capture. The client authenticates with its own certificate and never sends a password or hash. EAP-TLS environments are not vulnerable to evil twin credential harvesting.

WIDS alerts and rogue AP containment: enterprise WIDS can actively contain a rogue AP by sending deauthentication frames to clients connecting to it, reversing your attack. If clients keep disconnecting from your rogue AP, the WIDS may be actively fighting you.

Supplicant rejects GTC: the GTC downgrade only works if the client's supplicant accepts the inner method change. Hardened configurations, iOS, and recent Android versions will reject GTC and disconnect. Fall back to MSCHAPv2 capture.