Welcome!
Understanding Monitor Mode
This scenario will teach you how to put a wireless adapter into monitor mode, capture and interpret traffic, and crack a WPA2 handshake.
The basic environment is set up and ready to go, but you'll need to follow the steps to get it working. You will even need to install the required packages to get a feel for what it would be like doing it on your own computer.
Recommended background music: The Glitch Mob - Drink The Sea spotify, apple music, google play
Congratulations!
You've completed the scenario!
Scenario Rating
Thanks for playing.
In this course, I tried to show you how to put a wireless device into monitor mode, capture nearby wifi traffic, crack WPA handshakes and analyse wifi packet captures. I hope you learned something.
If you liked the course, please let me know either on Twitter @singe or via e-mail to encourage me to create more, make corrections, or try out your new idea :)
I maintain a list of wifi hacking tools at w1f1.net and my company, SensePost has been running commercial training on all sorts of hacking topics, including wifi, at places like BlackHat for years. Please Contact Us if you'd like to attend one of our training or run one at your company.
Your environment is currently being packaged as a Docker container and the download will begin shortly. To run the image locally, once Docker has been installed, use the commands
cat scrapbook_singe_monitor-mode_container.tar | docker load
docker run -it /singe_monitor-mode:
Oops!! Sorry, it looks like this scenario doesn't currently support downloads. We'll fix that shortly.

Steps
Understanding Monitor Mode
Get Setup
In this training, your course notes are on the left, and your terminal, where you can type commands is on the right. You'll see some commands listed in the training material, if you click on the
button, it will get automatically typed and executed for you. But I'd recommend you type it out as practise if you're new to this.
Explore The Environment
The environment has a (virtual) wifi card already plugged in. You can see all network interfaces by running ip link show
.
There you will see wlan0
listed as an adapter.
Alternativley, you can run iw dev
to just list wireless network interfaces.
Since we're going to be doing some wifi hacking, we'll need the aircrack-ng suite
. You can install this by running apt-get install -y aircrack-ng
. You'll need to do this to progress to the next step.
Next Step
Make sure you've installed aircrack-ng
to progress to the next step.
Enable Monitor Mode
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.
Capture Traffic
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
- Your frequency aka channel, displayed as
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.
Crack The Password
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+
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.
The password is Induction
. You can write it to a file with the command:
echo Induction > password
Analyze Traffic
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.
The other SSID is linksys
. You can find it with the command:
tshark -i mon0 -T fields -e wlan.ssid -Y 'wlan.ssid != Coherer'
You can write it to the ssid
file with:
echo linksys > ssid