Malware Analysis Spotlight: Smoke Loader

Date: 02/28/2022

Malware Analysis Spotlight: Tried and Tested – Smoke Loader

By the VMRay Labs Team

Smoke Loader is a downloader which is capable of downloading and deploying other payloads, or downloading additional plugins. Its plugins offer functionality related to, for example, credentials and cookie stealing, DDoS, or remote access. It’s been used to download various secondary payloads, e.g., the Raccoon stealer, RedLine stealer, or coin miners. Smoke Loader has been actively advertised on forums since at least 2011. It’s been maintained and constantly updated, as is evident from the changes in the code, e.g., the C&C URL encryption.

In this Spotlight, we are looking at Smoke Loader which is distributing a variant of the Raccoon stealer (Figure 1).

Analysis of the Initial Stages

Usually the Smoke Loader DLL is packed and it requires multiple stages to extract the actual payload. Some of those stages use various anti-analysis and anti-debugging tricks to detect the environment and make the life of the analyst harder. This approach could also prevent certain automated malware analysis solutions from being able to analyze it. In our example, the initial sample that we are investigating is solely responsible for extracting the second stage and making sure it gets control over the execution. To achieve this, it uses an injection method called process hollowing, which can be recognized by a set of common WinAPI calls observed during the execution inside the VMRay Analyzer. It starts with a call to CreateProcess that creates a new process from the initial executable and leaves it in a suspended state. Then the next steps are to unmap the memory in the suspended process with the help of NtUnmapViewOfSection, allocate new memory inside it by calling VirtualAllocEx and write the second stage at that location using NtWriteVirtualMemory. Finally, the thread context is set (SetThreadContext) and the execution can be resumed (ResumeThread) (Figure 2).

Anti-Analysis Methods

The second stage performs multiple anti-analysis checks before actually unpacking the final payload. For example, it verifies that it’s not being debugged by checking the ProcessDebugPort information class in a call to NtQueryInformationProcess. It also looks for common DLL files related to sandboxes like sbiedll, aswhook, snxhk (Figure 3).

There are two important registry keys it enumerates to detect the presence of a virtual machine: \HKLM\System\CurrentControlSet\Enum\IDE and \HKLM\System\CurrentControlSet\Enum\SCSI. Both keys store information about devices on the system. Their sub keys are created by the PNP manager for each device and are named after the device ID. The sample compares the device ID against a list of strings associated with virtual machines (Figure 4).

This stage also uses the NtQuerySystemInformation API with the SystemProcessInformation class to enumerate all running processes and compare their names against another hard-coded list (Figure 4 top):

qemu-ga.exe
qga.exe
windanr.exe
vboxservice.exe
vboxtray.exe
vmtoolsd.exe
prl_tools.exe

If this check passes, it calls the function again, but this time with the SystemModuleInformation class, which returns the undocumented RTL_PROCESS_MODULES structure. It contains an array of RTL_PROCESS_MODULE_INFORMATION constructs that store information about the loaded drivers. It iterates over the names of the modules and compares them against known VM modules (Figure 5 bottom):

vmci.s
vmusbm
vmmous
vm3dmp
vmrawd
vmmemc
vboxgu
vboxsf
vboxmo
vboxvi
vboxdi
vioser

Payload Injection

If up to this point no sandbox, debugger, or virtual environment is detected, the actual Smoke Loader payload is decrypted and injected into explorer.exe. To get the process ID of explorer.exe, this stage utilizes the two functions GetShellWindow and GetWindowThreadProcessId. Subsequently, it uses a set of native APIs to perform the injection (Figure 6). It creates two sections with the protections PAGE_READWRITE and PAGE_EXECUTE_READWRITE. It then maps those sections into its own process and into explorer.exe. The protection of the mapped section containing the final Smoke Loader payload are PAGE_READWRITE and PAGE_EXECUTE_READ respectively. Finally, RtlCreateUserThread is used to execute the injected Smoke Loader payload. At this point the Smoke Loader payload inside explorer.exe has all its headers zeroed.

Smoke Loader DLL

Smoke Loader doesn’t come with a rich set of features by default. A lot of the additional functionality is implemented by its plugins. The initial payload is mostly responsible for setting foothold on the system and making sure it can persist there. The persistence is achieved by scheduling a task (Figure 7). The recent samples use the following name for the task: Firefox Default Browser Agent <unique hash>. The hash is the first 8 bytes from the MD5 hash calculated from the string consisting of the computer name, a hard-coded number (0x99FC7869), and the volume serial number.

The DLLs main responsibility is then to extract the C&C URLs and try to communicate with them. If the connection is successful, it tries to parse the commands and execute them accordingly. It is able to download further payloads or plugins, inject them into a running process (explorer.exe) or start them as an entirely new process.

C&C Encryption

It appears that the method of hiding and encrypting the C&C URLs is the part of the code that changes the most frequently. Previous version were using a fairly simple XOR-based encoding or a variant of it. The recent samples have switched to RC4 encryption. RC4 isn’t new for Smoke Loader developer(s). It’s the method used to encrypt other kind of strings used by the malware.

The encrypted C&C URLs are stored in a structure and are scattered at different locations inside the CODE section. The pointers to those locations are placed in an array of pointers, which is referenced in the decryption routine. Each time an unsuccessful connection was attempted, a global variable signifying the offset into the array is incremented. The encrypted C&C structure is shown below

Network Communication

When a C&C URL is decrypted, Smoke Loader sends it a beacon. The packet is a custom structure which is depicted below. The comments for the structure members correspond to how the member was named in the panel of an older version of Smoke Loader. The member without a comment is a newer addition. The initial packet is notifying the C&C that the payload is ready to receive commands. Each request and response is encrypted with the RC4 algorithm. The keys (separate for requests and responses) are hard-coded inside the functions responsible for sending and receiving them (see Configuration section for the keys used by this sample).

When the server communicates with the client, it sends a non-empty HTTP response with the status code 404. The data then contains encrypted commands or further payload (Figure 8). In this analysis, during the exchange with the server, we can observe that a download is initiated and the resulting file is saved as B8FD.exe in the %Temp% folder.

Essentially, during the initial communication with the C2 the following steps are performed:

Smoke Loader sends the initial beacon in an encrypted form over HTTP.
If the server is available, it responds with an HTTP response and the status code 404. The content of the response contains the command.
The client parses the response contentFirst 4 bytes indicate the data length
The rest is an RC4 encrypted data which is decrypted with the hard-coded key
After decryption, Smoke Loader verifies that the response starts with a magic and processes the command

Raccoon Stealer

In our analysis the final payload delivered by Smoke Loader is the Raccoon stealer (Figure 9).

Conclusion

Smoke Loader has been active for the past 10 years and is being used by various threat actors. The developer is constantly adapting its methods to stay relevant and avoid detection. Although the packer used by Smoke Loader and the payload itself use multiple anti-evasion techniques to circumvent automatic sandbox analyses, the VMRay Analyzer is still able to monitor its complete behavior and provide actionable IOCs.