WPA-Enterprise delegates the authentication to a RADIUS server. Even though it is not vulnerable to any direct attack, it is still possible to intercept credentials by performing an evil-twin attack against clients.
berate_ap, it is possible to create an evil-twin access point configured to intercept the credentials of various EAP methods:
berate_ap -n <iface> <ESSID> --eap --mana-wpe --mana-credout [/path/to/output] --eap-user-file [/path/to/eap_user] --eap-cert-path [/path/to/cert/dir]
Use the following additional options to mimick the targeted access point configuration:
||Channel (list of WLAN channels)|
||Frequency band (2.4 Ghz / 5 Ghz)|
||Enable IEEE 802.11ac|
||Enable IEEE 802.11ac|
berate_ap -h and
hostapd-mana wiki for more details.
eap_user file allows you to configure the EAP methods order proposed during negotiation and thus, to perform a EAP downgrade attack. If not specified, it will use the following default configuration:
# Phase 1 users * PEAP,TTLS,TLS,MD5,GTC # Phase 2 users "t" MSCHAPV2,TTLS-MSCHAPV2,MD5,GTC,TTLS-PAP,TTLS-CHAP,TTLS-MSCHAP "1234test" 
* PEAP,TTLS,TLS,FAST "t" GTC,MSCHAPV2,TTLS-MSCHAPV2,TTLS,TTLS-CHAP,TTLS-PAP,TTLS-MSCHAP,MD5 "t" 
* PEAP [ver=1] "t" GTC "t" 
Full EAP downgrade (weakest to strongest):
* PEAP,TTLS,TLS,FAST "t" GTC,TTLS-PAP,MD5,TTLS-CHAP,TTLS-MSCHAP,MSCHAPV2,TTLS-MSCHAPV2,TTLS "t" 
Speed optimized approach (strongest to weakest):
* PEAP,TTLS,TLS,FAST "t" MSCHAPV2,TTLS-MSCHAPV2,TTLS,TTLS-CHAP,GTC,TTLS-PAP,TTLS-MSCHAP,MD5 "t" 
This patched version of
hostapd will always overwrite the user’s identity with ‘
t’, in order for the single user entry of the
eap_user file to always be used.
eap-cert-path option allows you to configure the certificate used by the rogue RADIUS server. If not specified, it will prompt you to interactively fill-in the information and automatically create the following required files within the
Once the files have been created, save them to avoid having to fill the certificate information again:
cp /tmp/create_ap.<iface>.conf.<rand>/hostapd.*.pem <destination folder>
Note on OpenSSL
hostapd-mana uses the OpenSSL libraries of the system, which does not support legacy clients using SSLv2 and SSLv3 (s.a. Windows 7). To fix this issue, use the patched version available on my repository which includes a local build of OpenSSL. Below are the instructions to build from source on a Kali Linux system:
apt install build-essential pkg-config git libnl-genl-3-dev libssl-dev net-tools git clone https://github.com/no0be/hostapd-mana --branch openssl-patch /opt/hostapd-mana cd /opt/hostapd-mana ./build.sh ln -sf /opt/hostapd-mana/hostapd/hostapd /usr/local/bin/hostapd-mana
eaphammer is a toolkit designed to perform attacks against WPA-Enterprise networks. It provides an easy-to-use interface that can be leveraged to execute powerful wireless attacks with minimal manual configuration. As the tool is always evolving and its documentation is well written, please refer to the original GitHub repo:
WPA-Enterprise, also refered to as WPA-EAP or WPA-802.1X, uses EAP to delegate the authentication to a RADIUS server. The Extensible Authentication Protocol is a framework more than a protocol, which provides a standardized set of functions and rules to specific authentication protocol implementations known as EAP methods:
- EAP-TLS - the original IETF open standard EAP authentication protocol, widely supported, only allows certificate-based authentication
- PEAP - encapsulates EAP within a TLS tunnel (rather an encapsulation than a method), developed by Microsoft, Cisco and RSA Security
- EAP-TTLS - TLS extension to provide EAP over a TLS tunnel, widely supported (except by Microsoft)
- LEAP - developed by Cisco prior to the standard, no native Microsoft support, deprecated
- EAP-FAST - Cisco replacement for LEAP
These EAP methods can be divided in two categories based on the way the client authenticates: certificate authentication and credentials authentication.
Both client and server authenticate using a certificate signed by a trusted authority.
Most common methods:
PEAP with EAP-TLS
In order to provide a way for the clients to authenticate using a username and password, the process is split in two phases:
- phase 1 allows the server to authenticate by presenting a certificate and creates a secure TLS tunnel
- phase 2 allows the client to authenticate by using a different protocol encapsulated within the TLS tunnel
While there are multiple authentication protocols available for phase 2, most clients will prefer to use
MSCHAPv2 which is based on a two-way challenge-response. However, many devices still support weaker protocol such as
GTC that transmit cleartext credentials.
Most common methods:
PEAP with MSCHAPv2,
EAP-TTLS with MSCHAPv2
This attack consists of creating a rogue access point mimicking the targeted ESSID in order to get clients to perform the phase 2 authentication process with your rogue RADIUS server. Thus, allowing you to capture the cleartext credentials or challenge-response used during inner authentication.
This attack will not work against clients configured to:
- use a certificate-based authentication (s.a.
PEAP with EAP-TLS), since there is no credentials to steal
validate the server certificate during phase 1 authentication, which prevents phase 2 authentication to happen
SSL: SSL3 alert: read (remote end reported an error):fatal:unknown CA OpenSSL: openssl_handshake - SSL_connect error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca
Since the EAP method negotiation is initiated by the evil-twin access point, it is possible to trick the clients to use a weak authentication protocol (s.a.
GTC). In fact, while legitimate access points propose EAP methods from the strongest to the weakest, the evil-twin access point can propose EAP methods from the weakest to the strongest. If you care about not getting caught, you can even mimick the EAP method order of the targeted access point.
The EAP negotiation process will propose one EAP method at a time. Thus, a full weakest to strongest EAP downgrade might add a noticeable amount of time to the authentication process, which might cause the users to abord the authentication. Since most client devices won’t accept the weaker EAP methods, a more balanced approach is usually more effective.