Summary: The content discusses two sophisticated malware frameworks, DUSTPAN and DUSTTRAP, utilized by the threat actor APT41. DUSTPAN serves as an in-memory dropper for executing payloads, while DUSTTRAP functions as a multi-stage plugin framework that employs evasion techniques to avoid detection.
Threat Actor: APT41 | APT41
Victim: Various targets | Various targets
Key Point :
- DUSTPAN is an in-memory dropper that can execute embedded or external payloads and has been disguised as legitimate Windows binaries.
- DUSTTRAP utilizes a multi-stage approach with a trojanized legitimate DLL to load plugins, employing sophisticated evasion techniques to bypass detection.
- Both malware frameworks leverage encrypted communications and can utilize Cloudflare for command-and-control operations.
Threat Activity
DUSTPAN and BEACON
DUSTPAN is an in-memory dropper written in C/C++ that decrypts and executes an embedded payload. Different variations of DUSTPAN may also load an external payload off disk from a hard-coded file path encrypted in the Portable Executable (PE) file. DUSTPAN may be configured to inject the decrypted payload into another process or create a new thread and execute it within its own process space.
Previously used by APT41 in several 2021 and 2022 breaches, DUSTPAN resurfaced in a recent investigation. This time, APT41 disguised DUSTPAN as a Windows binary by executing the malicious file as w3wp.exe or conn.exe. Additionally, the DUSTPAN samples were made persistent via Windows services; for example, one of the services was called Windows Defend.
The DUSTPAN samples were configured to load BEACON payloads into memory that were encrypted using chacha20. The BEACON payloads, once executed, communicated using either self-managed infrastructure hosted behind Cloudflare or utilized Cloudflare Workers as their command-and-control (C2) channels. BEACON configuration can be found in the Indicators of Compromise section.
DUSTTRAP
DUSTTRAP is a multi-stage plugin framework with multiple components. DUSTTRAP begins with a launcher (Stage 1) that AES-128-CFB decrypts an encrypted on-disk PE file <varies>.dll.mui and executes it in memory. Decryption relies on the target machine’s HKLMSOFTWAREMicrosoftCryptographyMachineGUID, thereby keying the launcher to the victim system. The decrypted PE from the launcher is a memory-only dropper (Stage 2) that is responsible for decrypting an embedded configuration and two or more embedded plugin dynamic-link libraries (DLLs) from its .lrsrc section. Once executed, these DLLs begin the setup of the modular plugin system. The first observed plugin (Stage 3) is responsible for low-level network setup and encryption. The second observed plugin (Stage 4) is responsible for higher-level network operations and may function as a downloader for additional plugins that, when loaded, may register themselves with prior components in the execution chain for additional functionality. We’ve observed the second plugin to vary in functionality and more plugin variants likely exist.
Plugin loading is performed by trojanizing a legitimate system DLL from %windir% with a sufficiently large .text section to hold the contents of each plugin. To trojanize the target DLL, the dropper will generate a new file on disk at %windir%Microsoft.NETassemblyGAC_MSILSystem.Data.Trace or
v4.0_4.0.0.0__b0<hex_uuid><original_module_name>.dll%programdata%Microsoft.NETSystem.Data.Tracev4.0_4.0.0.0__b0<hex_uuid><original_module_name>.dll. The malicious plugin code is only present in the .text section of this file long enough to call ZwCreateSection, loading the trojanized malicious plugin code into memory. Before the trojanized file is closed, the original contents of the .text section are restored on disk. This is an evasion technique that will bypass endpoint detection and response (EDR) solutions that scan for malicious contents on file close. The malicious code may therefore not be present in the file depending on when it was quarantined. During the trojanization process, the system time may be written to a log file at <filetime>.log and acquire the mutex ICMzUEkdLNayBdWF, though mutex names will likely vary from host to host.
The following legitimate DLLs are blocklisted from being trojanized:
Source: https://cloud.google.com/blog/topics/threat-intelligence/apt41-arisen-from-dust
“An interesting youtube video that may be related to the article above”