In this installment of our Shellcode Signatures Series, we discuss the OWASP ZSC Framework. While this project is not as robust as a larger framework like Metasploit, it does supply payloads and obfuscators that are worth understanding from a defensive standpoint.
The OWASP ZSC Framework is capable of producing several different types of built-in payloads and has support for downloading shellcode samples from shell_storm. The tool also contains basic obfuscators that can modify payloads to aid in bypassing detection.
In our earlier blog posts, we discussed different methods of obtaining the instruction pointer (GetPC). When writing signatures on shellcode, the primary idea is to write a few signatures that can successfully trigger on properties of shellcode without having to specify every discovered variant.
There are several obfuscators and payloads supported within ZSC. For the sake of brevity, we will only break down a
Generating shellcode within ZSC is a simple process: Typing through the menus allows the user to select the architecture, operating system, payload, and finally, the obfuscation technique they would like to apply.
A simple session would resemble the following:
zsc> shellcode zsc/shellcode> generate zsc/shellcode/generate> windows_x86 zsc/shellcode/generate/windows_x86> exec zsc/shellcode/generate/windows_x86/exec> file_to_execute file_to_execute> C:\Windows\System32\Calc.exe [+] file_to_execute set to "C:\Windows\System32\Calc.exe"
[+] none
[+] xor_random
[+] add_random
[+] sub_random
[+] xor_yourvalue
[+] inc
[+] dec
[+] inc_timesyouwant
[+] dec_timesyouwant
[+] add_yourvalue
[+] sub_yourvalue
[+] enter encode type
zsc/shellcode/generate/windows_x86/exec/encode_type> xor_random
Output assembly code?(y or n)> n
Output shellcode to screen?(y or n)> y
[+] Generated shellcode is:
\x31\xc9\x64\x8b\x41\x30\x8b\x40\x0c\x8b\x70\x14\xad\x96\xad\x8b\x58\x10\x8b\x53\x3c\x01\xda\x8b\x52\x78\x01\xda\x8b\x72\x20\x01\xde\x31\xc9\x41\xad\x01\xd8\x81\x38\x47\x65\x74\x50\x75\xf4\x81\x78\x04\x72\x6f\x63\x41\x75\xeb\x81\x78\x08\x64\x64\x72\x65\x75\xe2\x8b\x72\x24\x01\xde\x66\x8b\x0c\x4e\x49\x8b\x72\x1c\x01\xde\x8b\x14\x8e\x01\xda\x53\x52\x31\xc9\x51\xb9\x78\x65\x63\x61\x51\x83\x6c\x24\x03\x61\x53\x68\x30\x55\x6a\x59\x5b\x68\x67\x3c\x04\x1c\x59\x31\xd9\x5b\x51\x54\x53\xff\xd2\x83\xc4\x08\x59\x50\x31\xc9\x51\x53\x68\x43\x58\x75\x47\x5b\x68\x6d\x3d\x0d\x22\x59\x31\xd9\x5b\x51\x53\x68\x51\x6d\x71\x4d\x5b\x68\x12\x0c\x1d\x2e\x59\x31\xd9\x5b\x51\x53\x68\x33\x50\x6e\x39\x5b\x68\x5e\x63\x5c\x65\x59\x31\xd9\x5b\x51\x53\x68\x6c\x4b\x38\x70\x5b\x68\x15\x38\x4c\x15\x59\x31\xd9\x5b\x51\x53\x68\x45\x75\x4d\x4c\x5b\x68\x32\x06\x11\x1f\x59\x31\xd9\x5b\x51\x53\x68\x78\x5a\x6c\x32\x5b\x68\x11\x34\x08\x5d\x59\x31\xd9\x5b\x51\x53\x68\x48\x70\x6b\x6e\x5b\x68\x0b\x4a\x37\x39\x59\x31\xd9\x5b\x51\x31\xdb\x89\xe3\x31\xc9\x41\x51\x53\xff\xd0\x83\xc4\x24\x5a\x5b\x31\xc9\xb9\x65\x73\x73\x61\x51\x83\x6c\x24\x03\x61\x53\x68\x42\x44\x4e\x56\x5b\x68\x12\x36\x21\x35\x59\x31\xd9\x5b\x51\x53\x68\x53\x61\x72\x57\x5b\x68\x16\x19\x1b\x23\x59\x31\xd9\x5b\x51\x54\x53\xff\xd2\x31\xc9\x51\xff\xd0
Once the shellcode is generated, a session in Radare2 should be enough to analyze it.
Inspecting the first couple instructions, it becomes clear that the authors did not obfuscate the code that enumerates the process environment block (PEB).
xor ecx, ecx
mov eax, dword fs:[ecx + 0x30]
mov eax, dword [eax + 0xc]
mov esi, dword [eax + 0x14]
lodsd eax, dword [esi]
We will explain why this is important in detail in a later blog post, but the instructions are a by-the-book way of crawling the PEB to eventually find the base of kernel32.dll in memory. This is all done to find LoadLibrary so that APIs can be leveraged within the shellcode.
Observing this behavior is considered odd because we are looking at encoded shellcode. An encoder sub is usually run within encoded shellcode, which will decode some larger chunks of shellcode. Many different anti-virus vendors use this method and these offsets as signatures. Only when the analyst has worked all the way down do they typically observe this behavior.
After the PEB is enumerated, the next set of instructions look for GetProcAddress, as shown here:
0x00000023 41 inc ecx
0x00000025 01d8 add eax, ebx
0x00000027 813847657450 cmp dword [eax], 0x50746547 ; 'GetP'
0x0000002d 75f4 jne 0x23
0x0000002f 817804726f63. cmp dword [eax + 4], 0x41636f72 ; 'rocA'
0x00000036 75eb jne 0x23
0x00000038 817808646472. cmp dword [eax + 8], 0x65726464 ; 'ddre'
0x0000003f 75e2 jne 0x23
While it may not be entirely clear, the function is doing a simple string compare four bytes at a time. If the string compare fails at any time, the next exported function is evaluated.
Once GetProcAddress is found, the first bit of obfuscation is discovered. This should also give us a hint about the method that the shellcode uses to obfuscate the payloads.
0x0000005a b978656361 mov ecx, 0x61636578 ; 'xeca'
0x0000005f 51 push ecx
0x00000060 836c240361 sub dword [esp+3], 0x61 ; 'a'
0x00000065 53 push ebx
0x00000066 6830556a59 push 0x596a5530 ; '0UjY'
0x0000006b 5b pop ebx
0x0000006c 68673c041c push 0x1c043c67
0x00000071 59 pop ecx
0x00000072 31d9 xor ecx, ebx
0x00000074 5b pop ebx
0x00000075 51 push ecx
0x00000076 54 push esp
0x00000077 53 push ebx
0x00000078 ffd2 call edx
The first four-byte string, 0x61636578, is pushed onto the stack and 0x61 is subtracted to make the string null terminated—leaving 0x00636578. The shellcode likely does this––rather than directly pushing 0x00636578––to avoid using null bytes. This will cause problems if the shellcode is being used as part of a strcpy-type exploit.
To build the second string, the shellcode performs an XOR(0x596a5530,0x1c043c67) which is 0x456e6957.
Concatenating those two strings together in reverse order results in the string "WinExec." As we work our way down the assembly, the GetProcAddress function is called with the argument of WinExec.
Looking at our next section of obfuscation, we observe the same technique, as shown below:
0x00000083 6837443239 push 0x39324437 ; '7D29'
0x00000088 5b pop ebx
0x00000089 6819214a5c push 0x5c4a2119
0x0000008e 59 pop ecx
0x0000008f 31d9 xor ecx, ebx
0x00000091 5b pop ebx
0x00000092 51 push ecx
0x00000093 53 push ebx
0x00000094 6861556441 push 0x41645561 ; 'aUdA'
0x00000099 5b pop ebx
0x0000009a 6802340822 push 0x22083402
0x0000009f 59 pop ecx
0x000000a0 31d9 xor ecx, ebx
0x000000a2 5b pop ebx
0x000000a3 51 push ecx
0x000000a4 53 push ebx
0x000000a5 686f4f4e38 push 0x384e4f6f ; 'oON8'
0x000000aa 5b pop ebx
0x000000ab 68027c7c64 push 0x647c7c02
0x000000b0 59 pop ecx
0x000000b1 31d9 xor ecx, ebx
0x000000b3 5b pop ebx
0x000000b4 51 push ecx
0x000000b5 53 push ebx
0x000000b6 6851514a57 push 0x574a5151 ; 'QQJW'
0x000000bb 5b pop ebx
0x000000bc 6828223e32 push 0x323e2228 ; '(">2'
The following set of steps will reveal the string decoding:
0x39324437 ^ 0x5c4a2119 = ".exe"
0x41645561 ^ 0x22083402 = "calc"
0x384e4f6f ^ 0x647c7c02 = "m32\"
0x574a5151 ^ 0x323e2228 = "yste"
It eventually becomes clear that the payload is slowly building the path
C:\Windows\System32\calc.exe.
At this point, a couple different methods reveal themselves as candidates for signatures. While we may not be able to look for hard-coded strings, those are usually weak candidates for signatures in the first place. Strings within shellcode are the most trivial objects to change and lead to less resilient signatures.
One option is to look into heavy stack usage for manually building our strings. In a typical program, the stack is only used for temporary data storage while control flow passes back and forth between functions. Meanwhile, more permanent data is either modified in place or on the heap. The method of obfuscating strings seems to follow the same flow each time: push -> pop -> push -> pop -> xor -> pop
Checking benign software for false positives for this sort of behavior is easy once we generalize that series of commands into a Yara signature, as seen here:
rule zsc_stack_string_decode
{
meta:
author = "Nick Hoffman/Jeremy Humble"
description = "ZSC Stack String Decode"
strings:
$asm = {( 68 ?? ?? ?? ?? | 6a 00 ) // push
(58|59|5a|5b|5c|5d|5e|5f) // pop
( 68 ?? ?? ?? ?? | 6a 00 ) // push
(58|59|5a|5b|5c|5d|5e|5f) // pop
31 (c?|d?|e?|f?) // xor
(58|59|5a|5b|5c|5d|5e|5f)} // pop
condition:
any of them
}
Since the shellcode does not obfuscate the traversal of the PEB, writing even a naïve version of this signature will trigger on most samples generated from this tool. The simple version of this rule would resemble the following:
rule zsc_peb_traversal
{
meta:
author = "Nick Hoffman/Jeremy Humble"
description = "PEB Traversal method used in ZSC"
strings:
$simple_get_ldr_data = {648b4130 8b400c 8b7014 ad}
condition:
any of them
}
Running this rule against several payloads created by ZSC, we can see that the following signature yielded several different samples, regardless of the obfuscation used:
$ yara -r zsc.rule . zsc_peb_traversal ./windows_x86_exec_none.bin zsc_peb_traversal ./windows_x86_inc.bin zsc_peb_traversal ./windows_x86_dec.bin zsc_peb_traversal ./windows_x86_xor_random.bin zsc_peb_traversal ./windows_x86_sub_random.bin
This signature could be made even more general to support the swapping of registers and constants.
After studying both the obfuscators used within ZSC and the information the authors are specifically trying to obfuscate, we know the correct areas of the payload to trigger against. Putting this all together results in a Yara rule that resembles the following:
rule shellcode_owasp_zsc
{
meta:
authors = "Nick Hoffman/Jeremy Humble"
description = "Shellcode techniques used within the OWASP ZSC tool"
strings:
/*
mov eax, dword fs:[ecx + 0x30]
mov eax, dword [eax + 0xc]
mov esi, dword [eax + 0x14]
lodsd eax, dword [esi]
*/
$simple_get_ldr_data = {648b4130 8b400c 8b7014 ad}
$generic_get_ldr_data = {64 8b (05|0d|15|1d|25|2d|35|3d) 30 00 00 00
( 8b (4?|5?|6?|7?) 0c | 8b (44|4c|54|5c|64|6c|74|7c) 24 0c )
( 8b (4?|5?|6?|7?) 14 | 8b (44|4c|54|5c|64|6c|74|7c) 24 14 )
ad}
$stack_character_substitution = {( 68 ?? ?? ?? ?? | 6a 00 ) // push
(58|59|5a|5b|5c|5d|5e|5f) // pop
( 68 ?? ?? ?? ?? | 6a 00 ) // push
(58|59|5a|5b|5c|5d|5e|5f) // pop
31 (c?|d?|e?|f?) // xor
(58|59|5a|5b|5c|5d|5e|5f)} // pop
condition:
any of them
}
It's interesting that the authors were only interested in obfuscating the strings and library calls within the shellcode but did not alter control flow. While this may make the shellcode resistant to signatures based on strings alone, signatures that are looking for logic traversing the PEB, or args being pushed before a WinExec call, will still trigger.
Although this is not advanced obfuscation, it's useful for a defender to understand how shellcode is written, modified, and obfuscated. Understanding the internals will help defenders write better, more resilient, signatures.
