Fully Automatic Wireless Hacking Station

This article describes a working all-in-one standalone mobile wireless attack station that can perform MITM type attacks on clients automatically and without any internet access or other external connectivity or influence.

In laypersons terms; this portable battery powered device can automatically entice wireless devices to connect to it, be that iPhones/iPads, Androids and other phones or laptops and PCs. Most devices will connect to it automatically without the user even realizing. The device will provide a fake network running fake email and web servers and using some network trickery, will capture the hostname, username and password of any attempted connection and log it, along with the GPS co-ordinates of where the details were captured. This device could be used to hijack corporate and personal email logins, facebook logins, and so on.

HTTPS ActiveSync

Messing around with airbase-ng, part of the aircrack-ng suite over the last few months and researching wireless client vulnerabilities has led to an interesting proof of concept project. There are several weaknesses within the current wireless technologies in widespread use. First however, an explanation of the project. The project description was to launch a wireless man in the middle (MITM) attack, without having another end to connect the victim to. We need to create a MITM attack without having any internet access. Such an attack could theoretically be used on the tube, in locked down buildings, on the move, and so on, and without the use of a mobile data card. Built on top of a modified raspberry pwn release, although any Linux distribution would have been suitable, I have set my wireless device with a power output of 30dBm and started the following automated process:

Firstly, an airbase instance on my rtl8187 card as follows;

/usr/local/sbin/airbase-ng -c 3 wlan0 –essids “/root/pen/code/scripts/essids” -P -C 60 -I 60 -vv|grep –line-bufferedย  “directed probe request”|tee /run/probes

This starts an access point on channel 3, beaconing the SSIDs contained within /root/pen/code/scripts/essids as well as any probe requests that the access point may receive from clients looking to connect to an access point. Now, in a little more detail, regular ‘non-hidden’ access points will broadcast ‘beacons’ which are pieces of data that specify the SSID (wireless network name) as well as the supported encryption types and so on. These beacons are usually sent every 100msec. Wireless clients will send probe packets, containing the SSIDs of all wireless networks that they have stored, and asking if any of them are here.

Raspberry Pi

Raspberry Pi

The -P switch to airbase-ng will have airbase respond to all probes saying “yes, that’s me” at which point assuming the encryption or lack thereof matches the stored profile, the client will attempt to associate. Mid way through building this test however, Apple released IOS 6, and one of the changes seems that the iPhone will now only send out broadcast probes rather than directed probes, rendering the -P feature useless against them. The broadcast probe is where the device sends out a “is anyone there?” probe, and waits to see which access points reply. Most iPhones however have connected at some point to a wireless hotspot, and so the SSIDs I chose for the essids file are “Boingo Hotspot”, “BTOpenzone” and “BTWiFi” in the UK. I believe that “attwifi” is a popular one in the US.

We then wait for airbase-ng’s `at0′ interface to come up, before starting a DHCP server handing IPs out on the range whilst at0 itself is set to Clients are set with DNS and router set to

We then create a DNAT entry with iptables to redirect any traffic that comes in on at0 that would have been routed back to ourselves on;

iptables -t nat -A PREROUTING -i at0 -j DNAT –to-destination

Remembering that we have no default gateway, the biggest issue we have is that whilst we can run fake services on our device, we have no way of performing DNS lookups, and therefore even if we respond to all DNS A requests with ‘’, we’ll most likely be logging useless credentials.

At this point, I thought it would be a good idea to brush up on my programming skills and relearn PERL. Using the POE framework and sqlite3, we next run a fake DNS server. The DNS server is assigned a range, in this case on which to hand out IPs. The first request is assigned and logged in the database, the second request, and so on. If we already have a record of that request, we’ll hand out the IP we handed out the last time. Whether the client accepts our DNS or has their own hardcoded, the DNAT will redirect any DNS request to our device. Our DNS table might look something like;

id ip host
1 apple.com
2 www.google.com
3 m.google.com
4 imap.gmail.com

Now, iDevices and Blackberries attempt to connect to a URL to confirm internet service. If they do not receive the expected response, they assume they are on a wireless hotspot and pull up a login page. We must satisfy the query to pretend to the devices that they have valid internet access.

The next step in the process is where the client tries to connect to a service. I have currently built protocol support for POP3, IMAP, HTTP and their SSL versions, and additional services can be added easily.

Once the client initiates a connection, it is redirected back to us over DNAT. Under Linux, we have the originally requested destination IP available by using the socket option SO_ORIGINAL_DST. Assuming the client attempts to connect to now over IMAP, our IMAP server implements enough of the protocol to log the credentials and keep the client happy, as well as looking up the requested hostname ‘m.google.com’ in the sqlite3 database and presenting it as the banner.

iPhone: Cannot Verify Server IdentityShould SSL be in use, we dynamically create a self signed certificate for ‘m.google.com’ and present it to the client. It will yield the usual SSL warning although having a matching hostname, the non-technical user is more likely to accept. The iPhone [4 at least] had an annoying feature where no matter how many times ‘cancel’ is clicked, it will keep presenting with the same SSL warning until ‘continue’ is clicked or wifi is shut off. This almost guarantees that the user will click continue. In addition, whilst testing, I did not even realise at first that the warning I was presented with on the iPhone was even an SSL certificate warning. I am very surprised that the warning is not worded in stronger terms than it is.

Once we have credentials, these are logged in a separate table and related back to an IP entry which ultimately relates back to the original host the user attempted to connect to. Thus we are able to log host details, username and passwords on a standalone portable device with no network connectivity. Lastly, the device was kitted out with a BlueNEXT GPS dongle, and so GPS coordinates can be logged if they are available for where credentials were sniffed.

iPhone: Matching Certificate NameIt is not legally possible to actively run such a device in public, however based on internally testing the system with my own devices, as well as passively collecting some of the broadcast probes sent over the air in public places, running such a device in public could very easily harvest many hundreds of passwords ranging from home to corporate in only a few minutes at a suitably busy location. Furthermore, as the device has no internet or external connectivity of its own, and the attacker would be entirely untraceable.

In my next posting, I will discuss some of the weaknesses we touched upon and how they can be overcome.

Tags: , , , , , , , , , , ,

18 Responses to “Fully Automatic Wireless Hacking Station”

  1. Dennis H.M. says:

    Where can I buy one of these? ๐Ÿ™‚

    • npn says:

      They aren’t in Walmart yet ๐Ÿ˜‰

      • kk says:

        facing a problem with Filter-SSL installation in Kali Linux (v2). No matter what i do, this module cannot be installed at all. Can you please help in any way? Thank you!

        • Adam Palmer says:

          Not sure what the error is, but you can paste it here or try the Kali forums. I would say that this perl project is way out of date though and you can probably code something in Python that would be much cleaner and with less code.

          • kk says:

            Hello Adam and thanks for this awesome proof of concept! I managed to get all dependencies and the setup seems to be working except my cell phone doesn’t get an IP address. It says “Obtaining IP address…” until it decides to try to another network.

            Is there any chance that anything is missing from your step-by-step guide? Thank you so much for your reply!

          • Adam Palmer says:

            You need to run a DHCP server

  2. James says:

    Please advise where to purchase and how much. Thanks! Looking forward to use this device.

  3. Brane says:

    Great idea, great implementation and great article! Though I wish there were more details. I’ve taken upon a similar project myself and I’ve stumbled upon this page while searching for solutions to some of the problems that I’ve encountered.

    I’m trying to build a script that would primarily extend mdk3’s “WPA downgrade” functionality with some social engineering – mdk3 would continously deauthenticate stations connecting to the protected network, while at the same time my AP would broadcast an open network with the same SSID as target’s. One is expected either to “downgrade” their APs security eventually, or connect to my open network. Once they are on my network, all of their HTTP(s) traffic would get DNATted to a fake webpage asking them to enter their Wi-Fi passphrase. For example, if they would connect from a Windows machine, the webpage would be appropriately styled and say something like “Windows Enhanced Security – In order to continue, please enter password for your wireless network (SSID_here).” Another Wi-Fi interface would immediately try to authenticate with target’s network. If the authentication would be successful, all of the connected client’s traffict would at this point get routed through my authenticated interface (using target’s own internet connection as the uplink). There I would passively/aggressively try to intercept more of the target’s information/credentials while everything would appear to be working normally for the target.

    I’m wondering, would you be willing to share some of your code with me for my project?

  4. Enmanuel says:

    Hello nice research. is there anyways that you can make a tutorial of this?
    like what to do step by step and what tools did you use. and so on? I would really appreciate. I want to try to show this at my college fair for the computer security department. All by honored if you let me do this. thanks

  5. dontcare@home.com says:

    Really Perl?

    Worst language ever and to get the dependencies right is quite close to a nightmare…

    • npn says:

      I know.. I’m sorry! You’re absolutely right, I just used it as an opportunity to brush up on some Perl. I’ll have to port it to Python at some point.

  6. Johnny B says:

    sorry i’ve been living under a rock. are there actually people walking around with smart phones with their wifi ON?

    • Ogai says:

      mobile data connection like UMTS are not better, devices connect to the strongest, and for $1000 IIRC you can get a portable station.

  7. fak3r says:

    While not as DIY, there’s always the Pineapple AP that has similar goals to your project https://hakshop.myshopify.com/products/wifi-pineapple It’s easy to write plugins for it too, there are already some great ones out there.

  8. Yngwie Malware says:

    Isn’t this precisely what the WiFi Pineapple does?

    • Adam Palmer says:

      Certainly now, the WiFi Pineapple far surpasses this setup. The article is a year and a half old however and I’m not sure if the Pineapple supported this same approach and feature set at the time – it may well have done. I probably just wanted a new DIY project ๐Ÿ™‚

  9. Buge says:

    Does it log cookies? If not it should.

Leave a Reply