PHP Weak Typing Woes — With Some Pontification about Code and Pen Testing

By Josh Wright

The other day I was reading Jos Wetzels‘ post on the Full Disclosure mailing list regarding a vulnerability in the open source social networking kit HumHub.  One of the issues he pointed out was a PHP ‘type juggling’ attack where an attacker can force a password reset against HumHub for a user many times until a specific value is selected that reduces the password entropy (uniqueness), allowing her to access accounts without authorization.

I have not previously worked with HumHub, but the illustrative code Jos pointed out was intriguing (press CTRL+C to close the cat output after the closing PHP ?> tag):

$ cat >bahhumhubbug.php 
 if (md5('240610708') == md5('QNKCDZO')) {  print "Yes, these are the same values.\n"; 
$ php bahhumhubbug.php 
Yes, these are the same values.

Huh? No, those are not the same values:

$ echo -n 240610708 | md5sum 
$ echo -n QNKCDZO | md5sum 

The issue here is related to how PHP performs type checking.  Being the friendly language it is, PHP attempts to convert variables of different types in a way that makes comparison work as the programmer might expect*.  For example, consider this “math”:

$ cat >math.php
<?php print('5' + 8); ?>
$ php math.php

Here, PHP adds a string ‘5’ to the integer 8. This is intuitive for a lot of people, since 5+8 is indeed 13.  The magic of PHP is that these two values are of different types, but PHP accommodates the addition anyway.  Contrast this with a strong typed language like Python:

$ python -c "print '5' + 8"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: cannot concatenate 'str' and 'int' objects

PHP is convenient in this way; if you accept a numeric input in a HTTP POST value, for example, you can treat it as an integer if it fits any of the loose typing rules PHP uses for integers.  For beginning programmers, this allows them to sidestep any type conversion routines necessary to force data into a specific type.

This is all well and good… until it’s not.  Let’s revisit Jos’ code example from before. Why are the two MD5 output values equal to PHP? Because PHP thinks they are numbers:

$ echo -n 240610708 | md5sum
$ echo -n QNKCDZO | md5sum

PHP sees a number (0), followed by the letter “e”, and it converts the MD5 string to exponential notation (e.g. 0462097431906509019562988736854).  Because both MD5 hashes start with “0e”, they both evaluate to 0, making them numerically equivalent.

In the case of HumHub, an attacker can force a password reset without authentication.  HumHub selects a new password using a variety of techniques (which is also problematic, as pointed out by Jos) and MD5 hashes it.  If the resulting password hash starts with one or more zeros, followed by “e” and the rest of the characters are numeric, then an attacker can login with the password “0”.  If the password hash does not match this criteria, the attacker resets it again and keeps trying until they can login.

I posted a note about this on Twitter the other day, and one response from @nicoduck reminding people to stop using MD5 was awesome:

Since SHA1 hashes are longer than MD5 hashes, it is less likely that a randomly selected value will meet the 0 + e + digits rule for PHP to evaluate it as an exponential value.  I left this Python code running on my Mac overnight to test SHA1 hashes for this pattern:

>>> import hashlib, string, itertools, re
>>> for word in itertools.imap(”.join,
itertools.product(string.uppercase + string.lowercase +
string.digits, repeat=8)):
…        if re.match(r’0+[eE]+\d+$’,
…         print word

The itertools.imap() call returns a Python iterable object that consists of all the string combinations of upper and lowercase letters and numbers up to 8 characters in length.  Each “word” is SHA1 hashed and compared to a regular expression to see if it meets the 0 + e + digits requirement.  This routine is only single-threaded, but it was late at night and I was ready for bed.

In the morning, I awoke to this output:


Sure enough, all these strings SHA1 hash to what PHP would consider exponential numbers:

$ echo -n AAPkbYlH | sha1sum 
0e51223820731210116366152413868569204545  -
$ echo -n AAJd1x3j | sha1sum 
00e6811279456694288001763399976992804485  -
$ echo -n AAZlIwOZ | sha1sum 
0e13965443605273185827757762777509208778  -
$ cat p.php 
<?php var_dump((sha1('AAPkbYlH') == sha1('AAJd1x3j')) ==
sha1('AAZlIwOZ')); ?>
$ php p.php 

The Fix

My good friend Tom Hessman pointed out that this problem is not inherent in the PHP “===” operator:

$ sed -i php 's/==/===/' bahhumhubbug.php 
$ cat bahhumhubbug.php 
if (md5('240610708') === md5('QNKCDZO')) {
     print "Yes, these are the same values.\n";
$ php bahhumhubbug.php 

The “===” operator returns true only when the values are equivalent and are of the same type.  That said, I’d be willing to bet that other PHP projects are vulnerable to similar types of bugs, judging from the popular use of “==” in PHP projects.

As an instructor, I know a lot of pen testers out there get to a point in their careers where they are great at using tools, but lack coding skills.  Coding isn’t for everyone**, but if you want to be a great penetration tester, you need to be able to read code from time to time.  I’m not recommending you print out the source code to a popular web app and sit down with a good cup of coffee and read it end-to-end. However, you should be able to make judicious use of grep (or findstr.exe, I won’t judge) and search through source to find interesting bits of information that is worth a second look.  Understanding tidbits about the language you are looking at (like the difference between “==” and “===” in PHP) can be extremely useful:

$ egrep -R "md5|sha" * | grep '=='
     if(sha1($_POST['password']) == $admin_password) {


-Joshua Wright

*As “some programmers” might expect. This programmer finds this weak typing thing bizarre.
**Coding isn’t for everyone, unless you sign up for Mark Baggett’s SANS SEC573: Python for Penetration Testers class. You’d be amazed at how much you can get done with a little Python!

Awkward Binary File Transfers with Cut and Paste

[Editor’s note: Josh Wright spins up another useful blog article about different ways to move files to and from Linux systems.  Lots of nice little tricks in this one.  Thanks, Josh! –Ed.]

By Josh Wright

Sometimes I find myself with access to a remote Linux or Unix box, with limited opportunity to transfer files to my target. I appreciate the “Living off the Land” mentality and relying on locally-available resources instead of adding tools to my host as much as the next guy (or gal), but sometimes I need a binary to get the job done.

Fortunately, I’ve been working with Unix and Linux for a long time, and I remember old techniques back when modems made that horrible screeching sound. As long as you have a terminal, you can upload and download files regardless of other network access… with a little awkwardness.

Encode and Clip

In the example that follows, I’m going to transfer the netcat-traditional “nc” binary to my target system.  I’m starting from Kali Linux, and my target is a CentOS system.  The distribution type makes little difference for these steps, other than ensuring your binary will work on the target system.

Step 1: Compress the Source Binary

Compress the source binary using a method that will be accessible on the target system.  Gzip is usually a smart choice:

-rwxr-xr-x 1 root root 22140 Jun 12 2012 /bin/nc.traditional
root@kali:~# gzip /bin/nc.traditional
root@kali:~# ls -l /bin/nc.traditional.gz
-rwxr-xr-x 1 root root 11197 Jun 12 2012 /bin/nc.traditional.gz

Step 2. Install Sharutils and Xsel

On the attacker system, install  the sharutils and xsel packages (we’ll use them next):

root@kali:~# apt-get install sharutils xsel
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
sharutils xsel
Setting up sharutils (1:4.11.1-1) ...
Setting up xsel (1.2.0-1) ...

Step 3. Alias Pbcopy

Mac OS X has a wonderful tool “pbcopy”, which takes the STDOUT from one program and places the content in the clipboard.  This makes it so you can “cat” a file and send the output to the clipboard without having to highlight everything in your terminal with a mouse.  Linux users have also had this for a while with the “xsel” (and “xclip”) tool.  Create an alias for pbcopy in your login profile so it is always accessible and easy to remember:

root@kali:~# echo "alias pbcopy='xsel --clipboard --input'"
root@kali:~# source ~/.bash_profile
root@kali:~# alias pbcopy
alias pbcopy='xsel --clipboard --input'

Step 4. Transfer the File

With the prerequisites out of the way, we’ll transfer the file to the target system.  First we convert the binary 7-bit ASCII format using the uuencode utility.  Uuencode is the precursor the Base64 or MIME encoding techniques, and it breaks up the ASCII content into 63-character lines that makes it simpler to cut-and-paste than Base64 encoding.  In the example below, we specify the input filename twice – the first is the actual file, and the 2nd is the filename reference inside the uuencoded data:

root@kali:~# uuencode /bin/nc.traditional.gz /bin/nc | pbcopy

Next, switch to your target system, and create a new file using “cat”, pasting the content from the clipboard, and pressing “CTRL+C” at the end of the paste to close the file and return to the shell:

josh@centos:~ $ cat >nc.gz.uu
begin 755 /bin/nc.traditional.gz
josh@centos:~ $

Now we have a file called nc.gz.uu which we want to uudecode.  Do not fear if the target system is missing the uudecode utility — we have Python!

josh@centos:~$ python -c 'from uu import decode; decode("nc.gz.uu", "nc.gz")'
josh@centos:~$ gzip -d nc.gz
mock@centos:~$ chmod 755 nc
josh@centos:~$ ./nc -h
connect to somewhere: nc [-options] hostname port[s] [ports] ...
listen for inbound: nc -l -p port [-options] [hostname] [port]
-c shell commands as `-e'; use /bin/sh to exec [dangerous!!]

This process can get annoying when transferring multiple files, so remember that you can use tar to create an archive of everything you need to transfer first.


Writing this article made me feel old.  I distinctly remember using this same technique back when I was writing articles for Virus Laboratories and Distribution (VLAD) in the 90’s.  That was ages ago, but good tricks die hard.

-Joshua Wright

Using Built-Ins to Explore a REALLY Restricted Shell

By Ed Skoudis and Josh Wright

Josh Wright and I were working on a project recently which involved a target machine with a really restricted shell environment. I’m not talking about a mere rbash with some limits on the executables we could access, but instead a shell so restricted we could not run any binaries at all, save for the shell itself. No ls…  no cat… no netcat… we could access very little. It was some sort of ghastly chroot specter.

Still, Josh and I wanted to explore the target machine as much as we could given these shell restrictions. Of course we could have tried escaping our restricted shell (as Doug Stilwell describes in more detail here) and even doing privilege escalation, but before that, we wanted to just look around. Thankfully, we had many shell built-in capabilities we could rely on.

For the uninitiated, shell built-ins are features of the shell that don’t rely on separate binaries in the system. For example, in bash, commands such as alias, printf, and echo are built-ins, which the shell can do itself, without calling a separate program. While some of these built-ins also have a binary of the same name (/bin/echo for example), your shell can rely on the built-in independently from the binary. Indeed, it can perform the task even if the binary isn’t available. Turns out, you can do a whole lot with these shell built-ins.

A handy list of bash built-ins is available here, and can be quite an inspiration when faced with a task like that before Josh and me.

We started by looking around in the file system, using the following well-known trick as our rough “ls” equivalent:

$ echo *

We then wanted to look at the contents of file.txt, so we ran:

$ while read line; do echo "$line"; done < file.txt
Hello World!
This is a nice file.
Happy Holidays!

We then wanted to search through a file to find a specific string, rather like grep:

$ while read line; do if [[ $line == *"nice"* ]]; then echo $line; fi; done < ./file.txt
This is a nice file.

Want a count of the number of lines in a file (rather like wc -l)? Use something like:

$ i=0; while read line; do i=$(($i+1)); done < ./file.txt; echo $i  

Want your UID number? You should try:

$ echo $UID

Wanna do a whoami? If you have access to the world-readable /etc/passwd, you could build on what we saw above with:

$ while read line; do if [[ $line == *":x:$UID:"* ]]; then echo ${line%%:*}; fi; done < /etc/passwd

Those are just a few of the useful items we performed with built-ins. Got any more you’d like to share? Please do provide them in the comments below.


— Ed Skoudis & Josh Wright

Finding Zero-Day XSS Vulns via Doc Metadata

[Editor’s Note: Chris Andre Dale has a nice article for us about cross-site-scripting attacks, and he’s found a ton of them in various high-profile platforms on the Internet, especially in sites that display or process images.  He even found one in WordPress and responsibly disclosed it, resulting in a fix for the platform released just a few weeks ago.  In this article, Chris shares his approach and discoveries, with useful lessons for all pen testers.  Oh… and if you are going to test systems, make sure you have appropriate permission and don’t do anything that could break a target system or harm its users.  Thanks for the article, Chris!  –Ed.]

By Chris Andre Dale

XSS Here, XSS There, XSS Everywhere!

Today Cross-Site Scripting (XSS) is very widespread. While it is not a newly discovered attack vector, we still see it all the time in the wild. Do you remember back in the days, when you would click on a website’s guestbook, and suddenly you would have tons of pop-ups or redirections happen? Yeah, that’s often XSS for you. Today I see XSS vulnerabilities in almost all of the penetration testing engagements that I conduct.

Even to this very day, there is evidence of old XSS worms stuck on the web. Remember MySpace? Yeah, me neither. Make a Google search for “Samy is my hero”. You will see thousands of ghostly remains of a XSS worm back from  2006! The infamous Samy worm does not still linger, but what you are seeing is the remains of MySpace profiles that were victims of this worm back in 2006.

XSS is usually ranked only as a medium impact when exploited. For instance, OWASP has rated this vulnerability as a moderate impact. I disagree on this. In many cases XSS can be truly brutal and potentially life threatening. What do I mean? When XSS is bundled with other vulnerabilities, such as Cross-Site Request Forgery (CSRF), we can quickly imagine some very nasty scenarios. What if your XSS exploit hooks an IT Operations administrator, and through the XSS you add your CSRF payloads to perform administrative functions to their HVAC solutions? Alternatively, consider the unfortunate event where an attacker has successfully compromised thousands of hosts, using them all to DDOS an unsuspected victim.

New XSS attack vectors arise all the time, however we don’t often see something truly new or untraditional. Wouldn’t it be cool to see something else other than just your ordinary filter bypass? In this article, I’ll cover how I’ve successfully found 0-day exploits in WordPress, public sites and plugins for popular CMS systems, by merely using using this technique.

Let’s take a look at embedding XSS payloads into image metadata, more specifically EXIF data in JPEG images. This can be accomplished several ways. If you are old school (or perhaps just old :), you can accomplish this by modifying your camera settings:

The camera type used here is a Canon(1) camera.

Any hacker with any respect for themselves, uses ExifTool(2) by Phil Harvey to accomplish the task. The following command allows us to add/overwrite an exif tag, specifically the camera type that has allegedly been used to take this photograph:

exiftool.exe -"Camera Model Name"="// " "C:\research.jpg" 

Let’s not just add the model name, let’s extend it to other values as well:

As you can see, we’ve added the standard javascript alert code to a whole set of different EXIF data fields. Now we’ll create a simple PHP script that will mimic a real world example of a system that uses EXIF data:

$filename = $_GET['filename'];
echo $filename . "
$exif = exif_read_data('tests/' . $filename, 'IFD0');
echo $exif===false ? "No header data found.
\n" : "Image contains headers
$exif = exif_read_data('tests/' . $filename, 0, true);
foreach ($exif as $key => $section) {
    foreach ($section as $name => $val) {
        echo "$key.$name: $val

The above script will simply iterate through all EXIF data keys it finds and will output the respective value. For testing purposes, this is exactly what we want.

PHP’s EXIF parser does not have filtering in place by default, making it very interesting to test this attack vector. In cases where a developer has forgotten to do sanitization on these fields, we may have a successful attack. Developers think, in many cases, that some of their data is read-only, so why would they EVER need to sanitize it?! Common mistake…

Using the script above, and armed with our the metadata-bombed picture, we can try to attack ourselves through the demo script. In the following picture, we have told the script to fetch our metadata-bombed picture, simply illustrating the attack with a JavaScript pop-up:

So what? We’ve successfully attacked ourselves with a pop-up message? Well, there is so much more to this than just attacking ourselves. First of all, we’ve verified that there is no built-in filtering in the PHP exif_read_data function. That means that all developers need to remember is to apply filtering manually, and as we covered before, we all know that developers always remember this… Secondly, we’ve verified that we can gain executable JavaScript in someone’s browser. From here, we can simply rewrite our pop-up payload to something much more subtle and evil, such as introducing a BeEF hook. More on this later.

Scouring For 0 Day’s

Armed with a fully metadata-bombed picture, I set sail into the Wild Wild Web. I had to check whether my assumptions of developers failing to sanitize the EXIF data was true or not. From there, I roamed into the depths of picture upload sites… I started googling “upload picture”, “picture sharing”, “photograph sharing” and much more. On the sites that I found interesting, I registered an account and started uploading my pictures.

On a side note, Mailinator(3) comes in handy doing this kind of research. In fact, I registered with the account for most of the sites, however, to my great surprise, one of the sites already had an account with this username! What?! Someone had actually registered with this account before? Then undoubtedly, I could do a password reset! Sure enough, doing a password reset, I gained access to someone else’s account. Whew… Now, who would EVER register an account on a Mailinator address for their private pictures? Another security researcher? Criminals? Where do I go from here? Do I really want to venture into someone else’s account? If so, what will I find? Regardless of my questions and doubt, I decided to continue, knowing surely that there is no turning back from what I might be about to see.  To my surprise, and more importantly, to my relief, the site contained a bunch of family vacation pictures from a trip to Indonesia.

Many of the sites required registration, while many of them did not show any metadata at all. Out of 21 sites tested, 11 sites did not have a feature to display EXIF data, 7 sites had at least rudimentary filtering and 3 sites were found to be vulnerable. Not amazing numbers, however still fun to see it working in the wild, outside of my lab. What do I mean by rudimentary filtering? Well, it just means I didn’t try to bypass the filtering. Additionally, I tested the attack vector on 3 WordPress plugins, whereas 2 were found vulnerable and one had the appropriate filtering in place. Responsible disclosure against the sites and plugins has been conducted. Some of the examples in this article have been anonymized because as of the launch of the article, they have still not patched the issue.

Keep in mind, many of the sites that were applying filtering could still be vulnerable. I did not conduct any filter bypass in my testing. My gut feeling is that the filters were very rudimentary and could easily be bypassed.

First, here is an example from which was not found to be vulnerable:

You can see the payload present in the title and the camera is automatically populated by the site. That means that instead of prompting me to set a title for my picture, the site used one of the EXIF data fields to pre-populate it for me. Interesting…this was something I saw as a repeating characteristic when doing my testing.

Flickr also did appropriate filtering, keeping in mind, no filter bypass has been tried:

One particular site did not like my testing at all. When trying to upload my picture, it seemed to break something:

Anyway, we’re not here for the failures, are we? We’re here for the success stories! Ahh, this is the wonderful world of hacking…gaining success through other people’s failures… *evil grin*

Here is a site where we can see our attack manifest itself.  Just by uploading the picture and then viewing it, it triggers this vulnerability:

I also found the same vulnerability at other sites. We can see the image I’ve uploaded in the background — a princess and a unicorn. Sadly, no farting rainbows…

Many of the big sites were also tested, such as Google Plus, DeviantArt, and Photobucket. These were all applying some filtering.  A site, however, that did not apply the necessary filtering was WordPress.

In the screenshot above I’ve successfully uploaded an image, by accessing it through its respective attachment page. Remember, I am using a harmless payload, just alerting a text message. This could be a completely stealthy attack payload if I wanted it to be. Let’s dive further into the WordPress finding.

The WordPress Exploit

WordPress is the most popular blogging platform on the internet today, ranking up more than 60 million websites in 2012 (4). Finding working exploits in such a platform can be very interesting for many actors, hence they also have a working bug bounty program (5). The vulnerability I’m demonstrating in this paper has been submitted to WordPress through responsible disclosure, and we held this article until they had properly patched the issue.

The WordPress vulnerability manifests when an administrator, or editor, uploads an image with the ImageDescription EXIF data tag set to a JavaScript payload. The exploit works only for the user accounts as more strict filtering is put on the other accounts. This has sparked some controversy about this vulnerability, however, as I will prove in this article, we will create an attack that is fully stealthy, allowing the attack to take place without an administrator knowing what is going on.

Why the controversy? With WordPress, and other CMS  systems such as Sharepoint, some roles are allowed to upload HTML elements. With WordPress, administrators and editors are allowed to implement unfiltered HTML (6).  The other side of the controversy is how the attack can be made super stealthy. The administrator has very limited ways to realize that he is doing something wrong and actually uploading malware into his site. Now, that’s cool! This is also why WordPress has chosen to patch this issue.

Embedding some JavaScript into the tag and then uploading it will trigger the vulnerability once a user views the attachment page of the image. Using Exiftool, you can accomplish this with the following command:

Here I’ve changed my JavaScript payload to a reference instead of embedding the JavaScript file itself in the image. This will give us increased flexibility when creating working payloads.

exiftool.exe -"ImageDescription"="<script src=\"\">" paramtest1.jpg

The following example is one of my first runs of the attack. It is not stealthy as the administrator can easily pick up that something is wrong, simply by looking at the title element of the page. WordPress uses the ImageDescription element to populate the title element, and properly filters before doing so. We’ll see soon how to bypass this.

The attack works when you navigate to the attachment page, however any WordPress editor with IQ higher than their shoe-size would most likely realize that something is fishy, immediately deleting the picture. If we stopped at this point, I don’t think the issue would warrant a patch or much attention at all, however the next steps allows us to go into stealth mode.

If I figured out a way for the payload to be embedded, but without the title element being overridden, I could make the attack feasible. Luckily, I discovered a small artifact when doing the testing. Trying different types of encoding, and other obfuscation techniques, produced some really long strings. When producing a long enough string, I noticed that WordPress suddenly defaulted to using the filename as the title element! Nice!

The following Exiftool command makes WordPress ignore the ImageDescription, allowing a more stealthy attack:

exiftool.exe -"ImageDescription"="

<script src\"\"></script>" paramtes1.jpg

Notice all the extra spaces. This extra padding makes WordPress think that this is too long for the title field, thus defaulting to simply using the filename. The attack now manifests more beautifully when we upload the picture:

The picture loads normally. Our XSS vector is currently invisible. Here is what happens when someone, e.g. the administrator, visits the picture:

The screenshot shows how I’ve successfully included my malicious JavaScript. This could be a simple BEeF(7) hook, allowing us a very high level of control of the victims. From here, it’s game over.

Best Regards, Cross-Site Scripting

Why stop at EXIF data? What about other types of data, perhaps not in the same magnitude as online EXIF parsers, but let’s look at embedding XSS into other data.

What if a webpage allowed you to upload a Word document , and it would then automatically extract the Author field of the document and embed it on the site? That could definitely lead to a vulnerability. It sounds like a good vector for a XSS attacks, or even other types of attacks such as SQL Injection if they store the information in a database. When I look at the document I’m writing right now, I can see the following metadata information:

Without a doubt, many of these parameters can easily be changed by the user, either through Exiftool or using the word processor itself. The following example shows editing the username to a XSS payload. I do apologize for the Norwegian text; I’ve been cursed with a Norwegian installation of Windows and Office by my IT-department.

Pictures and documents. What about audio? Here is an example adding XSS to an mp3 file through the awesome free, and open-source, tool Audacity (8):

There are probably tons of other situations where we can add these types of attacks.  It’s up to us to find them before the bad guys does.


Let’s consider the future. The data we embed in metadata today might, sometime in the future, exploit services that has not yet been developed. Perhaps, we’ll see XSS shooting out from projectors, chat services, glasses (e.g. Google Glass) or robots going crazy having alert(1)’s all over the place. Or perhaps even cooler, your files embedded with XSS today might someday, in the future, trigger a callback connection straight back to your BEeF hook…

The bottom line is, data coming from a third party system, being a user or another system, should be sanitized! You know that whole concept of garbage in, garbage out? Let’s stop that.

Additionally, it is important for pen testers to have this information in their arsenal when doing their testing. The testers need to think outside the box and cover as much testing surface as possible.

Also, Ed Skoudis had a student who mentioned some great research that has been made on sites processing metadata. I recommend checking out the research done at (9). It might spark some further testing and research for some of our readers.

Now, go onward my friends and…



-Chris Andre Dale

Pen Test Hackfest Talks – Some GREAT Reads

A couple weeks ago, we held our annual SANS Pen Test Hackfest, a really wonderful event where we run 3 nights of NetWars challenges, 1 night of CyberCity missions, Coin-a-palooza (where attendees can earn SANS Pen Test Coins for classes they’ve taken before), and much more.  This year, we even went on a field trip to the National Cryptologic Museum, where we enjoyed my wife’s fresh-baked cookies, an ice cream sundae station, and an open bar.  Yes… at the museum, which was chock-full of cryptographic treasures including Enigma machines and more.  The museum trip was incredible, sharing such amazing history with over one hundred great friends.

But, the single best part of the SANS Hackfest is the great speakers who share incredibly useful tips, techniques, strategies, and utterly awesome knowledge with attendees.  The whole goal here is to help us all do more powerful, technically in-depth, and business-valuable pen testing.  Our presenters this year really knocked my socks off, and I think you’ll enjoy checking out their advice in their presentations included below.  I’m deeply grateful to each and every one of them.

Here are the slide decks from each of the presenters… they are all fantastic.  In fact, if you want to just download a big ol’ ZIP file with all the talks in it, click here.  The featured talks included:

Some of the audience favorites among this highly esteemed group of talks are:

Many thanks to our presenters for their fantastic work.

It took us 12 months to plan the 2014 Hackfest.  We’re now diving in to plan the 2015 Hackfest, and we’ve got some really amazing ideas for it to make it EVEN better.  It’ll be in the DC area in early November 2015.  I do hope you’ll consider joining us for something really special next time around.


–Ed Skoudis
SANS Fellow, Instructor, & Pen Test Curriculum Lead
Founder, Counter Hack Challenges