Hello World! In my previous posts on WiFi Security, I discussed personal networks that use a preshared key between the authenticator (access point) and the supplicant (client/station). This is an excellent solution for home or small networks, but it would be a nightmare for blue teams and system administrators if used in enterprises or large companies. As a result, they employ an external centralised server to provide an authentication mechanism for the WiFi networks to the client devices.

But that does not guarantee that the traffic is still secure; a wireless device implanted by an attacker in the environment may be able to sniff the in-flight packets and attempt to extract the username and password. I'll talk to you about the same thing today while using EAPHammer, a great tool for the job.

You can try this lab on the AttackDefense platform - https://attackdefense.com/challengedetails?cid=1328

There are two physical interfaces attached to the attacker system in the lab: wlan0 and wlan1. Later, I'll use wlan1 to build a honeypot access point while using wlan0 for capture. Put the WiFi interface into monitor mode, which can be done by executing the following commands in the correct order.

ifconfig wlan0 down				# set wlan0 interface status to down
iwconfig wlan0 mode monitor		# set monitor mode on the interface
ifconfig wlan0 up				# set wlan0 interface status to up
iwconfig wlan0					# view interface details (confirm mode)

Let's capture the packets from both 2.4 GHz and 5 GHz bands through the wlan0 interface using the following command.

airodump-ng --band abg wlan0

You'll notice that a client with the MAC 02:00:00:00:0A:00 is attempting to connect to the network "DefenseConference," but there isn't one nearby.

In order to capture the authentication handshakes, we could create a network with the same SSID and see if it connects. I'll show you how to use the EAPHammer tool for the same in the section after this.

In the lab, you will find out that there is a directory named eaphammer which contains a binary eaphammer. You can run this program with the following configuration as shown below

• -i wlan1 is used to start the WiFi network on the wlan1 interface
• --channel 6 is used to fix the frequency band at 2.4Ghz and use \( 6^{th} \) channel
• --wpa-version 2 will configure to use WPA2 encryption for the network
• --auth wpa-eap is used to configure the authentication server (MGT auth type), which is used in the enterprise network
• --essid DefenseConference will set the SSID of this WiFi network to DefenseConference
• --creds is used to enable EAP credentials harvesting using the evil twin attack

cd eaphammer
./eaphammer -i wlan1 --channel 6 --wpa-version 2 \
--auth wpa-eap --essid DefenseConference --creds

The honeypot network will start to broadcast the beacon frames to announce its presence in the network and you will see this in the airodump-ng output on channel 6.

The EAPHammer console logs show that the client attempted to use EAP-TTLS/PAP, which explains why the credentials are displayed in clear-text.

• https://www.securew2.com/blog/pitfalls-of-eap-ttls-pap
• https://github.com/s0lst1c3/eaphammer
• https://security.stackexchange.com/questions/68351/what-are-the-difference-between-wpa2-psk-and-wpa2-eap-psk