Wireless and Mobile Hacks

(For more resources related to this topic, see here.)

So I don't think it's possible to go to a conference these days and not see a talk on mobile or wireless. (They tend to schedule the streams to have both mobile and wireless talks at the same time—the sneaky devils. There is no escaping the wireless knowledge!) So, it makes sense that we work out some ways of training people how to skill up on these technologies. We're going to touch on some older vulnerabilities that you don't see very often, but as always, when you do, it's good to know how to insta-win.

Wireless environment setup

This article is a bit of an odd one, because with Wi-Fi and mobile, it's much harder to create a safe environment for your testers to work in. For infrastructure and web app tests, you can simply say, "it's on the network, yo" and they'll get the picture. However, Wi-Fi and mobile devices are almost everywhere in places that require pen testing. It's far too easy for someone to get confused and attempt to pwn a random bystander. While this sounds hilarious, it is a serious issue if that occurs. So, adhere to the following guidelines for safer testing:

  • Where possible, try and test away from other people and networks. If there is an underground location nearby, testing becomes simpler as floors are more effective than walls for blocking Wi-Fi signals (contrary to the firmly held beliefs of anyone who's tried to improve their home network signal). If you're an individual who works for a company, or you know, has the money to make a Faraday cage, then by all means do the setup in there. I'll just sit here and be jealous.
  • Unless it's pertinent to the test scenario, provide testers with enough knowledge to identify the devices and networks they should be attacking. A good way to go is to provide the Mac address as they very rarely collide. (Mac randomizing tools be damned.)
  • If an evil network has to be created, name it something obvious and reduce the access to ensure that it is visible to as few people as possible. The naming convention we use is Connectingtomewillresultin followed by pain, death, and suffering. While this steers away the majority of people, it does appear to attract the occasional fool, but that's natural selection for you.
  • Once again, but it is worth repeating, don't use your home network. Especially in this case, using your home equipment could expose you to random passersby or evil neighbors. I'm pretty sure my neighbor doesn't know how to hack, but if he does, I'm in for a world of hurt.


We'll be using Kali Linux as the base for this article as we'll be using the tools provided by Kali to set up our networks for attack. Everything you need is built into Kali, but if you happen to be using another build such as Ubuntu or Debian, you will need the following tools:

  • Iwtools (apt-get install iw): This is the wireless equivalent of ifconfig that allows the alteration of wireless adapters, and provides a handy method to monitor them.
  • Aircrack suite (apt-get install aircrack-ng): The basic tools of wireless attacking are available in the Aircrack suite. This selection of tools provides a wide range of services, including cracking encryption keys, monitoring probe requests, and hosting rogue networks.
  • Hostapd (apt-get install hostapd): Airbase-ng doesn't support WPA-2 networks, so we need to bring in the serious programs for serious people. This can also be used to host WEP networks, but getting Aircrack suite practice is not to be sniffed at.
  • Wireshark (apt-get install wireshark): Wireshark is one of the most widely used network analytics tools. It's not only used by pen testers, but also by people who have CISSP and other important letters after their names. This means that it's a tool that you should know about.
  • dnschef (https://thesprawl.org/projects/dnschef/): Thanks to Duncan Winfrey, who pointed me in this direction. DNSchef is a fantastic resource for doing DNS spoofing. Other alternatives include DNS spoof and Metasploit's Fake DNS.
  • Crunch (apt-get install crunch): Crunch generates strings in a specified order. While it seems very simple, it's incredibly useful. Use with care though; it has filled more than one unwitting user's hard drive.


You want to host a dodgy network. The first question to ask yourself, after the question you already asked yourself about software, is: is your laptop/PC capable of hosting a network?

If your adapter is compatible with injection drivers, you should be fine. A quick check is to boot up Kali Linux and run sudo airmon-ng start <interface>. This will put your adapter in promiscuous mode. If you don't have the correct drivers, it'll throw an error. Refer to a potted list of compatible adapters at http://www.aircrack-ng.org/doku.php?id=compatibility_drivers.

However, if you don't have access to an adapter with the required drivers, fear not. It is still possible to set up some of the scenarios. There are two options.

The first and most obvious is "buy an adapter." I can understand that you might not have a lot of cash kicking around, so my advice is to pick up an Edimax ew-7711-UAN—it's really cheap and pretty compact. It has a short range and is fairly low powered. It is also compatible with Raspberry Pi and BeagleBone, which is awesome but irrelevant.

The second option is a limited solution. Most phones on the market can be used as wireless hotspots and so can be used to set up profiles for other devices for the phone-related scenarios in this article. Unfortunately, unless you have a rare and epic phone, it's unlikely to support WEP, so that's out of the question. There are solutions for rooted phones, but I wouldn't instruct you to root your phone, and I'm most certainly not providing a guide to do so.

Realistically, in order to create spoofed networks effectively and set up these scenarios, a computer is required. Maybe I'm just not being imaginative enough.

Scenario 1 – WEP, that's me done for the day

Sometime in the past, someone thought it would be a really good idea to encrypt wireless network traffic so that others couldn't snoop on it and steal their things. There were some initial forays into the field until Wired Equivalent Protocol (WEP) came along. WEP was great, it was fast, it had a cool name, and was relatively easy to implement. The problem was that other naughty people realized that if you listened to WEP traffic long enough, you could decrypt the traffic, and furthermore, gain access to the network. Not good. Needless to say, you shouldn't use WEP anymore (though legacy systems are legacy systems, so people still do).

We are going to create a WEP network through one of a number of ways and generate some fake traffic for our attackers to watch. We're going to use Airbase, Python, and a little bit of iptables, though not so much that you'll cry yourself to sleep tonight.

Code setup

Before we get into the creation of wireless networks (which, to be honest, isn't all that difficult), we need to be able to generate some fake traffic. You could sit and browse the Web for however long it takes for the testers to complete the challenge, but that's not a productive use of time. What we will do is make a script that does it for us, which is also going to come in handy for later sections of this article. That's efficiency right there.

We're going to write the code in Python because Python is nice, simple, and easily customizable. The code, taken straight from the Python library demos (http://docs.python.org/2.7/library/socket.html), is as follows:

import socket s = socket.socket() HOST = "" PORT = 9001 s.bind((HOST, PORT)) s.listen(5) while True: c, addr = s.accept() print "got connection from", addr c.send ("Bulbasaur-should-get-a-mention")

Let's look at each line of the preceding code in turn:

  • import socket allows us to call modules from the socket library. This saves us from writing the whole of the socket interaction.
  • s = socket.socket() assigns the socket functionality to the variable s. We can now call socket functionality with the prefix s.
  • HOST = "" and PORT = 9001 assign our local IP and chosen port to the variables HOST and PORT. It's important to note that the port you choose should be free and not in use by any other service, and that your host is your local network-facing address, not the loopback. I've said it before, but if you set it to loopback, only then can you see it. This will make you sad when the script fails.
  • s.bind((HOST, PORT)) creates a new socket with the parameters HOST and PORT. For me, this will create a socket on port 9001 on my adapter with the IP
  • s.listen(5) instructs the socket to listen for connections and accept them if they are made. That's pretty much it for this line.
  • while True basically says that while True is still True (deep philosophical statements abound), do the following tasks. Short of the world ending and all logic losing meaning, this script will continue to run. Unless, of course, you press Ctrl + C, the lesser known shortcut for the end of the world.
  • c, addr = s.accept() says that when a connection is accepted, the script is to assign the connection source to two values, c and addr. These can then be used separately without issues.
  • print "got connection from", addr writes to the standard output that a connection was made and who it was from, using the value addr from the previous line.
  • c.send ("Bulbasaur-should-get-a-mention") sends my key value to the client connecting to the server. You can replace the text in quotes with whatever you want; I just feel bad for the leafy chap.

That's all for the server for the time being. Now let's look at the client.

The client code shares a large amount of code with the server, which saves on explanation space and time. The client code is as follows:

import socket import time HOST = "" PORT = 9001 while True: s = socket.socket() s.connect((HOST, PORT)) print s.recv(1024) s.close time.sleep(5)

This time, we have not only imported socket again, but also time. Importing time allows us to use the later sleep command. I'm trying but I can't stop thinking about JRPGs right now. Take a look at the explanation of every line of the preceding code:

  • HOST and PORT in the client script have to match HOST and PORT from the server script. Otherwise, bad things will happen, and more importantly, good things won't happen.
  • We've already covered while True: previously. Infinite repeat like Miley Cyrus on a 13-year-old's iPod.
  • s = socket.socket() again assigns socket powers to s.
  • s.connect((HOST, PORT)) is a different code! This one makes the script perform a remote connection to a port, namely, the one we set up in the server script.
  • print s.recv(1024) prints whatever the server sends to the standard output, up to a maximum of the defined buffer size.
  • s.close() closes the connection. We do this so that the client can reconnect again to continue generating traffic.
  • time.sleep(5) causes the script to sleep for 5 seconds. This is to stop the server from getting hammered by constant requests.

Now run both sets of code on two separate devices, ensuring that the IPs and ports are set to the correct values and match. If everything goes well, the server should look similar to the following screenshot:

The preceding screenshot shows a connection from the IP and ascending ports. The client side should look similar to the following screenshot:

The preceding screenshot shows the key being printed continuously. That makes up all the code we need for this segment.

Network setup

Let's move on to network creation. I'm going to cover two methods of setting up a WEP network in this section. There's the easy, less-fun way and the harder, educational way. The easy way relies on the built-in mechanism of Linux and the harder way relies on Aircrack and iptables.

Let's start with the easy method. In the top-right corner of your Kali build is the Options menu. Navigate to System Settings | Network | Wireless | Use as Hotspot. The great thing about this method is that it automatically defaults to WEP, so there's very little configuration required. Once the network is set up on the host machine, connect to the hotspot with the client device, and run the script on the client device. This will simulate your traffic for your testers. That's nice and simple, right?

To lead nicely into the WPA-2 handshake snoop and crack, the second method for setup is using airbase. The command string you'll need is as follows:

airbase-ng -w <wep-key> -c <channel> -e <name><interface>

The preceding line of code is explained as follows:

  • -w <wep-key> sets the WEP key. This is the value that will be used to encrypt the traffic and handle authentication.
  • -c <channel> sets the channel that the router will operate on. If you're struggling because there's lots of traffic around, then change this value a few times until you get a good signal. However, this shouldn't happen because you're doing this in a secure, quiet environment, right?
  • -e <name> sets the name of the wireless network. Pay attention because this is going to be important later.
  • <interface> is the wireless interface from where the network will run. On most devices, provided no other tasks related to wireless are being performed, this is going to be wlan0. The names of the interfaces can be found out with the ifconfig or iwconfig commands.

Once this is enabled, it's a case of handling the input from the client devices. This isn't entirely necessary, but some devices may refuse to connect unless their traffic is connecting somewhere. So, you'll need to set up some basic iptables. This is where it gets a little complicated. You'll need to take the traffic from wlan0 and pass it onto eth0 or whatever else your Internet-enabled interface is. This is performed with the following commands:

ifconfig at0 up ifconfig at0 netmask route add –net netmask gw iptables –P FORWARD ACCEPT iptables –t nat –A POSTROUTING –o wlan0 –j MASQUERADE echo '1' /opt/proc/sys/net/ipv4/ip_foward

You'd ordinarily need to handle DHCP services, but since this is only a test environment, it's allowable to set IPs manually on both the client and host devices.

Now connect with the client device that sets up the interface with an IP address in the same range and run the script. As always, the exploit is at the end.

Scenario 2 – WPA-2

For this scenario, we're going to create a WPA-2 secured network with hostapd and link a client to it. This will allow your testers to practice disassociating clients with networks and capturing handshakes. These are not related to their social equivalents; we're not going to have someone ostracized and steal all of their friends.

The WPA-2 crack is very similar to the WEP network except that you can't use either of the methods I've described earlier. Airbase-ng will create a dummy WPA-2 network that is good enough to fool the unobservant, but if I thought you were unobservant I wouldn't have even started writing this book. You are a security-minded individual, and I'm going to give you the real deal… sort of.


Hostapd is managed through a file called hostapd.conf. On Kali Linux, hostapd is usually already installed and present in /etc/hostapd. For everyone using a legitimate operating system, you may need to install it. The apt-get install hostapd command is the beginning and end of this difficult part.

If the hostapd.conf file is present, edit it. If it isn't, create it, and fill it with the following details:

Interface=<interface> Ssid=<AwesomeName> Hw_mode=g Channel=<channel> Macaddr_acl=0 Auth_algs=1 Ignore_broadcase_ssid=0 Wpa=2 Wpa_passphrase= <Passphrase> Wpa_key_mgmt=WPA-PSK Rsn_pairwise=CCMP

It's time for another line-by-line discussion. The explanation of every line of the preceding code is given as follows:

  • Interface=<interface> points hostapd at the right network interface. If you set this incorrectly, hostapd will try and launch a wireless network on your Ethernet cable. I know this is awesome, but it will likely not work. Set it to your equivalent of wlan0.
  • Ssid=<AwesomeName> fixes the name of your network that you are to host. Make it something awesome and attractive such as KillerRhinoceros. References to cats or Internet memes are also acceptable.
  • Hw_mode=g relates to the mode that your Wi-Fi card will operate in. We're going to leave this as g, denoting 54 Mbps among other things. Leave it as g.
  • Channel=<channel> specifies the channel on which the access point will operate. Pick one that isn't being used much in your area.
  • Macaddr_acl=0 sets rules about Mac address filtering. The value 0 says accept all except those explicitly denied.
  • Auth_algs=1 sets the authorization algorithm. The value 2 allows shared key authentication. The value 1 only accepts open system authentication.
  • Wpa=2 dictates which WPA modes are allowed. 1 allows WPA, 2 allows WPA-2, and 3 allows both. We pick 2.
  • Wpa_passphrase= <Passphrase> sets the password that users have to provide to connect to your network. Make it something that's not easy to guess or easily brute-forced; otherwise, what's the point?
  • Wpa_key_mgmt=WPA-PSK sets the handshake method to WPA-PSK, which is the one we want to learn how to crack.
  • Rsn_pairwise=CCMP sets the encryption method that has to be used by the WPA-2 secured traffic.

As done earlier, we need to handle traffic and pass it on to the correct interface providing Internet connections. We can steal the iptables from the previous scenario. Take a look at the following commands:

ifconfig at0 up ifconfig at0 netmask route add –net netmask gw iptables –P FORWARD ACCEPT iptables –t nat –A POSTROUTING –o wlan0 –j MASQUERADE echo '1' /opt/proc/sys/net/ipv4/ip_foward

Again, we don't actually need the network to handle multiple connections as the challenge is in capturing and cracking the key, not joining the network. To this end, IP addresses can be set manually, not requiring DHCP. If you do require DHCP, there is a sample configuration file in the second exploit guide for the next scenario.

Once the network is set up, we just need to connect a device to it. For this challenge, we don't even need to set up dummy traffic as the key is the handshake, not the data. What you require is a device that will automatically reconnect when disconnected. Most devices should do this, so there's no need to mess around with the code.

Perform a test run by connecting the device to the network and then restarting the wireless network. If the device automatically reconnects, you're set.

This is a really simple setup for a good test for your testers.

Scenario 3 – pick up the phone

In this section, we are going to create several devices probing for Wi-Fi networks that will allow individuals to test their ability to identify phone ownership or details without touching the phone. The setup from this scenario can be used in three different ways, so there are three exploit guides for this scenario.

Remember when I said that that the -e operator was important in the WEP setup; this is why.


I like to use phones for this, but you can use different devices: laptops, PCs, toasters—anything with a wireless interface. Basically, the premise of this exercise is to prepopulate multiple devices with probe request profiles. Basically, when Wi-Fi is turned on, on any device, it probes out for networks that it has previously connected to. As a professional malicious user, you can listen to these and make judgments about people. Judging people is fun!

So, in order to populate the phones with the networks, we need to create them. So, we go back off to airbase-ng and start setting up networks.

If you're using a PC or laptop, this is actually way easier. Just browse to the wireless network configuration menu and add values to the remembered networks list.

We can use the setup from the previous scenario, except this time, we just cycle through the names that we want and get the phone to connect to them. The string (in case you forgot) was airbase-ng -c 6 -e <network name>. You can even script this pretty easily with a for loop and a list of SSIDs.

Are you stuck for network names? Here's the interesting part that makes it worthwhile: go to https://wigle.net/ and look up some interesting places. I can recommend Siberia, Mongolia, and North Korea. Why? You need to find unique SSIDs in easy places to distinguish. When you fix SSIDs from Australia and Japan in the memory of the devices, it's easy to tell them apart.

Important things to remember

  • Make sure the SSIDs are unique to a location or country. Try Shinjuku-Street-Cafe or those with Cyrillic in their names. It's unlikely that there'll be more than one. It does make it a lot easier for the attacker however, so bear in the mind the difficulty of what you're setting.
  • Make sure the devices are distinguishable from their Mac addresses. If you're using phones, use phones with separate manufacturers. That way, when the Mac address lookup is performed, the attacker knows which one is which. If you have three iPhone 5Cs, the attacker will struggle even if they're all different colors. Mac addresses care not for your fashion choices.
  • Check that your own phone is off before you set this challenge. I have performed this demo to groups of business people, and I make this statement every time, and yet time and time again, the room is treated to a potted SSID history of someone in the room. It's all fun and games until your colleagues find out where you were this weekend.

Exploitation guides

The following are the exploitation guides for the scenarios created in this article. These are guidelines, and there are more ways to exploit the vulnerabilities.

Scenario 1 – rescue the WEP key

The brief provided for this exploitation guide is assumed to be: Crack the WEP network and recover the WEP key. Perform the following steps:

  1. This is reasonably straightforward. First, we need to record traffic in the area. We use airodump-ng to do this with the following command line:

    Airodump-ng <interface> -w <output prefix> --bssid <MAC> -c <channel> --ivs

    • <Interface> is the active interface to record on.
    • <output prefix> is what the output will be called.
    • <MAC> is the Mac address of the router you wish to target.
    • <channel> is the channel that the target network is operating on.
    • --ivs tells airodump to only record IVs. For this, my command will be as follows:

      Airodump mon0 -w Scenario1 –bssid 00:45:A4:21:17:D3 –c 11 --ivs

  2. We need to leave this for a while until roughly 9,000 IVs are recorded.
  3. Once we have all of our IVs, we then use Aircrack to attempt to break the encryption. The command for this is as follows:

    Aircrack –a 1 –b <MAC> -n <WEP Key Length><input file>

    • <MAC> is the Mac of the network we are attacking.
    • <WEP Key Length> may have been identified earlier, but if not, remove –n.
    • <input file> is the file collected earlier which should have the suffix .ivs. For this exercise, my command is as follows:

      Aircrack –a 1 –b 00:45:A4:21:17:D3 –n 64 Scenario1.ivs

  4. Aircrack will then go through the files and eventually, provided the stars align, pull out the WEP key.

Scenario 2 – potentiating partial passwords

The brief provided for this exploitation guide is assumed to be: Successfully gain access to the network blah. Sources indicate that the password for blah in other office locations was NotAnEasyPassword492. Perform the following steps for this scenario:

  1. The first thing we do is look for networks. We can use airodump-ng and look at the current networks with clients connected to them. I can see blah with a client connected, which is great because that's our target. Funny, that.
  2. The next step is to capture a handshake. We can point airodump-ng specifically at blah and monitor only those connections that communicate with blah. Now we could wait until this client reconnects or for another client to come along and connect. Alternatively, we could be belligerent and force the connected client off the network and make them reconnect. Let's get angry. The tool we use for this process is:

    aireplay-ng --deauth 5 -a <AP MAC> -c <Client MAC>

    • --deauth 5 is the number of deauth packets you want to send. 5 is sort of low, but I didn't want to put a silly number in there like one thousand just in case you got the wrong idea, though one thousand is actually a pretty good number.
    • <AP MAC> is the Mac address of the access point hosting the Wi-Fi network you want to attack.
    • <Client MAC> is the Mac address of a client currently connected to the network that you want to disconnect.
  3. If we return to our airodump-ng, we should be able to see that the handshake has occurred as the client has disconnected and reconnected. It isn't 100 percent certain that this will happen, but I'm fairly sure it will.

    We have a handshake, what next?

  4. The handshake needs to be decrypted, which we can achieve with another tool of Airsuite, aircrack-ng. The following command will do it with a word list:

    aircrack-ng --bssid <MAC> -w <password list><input file>

  5. However, the brief suggests that the password NotAnEasyPassword492 was used. Perhaps that indicates that there's a faster method. We can use crunch to generate bespoke word lists for use in these types of situations.

    crunch 20 20 -t NotAnEasyPassword%%%

  6. This will generate 20 character strings containing the phrase NotAnEasyPassword followed by three numbers.
  7. And then, we use the two together as follows:

    Crunch 20 20 –t NotAnEasyPassword%%% | aircrack-ng --bssid <MAC> -w- <input file>

Leave this to run; it should go fairly quickly. At the end of it, it will give you the Wi-Fi password. We connect to the Wi-Fi and we win.

Scenario 3.1 – be a geodude with geotagging

The brief provided for this exploitation guide is assumed to be: Identify the phone that has been in the following cities: Quebec, Beijing, and London. Perform the following steps for this scenario:

  1. We can inspect the devices to start with. Let's say we have a Nexus 4, an iPhone 5, and a Samsung S4. That tells us the following two things:
    • All three of these devices are smartphones and are capable of connecting to Wi-Fi networks
    • They all have distinctly different Mac addresses due to being made by three separate manufacturers (Google, Apple, and Samsung respectively)
  2. The most sensible plan of action here is to set up a monitoring device and see whether those devices are currently looking for wireless networks. We can use an all-in-one solution here (such as Snoopy, https://github.com/sensepost/Snoopy, or iSniff, https://github.com/hubert3/iSniff), but for educational purposes, we will do it manually.
  3. We need to put a wireless card in monitoring mode. We can achieve this on Kali Linux with sudo airbase-ng wlan0 start. The wireless adapter is represented by wlan0, so if your wireless adapter is not wlan0, replace it with the correct adapter reference.
  4. This will create the new monitoring adapter mon0. It is now listening to everything on the air in the nearby area. We need to refine that into a readable form. We can use tshark -i mon0 to view the traffic, but it might be a little difficult to read. There are operators we can use to make it more readable.
  5. However, it makes more sense to use the aircrack suite's tool designed for this purpose, airodump-ng. If we run airodump-ng -i mon0, we will see the currently probing devices in the area. Provided you've set this up correctly with minimal interference, you should see the three devices previously set up.
  6. The next step is to geolocate the SSIDs. Wigle.net is a fantastic resource for this. We have our lists of SSIDs split by device, so we can go through them one by one by comparing them against the Wigle database at www.wigle.net. Take a look at the following screenshot:

  7. It appears that the device with the Mac address <MAC> has been to all the cities. So which phone is it?
  8. The next step is to identify which device is which. You can retrieve a list of manufacturer Mac addresses from http://www.coffer.com/mac_find/. Let's check the first four digits of the Mac (indicating manufacturer) against the list. Lo and behold, it's the Apple device. Point to the Apple device and be smug in your knowledge.


This article contains projects targeting Wi-Fi-enabled devices, including a section specifically targeting portable devices such as tablets and smartphones.

Resources for Article:

Further resources on this subject:

You've been reading an excerpt of:

Kali Linux CTF Blueprints

Explore Title