Cracking WPA2-EAP WLAN perimeters with Evil Twin attacks
Coercing domain credentials from a device using evil twin attacks
Foreword
As mentioned in the recent post, Cracking PSK WLAN perimeters with Evil Twin attacks, the Evil Twin attacks are used to coerce an unsuspecting users to send their credentials to the adversary using a phishing-style attack. In this post, an Evil Twin attack will be used to allow a malicious Access Point (AP) to mimic a legitimate AP to coerce the user’s device to transmit stored credentials. The credentials will be domain credentials, as the Evil Twin will be set up to force the client device to authenticate using EAP-PEAP-MSCHAP. Ultimately, this attack is possible because users interact with a WLAN via the SSID, all the adversary has to do typically is mimic the SSID, and then users will connect to their malicious AP. This is further compounded by the default behaviour of user devices, which will automatically probe for and join previously connected WLAN that are stored in their wireless network lists.
An Evil Twin attack can be used in a wide range of attacks against EAP authentication methods, this post just happens to cover the more typical use case by targeting a device expecting a EAP-PEAP-MSCHAP WLAN. The attack be used against other EAP method, such as EAP-TLS; which often thought of as the most secure deployment. While EAP-TLS is secure in the sense of keeping an adversary from connecting to the WLAN, there are a range of a caveats. An evil twin attack could still be used to coerce the client device into joining an adversary-controlled WLAN, at which point it could be attacked. The client device will transmit its client certificate, which could be simply accepted by the adversary; however the adversary in turn can’t simply use the client certificate to connect to the legitimate AP, as they would not have the corrosponding private key. Instead once the client device is on the adversary’s WLAN, it can be targeted by network attacks using tools such as responder and mitm6 to coerce credentials from the device in that matter. At which point, the adversary could use the credentials to access the internal ecosystem via VPN, or in the case where the WLAN actually supports multiple EAP methods for authentication, bypass EAP-TLS by using alternative authentication method. This will be demonstrated in a future post to come.
The basic Evil Twin EAP-PEAP attack
Tools required
wiresharkiwconfigroguehcxpcapngtool(hcxtools)hashcat
Hardware required
- one wireless adaptor, I’ll be using the ALFA 1900 ( chipset:
RTL8814AU)
Conducting the basic Evil Twin EAP-PEAP-MSCHAP attack
I’ve built rogue as a simple to use attack platform for conducting evil twin attacks. In this post section I cover what I refer to as the basic EAP-PEAP-MSCHAP attack. In this attack, an adversary conducts an evil twin attack using a self-signed certificate, which can be generated using the below command.
sudo python3 /opt/rogue/rogue.py --cert-wizard
After going through the prompts, the certificate will be generated and rogue instance can be deployed to perform the attack.
sudo python3 /opt/rogue/rogue.py -i wlan0 --auth wpa-enterprise --internet --preset-profile wifi4 --channel-randomiser --default-eap peap -E all --country AU
The newer versions of rogue has the --preset-profile argument, which allows the user to select which generation of 802.11 (ie 802.11n, 802.11ac and etc) will be used without needing to know all the required parameters.
I will typically use watch to monitor the freeradius-server-wpe.log log file for the captured credentials using the following command.
watch -n 0.1 'cat /opt/rogue/logs/freeradius-server-wpe.log'
Once the evil twin attack is underway, the client device will see the malicious AP like below.
Assuming the client device has previously connected to the target WLAN and is what this attack is ultimately banking on, the client device will automatically connect and transmit the stored credentials.
There is another assumption being made at this point, we’re assuming the user has not specifically disabled the automatic reconnect function when the desired network is in range.
The below image shows the client connecting to the malicious AP and transmitting credentials.
The captured credentials are now shown in the log file.
The captured credentials are recorded as a Net-NTLM challenge, refer to Péter Gombos’ LM, NTLM, Net-NTLMv2, oh my! write for a great explanation. The challenge needs to be converted to a format usable by hashcat. Fortunately, I’ve included a utility as part of the rogue toolkit called hashcatifer.py, which will just do this.
sudo python3 /opt/rogue/tools/hashcatifer.py -f /opt/rogue/logs/freeradius-server-wpe.log -o demo.5500
As shown in the image above, hashcatifer.py provides the user guidance on the next command - which is using hashcat to attempt to crach the captured credentials.
echo 'rogue'| hashcat -m 5500 demo.5500 --quiet
The advance Evil Twin EAP-PEAP attack
Tools required
wiresharkiwconfigroguehcxpcapngtool(hcxtools)hashcat
Hardware required
- one wireless adaptor, I’ll be using the ALFA 1900 ( chipset:
RTL8814AU)
Conducting the advance Evil Twin EAP-PEAP-MSCHAP attack
In this attack, the client devices have had a basic level of hardening applied and refuse to connect to a WLAN which uses a self-signed certificate. In these scenarios, the adversary can still perform an evil twin attack, however they must replace the self-signed certificate with certificates signed by a trusted Certificate Authority (CA), such as default trusted root CA.
It just happens, that the Let’s Encrypt will issue certificates that have been signed by their the certificates, which in turn have been signed by the ISRG Root X1 certificate - which happens to be a default trusted root CA. This means, an adversary can request Let’s Encrypt to issue a free legitimately signed certificate, that has a trust chain up to a default trusted root CA, to use an evil twin attack for any domain that they own.
Looking at the hardened client behaviour
Below is hardened client configuration, for a Windows supplicant, in which the client is going to validate the RADIUS certificate is trusted, and if the certificate is not trusted, then do not ask the user to authorise a new certificate (see the Notifications before connecting dropdown list). Ultimately, this configuration will prevent a client from automatically transmitting the credentials, and also will manually connecting to the malicious AP - will stop that as well.
Using wireshark it is possible to confirm that the client device rejected the server’s certificate, in message 13 and did not send credentials as part of the inner authentication of EAP-PEAP-MSCHAP.
Ultimately, the advance evil twin technique is used to bypass this validation due to the default nature of supplicants. Which is, while this configuration is hardened, it is still insecure. In the above client configuration screenshot, the Verify the server's identity by validating the certificate tick box has been selected. But neither of the sub-boxs have been selected, therefore any of the certificates loaded into the device’s trusted root CA certificate store can be used to validate any RADIUS server’s identity:
- The
connect to these servers (examples:srv1;srv2;.*\.srv3\.com)tick box has not been selected, and is used to specify the RADIUS server the device will use to validate itself. - No default
Trusted Root Certification Authoritieshave been explicitly selected, therefore all are selected.
And because all trused root CA are selected, this is the reason why the adversary can generate a free certificate using Let’s Encrypt.
Generating the Let’s Encrypt certificate
The adversary would have to buy a domain, then deploy a machine (such as an EC2 instance), then add an A record for the instance to their zone file. However, assuming that is all done.
Install and configure cert-bot using the below command:
sudo apt update --assume-yes; apt install libaugeas0 --assume-yes
sudo python3 -m pip install certbot certbot-apache
sudo ln -s /opt/certbot/bin/certbot /usr/bin/certbot
Run the cert-bot client and follow the steps
certbot certonly -d rogue.pki.infamoussyn.com
Deploying the evil twin with Let’s Encrypt issued certificates
While rogue has the --cert-wizard argument, which launches a workflow to generate a self-signed certificate, it also includes three additional arguments that when used in tandum allow a custom certificate to be used instead. The following command example will deploy a rogue instance using the newly generated certificates from Let’s Encrypt.
sudo python3 /opt/rogue/rogue.py -i wlan0 --auth wpa-enterprise --internet --preset-profile wifi4 --channel-randomiser --default-eap peap -E all --country AU --essid rogue-advance --server-certificate /home/kali/Documents/fullchain.pem --ca-certificate /home/kali/Documents/chain.pem --server-private-key /home/kali/Documents/privkey.pemt
Note: Let’s Encrypt does not set a passphrase for the private key file, therefore there is no need to use the --server-private-password.
It can be seen in the below screenshot, that at frame 71 the rogue instance sends the Let’s Encrypt certificate and the client does not immediately reject it; at which point the hardened configuration has been bypassed and the standard evil twin attack can be continued.
Checking the log file, credentials have been captured.
Again hashcatifer.py is used to ready rogue instance log file for hashcat.
sudo python3 /opt/rogue/tools/hashcatifer.py -f /opt/rogue/logs/freeradius-server-wpe.log -o advance.5500
Finally hashcat is used again to crack the captured credentials.
echo 'rogue-advance'| hashcat -m 5500 demo.5500 --quiet
