LESLIELOADER – Undocumented Loader Observed

Key Takeaways

• Kroll has observed a new loader for SPARKRAT malware used in ongoing campaigns.
• While SPARKRAT development has officially ceased, unofficially it has continued to be modified by threat actors as needed.
• One of these new changes is a previously undocumented loader, identified by the AES key “LeslieCheungKwok”.

Summary

Kroll observed the use of SPARKRAT in conjunction with a previously undocumented loader written in Golang. The loader assists in the initial infection and deployment of the malicious payload, enabling SPARKRAT to execute on a system. This process allows the payload to reach the target system undetected and unquarantined. The loader achieves its goal by decoding and decrypting a secondary payload binary, then injecting it into a notepad.exe instance. This injection allows the malware to blend with legitimate system activity as it shares the memory space of a legitimate application. Despite detection tools’ ability to mitigate process injections, they remain a common evasion tactic.

GitHub developer XZB-1248 wrote and released SPARKRAT, a Golang binary compiled for multiple platforms, as an open-source, feature-rich remote admin tool on GitHub on March 18, 2022. Even though the developer abandoned the project in February 2023, intrusion investigations continue to discover modified versions of SPARKRAT. The “DRAGONSPARK” campaign, notorious for its attacks against organizations in East Asia, frequently uses this malware. SPARKRAT interprets its embedded Golang source code at runtime, which complicates analysis and static detections.

A source code repository very similar to LESLIELOADER has been identified alongside with instructions on how to utilize the loader for any payload necessary, originally timestamped June 7, 2022. Steps include generating a shellcode payload, AES encrypting the payload, and generating the executable. Additionally, the author posted proofs of running the samples against various antivirus and sandbox tools. However, there are some key differences from LESLIELOADER. Unlike the samples observed by Kroll, this loader does not beacon out a network connection. Additionally, this loader does not use process injection for code execution or a secondary file for payload.

Figure 1: Similar Code Repository

Later forks of this repository show modified versions of the initial loader, which begin to implement Base64 decoding. Continued modification of this original source code likely resulted in the version covered within this article.

Figure 2: Forked Repository Showing Addition of Base64 Decoding Stage

Kroll has identified and triaged additional LESLIELOADER samples and has observed them to contain Cobalt Strike configurations as well as other payloads, so this loader is not limited to SPARKRAT.

First Loader Stage

The loader begins with two files, Ntmssvc.dll and RemovableStorage.dll. Upon execution of Ntmssvc.dll with the /runcode flag, RemovableStorage.dll is read from C:\\Windows\System32\. Ntmssvc.dll contains the loader functionality, and RemovableStorage.dll functions as the payload.

Figure 3: RemovableStorage.dll File Read into Memory

RemovableStorage.dll is not a true PE file and does not contain the structure needed by the Windows PE loader to run independently. Instead, it serves as a payload data file that has undergone both Base64 encoding and AES 192-bit encryption.

Ntmssvc.dll initially attempts to beacon out to 209.141.50[.]215:443, however, this execution can be skipped in favor of overwriting the instruction pointer to the storage decoding function.

Figure 4: HTTP Beacon Attempt

Figure 5: Jumping to the Loader Function

Stepping through the storage decoding function, the last 32 bytes of RemovableStorage.dll are Base64 decoded and loaded into the RDI register, with LeslieCheungKwok loaded into the RCX register. The system then Base64 decodes RemovableStorage.dll and uses LeslieCheungKwok as the AES key to decrypt the resulting payload of data, with the 32 bytes from the end of RemovableStorage.dll serving as the IV. The resulting payload contains additional Base64 encoded data.

Figure 6: AES Key and IV are Loaded into Memory

Second Loader Stage

Stepping into the loader for this decrypted and decoded output, we continue to see Base64 decoding occur to portions of our file.

Figure 7: Further Base64 Decoding

Inspecting this, we see snippets of what appears to be shellcode using CyberChef.

Figure 8: CyberChef Recipe and Output

To continue observing the loader’s behavior to the memory pages containing these payloads, we set hardware breakpoints for memory access to them. Ultimately, we can observe the final payload for process injection dynamically calculated to have the size of 83DA50 in registers RCX and RDX.

Figure 9: Preparing for process injection.

Figure 10: Final Payload Size in RAX and RDX

Process injection to notepad.exe begins with a matching payload size in register r8 when memory is being allocated.

Notepad.exe is launched as a suspended process, however, there are additional artifacts of note within the loader indicating other processes such as calc.exe and cmd.exe. While they do not appear to be used in this sample for injection, the analysis of the use of these processes is out of scope.

Figure 11: Acquiring Pointer to notepad.exe

Once notepad.exe is created as a suspended process, Ntmssvc.dll overwrites the process memory for notepad.exe to manipulate the entry point. Prior to overwriting the entry point, notepad.exe proceeds as follows:

Figure 12: Original Entry Point

Once the notepad.exe entry point has been overwritten, the memory address of our SPARKRAT payload is loaded into RAX and jumped to, beginning execution of the malware.

Figure 13: Modified entry point

This now allows for the injected payload to be executed as notepad.exe.

Additionally, the below Yara rule may be used to search for indications of this loader:

import "pe"

rule leslieloader
{
  meta:
    author = "Marc Messer"
    description = "Checks for the inline string “LeslieCheungKwok” with instructions."
    truepositive = "ec45da0ca70a9b71652cc95d51665f7ad568294bd5652c395a119bccd613e9b4"
  strings:
    $a = {48 b9 4c 65 73 6c 69 65 43 68 48 89 08 48 b9 65 75 6e 67 4b 77 6f 6b}
  condition:
    pe.is_pe and $a
}