MoonWalk: A deep dive into the updated arsenal of APT41 | Part 2

Introduction

This is Part 2 of our two-part technical deep dive into APT41’s new tooling, DodgeBox and MoonWalk. For details of DodgeBox, go to Part 1.

In Part 2 of this blog series, we examine the MoonWalk backdoor, a new addition to APT41’s toolkit. Continuing from our previous analysis of the DodgeBox loader in Part 1, we have discovered that MoonWalk shares several evasion techniques. It makes use of Google Drive for command-and-control (C2) communication and abuses Windows Fibers, a lesser-known Windows feature, to evade anti-virus (AV) and Endpoint Detection and Response (EDR) solutions.

Key Takeaways

• APT41, a China-based nation-state threat actor known for campaigns in Southeast Asia, has been observed using a new backdoor called MoonWalk.
• MoonWalk shares a common development toolkit with DodgeBox, reusing code that implements evasive techniques such as DLL hollowing, import resolution, DLL unhooking, and call stack spoofing. Additionally, MoonWalk employs further evasion tactics, including the use of Google Drive as its C2 channel to blend in with legitimate network traffic and the utilization of Windows Fibers to evade AV/EDR security solutions.
• MoonWalk’s modular design allows attackers to easily update its capabilities, modify its behavior, and customize functionality for different scenarios.

Technical Analysis

Attack chain

The focus of this blog post is the second half of the attack chain that begins with the in-memory execution of MoonWalk backdoor. Once the MoonWalk backdoor is successfully loaded by DodgeBox, the malware decrypts and reflectively loads two embedded plugins (C2 and Utility). The C2 plugin uses a custom encrypted C2 protocol to communicate with the attacker-controlled Google Drive account. 

A figure depicting the attack chain used to deploy MoonWalk with the DodgeBox loader is shown below.

Figure 1: Attack chain used to deploy the DodgeBox loader and MoonWalk backdoor.

MoonWalk analysis

MoonWalk is a malware backdoor written in C that shares many code similarities with DodgeBox, suggesting a common development toolkit. It incorporates many evasion related functions from DodgeBox, including those related to the following:

• DLL hollowing 
• Import resolution 
• DLL unhooking 
• Call stack spoofing 

Additionally, MoonWalk utilizes the same DLL blocklist as DodgeBox.

ThreatLabz analysis reveals MoonWalk’s modular design, allowing it to load different plugin components as needed. The sample examined by ThreatLabz contains two embedded plugins, a C2 plugin for C2 communication, and a utility plugin that provides functionality related to compression and public-key cryptography. This modular architecture makes MoonWalk highly adaptable, enabling attackers to customize its functionality for different scenarios. 

In the section below, we will highlight several notable capabilities of MoonWalk.

Unloading the DodgeBox loader

When MoonWalk first initializes, it resolves its imports using the same algorithms as DodgeBox. Then, depending on the DodgeBox configuration parameter Config.fShouldUnloadStealthVector, MoonWalk unloads the DodgeBox DLL from memory and unlinks it from the Process Environment Block (PEB). This reduces MoonWalk’s in-memory footprint, and obfuscates its origins, hindering memory forensic analysis.

Using Windows Fibers

Next, MoonWalk initializes global structures used to manage Windows Fibers. Windows Fibers are a lightweight threading mechanism, available in the Windows operating system since Windows NT SP5. Unlike traditional threads, which are scheduled by the operating system, fibers are cooperatively scheduled by the application itself. This allows developers to tune an application’s performance for a specific workload. However, due to the complexity of utilizing Windows Fibers, and performance improvements of computer hardware, Windows Fibers were not widely adopted, and remains an obscure feature.

However, with the increased focus on cybersecurity in recent years, there has been an uptick in interest in Windows Fibers from the research and red-teaming community. Multiple research papers (1, 2, 3) and open-sourced proof of concepts (POCs) have been published, abusing Windows Fibers to evade AVs/EDR solutions.

APT41 may have been following these developments, as they have incorporated Windows Fibers into the MoonWalk backdoor. At a high level, MoonWalk maintains a global array of fibers. When a function needs to be executed as a fiber, a fiber is created using the CreateFiber API. This fiber is then packaged together with the address of the function and its arguments and other metadata, and inserted into the global array. The main fiber then schedules these fibers for execution. This use of Windows Fibers helps MoonWalk evade AVs and EDRs which do not support the scanning of Windows Fibers, and also makes analysis challenging by breaking up the control flow.

Configuration

MoonWalk decrypts its configuration, which is hard-coded within its .lrsrc section. Like DodgeBox, MoonWalk uses MD5 for configuration validation and AES Cipher Feedback (AES-CFB) for decryption. 

However, MoonWalk’s configuration is more complex, featuring nested structures and arrays. This configuration contains various execution parameters including the following: 

• Mutex names 
• A fiber configuration 
• Heartbeat intervals 
• Encryption keys 
• C2-related data 

In the sample we analyzed, MoonWalk’s configuration (referred to as Config) included OAuth secrets used to authenticate with the attacker-controlled Google Drive account, and other notable fields as shown below:

Config.szClientID: 
XXXXXXXX3108-0pm3bsjc0mto2e1k4kp2u8817lgk3e3v.apps.googleusercontent.com

Config.szClientSecret:
XXXXXXXXBiuo8VPZUH1dBHkv86mC1xFU_Z3

Config.szRefreshToken: XXXXXXXXiYDPmH9cCgYIARAAGAkSNwF-L9IrcM7YiuxWrNuyIfKINyNc_pEVytGNNK750ZyyIm32qH6Wh3dGIBTvdPJ2v92xAohHwWw

Config.rgbXorKey:
a8e6bd132daf0360b1af1f5eea15e42f8c6f1dcd7d34376ae4e83a1a4f5907c0

Config.szMutexName:
GlobalctXjvsAxpzyqElmk

Config.szName:
default

After loading the default configuration, MoonWalk searches for a new configuration file at C:ProgramData[MD5(Config.rgbIDBytes)]. If found, the malware decrypts and loads this file. A sample of MoonWalk’s decrypted configuration is available in the Appendix of this blog for reference.

Unpacking and loading plugins

MoonWalk then extracts embedded plugins from the .lrsrc section. In the MoonWalk sample we analyzed, there were two plugins embedded within this section: one plugin for C2, and another plugin which provides utility functions such as public key cryptography and compression.

Each plugin in the .lrsrc section is prefixed with 72 bytes of metadata, which includes AES-CFB secrets, an MD5 checksum, and plugin type information. The plugin type information fields provide information about the features of a plugin. These fields help identify whether a plugin serves as a command handler, C2, or utility. More details about the structure of plugin metadata can be found in the Appendix section.

MoonWalk organizes these plugins by registering them in a global linked list. MoonWalk then goes through this list to load the C2 plugin and its dependencies, such as the utility plugin, using DLL hollowing. This process is similar to what we previously described in Part 1 for DodgeBox. Like DodgeBox, this MoonWalk sample stores a copy of the host DLL in C:WindowsMicrosoft.NETassemblyGAC_MSILSystem.Data.Trace.

Network Communication

After loading the C2 plugin, MoonWalk is prepared to establish communication with the C2 server. MoonWalk utilizes Google Drive for C2 communications. This helps MoonWalk evade detection, as traffic to and from reputable cloud services are less likely to raise suspicion, especially if a target is already using this service. Strangely, MoonWalk uses the string curl/7.54.0 as its User-Agent when making HTTP requests, even though it does not utilize libcurl in its C2 plugin, and uses the WinHTTP family of APIs instead.

At a high level, MoonWalk communicates over Google Drive in the following manner:

Curve25519_Donna(
    a1->rgbECDHServerPublicKey,
    // Public Key (out):
    // 000001e6`246391ec  b5 8f a7 ee 0b da d6 79-79 60 85 79 bf 32 ad 91
    // 000001e6`246391fc  24 a3 39 66 4c 4b 49 97-6c 71 92 d3 55 45 4b 3e
    a1->rgbClientAESKey,     
    // Private Key:
    // 000001e6`2463920c  54 be fd a7 f4 0f 62 15-fb 22 9a 48 04 e3 6e 90
    // 000001e6`2463921c  85 4b b9 c7 f2 5f de 57-65 59 9c 90 18 04 d9 d1
    a1->rgbECDHServerBasepoint);
    // Basepoint:
    // 000001e6`24639251  77 82 64 13 04 16 94 da-35 d2 1e b8 27 d7 35 ff
    // 000001e6`24639261  02 8a 47 85 56 41 29 5b-cb 3b 28 22 f2 69 3d 3a

rgbServerAESKey = rgbECDHServerPublicKey ^ Config.rgbXorKey
// 1d 69 1a fd 26 75 d5 19-c8 cf 9a 27 55 27 49 be
// a8 cc 24 ab 31 7f 7e fd-88 99 a8 c9 1a 1c 4c fe

Conclusion

MoonWalk is a sophisticated and modular backdoor that incorporates evasion techniques seen in DodgeBox. It also introduces innovative techniques, including the utilization of Windows Fibers, which are not commonly observed. These evasion techniques combined with the usage of a custom complex C2 communication protocol abusing Google Drive to blend in with legitimate traffic highlights the highly skilled nature of the APT41 threat adversary.

We continue to closely monitor the latest tactics, techniques, and procedures (TTPs) of this threat actor to protect our customers and share research with the security community.

Zscaler Coverage

Zscaler’s multilayered cloud security platform detects indicators related to DodgeBox at various levels with the following threat name.

• Win64.Backdoor.Moonwalk

Indicators Of Compromise (IOCs)

MITRE ATT&CK Framework

Appendix

.lrsrc section

An example of the .lrsrc section from MoonWalk is shown in the figure below.

Figure 5: An example of the .lrsrc section from MoonWalk.

The table below provides a description of the various fields.

Plugin metadata

An example of a MoonWalk C2 plugin’s metadata is shown in the figure below.

Figure 6: An example of a MoonWalk C2 plugin’s metadata.

The table below provides a description of the various fields.

Decrypted configuration

MoonWalk’s configuration is complex, containing arrays and nested structures of various types, as shown in the figure below. This analysis will focus only on the relevant fields, with non-essential bytes omitted from the analysis. These omitted bytes will either have unknown functionality or contain metadata for parsing the configuration.

An example of MoonWalk’s decrypted configuration is shown in the figure below.

Figure 7: MoonWalk’s configuration which contains arrays and nested structures of various types.

The table below provides a description of the various fields.