Tails from the shadow: APT 41 Injecting ShadowPad with Sideloading.

Intro

TLDR;

• Initial Access: Compromised VPN appliance as entry point.
• Lateral Movement: Via RDP.
• First Sign of Compromise: Suspicious DNS activity from spoolsv.exe.
• DLL Sideloading: Malicious DLL deployed via Logger.exe.
• Shellcode Injection: Injected into spoolsv.exe to evade detection.
• Use of ShadowPad: Employed for persistence and remote command execution.
• EDR Detection: Occurred at C2 phase with external DNS communication.

 

The HackersEye DFIR team's investigation into an APT41 attack uncovered the group's expertise in leveraging sophisticated tactics to target enterprise environments. The campaign began with a compromised VPN appliance, which enabled initial access, followed by lateral movement using RDP. The early indicators of compromise were only subtle traces, such as unusual DNS activity from spoolsv.exe. The details of APT41's approach are highlighted below:

 

• Initial Access: Compromised VPN appliance, followed by lateral movement via RDP.
• Malware Execution: APT41 used DLL sideloading with Logger.exe from Microsoft Logger SDK, injecting shellcode that launched ShadowPad.
• Persistence: ShadowPad, a modular backdoor, was deployed for persistence and remote command execution.
• Delayed Detection: The EDR system only detected the threat during the C2 phase, identifying suspicious DNS queries to external servers. This incident demonstrates APT41’s skill in deploying stealthy, multi-layered attack techniques. The fact that the EDR detected the threat only during the command-and-control stage underscores their ability to evade early detection and maintain a prolonged presence in compromised environments.

 

 

The critical vulnerability lays in “Logger.exe”‘s ability to load DLLs without validation. The attackers exploited this feature to bypass the system’s defenses, enabling them to remain undetected for an extended period. The EDR’s delayed detection further illustrates the challenge in identifying attacks that exploit legitimate tools in their execution.

 

Understanding ShadowPad: Origins and Usage

ShadowPad is a sophisticated modular backdoor and a tool of choice for several advanced persistent threat (APT) groups, mostly related to Chinese APT groups, and specifically APT41 AKA Barium.

Originating as a successor to PlugX, ShadowPad is designed to provide robust capabilities for long-term access, data exfiltration, and command execution. It boasts a highly flexible architecture, allowing attackers to deploy various modules tailored for specific operations, including C2 communications, keylogging, and data collection. Known for its use of encrypted communications and ability to blend into legitimate network traffic, ShadowPad is particularly effective at maintaining stealth and persistence in compromised environments. The tool’s extensive use by APT41 emphasizes their focus on targeted, high-value campaigns, often blending espionage with financially motivated attacks.

 

Group that Uses This Software according to MITRE

Source: https://attack.mitre.org/software/S0596/

 

Exploring APT41’s ShadowPad Exploits in Middle Eastern Critical Systems

 

APT41, also known as Barium, stands as one of the most technologically adept and elusive APT groups in the world. With origins rooted in China, they seamlessly blend cyber espionage with financially driven operations, targeting enterprises and critical infrastructure across regions, including the Middle East. Their campaigns frequently leverage supply chain vulnerabilities, demonstrating an unparalleled ability to infiltrate trusted systems and maintain long-term access.

 

A notable example of their advanced capabilities involves the exploitation of Microsoft’s Logger.exe, a legitimate debugging tool within the Microsoft SDK. Originally designed to log application processes for development purposes, APT41 repurposed it into a delivery mechanism for their malicious payloads. Utilizing DLL sideloading, they swapped the benign Logexts.dll with a weaponized variant. This allowed the group to inject shellcode into system processes and maintain covert control, bypassing conventional security measures and delaying EDR detection until the Command-and-Control phase.

 

The case of APT41 exemplifies how even trusted tools can become liabilities. For organizations, vigilance is key—legacy software, unchecked tools, and supply chain vulnerabilities present exploitable attack vectors. Comprehensive monitoring and proactive defenses are essential to staying ahead of these sophisticated adversaries.

 

As seen in the FBI wanted poster, five key members of APT41—ZHANG Haoran, TAN Dailin, QIAN Chuan, FU Qiang, and JIANG Lizhi—are accused of engaging in widespread cybercriminal activities. These individuals have conducted unauthorized network intrusions, supply chain attacks, and ransomware campaigns against industries across the globe. Their activities include identity theft, money laundering, and fraud, targeting sectors such as telecommunications, government, and technology. The poster emphasizes APT41’s dual focus on state-sponsored espionage and financial gain, highlighting the significant global impact of their operations.

 

Technical Analysis

The Rise and Fall of Logger.exe

Originally, Logger.exe was part of Microsoft's SDK, used to inject logging capabilities into applications for debugging. In conjunction with Logexts.dll, it provided detailed logging of application behavior, relying on shared memory communication. This is where APT41 found their opportunity.

APT41 exploited Logger.exe’s ability to load and inject DLLs without verifying their authenticity. This lack of validation allowed attackers to replace legitimate DLLs with malicious ones, gaining unauthorized control over system processes.

https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/using-logger-exe

 

Once APT41 successfully loaded their malicious version of Logexts.dll, they injected shellcode—a small piece of code designed to execute commands—directly into memory. The malicious Logexts.dll became the gateway for injecting shellcode into critical system processes, such as spoolsv.exe, effectively hijacking the system.

 

Endpoint Detection and Response (EDR) systems, designed to detect malicious activity, were delayed in identifying the attack because APT41 leveraged a legitimate, signed Microsoft binary. This method allowed the attack to evade detection, progressing through the network until the later command-and-control (C2) stages. Although effective, even this phase of the operation could have been stealthier. It is anticipated that APT groups like APT41 will continue refining their tactics to make future attacks even more covert, underscoring the ongoing need for improved detection capabilities.

 

“Shadowpad”, side loading techniques known from past research:

The logger tool is not yet to be known as a part of the shadowpad kit, until now.

https://www.secureworks.com/research/shadowpad-malware-analysis

 

Understanding Logger.exe

To understand how the attackers leveraged Logger.exe (which in our case was rebranded as connections.exe), it’s crucial to dive into the inner workings of the tool, particularly focusing on how it loads and utilizes the Logexts.dll library without performing any validation.

This is where the attackers found their opportunity to exploit the system.

Loading Logexts.dll Without Verification

 

The function FUN_100003320 is part of Logger.exe, a legitimate Microsoft SDK utility intended for debugging purposes. In this case, APT41 has weaponized Logger.exe for malicious DLL sideloading, abusing it to inject their customized, malicious version of logexts.dll into memory under the guise of a legitimate process.

 

Breakdown of FUN_100003320

 

Parameter Handling and Variable Initialization:

• The function starts by taking in three parameters (undefined8 param_1, undefined8 param_2, LPSTR param_3).
• Several local variables (local_e0, local_18, etc.) are defined and initialized to support further operations, including environment checks and handle management.

 

Environment Checks and Pre-Setup:

• GetVersionExA(&local_b8) is used to gather the Windows version information and check compatibility (local_b8.dwPlatformId == 1).

 

Initial Setup and Thread Creation

 

• The function starts by setting up the environment and creating a new UI thread using CreateThread. The thread is crucial for handling user interactions, but it is not directly relevant to the malicious loading of the DLL.

 

Loading Logexts.dll

• The function attempts to load Logexts.dll using the LoadLibraryA function:

This code attempts to load the DLL from two potential paths: the current directory and a subdirectory named winext. Notably, there is no validation performed on the DLL being loaded. This is a critical vulnerability, as it allows attackers to replace the legitimate Logexts.dll with a malicious one, enabling them to execute arbitrary code within the process.

 

Retrieving Function Pointers:

• Once the DLL is loaded, the function retrieves the addresses of several key functions within Logexts.dll using GetProcAddress:

These functions, such as LogDebuggerInit, logc, and others, are critical to the legitimate operation of logexts.dll. However, in the case of a malicious DLL, these pointers could be redirected to harmful routines, enabling the attacker to take control of the process. the full explanations on the logexts.dll file under Microsoft learning center:

https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/using-the-debugger-and-logexts-dll

 

Implications of the Exploitation

• No Validation: The lack of validation when loading Logexts.dll is the crux of the vulnerability. The attackers exploited this by substituting the legitimate DLL with their own, leading to a successful compromise of the system.
• Shellcode Execution: The ability to inject and execute shellcode via the loaded DLL highlights how easily this trusted utility can be turned against the system it was meant to help.
• Bypassing EDR: The use of a legitimate, signed binary (Logger.exe) combined with a malicious DLL allowed the attackers to bypass the EDR’s initial defenses, leading to delayed detection.

 

Shellcode Injection and Execution (Logexts.dll)

Flow Chart: Logger.exe Execution and Malicious DLL Loading Process

As the process is executed \ located by the “logger.exe” binary, it injects the “logexts.dll” file to its memory and executing it by jumping to the relevant entry point.

 

Shadowpad key execution function:

The ShadowPad malware code segment demonstrates several advanced evasion techniques that ensure its payload remains undetected while achieving successful execution:

 

• Dynamic API Resolution: The malware uses an indirect call to GetModuleHandleW to resolve the module base address dynamically, evading direct detection by static analysis tools.
• Memory Address Calculation: By adding an offset (0x3479) to the base address, the malware computes the exact location of the encrypted payload, making its whereabouts harder to trace.
• Retrieving and Decrypting Payload: The encrypted data (shellcode) is retrieved into ECX, then decrypted using an XOR operation with the hardcoded key 0x24448948. XOR decryption is lightweight and effective for runtime obfuscation.
• Anti-Forensic Measures: After decryption, the malware clears ECX to prevent residual decrypted data from being recovered during analysis.
• Conditional Execution Flow: The CMOVNZ instruction determines the subsequent value of RAX, adding conditional logic to obscure the flow of execution.
• Stack Management and Return: Finally, stack adjustments are made to align properly before returning, ensuring stability and avoiding detection by avoiding anomalous behaviors.

 

This ShadowPad segment decrypts shellcode in memory and seamlessly executes it. By using dynamic imports, encryption, and anti-forensic techniques, the malware decrypts and activates the shellcode in-memory for immediate execution while evading detection, demonstrating ShadowPad’s sophistication and capability to maintain stealth throughout its operations.

 

Intelligence and attribution:

 

Modus Operandi

Logexts.dll Case vs. APT41 Sideloading

 

Intelligence attribution:

Open-source threat intelligence research on the IP address reveals that it is associated with APT 41 (Barium), as indicated by findings from the Maltrail threat detection system.
https://github.com/stamparm/maltrail/blob/master/trails/static/malware/apt_barium.txt

 

Open-source threat intelligence research on the IP address reveals its association with ShadowPad, a malware tool used by APT41, according to findings from THREATfox.
https://threatfox.abuse.ch/ioc/1320780/

 

Open-source threat intelligence lookup on the C2 IP address via Censys revealed that the IP address is in Seoul, South Korea.

 

Open-source threat intelligence lookup on the C2 IP address via VirusTotal shows connections between the IP and ShadowPad malware.

 

A Twitter post reported the IP address as being involved in a malicious campaign, highlighting its role in cyberattack activity.

 

Conclusion , IOCs, Detection.

 

Attribution Analysis

• APT41 Parallels: The method used in the Logger.exe and Logexts.dll incident closely parallels the tactics of APT41, particularly the use of legitimate, signed binaries to sideload malicious DLLs. The similarities include the use of sideloading techniques, the deployment of shellcode, and the emphasis on stealth and persistence.
• Sophistication Level: Both the Logexts.dll incident and APT41’s operations demonstrate a high level of sophistication, characterized by careful planning and execution that exploits the trust placed in legitimate software.
• APT41 as a Likely Actor: Given the modus operandi and the observed parallels, it is reasonable to attribute the Logexts.dll incident to an actor with capabilities and methods like APT41. However, without direct evidence linking the specific attack to APT41, the attribution remains speculative but informed.

 

Detection and Mitigation

• In response to this discovery, the HackersEye team developed a YARA rule specifically designed to detect the behaviors and patterns associated with this attack. This rule focuses on:
• Detecting the use of LoadLibraryA to load Logexts.dll without validation.
• Identifying unique byte sequences and instructions within the malicious Logexts.dll, including the magic number validation and API hooking routines.

 

IOCS and yara: