By default wireless interfaces are configured to only listen for traffic destined for them (either directly or broadcast). However, on many wireless cards, you can enable "monitor mode" to turn them into passive listening devices that will show all wireless traffic on the frequency (aka channel) they are tuned to.

Enabling Monitor Mode with iw

You can check what mode (called the type) your device is in with the command: iw dev wlan0 info

You should see a line saying: type managed This means your device is currently configured to behave like a normal wireless device, and is not in monitor mode.

You can put the device into monitor mode with the command: iw dev wlan0 set type monitor

And check that it was successfull, by rerunning: iw dev wlan0 info and noticing a line saying: type monitor

You could switch back to managed mode with iw dev wlan0 set type managed but hold off on that for now.

Enabling Monitor Mode with airmon-ng

The aircrack-ng suite also has a tool for turning monitor mode on and off called airmon-ng. You can see a list of wireless devices with the command: airmon-ng

Since we already had wlan0 in monitor mode, let's use airmon-ng to switch it back to managed mode: airmon-ng stop wlan0

We can re-enable monitor mode with: airmon-ng start wlan0

When you run this, you'll see output similar to: (monitor mode enabled on mon0) This indicates that it has created a duplicate device of wlan0 called mon0. mon0 is in monitor mode and wlan0 is in managed mode. This can be confusing, and isn't consistent across platforms. Depending on your Linux version airmon-ng might rename your device e.g. wlan0 becomes wlan0mon, or create a duplicate device. Remember, it's still the same hardware, so don't try use wlan0 to connect to a network then wonder why your monitor mode isn't working well.

airmon-ng has a slew of other features. More information on airmon is avilable from the aircrack-ng wiki for airmon-ng

Next Step

To proceed to the next step, you should have at least one wireless interface set to monitor mode.

Great, you should now be able to start listening to and capturing traffic.

airodump-ng

To do this, we're going to use a tool called airodump-ng also from the aircrack-ng suite of tools.

You can see what's happening nearby by simply running airodump-ng and giving it the name of the wireless interface you put into monitor mode e.g.: airodump-ng mon0

The Interface Explained

airodump-ng's interface can be confusing at first, let's take a moment to go throught it. The screen is broken into three sections.

• the top line consists of:

  • Your frequency aka channel, displayed as CH 1
  • How long you've been capturing for
  • The current date and time
  • If a WPA/2 handshake has been seen/captured and for which AP

• the middle section lists nearby access points and consists of the following columns:

  • the unique hardware address of the access point (BSSID)
  • the signal strength of the last recieved frame
  • the number of beacons frames (used to sychronise a network) seen
  • the number of data frames
  • the data rate, expressed in data frames per second
  • the frequency of the network as a channel
  • the maximum rate MB
  • whether the network is encrypted or not and what kind OPN is no encryption
  • the type of encryption aka cipher
  • the type of authentication e.g. pre-shared key (PSK) or EAP (MGT)
  • the name of the network the AP belongs to i.e. it's SSID

• the bottom section lists nearby clients (aka stations) and consists of the following columns:

  • the AP the station is associated to (as a BSSID) or (not associated) if none
  • the MAC address of the stations
  • the signal strength of the station
  • the last data rate from the AP to STA and STA to AP respectivley
  • are we missing frames from the client and how many
  • how many frames have we seen from the client
  • what network names have we seen the client probe for

This and much more is explained in greater detail on the aircrack-ng wiki for airodump-ng.

You should be seeing some wireless activity. As you're using a virtualised cloud environment, and there isn't really a physical wireless device, the wifi activity you're seeing is simulated using a technique developed by SensePost.

Look for a network named Coherer and make a note of what channel it is on.

Zooming In On A Network

Wireless networks can run on one or more of several frequencies. These are defined as channels. 2.4GHz WiFi networks run on channels 1-14 and 5GHz WiFi networks run on channels 36-64 and 100-165. These channels have different restrictions in different countries. We're just looking at 2.4GHz for now. By default your wifi card can listen to approximately 3 channels at a time, the channel it's on, and one above and below that channel. e.g. if you're on channel 6 you will see some activity from channels 5 and 7.

However, as WiFi networks can be on one of many channels, by default airodump-ng will hop between channels. You'll notice this happening based on the changing number in the top left of your screen when running airodump-ng. This has the down side, that we may miss some activity that occurs while we're not listening to a specific channel.

Since we know what network we want to focus on, and what channel it's on (1), let's exit airodump-ng by pressing Ctrl+c and configure it for this.

We're going to pass two switches to airodump-ng the first -c 1 will tell it to listen only on channel 1, and the second -w prac will tell it to capture the observed traffic to a file called prac-01.cap (with the 01 getting incremented each time you rerun the command). Let's do that now: airodump-ng -c1 -wprac mon0

Time to Wait

Now we need to wait until we see a WPA/2 handshake. These happen when a station associates to a network. In a busy network this will happen naturally and people connect to the network. However, in some cases you may need to forcefully "deauthenticate" a user to capture a handshake when they reconnect. This is not covered here, but is detailed under the aircrack-ng wiki on deauthentication attacks.

You'll know you've captured at least one handshake, when you see the interface display WPA Handshake: 00:0C:41:82:B2:55 in the top right of your screen. You'll need to have captured a handshake before you can move to the next step.

Great, you've captured a handshake, now it's time to try crack the password.

Some Theory

WPA2 makes use of a four-way handshake to negotiate a set of shared secret keys, without sending any of them over the air to be intercepted by an attacker.

There's a lot that happens in the four way handshake, you can read about the detail in the CWSP study guide if you want more information. But essentially, you need a minimum of the first two messages in the handshake, but ideally at least the first three, giving you:

• The random data from the access point (anonce) contained in message one
• The random data from the client (snonce) contained in message two
• The hash of the random data from the client contained in message two (MIC)
• (Optional) The hash of the message sent back from the access point in message three (MIC)

The reason the fourth part is optional, is because with just the MIC from the client, we have enough to try to brute force the password. However, if the client attempted the wrong password, the MIC could be wrong. By seeing message 3, we know the client had the right message and can be sure we aren't wasting our time brute forcing.

Checking For A Handshake

In the next step, we'll dive into the actual packets, but for now, the easiest way to check if you have enough to crack a handshake, is to make use of the aircrack-ng tool.

Make sure you've exited from airodump-ng with Ctrl+c before you do this next part.

The simplest way to check if you have enough of a handshake to attempt cracking is just to run aircrack-ng across all your capture files. If you type ls you should see one of more files ending with the extension .cap. If you ran the previous step as I suggested, you should see:

prac-01.cap  prac-01.csv  prac-01.kismet.csv  prac-01.kismet.netxml

airodump-ng generates several files by default when you specify the -w switch. We want to look at the packet capture file prac-01.cap. Just to be safe, I'm going to suggest you look at all .cap files with: aircrack-ng *.cap

You should see something similar to this:

Opening prac-01.cap
Read 457 packets.

   #  BSSID              ESSID                     Encryption

   1  00:0C:41:82:B2:55  Coherer                   WPA (1 handshake)
   2  98:D3:04:64:FA:55  Foo                       WPA (0 handshake)

Index number of target network ?

It looks like we do have a handshake captured for the Coherer network and can proceed. Hit Ctrl+c to exit.

Cracking The Password

To crack the password, we need to brute force it, by completing the same cryptographic steps the access point and client would have, but with different passwords. The IEEE thought of this attack, and so it's typically a slow process, which is why tools like hashcat can make it a bit faster using your GPU. It's also why you should make sure you WPA/2 passwords are complex and unique (a sentence with spaces can be easy to remember).

To crack the password, we'll need a wordlist. As WPA/2 passwords need to be between 8-64 characters, make sure your wordlist doesn't include passwords less than 8 characters.

I've provided one for you at /usr/share/dict/wordlist. You can use it by passing aircrack-ng the -w /usr/share/dict/wordlist switch like this: aircrack-ng -w /usr/share/dict/wordlist *.cap

When prompted press the number corresponding to the Coherer network, and wait for aircrack-ng to finish cracking the key. You'll know you found it when you see: KEY FOUND! [ thepassword ] on your screen. Note "thepassword" is just an example here.

Next Step

Were you able to get the password? If so, write it to a file called password to proceed to the next step. For example: echo thepassword > password

You'll need to change thepassword in that command to the actual password you retrieved.

We can capture wifi traffic and crack handshakes, but if you want to "learn the trade and not the trick" it's good to understand what the traffic looks like.

The defacto tool for doing this is wireshark however, as we don't have access to a GUI in this tutorial, we're going to use a wireshark-like web application called cloudshark as well as wireshark's command line client tshark.

Cloudshark

You'll notice a tab above your terminal to the right of the Terminal tab called Cloudshark. Click on it and you'll be taken to a graphical view of your captured packets (it may take a few seconds to appear, if it doesn't load, click the blue Display Port button). Alternativley, you can access it directly here.

The view is broken into four layers:

• The top layer is where you can specify display filters or invoke other analysis tools
• The second layer gives you a scrollable/clickable list of all the frames you captured
• The third is a tree view of each layer of the individual frame highlighted, which can be expanded to show and interpretation of what it contains
• The last layer is the raw bytes in the frame

Filtering In Cloudshark

In the previous step, we used the captured handshake messages to crack the password. Let's filter in on the handshake. This can be done by typing eapol into the text box at the top left of the Cloudshark screen where it says Start typing a Display Filter. When you're done, hit Enter or click Apply. Or you can click on this link to have it done for you.

You should see four frames with (Message x of 4) under the Info column. These are the four messages that make up the four-way handshake discussed in the previous step. Spend some time looking at what the frame is made up on in the third layer (you may need to drag the layers divider up to give you more space for viewing the detail).

We can also look at WiFi management frames to see devices attempting to connect to an access point. In particular, let's look for Probe Requests for a device looking for a named network. This makes use of a more complicated display filter wlan.fc.type_subtype == 0x04. The 0x04 says we're looking for a Probe Request. 0x08 would be a Beacon frame. Type in the new filter and click Apply or follow this link.

The first frame (No. 58) is from an Apple device, and set to all listening access points (aka Broadcast). Click on it, then click on the arrow next to IEEE 802.11 wireless LAN in the third frame to expand it. Next click on the arrow next to Tagged parameters (25 bytes) and next to the label Tag: SSID parameter set: you'll see that the probed for SSID was Coherer.

Doing The Same With tshark

Let's switch back to our terminal, and repeat the above steps using tshark the command line interface for wireshark.

You can tell tshark to look at your capture file by passing it to the -r switch e.g.: tshark -r prac-01.cap

If you named your capture file something else, make sure to change the file name in the above command.

You'll see tshark dump a summary of all the frames in that capture.

Now, let's filter in the same way we did with cloudshark. First, for eapol frames, with: tshark -r prac-01.cap 'eapol'

Easy, right?

We can also filter for Probe Requests like we did with cloudshark with: tshark -r prac-01.cap 'wlan.fc.type_subtype == 0x04'

You can look up other display filters at wireshark's Display Filter Reference.

Displaying Specific Fields

tshark can let you choose what to display about each frame. This is done using the -T fields switch, and specifying each field you want included in the output with -e switches. For example, wlan.sa is the MAC address of the device that sent a wireless frame. If we wanted to show just the sending address, we would do it like this: tshark -r prac-01.cap -T fields -e wlan.sa

And if we wanted to add our filter in, just put it on the end as before: tshark -r prac-01.cap -T fields -e wlan.sa 'eapol'

We can also add in more fields, for example, the SSID field is wlan.ssid if we wanted to show the sending address of SSID probed for, of all Probe Requests, it would be: tshark -r prac-01.cap -T fields -e wlan.sa -e wlan.ssid 'wlan.fc.type_subtype == 0x04'

Phew.

Capturing Live Packets With tshark

Up till now, we've been examining the packet capture generated by airodump-ng. But tshark can also capture frames for us. We do this by replacing the -r prac-10.cap with -i mon0. We also need to tell tshark to use display filters as a capture filter with the -Y switch. For example, if we just wanted to see the SSIDs of Probe Requests, we would do: tshark -i mon0 -T fields -e wlan.ssid -Y 'wlan.ssid != foo'

You can stop a live capture with Ctrl+c.

Next Step

Using what you've learned, can you find the SSID of at least one network other than Coherer? Write it to a file called ssid like this: echo thessid > ssid

Note thessid above is merely an example, you'll need to replace it with what you found.