There Is More Than Meets The Eye - Analyzing Obfuscated WSHRAT Script

Nowadays it is really a common thing for a malware to have a crypter packer, obfuscation and encryption to hide its code from analyst, evade AV detections , bypassed emulation and so on. Aside from binary compiled malware, another interesting file type that can be easily to obfuscate is script compile code like JScript, VBscript, Autoit, powershell, python, golang and many more.

I know there are so many way to de-obfuscate or analyze a malicious script like using the browser as a debugger, using AMSI technology , wscript.exe to trigger a debug mode "/X" to a target script file or deep dive analysis and try to work with some tools or code some script.

Today I will share some tip how I analyzed the obfuscation technique of WSHRAT JS script with the help of python script to make the code more clear and see how it keeps several payload file on its code body.

Let's Start!! :)

First Stager - The Initial loader

The First Stage of WSHRAT script show interesting obfuscation that it used even in its second stage. As we can see in the figure 1, It started with a "squrr3L" function which will de-obfuscate each initialized strings within the code that will executed using EVAL() command.

The "squrr3L" function will replace the string "{}" that contains an index number pertaining to the index of string counter part that was pass to it as parameter. So in the figure 1. we can see "Array.prototype.tp_l1nk" is a big string contains "{}" which is either {0},{1},{2} that pertains to the parameter "F", "P", "x" pass to it so we can say that {0} = "F", {1}="P" and {2}="x". 

Figure 1 - First Stager The Loader

Once we replaced all the needed strings specially in variable "Array.prototype.tp_l1nk" which is base 64 encoded string of the next stager, we can decode it with our tool of choice. 

Second Stager - The Payload Executioner

After decoding the base-64 encoded string, The code is really a mess at first glance but don't worry as you work to figuring out how it works little by little it is not hard as what we expected. At the start of the code you will notice right away a big array list of hex string values named as "dKEW_qS[]".  This big chunk of hex encoded string is the gem of this script once converted to readable string and place on the right place. below is the code snippet of the hex string array.

figure 2 - hex encoded string array

And like what we've expected, the array list "dKEW_qS" was used as a reference to index the hex encoded string it needed to initialize, process or execute.

figure 3 - referencing the Hex Encoded String Array

Attacking The Problem - De-Obfuscation

Now we know the problem and how the obfuscations work. we can start analyzing it either manually checking or referencing the hex encoded string as you go to its code or "if you're lazy like me" you can work with simple script. 

So the goal of my script is the following: 

1. read each line of the wshrat script malware and check if there is a array referencing the  "dKEW_qS[]"

2. if yes grab the index number, locate the hex encoded string and then normalized it

3. copy that line into the output file as we as create a comment below the original code line 

4. if not just copy the original line

link: https://github.com/tccontre/KnowledgeBase/blob/main/malware_re_tools/wshrat/wshrat_deobfus.py

below is the example console output of the script I created showing how it replace all the index array to its normalized string.

figure 4 - console out of script

While below is the output file generated by the script I created where it creates a comment for each line having the reference array with the normalize string counter part to it. now it is easier to read right! ;)

figure 5 - before and after the execution of the script

I know the script is not so fancy but the help for analysis is really worth it. After having the output of my script I understand some its feature function like RDP (), keylogger() and reverseproxy() better. I thought all those function will be done within the script but nope. It will decode a base-64 encoded .net executable file for each of those payload and run it :).

figure 6 - getRDP function before and after the execution of the script

figure 7 - getKeyLogger function before and after the execution of the script

figure 8 - getReverseProxy function before and after the execution of the script

And some noteworthy behavior can be easily seen now after the normalizing it.

figure 9 - UAC bypass and defense evasion technique

Conclusion:

In this Blog We learned that sometimes if you have time it is really worth it to go on deep dive on some technique made by malware especially the obfuscation because at the end of the day you will learn something new. 

Hashes:

stage 1: SHA1 : d13add65fdee9c2b86925ed112d73685011e463b

stage 2: SHA1: e5eb857e1564204997c1de1049d452a0bf6c8421

Gh0stRat Anti-Debugging : Nested SEH (try - catch) to Decrypt and Load its Payload

 SEH tricks is not a new Anti-Debugging trick. So many malware already used this to make the manual debugging of its code time consuming and confusing. Today I will share how Gh0strat malware make use of nested SEH exception (try{} catch) as anti-debugging trick to hide its decryption routine.

This article is not to tackle the full C++ Exception Internals, but to share how IDAPRO really helps me in analyzing this type of anti-debugging tricks statically. :)

So lets start!!!

SEH:

Structure Exception handler (SEH) is one of the classic Anti-debugging tricks used by malware. where it tries to abuse the mechanism provided by operating system in managing exceptional situation like reference to a non-existence address pointer or execution of code in a read-only page.

This is done usually  by locating the pointer to SEH linked list in the stack known to be the SEH frame. The current SEH frame address is located in 0x00 offset relative to the FS (x32 bit) or GS selection (x64 bit).

figure 1: FS[0] of x32 bit OS

figure 2: The EXCEPTION_REGISTRATION_RECORD in FS[0]

When the exception is triggered, control is transfer to the current SEH handler where it will return one of the _EXCEPTION_DISPOSITION members.

In this Gh0strat variant it used nested SEH (try{} catch{}) that serve as anti-debugging tricks to make the debugging more confusing or let say more time consuming if analyst didn't notice the SEH.

Gh0srat: Nested SEH to decrypt its payload:

The sample we will use here contains a big data section where the encrypted gh0strat payload located. we will notice that using DIE tool or PE-bear that visualized the size of each section with quite high entropy same as text section.

figure 3: high entropy of data section

we all know there are so many faster way to bypassed this anti-debugging technique like monitoring the TIB offset 0x0 dynamically for next SEH or dumping process. In our case I will just want to share how IDA PRO will help you a lot in this case in traversing "FuncInfo" structure since IDAPRO resolved most of this SEH structure.

when you try to load the sample in debugger and breakpoint on some API let say, you may encounter some exception error shown in figure below. This is also a good hint that it may use SEH technique. 

figure 4: exception during debugging

by further checking its code using IDAPRO I notice that it uses nested SEH. yes a nested try{} catch{} exception handler to decrypt its payload. at the entry point of the malware code you will notice right away the first exception handler function registered to FS:0. Exception will be trigger by calling "call    __CxxThrowException" API. 

figure 5: first SEH in malware entrypoint

ehFuncInfo or the exception handler function registered in FS:0 contains some structure that may help us to figure out statically which exception handler function may be call upon the exception is trigger.

I really recommend to read this great presentation of hexblog regarding the Exception and RTTI:

https://www.hexblog.com/wp-content/uploads/2012/06/Recon-2012-Skochinsky-Compiler-Internals.pdf

The ehFuncInfo is a object structure that may lead you to the "AddressOfHandler" which is a address or a function address that will handle the exception encounter of the current thread.

IDAPRO really did a good job to give you some hint how to traverse that structure and lead you the said structure member of HandlerType. FuncInfo structure contains several member so I will just focus on the member that helps me to decrypt the payload.

Below is a simple structure starting from "FuncInfo" that may help you to look for the AddressOfHandler field member of HandlerType structure. 

figure 6: Traversing AddressOfhandler

The figure 6 shows that FuncInfo structure contains TryBlockMap field. this field is another structure object that contains HandlerArray field structure that holds the AddressOfHandler field. so to make use of this structure in our sample lets try to traverse the first SEH in malware entry point.

figure 7: Traversing the AddressOfHandler of SEH in malware entry point

We saw that the possible Address that will handle the exception is in 0x40243d. It works in dynamically test I did with x64dbg where I put break point on this address after the exception then press skip exception shift+f9.

figure 8: AddressOfHandler was triggered

if we follow the call function 0x402200 pushing string address "Shellex" as a parameter. you will notice again that it use another SEH to execute piece of its code. Not like the first SEH, this SEH contains 9 tryblock and HandlerOfAddress like the figure below.

figure 9: multiple try Block Map

Parsing ehFuncInfo structure Using Ida python:

In this case I decided to use IdaPython to parse all the FrameHandler ehFuncInfo structure to locate all AddressOfHandler field available for all tryBlockMap entries and add it as a code reference comment in its IDB. This approach help me to figure out where the decryption routine and learn multi line comment in idapython :).

the script is available here:

https://github.com/tccontre/KnowledgeBase/tree/main/malware_re_tools/gh0strat_seh_helper

figure 10A: before running the script

figure 10B: IDB after running the script

now with this comment we can verify all possible AddressOfHandler in each tryBlockMap entry to locate the decryption routine. Like the figure above, the first AddressOfHandler isa function waiting for the decryption key, size of the encrypted payload and the address of the encrypted payload.

figure 11: decryption routine

and once you decrypt the payload using this simple xor decryption routine. you can see right away some note worthy string of gh0strat like keylogging, creating services, regrun, download files, backdoor and etc.

figure 12: strings upon decryption

Conclusion:

In this article we just focus on some basic internals of SEH frameHandler and how to look for all possible HandlerOfAddress that may executed upon the trigger of registered SEH. we also learned how IDAPRO did a really good job in giving you all the needed structure for try block entries where you can use IDApython to make your static analysis more easier. :)

IOC:

https://bazaar.abuse.ch/sample/70ac339c41eb7a3f868736f98afa311674da61ae12164042e44d6e641338ff1f/

yara:

import "pe"

rule gh0st_rat_loader {

    meta:

        author =  "tcontre"

        description = "detecting gh0strat_loader"

        date =  "2021-02-22"

sha256 = "70ac339c41eb7a3f868736f98afa311674da61ae12164042e44d6e641338ff1f"

    strings:

        $mz = { 4d 5a }

        $code = { 40 33 FF 89 45 E8 57 8A 04 10 8A 14 0E 32 D0 88 14 0E FF 15 ?? ?? ?? ?? 8B C6 B9 ?? 00 00 00 }

        $str1 = "Shellex"

        $str2 = "VirtualProtect"

       

    

    condition:

        ($mz at 0) and $code and all of ($str*)

    }

    

rule gh0st_rat_payload {

    meta:

        author =  "tcontre"

        description = "detecting gh0strat_payload in memory without MZ header in memory"

        date =  "2021-02-22"

sha256 = "edffd5fc8eb86e2b20dd44e0482b97f74666edc2ec52966be19a6fe43358a5db"

    strings:

    $dos = "DOS mode"

    $av_str1 = "f-secure.exe"

    $av_str2 = "Mcshield.exe"

    $av_str3 = "Sunbelt"

    $av_str4 = "baiduSafeTray.exe"

    

    $clsid = "{4D36E972-E325-11CE-BFC1-08002BE10318}"

    $s1 = "[WIN]"

    $s2 = "[Print Screen]"

    $s3 = "Shellex"

    $s4 = "HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\0"

    $s5 = "%s\\%d.bak"

    

    condition:

        ($dos at 0x6c) and 2 of ($av_str*) and 4 of ($s*) and $clsid

    }

    

References:

https://www.hexblog.com/wp-content/uploads/2012/06/Recon-2012-Skochinsky-Compiler-Internals.pdf

Extracting Shellcode in ICEID .PNG Steganography

 In this past few days I stumble to some new and old variant of ICEID malware that uses .png steganography to hide and execute its encrypted shellcode. In this article I will share how the structure of the Iceid png payload look like and how to extract its encrypted shellcode.

Loader Compression:

same as the other malware, IceID Loader changes its Crypter to execute its main module in memory. From old variant where the encrypted code stub and decryption module is place in the RSRC section as a data .rsrc entry (RC4 encrypted) to applib compression like the figure below.

figure 1: The aplib decompressed module of ICEID

PNG Header:

Before we deal with the ICEID PNG steganography, I think it is a good idea to have some preview what PNG file header format is. It will give as a clear preview how ICEID parse the .PNG header and look for its encrypted shellcode.

The PNG file format started with 8-bytes signature header "89 50 4e 47 0d 0a 1a 0a". after this header is a chunk structure or series of chunk structures that contains either a "critical chunks" like "IHDR", "IDAT" and etc... or "Ancillary chunks" that may contain some attribute related to the color, pixel or metadata of the png file like "sRGB", "gAMA" and many more.

each PNG chunks layout consist of 4 parts or 4 structure member. the figure below show the 4 parts in IHDR chunk type.

figure 2: PNG File header Format

ICEID PNG Module Decryptor:

Now that we have some insight how PNG file format look like, lets dive in to the ICEID PNG decryptor module ("let's call it PNG module") that we already extracted earlier in the memory. This part is really interesting especially in parsing the header. :)

The PNG module start by executing a thread that will do the following:

1. decrypt its data section (C&C url link) using same approach how it decrypt the shellcode in PNG payload file.

2. it will check the existence of the PNG file in %appdata%<randomname>/, if not

3.  it will try to download it to its C&C server

4. then it will parse and check the png file to extract and execute its shellcode.

The first task is decrypting the C&C server URL link that are place in data section that are encrypted in RC4 algorithm. the structure of data it used in decrypting this data section can be seen before a call  function that will do the decryption part.

figure 3: Encrypted Data Structure

The first 8 bytes of the encrypted data section is the RC4 key and the rest is the encrypted data.

figure 4: decrypting C&C server URL link

Next it will create a random name folder in %appdata% using the "username" of the infected machine. 

with the use of RDTSC command to generate random character. If the module didn't find the png payload in the said folder it will try to contact the C&C server to download it.

figure 5: looking for the PNG payload file

Parsing PNG Header:

after reading the PNG and save it in the memory, it will start the checking in offset 0x8 (skipping the PNG header) which is the "chunk_data_length" of the first chunk type in the header which in our case is "IHDR". The way how it parse the header to look for "IDAT" chunk_type structure is by adding:

next_chunk_type_struct = size(chunk_data) + chunk_data_length (4 bytes) + chunk_type (4byes) + chunk_crc32 (4 bytes)

except for the start chunk_type structure where you need to include or add the PNG header size which 8 bytes.

for this topic, I created a simple python script that will parse this header and give you the basic information about the header. it also parse the chunk_data but I place it in the debug.log of this script.

https://github.com/tccontre/KnowledgeBase/tree/main/malware_re_tools/iceid_stego_shell_decryptor

figure 6: parsing the header

Byte Flag and Decryption Key:

as soon as it found the IDAT chunk_type structure it will check first if the chunk_data_length > 5 then it will skip the chunk_data_length , chunk_type and chunk_crc32 by adding 0x0c to the current pointer of the "IDAT" chunk header. the byte in this position looks like a validity flag of the PNG. If this byte is zero, the PNG module will check another value which is one of the parameter to the function that parse the png header which is also zero, so in this case it will exit the flag. 

figure 7: byte flag

after this byte is the 8 byte RC4 decryption key followed by the encrypted shellcode using this RC4 key. the python script I mentioned earlier will parse the RC4 key, extract the shellcode and check the shellcode header and entrypoint by dis-assembling it using capstone python library.

figure 8: script tool parser

Conclusion:

In this analysis we learned how PNG file can be used as a weapon to hide the malicious code and how malware keeps on updating their tools to bypassed detection.

Also thanks to the community for sharing the samples :)

Samples:

sha1: 9a07f8513844e7d3f96c99024fffe6e891338424

sha1: 1ab6006621c354649217a011cd7ca8eb357c3db4

sha1: c1faa9cb4aa7779028008375e7932051ee786a52

sha1: 481bc0cbdcae1cd40b70b93388bf4086781b44b4

https://www.virustotal.com/gui/file/45520a22cdf580f091ae46c45be318c3bb4d3e41d161ba8326a2e29f30c025d4/details

https://www.virustotal.com/gui/file/e6e0adcc94c3c4979ea1659c7125a11aa7cdabe24a36f63bfe1f2aeee2c5d3a1/detection

https://www.virustotal.com/gui/file/cc1030c4c7486f5295444acb205fa9c9947ad41427b6b181d74e7e5fe4e6f8a9/details

https://www.virustotal.com/gui/file/f6ea81aaf9a07e24a82b07254a8ed4fcf63d5a8e6ea7b57062f4c5baf9ef8bf2/detection

References:

https://en.wikipedia.org/wiki/Portable_Network_Graphics

http://www.libpng.org/pub/png/spec/1.2/PNG-Structure.html

https://blog.malwarebytes.com/threat-analysis/2019/12/new-version-of-icedid-trojan-uses-steganographic-payloads/

https://www.malware-traffic-analysis.net/2020/12/11/index.html