Tuesday, 08 September 2015 12:15

Passive packet sniffing on Wifi connections

Written by 
Rate this item
(0 votes)

Wireshark, tcpdump, and dumpcap are packet sniffers we use to passively do some some wifi sniffing with Kali linux

We'll cover the basics and complete the captures.

This guide is specifically for Kali linux but you can use other versions of linux with minor modifications and/or manually installing some of the software tools needed.

This is the First part in a series where we use our network WiFi adapter and capture data using various methods and take the Pcap capture files and methodically pick through them and analyse the different types of useful information we can extract.  All based around Kali and Ubuntu linux computers, multiple access points, and a variety of target devices, we will use a variety of tools available today to complete our analysis of the data we find.  Usually there are multiple ways to accomplish a particular task so I try to experiment with different methods in an attempt to find the best method for the task at hand.

All of these examples shown here are using captures of traffic from my own computers and access points.

In the next part of the series, Pcap capture : Extract SSID AP names, we will see if we can extract any SSID names that we were able to capture.  This information can be useful in different ways, especially when we want to further explore more details on only a specific network.  Frst, let's capture some packets!

Here's what you'll need

  • Laptop running Kali linux
  • USB Wifi adapter which supports monitor and promiscuous modes (ALFA AWUS036H) or similar
  • An open wifi network (hopefully your own)
  • A second laptop/smart phone/tablet/etc to act as the traffic we will sniff out
  • tcpdump, dumpcap, wireshark, airodump-ng

One laptop connected to my open wifi internet connection, One Kali laptop to "see" what I could remotely monitor...

I've done my share of sniffing around, but with all of my experimentations, I've always been connected to the network (either physical or wireless).  I wanted to reliably setup a way to monitor the wifi traffic in the air around me without being associated with any networks.  The only times I have done this previously was to capture enough traffic to crack a WEP password or capture the 4 way handshake used for WPA.  I have never actually analysed and looked at what data I could possibly passively capture. 

Passively listening to the wifi traffic without being associated with any actual network is achieved by what is called monitor mode.  This is not to be confused by promiscuous mode which by definition allows your network interface to listen to all traffic within your associated network.  In theory, cards which support monitor mode should be able to hear and capture any wifi traffic in your surroundings and not just within a specified network.

My goal is to see how much of my privacy can really be taken by passively monitoring a network.  Understandably most traffic will be encrypted using tls, so easy access to passwords and such will be out of the question.  I do expect to be able to gather enough information that can be used in social engineering and ability to profile a target in detail through the captures of dns lookups, images, and overall internet habits.  Also, you can only use this information if the network is open, unless you can access the WEP/WPA password, but that's for another time.


Using Kali, all commands in the examples below were run as root (not necessary recommended) (some commands may need to be preceded with sudo in different environments)


Setting up your Wifi interfaces

The card your are using must support monitor mode.  In additional an external gain antenna of some sort can help tremendously when attempting to capture more distant traffic.  You can also set up your wireless network card by running airmon-ng, example: airmon-ng start wlan0, but I prefer to do it manually as shown below.


Kill any processes that may interfere with setting up monitor mode.  This is all I needed to do but you may also try airmon-ng check kill to assist with this task.  You can start it back up later with service network-manager start

pkill NetworkManager


Find any active wifi instances configured to use your physical interfaces.  (This will list out any active wifi instances wlan0, wlan1, mon0, etc.)


Now shutdown these instances.  Do this for every wifi interface listed.

ifconfig wlan0 down
ifconfig wlan1 down


Find your physical network interfaces (you should see a listing of phy#0, phy#1, etc for every physical wireless interface that is attached).  I have 2, one built into my laptop (phy#0) and my ALFA USB interface known as phy#2.

iw dev


Confirm your physical wifi interface supports monitor mode (you should see monitor listed as one of the "Supported interface modes")

iw phy phy2 info


Delete the wifi instance associated with your physical interface (in my case wlan1 is associated to phy2).  Since we will be creating a new monitor mode instance associated with phy2, we do not need wlan1 at this time.

iw dev wlan1 del


Create a monitor mode interface with the physical interface (mon0 on phy2)

iw phy phy2 interface add mon0 type monitor


Change the mac address on the monitor mode interface that was created (mon0) to a random address

ifconfig mon0 down
macchanger -r mon0
ifconfig mon0 up


Set the channel (frequency) you want to monitor.  You can use airodump-ng (airodump-ng mon0) to scan all of the channels available to you to find which channel the open wifi network is using.

iw dev mon0 set channel 6

 * If your capture interface support it (802.11n) you may need to set the channel spacing (HT20 | HT40+ | HT40-) after the channel, depending on the other interface capabilities and how they negotiated when they associated with the AP.  For example:

iw dev mon0 set channel 6 HT40-

further details can be found in the Troubleshooting section below.


You can verify that the interface is now on the correct channel


It should show you the Frequecy the interface is set to (in our case it is 2.437 GHz, for channel 6)

wifi channel frequency


Streamlining the capture with filters

When I started out documenting this experiment, I included a long introduction to capture filters.  I typically agree with most people on not using capture filters.  The usual reasons are if your are troubleshooting a problem,  often times during your analysis, it may lead you down a different path then you have originally planned for, and it's possible you may have filtered out some information that could of assisted you narrowing down the problem.  In my case, I did know exactly what I was looking for, I was going to start out by filtering most 802.11 control and management frames along with options of filtering out only traffic going through a specific access point.

When I did side by side comparisons capturing data both with and without capture filters, I noticed more packets being dropped when I introduced capture filters.  Using two different software tools (tcpdump and dumpcap), and playing with buffers, the biggest loss was always with when capture filters were in use.  That being said, the laptop I am using is far from ideal (it's a slightly older netbook) but never the less, I suggest to take some time before hand in your testing if you do plan on utilizing capture filters.

One of the tests that made me notice the difference is when I introduced a filter for EAPOL (ether proto 0x888e) and I continuously had a remote laptop connect and disconnect from a WPA2 access point.  With no capture filters, I had 99% success rate on capturing the 4-way authentication handshake, while I probably had around 50% success rate with the filters in place, even less using a particular software, more on that below.

As I said before, the laptop running the capture may have not been ideal, but those are my results so I will continue avoiding capture filters myself.


tcpdump vs dumpcap to capture the wifi traffic

To streamline the capture process a bit further we can use tcpdump or dumpcap.  Both are command line tools so it should be less overhead while capturing.  For serious information gathering I always like to rely on command line tools as I find them to be more flexible with the handling of data and how I want to process it.  Tcpdump is by far the more popular tool, but dumpcap is much smaller in size.  Dumpcap which is the backend to wireshark/tshark, is said to be more secure with less bugs.  Sans put out a whitepaper stating tcpdump had fewer packet drops vs dumpcap when all external variables were the same (cpu, memory, etc).

I intended in using  dumpcap along with tcpdump when I began this documentation.  I have never used dumpcap as a stand alone capture tool and wanted to give it a try.  I have to agree with the Sans whitepaper, and even on a small scale, when I did a side by side comparison of various wifi captures, with all other variables the same, tcpdump always came out ahead with the least amount of traffic lost.  I don't have any graphs or analytical data to prove this, but for my captures I will stick with tcpdump.

I will provide examples for tcpdump and dumpcap for reference, but personally my preference is to use tcpdump.  Start capturing on your monitor mode interface using one of the examples below.


Capture to a file

This will not resolve any addresses and will begin the capture on interface mon0, print on screen the number of frames captured and write to file capture.pcap.


tcpdump -nni <interface> -v -w <output-file>


dumpcap -i <interface> -P -w <output-file>


tcpdump -nni mon0 -v -w ~/capture.pcap
dumpcap -i mon0 -P -w ~/capture.pcap


Timestamp the file name

At times to better organize your captures, you may want to include variables in the file name to place the year, month, date, hour, minute, and seconds when the capture was written.


tcpdump -nni <interface> -v -w <formatted-output-file>


dumpcap -i <interface> -P -w <formatted-output-file>


tcpdump -nni mon0 -v -w ~/"capture_`date '+%Y-%m-%d_%H:%M:%S'`.pcap"
dumpcap -i mon0 -P -w ~/"capture_`date '+%Y-%m-%d_%H:%M:%S'`.pcap"


Capture to a file for a specified period of time

Examples shown will write a single capture file for 1 hour and then stop.


tcpdump -nni <interface> -G <time-in-seconds> -W <number-of-times-to-write-to-file> -v -w <formatted-output-file>


dumpcap -i <interfaace> -P -a duration:<time-in-seconds> -w <formatted-output-file>


tcpdump -nni mon0 -v -G 3600 -W 1 -w ~/"capture_`date '+%Y-%m-%d_%H:%M:%S'`.pcap"
dumpcap -i mon0 -P -a duration:3600 -w ~/"capture_`date '+%Y-%m-%d_%H:%M:%S'`.pcap"


Capture to multiple rotating files with a maximum filesize

Examples shown will write 50 capture files at 100MB each file (5GB total) and continue to rotate.  Dumpcap will append "_xxxxx_date/timestamp" to each output file name with _xxxx being the number of file written in rotation, so you can omit the manual timestamp we add through variables if preferred.  Tcpdump will append a number following the file name, beginning with 00 (ie: capture_2015-09-15_19:32:01.pcap00, capture_2015-09-15_19:32:01.pcap01, etc) but the timestamp will not change from the first file write.


tcpdump -nni <interface> -C <file-size-in-MB> -W <number-of-files-to-rotate> -v -w <formatted-output-file>


dumpcap -i <interfaace> -P -b filesize:<file-size-in-kB> -b files:<number-of-files-to-rotate> -w <output-file>


tcpdump -nni mon0 -v -C 100 -W 50 -w ~/"capture_`date '+%Y-%m-%d_%H:%M:%S'`.pcap"
dumpcap -i mon0 -P -b filesize:100000 -b files:50 -w ~/'capture_.pcap'


Capture to multiple rotating files with a maximum filesize and compress

Similar to the example above, but we will use tcpdump's postrotate option (-z) to execute a 1 line shell script.  This is unique to tcpdump so no example for dumpcap will be shown.


tcpdump -nni <interface> -C <file-size-in-MB> -W <number-of-files-to-rotate> -v -w <formatted-output-file> -z <command-to-execute>


tcpdump -nni mon0 -v -C 100 -W 50 -w ~/"capture_`date '+%Y-%m-%d_%H:%M:%S'`.pcap" -z ~/compress.sh


gzip -9 -f $1

Remember to make your script executible

chmod +x ~/compress.sh


Capture to multiple rotating files for a specified period of time

There is really no way of doing this natively with tcpdump.  You could use -G <time-in-seconds> without -W and trigger a separate script to delete the oldest capture after x amount of files.  Example shown will write 25 capture files for 1 hour each and continue rotating files.  Dumpcap will append "_xxxxx_date/timestamp" to each output file name with _xxxx being the number of file written in rotation, so you can omit the manual timestamp we add through variables if preferred.


dumpcap -i <interfaace> -P -b duration:<time-in-seconds> -b files;<number-of-files-in-rotation> -w <output-file>


dumpcap -i mon0 -P -b duration:3600 -b files:25 -w ~/'capture_.pcap' 



Once you have your interface in monitor mode, you may still not be capturing the traffic you are interested in.  You may in fact you may be only capturing control and management frames such as Beacons, Probe Requests, Probe Responses, etc but no other traffic such as HTTP, TCP, ARP.  There can be several factors that be the cause of this.  As long as

  • Your capture interface is set to the proper channel
  • You are in range to pick up the intended wifi traffic
  • The data in not encrypted (again this page and these examples only pertain to open data networks)

the most likely cause for this is the channel bandwidth and/or bit rates.  How your capture interface is setup to receive these signals plays a part and more importantly if your capture interface is even capable of receiving these signals.

  • 802.11b 2.4 GHz, channel spacing is set to 22MHz wide (typical shown as 20Mhz wide) with 11Mbps
  • 802.11g 2.4 GHz, channel spacing 22MHz with up to 54Mbps 
  • 802.11n 2.4 GHz or 5 GHz, upto 40MHz with up to 600Mbps.

If your monitor mode wifi interface card does not support the mode the other interfaces have negotiated with the AP, you will not be able to intercept the traffic.  The popular network adapter Alfa AWUS036H only will capture 802.11b/g at 20MHz, an alternative is an Alfa AWUS036NHA, which will capture channels in the 2.4 GHz range of up to 40MHz up to 150Mbps.


Analysing the packet captures

So now we have gigs and gigs of capture files, so what next.  Depending on what you are looking to sniff out, there is a huge variety of tools available to help analyse the packet captures.  Wireshark, tshark, dsniff, driftnet, urlsnarf, msgsnarg, NetworkMiner, Chaosreader, foremost, xplico, to name a few.  Some tools work better than others for specific tasks, so not one tool will always do the job.  I go into further details in my next article on processing, manipulating, and analysing the capture files.



Being associated with a network, port mirroring, or mitm attacks can deliver a lot of information on your target.  Passively monitoring the surrounding traffic, which may be limited due to encryption of certain traffic, can be very informative on your target, and in theory cannot be detected since your are only capturing what's "in the air" and not associated to any network. 

In linux, setting up an interface to listen in on monitor mode and capture wireless packets is easy with the powerful tools available today.   The examples discussed here only give us a small glimpse of what these tools can do and how to use them specifically in capturing wifi packets.  Capture filters can be dangerous as you may miss out on something you filtered before the actual capture and they may also cause some data loss in your captures, so use them wisely. 

There are debates on which tools are best for what task, but I like to look for the smallest tool for each individual task at hand.  I personally always look at wireshark first as usually I can quickly make out if I am capturing properly and get an idea if I am capturing the data that I am after.  I then switch to more specific tools such as tcpdump to continue the capture process.

While this information can be utilized in other network sniffing tasks, I wanted to attempt to keep focus on wireless capturing in general.


Next: Pcap capture : Extract SSID AP names

We will see if we can extract any SSID names that we were able to capture.  This information can be useful in different ways, especially when we want to further explore more details on only a specific network.














Read 20317 times Last modified on Tuesday, 02 February 2016 18:56
Algis Salys

Creator and owner of algissalys.com.  Linux enthusiast, electronics tinkerer, and likes to spend time in the workshop building and creating new projects.