Capturing WPA2-PSK Handshake with Kali Linux and Aircrack

In my last post we went through setting up an external USB Wi-Fi adapter and went through the configuration steps to put the adapter into monitor mode. We also looked at the standard output of airodump-ng, and were able to gain a bunch of good information about all of the access points around us, including their ESSID, BSSID, what channel they were operating on, what type of encryption they’re using, and what type of authentication they’re using.

Now that we have all of that information, we can choose a single AP to be our target for the purposes of trying to break the WPA2 pre-shared key (PSK) that’s configured on the access point. Once we’re able to obtain that PSK, we’ll be able to associate with the access point and begin prodding around whatever network it’s connected to.

Setting Up Our Adapter and Choosing a Target

We’ll start by putting our USB Wi-Fi adapter in monitor mode. If you aren’t sure what’s happening here, please refer to the previous article.

Now let’s see what access points are near us, and choose one to target. To do this, we’ll run airodump-ng in its most basic form, only taking a single parameter – the name of the monitor interface.

airodump-ng wlan1mon

From this list, we’ll choose an AP to target. We’ll need to note the BSSID, ESSID, and channel of the AP. Since we’re targeting WPA2-PSK in this example, we’ll have to choose an AP whose encryption type is listed as WPA2, and whose AUTH type is PSK.

Capturing Frames to/from the Targeted AP

Once we have that information, we’ll be able to use airodump-ng to target that AP and its connected clients specifically. While doing this, we’re also going to specify additional parameters that we didn’t specify before. We’re going to specify the name of the channel that our target AP is running on with the -c switch, the name of the BSSID with the –bssid switch, and the name of an output file with the -w switch.

The output file will contain all of the captured frames that our monitor mode wireless adapter is able to capture. What we’re looking to capture specifically is a WPA2-PSK authentication handshake between a client and the AP. That handshake contains a hashed version of the pre-shared key, which we’ll be bruit-forcing later.

In this example I’m using the values that came from my target AP (with the BSSID slightly obfuscated for privacy reasons). You’ll use your own values, obtained from our previous airodump-ng session to replace mine. You don’t need to specify an extension for your output file, as several will be created, each with an appropriate extension, automatically.

airodump-ng -c 1 --bssid 00:15:FF:EE:EE:EE -w capture wlan1mon

You’ll notice that this airodump-ng output looks similar to the last output, only the list of APs isn’t populating with more than just the one we specified. Also, the channel field in the upper left corner isn’t hunting, since we specified the channel on the command line. airodump-ng is now only capturing packet for the AP we specified, on the channel we specified. At the bottom of the terminal, the list of connected clients should start to populate.

This process could take a bit longer to run, especially if there aren’t a lot of clients connected to the AP. In order for this to work, we need at least one connected client who is talking to the AP, but the more clients that are connected simultaneously the easier it’s going to be to capture a WPA2-PSK authentication handshake.

Speeding Up the Capture with a Deauthentication Attack

If your wireless adapter supports packet injection, we can speed this process up using the aireplay-ng utility. We can do this by opening a new shell, since we want to keep airodump running / capturing in the background, and using the following context.

aireplay-ng -0 10 -a 00:15:FF:EE:EE:EE wlan1mon

The -0 switch tells the aireplay-ng how many deauthentication (deauth) packets to broadcast “from the AP.” In theory, what should happen, is that all clients connected to the AP should receive these deauth broadcasts, deauthenticate from the AP, and then automatically reauthenticate to the AP once the deauth broadcast stops. In this example, we’ll send 10, which should be enough to force a handshake to happen upon reauthentication, given the number of clients connected to this AP.

The -a switch specifies the ESSID of the AP, and the final option is just the name of our monitor mode interface.

After I run the deauth attack, notice something that we didn’t see before. In the upper-right corner of the airodump window, we can now see that a WPA handshake was captured. (Scroll up to the last image to see that it wasn’t there before). Since we were capturing to our output file this entire time, that file should now contain a capture of the WPA2-PSK handshake.

If you are unable to capture a handshake right away, it might be a good idea to wait a few minutes, and attempt the aireplay attack again. It also might be a good idea to heed the warning that aireplay gave us after I ran the command and perform a targeted attack. Rather than sending broadcasts to all connected clients, we’ll direct a deauthentication attack at a single connected client. The syntax for that is as follows.

aireplay-ng -0 10 -a 00:15:FF:EE:EE:EE -c E0:46:9A:11:22:33 wlan1mon

A directed attack is basically the same command, but has the -c switch added and specifies the MAC address of the wireless client that we’re attempting to deauth.

Frame Capture File Information

Now that we have captured a WPA2-PSK handshake, you can stop the airodump session by pressing CTRL+C. There will now be several files related to the capture in your home directory. The one we’re most concerned with is the .cap file that corresponds to the capture we took above. I used the -w switch to call my capture output “capturefile,” so the file I’m concerned with is capturefile-01.cap.

Now that we have the file we need, we can take it offline to crack. There’s no reason to stay within the vicinity of the AP that you’re targeting if you don’t want to. Obviously if this is in a lab environment it doesn’t matter, but in the real world, it may. We’ll come back after we (hopefully) have broken the pre-shared key.

In addition to the convenience of not having to hang around your target while their hash is being cracked (which can take a LONG time), another real-world convenience exists in that cracking hashes using CPU power alone is a slow and almost pointless process. Realistically, you would take the capture file back to a machine running one or more GPUs, and use those GPUs to crack the key with a utility that supports GPU cracking, like Hashcat.

If you don’t think a GPU would make a big difference over a fast CPU, note this real-world study that I did just the other day. In an attempt to crack a WPA2-PSK key, I used a command that would run every phone number in an area code against a captured file (lots of users use a 10-digit phone number as a WPA2 key). Knowing what area code I was going to use, that left 10,000,000 possibilities. An Intel Core i5-7400 running at 3.0GHz took 8 hours and 14 minutes to complete that operation. A GeForce GTX 1070 did the same in 52 seconds.

In the next post, I’ll show you how to convert your .cap file to a .hccapx file, which is the format that Hashcat likes to work with. I’ll also show you some of the methods that I like to use to crack hashes using Hashcat, which can apply to virtually any hash, not just WPA2-PSK hashes.