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:
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);
((void(*)())exec)();
}
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?.
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?.
So the shellcode you place in there must be pre xor'ed with 'x' so that the code xor's it back to usable shellcode right? Another obvious question, was the shellcode detectable before you simply xor'ed it?
ReplyDeleteYes, absolutely. The shellcode must be pre XORd with the desired key. And yes, the shellcode I used was a standard meterpreter shellcode for reverse TCP that was not encoded with anything fancy. It was detected by almost all AV on virustotal.
DeleteThis works for balloon executables not just shellcode, and why would anybody wants to protect shellcode into exe?
Deletehttp://hackforums.net/showthread.php?tid=5197517
http://hackforums.net/showthread.php?tid=5168562
The other vendor you talk about that does DLL injection -TRAPS... It only works on .pdf and MS office filetypes. That's it! A straight up .exe will pop on their endpoint just the way you created this one.
ReplyDeleteThat is one of them - but so is (for example) EMET and it works on binaries. :) I'm not sure if that solution does more than pdf and office filetypes, but I believe that it does.
DeleteTraps works on binaries for exploit detection, I'm currently doing deployments and testing and can vouch for this. Wildfire analyses unknown binaries and can be they can be blocked by default until a verdict is given.
DeleteYou're assuming the end point is on the network with Wildfire. What happens if it's a laptop off network? Also, my issue with Wildfire AND Traps is that their vendor recommends you do application white-listing for it to work. I've been popping boxes left and right with Traps running, using basic Metasploit binaries. No detection. :-/
DeleteIt's these little moments that have convinced me that, as the Symantec exec said famously, A/V is thoroughly dead. When the silliest things work, you know that the barrier of entry is low enough that anyone can get in.
ReplyDeleteMy favorite one is some of these network threat protection features that watch network connections and do some "layer 7 analysis". Send a payload, it kills the socket when it detects a meterpreter. So I made a shim and custom stager that sends over 64k of random garbage, and then sends the meterpreter payload. A/V gets tired easily, and gives up every time.
A simple XOR is terrible crypto, but it's "good enough" because A/V isn't going to try all XORs on every substring of every EXE to match signatures. And even if it did, then do a two-byte XOR, etc. The first rule of A/V bypass is to do something that you know A/V isn't willing to do.
XOR isn't for encryption in this use case, it's for obfuscation.
DeleteHay Josh, That sound sick. Is there any way if you could explain or demonstrate using an example? Really wanna try this.
DeleteThat's pretty bad but since AV are signatures based this isn't totally unexpected (hence your research) but using a behavior based detection like sandboxing or auditing this should be obvious, right ? Any recommendations on a se-linux like level of audit for windows systems?
ReplyDeleteThe virus total scan is from 10-2-15. What are the results of a rescan today?
ReplyDeleteAs stated, a reanalysis was done at the time of publishing this post and the results were the same.
Delete