Sunday, June 26, 2016

PowerShell Empire Docker Build

For those of us that have had the chance to play around with it, docker is pretty awesome. While primarily designed with development / deployment / continuous integration in mind, it is also pretty awesome for offense related tasks.

I have put together a docker build for PowerShell Empire. You can grab the dockerfile and such from GitHub or just pull the image directly from Docker Hub. I intend on configuring automated builds to ensure that a fresh and fully updated version can be pulled down regularly

Grab from GitHub
Grab from Docker Hub

Usage & Considerations

In order to build the docker container yourself, you will need to clone this repository:
git clone
Once you have the repository cloned you will need to build the image from within the cloned directory:
cd PowerShellEmpireDocker
docker build -t PowerShellEmpire .

Once the image has been built, a container can be created and ran. For example:
docker run -it --name PowerShellEmpireDocker -p [HOST_IP]:[HOST_PORT]: \
[CONTAINER_PORT] -v /tmp:/tmp PowerShellEmpire
Taking a look at the run command:
  • -it instructs docker to let us interact with the container (input & output) 
  • -p instructs docker to forward communication received on the host IP on port 8080 to the container on port 8080. This can be modified as desired, however it is important to specify the host interface you intend stagers to communicate with. 
  • -v create a volume linking the host /tmp directory to the containers /tmp directory. This exists to conveniently write stager output files to the host for use. By default, PowerShell Empire writes generated stager files to /tmp. The host location is arbitrary. 

Important Note 

Bear in mind that when configuring listeners you must specify the IP address of the _host_ interface you intend to receive connections on. PowerShell Empire will bind a listener to, as such even if you specify an IP that does not exist within the container, it will bind without issue. Specifying the host interface when configuring the listener ensures that the stager is built with this same host interface, allowing it to connect back to the host as opposed to a local network interface that exists
within docker networking.

I'm lazy!

 If the above build process consists of more keys than you can bring yourself to type, the pre-built image can be found on docker hub. I intend to update them regulary. You can pull the image to your local device by executing the following
docker pull attactics/powershellempire

Monday, March 14, 2016

Bypassing Antivirus With Ten Lines of Code or (Yet Again) Why Antivirus is Largely Useless

I had originally set out to write a long winded blog post on different antivirus bypass techniques. I went through what was supposed to be step 1 of my guide and uploaded my binary to virustotal... and the binary got a 0/56 detection rate. I then decided to throw out my long winded idea and move forward with this quick and dirty blog post.

I believe that most of my readers would agree that bypassing most antivirus based solutions is not that hard, however we don't all have the same skillsets; some of us have been at this longer than others. I occasionally bump in to some folks who solely rely on tools that generate binaries for them. These can be easily fingerprinted and flagged by antivirus solutions if the tooling becoems popular enough. This article is mainly intended to help those that haven't considered writing their own AV bypasses.

Before I dive in to this small tidbit of C++ code, I'd like to touch on a tool that is really good at producing binaries that almost always evade detection, Veil-Evasion (part of the Veil-Framework). This tool is awesome (many thanks to @harmj0y and others for creating and contributing to this awesome project) and in almost all instances I have had to use it has not let me down. If it has, I blame people who keep generating binaries and then testing them on virustotal. Please stop doing that.

At any rate, if tools like Veil Evasion are so epic, why should you care about knowing how to slap togother a binary with a shellcode payload yourself? Well there are a number of reasons:

  • People get busy and tools become deprecated
  • The binaries generated by tools become fingerprintable; not the payload necessarily, but the compiled structure of the binary.
  • As a penetration tester, it is a good skill to learn how to write, at least, basic AV bypasses. Ups your leet cred.. or so I hear.
Before you take a look at the below code, it's worth noting that this is targeting the windows platform; Note the reference to windows.h

#include <windows.h>
#include <iostream>
int main(int argc, char **argv) {
 char b[] = {/* your XORd with key of 'x' shellcode goes here i.e. 0x4C,0x4F, 0x4C */};
 char c[sizeof b];
 for (int i = 0; i < sizeof b; i++) {c[i] = b[i] ^ 'x';}
 void *exec = VirtualAlloc(0, sizeof c, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
 memcpy(exec, c, sizeof c);

The above code creates a character array with shell code you can add, performs an XOR operation with the incredibly sophisticated key of lowercase 'x', allocates some memory, copies the character array in said allocated memory, and executes it. It may be worth highlighting that you will need to XOR your shellcode with your key of choosing (in this case 'x') before you put it in the above code and compile.

So you are probably looking at that and thinking 'really?' - I know how you feel. This is how I felt after I intended this to be step 1 of my tutorial. I'd like to stress that this is an incredible simple and most basic technique, yet its success is still rather surprising.

I originally wrote this example and tested it on virus total a while ago, but I did reanalyze the executable on virustotal at the time of publishing this post and found it still had a 0 detection rate.

The binary you generate will very likely not match the SHA256 of the binary I have tested; the binary I uploaded contained shellcode generated with the metasploit framework.

Final Comments

Alright, so traditional antivirus is dead. That being said, we can't argue that over 95% of organizations are still depending on antivirus to protect endpoints. 

Is there a better way? certainly. A number of vendors have launched products that take a new approach to protecting endpoints primarily focusing on identification of known exploit techniques by way of DLL injection, allowing for monitoring of known techniques and execution prevention. 

Is this fool proof technique? No. The bar will be raised, but a new type of cat and mouse game will begin.

Final note: The above may not work on _all_ antivirus solutions. I had thought that was implicit, but thought I would mention it before the pitch forks come after me!

Edit (3/17/2016): Wow. This post blew up a lot more than I intended it to. Please bear in mind that this article was targeted at penetration testers. The goal was to demonstrate an extremely simplistic signature based AV bypass technique. I didn't point out 'signature' as I assumed it was obvious that heuristics capabilities would very likely pick this up - although it really depends on your payload more than anything else. I don't advocate using this technique over infinitely more sophisticated implementations that can be found in Veil-Framework or Shellter. Think of the above code as a template - get creative - make the encoding routing more complicated - maybe implement encryption with key bruteforcing? then maybe add some prime number generation at the get go to throw off heuristics if you want to be fancy. Use payloads that communicate over HTTPS as well. Sky's the limit right?.

Tuesday, September 29, 2015

NMAPgrapher: A tool to generate graph and other output from NMAP XML files.

NMAPgrapher can be found at

What is it?

A tool I created to assist me in providing supplementary data with my penetration test reports. I'm releasing it to the public to do as you wish with it. The primary purpose of this tool is to allow the user to quickly and easily output exploratory data from NMAP XML files. The tool is capable of generating the following:
  • Most and least common services
  • Most and least common ports
  • Most and least common operating systems
  • Hosts with most and least number of open ports
  • HTML document with tables including each host and open services / ports
Most of the data sets can be output to:
  • PNG
  • SVG
  • CSV
  • HTML
In order to make this tool more useful to others, I have added the ability to skin the HTML output with CSS styles, found in the css folder. In order to generate the included template I used csstablegenerator. If you want to create your own css styles, just make sure to name the css class name 'table'.

SVG and PNG graphs can be styled by modifying I tried to use pygal's CSS styles and have a separate file for editing, however cairosvg was not liking it.

Quick Primer on Use

While NMAPgrapher has a fairly extensive help menu, here is the general usage structure: [inputFile] [outputBaseName] [outputType]

  • inputFile  is the NMAP XML file you wish to process
  • outputBaseName is the base name of the output files. All output files will be placed in a subfolder from where you ran NMAPgrapher
  • outputType is the type of output you want (csv, png, html, svg)
The default behavior is to produce all possible outputs for the output type specified. Some outputs such as the host lost detailing all open ports and services is only output in HTML for the time being. This will automatically be output in HTML regardless of the type you specify.

There are also a number of optional flags to only output certain types of data, for more information on these please invoke -h. They should be pretty straight forward.


NMAPgrapher requires a number of libraries to operate. I recommend using pip to install them. You can install them with pip like so:
pip install pygal cairosvg cssselect tinycss lxml elementtree

Bugs and Feature Requests

I'm not a python ninja (...yet?). I know the code is not the prettiest and I will work on refining it as time allows. If there are any bugs or feature requests, please message me on twitter (@evasiv3) and I'd be glad to help.

Sample Graph and Table Screenshots

The following are two example outputs from NMAPgrapher. The visuals are customizable.

Tuesday, September 8, 2015

Tool Spotlight: Eyewitness

If you have ever had to conduct a large penetration test, you know just how daunting it can be when you finish port and service scanning and start looking at all the data. While I strongly recommend learning some python to help sift through data, I wanted to highlight a tool that I've used in the past for grabbing screenshots of various running services en masse.

EyeWitness, developed by Chris Truncer, is a handy little tool that allows you to quick and efficiently grab screenshots from various services, including:

  • RDP
  • VNC
EyeWitness is able to run on both Windows and *nix platforms and provides a number of scanning configurations and reporting options.

As we all know, it can be quite tedious hitting all these services by hand to weed out the interesting bits. EyeWitness does all the hard work for you, allowing you to spend your time reviewing the output for interesting findings.

I've personally found this tool especially effective for quickly identifying administration interfaces of devices that aren't commonly picked up by vulnerability scanners such as SCADA / ICS infrastructure.

A full HOWTO on using the tool is provided by Chris Truncer here.


Monday, September 7, 2015

Extracting Hashes & Plaintext Passwords from Windows 10

Windows 10 is here. Well... it's sort of been here for some time, but it's fully rolled out now and soon we will begin to see enterprise adoption. I, like I'm sure many others out there, have been playing with Windows 10 in a virtual environment the last few weeks. My motivation has primarily been to understand how the game has changed with respect to my standard set of tools. In this blog post we will only be discussing my findings in relation to hash and plaintext password extraction.

We all know the value of windows password hashes and the fun they let us have via pass-the-hash attacks! If you aren't aware, I strongly recommend looking in to it. Now, I prefer having the actual password whenever possible, but hashes will suffice if that is all I can get. Naturally, I put a number of my usual suspects up against Windows 10 to see how they would perform:
  • mimkatz 2.0
  • wce 1.42 beta
  • fgdump 2.10
All testing was performed on Windows 10 Pro x64.

mimikatz 2.0 alpha x64 output

wce 1.42beta x64 output

fgdump 2.1.0 output

The results:
  • mimkatz 2.0
    • We can dump hashes, but not plaintext passwords
  • wce 1.42 beta
    • Does not seem to dump hashes or plaintext passwords
  • fgdump 2.10
    • Works as expected and dumps our hashes

In general, this isn't really too bad. We have our hashes and we can either crack those and use them in pass-the-hash attacks... but no plaintext passwords? Boo!

I decided to poke around on the internet and consult some friends to see if they had stumbled upon any interesting tools that are capable of dumping plaintext passwords on Windows 10. This is how I discovered a set of tools created by Pierre-Alexandre Braeken called PowerMemory. Of particular interest was a PowerShell script called Reveal Windows Memory Credentials (RWMC).

I grabbed the RWMC from github (link here) and threw it at my test VM.

Note: You must first execute 'Set-ExecutionPolicy Unrestricted -force' within PowerShell in order to allow the script's execution.

The following screenshots demonstrate how to use RWMC to dump plaintext passwords from a local Windows 10 Pro x64 machine, although they should not really differ on any other Windows operating system.

Running RWMC

Interestingly, the tool advises that a registry key was set and a reboot is needed. I took a peak at the script to find this:

Ah, here we can see that a registry setting for storing credentials in plaintext for the WDigest provider, is being set to 1. I haven't mucked with any of the settings on this Windows 10 Pro install, so UseLogonCredential being set to 0 must be default behavior on Windows 10. After looking in to the matter some more, this seems to be the case at least going back to Windows 8.1.

Let's try RWMC once more, after the registry modification and reboot.

This looks better... and our results are:

Alright. So that worked - nice! RWMC has a number of other features including the ability to dump passwords remotely and to retrieve passwords from dumps. More information can be found here.

The one thing that threw me off was having to reboot if the registry setting wasn't enabled. This can be quite an inconvenience, but I haven't found a way around it with the limited testing I have performed.

But now that we have the registry setting enabled, lets throw mimikatz at it again and see what happens:

There we have it. Mimikatz is also now able to dump the hashes without issue. Interestingly, in my tests, WCE was still failing.

It's more or less business as usual:
  • mimikatz
    • enable the UseLogonCredentials registry setting
  • RWMC
    • enable the UseLogonCredentials registry setting
  • WCE
    • doesn't seem to work all around, in my quick tests anyways
  • fgdump
    • Works as expected. No registry tweaks needed, but then again it's not interacting with WDigest.
Interestingly enough, Windows Defender did complain about the tools why they were being executed, but did not stop any of them from executing.

Thanks for reading,

Thursday, September 3, 2015

Providing Value In Your Penetration Test Reports: Part 1

So, you've pwned all the things, you have the keys to the kingdom, and you've pilfered all the data. You've done a great job, and now you're done right? Wrong.

I've been working in the offensive side of the infosec space for some time now, and I've seen a number of competitors' reports come across my desk; some pretty darn good and others... well.. pretty terrible. To be quite honest, there was a time where my reports were pretty terrible too... but one day a client asked me a question that started to make me think.

It was 5 or 6 years ago. I had pretty much just finished a penetration test similar to the one I just described above, managing to gain access to the entire organization. I tediously documented a long report full of vulnerabilities and sent it off to the client. As usual, we had a call a few weeks after to discuss their thoughts and close out the project. The client was a bit distraught on the phone. They were happy that I was able to bring all of these vulnerabilities to their attention, but they made a few comments that stuck with me; What does this all really mean? Where do we start? Will this fix our problems and make us more secure?

Now, you might think that is pretty obvious. It means your security is terrible and you should start at the beginning (duh!) and then all your problems will be solved, right? Well maybe... but there is a lot more to it. I tried to put myself in my client's shoes, doing my best to understand what they might be thinking when they read my report. With that mindset, I sat down and read through the report myself. It wasn't before long that I could see what the client meant. My report was full of technical detail, a brief executive summary that outlined the top vulnerabilities and that was pretty much it.

This started me a down a path of trying to analyze what a client is really trying to achieve when they have a penetration test performed, and consequentially how I can provide them the good value for their money.

Now is a good time to bring up an important point, the report you produce at the end of your penetration test is the only tangible artifact that you leave with the client. It doesn't matter how good you were technically or how much you pwned them, if your report is garbage, you aren't providing a valuable service, period. The report is one of, if not the most important parts of the penetration test.

So, let's talk about some important considerations in producing a penetration test report that is provides some real value to your clients...

Know Your Audience

Understanding who will be digesting your penetration test report goes a long way in terms of knowing how to communicate your findings to your client. If the report is going to be consumed by someone at the director level and all you have in your report is technical vulnerability detail, they probably won't read 90% of it, and worse off, they probably won't see any real value.

But we're trying to write a great report here, not just one targeted for a specific audience. With that in mind, I propose the following three audience types your report should address.

Technical Audience

This audience is pretty straight forward. They usually don't care about pretty graphs or sexy templates. They aren't afraid to roll their sleeves up and get their hands dirty, they want to know your findings in all of their technical glory and gruesome detail.

Managerial Audience

This audience is a little harder to nail down, as they can vary a bit, in general though, most of the managerial audience is interested in the 'dashboard' view of the results. They don't really care about the technical details, they might peak at a few findings, but they are mainly interested in getting situational awareness.

Strategic Audience

This audience is focused on strategic initiatives and are usually in the executive / director seat. They generally don't care about CVE-2099-1337 or how you managed to shell the thing with some other thing. This audience wants to know what strategic changes they can make in their organization to decrease vulnerability, and consequentially risk. They want to know about root cause problems, not vulnerabilities.

Now is another good time to stop and make something clear: vulnerabilities are not the real problem. It took me a while to realize. It wasn't until I had been penetration testing for a few years before I finally understood this. If you perform penetration tests for the same client over and over again, you start to see a pattern. You find vulnerabilities, they fix them. You come back again, and find some new vulnerabilities, and they fix them. This process continues forever. Why you ask? Well, vulnerabilities are symptoms of another problem, but they are not the over-arching problem themselves.

As penetration testers, we have seen a lot of different networks, clients, and scenarios. After some time of being in this field you start to see things pretty clearly. For example, you perform a penetration test and find that over 100 hosts are critically vulnerable and many to different vulnerabilities. What does this tell you? it's a pretty good indicator that the organization has a weak patch management program. Another example, you find that the systems are patched fairly well, but there are all sorts of security misconfigurations that allow you to abuse functionality and still pwn the organization. This is generally a good indicator that the client has a weak or non-existent configuration and build hardening standard.

Do you see what I'm getting at here? As a seasoned penetration tester, you can infer a lot of systematic issues that are the real problems leading to the vulnerabilities you find. These are the root causes. Fixing these issues is the only real way to make a lasting improvement in the client's environment. I'm not saying that once root cause issues are fixed that you should never perform a penetration test again, certainly not. No matter how good your security program is, there is always room for improvement. That being said, if root cause issues are tackled instead of just focusing on the symptoms (read: vulnerabilities), you will find that overall the security posture improves and critical severity vulnerabilities a) exist for a shorter duration in the environment and b) are less common.

So let's put two and two together. We've talked about target audiences, and about how we can infer some root cause problems. Should we include this stuff in our report? Absolutely, and not only should we bring up the root cause issues, but we should provide at least some high-level guidance on where they can begin to address them. By doing so, we can create a report that speaks to our client on different levels; from the technical to the strategic. And while we are at it, we can include some nice graphs and dashboards in the report to give our managerial audience the situational awareness they need, at a quick glance. If they want to dig deeper, they certainly can, but lets make sure we make the information accessible without having to spend 5 hours reading a report.

Okay, so our great report is going to speak to three different audience types, but how do we organize this information? I'm sure there are a number of ways, but I personally like to structure my reports in such a way that they get more technical the deeper you read in to them. Put the root cause (strategic) stuff up front, the dashboards and graphs (managerial) stuff right after, and then finally start jumping in to the technical rainbow land. This way our strategic audience can leaf through the first few pages, our managerial audience

Connect The Dots

Remember we talked about how you pwned the organization and hacked all the things? Great job... but hold on a second. Let's say you found 100+ vulnerabilities, and you are a great gal / guy, so you go to painstaking lengths of explaining everything in detail to make sure that your client understands each and every vulnerability, and of course how to fix them! You've done a great job, right? I'd say you've done a good job, but there is still room for improvement, young jedi.

Think about it... 100+ vulnerabilities, some of which have write-ups 5+ pages long. How did you go from poking at their external web applications to pwning the entire domain? This is what I mean by connecting the dots. The report should walk the client through the penetration testing process, where did you start? what did you find? what did that lead you to?

I call this an attack narrative. I'm not saying I made up the term, it's just what I call it. When we include this section in our great report, we are effectively narrating the penetration test to the client. This way they can understand our thought process and what we chained together to go from A to Z. Clients often find this detail very valuable as it allows them to understand the steps in a methodical manner.

Group The Things

Don't just dump all the vulnerabilities in to one section. If you performed internal and external testing, looking at both the application and network layers; separate those findings! Your clients likely have multiple individuals who will be assigned to address vulnerabilities. So do them a favor and organize your findings in a logical manner, making it easier for your client to slice up the report and action it within their organization.

I hope you found some of this information useful. At the end of the day, we perform our penetration testing to make a difference, so make sure your reports and the services you provide help to make that difference.

I'll follow up with another blog post shortly. There are some other points I'd like to bring up as well, so keep an eye out for part 2!

happy hacking,

Thursday, April 25, 2013

how to abuse xbmc

As we mentioned in the previous post, we spent some time this past weekend playing around with XBMC as it is gaining in popularity and because we use it often as well.

Quick note before we get going - we're not trying to feed script kiddies. There are no videos, and the details are somewhat vague... on purpose.

We found a neat little hack to execute arbitrary code on (specifically tested) xbmcbuntu, raspbmc, and ubuntu with xbmc installed. This probably works in similarly crafty ways on the windows side and other platforms but we just can be bothered to verify. This attack isn't crazy complex or sup3r1337z; rather a (we like to think) clever abuse of functionality.

The heart of this attack relies on the fact that xbmc.runscript allows you to run any python script on the victim box that is accessible to the user xbmc is running as.

Lets cover off getting a shell on xbmcbuntu and raspbmc. This ones less cool because it relies on SMB.

  • The event server is running.
    • This is on by default on (we're pretty sure) all XBMC deployments.
    • event server is on udp port 9777
  • SMB is enabled without a password
    • By default xbmcbuntu and raspbmc both ship with SMB enabled with no password.
The attack is pretty straightforward:
  1. create a python script that downloads a file and executes it... maybe a backdoor?
  2. upload this python script to the victim using SMB
  3. invoke the event server on the victim's xbmc from a remote machine calling Runscript with the file you dropped
  4. Boom.
We spent some extra time playing with a default ubuntu install updated to the current date with xbmc installed. The attack landscape was a little different here as SMB isn't available out of the box, especially not without a password.

We got creative.

  • The event server is running.
    • This is on by default on (we're pretty sure) all XBMC deployments.
    • event server is on udp port 9777
The attack:
  1. invoke the event server on the victim's xbmc from a remote machine calling Runscript with one of the python scripts that is already on the ubuntu box (by default) and can be abused to download a file. We're not going to spell it out... it's not that hard to find.
  2. this call to event server (in our tests) downloaded a python script to the victim
  3. invoke the event server on the victim's xbmc from a remote machine calling Runscript with the python script you downloaded previously.
  4. Boom.
We also found a way to list directory contents using a JSON RPC over HTTP request. Also a way to pull files from xbmc on ubuntu. We'll write these up in another blog post.

All these vulnerabilities give you privileges as whatever the user who ran xbmc was. Usually a regular user... but once you get a shell you can look at local vulns to elevate privilege.

Note: we posted this a while back but pulled it back in to draft as we wanted too formalize with a POC, but wont be releasing a formal write up as in the time that we were lazy others already have.