Winners of the SANS Spectacular Pen Test Video Contest

Ladies and gentlemen, boys and girls, friends, Romans, and countryman,

I’m delighted to announce the winners to our  SANS Spectacular Pen Test Video Contest.  Back in January and February, we asked folks to channel their creativity to share some great tips, insights, techniques, and inspiration with other penetration testers.  You can read the contest description here.

We got some FANTASTIC entries, and we’d like to thank all who participated.  Entries included numerous great technical tips, interesting “acting”, noble attempts at humor, and even one Rick Roll, naturally.

So, without further ado (thanks, Ted, for your gracious input), let’s announce the winners (click on each picture to see the video).  We’ll announce the victors in our four categories first, and then select from among them for the GRAND prize winner.

First up, our  highest production values (with a useful tip)  award goes to Chris Andre Dale for his epic video  Local File Inclusion.  In addition to some great start-up graphics and sound effects, Chris explains the issue of local file inclusion in clear, understandable terms, performing a great demo.

Our  most useful tip award  goes to Jeremy Galloway (also known as xgermx)!  His video on  Scanning Your Network for Reflective Amplification DDoS  issues describes the vulnerabilities, the use of the Nmap Scripting Engine to find some flaws, and the use of Metasploit to find others.  And, his inclusion of ultra funky slow jam music during his attacks was an awesome touch, along with some great zoom-in action to see his command lines.

Our  most entertaining (with a useful tip)  award goes to Kirk Hayes, for his magnum opus,  Don’t Fret… Introducing Veil.  The creepy voice-over, the head pounding on the desk, the big FAIL arrows, and more all work together to make it a thoroughly entertaining vid.

Random draw goes to Mario R. De Tore, who provided this gem:  Ahhh… that one never gets old.

Each of our four winners above will get an autographed copy of the book Counter Hack Reloaded.

But, one and only one video will be awarded the coveted GRAND prize, a free four-month journey through NetWars Continuous.  During this four month span, the winner will be able to build skills, solve fun and exciting challenges, and earn valuable CMUs/CPEs.  The GRAND PRIZE WINNER is…. drum roll please…

Jeremy Galloway (that’s XGERMX)!  While all the winning videos were great, this video covered a lot of really useful skills in a short-duration format.  It included some great Nmap and Metasploit kung fu, as well as useful zoom-ins to see the action.

Thank you all for participating!  We’ll be reaching out to the winners shortly.

–Ed Skoudis.
Author,  SANS Security 560, Network Pen Testing & Ethical Hacking
SANS Instructor, Fellow, and Pen Test Curriculum Lead

SANS Checklist for Securing Mobile Devices in the Enterprise

[Editor’s Note: Lee Neely has developed a very useful spreadsheet checklist to help organizations better plan and mitigate security risks associated with mobile devices, including phones and tablets.  It’s really handy stuff, and I strongly recommend you check it out!  –Ed.]

By Lee Neely

To help organizations better understand, manage, and mitigate risks associated with mobile devices and their infrastructures, we’ve released an updated  SANS SCORE Mobile Device Checklist.  This checklist is designed to provide a repeatable approach to adding mobile devices to your environment in a secure fashion. The intent is to be device agnostic, to support long-lasting results, and to provide a basis for making consistent decisions around having these devices in your environment, as well as proper protection of the information on and around them. Too often, I’ve seen instances where mobile devices were brought into the workplace without consideration of all of the aspects of safely incorporating these devices.  Disaster often ensues.

I have a bias around both physical use and disposition (lifecycle) of mobile devices, due to my background in U.S. Government Cyber Security. For the public sector, consider these devices as an uncleared visitor in the room who is listening and recording.  This analogy, though, useful elsewhere.  For private sector, consider mobile devices as a live webcam in the closed session of your board meeting.  Ask yourself what (unauthorized) information is leaving the room and where it is being stored. There are ways to mitigate this risk, depending on your risk appetite. We’ve provided the checklist to help you think through these issues.  We also hope the checklist helps inspire conversations with management and users to aid management in making a conscious decision that will achieve necessary protections, while allowing the devices to remain useful.

In this case, by mobile devices, I am referring to smartphones and tablets rather than laptops. I see tremendous growth in technology and capabilities for these devices.
This checklist is designed to be simple, non-threatening, and easy to use. It is organized into tabs related to various aspects of mobile devices including Policies, Lifecycle, Security Settings, Applications, COPE, BYOD and References. Each tab has a list of areas to consider such as: understanding use cases, performing risk assessments, policy, training, operational models, physical presence, etc. with the intent of recording decisions on each as a basis to plan your adoption and implementation. Some of the tabs are linked together where more in-depth consideration is warranted. These items are also intended to encourage thoughts about anything else that should be included in the list. I’d love to get feedback on ways to make this tool more useful.

This update also includes a new tab relating to COPE, more application security and device forensic information, as well as updated references. This version doesn’t cover Samsung KNOX or BlackBerry Balance. Both are forms of sandboxing, which is covered in a more general way, and whose specific future is unclear right now. Time will help. I’m not sure when it will be time to address NFC, or the larger question of using these as payment devices, particularly in a corporate environment.

Many thanks to all who contributed to the checklist, and I am looking forward to your comments.

You can download the checklist here:  SANS SCORE Mobile Device Checklist

-Lee Neely

p.s., If you really want to take a deep dive into mobile device attacks and defenses, please check out the excellent SANS SEC 575 course, which provides in-depth, hands-on experience in securing Android, Apple iOS, and other related technologies.  There are sessions upcoming on the following dates and locations:

April 28 in Austin, Texas

May 8 in San Diego, CA

June 16 in Berlin, Germany

Tor-nonymous – Using Tor for Pen Testing

[Editor’s Note: In this article, Chris Crowley provides some really useful tips for using Tor to anonymize your penetration testing.  He provides details on strategy and tactics, along with some helpful configuration settings and scripts.  His discussion of Privoxy is especially useful.  Thanks, Chris!  –Ed.]

By Chris Crowley

Pen testing derives its value from being able to emulate the behavior of real world attackers. We pen testers need to train ourselves to behave like those with malicious intent, but simultaneously maintain appropriate decorum and sensitivity to the operations of the networks we’re trying to improve. Malicious attackers have no such restrictions.

This post is to share a method I use for obscuring the source IP address of my computer. Pen testers have two basic reasons for obscuring their source IP address. First, is to connect to malicious (or suspected malicious) resources when we perform research. Second, is to obscure the source of our pen testing recon or attack activities.

In order to study the behaviors of a malicious attacker, or a piece of malware, we might want to connect to an attacker controlled resource. Here’s one common scenario for this: Users are being compromised via a social media link that is making the rounds on facebook or a similar social media site. We’re not certain how the attacker is successfully compromising the end point system. The initial page has a lot of additional links and javascript. Since we plan to utilize a similar technique for an upcoming pen test, we would like to browse through the experience in the same way that a user would. Of course, we don’t want to be identified by the bad guy.

Connecting to known malicious sites from our own IP address is not advisable. Reaching out to the attacker’s resource divulges the source IP of our systems, notifying them that we’re interested in their host. Further, if we were to send the sort of requests that a compromised system would send, (such as beaconing or some other call back mechanism) this would indicate to the bad guy that the system we’re connecting from is compromised. This invites unwanted connections back to us, so it is useful to obfuscate the source IP of the traffic we generate.

Sometimes malware only runs when it can reach out to its command and control (c2) channel. We could spend a lot of time setting up our lab to provide the c2 with the malware expects, but it would be much faster to let the malware run so it can connect to the real c2. But, we don’t want the residual attention that would come from the attacker attempting to utilize this compromised host for some subsequent activity. We want the information. We want to profile the attack methodology. We want to see the action of the attack. But, we want that connection to be severed as soon as we’ve gathered the information we’re after.

Attackers have disposable systems. They don’t identify themselves by IP address. During a pen test (with appropriate approval from the customer, of course) using an IP address that is unexpected or unattributable is desirable and is an effective emulation of a real world attacker. Here are a few scenarios that come to mind for this. First is website recon. A malicious party probably isn’t going to use the same IP address for the initial web app scanning as the ultimate attacks on the web app. Second scenario is service scanning. If you’ve looked at firewall logs for an ISP facing firewall lately, you know that there is incessant scanning for most ports on your network. A few ports are the highest priority, but the scans come from all over. Attackers use throw away IP addresses to perform the initial identification of targets, then use other IP addresses to actually perform the exploitation. The real bad guy steals sensitive information. That’s the ultimate goal of his efforts. Is he going to provide his own name and address on that return package? Not if he is smart! He’ll use a series of systems to make it difficult to provide attribution. Fourth, is something that will be more common for pen testers over the coming years. Pen testers will more frequently be tasked to identify the risk associated with applications deployed on mobile devices. Mobile or legacy (yes, I just called laptops and workstations legacy compute devices) application assessments can be performed using anonymized network connectivity.

The process outlined below can be performed in a number of different ways. I’ll outline one method that will work, and you can adjust as needed, to suit your needs.

There’s been a lot of attention in the news about government agencies taking advantage of flaws in implementations of Tor (for example see and  Basically, for our purposes Tor is good enough. If you’re looking for an article on how to evade nation states monitoring Tor traffic, I’m afraid you’re going to have to look elsewhere.

Here are the basic steps:

1. Install and Set up Privoxy.
2. Install and Set up Tor.
3. Configure Privoxy to chain to Tor.
4. Get the traffic to go into the proxy.

Although I use this set up on a linux system, you can adjust the instructions to whatever OS you want to use. It will work for Windows or OS X, as well. Privoxy and Tor are going to provide a transport that facilitates communication from an “exit node” from the tor network that is different than your IP address. If someone had access to observe your network traffic enter the tor network, it is possible that party could watch where you communicated to. But, that’s not our concern in the scenarios I’m addressing here. What we’re concerned about is the termination of the communication from our system so it does not know the source of the IP traffic.

  1. Install and Set up Privoxy

According to the Privoxy website (, “Privoxy is a non-caching web proxy with advanced filtering capabilities for enhancing privacy, modifying web page data and HTTP headers, controlling access, and removing ads and other obnoxious Internet junk. Privoxy has a flexible configuration and can be customized to suit individual needs and tastes. It has application for both stand-alone systems and multi-user networks.”

It is very straightforward to install. Use the directions provided at for your operating system. Or in my case, I used the built-in repos on Fedora to install it:

yum -y install privoxy

You could choose to run polipo, or another HTTP proxy instead.

2. Install and Set up Tor

According to the Tor project page (, “Tor was originally designed, implemented, and deployed as a third-generation onion routing project of the U.S. Naval Research Laboratory. It was originally developed with the U.S. Navy in mind, for the primary purpose of protecting government communications. Today, it is used every day for a wide variety of purposes by normal people, the military, journalists, law enforcement officers, activists, and many others.”

If you’re looking for background on how tor works, read this page:

Once your curiosity is sated, or patience exhausted, download and install the program per the instructions here:

Now read the warnings about the limitations of Tor:

This isn’t necessary, but if you’re more than a bit paranoid about this, or suspect that the connection isn’t working because your ISP blocks connections to the tor network, look at establishing connections to a tor bridge first:

3. Configure Privoxy to chain to Tor

DNS is the primary reason I choose to utilize Privoxy in conjunction with Tor. If I want to manage the DNS requests associated with the hosts I’m attempting to connect to, so that  the information about the source of the requests isn’t provided to the target, I can approach this from a different perspective, and utilize an alternate, public, DNS server (such as But privoxy also gives us some added capability for blocking types of requests. It also attempts to prohibit requests that might divulge our IP address or location.

The configuration is relatively straightforward. In Linux, you simply configure the chained proxy setting, and privoxy will redirect the DNS and HTTP requests it needs to perform into the Tor network.

This is the privoxy config line for forwarding to tor:
forward-socks5 / .

Here’s my whole privoxy config file settings, without the comments. This is basically plain, except listening on all interfaces and enabling the tor forwarding.

$ grep -v "^#" /etc/privoxy/config
confdir /etc/privoxy
logdir /var/log/privoxy
actionsfile match-all.action # Actions that are applied to all sites and maybe overruled later on.
actionsfile default.action # Main actions file
actionsfile user.action # User customizations
filterfile default.filter
logfile logfile
listen-address :8123
toggle 1
enable-remote-toggle 0
enable-remote-http-toggle 0
enable-edit-actions 0
enforce-blocks 0
buffer-limit 4096
forward-socks5 / .
forwarded-connect-retries 0
accept-intercepted-requests 0
allow-cgi-request-crunching 0
split-large-forms 0
keep-alive-timeout 5
socket-timeout 300

4. Get the traffic to go into the proxy

a) Configure a command line environment variable (http_proxy, https_proxy, ftp_proxy), and command line tools will use the proxy.

For example, wget: wget is a command line web browser. It is able to make requests, recursively and across domains too, for pages that you specify.  For example:

$ export http_proxy=
$ wget -nc -nd

In this case, I want to get Josh’s subscription list for RSS feeds, but I don’t want him to realize it is me. I do this via a cron job every minute or so from most of my computers ( * * * * * wget -nc -nd ) just in case something changes on that page.

Now, wget is a well behaved webbot. It will first request the robots.txt file from the website that you direct it to, and abide by any specifications within that file. Also, wget has the -nc option that I used in the previous example. That means “no-clobber” or don’t overwrite any files I’ve already downloaded. In fact, it downloads it and doesn’t keep it, which is the same net affect. How does wget know which files have already been downloaded? It looks at the filesystem, of course. So, “touch robots.txt; wget -nc -nd” will tell wget not to retain the robots.txt from, but to use the one that’s already on the file system that is blank. I’m just saying.

b) Start your android emulator with the -http-proxy option.

Having a fully functional android emulator capable of running the actual apps that you need to assess as part of a software assessment pen test engagement is a nice shortcut. When you launch the android emulator using the emulator command, one of the many options is “-http-proxy ipaddr:port”.

Make sure you have the privoxy running first. If the android emulator can’t access the proxy port, it will disregard the setting. It says so in a warning, but that command line window is overwhelmed with the graphical depiction of the emulator.

For example:

emulator -avd IceCreamSandwich -partition-size 256 -qemu -http-proxy

Now, all traffic originating from the emulator will be automatically redirected into my privoxy–>tor arrangement.

One critically important note for this: have your privoxy listener up and running prior to launching the emulator. If the emulator is unable to connect to the proxy port at launch, it ignores the proxy option, and the emulator will use the system’s native stack for communication, potentially exposing the source IP address.

c) Configure an application (or device) to use the proxy.

The http_proxy (et al) environment variable is very useful for command line based tools. Most tools will honor that variable. But, graphical tools likely have their own proxy settings and don’t look at the BASH environment variables. So, you can use the configuration of that application to connect into the proxy. Chrome for example:

  • Open chrome, enter “chrome://settings/” in the URL bar
  • Select “Show advanced settings…”
  • Under the Network section, click the “Change proxy settings…” button
  • Configure the HTTP and HTTPS sections as manual proxies to

(There are analogous settings in all major web browsers.)

d) Snarf the traffic using iptables rules.

If your app doesn’t honor the command line proxy environment variables, and you don’t have a way to change the configuration within the application itself, you can potentially manipulate the network traffic via the iptables utility within linux to forcibly rewrite the traffic using NAT rules.

Here’s a BASH script that I use for things like this.

if [[ "$wai" != "root" ]]
    echo "
You need to be uid 0. Re-run as:
sudo $0
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8123
iptables -t nat -A PREROUTING -p tcp --destination-port 443 -j REDIRECT --to-port 8123
pgrep -fl privoxy 2>&1 > /dev/null || echo "Are you sure privoxy is running?\nOr maybe you intend to use something else I didn't check for."

After I think I am set up, I test first to be sure that it is working. A simple “wget” will suffice. I run “tcpdump -Xnnv -i eth0 port 80 or port 443 or port 53” to monitor because there should be no traffic on those ports if my proxy config is working properly.

Note that my request (which actually originates from a bunker somewhere beneath the frozen mid-west) redirects to because of the exit node in use with tor.

Now go do your evil thing, my penetration testing friend! Make sure you have permission to assess whatever it is you’re assessing. For example, you might want to inspect the interoperability of a prospective piece of software with your home network.

And now that you have some degree of anonymity (and appropriate permission to perform your assessment), you might: spider or scan a target web server; download malware you’re interested in learning about; or run the application you’re assessing for a client and not divulge the source of the inspection.

-Chris Crowley