A Dive Into The OWASP ZSC Project

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 couple methods the tool uses in this blog post.

Generating Shellcode and XOR Obfuscation

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.  

Building a Signature

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.

Stack Usage

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
}

PEB Traversal

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.

Final Rule

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
}

Conclusions

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.