Grey bar Blue bar
Share this:

Thu, 23 May 2013

Stay low, move fast, shoot first, die last, one shot, one kill, no luck, pure skill ...

We're excited to be presenting our Hacking By Numbers Combat course again at Black Hat USA this year. SensePost's resident German haxor dude Georg-Christian Pranschke will be presenting this year's course. Combat fits in right at the top of our course offerings. No messing about, this really is the course where your sole aim is to pwn as much of the infrastructure and applications as possible. It is for the security professional looking to hone their skill-set, or to think like those in Unit 61398. There are a few assumptions though:

  • you have an excellent grounding in terms of infrastructure - and application assessments

  • you aren't scared of tackling systems that aren't easily owned using Metasploit

  • gaining root is an almost OCD-like obsession

  • there are no basic introductions into linux, shells, pivoting etc.

As we've always said, it is quite literally an all-hack, no-talk course. We are not going to dictate what tools or technologies get used by students. We don't care if you use ruby or perl or python to break something (we do, actually - we don't like ruby), just as long as it gets broken. The Combat course itself is a series of between 12 and 15 (depending on time) capture the flag type exercises presented over a period of two days. The exercises include infrastructure, reverse engineering and crypto.

These targets come from real life assessments we've faced at SensePost, it's about as real as you can get without having to do the report at the end of it. How it works is that candidates are presented with a specific goal. If the presenter is feeling generous at the time, they may even get a description of the technology. After that, they'll have time to solve the puzzle. Afterwards, there will be a discussion about the failings, takeaways and alternate approaches adopted by the class. The latter is normally fascinating as (as anybody in the industry knows), there are virtually a limitless number of different ways to solve specific problems. This means that even the instructor gets to learn a couple of new tricks (we also have prizes for those who teach them enough new tricks).

In 2012, Combat underwent a massive rework and we presented a virtually new course which went down excellently. We're aiming to do the same this year, and to make it the best Combat course ever. So if you're interested in spending two days' worth of intense thinking solving some fairly unique puzzles and shelling boxen, join us for HBN Combat at BlackHat USA.

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.

    Mon, 4 Mar 2013

    Black Hat Europe - Bootcamp Training

    SensePost will be at Black Hat Europe 2013 to deliver the Bootcamp module of the Hacking by Numbers series. This method based introductory course emphasizes the structure, approach, and thought-processes involved in hacking (over tools and tricks). The course is popular with beginners, who gain their first view into the world of hacking, as well as experts, who appreciate the sound, structured approach.

    A break down of what will be covered during this course:

    • Internet Reconnaissance

    • Internet Fingerprinting

    • Vulnerability Discovery

    • Exploiting Known Vulnerabilities

    • Finding and Exploiting Vulnerabilities in Web Applications

    • Attacking Content Management Systems

    • SQL Injection

    • Real-world exercises and capture-the-flags

    To summarize:

    What? SensePost Hacking by Numbers, Bootcamp edition
    Where? Amsterdam, BlackHat EU
    When? 12th & 13th March 2013
    Level? Introductory

    See the BlackHat course page for more information, or to book your seat.

    We're looking forward to seeing you there!
    Glenn & Sara

    Wed, 16 Jan 2013

    Client Side Fingerprinting in Prep for SE

    On a recent engagement, we were tasked with trying to gain access to the network via a phishing attack (specifically phishing only). In preparation for the attack, I wanted to see what software they were running, to see if Vlad and I could target them in a more intelligent fashion. As this technique worked well, I thought this was a neat trick worth sharing.

    First off the approach was to perform some footprinting to see if I could find their likely Internet breakout. While I found the likely range (it had their mail server in it) I couldn't find the exact IP they were being NAT'ed to. Not wanting to stop there, I tried out Vlad's Skype IP disclosure trick, which worked like a charm. What's cool about this approach is that it gives you both the internal and external IP of the user (so you can confirm they are connected to their internal network if you have another internal IP leak). You don't even need to be "friends", you can just search for people who list the company in their details, or do some more advanced OSINT to find Skype IDs of employees.

    Once I had that IP, I went on a hunt for web logs that had been indexed by a search engine, that contained hits from that IP. My thinking was that I run into indexed Apache or IIS logs fairly often when googling for IPs or the like, so maybe some of these contained the external NAT IP of the target organisation. It took a fair bit of search term fiddling, but in the end I found 14 unique hits from their organisation semi-complete with User Agent information (some were partially obscured).

    This provided me with the following stats:

    Operating System

    Win XP 8

    Win 7 32 3

    Win 7 64 3


    IE 8 8

    IE 6 3

    IE 7 1

    IE 9 1


    Win 7 IE 8 4

    Win XP IE 8 4

    Win XP IE 6 3

    Win 7 IE 9 1

    Win XP IE 7 1

    Granted, it could be that the same machine was present in multiple logs and the stats are skewed, but they are a large enough organisation that I thought the chances were low, especially as most of the sites who's logs I found were pretty niche. As validation of these results, later, once we had penetrated through to the internal network, it was clear that they had a big user base in regional offices still on Win XP and IE6, and a big user base at corporate offices who had been migrated to Windows 7 with IE8.

    Unfortunately, the UserAgent didn't make it clear whether they had Acrobat or Java or what versions they were at. We thought of using some JavaScript to do such detection, but were under a time constraint, and went with trying to pwn them instead, with the thinking that if it doesn't work, we could retarget and at least get some debugging information.

    Anecdotally, and to give the story an ending, it turned out that BlackHole and Metasploit's Browser AutoPwn were a bust, even our customised stuff got nailed by Forefront when the stager tried to inject it's payload at runtime, but an internal tool we use for launching modified meterpreter payloads worked like a charm (although, periodically died on Win7 64bit, so I'd recommend using reverse-http, you can restart sessions, and firing up a backup session to restart the other with).

    Mon, 26 Nov 2012

    Skype Passive IP Disclosure Vulnerability

    When performing spear phishing attacks, the more information you have at your disposal, the better. One tactic we thought useful was this Skype security flaw disclosed in the early days of 2012 (discovered by one of the Skype engineers much earlier).

    For those who haven't heard of it - this vulnerability allows an attacker to passively disclose victims external, as well as internal, IP addresses in a matter of seconds, by viewing the victims VCard through an 'Add Contact' form.

    Why is this useful?

    1. Verifying the identity and the location of the target contact. Great when performing geo-targeted phishing attacks.

    2. Checking whether your Skype account has not been used elsewhere :)

    3. Spear phishing enumeration while Pen Testing.

    4. Just out of plain curiosity.

    To get this working, following these basic steps:

    1. Download and install the patched version of Skype 5.5 from here (the patch enables the Skype client to save the logs in non obfuscated form)

    2. Save the lines below as a Skype_log_patch.reg reg file:

    Windows Registry Editor Version 5.00
    Once saved, run it to enable the Skype Debug Log File.

    4. Start Skype.

    5. Search for any Skype contact and click on the 'Add a Skype Contact' button, but do not send the request, rather click on the user to view their VCard.

    4. Open the log file (it should appear in the same folder as Skype executable e.g. debug-20121003-0150)

    5. Look for the PresenceManager line - you should see something similar to this - >

    In the above image you can spot my Skype name, external as well as internal IP addresses.

    The log will include similar credentilas for everyone listed as a "contact" under your Skype account, as well as many other fresh, genuine and useful information received directly from your local Skype tracker.