Bypassing Antivirus using De-Obfuscation

About six months ago I was working on an idea for a new executable packer. Before I started coding, I performed some tests to see how easy current Antivirus products can be bypassed.

I chose the tool PwDump3 for testing as I did not want to handle real malware for the small test and this was sufficient as most AV products detect it as malicious software.

Two of my tests were quite simple:

Test1:

• pack the program with upx

 Test2:

• pack the program with upx
• rename sections
• add a time consuming loop to the programm, hoping that an AV scanner using generic unpacking will fail

The second test was somewhat successful - the detection rate dropped by 50%, whereas the first one did not really help bypass detection.

Now I wanted to take up the project again - checking what I did 6 months ago I also re-uploaded the testfiles to virustotal. To my surprise, these two testfiles led to almost identical results: 31/41 compared to 28/41.
As we all know and Kaspersky showed again recently, AV vendors often add detection for programs that are detected by other vendors, so one question arises: did they just add a static signature detecting my obfuscated version of the program or did the generic detection really improve?

The time consuming loop was really trivial, this is the code:

pushad
mov eax, 5
outer:
mov ecx, -1
inner:
xor ebx, ebx
loop inner
dec eax
jnz outer
popad

It should be fairly easy to detect something like that. I modified the executable so that it jumps to the end of the code section, executes the loop and then returns to the original entry point of the program.

After renaming the sections back to their original names set by UPX and replacing the loop with NOPs, I uploaded the program again. Surprisingly, only 16 of 39 scanners still detect that one, so now I bypassed 12 AV products by removing the obfuscation originally implemented...

Windows Vista + 7 Targets for Screen Unlock Script

The screen_unlock script for metasploit now supports Windows Vista and 7 (might not work with every version though).

The basic method used for Vista and 7 is still the same, yet there was one problem: Vista and 7 use ASLR, so fixed addresses for the code patch do not work.

The meterpreter API has a nice solution to this problem - it is possible to find out the base address of a specific process module.

The updated target section in the script contains relative offsets which are combined with the base address of msv1_0.dll in the lsass.exe process to locate the exact positions for checking the signature and applying the patch.

The script now also supports multiple targets for one OS - every matching target gets tested until a working one is found.

Get the new version here: http://github.com/svent/misc/blob/master/metasploit/screen_unlock.rb

Screen Unlock Meterpreter Script

Just released a meterpreter script that can be used to unlock the screen of a windows system. The script needs SYSTEM privileges and patches the msv1_0.dll loaded by lsass.exe so that every password will be accepted to unlock the screen. (the patch can also be undone to get back to normal behavior). Currently Windows XP SP2 and SP3 are supported.

The idea for this technique was first published by Metlstorm used for the winlockpwn tool performing the patch via firewire access to a machine.

I think it might be good for some demonstration purposes.

you can get the script here: http://github.com/svent/misc/blob/master/metasploit/screen_unlock.rb

Circumventing Antivirus Javascript Detection

Some browser-based exploits using javascript are detected by antivirus engines as they often use special strings that are easy to identify, e.g. ActiveX CLSIDs or "unescape('%u0c0c%u0c0c')".

Quite often, very advanced techniques like changing

"clsid:0955AC62-BF2E-4CBA-A2B9-A63F772D46CF"

into

"\x63\x6c\x73\x69\x64\x3a\x30\x39\x35\x35\x41\x43\x36\x32\x2d\x42\x46\x32\x45\x2d\x34\x43\x42\x41\x2d\x41\x32\x42\x39\x2d\x41\x36\x33\x46\x37\x37\x32\x44\x34\x36\x43\x46"

already help to get past AV detection.


More general techniques include randomly named variables, xor-encoded strings and so on. They all have in common that they are detectable if the javascript emulation engine is just good enough, as everything needed for detection is still contained in the examined code.

Some time ago, I implemented a new approach which was integrated into the metasploit framework in combination with the msvidctl_mpeg2 exploit. The detection on virustotal.com dropped to zero. Seven months later, it is still undetected. The used encryption was now integrated into the ie_aurora exploit and again the detection dropped to zero.
As zero detection on virustotal.com does not mean that no AV product will catch the exploit in a live environment (the scanners on virustotal will perform mostly static analysis), I tested the aurora exploit against two installed AV products (I'll better not name them) - with encryption, the exploit worked and was not detected anymore.

How it works
As said before, AV detection relies on the fact that the inspected javascript contains everything needed for the exploit. The new implementation also uses an xor-encryption, yet the key is not contained within the script.
The key used by the script is transferred as part of the URL, e.g.

http://host/exploit.html?<key>

Whereas the javascript executed within the browser can access this part of the url without any problems, many AV products just access the html file stored as temporary file on the disk and therefore cannot access the key - leading to unencryptable javascript code (with the techniques currently used).

Links
Javascript encoder module and integration into the msvidctl_mpeg2 module:
http://www.metasploit.com/redmine/projects/framework/repository/revisions/6784 

The patch for the ie_aurora exploit module can be found here:
http://github.com/svent/misc/tree/master/metasploit/