Zero2Auto Custom Sample

Introduction

The following sample was analysed as part of the Zero2Auto course.

All the script can be found here: Github

Executive summary

The sample uses several stages of encrypted payload. The final stage is downloaded using http requests and injected into a svchost.exe process. The URLs in the provided sample point to a harmless dummy payload. See section IOCs for detection opportunities, including a Yara rule which covers all stages of the provided executable and infection chain.

Infection chain analysis

main_bin.exe

SHA256: A0AC02A1E6C908B90173E86C3E321F2BAB082ED45236503A21EB7D984DE10611

Having a first look at the provided binary we can see that it is a PE executable, and it has a very noticable large resource “101” with as very high entropy - indicating that there is some packed content within the binary.

When having a closer look at the main function with Ghidra it is obvious that the program resolves some functions using LoadLibrary and GetProcAddress using encrypted strings:

The function decrypting the strings - FUN_00401300 - uses ROT13 with a custom alphabet (a-zA-Z0-90./=).

Using a small Ghidra Python script (Github: ghidra_rot13.py) we can decrypt every string passed into this function and change the label accordingly.

As we can already see based on these first resolved functions, the binary then accesses the resource which was already identified as suspicious during the first look. This payload is RC4 encrypted, with the key being stored in the resource as well.

The RC4 decryption can be beautifully seen in the decompiler, showing the two loops up to 256 (0x100) for the Key Scheduling algorithm, followed by the PRGA and finally XOR encryption:

The executable reads the key in the 101 resource at offset 0xc with length 0xf, and then uses this key to decrypt the data at resource offset 0x1c. Dumping the payload can be automated easily using a script which follows the exact same procedure (Github: dump_payload.py)

Analysing the code further, we can see a process injection into a new process of the same executable.

payload1.exe

SHA256: 5700FF80246231E64296A8692FFA90B48823A4AACF4BDA51F3CB731E0E1A0E73

The second payload resolves function using API hashing - loading lobraries and comparing each export by CRC-hash to hardcoded values that will be resolved then. This makes it harder to identify the API functions since they cannot be easily decrypted. Fortunately we can use the same approach, hashing all exports from the desired libraries and comparing these hashes to the imports in the binary.

A small script was developped for this (Github: Hash exports) which generates a list of hashes for all the exports in a binary. Using this to hash the exports in the three relevant libraries in the malware (kernel32.dll, wininet.dll, ntdll.dll) we can generate a list of hashed functions: CRC32 Hash List (directly applying this through a lookup within the decompiler is an exercise for next time, but will definitely make life a bit easier)

The main function creates the CRC hash of the module name and compares it to 0xb925c42d (after finishing the analysis it became clear that it is svchost.exe). If the hash does not match, meaning a different process name, some anti-analysis checks are performed (IsDebuggerPresent, Running processes) and the binary will create a svchost.exe process and inject itself into it. If the has matches, meaning that the injection has already happened, the binary will use the WinInet API to download content form a URL.

This URL is stored as an XOR encrypted (Key: 0xc5) stackstring:

Since there are several other XOR encrypted stackstrings in the binary, a small script was used to decrypte all of them: Decode Stackstrings

This reveals the URL hxxps://pastebin.com/raw/mLem9DGk which contains another URL: hxxps://i.ibb.co/KsfqHym/PNG-02-Copy.png

It ist interesting to note that the binary uses the useragent “cruloader”.

After accessing the first URL, a second request made is against the result of the first request, which is the second URL. The file behind the second URL is then downloaded and stored in a temporary directory as output.jpg.

This file consists of an image, followed by a keyword “redaolurc”, followed by an XOR encrypted PE executable (the key here is ‘a’). After decrypting the payload, another svchost.exe process is launched and the payload injectred into it.

To extract this payload from the downloaded file another script was used emulating the original program: Dump Payload 2 This results in payload2.exe.

payload2.exe

SHA256: a84b6fa193bd8d17065907744354333f0d0240a0498a4c6fdef75e3ac9620606

The second payload seems to be a test only - it’s only functionality is to open a Message Box with the following text and title: “Uh Oh, Hacked!!”,“FUD 1337 Cruloader Payload Test. Don't upload to VT”

IOCs

SHA256

• a0ac02a1e6c908b90173e86c3e321f2bab082ed45236503a21eb7d984de10611 main_bin.exe
• 5700ff80246231e64296a8692ffa90b48823a4aacf4bda51f3cb731e0e1a0e73 payload1.exe
• a8cefb496de996601a83d71898d6ba445c07069236347aa8cd77f930d92f6585 output.jpg
• a84b6fa193bd8d17065907744354333f0d0240a0498a4c6fdef75e3ac9620606 payload2.exe

Network

• hxxps://pastebin.com/raw/mLem9DG
• hxxps://i.ibb.co/KsfqHym/PNG-02-Copy.png

Other

• User-Agent: cruloader

Yara rule

Link: cruloader.yar

rule cruloader
{
  strings:
    $payloadkeyword = { 72 65 64 61 6F 6C 75 72 63 }
    $useragent = "cruloader" nocase
    $svchostexe_crc = { 2d c4 25 b9 } 
    $rot13_dict = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890./="

  condition:
    any of them
}