Aircrack Handshake

[Leonides Suttle]

Thistutorial walks you through cracking WPA/WPA2 networks which use pre-shared keys. I recommend you do some background reading to better understand what WPA/WPA2 is. The Wiki links page has a WPA/WPA2 section. The best document describing WPA is Wi-Fi Security - WEP, WPA and WPA2. This is the link to download the PDF directly. The WPA Packet Capture Explained tutorial is a companion to this tutorial.

WPA/WPA2 supports many types of authentication beyond pre-shared keys. aircrack-ng can ONLY crack pre-shared keys. So make sure airodump-ng shows the network as having the authentication type of PSK, otherwise, don't bother trying to crack it.

There is another important difference between cracking WPA/WPA2 and WEP. This is the approach used to crack the WPA/WPA2 pre-shared key. Unlike WEP, where statistical methods can be used to speed up the cracking process, only plain brute force techniques can be used against WPA/WPA2. That is, because the key is not static, so collecting IVs like when cracking WEP encryption, does not speed up the attack. The only thing that does give the information to start an attack is the handshake between client and AP. Handshaking is done when the client connects to the network.Although not absolutely true, for the purposes of this tutorial, consider it true. Since the pre-shared key can be from 8 to 63 characters in length, it effectively becomes impossible to crack the pre-shared key.

The only time you can crack the pre-shared key is if it is a dictionary word or relatively short in length. Conversely, if you want to have an unbreakable wireless network at home, use WPA/WPA2 and a 63 character password composed of random characters including special symbols.

The impact of having to use a brute force approach is substantial. Because it is very compute intensive, a computer can only test 50 to 300 possible keys per second depending on the computer CPU. It can take hours, if not days, to crunch through a large dictionary. If you are thinking about generating your own password list to cover all the permutations and combinations of characters and special symbols, check out this brute force time calculator first. You will be very surprised at how much time is required.

IMPORTANT This means that the passphrase must be contained in the dictionary you are using to break WPA/WPA2. If it is not in the dictionary then aircrack-ng will be unable to determine the key.

It is recommended that you experiment with your home wireless access point to get familiar with these ideas and techniques. If you do not own a particular access point, please remember to get permission from the owner prior to playing with it.

In the response above, you can see that ath0 is in monitor mode, on the 2.452GHz frequency which is channel 9 and the Access Point shows the MAC address of your wireless card. Only the madwifi-ng drivers show the card MAC address in the AP field, other drivers do not. So everything is good. It is important to confirm all this information prior to proceeding, otherwise the following steps will not work properly.

Notice that airmon-ng enabled monitor-mode on mon0. So, the correct interface name to use in later parts of the tutorial is mon0. Wlan0 is still in regular (managed) mode, and can be used as usual, provided that the AP that wlan0 is connected to is on the same channel as the AP you are attacking, and you are not performing any channel-hopping.

Here, mon0 is seen as being in monitor mode, on channel 9 (2.452GHz). Unlike madwifi-ng, the monitor interface has no Access Point field at all. Also notice that wlan0 is still present, and in managed mode - this is normal. Because both interfaces share a common radio, they must always be tuned to the same channel - changing the channel on one interface also changes channel on the other one.

This step is optional. If you are patient, you can wait until airodump-ng captures a handshake when one or more clients connect to the AP. You only perform this step if you opted to actively speed up the process. The other constraint is that there must be a wireless client currently associated with the AP. If there is no wireless client currently associated with the AP, then you have to be patient and wait for one to connect to the AP so that a handshake can be captured. Needless to say, if a wireless client shows up later and airodump-ng did not capture the handshake, you can backtrack and perform this step.

This step sends a message to the wireless client saying that that it is no longer associated with the AP. The wireless client will then hopefully reauthenticate with the AP. The reauthentication is what generates the 4-way authentication handshake we are interested in collecting. This is what we use to break the WPA/WPA2 pre-shared key.

The purpose of this step is to actually crack the WPA/WPA2 pre-shared key. To do this, you need a dictionary of words as input. Basically, aircrack-ng takes each word and tests to see if this is in fact the pre-shared key.

When this happens you either have to redo step 3 (deauthenticating the wireless client) or wait longer if you are using the passive approach. When using the passive approach, you have to wait until a wireless client authenticates to the AP.

Unfortunately, sometimes you need to experiment a bit to get your card to properly capture the four-way handshake. The point is, if you don't get it the first time, have patience and experiment a bit. It can be done!

In an ideal world, you should use a wireless device dedicated to capturing the packets. This is because some drivers such as the RTL8187L driver do not capture packets the card itself sends. Also, always use the driver versions specified on the wiki. This is because some older versions of the drivers such as the RT73 driver did not capture client packets.

To dig deep into the packet analysis, you must start airodump-ng without a BSSID filter and specify the capture of the full packet, not just IVs. Needless to say, it must be locked to the AP channel. The reason for eliminating the BSSID filter is to ensure all packets including acknowledgments are captured. With a BSSID filter, certain packets are dropped from the capture.

When it comes to analyzing packet captures, it is impossible to provide detailed instructions. I have touched on some techniques and areas to look at. This is an area which requires effort to build your skills on both WPA/WPA2 plus how to use Wireshark.

To keep things short I've been experimenting with cracking wpa in aircrack. Everything works fine except a handshake is never captured as I am told when I go to run aircrack against the .cap file. I am using the panda PAU09 which plenty of people say works great, and yes the deauth command does work.

Can you post all the commands on how you started and capture everything? Might help. Make sure when the card is started in monitor mode, airmon-ng -check shows nothing in the way. Also, airodump-ng, set it to a specific channel with -c # where # is the channel of your AP. If you don't, it will hop all channels and never work properly. After a deauth is run, wait a bit, airodump will show it captured the handshake at the top of the screen. If it doesn't, then it didn't see a handshake, meaning no one connected to it after the deauth, but need to make sure clients were on first, then deauth, then when they reconnect, you should see the handshake. Even when it says it captures it, do it a few times. It can also sometimes show false positives. Then in aircrack, you should get a good file to work with.

It would seem this is an issue with the raspberry pi 3, could be the arm image. Maybe I'll take a plain Debian arm image and reroll it with kali tools and see if that's works. I'm really surprised I can't find anyone else with this problem.

If this is specific to the Pi, you may need to update to the re4son kernel, for driver support on the card you're using, or, the card is not compatible for injection and monitor mode to begin with, which is not so much the Pi and Kali, but the card's support. Raspberry's have different drivers though, and some work, some need to be updated, or in some instances, a different kernel depending on the wifi card.

But I'm going to think that the Pi, didn't have drivers for that card specifically, where the desktop variants might. Only testing will tell. Also make sure the card, if supposed to work on Kali, works on the other versions of Kali(non Pi /non-arm based). If it does, then seems they need the drivers ported to the Pi and ARM branches, which hopefully Re4son's Pi kernel will fix for you, but not sure if that is one of the cards he has tested. He is working on a bunch of new wifi cards for the Pi though.

Thanks for all the help. I've been forum hopping trying to find a solution and ended up on the kali forums where someone is having the same issue with a Realtek chip card. I actually just found re4son there and links to his kernel. I'll update and shoot him a message if it's still not working.

Unless its a linux driver on the disk, more than likely, it's an NDIS wrapper, and only work for connectivity, and not injection/monitor mode, but without having one to test, i can't say. Good it works from desktop versions, i had a feeling after you mentioned Pi, it's an ARM driver issue, which is not uncommon. Not everything is ported 100% because of the support and testing done by people who have those cards and build the arm branch. Re4son is just a community member, but he's already contributed a lot to the Pi side of the project with his driver updates and kernel testing. Hopefully they get rolled into the main side at some point.

3a8082e126