SANS Pen Test Poster: Pivots Payloads Boardgame


We are excited to introduce to you the new SANS Penetration Testing Educational Poster, “Pivots & Payloads Board Game”! It is a poster and a board game. How is it a board game? You can lay it down on a table, cut out the game pieces and game modifiers, use a dice to move your piece around the board…and play with your friends, colleagues, and/or family.

The board game takes you through pen test methodology, tactics, and tools with many possible setbacks that defenders can utilize to hinder forward progress for a pen tester or attacker. The game helps you learn while you play. It’s also a great way to showcase to others what pen testers do and how they do it.

We have made the poster/board game available to download, with additional downloads of the cheat sheets, game pieces, and game modifiers. We will add additional content to this blog page as we continue to evolve the board game and improve on it in future versions.

Download PDF of Pivots & Payloads:



Additional Pivots & Payloads:

Desktop Wallpaper



Game Pieces – Print PDF


Cheat Sheets – Print PDF




Pen Test Cheat Sheets:

SANS Pen Test Training:

SANS Pen Test Posters:

Build your Skills (Free):

SANS Penetration Testing Webcasts (YouTube):

Upcoming SANS Special Event – 2018 Holiday Hack Challenge


SANS Holiday Hack Challenge – KringleCon 2018

  • Free SANS Online Capture-the-Flag Challenge
  • Our annual gift to the entire Information Security Industry
  • Designed for novice to advanced InfoSec professionals
  • Fun for the whole family!!
  • Build and hone your skills in a fun and festive roleplaying like video game, by the makers of SANS NetWars
  • Learn more:
  • Play previous versions from free 24/7/365:

Player Feedback!

  • “On to level 4 of the #holidayhackchallenge. Thanks again @edskoudis / @SANSPenTest team.” – @mikehodges
  • “#SANSHolidayHack Confession – I have never used python or scapy before. I got started with both today because of this game! Yay!” – @tww2b
  • “Happiness is watching my 12 yo meet @edskoudis at the end of #SANSHolidayHack quest. Now the gnomes #ProudHackerPapa” – @dnlongen

So You Wanna Be a Pen Tester? 3 Paths To Consider (Updated)

Tips for Entering the Penetration Testing Field

By Ed Skoudis

It’s an exciting time to be a professional penetration tester. As malicious computer attackers amp up the number and magnitude of their breaches, the information security industry needs an enormous amount of help in proactively finding and resolving vulnerabilities. Penetration testers who are able to identify flaws, understand them, and demonstrate their business impact through careful exploitation are an important piece of the defensive puzzle.

In the courses I teach on penetration testing, I’m frequently asked about how someone can land their first job in the field after they’ve acquired the appropriate technical skills and gained a good understanding of methodologies. Also, over the past decade, I’ve counseled a lot of my friends and acquaintances as they’ve moved into various penetration testing jobs. Although there are many different paths to pen test nirvana, let’s zoom into three of the most promising. It’s worth noting that these three paths aren’t mutually exclusive either. I know many people who started on the first path, jumped to the second mid-way, and later found themselves on path #3. Or, you can jumble them up in arbitrary order.

Path A: General Enterprise Security Practitioner Moving to Penetration Testing

First, you could parlay a job in the security group of an enterprise (whether a corporate, government, or educational position) into vulnerability assessment and then penetration testing. For example, today, you may be a security auditor, administrator, analyst, or a member of a Security Operations Center (SOC) team. Tell your management that you are keenly interested in vulnerability assessment and penetration testing, and offer your support in existing projects associated with those tasks. You might have to start by taking one for the team and putting in your own hours in helping out, without getting a break from your “regular” job. Consider this extra time an investment in yourself. At first, you could help with tasks such as project scoping, false positive reduction, and remediation verification. Later, offer help in preparing a high-quality penetration testing report. Over the space of several months or even a year, you’ll demonstrate increasing skills and can ask management or other groups in your enterprise for a move more directly in the heart of penetration testing work.

Path B: Working for a Company or Division that Focuses on Penetration Testing

There are many companies that provide third-party penetration testing services to other companies, including organizations such as Verizon, Trustwave, and FishNet Security. Many of these organizations are looking to hire exceptional penetration testers, especially those who have experience. If you have no direct penetration testing experience, you may still want to try your hand by applying for a junior role in such organizations. A solid background in secure networking, development, or operations will prove helpful. But, if experience is absolutely required, consider moving through Paths A or C to hone your skills before jumping to Path B.

Path C: Going Out on Your Own

If you are more entrepreneurially minded, you may want to consider forming your own small company on the side to do vulnerability assessment for local small businesses, such as a local florist or auto mechanic. Start with just vulnerability assessment services, and build your skills there before going into full-blown penetration testing. There are a couple of huge caveats to take into account with this path, though. First off, make sure you get a good draft contract and statement of work template drawn up by a lawyer to limit your liability. Next, get some liability and errors & omissions insurance for penetration testing. Such protection could cost a few thousand dollars annually, but is vital in doing this kind of work. Once you’ve built your vulnerability assessment capabilities, you may want to gradually start looking at carefully exploiting discovered flaws (when explicitly allowed in your Statements of Work) to move from vulnerability assessment to penetration testing. After your small business is humming, you may decide to stick with this path, growing your business, or jump into Paths A or B.

Regardless of whether you go down paths A, B, C, or your own unique approach to entering the penetration testing industry, always keep in mind that your reputation and trustworthiness are paramount in the information security field. Your name is your personal brand, so work hard, be honest, and always maintain your integrity. Additionally, build yourself a lab of four or five virtual machines so you can practice your technical skills regularly, running scanners, exploitation tools, and sniffers so you can understand your craft at a fine-grained level. Learn a scripting language such as Python or Ruby so you can start automating various aspects of your tasks and even extend the capabilities of tools such as the Metasploit framework. And, most of all, give back to the community by writing a blog, sharing your ideas and techniques, and releasing scripts and tools you’ve created. You see, to excel in pen testing, you can’t think of it as a job. It is a way of life. Building a sterling reputation and contributing to others is not only beneficial to the community, but it will provide many direct and indirect benefits to you as you move down your path from new penetration tester to seasoned professional.

Additional SANS Penetration Testing Resources

Watch: WEBCAST – So, You Wanna Be a Pen Tester?


Available Now!
Recorded: 6/19/2108


Upcoming SANS Pen Test Webcasts:

Pen Test Cheat Sheets:

SANS Pen Test Posters:

Build your Skills (Free):

SANS Penetration Testing Webcasts (YouTube):

SANS Pen Test Training:


Upcoming SANS Special Event – 2018 Holiday Hack Challenge


SANS Holiday Hack Challenge – KringleCon 2018

  • Free SANS Online Capture-the-Flag Challenge
  • Our annual gift to the entire Information Security Industry
  • Designed for novice to advanced InfoSec professionals
  • Fun for the whole family!!
  • Build and hone your skills in a fun and festive roleplaying like video game, by the makers of SANS NetWars
  • Learn more:
  • Play previous versions from free 24/7/365:

Player Feedback!

  • “On to level 4 of the #holidayhackchallenge. Thanks again @edskoudis / @SANSPenTest team.” – @mikehodges
  • “#SANSHolidayHack Confession – I have never used python or scapy before. I got started with both today because of this game! Yay!” – @tww2b
  • “Happiness is watching my 12 yo meet @edskoudis at the end of #SANSHolidayHack quest. Now the gnomes #ProudHackerPapa” – @dnlongen

Why You Need the Skills to Tinker with Publicly Released Exploit Code

By Chris Davis

If you are a security enthusiast, like me, then you likely find yourself tinkering with exploit code for most of the major vulnerabilities that are released. This “tinkering” can be incredibly valuable to security researchers, blue teamers, and especially penetration testers. In fact, I frequently find myself modifying and testing public exploit code during penetration tests.

The reason for modifying this code is most often due to the fact that a lot of exploit code written for websites like “” are proof-of-concept scripts that show a concept, but don’t exploit it flexibly or as efficiently as they could. For example, when the Equifax breach came out, I set up a lab with several of the major Apache Struts vulnerabilities from 2017 for testing purposes. CVE-2017-5638 and CVE-2017-9805 were two easily testable exploits thanks to Metasploit having modules available.

Normally Metasploit is highly modular and achieves what I need but that’s not always the case. In this instance, the module in question was limited to reverse call back payloads. While such payloads are very useful, it’s very common for reverse connections from DMZ servers to be blocked. On top of this, it assumes that you also have a public IP to catch the call back on or perhaps in-bound firewall filtering is in place to block bind shells. These are all examples of instances where pulling down publicly released exploit code and modifying it would come in handy.

Problems facing some publicly released proof-of-concept exploit code is that it is often created without giving any major thought to user error, how applications function, or countless other factors. CVE-2017-9805 was a perfect example of this as Metasploit didn’t solve my reverse call back issue. Additionally, the sample public exploit code I found for it didn’t properly handle special characters due to the payload being XML and would break if a user-supplied command contained certain special characters.

Challenges Of Modifying CVE-2017-9805 Exploit Code

The Apache Struts 2 REST Plugin XStream RCE (CVE-2017-9805) uses an XStream handler to deserialize without type filtering of XML payloads. As such, a properly crafted XML payload could allow an attacker to send a specially crafted HTTP request to achieve command execution.

The problem with most of the public exploit code I found was that it wasn’t
object-oriented and simply did string concatenation to insert the user supplied command in-between the XML payload without accounting for special characters that break XML.

A quick example of XML without special characters:


<to>Nick Burns</to>


<heading>Need Help Cant Print</heading>

<body>Cant print out. Need computer help </body>



Now what happens if we pass in special characters as simple as a text emoji of “>_> “?


<to>Nick Burns</to>


<heading>Need Help Cant Print</heading>

<body>Cant print out. Need computer help >_> </body>



The unencoded “>” characters near the end would likely throw off our payload. This is likely to happen in a user supplied command as the greater than symbol “>” is often used to direct standard out to a file in Linux. The XML format uses entity encoding similar to HTML to account for this. For example, if we wanted to encode the greater than sign “>” for XML, we would convert to “&gt;”.

The problem with this encoding when trying to achieve command execution through struts is that it will not interpret these characters to the system as the intended greater than sign “>”; which breaks our command execution.

This means we need to:

1. Encode special characters without using XML encoding

2. Decode that on the command line and execute it without using any special characters that would break XML.

We could base64 encode the user supplied command (since base64 characters don’t break XML) and decode that on the command line into a file, then execute that file with /bin/bash and then remove that temporary file all while avoiding special XML characters. For example, the following one-line command could achieve this:

echo L3Vzci9iaW4vd2hvYW1pIA==| base64 -d | tee -a /tmp/payload.tmp ; /bin/bash /tmp/payload.tmp; /bin/rm /tmp/ payload.tmp

Finally, we embed this command in our XML payload and our vulnerable apache struts server will execute the user’s base64 encoded command regardless of any special characters in their supplied command. A sample of the finished version of the exploit code for CVE-2017-9805 can be found here:


The above example a perfect illustration of why having the skills to interpret and modify public exploit code “on-the-fly” is so critical a skill to possess. This is especially true of penetration testers and is often what separates “Script Kiddies” from the proficient security professionals.

-Chris Davis
Counter Hack

Upcoming SANS Special Event – 2018 Holiday Hack Challenge


SANS Holiday Hack Challenge – KringleCon 2018

  • Free SANS Online Capture-the-Flag Challenge
  • Our annual gift to the entire Information Security Industry
  • Designed for novice to advanced InfoSec professionals
  • Fun for the whole family!!
  • Build and hone your skills in a fun and festive roleplaying like video game, by the makers of SANS NetWars
  • Learn more:
  • Play previous versions from free 24/7/365:

Player Feedback!

  • “On to level 4 of the #holidayhackchallenge. Thanks again @edskoudis / @SANSPenTest team.” – @mikehodges
  • “#SANSHolidayHack Confession – I have never used python or scapy before. I got started with both today because of this game! Yay!” – @tww2b
  • “Happiness is watching my 12 yo meet @edskoudis at the end of #SANSHolidayHack quest. Now the gnomes #ProudHackerPapa” – @dnlongen

Got Meterpreter? PivotPowPY!


by Cliff Janzen

My how time flies. It seems like only yesterday I wrote the post Got Meterpreter? Pivot! (/blog/2012/04/26/got-meterpreter-pivot), but it has been four and a half years. In our industry, the only thing constant is change and Mr. Ed Skoudis gave me the opportunity to revisit this topic to see what has changed. Thank you Ed.

So, once again, we will start with the same scenario:

We have a Metasploit Meterpreter shell with Admin/System privileges on an in-scope target Windows box. We will call this system X and it is in the DMZ. Do the root dance, pillage the heck out of it and get ready to pivot!

There are many ways to leverage the exploited system to discover, scan, and pivot to other devices in the target network. This article will discuss some ways to leverage the Metasploit Framework ( (hereafter referred to as Metasploit) to accomplish various kinds of pivots, although there will be some non-Metasploit tips scattered throughout as well. Where a technique from the previous post is still valid, it will be referenced. Our test system, X, uses a dual homed network, one network connected to the 172.16.33.x DMZ network and one connected to the 192.168.100.x internal network. The same techniques described below can be used for VLANs or physically separate networks that have paths to route to different networks.

Let’s go.


Watching the network interactions between devices is still one of my favorite ways to learn who, what, when and why an exploited system communicates with others on the network.

Meterpreter still has the sniffer module discussed in the last post available. In fact it has been updated with x64 support since then. However, rather than rehash sniffer, we will use the Packet Recorder sniffer extension written by Carlos Perez.

Packet Recorder uses sniffer, but makes it even easier. Start by executing the command run packetrecorder –li in the Meterpreter session to list out the available network interfaces, then execute the command run packetrecorder –i 3. To end the capture, carefully press CTRL-C then open up the capture and look for interesting info. The example below shows the entire process.


Not using Metasploit? For some reason when writing the post in 2012, I didn’t mention the built in netsh capability so let me correct that oversight now. The netsh trace command can be used. There are all sorts of filters that can be used but a simple method is just to use the IPv4Address flag as shown in the screenshot below.

This capture is saved in ETL format and can be viewed using Microsoft Message Analyzer. You can also convert the ETL capture to PCAP format with a couple of PowerShell commands. See the Internet Storm Center post in the references for more details.


 Route and Auxiliary scan

There are more than 250 post-exploitation modules currently available in Metasploit. A lot of them are used to gather info from the exploited system and a few of these are very useful in a pivoting situation.

A couple of good ones, again compliments of Carlos Perez, which can be used to determine what other systems are on the network are
post/windows/gather/arpscanner and post/multi/gather/pingsweep.



As illustrated above, these scans identified a few systems we can potentially pivot to.

Routing and Proxy

Routing is even easier then it was in 2012. From within your Meterpreter session simply type run autoroute –s subnet, then ctrl-z to go back to the Metasploit console and use the new route with some of the auxiliary TCP based scan modules and if we find something juicy, even exploit through the autoroute. The example below shows using our exploited system as route to identify listening ports from the systems discovered during the ping_sweep,


PORTFWD, SOCKS proxy and SSH Tunnelling illustrated in the previous post still works well. If you haven’t used them yet, you should. Re-read the post and setup a test lab to ensure you see it in action. You won’t regret it.

One new development since that post is the addition of PowerShell version of SSH. Personally, I have only done limited tunnelling testing with the Microsoft backed version If you have had some successes or challenges using PowerShell implementations of SSH for pivoting I would love to see them in the comments below.


Unfortunately, it appears that the module MSFMap by SecureState is no longer working in the current versions of Metasploit. All is not lost, though. There have been some very handy additions to Meterpreter that we can use in its place.


There are many ways to get a PowerShell session with Metasploit. One of the easiest is to use an existing session to create a PowerShell session. Background the existing session and do the following run the module exploit/windows/local/payload_inject with the Windows/powershell_reverse_tcp payload as shown below.


From here you can run (almost) any PowerShell module. In the example below, a PowerShell script, Invoke-TSPingSweep, which was modified a bit to make it more display friendly, was uploaded via Meterpreter, imported and then executed.


Note that some scripts will behave differently when run in the injected session. In particular watch out for scripts that use out-host and some that do not handle network connection timeouts will return big ugly errors like this one below, but will typically continue.



Another new addition is the ability to run Python directly in a Meterpreter session!!

This ability is still being developed and currently, there are some technical issues that limit some of the usefulness, for instance you can’t have the Python script run in the background (,. Still, this is an great addition and one that certainly will be useful when pivoting.



Imagine being able to easily use your favorite Python code from Black Hat Python, Violent Python or the SANS Security 573 class. Wonderful!

Not using Metasploit? As briefly shown above, PowerShell is a very powerful tool for the penetration tester and can be especially handy for post exploitation activities. All of the automated penetration testing programs provide PowerShell modules and a lot of very good work is being done on utilizing PowerShell for both defense and offense.

PowerShell remoting may not always available, but if it is, it can be a quick way to pivot around a network. From an existing PowerShell session run the command New-PSSession –ComputerName abc.fg.hi then to interact with the shell run the command Enter-PSSession X


What’s next?

I don’t see any slowdown in the opportunities to pivot through the network anytime in the near future. Do you have a favorite I haven’t mentioned? If so, please share it in the comments.

Thank you for your time



Upcoming SANS Special Event – 2018 Holiday Hack Challenge


SANS Holiday Hack Challenge – KringleCon 2018

  • Free SANS Online Capture-the-Flag Challenge
  • Our annual gift to the entire Information Security Industry
  • Designed for novice to advanced InfoSec professionals
  • Fun for the whole family!!
  • Build and hone your skills in a fun and festive roleplaying like video game, by the makers of SANS NetWars
  • Learn more:
  • Play previous versions from free 24/7/365:

Player Feedback!

  • “On to level 4 of the #holidayhackchallenge. Thanks again @edskoudis / @SANSPenTest team.” – @mikehodges
  • “#SANSHolidayHack Confession – I have never used python or scapy before. I got started with both today because of this game! Yay!” – @tww2b
  • “Happiness is watching my 12 yo meet @edskoudis at the end of #SANSHolidayHack quest. Now the gnomes #ProudHackerPapa” – @dnlongen

Modern Web Application Penetration Testing Part 1, XSS and XSRF Together


By: Adrien de Beaupre


I enjoy performing penetration tests, I also enjoy teaching how to do penetration testing correctly. I will be teaching SANS SEC642: Advanced Web App Penetration Testing, Ethical Hacking, and Exploitation Techniques at many events this year. This is one of the many techniques that I will be exploring in this series of posts. When I am teaching one of the points I make is to never consider the vulnerabilities in isolation, using them in combination truly demonstrates the risk and impact. My team were performing a web application penetration test, and the list of things that it was vulnerable to was quite impressive!


The list of vulnerabilities:

  • Content can be framed
  • XSS
  • Method interchange
  • DoS, application hangs on long abnormal inputs, relies on client side validation
  • Able to upload files, including malicious content
  • Information leakage, internal server names, IP addresses, install locations…
  • XSRF
  • User enumeration via forgot password function
  • Administrators can disable their own account

We had determined that the primary threat would be for a user to escalate privileges and access information from other accounts. In order to achieve this goal we concentrated on the persistent XSS and XSRF. We would use the persistent XSS to launch the XSRF attack. We leveraged all of the vulnerabilities in one way or another, in other words, we were having a good time! Once you have XSS in an application all that you need is one or more attractive transactions to be performed. We find that XSRF is the best XSS payload there is.

Using the persistent XSS:

  • Create trouble ticket
  • Ticket will be first viewed by administrator
  • Script executes in the administrator browser
  • Administrator can perform all of the functions vulnerable to XSRF

A significant number of the functions were vulnerable to Cross Site Request Forgery (CSRF or XSRF), which is also known as session riding and transaction injection. The functions that were vulnerable had absolutely no anti-XSRF protection, and the interesting ones were all in the administrator part of the site.

An attacker could add a new user, put the user in the administrator group, change the passwords, and log out. The problem was, each of these were different transactions, and had to be performed in the correct order to pull off the attack. The application owner and the development team did not appreciate the severity of the issue, and pointed out that their automated scanning tool had not identified the issue, therefore it didn’t exist. Even if the issue did exist, it could only be of medium severity, because their tool said so. To top it all off, even if an attacker could pull off this mythical attack, it could not be done in one shot, the administrator had to click multiple times. In short, they did not appreciate the impact, the attacker would have complete control over the application. In order to make our point a demonstration was in order, that did the following:

  • Add a new user
  • Put the user in an administrator group
  • Lockout the super-user account
  • Logout the super-user account
  • Did the functions in the correct order
  • Each function would wait for the last to complete
  • Was all in one HTML page
  • Could be delivered as a single XSS payload
  • Would force the administrator to view a certain Rick Astley video :)
  • OK, we didn’t do the last one, that would be WAY too mean.

Google-fu was with us that day, we discovered a post by Tim Tomes (lanmaster53) that described exactly what we wanted to do. He also had sample code to start with:

The next problem was that obviously we could not use their custom application to do the proof of concept, but needed another application with similar vulnerabilities to demo for this post. Once again the force of Google-fu was with us:

Omeka is a free and open source web publishing application. Also quick and easy to install. Also quick and easy to exploit. Last, but not least, we could download the vulnerable version 2.2 and be up and running in no time.


Administrator (victim) logs into the application:

modern_beaupre01Click image for full-size


The add user function as seen in an interception proxy (OWASP ZAP):

modern_beaupre02Click image for full-size


The Add User function was just one of many that were vulnerable to XSRF, with no protection as shown above. The api_key_label POST parameter id not sanitized, it is our persistent XSS vector. The administrator would have to invoke that function for the code to run. The code used is shown below in a PDF format.
The code running:

modern_beaupre03Click image for full-size


Now the code. The important parts are getting the script to run, we used a body onload. The script runs each one of the forms. The forms each contain one of the XSRF attacks. Each form loads in a different iframe. The first one runs, then the second one waits from the iframe onload to fire before it runs, and so on. Victim logs in, they check their queue, the XSS runs, the XSRF runs, they have lost control of the application, attacker win, or in this case a very effective demonstration of risk.

I am teaching SEC642: Advanced Web App Penetration Testing, Ethical Hacking, and Exploitation Techniques at multiple SANS training events around the world in 2018.

Adrien de Beaupré Inc.
Certified SANS Instructor
Co-author of SANS SEC642: Advanced Web App Penetration Testing, Ethical Hacking, and Exploitation Techniques




CODE – PDF Format (Copy & Paste):


Upcoming SANS Special Event – 2018 Holiday Hack Challenge


SANS Holiday Hack Challenge – KringleCon 2018

  • Free SANS Online Capture-the-Flag Challenge
  • Our annual gift to the entire Information Security Industry
  • Designed for novice to advanced InfoSec professionals
  • Fun for the whole family!!
  • Build and hone your skills in a fun and festive roleplaying like video game, by the makers of SANS NetWars
  • Learn more:
  • Play previous versions from free 24/7/365:

Player Feedback!

  • “On to level 4 of the #holidayhackchallenge. Thanks again @edskoudis / @SANSPenTest team.” – @mikehodges
  • “#SANSHolidayHack Confession – I have never used python or scapy before. I got started with both today because of this game! Yay!” – @tww2b
  • “Happiness is watching my 12 yo meet @edskoudis at the end of #SANSHolidayHack quest. Now the gnomes #ProudHackerPapa” – @dnlongen

Opening a Can of Active Defense and Cyber Deception to Confuse and Frustrate Attackers



As Cybersecurity/Infosec Professionals we know that all you have to do is wait 30 seconds and someone else has been breached and two new vulnerabilities have been discovered (hypothetically of course). There are few jobs on Earth that see the constantly evolving challenges that we get the privilege to deal with. This constant state of flux and learning has been what has kept me interested in this field as there are no shortages of challenges to counter. With an ever-growing list of Nation State attackers, organized criminals, hacktivist groups, and every other threat out there, no organization is safe. When you look across all industries in the private sector as well as government organizations at all levels, we are all getting attacked constantly.



Active Defense: Any defensive activity that is not simply installing a product or waiting for an IDS/firewall alert

- Proactive and anticipatory (hunt teaming, software restriction polices, and Internet whitelisting)

Cyber Deception: The deliberate and calculated process of deceiving attackers in an effort to wage a better defense (“Honey” things placed in your network which wouldn’t normally be accessed)

“All warfare is based on deception. There is no place where espionage is not used. 
Offer the enemy bait to lure him.” ~Sun Tzu”



  • The tactics covered here are meant to augment existing defensive techniques and technologies; not replace them
  • Before employing these tactics, you must make sure you have the ability to ingest and analyze the additional alerts that could arise
  • Make sure you vet all tactics with your legal team, human resources, and upper management first


Reducing Blind Spots in your Network

Many organizations today have solid defensive capabilities and monitoring at their network boundary, but once an attacker is within the network their activities and movements they often go unnoticed. One of the goals of implementing Active Defense and Cyber Deception is to reduce blind spots within the network by essentially setting up virtual trip-wires within the network. More specifically, it involves strategically deploying honeypots, honeyports, and honeyobjects. These “honey” things serve no legitimate purpose, so anytime they are interacted with it needs to be investigated. The tools and tactics that I am covering in this post utilize built-in capabilities within the operating system or free open-source software.

There are a few key things to keep in mind as you deploy a honeypot, honeyport, or any form of honeyobject. First anything you deploy should be done in such a way that it is believable, and secondly, you must ensure that you can receive alerts when the honeypot, honeyport, or honeyobject is interacted with. By doing these things you will greatly increase your chances of identifying anomalous activity within the lower areas of your network.

In addition to these capabilities custom IDS signatures should be created to identify unique strings or port access across your network. With this in mind, let’s look at a couple common honeypots in use today.

The goal of all Active Defense and Cyber Deception techniques is to disrupt the attack cycle to give defenders a better chance of early detection. The earlier in the attack cycle we detect anomalous/malicious activity, the greater our chances of stopping an attacker from establishing long term persistence and/or exfiltrating sensitive data.




There are many different honeypots available today both in the open-source and commercial software arenas. There is definitely no one-size fits-all solution out there. With this being said, I am going to cover two common open-source honeypots that have very specialized functions. The two that I am going to discuss here are Dionaea and Conpot. Dionaea is a honeypot that is focused on malware collection, but is also capable of logging information pertaining to server-side attacks. Conpot is a ICS/SCADA honeypot that is able to mimic a wide variety of different control systems.

I chose these two honeypots to discuss because they provide an excellent example of why you should not deploy a honeypot in its default configuration, and you must put some thought into how and where the system is deployed.



One of the first steps most attackers are going to take will be to scan your environment to identify the systems and services available within your network. For this example I have deployed Dionaea in its default configuration and have run a nmap service scan against the system. As you can see in the scan results below, there are three ports that have services being identified as Dionaea honeypot.


If an attacker was to discover this they will likely change their tactics to be more careful and they will definitely avoid this system. As defenders we don’t want any type of active defense measure to be able to be identified this easily; so we should investigate the tool prior to deploying it and try to make some subtle modifications to help avoid detection. This is essentially the same thing attackers do by utilizing measures to avoid detection of A/V, IDS, and other traditional defense products.

To help avoid easy detection of the Dionaea honeypot I needed to find out what nmap was using to fingerprint these services. I started doing the research and code analysis to determine this, but during the course of my investigation I discovered that Jose Manuel Fernandez had already done this research and had published it on

When nmap is working to fingerprint a service, it simply compares the strings coming back to it against the nmap-service-probes file, which contains a listing of known strings along with their corresponding service identifier. To help Dionaea avoid detection by nmap, we simply need to change the strings that it is sending in response to the probes sent by nmap. As I stated earlier, we want to make sure that this is believable, so we want to pick service fingerprints that make sense for our environment and ideally aren’t too far out of date.

For the FTP service I did a little research on vulnerable FTP services that were relatively current. In addition to making the service current, I also wanted to find a vulnerable FTP service, so I did some research on the site; and chose to mimic VsFTPD 3.0.2.


To make the changes for Dionaea’s responses I had to modify the script being used for the service. The exact location will vary depending on where you install, but for my instance it was located in



Once I opened the file in a text editor, I needed to find the string being used to fingerprint it, which is highlighted below.


To complete the modifications, I updated the SMB and MSSQL files so that they wouldn’t match the nmap-service-profiles definitions for the SMB and MSSQL services as shown below.








Once all of these changes were complete and the Dionaea honeypot was restarted, you can see that the scan results no longer scream “I’m a Honeypot!



Conpot is a low interactive server side Industrial Control Systems honeypot designed to be easy to deploy, modify and extend to mimic a wide variety of devices/infrastructures. There has been some interesting research on Conpot with regards to its default configuration and deployment. Specifically, Darren Martyn documented a significant amount of data for Conpot on

Conpot can be easily identified by a series of default values set within its configuration file simply named default.xml. On my installation it is located here:



Below are two excerpts from the default.xml file with specific values pointed out that can be used to identify the presence of Conpot.



With these values in mind, I went to Shodan to demonstrate how you can do a search on these values and get quite a few responses back. In the graphic below, you can see that I did a search on the device serial number and got back 206 results. If you take a look at the results you can see that they all have the same Module Type, Module name, and serial number. Additionally, if you were to run this same search in Shodan, you will find a number of these Conpot systems hosted by Cloud based providers. This ties in with my earlier statement on deploying systems in a way that is believable. You should not see ICS systems running in the cloud! Could it happen, sure, you could theoretically virtualize a PLC and host it in the cloud, but just because you can, doesn’t necessarily mean you should.


From this result, I picked one IP and did another search in Shodan’s experimental site Honeyscore to see if the IP could be identified as a honeypot. As you can see in the following graphic, Honeyscore identified the IP as a honeypot.




As an alternative to deploying full honeypot systems, we can always stand-up a handful of decoy ports that serve no legitimate purpose. Personally, honeyports are something I believe are best used within your network and should mimic services that attackers will use to move laterally. They can be extended well beyond this of course, and their implementation is only limited by the creativity of the defender. There are numerous FREE tools and methods available for honeyports, so it is recommended to try a few and see what works best for your environment. A few examples are:

  • Honeyports python script by Paul Asadorian:
    • is a simply python script that will establish a set of honeyports, monitor for connections, and automatically enter firewall block rules to block attacker IPs from connecting to the system again.
  • Artillery by Dave Kennedy:
    • Artillery is an open source project aimed at the detection of early warning indicators and attacks. The concept is that Artillery will spawn multiple ports on a system giving the attacker the idea that multiple ports are exposed. Additionally, Artillery actively monitors the filesystem for changes, brute force attacks, and other indicators of compromise. Artillery is a full suite for protection against attack on Linux and Windows based devices. It can be used as an early warning indicator of attackers on your network. Additionally, Artillery integrates into threat intelligence feeds which can notify when a previously seen attacker IP address has been identified. Artillery supports multiple configuration types, different versions of Linux, and can be deployed across multiple systems and events sent centrally.

Or, we can simply use some good old fashioned command-line kung-fu to accomplish the same thing. Just like with the above-mentioned tools, the goal is to have a port or ports which will show up in port scan results that are not meant for a legitimate purpose. When anyone interacts with them it is automatically considered suspicious, and a firewall block is put in place. When setting up a honeyport, remember that it should mimic a vulnerable service or one that an attacker would use to move laterally.

On Windows XP and later, we can set-up a Windows batch file to set-up our honeyport and to automatically create a firewall rule if it is accessed. In the example below, the firewall syntax is for Window 7 and above, but it could be changed to simply use the netsh firewall command if you were using this on an XP machine.

To make this work, we would simply enter the commands below into a .bat file and set it to run on system start.


You will want to ensure that you are logging firewall events, and you can then set to forward and monitor for Event ID’s 2002 & 2010. Event ID 2002, indicates that firewall rules were changed, and Event ID 2010 indicates that the network profile has been changed. In situations where we are deploying honeyports or honeyobjects, we really need to be forwarding logs to a central log management server and monitoring from there.

An example of how this could be deployed, would be for us to set-up a Honeyport on TCP port 5900 to mimic a listening VNC server across many, or even all systems in the network. Legitimate users should never touch this, but it would be an attractive port to an attacker seeking to move laterally throughout the network. When the attacker attempts to access the port, they are blocked and the event gets logged. The way this would look on the local event viewer is shown in the graphic below.



The goal with a honeyobject is to simply have some files or folders in a place where typical users are never going to access them, and if someone does it would be deemed suspicious. For files and folders being used as a honeyobject, you could apply the hidden attribute to help ensure that casual users don’t interact with them. Once the honey file/folder is created, you will need to have object access auditing enabled. For an example, I created the following scenario:

1. Established object auditing on the C:\Users\zander\Wicked Stuff directory
2. Applied hidden attribute, so that an average user won’t know the file is there

To enable object auditing you need to do the following:

Step 1: From the Security Policy Editor, Select Local Policy > Audit Policy > Audit Object Access > Select success & failure


Step 2: Go into Advanced properties for the folder you want to monitor


Step 3: Select Auditing Tab


Step 4: Add the user accounts you want to track usage for


Once this was completed, I ran a recursive directory listing in the same fashion that a bad guy would comb your file system looking for interesting files.


The result will be a number of entries in the Security log under Event ID 4663.




Active Defense and Cyber Deception capabilities provide a serious force multiplier for those trying to defend their networks. Determined attackers will find a way in, and you must be able to detect them once they do. Incident response is not an if it is going to happen situation, it is a when. Everyone is a target, and statistics show that attackers definitely have the advantage in this fight. Active Defense and Cyber Deception techniques can help you disrupt the attack cycle to disrupt and frustrate attacker activities. The tools and techniques discussed above are not meant to replace anything, they are meant to augment your existing defense capabilities. When deployed strategically and methodically they can greatly increase your chances of detection thereby reducing attacker dwell time within your environment. Take your network back!

I am teaching SEC504: Hacker Tools, Techniques, Exploits, and Incident Handling  at many events in 2018 and 2019.

Chris Pizor, SANS Certified Instructor

Upcoming SANS Special Event – 2018 Holiday Hack Challenge


SANS Holiday Hack Challenge – KringleCon 2018

  • Free SANS Online Capture-the-Flag Challenge
  • Our annual gift to the entire Information Security Industry
  • Designed for novice to advanced InfoSec professionals
  • Fun for the whole family!!
  • Build and hone your skills in a fun and festive roleplaying like video game, by the makers of SANS NetWars
  • Learn more:
  • Play previous versions from free 24/7/365:

Player Feedback!

  • “On to level 4 of the #holidayhackchallenge. Thanks again @edskoudis / @SANSPenTest team.” – @mikehodges
  • “#SANSHolidayHack Confession – I have never used python or scapy before. I got started with both today because of this game! Yay!” – @tww2b
  • “Happiness is watching my 12 yo meet @edskoudis at the end of #SANSHolidayHack quest. Now the gnomes #ProudHackerPapa” – @dnlongen

Using the SSH “Konami Code” (SSH Control Sequences)

By Jeff McJunkin

Are you familiar with the Konami code? The one popularized by the Contra video game?

Pictured above: Tangentially related to SSH

If not, let me fill you in.  This code is a sequence of control actions for some video games that’ll let you jump forward in the game (some call it a “cheat,” but I’d rather not judge.).  The code itself is a series of button presses as follows (from Wikipedia):


For me, learning about SSH control sequences felt like finding SSH’s Konami code. First I learned how to kill an SSH client that wasn’t responsive, which was convenient. Then, finding out about changing SSH’s options *after I had established the connection* felt like cheating. Adding SOCKS proxies or local and remote port forwards after I’ve already connected to an SSH server is very useful, and far less annoying than typing my SSH key passphrase again.

So, how do you start a control sequence? First, make sure “Enter” was the last key you pressed, as the SSH client won’t notice the control sequence otherwise. Next, press the tilde character (shift + backtick) followed by another character.

What are the support escape sequences, you ask? Well, press “?” as your second character, and your SSH client will tell you:

Supported escape sequences:
~. – terminate connection (and any multiplexed sessions)
~B – send a BREAK to the remote system
~C – open a command line
~R – request rekey
~V/v – decrease/increase verbosity (LogLevel)
~^Z – suspend ssh
~# – list forwarded connections
~& – background ssh (when waiting for connections to terminate)
~? – this message
~~ – send the escape character by typing it twice
(Note that escapes are only recognized immediately after newline.)

Of these, I use “~.” to kill stubborn SSH clients, “~C” to use additional SSH options (like “-D 8080” to start up a new SOCKS proxy), and rarely “~#” to see what forwards I’ve created.

Here’s an example of me connecting to an SSH server (I set up the alias in my ~/.ssh/config file) and using an SSH control sequence to add a SOCKS proxy on port 9001 retroactively:

Jeff 1

An example of using an SSH escape sequence

Note the line beginning with “whoami”. We were interacting with the SSH client itself at the line beginning with “ssh>”, but when we finished that by pressing Enter, we didn’t get a new prompt from the remote server. The input was still accepted, though, which is why the “whoami” command I typed returned “jeff” in the next line, followed by another newline and the SSH server’s prompt.
Gosh, this is useful stuff.

Thanks for reading along! I hope you find as much use for the SSH Konami Code as I have.

– Jeff McJunkin


Upcoming SANS Special Event – 2018 Holiday Hack Challenge


SANS Holiday Hack Challenge – KringleCon 2018

  • Free SANS Online Capture-the-Flag Challenge
  • Our annual gift to the entire Information Security Industry
  • Designed for novice to advanced InfoSec professionals
  • Fun for the whole family!!
  • Build and hone your skills in a fun and festive roleplaying like video game, by the makers of SANS NetWars
  • Learn more:
  • Play previous versions from free 24/7/365:

Player Feedback!

  • “On to level 4 of the #holidayhackchallenge. Thanks again @edskoudis / @SANSPenTest team.” – @mikehodges
  • “#SANSHolidayHack Confession – I have never used python or scapy before. I got started with both today because of this game! Yay!” – @tww2b
  • “Happiness is watching my 12 yo meet @edskoudis at the end of #SANSHolidayHack quest. Now the gnomes #ProudHackerPapa” – @dnlongen

Post Exploitation Redux Webcast Slides

Last Thursday, John Strand and I delivered a new webcast on post exploitation, covering all kinds of tips and tricks.  I focussed on some of the cool stuff you can do with the Windows netsh command, including setting up port pivots, sniffing, and gaining remote access to a target’s network configuration.  John Strand discussed a new tool his team released that provides a command and control channel via gmail.  We covered a lot of fun and useful material.


The slides are available here.

And, if you’d like to hear the webcast itself, you can do so here.

If you really like this kind of thing, I hope you’ll consider taking the SANS Security 560 course from me soon, where we delve deep into the art of high-value penetration testing.  I’ll be teaching it at SANS Orlando in April.  Hope you can join us there!


–Ed Skoudis & John Strand

EXTRA EXTRA! The New SANS Pen Test Poster

Extra! Extra! Read all about it! This week, many of you will be receiving our brand-spankin’ new SANS Pen Test Poster in the mail.  Please be on the lookout, because it’s got some really cool stuff on attack surfaces, tools, and techniques.  It’s included in the mailing with the SANS Security West brochure.


The poster is chock full of some really nifty pen test advice from some of the best pen testers I know, including:

Tim Medin
Seth Misenar
Larry Pesce
Justin Searle
Steve Sims
John Strand
Josh Wright

The poster includes several sections.  On one side, we’ve got a description of the SANS Pen Test Coins (collect all eleven!), an overview of the SANS Pen Test Curriculum, and a super updated version of the Pen Test Practice Lab Mind Map created by Aman Hardikar .M, with pointers to all kinds of great exploitable distributions and “hack-this-site” targets for you to practice and build your skills.  Aman’s mind maps are simply fantastic.

2015 Poster Side 1

The reverse side includes a view of different attack surfaces in  a given example target enterprise, and all the different methods, tools, and techniques pen testers can apply against such target infrastructures.  We’ve got a couple of views of network pen testing, an approach to wireless pen testing, some web app pen testing details, and a really cool view of mobile device and infrastructure pen testing.  Each one provides a step-by-step approach to penetrating the target organization, with a list of each tool used along the way.

2015 Poster Side 2

So, you might be wondering… how can I get a poster?  Well, like I mentioned above, we’ve dropped them in the mail to many people along with the SANS Security West (San Diego) brochure.  If you don’t get one in the mail, we’ll have some on-hand at upcoming SANS events, and we’d be delighted to hand you one there.  Alternatively, if you can’t make it and just want to download a high-res copy, please click here.

If you want a printed version but didn’t receive one in the mail, please reach out to me in the comment section below, and I’ll be in touch.

I really do hope you enjoy the posters, and I’m really grateful for all the hard work of the   SANS Pen Test Instructor team who provided such great input on this one.

Have fun pen testing all the things!!!

Thank you–


Upcoming SANS Special Event – 2018 Holiday Hack Challenge


SANS Holiday Hack Challenge – KringleCon 2018

  • Free SANS Online Capture-the-Flag Challenge
  • Our annual gift to the entire Information Security Industry
  • Designed for novice to advanced InfoSec professionals
  • Fun for the whole family!!
  • Build and hone your skills in a fun and festive roleplaying like video game, by the makers of SANS NetWars
  • Learn more:
  • Play previous versions from free 24/7/365:

Player Feedback!

  • “On to level 4 of the #holidayhackchallenge. Thanks again @edskoudis / @SANSPenTest team.” – @mikehodges
  • “#SANSHolidayHack Confession – I have never used python or scapy before. I got started with both today because of this game! Yay!” – @tww2b
  • “Happiness is watching my 12 yo meet @edskoudis at the end of #SANSHolidayHack quest. Now the gnomes #ProudHackerPapa” – @dnlongen

How Pen Testers Can Deal with Changes to Android SD Card Permissions

By Lee Neely & Chris Crowley

Recent updates to the Android OS have changed the permission model for external storage, and these changes will likely impact the way pen testers assess the actions and corresponding risks associated with applications, both malicious and benign, particularly when analyzing how they interact with external storage.

Consider this scenario: You are provided an application from an unknown third party to assess. Your assignment is to assess both the behavior and trustworthiness of the application. Because of the permission model changes, the application behaves differently when trying to access external storage than it would have in earlier releases of the Android OS.

In this article, we’ll provide information on how the permission model changed and some tips and techniques you can leverage when you are assessing an application in your next Android pen test.

What changed?

There were two changes which we will discuss separately. They have different impacts when assessing application behavior. Additionally, based on feedback after the KitKat release, Lollipop (5.0) introduced a new intent that allows application developers to return to the more familiar behavior. More on the Lollipop change later.

The first change, which has the greater impact on applications, was a change in the permission model for external storage. The second is a refinement in the treatment of application private storage area on secondary storage, which could be a bonus for malware.


Android external storage is defined to be a case-insensitive filesystem with immutable POSIX permission classes and modes. External storage can be provided by physical media, such as an SD card, or by exposing a portion of internal storage through an emulation layer. (see )

Android versions prior to KitKat (4.4) provided a single access model for external storage. Access to this storage was protected by a single permission WRITE_EXTERNAL_STORAGE. Starting in Jelly Bean (4.1) read access was protected with the READ_EXTERNAL_STORAGE permission. Prior to Jelly Bean, read access did not require any special permissions.

KitKat introduced two storage models for external storage; one known as primary storage which is essentially unchanged and another known as secondary storage. Primary storage is a part of the device internal storage. The APIs for accessing primary storage are unchanged. Secondary storage is provided by physical media, such as an SD card. Secondary Storage implements new permissions, such that attempts to write outside the applications private storage area (/storage/extSDCard/Android/Data/[Package Name]) are not permitted by the application without additional permissions. The concept of these application specific directories was introduced in FroYo (2.2.)

Permissions on external storage are synthesized. This can be confusing if you’re used to accessing SD cards that utilize the FAT file system without concerns about permissions. This is because the FAT file system doesn’t support permissions natively. Starting in KitKat, the owner, group and modes of files on external storage devices are now synthesized based on directory structure. These synthesized permissions are accomplished by wrapping raw storage devices in a FUSE daemon.

The First Change:

When Honeycomb (3.0) was introduced, a new paradigm for secondary storage access was also included. The paradigm includes the relevant additional permissions: WRITE_MEDIA_STORAGE and READ_MEDIA_STORAGE. (Note the change from *_EXTERNAL_STORAGE.) These permissions allow read and/or write access across the secondary storage device and are granted to system, manufacturer and mobile operator applications. Initially some device manufacturers also granted this on the fly to applications with WRITE_EXTERNAL_STORAGE permission. With the KitKat updates, this behavior has disappeared requiring applications to use new API calls to perform updates on items in secondary storage. Thus it has received the most attention with the KitKat release.

Applications with only the READ_EXTERNAL_STORAGE permission are largely not impacted. While the new permission model also tightened the permissions on the application specific directories on secondary storage; most applications were not accessing those locations. The WRITE_EXTERNAL_STORAGE permission also includes READ_EXTERNAL_STORAGE permissions.

The Second Change

The application specific folders (/storage/extSDCard/Android/Data/[Package Name]) are now deleted upon application uninstall. That means that if you store important information in that directory, then uninstall the application that created that information, your data will also be deleted. In contrast, while this behavior could be desired if an application is trying to hide its tracks or malware, it could be frustrating during the forensic examination or during times where you expect data to persist between actions taken while testing a device.

When analyzing application behavior, be sure to examine the application specific folders. Also, compare the folders on Jelly Bean and KitKat devices for content differences due to the permission changes.

How does that permission model work?

These permissions are implemented in kernel level groups.

The WRITE_EXTERNAL_STORAGE permission grants membership to the sdcard_rw and sdcard_r groups, which used to have full access to the secondary storage device.

The READ_EXTERNAL_STORAGE permission grants membership to the sdcard_r group, and therefore grants permission to read the secondary storage device.

The WRITE_MEDIA_STORAGE permission grants membership to the media_rw and media_r groups. This is the group system applications use to access the entire secondary storage device.

It turns out there is also a READ_MEDIA_STORAGE permission with a corresponding media_r group. It is not clear how this differs from the READ_EXTERNAL_STORAGE group.

Groups are associated with their permissions in system/etc/permissions/platform.xml. Researchers wishing to restore the old behavior are modifying this file to add the media_rw group to the WRITE_EXTERNAL_STORAGE permission. This modification requires a rooted device.

Show me!

To illustrate, here are secondary storage directory listings from a KitKat and Jelly Bean device:

Here is the private application storage directory on a Jelly Bean device: (Android/data on the secondary storage device.)

shell@android:/storage/sdcard0 $ ls -la Android/data
-rw-rw-r-- root     sdcard_rw        0 2013-03-28 15:04 .nomedia
drwxrwxr-x root     sdcard_rw          2011-12-31 16:01
drwxrwxr-x root     sdcard_rw          2013-03-28 15:32
drwxrwxr-x root     sdcard_rw          2013-03-28 15:04
drwxrwxr-x root     sdcard_rw          2013-03-28 15:04
drwxrwxr-x root     sdcard_rw          2013-03-22 16:11

Here is the same directory on a KitKat device:

shell@d2vzw:/storage/extSdCard $ ls -la Android/data
-rwxrwx--- root     sdcard_r        0 2014-12-15 19:58 .nomedia
drwxrwx--- u0_a84   sdcard_r          2014-12-15 20:11
drwxrwx--- u0_a137  sdcard_r          2014-12-15 20:14
drwxrwx--- u0_a56   sdcard_r          2014-12-15 19:58
drwxrwx--- u0_a124  sdcard_r          2014-12-15 19:58
drwxrwx--- u0_a92   sdcard_r          2014-12-15 20:48
drwxrwx--- u0_a6    sdcard_r          2014-12-15 19:58
drwxrwx--- u0_a153  sdcard_r          2014-12-15 20:12 com.vcast.mediamanager

If you examine the two listings you can see that the group controlling access to the private application directories has changed, and the ownership of the individual directories has changed to match the application owner/user on the device. Also notice the world read/execute permissions on these directories is removed in KitKat. With those changes a given application can no longer write to other application directories.

Note: the sdcard_r group doesn’t actually have write permissions to these directories, the FUSE daemon is synthesizing the results.

Let’s take a look at the permissions at the top level of the secondary storage device:

Storage Permissions in Jelly Bean:

shell@android:/storage/sdcard0 $ ls -la
drwxrwxr-x root     sdcard_rw         2014-11-10 16:02 .downloadTemp
drwxrwxr-x root     sdcard_rw         2011-12-31 16:01 .face
drwxrwxr-x root     sdcard_rw         2014-12-15 21:27 .thumbnails
drwxrwxr-x root     sdcard_rw         2011-12-31 16:01 Alarms
drwxrwxr-x root     sdcard_rw         2011-12-31 16:01 Android
drwxrwxr-x root     sdcard_rw         2011-12-31 16:01 Application
drwxrwxr-x root     sdcard_rw         2011-12-31 16:01 DCIM

Storage Permissions in KitKat:

shell@d2vzw:/storage/extSdCard $ ls -la
drwxrwx--x root     sdcard_r         2014-12-15 19:58 Android
drwxrwx--- root     sdcard_r         2014-12-15 19:58 LOST.DIR
drwxrwx--- root     sdcard_r          2013-02-21 04:57 books
drwxrwx--- root     sdcard_r         2013-02-21 06:32 camera
drwxrwx--- root     sdcard_r         2013-02-21 06:31 documents
drwxrwx--- root     sdcard_r         2013-02-21 04:57 downloads
drwxrwx--- root     sdcard_r         2013-02-21 04:57 music

From here, it looks like nothing can write to the top level under KitKat. In practice, the system applications are able to read and write just fine.

So, when you’re assessing the operations of an application, you now need to consider both the overt READ/WRITE_EXTERNAL_STORAGE permissions, actions taken in the application private storage area, and lastly, use of the new intents designed to manage access to this storage.

What is the reasoning behind the change?

In short, the media card was unstructured storage and not well managed, which made it easy for applications to both write and read that data. That’s why OHA is continually adjusting the behavior, because there is a critical balance between access to the phone owner’s data, and the risk of exposing that data. The new model is to wrap access to external storage through the FUSE daemon as well as cleanup and/or normalize access to the media card.

From the web site:

The WRITE_EXTERNAL_STORAGE permission must only grant write access to the primary external storage on a device. Apps must not be allowed to write to secondary external storage devices, except in their package-specific directories as allowed by synthesized permissions. Restricting writes in this way ensures the system can clean up files when applications are uninstalled.

What are the impacts?

Apps can no longer write ad-hoc to the media card, so things like third-party photo editors don’t work without changing how they are accessing those files. Read permissions still work, so third party media players/readers still work. Files are lost on application uninstall and device backup applications have had to adjust where files are stored. Additionally, running applications from a media card no longer works. Sideloading applications from the media card works provided the APK file is in a viable location, such as the downloads directory, and the options are set to allow application installation from other sources.

What does that mean when assessing an application?

  1. Application use of primary rather than secondary storage.
    1. This is not changed. If an application makes no use of secondary storage, your assessment is not impacted by these changes.
    2. An application may avoid the whole issue by never trying to write there.
  2. Application developers may try new ways to access secondary storage.
    1. Look for applications trying to add the WRITE_MEDIA_STORAGE permission in the manifest.xml file. Note: this only works for system/manufacturer applications.
    2. Look for calls to the new APIs – Pen Testers can assume malware has already adjusted to the new paradigm.
  3. Examine use of private application storage space
    1. Check for use of the new private application space on secondary storage, and consider how the application may try to leverage it being deleted on uninstall. Conversely if you uninstall the application, remember it gets deleted.
  4. Does the application use new intent introduced in Lollipop?
    1. Lollipop contains a new intent designed to emulate the old behavior.
    2. This is the supported/preferred mechanism for accessing secondary storage and isn’t necessarily an indication of a problem.
  5. Just to be sure, make sure the platform.xml file hasn’t been modified.
    1. Examine system/etc/permissions/platform.xml to see if media_rw group was added to WRITE_EXTERNAL_STORAGE definition which restores the old behavior and could be indication of device modification/rooting.
    2. It could be illuminating to compare the application behavior on a Jelly Bean device.

New in Lollipop

With Lollipop, a new ACTION_OPEN_DOCUMENT_TREE intent was introduced that allows application developers to return to the more familiar behavior. It is expected that applications will implement this intent as the simplest mechanism to restore the expected behavior. Google Software Engineer Jeff Sharkey explained the change and is quoted below.


After the change was rolled out in KitKat, Google heard loud and clear that developers wanted richer access beyond these directories, so in Lollipop they added the new ACTION_OPEN_DOCUMENT_TREE intent.  Apps can launch this intent to pick and return a directory from any supported DocumentProvider, including any of the shared storage supported by the device.  Apps can then create, update, and delete files and directories anywhere under the picked tree without any additional user interaction.  Just like the other document intents, apps can persist this access across reboots.

This gives apps broad, powerful access to manage files while still involving the user in the initial selection process.  Users may choose to give your app access to a narrow directory like “My Vacation Photos,” or they could pick the top-level of an entire SD card; the choice is theirs.

To make it easy for developers to transition to these new APIs, there’s a new DocumentFile support library class.  It looks and feels just like a traditional java.lang.File object, which makes it easy to adapt existing code:

-Lee Neely & Chris Crowley

p.s.  If you want to secure your mobile infrastructure and apps using world-class methodologies and techniques, you should definitely check out SANS Security 575, a GREAT  course on mobile device security and pen testing.

Chris Crowley will be teaching it in Houston from March 28-28, 2015.

Josh Wright will be teaching it at SANS Orlando from April 13-18, 2015.