Well come back after we (hopefully) have broken the pre-shared key.

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 theyre using, and what type of authentication theyre using.

If you arent sure whats happening here, please refer to the previous article.

To do this, well run airodump-ng in its most basic form, only taking a single parameter the name of the monitor interface.

Since were targeting WPA2-PSK in this example, well have to choose an AP whose encryption type is listed as WPA2, and whose AUTH type is PSK.

While doing this, were also going to specify additional parameters that we didnt specify before.

Were 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.

What were 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 well be bruit-forcing later.

Youll use your own values, obtained from our previous airodump-ng session to replace mine.

You dont need to specify an extension for your output file, as several will be created, each with an appropriate extension, automatically.

Also, the channel field in the upper left corner isnt hunting, since we specified the channel on the command line.

At the bottom of the terminal, the list of connected clients should start to populate.

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 its going to be to capture a WPA2-PSK authentication handshake.

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.

In this example, well send 10, which should be enough to force a handshake to happen upon reauthentication, given the number of clients connected to this AP.

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 wasnt 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.

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, well direct a deauthentication attack at a single connected client.

There will now be several files related to the capture in your home directory.

I used the -w switch to call my capture output capturefile, so the file Im concerned with is capturefile-01.cap.

Theres no reason to stay within the vicinity of the AP that youre targeting if you dont want to.

Obviously if this is in a lab environment it doesnt matter, but in the real world, it may.

Intel Kali Linux Driver