Show me your SSID’s, I’ll Tell Who You Are!

Privacy, Security 33 comments

Wi-Fi

The idea of this article came from a colleague of mine. He wrote a first version of the script described below. I found it very useful and asked his permission to re-use it and to write this blog article. Thanks to him! In the mean time, during my researches, I also found that a friend, Didier Stevens, published on his blog the same kind of script but for an AirCap adapter. Mine uses any adapter capable to be switched to “monitor” mode.

All devices have Wi-Fi interfaces (laptops, tablets, mobile phones, consoles, etc) and their operating systems have features to easily manage the wireless networks you connect them to. When you connect for a first time to a new network, most users save the informations for later use (or the system stores it for you without notification). This small database will be used later by the operating system to discover which known network(s) is(are) available and automatically connect to them.

This database may contains a lot of interesting data. Some may reveal private information like your employer, your ISP, where you go to party, to eat, where you go on holidays or which security conference you attended. Why? Simply because networks are often configured with explicit names. Have a look at the screenshots below taken from a laptop running Ubuntu:

 

Ubuntu Wifi-Settings
(Click to enlarge)
Network Configuration
(Click to enlarge)

By default, when a new wireless network is configured, the flag “auto-connect” is enabled. This is the case on Ubuntu, MacOS and Windows 7. What does this mean? Each time you boot your computer or you reconfigure your Wireless card, the device will sent “Probe Request” management frame over the air. This can be compared to a message like “Hey! Network xxx are you there?“. Even if your network uses encryption, all those probes are sent in clear! In Wi-Fi technologies, they are several methods available to detect the available networks or SSIDs:

  • Beacon,
  • Probe Requests,
  • Probe Responses,
  • Association Requests,
  • Reassociation Requests

“Probe Requests” are very interesting to be captured to detect the SSID’s already configured and used by people. To achieve this, we just need a BackTrack 5, a Wi-Fi network card that supports monitoring mode and some tools. To collect “Probe Requests“, just use the following commands:

  # iwconfig wlan0 mode monitor
  # iwconfig wlan0 channel <i>
  # tshark -i wlan0 subtype probereq

It’s easy but not very convenient! If you keep tshark running a few hours, you could miss data. The purpose of the script is to automate this process and keep some statistics about the detected probe requests (clients MAC addresses and SSID’s). It’s also important to scan all the available channels (1-14) to grab as much SSID’s as possible. This is called “channel hopping” and to achieve this, the script starts a child process which changes the Wi-Fi channel every 5 seconds within an infinite loop. The script syntax is the following:

  Usage: ./hoover.pl --interface=wlan0 [--help] [--verbose] [--iwconfig-path=/sbin/iwconfig]
                    [--ipconfig-path=/sbin/ifconfig]
                    [--dumpfile=result.txt]
  Where:
  --interface     : Specify the wireless interface to use
  --help          : This help
  --verbose       : Verbose output to STDOUT
  --ifconfig-path : Path to your ifconfig binary
  --iwconfig-path : Path to your iwconfig binary
  --tshark-path   : Path to your tshark binary
  --dumpfile      : Save found SSID's/MAC addresses in a flat file (SIGUSR1)

It will dump all detected SSID’s to the console in a completely passive way. No packets are sent over the air from the scanning host! When you kill the script or wake it up via a SIGUSR1 signal, it will dump all detected SSID’s, MAC addresses, packets count and the last time if was seen. The example below shows the result of one day of scan in my neighborhood. 40 SSID’s detected in my area is not bad (I’m leaving in the countryside).

 !! Dumping detected networks:
 !! MAC Address          SSID                           Count      Last Seen
 !! -------------------- ------------------------------ ---------- -------------------
 !! 7E-62-89-9E-C4-E4    Billi-Wifi                             43 2012/01/10 22:15:36
 !! 07-46-6E-4F-61-4E    Réseau de ******                     2732 2012/01/11 16:28:09
 !! 6F-B6-11-2E-AF-74    LA HAGOULLE                             1 2012/01/11 16:17:08
 !! 8F-9F-B1-5B-73-C8    Go-Away-Lamerz                         85 2012/01/11 16:28:09
 !! 00-ED-E1-3A-A9-1C    wifi94                                  6 2012/01/10 18:25:27
 !! E1-28-7F-6A-C6-44    3cles                                   1 2012/01/11 16:17:08
 !! 4E-CD-8A-BD-1C-EB    NOW-X-54                               10 2012/01/10 20:08:02
 !! 0B-8C-A1-1C-BB-51    CRAPS                                5598 2012/01/11 16:28:09
 !! 91-4A-F0-42-A6-63    bbox2-****                              1 2012/01/11 10:48:49
 !! 0B-A7-51-ED-E1-FA    SpeedTouchD4288C                        2 2012/01/11 16:17:08
 !! C09-C2-23-89-2D-E9   ISFS                                    4 2012/01/10 18:12:25
 !! CE-7C-B6-58-39-D3    HAYEZ                                   1 2012/01/11 10:48:49
 !! 44-45-60-E6-61-1B    Guest                                   1 2012/01/11 16:17:08
 !! 0B-A7-51-ED-E1-FA    bbox2-****                              8 2012/01/11 16:15:11
 !! 09-C2-23-89-2D-E9    biblio                                  1 2012/01/11 10:48:49
 !! CE-7C-B6-58-39-D3    free-hotspot.com                        2 2012/01/11 16:17:08
 !! 37-F3-65-28-35-0C    123EURO                                 1 2012/01/11 16:17:08
 !! E4-8F-02-9B-E8-3C    FREE_DELIRIUM                           1 2012/01/11 10:48:49
 !! 6E-2C-81-CE-13-E3    bbox2-****                              4 2012/01/10 18:25:27
 !! E9-4A-D6-4F-72-0C    chateau_magique                         1 2012/01/11 16:19:07
 !! A4-B4-B3-FC-B0-75    WiFi_FD                                 1 2012/01/11 16:17:08
 !! E3-9E-A3-9F-A1-F7    TP-LINK_******                        519 2012/01/11 16:10:51
 !! DA-6C-E2-D8-D8-A7    bbox2-****                              6 2012/01/10 18:25:27
 !! 03-94-41-21-6C-C2    bbox2-****                              3 2012/01/10 18:25:27
 !! 27-E3-1F-61-5A-69    linksys-n                               1 2012/01/11 10:48:49
 !! 81-8A-48-1B-DF-20    Philips WiFi                            1 2012/01/11 10:48:49
 !! 55-C3-BE-F9-63-60    SpeedTouch******                        1 2012/01/11 16:17:08
 !! F0-3D-CC-D3-16-A4    blanmont                               27 2012/01/11 16:28:09
 !! 7A-19-39-BC-3B-A6    chouchou                                1 2012/01/11 10:48:49
 !! 7E-62-89-9E-C4-E4    belgacom                                1 2012/01/11 10:48:49
 !! 07-46-6E-4F-61-4E    Réseau UAH                              4 2012/01/10 18:25:27
 !! 6F-B6-11-2E-AF-74    dlink                                   5 2012/01/11 10:48:49
 !! 8F-9F-B1-5B-73-C8    sagem-****                              1 2012/01/11 16:17:08
 !! 00-ED-E1-3A-A9-1C    bbox2-****                              1 2012/01/11 10:48:49
 !! E1-28-7F-6A-C6-44    bbox2-****                              2 2012/01/11 10:48:49
 !! 4E-CD-8A-BD-1C-EB    QuickWiFi                               1 2012/01/11 16:17:08
 !! 91-4A-F0-42-A6-63    bbox2-****                              1 2012/01/11 16:17:08
 !! 81-8A-48-1B-DF-20    linksys                                14 2012/01/11 16:19:07
 !! 27-E3-1F-61-5A-69    WiFi_6E                                 1 2012/01/11 16:17:08
 !! 82-94-05-84-30-ED    Sitecom                                 1 2012/01/11 16:17:08
 !! Total unique SSID: 40

Note: the MAC addresses have been randomized using the MAC Address Generator.

That’s all for the technical part. Now that you have a list of MAC addresses and SSID’s, what can you do with them? How can this script be useful from an attacker perspective?

First, use this as a “presence detection” mechanism. You can track the presence of people in a specific area. Being at home, I could detect when my neighbor is back at home and uses his laptop. Same for companies. Behind outside, you could detect the presence of employees in the office. More your antenna is powerful more you will be able to detect activity from a long way. Then, the detected SSID’s could help you to learn a lot about your potential victim. The goal is to “put a face” on the MAC address. You can learn the type of device/ISP they use. You can learn about the habits (and later to perform social engineering). hotel SSID’s, restaurant SSID’s etc.Some people defines SSID’s with personal data: pet names, street addresses, nick names. Always interesting stuff… If you know that your victim booked an room in a specific hotel, it’s a step forward to asking him to click on a rogue document coming from this hotel. But that’s another story!

The script is available here.

33 comments

  1. In the script, the default path for tshark is /usr/local/bin/.
    You change change it with the –tshark command line switch.

  2. Hey… I know this script is getting old… but has anyone used it recently?
    I’m a bit of a noob at linux and for some reason it won’t work on any of my machines… Kali, Parrot, Ubuntu…
    I can get the tshark command to work fine and it pickes up probes… but when running the script all i get is “Cannot spawn tshark process!”
    Tried to google it but no luck so far 🙁
    help.. anyone?

  3. Thanks for the script, yet it has to be modified to be updated. As Mike indicates, in oerder to filter tshar must use the option -f . As alberto me tioned in order to get the interface in monitor mode, first is needed to get the interface down. And last but not least, if you are usin a raspberry, inorder to get the interface down, one must reconfigure the ifplugd or stop it. Thanks again!

  4. The reason many probe requests are “missing” is because the script filters out “broadcast” probes. I am not sure what the logic or reasoning behind that behavior in the script, but it should be fairly easy to modify it.

  5. Pingback: WiFi Still Remains a Good Attack Vector, (Tue, Oct 11th) « CyberSafe NV
  6. Pingback: WiFi Still Remains a Good Attack Vector, (Tue, Oct 11th) – sec.uno

  7. Nice script, but there is a bug: In line 180 “localtime($detectedSSID{$key}[2])” should be “localtime($detectedSSID{$key}[3])” to get correct “Last Seen” output.

  8. Hi there again, I followed the code and effectively there is a condition discarding all the Broadcast messages which happen to be the ones sent by the devices. Now I can see ‘some’ MACs that are broadcasting but not as many as when I run the tshark command alone. Could it be the channel hoping the problem ?

  9. Thanks Xavier for the code and the post.
    I observed the same issue. when I run the script I only see the requests coming from the Access Points around and not the devices like phones. Is that a filter in the code ? Thanks !!

  10. Xavier, it works nice! I implemented suggestions from Alberto and Mike (many thanks for sharing), however i’m not getting the SSID probe requests from my mobile phones. On my phone I disabled the wifi then re-enabled it, no luck… switching to different wifi ssid, no luck.
    So i never get the SSID’s from my phone, however i do get the probe requests.
    But i did get some other SSID probes from different devices (neighbors/passerby’s?) so what’s the difference?

    Trying with raspberry pi connected to ethernet for network access+control & modmypi wifi dongle.
    Thank you

  11. very interesting – i may have figured it out – I don’t know if its because of debian or the tshark version I am using but if I want to say “tshark -i wlan0 subtype probereq” I need to do it like this: “tshark -i wlan0 -f ‘subtype probe-req'” – I am not sure if that is just me or if maybe that should be a fix that everyone using this script needs.

  12. I would love to but I am unfortunately not very experienced with Perl. I think the problem is the tshark command being used to try to filter the probe requests. That command may be depreciated in this version of tshark (or I need to install something else for pcap filtering to work – I wish I knew more – would love it if someone could figure it out!

  13. Honestly, the script is quite old. I should have a look… If you have suggestions or patches, feel free to submit!

  14. Very much appreciate your time and effort on this! However, I am not sure if this script still works correctly. The parent process dies for me rather quickly, however 1 child process continues to run. I am trying to run the latest version of this script on a new install of debian jessie with tshark version 1.12.1 – any help would be much appreciated!

  15. Monkey: I guess you are running this script from a RPi or similiar with no realtime clock on board. This means the system clock is set on boot to unix start time which corresponds with 1970/1/1 00:00:00. You need to set the time somehow. Maybe by DHCP or connect a RTC.

  16. Heya,

    Great bit of code but the dates come up wrong and I’m not sure how to fix it. When it dumps the list all the dates are 1970/01/01 01:0x:xx.

    Also, is there a way to change the code to get it to change wireless channels more frequently like airodump-ng does?

    Thank You

  17. Hi Xavier, thank you for your reply… yes old but still better than other script for this purpose. Meanwhile I’m waiting for answer to my previus post I want to report another problem that I fixed by myself. Starting the script iwconfig give error “interface busy”… so I’ve modded a line to put iface down before iwconfig command:
    (system(“$ifconfigPath $interface down”)) && ……………
    (system(“$iwconfigPath $interface mode monitor”)) …………..
    (system(“$ifconfigPath $interface up”)) && …………………
    Take your time and thank you.

  18. Hi Alberto,
    You’re the 1st to report this. I don’t if it’s a bug or a feature. The script is quite old, let me some time to take a look at it.

    /x

  19. Hello, first off, thanks for this script. I want to report that wen I run the script and 2 or more devices (different MAC) send probes to the same AP only one device it’s reported in the final table, usually the last device seen. It’s my problem only? Or there is chance to mod the script in a way that it report all MAC that send probes to a single AP? Thank in advance and sorry for my bad English.

  20. Thanks Xavier I fixed before and also I realize that since 2013 (I believe) tshark is only part of Wireshark package and a lots of people having trouble with their codes.

  21. Do you have tshark installed? By default, hoover.pl looks for it in /usr/local/bin/.
    You can specify your tshark path via the command line:
    –tshark-path=

    PS: There was indeed a typo in the code, I fixed it 🙂

  22. hoover.pl is giving me a tshark tool not available!! I fix the path but it seems that something is wrong with code cause by hand command starts. Please I need your help cause this is exactly what I was looking for it!!! Using Kali Linux on raspberry pi 2

  23. Hello , I’ve had my Xbox one stolen but I have the box,so I have all the serial numbers including SSID, I’ve contacted the police but they’ve been no help , can you track the console with the SSID?

  24. I’ve been comparing the output of hoover.pl and wifiscan.py (discussed here http://edwardkeeble.com/2014/02/passive-wifi-tracking/) and notice a difference, although running at the same time. Hoping someone might know whats going on with the probe request capture.
    With hoover.pl, there are always ssid’s reported in the output. example (i customed the output, and modified the MACs and SSIDs for this post):
    ++, Thu Sep 25 09:43:01 201x, New probe request from, ‘MAC#1’ with SSID, ‘SomeSSID#1’ [106]
    –, Thu Sep 25 09:43:01 201x, Probe seen before from, ‘MAC#1’, ‘SomeSSID#1’ [106]

    However, using wifiscan.py at the same time, there may or may not be an ssid reported on the output. Example:
    Probe request,201x-09-25 09:43:08.502438: Source: ‘MAC#1’ SSID: ‘SomeSSID#1’ RSSi: -66
    Probe request,201x-09-25 09:43:08.524455: Source: ‘MAC#1’ SSID: RSSi: -61

    You can see these captures are nearly the same time. They are from the same device. What’s going on here? Is the device sending out random probe requests (no SSID) and then some have the SSID included? Why? Also, I’ve captured probe requests from devices that were associated with an access point, specifically, and ipad that has the cover closed and not in current use. Why would such a device be sending a probe request if its connected (although not in use)?

    I’m interested in your thoughts or what anyone has to say.
    Best regards.

  26. Thanks for the script, but I seem to get less/slower results than tshark on its own – I think the channel hopping is working against it in my case.

    My interest is in tracking numbers of devices though, more than their SSID data, so I’m not ignoring broadcasts

  27. Hi Ronny,
    I mean that running tshark on the console is not very convenient. Of course you could send the captured packets into a pcap file but this will require further processing.

  28. you said “If you keep tshark running a few hours, you could miss data.” why would you miss the capture of data? could you further explain please?
    thanks

  29. That’s why I don’t broadcast. I know this doesn’t increase security, but I know little faggots don’t get their small head worked up about what’s written in the SSID.

  30. Pingback: Mapping my neighbourhood SSIDs | | vanimpe.euvanimpe.eu
  31. Pingback: Bookmarks for February 3rd through February 4th — Somewhere out there!

  32. Yep, it is except that my script is fully passive. It does not reply to probe requests to “attract” clients to the rogue access point.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.