Grey bar Blue bar
Share this:

Mon, 23 Feb 2015

Improvements in Rogue AP attacks - MANA 1/2

At Defcon 22 we presented several improvements in wifi rogue access point attacks. We entitled the talk "Manna from heaven" and released the MANA toolkit. I'll be doing two blog entries. The first will describe the improvements made at a wifi layer, and the second will cover the network credential interception stuff. If you just want the goodies, you can get them at the end of this entry for the price of scrolling down.


This work is about rogue access points, by which we mean a wireless access point that mimics real ones in an attempt to get users to connect to it. The initial work on this was done in 2004 by Dino dai Zovi and Shaun Macaulay. They realised that the way wifi devices probe for wireless networks that they've "remembered" happens without authentication, and that if a malicious access point merely responds to these directed probes, it can trick wireless clients into connecting to it. They called this a KARMA attack.

Additionally, Josh Wright and Brad Antoniewicz in 2008 worked out that if you man in the middle the EAP authentication on secured networks, you could crack that hash and gain access to the network yourself. They implemented this in freeradius-wpe (wireless pwnage edition).

However, KARMA attacks no longer work well, and we wanted to know why. Also, the WPE stuff seemed ripe for use in rogue access points rather than just for gaining access to the original network. This is what we implemented.

Changes in Probing

After a significant amount of time poring over radio captures of the ways in which various devices probed, and informed by our previous work on Snoopy, we realised two things. The first is that modern devices, particularly mobile ones, won't listen to directed probe responses for open, non-hidden networks if that AP didn't also/first respond to a broadcast probe. What this means is that our rogue access point needs to implement the same. However, the challenge is, what do we respond to the broadcast probe *with*?

To overcome that, we took the existing KARMA functionality built by Digininja, ported it to the latest version of hostapd and extended it to store a view of the "remembered networks" (aka the Preferred Network List (PNL)) for each device it sees. Then when hostapd-mana sees a broadcast probe from that device, it will respond with a directed probe response for each network hostapd-mana knows to be in that device's PNL. This is based on our finding, that wifi clients don't have a problem with a single BSSID (i.e. AP MAC address) to have several ESSIDs (aka SSID aka network name).

Practically, suppose there are two devices, one probing for a network foo, and the other probing for two networks bar and baz. When device1 sends a broadcast probe, hostapd-mana will respond with a directed probe response for foo to device1. Likewise when device2 sends a broadcast probe, hostapd-mana will respond with two directed probe responses to device 2, one for bar and one for baz. In addition, the "normal" KARMA functionality of responding to directed probes will also occur. Practically, we found this significantly improved the effectiveness of our rogue AP.

iOS and hidden networks

iOS presented an interesting challenge to us when it came to hidden networks. A hidden network is one configured not to broadcast its ESSID in either its beacons or broadcast probe response. Practically, the only way a client device can know if the hidden network it has remembered is nearby is by constantly sending out directed probes for the network. This is why hidden networks aren't a very good design, as their clients need to spew their names out all over the place. However, when observing iOS devices, while they could join a hidden network just fine, they seemed to not probe for it most of the time. This had us constructing faraday cages, checking other factors like BSSID and geolocation to no avail. Until we realised that iOS will not probe for any hidden networks in its PNL, unless there is at least one hidden network nearby. So, if you'd like to maximise your rogue'ing, make sure you have a hidden network nearby. It doesn't even need to be a real network; use a mifi, use airbase-ng or just create another hostapd network.

Limits in probing

Modern mobile devices probe for networks on their PNL *significantly* less than laptops or older devices do. In an ideal world, manufacturers would change the implementation to never probe for open network, and only wait for a response to a broadcast, effectively limiting these attacks to requiring pre-knowledge, common networks or being performed in the vicinity of the actual network. Actually, a patch was pushed to wpa_supplicant to limit the stupid probing behaviour Android does in low power mode a few months ago, this will make it into Android proper sometime soon. Also, iOS has significantly reduced how often it probes.

There are two ways to work around this. The first is manual; go for a common network. The rise of city-wide wifi projects makes this somewhat easy. Or if you're going for a corporate network, just do some recon and name one of your access points after that. But, we wanted to make things work better than that. The default behaviour of hostapd-mana is to build up a view of each devices PNL and only respond to broadcasts with networks specific to that device. However, we can remove that limitation and build a global PNL, and respond to each broadcast with every network every device has probed for. We call this loud mode, and it's configurable in the hostapd-mana config. This relies on the fact that many devices, particularly laptops and older mobile devices still probe for networks a lot. It also relies on the fact that many devices have networks in common (have they been in the same city, same airport, same conference, same company, same pocket etc.). This works *very* well in less crowded areas, and you'll get a much higher number of devices connecting.

However, in busy areas, or if your antenna is large enough, you'll quickly exceed the capacity for your average wifi device to respond fast enough to all of the devices, and as the number of response probes grows exponentially with each new device, even in quiet areas over time, this problem crops up (but didn't on stage at Defcon miraculously). So, it's *good enough* for now, but needs an in-kernel or in-firmware implementation with some network ageing to scale a bit better (one of the many opportunities for extending this work if you're up for some open source contribution).

Auto Crack 'n Add

freeradius-wpe is great, it provides a nice way to grab EAP hashes for clients that don't validate certificates presented via EAP's that implement SSL (PEAP, EAP-GTC, PEAL-TTLS). However, the patches are for freeradius v1 and, much like the KARMA patches for hostapd, have aged. But, hostapd contains a radius server, and so we could port the freeradius-wpe work to that, something we based off some initial but incomplete patches by Brad Antoniewicz. So hostapd-mana will also let you grab EAP hashes without needing another tool.

However, the KARMA attacks only work against open wifi networks. EAP networks are increasingly common (especially corporate ones) and we wanted to be able to have a go at getting devices probing for those to connect to our rogue AP. To do this, we modified hostapd-mana to always accept any EAP hash, but send it off for cracking. It simply writes these to a file, from which the simple python tool crackapd (included) will grab it and send it off to another process for cracking. Currently, we use asleap (also by Josh) and the rockyou password list, but these can all be easily modified. For example, to use CloudCracker and its incredibly optimised MS-CHAPv2 cracking setup.

The net result is pretty great for simple EAP hashes. The device will try and connect, and fail as we don't know enough to do the challenge response right. But after the hash is cracked, when it retries to connect (something a device will keep doing) it will succeed (and you'll have your first creds). For simple hashes, this is transparent to the user. Of course, very complex hashes will only work if you crack them in time. Worst case scenario, you leave with hashes.


So that's what we built into hostapd-mana. You get improved KARMA attacks, a modern hostapd version, an integrated hash stealer, and the possibility of rogue'ing some EAP networks. You can get the full toolkit at MANA toolkit on GitHub or our hostapd-mana at hostapd-mana on GitHub.

The next blog entry will cover what we did once we got a device to connect.

The Goodies

The Defcon talk:

The supporting slide deck with more information:

The final toolkit: MANA toolkit on GitHub You can also get this on Kali with "apt-get install mana-toolkit"

The modified hostapd (for hackers or people who want to build their own setup): hostapd-mana on GitHub

Sun, 17 Aug 2014

DefCon 22 - Practical Aerial Hacking & Surveillance

Hello from Las Vegas! Yesterday (ed: uh, last week, my bad) I gave a talk at DefCon 22 entitled 'Practical Aerial Hacking & Surveillance'. If you missed the talk the slides are available here. Also, I'm releasing a paper I wrote as part of the talk entitled 'Digital Terrestrial Tracking: The Future of Surveillance', click here to download it.

Whiskey shot!
Whiskey shot!

The Snoopy code is available on our GitHub account, and you can join the mailing list here. Also, congratulations to @AmandersLPD for winning our #SnoopySensor competition! You can see the output of our *amazing* PRNG in action below:

I'll update this post to point to the DefCon video once they're released. In the meantime, the specifications of my custom quadcopter I had on stage are below:

Part    Type    Link
Frame DJI F450
Flight Controller APM 2.6
Motors DJI 920KV
Radio Turnigy 9x
Radio TX HawkEye 1W
Radio RX HawkEye 6ch
FPV Camera Sony 600
Video TX 600mw
OSD Minimosd
HD Camera GoPro3+ Black
Goggles SkyZone
Lost quad GPS Fi-Li-Fi
Payload BeagleBone Black

Fri, 27 Jun 2014

The SensePost Academy: Wrecking Balls

There is a serious skills shortage in our industry. There are just not enough skilled hackers out there to fill all the open positions. In November of last year, I proposed a new approach for us at SensePost to address these concerns. I looked at what we could do as a company to ensure the next generation of hackers were being educated correctly (no, it's not about how you use a tool) and moulded into what we, at SensePost, perceive to be good penetration testers.

I termed this the SensePost Academy and it is a structured training programme for all new recruits looking at a life at SensePost in the Assessment team. It is a combination of basic technical + offensive attack approaches and client interaction skills that provide an excellent stepping stone for those looking at starting a career as a penetration tester. The academy runs for a period of six months, finishing with a final culminating exercise (CULEX) before the decision is made to accept the recruit into the assessment team as an unmonitored penetration tester. The SensePost Academy Review Board (SARB) oversees each recruit and is responsible for grading and testing the recruit on each phase, in addition to mentoring (or should that be tormenting?) them.

Interviews were performed, we wanted the right recruit and had to turn down a lot of people in the process, but we did find two gentlemen, and as a team, decided on our first ever recruits:

On their first day, we reminded them that they were recruits and as a result, needed a special theme tune:

This theme tune would be played whenever they were addressed and as often as possible.

Over the past six months, they've been on many training courses internally, been shown the ways of the pwnage by the assessment team, presented at conferences and also developed and broken applications. Each phase was carefully monitored by the review board to ensure they were being moulded into a form we felt was right.

Finally, the CULEX week was upon us. A client application assessment (fictitious German company) and client feedback meeting. No hand holding, just perform the test like you've been shown and don't mess up.

After making them sweat, we took a vote this morning and I'm happy to welcome both Johan and Dane to our assessments team as Junior penetration testers.

If you think you'd be a good addition to the next academy intake, we've love to hear from you. Tweet us on @sensepost or email us at

Thu, 19 Jun 2014

Release the hounds! Snoopy 2.0

Friday the 13th seemed like as good a date as any to release Snoopy 2.0 (aka snoopy-ng). For those in a rush, you can download the source from GitHub, follow the file, and ask for help on this mailing list. For those who want a bit more information, keep reading.

What is Snoopy?

Snoopy is a distributed, sensor, data collection, interception, analysis, and visualization framework. It is written in a modular format, allowing for the collection of arbitrary signals from various devices via Python plugins.

It was originally released as a PoC at 44Con 2012, but this version is a complete re-write, is 99% Python, modular, and just feels better. The 'modularity' is possibly the most important improvement, for reasons which will become apparent shortly.

Tell me more!

We've presented our ongoing work with snoopy at a bunch of conferences under the title 'The Machines that Betrayed Their Masters'. The general synopsis of this research is that we all carry devices with us that emit wireless signals that could be used to:

  • Uniquely identify the device / collection of devices

  • Discover information about the owner (you!)

This new version of snoopy extends this into other areas of RFID such as; Wi-Fi, Bluetooth, GSM, NFC, RFID, ZigBee, etc. The modular design allows each of these to be implemented as a python module. If you can write Python code to interface with a tech, you can slot it into a snoopy-ng plugin.

We've also made it much easier to run Snoopy by itself, rather than requiring a server to sync to as the previous version did. However, Snoopy is still a distributed framework and allows the deployment of numerous Snoopy devices over some large area, having them all sync their data back to one central server (or numerous hops through multiple devices and/or servers). We've been working on other protocols for data synchronisation too - such as XBee. The diagram below illustrates one possible setup:

Architecture Diagram

OK - but how do I use it?

I thought you'd never ask! It's fairly straight forward.

Hardware Requirements

Snoopy should run on most modern computers capable of running Linux, with the appropriate physical adapters for the protocols you're interested in. We've tested it on:

  • Laptop

  • Nokia N900 (with some effort)

  • Raspberry Pi (SnooPi!)

  • BeagleBone Black (BeagleSnoop!)

In terms of hardware peripherals, we've been experimenting with the following:
Wi-FiAWUS 036H100m
ZigBeeDigi Xbee1km to 80kms
GSMRTL2832U SDR35kms

The distances can be increased with appropriate antennas. More on that in a later blog post.

Software Requirements

Essentially a Linux environment is required, but of more importance are the dependencies. These are mostly Python packages. We've tested Snoopy on Kali 1.x, and Ubuntu 12.04 LTS. We managed to get it working on Maemo (N900) too. We're investigating getting it running on OpenWRT/ddWRT. Please let us know if you have success.


It should be as simple as:
git clone
cd snoopy-ng
bash ./


Run Snoopy with the command 'snoopy', and accept the License Agreement. We'd recommend you refer to the file for more information, but here are a few examples to get you going:

1. To save data from the wireless, sysinfo, and heartbeat plugins locally:

snoopy -v -m wifi:iface=wlanX,mon=True -m sysinfo -m heartbeat -d <drone name> -l <location name>

2. To sync data from a client to a server:


snoopy_auth --create <drone name> # Create account
snoopy -v -m server # Start server plugin

snoopy -v -m wifi:iface=mon0 -s http://<server hostname>:9001/ -d <drone name> -l <location name> -k

Data Visualization

Maltego is the preferred tool to perform visualisation, and where the beauty of Snoopy is revealed. See the for instructions on how to use it.

I heard Snoopy can fly?

You heard right! Well, almost right. He's more of a passenger on a UAV:

There sure is a lot of stunt hacking in the media these days, with people taking existing hacks and duct-taping them to a cheap drone for media attention. We were concerned to see stories on snoopy airborne take on some of this as the message worked its way though the media. What's the benefit of having Snoopy airborne, then? We can think of a few reasons:

  1. Speed: We can canvas a large area very quickly (many square kilometres)

  2. Stealth: At 80m altitude the UAV is out of visual/audible range

  3. Security: It's possible to bypass physical security barriers (walls, men with guns, dogs)

  4. TTL (Tag, Track, Locate): It's possible to search for a known signature, and follow it

We're exploring the aerial route a whole lot. Look out for our DefCon talk in August for more details.

Commercial Use

The license under which Snoopy is released forbids gaining financially from its use (see LICENSE.txt). We have a separate license available for commercial use, which includes extra functionality such as:

  • Syncing data via XBee

  • Advanced plugins

  • Extra/custom transforms

  • Web interface

  • Prebuilt drones

Get in contact ( / if you'd like to engage with us.

Wed, 12 Feb 2014


Hey all,

So following on from my talk (slides, video) I am releasing the NMAP service probes and the Poison Ivy NSE script as well as the DarkComet config extractor.

An example of finding and extracting Camellia key from live Poison Ivy C2's:
nmap -sV -Pn --versiondb=nmap-service-probes.pi --script=poison-ivy.nse <ip_address/range)
Finding Poison Ivy, DarkComet and/or Xtreme RAT C2's:
nmap -sV -Pn --versiondb=nmap-service-probes.pi <ip_range>

If you have any questions, please contact