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 https://github.com/attactics/PowerShellEmpireDocker
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 0.0.0.0, 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 resultant binary to virustotal. To my complete and utter shock, the binary got a 0/56 detection rate. I decided to throw out my long winded idea and move forward with this quick, dirty, and unbelievably easy method.

I believe that most of my readers would agree with me that bypassing most antivirus based solutions is rather trivial, however I do occasionally bump in to some people who solely rely on tools that generate binaries that can easily be fingerprinted and flagged by antivirus solutions. This article is largely intended for that audience.

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. If you people could stop doing that, that would be great.

At any rate, this begs the question, 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, you should really know how to do this. 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; as obviously noted with 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);
 ((void(*)())exec)();
}

Quite simply, 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 and I ran it through virustotal and it returned 0/56 detection. I'd like to stress that this is an incredible simple and most basic technique, yet its success is still rather astonishing.

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 antivirus is dead. We all know that. 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, which I shall not name, have launched products that take a new approach to protecting endpoints primarily focusing on identification of known exploit techniques. This is usually performed by way of injecting DLLs in to processes that will monitor for these known techniques and prevent the exploit from working successfully. 

Is this fool proof technique? I would be inclined to say 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 figure that was obvious, 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 - this was just a super fundamental example.