Zero2Automated — Custom Sample — Executing the final payload

Hi all,

the analysis of the provided piece of malware is continued in this article, focusing solely on the third stage and applied capabilities and techniques to evade detection and thwart analysis. In this stage, we perform steganalysis to extract and later decrypt embedded payload from a downloaded picture.

To recap, the second stage of the sample performed API-Hashing with the CRC-32 algorithm and dynamic API resolution to load additional APIs with the goal to spawn a svchost.exe process and to execute a new function within the scope of this process. This function resolves additional APIs to access internet resources and downloads them into memory.

Link to the analysis of Stage 2.

Since this phase of the infection occurs exclusively in one function, I will skip the triage.

Advanced Analysis

Download and save the picture

After the malware accessed the pastebin URL, it uses a displayed and downloaded URL to retrieve a picture from hxxps[://]i[.]ibb[.]co/KsfqHym/PNG-02-Copy[.]png. This URL is used as a parameter to download the next stage resp. the picture.

buffer used as parameter via fastcall calling convention

In the picture below, it is visible that the malware uses the same function like to before to download the content behind a given URL and returns the output for later usage. After some string decryption and API hashing and resolving, the malware creates a new folder called cruloader in the TEMP directory of the user.

Immediately after creation of the folder, the file output.jpg is created and the previously downloaded content (the picture) is saved into this file.

downloaded picture being written

Find and decrypt the payload

The downloaded picture contains an encrypted payload, that is being accessed and decrypted by the following instructions.

At first, the malware decrypts the string redaolurc (‘cruloader’ reversed) via the well-known decryption routine.

decryption of delimeter

decrypted string

This string acts as a delimeter (red box), to find the encrypted payload in the downloaded picture. The numerous 0x61 bytes are also noticeable. These repeated 0x61 bytes suggest that the data may have been XOR-encrypted with the single-byte key 0x61. Decrypting them, this pattern will produce sequences of 0x00 bytes, which are typical in Windows executable headers. This could indicate that the embedded payload is a PE file that was obfuscated using a simple XOR scheme.

delimeter in the picture file

The malware then steps through the whole picture, to find the delimeter. If it is found, it saves the address of the byte after the delimeter into EBX, acting as a starting point of the decryption. Then it takes a jump at 0x401640 to reach the decryption routine.

routine to find the delimeter

The decryption routine is a simple XOR with a hardcoded key, that is loaded into the register XMM2. The encrypted payload is loaded into EAX and XMM registers to ensure decryption of 16byte blocks at once.

decryption of embedded payload

decrypted payload

Injection (Process Hollowing)

After the malware decrypts the payload, it starts with the injection into another instance of svchost.exe, that has been created in the same manner like before (string decryption and process creation via CreateProcessA). The approach to injecting the executable into the newly created process has some similarities to the injection performed before. However, the malware applies some additional APIs, like NtUnmapViewOfSection, to unmap the original mapped executable of svchost.exe, before injecting the previously decrypted code.

In the picture below we can see, that the malware saves the thread context in the first stage. Parts of the _CONTEXT structure will be used for a call to ReadProcessMemory to read a specific area of the process svchost.exe, namely the PEB. Like before, the goal is to find the base address of the image. But instead of changing the specific member in the PEB, the idea is now to unmap this section. Later the malware resolves additional APIs to write the decrypted payload into the targeted process via looping several times and calling WriteProcessMemory.

In the end, the injected code runs via a call to ResumeThread.

Automation and Emulation

To automate the download and extraction of the executable to be injected, I wrote the following Python script:

import requests

def accessURL(url):
    response = requests.get(url)
    print(f"[+] Accessing URL {url} ....")
    if response.status_code == 200:
        body_content = response.content
        print("[+] Response received: ", response.status_code)
    else:
        print(f"Request failed with status code: {response.status_code}")

    print("[+] response saved into variable!")
    return body_content

def downloadPicture(url):

    url2 = accessURL(url)
    print(url2)
    picture = accessURL(url2)
    return picture

def trimPayload(picture, deli):
    deliRev = ''.join(reversed(deli)).encode('utf-8')
    index = picture.find(deliRev)
    encryptedPayload = picture[index + len(deliRev):]

    return encryptedPayload

def decryptPayload(enc, key):

    decryptedPayload = bytearray()
    for i in range(len(enc)):
        decryptedPayload.append(enc[i] ^ key)
    with open('decryptedPayload.bin', "wb") as f:
        f.write(decryptedPayload)
    print("[+] Payload written to disk!")

url = "https://pastebin.com/raw/mLem9DGk"
deli = "cruloader"
key = 0x61
picture = downloadPicture(url)
encryptedPayload = trimPayload(picture, deli)
decryptPayload(encryptedPayload, key)

The result is a clean PE file with the following SHA256 hash:

A84B6FA193BD8D17065907744354333F0D0240A0498A4C6FDEF75E3AC9620606

peStudio view of decrypted file

This final payload just pops up a message box via a call to MessageBoxA.

This step marks the end of the analysis of the provided piece of malicious software designed for learning purposes. Overall, it was interesting to analyse the entire chain, particularly due to the various techniques employed to thwart analysis and the potential for automating some analysis tasks.