DBatLoader Reloaded: Dual Injection and Resilience

Overview

The SonicWall Capture Labs threat research team has observed the latest variant of DBatLoader performing a dual injection of Remcos RAT, utilizing two distinct injection techniques. The malware is mainly known for delivering Remcos RAT, but also delivers other malware. The malware is delivered as an archive attached to an email, containing highly obfuscated JavaScript that embeds the encrypted DBatLoader wrapper executable.

Below is the DBatLoader infection chain, which we will explore in detail later in this blog post.

First Layer: DBatLoader Executable

Upon execution of the obfuscated JavaScript, it drops the DBatLoader executable file in the %temp% folder and starts its execution. This executable is a Delphi-compiled binary that contains extensive obfuscation, junk code, and Delphi library functions, making it highly frustrating for malware researchers to analyze and debug. This Delphi binary contains approximately 1 MB of data in its resource section, which includes the encrypted loader binary, encrypted Remcos RAT, and LOLBins files required for its execution.

The main executable accesses the resource section and reads its data, parsing the large encoded content to pinpoint the exact location of the second-stage payload. Once the position is identified, it reads 0x34604 bytes from the resource section and copies them to a newly allocated memory region to start the decryption routine.

DBatLoader employs a simple addition-based decryption method to retrieve the second-stage payload, which it plans to inject into its own memory for execution. During this process, each encoded byte has 0x014F added to it, and only the least significant byte of the resulting WORD is kept, with the most significant byte discarded. These bytes are then assembled sequentially to reconstruct the byte array representing the second-stage payload.

After completely decrypting the second-stage payload, which is a Delphi DLL, DBatLoader carries out self-injection by manually loading the DLL into its own memory and initiating its execution. Essentially, DBatLoader acts as an in-memory loader, performing manual mapping to inject the DLL and then transferring execution control to it.

Second Layer: Self-Injected DLL by DBatLoader

The second-stage payload is a Delphi-compiled DLL, featuring the same level of obfuscation and junk code as its wrapper executable.

The malware calls the timeSetEvent API to delay a callback function execution by 2710h milliseconds and uses the argument constant TIME_PERIODIC for periodic execution of the callback function. The malware checks the client’s internet status using the API InetIsOffline.

Anti-Debug Functionality

The second-stage payload includes anti-debugging functionality, utilizing the CheckRemoteDebuggerPresent and IsDebuggerPresent APIs to detect the presence of a debugger. If a debugger is detected, it enters an infinite loop, effectively stalling execution until these anti-debugging checks are bypassed.

The malware utilizes the NtReadFile API to read its parent DBatLoader wrapper executable and extract the encoded Remcos Loader, which contains the embedded Remcos RAT. It then decrypts this Remcos Loader in preparation for the dual injection of the Remcos RAT.

Next, the malware launches the colorcpl.exe process using the WinExec API and enumerates running processes to obtain a handle to the colorcpl.exe process.

The second-stage DLL injected by DBatLoader carries out two separate process injections. It first injects the Remcos Loader executable into colorcpl.exe, and then carries out the second injection into the Mercury Loader process.

The malware allocates an RWX memory region in colorcpl.exe using the NtAllocateVirtualMemory API. It then injects the Remcos Loader executable into this allocated memory region with the NtWriteVirtualMemory API. Afterward, it parses the in-memory Remcos Loader binary to identify the Relative Virtual Address (RVA) of the entry point and computes the actual entry point by adding the RVA to the image base address.

Finally, it starts the execution of the Remcos Loader in colorcpl.exe by creating a new thread with the NtCreateThreadEx API, specifying the entry point of the injected Remcos Loader as the thread’s starting address.

After injecting the Remcos Loader executable into colorcpl.exe, the malware prepares for a second injection of the same payload, this time targeting the Mercury Loader LOLBins. It drops the Mercury Loader executable onto the disk, specifically in the Links folder— in our case, at the path C:\Users<username>\Links\gmxualuL.pif—and initiates the setup for the second process injection.

The malware starts the Mercury Loader LOLBins process in a suspended state and allocates an RWX memory region within it. It then injects the Remcos Loader into the Mercury Loader process using the NtWriteVirtualMemory API. Next, it modifies the execution context of the suspended process by using the GetThreadContext and SetThreadContext APIs to redirect the instruction pointer to the entry point of the injected payload. Finally, it begins execution of the injected code by resuming the suspended Mercury Loader process with the NtResumeThread API.

Third Layer: Remcos Loader

The Remcos Loader now begins its execution concurrently in two separate processes—first through code injection into colorcpl.exe, followed by injection into the Mercury Loader process.

The initial part of the Remcos Loader contains a decryption routine that decrypts a segment of shellcode embedded within the text section and then transfers control to the decrypted code.

The malware employs a combination of XOR and addition operations to decrypt 0x458 bytes of assembly instructions. It then transfers execution to this decrypted code, which contains the final decryption routine responsible for decrypting the Remcos RAT payload.

The malware initiates the final stage of decryption to extract the Remcos RAT payload, using a custom routine that combines arithmetic and bitwise operations.

The snapshot below illustrates the decryption logic used to retrieve the final Remcos payload.

The following snapshot shows the embedded encrypted Remcos RAT within the Remcos Loader binary, highlighting a comparison of the payload before and after decryption.

Once the Remcos Loader decrypts the Remcos RAT, it acts as a loader for the Remcos RAT.

The malware allocates memory and maps each section of the Remcos binary into the newly allocated space. It then applies relocation fixes by parsing the relocation section of the Remcos binary. Additionally, it modifies the Process Environment Block (PEB), updating the image base and entry point to reflect those of the Remcos RAT. Finally, it resolves the necessary APIs for Remcos execution using the GetProcAddress API and populates the Import Address Table (IAT) accordingly.

Finally, the Remcos Loader transfers control to the injected Remcos RAT payload using the jmp eax assembly instruction.

We observed that if code injection into colorcpl.exe fails for any reason, the Mercury Loader process continues running with the injected Remcos RAT payload. However, if colorcpl.exe runs successfully, the Mercury Loader process eventually terminates itself, leaving only colorcpl.exe running with the Remcos payload.

This behavior is likely deliberate, designed to guarantee that at least one instance of the Remcos RAT stays active on the compromised system.

IOCs

This threat can also be detected by SonicWall Capture ATP with Real-Time Deep Memory Inspection (RTDMI™). Below is the snapshot showing the detection details.