NPR Blog Series Part 2: A Week in the Life

Note: Per our agreement with NPR, Pwnie Express is not disclosing any data collected during the research experiment with Steve Henn, but focusing it’s comments on providing education on the techniques used.

In my last post I described how I configured a Pwn Plug R2 to stream Steve Henn’s laptop and iPhone traffic from his home office to my analysis server in Vermont. Steve was acting as a proxy for the average Internet user, whose traffic could be monitored by any malicious intermediary. With our Pwn Plug now acting as a “web surveillance” drop box, we then proceeded with our first order of business: A week in the life of Steve Henn.

Note our approach here was not to emulate advanced NSA surveillance techniques, such as exploitation of SSL protocol weaknesses, malware delivery, or other “active attacks”. Instead, we focused on what the NSA, your ISP, the dude with a Pwn Phone at your local coffee shop, or any number of other intermediaries can discern about an individual by passively monitoring the enormous amount of Internet traffic that’s still transmitted in clear-text (unencrypted) today.

With just a week’s worth of web traffic I was able to assemble a rather thorough personal profile of Mr. Henn. Between Steve’s day-to-day laptop/iPhone web traffic and some additional testing in Pwnie’s lab environment, we were able to capture:

  • Passwords
  • Phone numbers
  • Email addresses
  • Physical location
  • VoIP/SIP phone calls
  • Cell carrier parameters
  • Audio recording from an FTP file transfer
  • Search keywords
  • Personal interests & shopping habits
  • Session keys & cookies
  • Universally-unique session IDs
  • Make, model, & BIOS/firmware versions of laptops, mobile devices, & printers
  • Installed OS/application versions & patch levels (including AV software)
  • Running Windows processes, exe/dll versions, & connected USB devices
  • MAC addresses, internal IPs, & other unique device identifiers
  • Log of all visited domains, websites, & countries
  • Images, photos, software downloads, SSL certificates

In this post I’ll describe the techniques I used to extract this information from raw web traffic. This analysis was completed on a Pwn Plug R2 (via SSH) with the following open-source tools installed: tcpflow ngrep tshark ssldump p0f pads trafshow tcpxtract pcregrep tcpslice dsniff xplico argus libplist-utils

The below examples reference a “CAPFILE” variable, which can be set to your target tcpdump capture file as follows:

$ CAPFILE=”June-3.cap”

Extracting clear-text passwords:

$ ngrep -I “$CAPFILE” -W byline -q -t | egrep -i “password=|pass=|secret=|^PASS |^USER ”
$ dsniff -p “$CAPFILE”

Extracting phone numbers:

$ tcpflow -r “$CAPFILE” -c -s port 80 | pcregrep -o “[^a-zA-Z0-9](\d{3}).(\d{3}).(\d{4})[^a-zA-Z0-9]” | pcregrep -o “(\d{3})-(\d{3})-(\d{4})|(\d{3})\.(\d{3})\.(\d{4})”

Extracting email addresses:

$ tcpflow -r “$CAPFILE” -c -s | grep -v “\.\.” | pcregrep -o ‘\w+@[a-zA-Z_]+?\.[a-zA-Z]{2,6}’

Extracting clear-text credit card numbers:

$ ngrep -I “$CAPFILE” -q -t ‘(\s|^)([0-6]\d\d|7[0-256]\d|73[0-3]|77[0-2]) \d{2} \d{4}(\s|$)’
$ ngrep -I “$CAPFILE” -q -t ‘(\s|^)(6011|5[1-5]\d{2}|4\d{3}|3\d{3})-\d{4}-\d{4}-\d{4}(\s|$)’
$ ngrep -I “$CAPFILE” -q -t ‘(\s|^)(6011|5[1-5]\d{2}|4\d{3}|3\d{3})\d{12}(\s|$)’

Extracting clear-text social security numbers:

$ ngrep -I “$CAPFILE” -q -t ‘(\s|^)([0-6]\d\d|7[0-256]\d|73[0-3]|77[0-2]) \d{2} \d{4}(\s|$)’
$ ngrep -I “$CAPFILE” -q -t ‘(\s|^)(6011|5[1-5]\d{2}|4\d{3}|3\d{3})-\d{4}-\d{4}-\d{4}(\s|$)’

Extracting physical location (GPS latitude & longitude) from iPhone Weather app traffic:

$ ngrep -I “$CAPFILE” -W byline -q -t ‘^(GET|POST|HTTP/)’ port 80 |egrep “%2Clatitude%2Clongitude%2C”

Extracting VOIP/SIP call data:

$ ngrep -I “$CAPFILE” -W byline -q -t | grep -v “\.\.” |grep SIP

Decoding Apple device plist files to obtain cell carrier parameters:

First, use xplico to carve the plist XML files out of the packet capture:

$ xplico -l -m pcap -f “$CAPFILE”

Then, use plutil to decode the plist XML files into readable strings:

$ plutil -i “xdecode/bag” |strings > iphone_plist_bag.txt
$ plutil -i “xdecode/bag(1)” |strings > iphone_plist_bag1.txt
$ plutil -i “xdecode/getBag%3fix\=1” |strings > iphone_plist_getBag.txt
$ plutil -i “xdecode/version(1)” |strings > iphone-plist-cell-carriers.txt

Carving out & listing audio/video files, images, photos, executable files, SSL certificates, etc:

$ xplico -l -m pcap -f “$CAPFILE”
$ find xdecode/

Extracting keyword strings from HTTP Referer values:

$ ngrep -I “$CAPFILE” -W byline -q -t ‘^(GET|POST)’ port 80 | egrep “^GET |^POST |^Referer: ” | egrep -o “[a-z-]*” | egrep “[a-z-]*-[a-z-]*-” | egrep -v “(^-|-$)”

Displaying Microsoft Bing Search keywords:

$ ngrep -I “$CAPFILE” -W byline -q -t ‘^(GET|POST|HTTP/)’ port 80 | egrep “”

Displaying Amazon product searches:

$ ngrep -I “$CAPFILE” -W byline -q -t ‘^(GET|POST|HTTP/)’ port 80 | egrep “”

Extracting cookies, session IDs, keys, tokens, etc:

$ tcpflow -r “$CAPFILE” -c -s port 80 | grep -v “\.\.” | egrep “^Set-Cookie|oauth|UUID||session.token|Authorization:”

Extracting make, model, & BIOS/firmware versions of PCs & mobile devices from Microsoft Windows error reporting, Apple iDevice browser, & Android YP app traffic:

$ ngrep -I “$CAPFILE” -W byline -q -t ‘^(GET|POST)’ port 80 |egrep “^T |^GET |^Host: ” |egrep -B2 “$”
$ ngrep -I “$CAPFILE” -W byline -q -t ‘^(GET|POST|HTTP/)’ port 80 | egrep “X-Device-Info: ”
$ ngrep -I “$CAPFILE” -W byline -q -t ‘^(GET|POST|HTTP/)’ port 80 | egrep “macAddress=|device_name=|device_type=|os_version=|dev=”

Displaying client OS/applications & versions:

$ ngrep -I “$CAPFILE” -W byline -q -t port 80 | egrep “^User-Agent: “

Extracting running processes, exe/dll versions, & connected USB devices from Microsoft Windows error reporting traffic:

$ ngrep -I “$CAPFILE” -W byline -q -t ‘^(GET|POST)’ port 80 |egrep “^T |^GET |^Host: ” |egrep -B2 “$”

Top 10 domains:
$ tcpdump -nn -r “$CAPFILE” port 53 | egrep ” A\? ” | awk ‘{print$8}’ | egrep -io “[a-z0-9]*\.[a-z]*\.$” | sort | uniq -ic | sort -nr | head |awk ‘{print$1,$2}’

Top 10 websites (based on number of HTTP requests):
$ ngrep -I “$CAPFILE” -W byline -q -t ‘^(GET|POST)’ port 80 | grep “^Host:” | sort |uniq -ic |sort -nr |head |awk ‘{print$1,$3}’

Top 10 referers:
$ ngrep -I “$CAPFILE” -W byline -q -t ‘^(GET|POST)’ port 80 | egrep “^Referer: ” |sort |uniq -ic | sort -nr |head |awk ‘{print$1,$3}’

Top TLDs/countries:
$ tcpdump -nn -r “$CAPFILE” port 53 | egrep ” A\? ” | awk ‘{print$8}’ | egrep -io “\.[a-z]*\.$” |sort |uniq -ic |sort -nr |awk ‘{print$1,$2}’

List any weak/vulnerable SSL sessions:
$ ssldump -n -r “$CAPFILE” | grep “cipherSuite” | egrep -i “RC4|MD5|EXP|NULL|_DES|ANON|64″ | sort | uniq -c | sort -nr | awk ‘{print$1,$2,$3}’

NPR Blog Series: Part 1 – The Drop Box

Note: Per our agreement with NPR, Pwnie Express is not disclosing any data collected during the research experiment with Steve Henn, but focusing it’s comments on providing education on the techniques used.As part of a collaboration between NPR, Ars Technica, and Pwnie Express, I spent the last few months on what can only be described as “way too much fun to be called work”. When Sean Gallagher (Ars Technica editor and long-time Pwnie fan) approached me asking if I’d be interested in legally “spying” on an NPR journalist, I gleefully accepted the challenge. The willing target would be NPR tech correspondent Steve Henn, in support of a Morning Edition series about the state of Internet privacy a year after the Snowden/NSA revelations.

Once the proper legal authorizations were in place, we decided the Pwn Plug R2 would serve as the ideal “drop box” to stream Steve’s laptop and iPhone traffic from his home office to my analysis server in Vermont. The Pwn Plug R2 was deployed as a secondary wireless AP on Steve’s home network as shown:



















To turn the Pwn Plug R2 into a normal (“non-evil”) wireless AP, I first installed the hostapd package:

# aptitude update

# aptitude install hostapd

I then configured /etc/hostapd/hostapd.conf as shown:














To ensure the hostapd service started up automatically at boot time, I created the following init script:


# Provides:                  pwnix_ap

# Required-Start:         $remote_fs $syslog

# Required-Stop:         $remote_fs $syslog

# Default-Start:            2 3 4 5

# Default-Stop:            0 1 6

# Short-Description: Pwnie Express normal (non-evil) AP service



# processname: pwnix_ap


 DESC=”Pwnix AP Service”





  case “$1″ in


            echo “[+] Starting $NAME…”

            echo “[+] Using AP interface: $AP_INTERFACE”

            echo “[+] Using Internet interface: $INTERNET_INTERFACE”

            # Clean slate

            ifconfig $AP_INTERFACE down

            killall hostapd  > /dev/null 2>&1

            killall dhcpd > /dev/null 2>&1

            iptables –flush

            iptables –table nat –flush

            iptables –delete-chain

            iptables –table nat –delete-chain

            sleep 1


             # Start AP        #


            # Configure AP interface

            ifconfig $AP_INTERFACE up netmask

            sleep 5

            # Start dhcpd server on AP interface

            dhcpd -cf /etc/dhcp/dhcpd.conf -pf /var/run/ $AP_INTERFACE & > /dev/null 2>&1

            # Enable NAT

            iptables –table nat –append POSTROUTING –out-interface $INTERNET_INTERFACE -j


            iptables –append FORWARD –in-interface $AP_INTERFACE -j ACCEPT

            # Enable IP forwarding

            echo 1 > /proc/sys/net/ipv4/ip_forward

            # Start hostapd

            hostapd -B /etc/hostapd/hostapd.conf > /dev/null 2>&1

            # indicate to the user that passive recon is on

            touch $PIDFILE

            echo “[+] $NAME started.”

            exit 0



            echo “[+] Checking $NAME…”

            if [ -f $PIDFILE ]; then

            echo “[+] $NAME is running.”

            exit 0


            echo “[-] $NAME not running.”

            exit 1




            echo “[+] Stopping $NAME”

            ifconfig $AP_INTERFACE down

            killall hostapd  > /dev/null 2>&1

            killall dhcpd > /dev/null 2>&1

            iptables –flush

            iptables –table nat –flush

            iptables –delete-chain

            iptables –table nat –delete-chain

            echo 0 > /proc/sys/net/ipv4/ip_forward


            echo “[+] $NAME stopped.”

            exit 0



            $0 stop

            $0 start



            echo “Usage: $0 {status|start|stop|restart}”

            exit 1


 After saving this script to /etc/init.d/pwnix_ap, I made it executable and set it to autostart:

# chmod +x /etc/init.d/pwnix_ap

# update-rc.d pwnix_ap defaults

Persistent remote access to the Pwn Plug R2 was a cinch using the “Reverse Shells” feature. Once connected to the plug via SSH, I started a full-packet capture using tcpdump:

# tcpdump -vUnni wlan0 -w date "+%h.%d.%Y-%H%M".cap

I then used a variety of open-source analysis tools to parse and inspect the web traffic generated by the normal day-to-day use of our mobile device and PCs/laptops. Stay tuned for “Part 2: A Week in the Life” to see what I found!


Pwnie Express turns the Nexus 5 into a powerful white hat hacking tool

Pwnie Express Turns the Nexus 5 Into a Powerful White Hat Hacking Tool

By Andrew Grush

Part of the magic of Android is the flexibility of the platform when it comes to customization and modding. With a little ingenuity, you can transform your Android-powered devices into just about anything — including a sweet hacking tool.

That’s exactly what Pwnie Express did to the Nexus 5, which it dubs as the Pwn Phone. Retailing for a pricey $1295, the Pwn Phone utilizes Nexus hardware but switches out stock Android for a special variant that has a recompiled kernel and runs on its own derivative of Kali Linux on the back-end of Android.

The Pwn Phone’s custom ROM gives the device the ability to act as a USB host, allowing it to add on Wi-Fi, Bluetooth and Ethernet via adapters. The reason for the added on adapters are that they offer improved range and capabilities over what’s already baked into the phone.

(Original Article)

The Weakest Link

weakest security linkIn the oft-repeated words of Bill Cheswick of Bell Labs, perimeter defenses like firewalls can serve as “a sort of crunchy shell around a soft, chewy center.” Your datacenter may be secured like Fort Knox with multiple layers of RFID and biometric access controls, security guards and anti-tailgating measures but your security posture is only as strong as its weakest component. This is the Defender’s Dilemma: The attacker only needs to find a single way into the network; the defender must defend all points from attack.

Open network ports in common areas such as training, break and conference rooms can provide an end run around the best laid security plans. The tension between the security of corporate data and convenience for users and administrators is most evident at these points. Given the choice between manually provisioning guests throughout the day and more permissive controls, the balance usually tilts towards greater ease of use.

In a recent pen test conducted by Black Hills Information Security for a company with otherwise strong security culture and controls, a Pwn Plug R2 was plugged into an open Ethernet port in a headquarters conference room that was accessible from the lobby without passing through a guard station. The Pwn Plug was also able to access Wi-Fi networks. The device remained undiscovered and operational for two weeks hidden under a conference room table. This device provided a platform to penetrate the headquarters network and the hardened data center beyond.

What can you do to prevent such an opening that bypasses your controls? The following measures can lessen the risk of a breach:

  • Disable unused cable drops
  • Apply network access control (NAC) where possible
  • Regularly inspect common areas for unfamiliar devices
  • Segment the corporate network to limit exposure if a compromise occurs in a single area
  • Treat networks in common areas as public and require VPN to access corporate resources
  • Restrict and monitor outbound protocols, especially from networks with public access

Android-based Pwn Phone is Prepared to Do Evil for Your Network’s Own Good

By Sean Gallagher

Mobile technology has made it possible for people to do an amazing amount with tablets and smartphones within the workplace—including hacking the living daylights out of the corporate network and other people’s devices. Pwnie Express is preparing to release a tool that will do just that. Its Pwn Phone aims to help IT departments and security professionals quickly get a handle on how vulnerable their networks are in an instant. All someone needs to do is walk around the office with a smartphone.

Pwnie Express’ Kevin Reilly gave Ars a personal walk-through of the latest Pwn Phone, the second generation of the company’s mobile penetration testing platform. While the 2012 first-generation Pwn Phone was based on the Nokia N900 and its Maemo 5 Linux-based operating system, the new phone is based on LG Nexus 5 phone hardware. However, it doesn’t exactly use Google’s vanilla Android.

“What we’ve done is taken Android 4.4 Kit Kat and recompiled the kernel,” said Reilly. “On the backend, it runs our own derivative of Kali Linux, called Pwnix. Essentially it’s running a full-blown Debian OS on the back-end of Android.“

(Original Article)

Mapping WiFi Networks on the Pwn Pad 2014

There are many advantages to mobile pentesting, certainly one of the biggest being the simple fact that you aren’t stuck in one single geographic location; you can move seamlessly through buildings or even whole campuses without breaking stride. But making sense of the data you collected while moving around a location can be a nightmare if you don’t have the visual context to put it all together.

Luckily, a few quick steps can take the data you’ve collected from Kismet on the Pwn Pad and turn it into a file ready for importing into Google Earth; giving you the geospatial perspective you need to turn raw data into a valuable pentesting tool.

Enable GPS

First, you’ll need to make sure GPS is enabled on the Pwn Pad. The easiest way to do this is to take a look at the “Power Control” widget on the main screen. If the center GPS icon isn’t illuminated, simply tap it to turn on the Pwn Pad’s GPS hardware.


With the GPS radio powered on, open the “BlueNMEA” application, located under the “Wireless Tools” directory.

Pwn Pad wireless tools

Capture APs with Kismet

With GPS enabled and the BlueNMEA application running, you can start the Kismet WiFi scanner by tapping its icon under “Wireless Tools”. As soon as Kismet opens, hit the “Enter” key on the onscreen keyboard to begin capturing WiFi networks and their GPS coordinates.


As you walk around scanning for WiFi access points, you’ll see a constantly updated feed at the bottom of the screen as new networks are detected. You should also be able to see the GPS coordinates update as you move around.

Once you’ve finished logging some APs, press the physical “Volume Down” button on the side of the Pwn Pad, followed by “c” on the keyboard. This will cause Kismet to gracefully shutdown, and make sure the log of discovered networks and their associated devices is saved properly.

Log File Conversion

You now have a Kismet log file that contains all of the WiFi devices you’ve seen as well as their geographical location under /opt/pwnix/captures/wireless, but it isn’t ready for displaying in Google Earth yet. We’ll need to convert it first with a simple tool from the Kali repository.

After you exit Kismet you’ll be dropped back to the terminal. From here, enter the following commands to install giskismet:

apt-get update
apt-get install giskismet

Hit “Enter” when asked if you’d like to install giskismet and its dependencies, and give the Pwn Pad a minute to complete the operation. Once installed, run giskismet against the latest Kismet log file with the following command (where DATE is the timestamp of the log file you wish to convert):

giskismet ­-x Kismet-DATE.netxml ­-q "select * from wireless" ­-o blog_example.kml

After running the command, you’ll see a list of discovered AP’s as giskismet works through the file and does the conversion process. After conversion, copy the new KML file to /sdcard/ so it’s easier to find in the next step:

cp blog_example.kml /sdcard/


Opening in Google Earth

With your Kismet log file converted, all that’s left to do is install Google Earth and take a look. You’ll also need to install a file manager to select the KML file for import into Google Earth (ES File Explorer is recommended). Head over to the Google Play Store to install both applications as you would on any other Android device.

Note: Accessing the Google Play Store will require you to associate a Google Account with your Pwn Pad. You’ll be asked to either create a new account or use an existing one as soon as you open the Play Store for the first time.

Now simply open ES File Explorer and select the blog_example.kml file you moved to /sdcard/:


Google Earth will start up and zoom to your current location. You can then move around the globe, viewing the WiFi networks you detected. Tapping an individual network will let you see additional information about it, such as the channel it was running on, and the MAC addresses of any clients that were connected to it at the time of the scan.




EvilAP: A Practical Example

Like most transformational technologies, WiFi has both a positive and negative side. The ease of use offered to the user by a modern WiFi device is matched only by the ease in which it can be exploited by an attacker. With the proliferation of mobile computing, its never been more important to make sure client devices are connecting only to approved networks; but unfortunately, its also never been easier for attackers to make sure that doesn’t happen.

One technique which can be used to lure unsuspecting WiFi users is known as an EvilAP. This is a collection of software and appropriate hardware which allows for the creation of a rogue access point that is indistinguishable from a legitimate WiFi network to the casual observer.

Once a client has connected to such a network (often without the user’s knowledge), the attacker has full control of all information going into and out of the device, and can deploy various tools to modify or monitor the victim’s communication. From the perspective of the victim, their usage of the Internet will be unhindered, and it’s unlikely they’ll ever suspect they’ve been compromised.

Setting up a rogue access point and running the appropriate tools to capture a victim’s credentials is trivially easy with modern software and penetration testing products. Using the Pwnie Express Pwn Pad tablet, a rogue access point and associated network monitoring tools can deployed in literally seconds while remaining mobile during the entirety of the operation.

EvilAP Setup

To start, simply connect up the included external WiFi adapter and tap the “EvilAP” icon under the “Wireless Tools” folder on the Pwn Pad main screen. This will bring up a dialog asking which interface you’re currently using the connect to the Internet. Here you’ll have the option of using a cellular connection, the Pwn Pad’s internal WiFi, or even a USB connected Ethernet device.


Once you’ve selected your source interface, you’ll then be asked what you want to call this rogue AP. You can hit the Enter key to go with the default “Public_Wireless”, or enter your own SSID. Next, you can enter what channel you want to run the AP on. The default (Channel 1) should be fine here, as there’s generally not as much traffic on the lower channels.


At this point you need to decide if you want to run in the so-called aggressive or static mode. Aggressive mode will net you more results, but it can be overwhelming in high traffic areas, as you’ll get connections from all devices rather than just those with the matching SSID.

Finally, you’ll be asked which beacon rate you want to use. Try the default of 30 to start with, but this value can be adjusted up or down a bit if you find you’re having trouble keeping clients connected.

Activating Attacks

The hard part’s over, now it’s time to layer attacks on top of our fake access point and start collecting data.

From the “Attack Tools” folder on the home screen, tap the “SSL Strip” icon, and choose which interface you want to sniff on (for each tool, you’ll want to select the EvilAP interface, at0).

EvilAP screenshot 6

Head back to the Pwn Pad’s main screen and open up the “Network Tools” folder, where you’ll find the next two tools, “Strings Watch” and “Dsniff”. For both tools, select the at0 interface and confirm you want to log results.

That’s it. Now with just a swipe of your finger you can switch between terminal windows running the various tools and watch the results as they flow through the Pwn Pad in real-time. Results will also be stored in /opt/pwnix/captures/passwords/ for later analysis, so you won’t even have to watch the screen.


The Pwn Pad running an EvilAP in a crowded public place like a coffee shop will likely result in a log file brimming with credentials from multiple users and services in a relatively short time. Since the victim’s experience using the Internet was not significantly different than normal, there’s little chance anyone who connects to the EvilAP will ever question its legitimacy until it’s too late.

Introduction to EvilAP

With the ubiquity of WiFi devices, the ability to create a rogue access point (also known as an EvilAP) has never been more useful, or in the wrong hands, more dangerous. For a pentester, an EvilAP can be used to not only verify client devices are not automatically connecting to unauthorized access points, but to also test if the legitimate access points on the network can be spoofed without the users noticing.

Using EvilAP is fairly straightforward, but there are a few details and caveats you should be aware of for a successful deployment.

EvilAP Operating Modes

The EvilAP function can operate in two different modes: aggressive or static. The different modes have their own strengths and weaknesses, and selecting which one is appropriate for your task is important for best results.

Aggressive Mode

In aggressive mode, EvilAP will listen for and answer any WiFi probe requests it receives. This allows EvilAP to spoof the SSID of whatever open networks the device has connected to previously. So if a user has his smartphone configured to automatically connect to his open home WiFi network named “linksys”, EvilAP’s aggressive mode will fool the device into thinking it’s connecting to the user’s home network.

The principle advantage of aggressive mode is that WiFi devices will automatically connect to the EvilAP without any user intervention, which makes it an excellent choice for performing spot checks in the test environment to find if any client devices have been incorrectly configured to connect to open networks within range.

To enable aggressive mode, select 1 when asked if you’d like to force clients to connect based on their probe requests.

EvilAP screenshot 1

Additionally, you’ll be given the opportunity to specify a beacon rate to use when sending probe requests. The default is 30 milliseconds, but it can be adjusted between 20 and 70 milliseconds if you’re finding that devices are not reliably making and maintaining a connection to the EvilAP.

Note: Aggressive mode can become unstable when operating in areas of high WiFi traffic. Keep an eye out for error messages, and try adjusting the beacon rate to see if performance improves.

Static Mode

In static mode, EvilAP will advertise itself as a specific (user supplied) SSID and wait for devices to connect. This mode is useful when targeting a specific access point, and has the advantage of greater stability than aggressive mode.

Naturally, the SSID must be a known ahead of time for static mode to operate. Accordingly, static mode is primarily useful when attempting to spoof a known access point during a pentest. It’s worth noting that valid SSIDs for use in static mode can first be found using EvilAP in aggressive mode.

Due to the more stable nature of static mode, it is the prefered mode to use when additional exploits are going to be run on top of the EvilAP.

Enabling static mode is simple, just give EvilAP an SSID to use, and it will handle the rest.


Internet Access

For a truly effective EvilAP deployment, Internet access is required so that it can be passed on to any victims which end up connecting to it. Aside from alerting the user to a problem, a lack of Internet access means the client won’t be able to communicate with any outside services, thus giving no opportunity to exploit it.

When using the Pwn Pad, you’ll have the option of using either the device’s 4G cellular modem, the internal WiFi, or an external Ethernet device.

Note: The internal WiFi radio (wlan0) will take routing preference over any other interface. Be sure that the Pwn Pad’s WiFi is not connected to any existing networks before attempting to use the other interfaces as a source of Internet connectivity.


Layered Attacks

With an EvilAP up and victims connecting to it without even realizing, you now have the perfect platform from which to launch a myriad of other attacks and exploits. Since all of the user’s Internet traffic will be passing through your EvilAP, it’s possible to collect user credentials, falsify web pages, or simply monitor the victim’s every move online.

Pwnie Express and Splunk: Realtime Wireless & Bluetooth Visibility

As part of a recent collaboration between Pwnie Express and Splunk, Inc., we put together a simple “Pwnie-Splunk” dashboard showing a real-time stream of all wireless and Bluetooth devices detected by a Pwn Plug R2 on the RSA show floor.

To accomplish this, we cobbled together a few parsers for Airodump-NG and Bluelog output, which we then forwarded to the Splunk demo server via syslog.

The Bluelog parser is fairly simple. First, we launch Bluelog in daemon mode, recording Bluetooth device names and device types and logging all detected devices to a local log file on the Pwn Plug R2:

# Start bluelog and write output to local logfile
bluelog -nfdo /var/log/pwnix/bluelog-devices

Next, we forward a real-time tail of this log to the Splunk server:

# Forward newly detected Bluetooth devices to Splunk server
tail -f /var/log/pwnix/bluelog-devices | logger -u /tmp/ignored -d -P 514 -t bluelog -n "${splunk_server}" &

Ok, that was fairly painless. Parsing Airodump-NG output on the hand was a bit of a challenge. Airodump-NG does export to CSV. However, the resulting CSV contains binary blobs, MS-DOS newline characters, two separate sections (with header rows) for wireless APs versus wireless clients, and the CSV file is entirely overwritten every 5 seconds while Airodump-NG is running. Also, Airodump-NG has no native support for backgrounding or daemonizing itself.

We thus first launch Airodump in a detached screen session:

# Launch a detached airodump session that logs output in CSV format
screen -d -m -S AirodumpSession airodump-ng --output-format=csv --write=/var/log/pwnix/airodump "${monitor_interface}"

Next, because Airodump overwrites the CSV every 5 seconds, we need to establish a way to track “already known” devices to avoid duplicate log entries for devices already discovered by the running Airodump session. To accomplish this, we first log the initial list of client devices and APs detected by Airodump:

# Create initial list of client devices and forward to Splunk server
cat /var/log/pwnix/airodump-01.csv | tr -d 'r' | tr -cd '11121540-176' | awk -vRS='nStation MAC' 'NR==2 {print}' | egrep -v "First time seen|^$" | awk -F"," '{print$1","$6","$7,$8,$9,$10,$11,$12,$13,$14,$15,$16}' | tee "${local_logpath}"/airodump-known-clients | logger -u /tmp/ignored -d -P 514 -t wificlient -n "${splunk_server}"

# Create initial list of APs and forward to Splunk server
cat "${local_logpath}"/airodump-01.csv | tr -d 'r' | tr -cd '11121540-176' | awk -vRS='nStation MAC' 'NR==1 {print}' | egrep -v "^BSSID|^$" | awk -F"," '{print$1","$14","$6}' | tee "${local_logpath}"/airodump-known-APs | logger -u /tmp/ignored -d -P 514 -t wifiap -n "${splunk_server}"

The “tr” commands strip out the MS-DOS newlines and binary blobs. The first “awk” command then splits the wireless AP/client sections into a simple comma-separated list of each device type, then the second “awk” command organizes the output into the desired format for our syslog entries. The “tee” command writes the initial list of known APs/clients to a local file, and “logger” then forwards that same list to the Splunk server.

We now want to keep an eye on the Airodump CSV file and forward any newly detected APs/clients to Splunk. This is accomplished with the following while loop:

while [ 1 ]

# Extract wireless clients from airodump CSV file, append newly detected clients to airodump-known-clients, and forward newly detected clients to Splunk server
cat "${local_logpath}"/airodump-01.csv | tr -d 'r' | tr -cd '11121540-176' | awk -vRS='nStation MAC' 'NR==2 {print}' | egrep -v "First time seen|^$" | awk -F"," '{print$1","$6","$7,$8,$9,$10,$11,$12,$13,$14,$15,$16}' | grep -vxf "${local_logpath}"/airodump-known-clients | tee -a "${local_logpath}"/airodump-known-clients | logger -u /tmp/ignored -d -P 514 -t wificlient -n "${splunk_server}"

# Extract wireless APs from airodump CSV file, append newly detected APs to airodump-known-APs, and forward newly detected APs to Splunk server
cat "${local_logpath}"/airodump-01.csv | tr -d 'r' | tr -cd '11121540-176' | awk -vRS='nStation MAC' 'NR==1 {print}' | egrep -v "^BSSID|^$" | awk -F"," '{print$1","$14","$6}' | grep -vxf "${local_logpath}"/airodump-known-APs | tee -a "${local_logpath}"/airodump-known-APs | logger -u /tmp/ignored -d -P 514 -t wifiap -n "${splunk_server}"

# Repeat every few seconds
sleep 3

The “tr” and “awk” commands server the same purpose as when we created the initial list of APs/clients above. With the addition of the “egrep” command however, we can effectively de-duplicate our results by excluding any “already known” AP/client devices from our output and then appending any newly detected devices to the original list.

Pwnie-Splunk Dashboard Screenshot

Running this demo live at both the Splunk and Pwnie booths made one thing quite clear: It’s 2014, and most security conference attendees still do not disable the Wifi or Bluetooth functions of their mobile devices while on the conference floor. Within 10 minutes of launching the demo, over 1000 mobile devices appeared on our Pwnie-Splunk dashboard.


The State of Open Source Pentesting Tools

Penetration testers rely heavily on a challenging combination of open source and proprietary software. Most of these tools are available for free through various software repositories but who makes these tools and who maintains them? How up-to-date and robust is the ecosystem on which we stake our professional careers and test the security of some of the most important systems on the planet?

At Security B-Sides in San Fransisco, Pwnie Express developers Sam Stelfox and I (Gabe Koss) investigate the state of many uncommon and well-established tools. This talk looks at the various tools which are publicly available via the Kali Linux repositories from the perspective software development, maintainability and professional reliability.

In this talk we will:

  • Present statistical information about these tools
  • Place shame on projects which need to be better maintained
  • Highlight tools which are doing a good job
  • Make solutions to help the community at large better curate this complex ecosystem of tools

Drop by our talk at 4pm in the Main Room (Track 1) of the DNA Lounge.

About Security B-Sides

Security B-Sides is the first grass roots, DIY, open security conference in the world!  Security B-Sides is a great combination of two event styles: structured anchor events and grass-roots geocentric events. B-Sides San Francisco is a 2-day information security conference taking place on February 23rd and 24th at the DNA Lounge. Each day will feature two speaking tracks. Admission is free, on a first-come, first-served basis.

Click here to learn more about B-Sides San Francisco.