Snoopy’s core functionality was to observe probe requests for remembered networks from wireless clients, although it ended up doing much more.

The problem tools like Snoopy face, is that they can’t monitor the whole 2.4Ghz wireless spectrum for probe requests, without the use of multiple wireless cards. So they channel hop to make sure they see probes on multiple channels. In the 2.4Ghz range this wasn’t terrible, because the channels overlap, which means you didn’t have to tune in to all 11 or 14 (depending on location) channels individually to see probes across the spectrum. So while you may have missed a few probe requests, you didn’ t miss many.

However, with the introduction of the 5Ghz spectrum, you now have an additional 24 non-overlapping channels to monitor. This means that in order to monitor for probe requests across both 2.4Ghz and 5Ghz ranges, there is a high chance that some probes will be made while your transceiver isn’t listening to that frequency, and won’t be recorded.

Wireless clients have a similar problem. They need to quickly find nearby APs and can’t monitor the whole spectrum. Through a combination of, usually proprietary, active and passive scanning techniques, they will be “attracted” to channels with APs on and send their probes there. So we can make use of an AP and have the clients come to us, rather than us looking for them. Additionally, this is already core mana functionality, as it needs to see probe requests to know what networks to impersonate.

Additionally, to make sure we’re getting as much from the PNL (preferred networks list) of the devices we’re observing as possible, mana can also pretend to be a hidden network in it’s beacons (with ignore_broadcast_ssid=1), while still responding to probe requests. This triggers iOS devices to probe for hidden networks on their PNL but still lets you impersonate non-hidden networks.

So, I added an option to hostapd-mana that will have it log station MACs, the network they’re probing for, and whether it is a locally administered (aka random) MAC. You can enable this functionality by adding the following line to your hostapd.conf:

mana_outfile=/some/file
enable_mana=1
mana_loud=0

The last two lines are enabling mana, and disabling loud mode. This is required to track individual stations. With loud mode enabled, you’ll be limited to a single entry per SSID.

Practically, the output will look something like:
00:11:22:33:44:55, FunnyNetwork, 0
That’s a CSV of station MAC, ESSID and a 1/0 flag with 1 indicating a random MAC.

The real magic is when you import this into Maltego for visualisation. You can do this using the new “Import/Export -> Import Graph from Table” function in Maltego 4. Before doing so, make sure you have the SensePost Toolset installed from the Transform Hub on the front page, otherwise you won’t have the entities we’re about to map to.

There’s a nice tutorial when you click the Import Graph from Table button, but effectively you need to configure Column 1 as a MAC Address, Column 2 as an SSID and Column 3 as a dynamic property of the MAC Address. This looks like this picture:

Doing so, will get you a graph of which devices were probing for which networks.

Next, you can map a network name to a location using wigle.net and the “Geolocate SSID (Wigle)” transform from the SensePost Toolset. You’ll need to register for an account at wigle.net and if you’re planning on doing anything more than point lookups, you may need to contact wigle to ask for an account with less API rate limiting.

The other advantage of running mana to do this, is that you can “decloak” random MACs when the device tries to join the network. For example, here we can see three devices probing for a network, two of them are random and one is a non-random Apple device. In all likelihood, we’ve “decloaked” the random MACs by the device attempting to associate to our AP. This won’t work for Windows randomisation however.

You can grab the code now from https://github.com/sensepost/hostapd-mana I haven’t rolled it into mana-toolkit yet.