’d like to thank my co-author, Martin Zugec, for his valuable contributions to this report.

TL;DR: Bitdefender Labs tracked a multi-wave intrusion targeting an Azerbaijani oil and gas company from late December 2025 through late February 2026. This research documents expansion of Chinese APT activity against South Caucasus energy infrastructure, attributed with moderate-to-high confidence to FamousSparrow (overlapping with the Earth Estries threat ecosystem).

The operation demonstrates several notable technical and strategic characteristics, most notably an evolved DLL sideloading technique. Unlike standard DLL sideloading that relies on simple file replacement, this method overrides two specific exported functions within the malicious library. This creates a two-stage trigger that gates the Deed RAT loader’s execution through the host application’s natural control flow, further evolving the defense evasion capabilities of traditional DLL sideloading.

Beyond the delivery mechanism, the operation is characterized by the deployment of two distinct backdoor families, Deed RAT and Terndoor, which were utilized across three separate waves of activity. This technical variety is matched by a strategic persistence, evidenced by the attackers' repeated return to the same vulnerable Microsoft Exchange server entry point despite multiple remediation attempts.

This targeting extends the known FamousSparrow victimology into a region where Azerbaijan’s role in European energy security has materially increased following the 2024 expiration of Russia’s Ukraine gas transit agreement and 2026 Strait of Hormuz disruptions. The intrusion illustrates that actors will exploit and re-exploit the same access path until the original vulnerability is patched, compromised credentials are rotated, and the attacker’s ability to return is fully disrupted.

Strategic Highlights

This intrusion adds three dimensions to the public understanding of Chinese APT activity in contested regions:

1. It extends FamousSparrow’s known targeting map. Prior public reporting documents activity against telecoms, government, and technology sectors across the United States, Asia-Pacific, Middle East, and South Africa. This research documents energy-sector targeting in the South Caucasus, a region not previously linked to this activity cluster in public reporting.

2. It reveals technical evolution in the Deed RAT toolchain. While the loader shares structural DNA with prior Deed RAT samples, it incorporates significant implementation changes. Magic values have been updated to 0xFF66ABCD, replacing 0xDEED4554, and Deflate has replaced Snappy for plugin decompression. But most notably, we discovered an interesting two-stage DLL sideloading mechanism designed to bypass automated analysis.

A legitimate binary is tricked into loading a malicious library masquerading as a trusted system component. But this malicious loader is engineered to remain inactive until the host application completes a specific sequence of internal calls.

By splitting its logic across two different functions, the malware requires the host application to follow its natural, full startup path before the malicious payload can execute. This effectively gates the infection, ensuring that security sandboxes that only examine parts of the code in isolation will fail to observe any malicious behavior.

3. It demonstrates operational discipline across repeated remediation cycles. The attackers returned to the same Exchange entry point three times across two months, swapping backdoors (Deed RAT in wave one, Terndoor attempt in wave two, modified Deed RAT in wave three) while preserving access. This is not opportunistic compromise, but rather sustained espionage with redundant persistence mechanisms and willingness to adapt tooling mid-operation. 

Context: The South Caucasus as Contested Cyber-Espionage Territory

In February 2025, Bitdefender Labs documented a Russia-aligned cyber-espionage operation pushing west from Central Asia into Europe in our analysis of UAC-0063 cyber-espionage operation expanding from Central Asia. That research established Central Asia as a region where Russia’s post-Ukraine influence has declined, China’s economic leverage via the Belt and Road Initiative has grown, and the Russia-China strategic relationship is characterized by both cooperation and competition across the cyber domain.

This research extends that analysis one region west-into the South Caucasus-and to a different actor: UAC-0063 is Russia-linked; FamousSparrow is likely affiliated with the Chinese APT ecosystem. The narrative sequencing is consistent. While Russia-aligned espionage operations have been documented moving westward from Central Asia, China-aligned activity is now visible in the South Caucasus, targeting energy infrastructure in a country whose strategic importance to European energy security has materially increased in the 2025 to 2026 timeframe.

Azerbaijan’s role in European gas supply expanded significantly after the Ukraine transit agreement expired at the end of 2024. A second shock arrived in early 2026 when Qatar LNG shipments were suspended and Strait of Hormuz disruptions reduced alternative sources. By early 2026, Azerbaijan has solidified its role as a strategic energy partner for Europe by expanding its reach to 13 European countries, including new deliveries to Germany and Austria, while maintaining a stable export volume that has grown by 56 percent cumulatively since 2021 (Astana Times, March 2026). Azerbaijan has become a more important energy partner to Europe in the period this intrusion was active.

This context does not establish motive. We have N=1 victim and moderate-to-high attribution confidence. What it does establish is that the victim’s sector and country matter because public reporting has not previously documented this FamousSparrow / Earth Estries activity cluster against energy infrastructure in the South Caucasus. This intrusion extends the known targeting map.

Attribution and Victimology

This intrusion is best attributed to FamousSparrow with moderate-to-high confidence, based on the combined weight of observed TTPs, malware families, and execution flow. The assessment reflects substantial overlap with the Earth Estries toolset and tradecraft.

The chain of evidence includes Exchange exploitation (T1190 Exploit Public-Facing Application), web-shell activity (T1505.003 Web Shell), post-compromise command execution, DLL sideloading (T1574.002 DLL Side-Loading), Deed RAT deployment, Mofu-based staging, and Terndoor-style driver-backed behavior. When viewed together, this intrusion chain is most consistent with the FamousSparrow side of the shared operational ecosystem, while reinforcing the close relationship between FamousSparrow and Earth Estries documented in prior public reporting by Cisco Talos, Trend Micro, Microsoft, and ESET.

FamousSparrow’s prior public victimology includes telecoms, government, and technology sectors across the United States, Asia-Pacific, Middle East, and South Africa. This intrusion extends that map to the energy sector in the South Caucasus.

Initial Access and Exchange Exploitation

The earliest signs of the intrusion date back to December 25, 2025, when the w3wp.exe process (Microsoft Exchange IIS worker process) attempted to write a malicious web shell into a publicly accessible directory on the Exchange server. The process command line contained the MSExchangePowerShellAppPool argument, indicating that the attacker exploited the Exchange server via the ProxyNotShell exploit chain (T1190 Exploit Public-Facing Application).

What are ProxyShell and ProxyNotShell?

ProxyShell and ProxyNotShell are exploit chains targeting Microsoft Exchange servers. ProxyShell (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207) chains three vulnerabilities to achieve remote code execution. ProxyNotShell (CVE-2022-41040, CVE-2022-41082) is a related exploit chain disclosed in 2022. Both allow unauthenticated attackers to execute code on unpatched Exchange servers, making them high-value initial-access vectors for APT actors. Bitdefender published a detailed technical advisory on these exploit chains: Technical Advisory: ProxyHell Exploit Chains in the Wild.

Further attempts to deploy web shells were recorded on December 26 and December 29, with filenames including key.aspx, log.aspx, errorFE_.aspx, and signout_.aspx. In parallel, the investigation revealed attempts to execute commands through w3wp.exe under the MSExchangePowerShellAppPool, pointing to the use of the ProxyNotShell exploit chain as well.

These actions suggest the attackers were working to establish a persistent foothold before deploying the Deed RAT backdoor. This stage involved the use of the legitimate binary C:\TEMP\LMIGuardianSvc.exe alongside the malicious loader C:\TEMP\lmiguardiandll.dll, setting the stage for the next phase of the compromise.

Defender action: Monitor for w3wp.exe writing .aspx files to publicly accessible directories, especially under the MSExchangePowerShellAppPool context. Legitimate Exchange maintenance workflows rarely write web-accessible script files through the IIS worker process.

First Wave: Deed RAT Deployment via LogMeIn Hamachi Triad

The next stage of the intrusion began with the execution of C:\TEMP\LMIGuardianSvc.exe (MD5: 0554f3b69d39d175dd110d765c11347a), which sideloaded C:\TEMP\lmiguardiandll.dll. That DLL initiated the execution chain of a backdoor later identified as Deed RAT. The attribution became clear after recovering a third component, C:\TEMP\.hamachi.lng, revealing the full three-part deployment chain used by the attackers.

What is DLL Sideloading?

DLL sideloading is a technique where an attacker places a malicious DLL next to a legitimate executable that loads DLLs by filename rather than by full path. When the legitimate binary runs, it loads the attacker’s DLL instead of the expected library, transferring execution to malicious code without modifying the legitimate binary itself. You can learn more in our explainer “What is DLL Sideloading?”.

Once executed, the malware was installed in C:\Program Files (x86)\LogMeIn Hamachi\, a location deliberately chosen to mimic the legitimate installation path of LogMeIn Hamachi and thereby reduce suspicion. To secure persistence (T1543.003 Windows Service), the attackers created a service named LogMeIn Hamachi, configured to automatically launch C:\Program Files (x86)\LogMeIn Hamachi\LMIGuardianSvc.exe at system startup.

The Three-Component Chain

Deed RAT is delivered through a three-component chain that blends seamlessly into the legitimate LogMeIn Hamachi ecosystem:

1. LMIGuardianSvc.exe: Legitimate LogMeIn Hamachi binary (MD5: 0554f3b69d39d175dd110d765c11347a)
2. LMIGuardianDll.dll: Malicious loader that patches a Windows API and stages the payload
3. .hamachi.lng: Encrypted Deed RAT payload

This setup enables the backdoor to execute via the LogMeIn Hamachi launcher, maintaining a veneer of legitimacy even though the underlying application remains non-functional.

Evolution of DLL Sideloading: Implicit Anti-Analysis via Legitimate Execution Gating

Traditional DLL sideloading places a malicious DLL next to a legitimate executable, and when that executable runs, the DLL’s entry point (DllMain) or a specific export is invoked, triggering the malicious logic immediately. This execution model is straightforward: load the DLL, call the entry point, run the payload.

The Deed RAT loader observed in this intrusion operates differently. Instead of triggering immediately when loaded, it distributes its functionality across two exports: Init and ComMain and embeds itself inside the control flow that the legitimate LogMeIn Hamachi application follows during normal operation. This means the malware does not need to hijack the overall application flow immediately but instead embeds itself inside an execution path that appears legitimate.

Image: Import resolution from LMIGuardianSvc.exe 

The role of Init is not to execute the payload, but to quietly prepare the conditions for it. During this stage, the DLL targets the Windows API function StartServiceCtrlDispatcherW and modifies it so that future calls will be redirected. This is achieved by temporarily changing memory protections (T1562 Impair Defenses), preserving the original function bytes, and patching the function entry point.

What is API Hooking / Patching?

API hooking (also called API patching) is a technique where malware modifies the first few bytes of a Windows API function in memory so that calls to that function are redirected to malicious code. The attacker preserves the original bytes so they can be restored later, preventing the hook from being detected if another process or security tool inspects the function.

Once this setup is complete, Init exits and the application continues as expected.

Image: StartServiceCtrlDispatcherW patching within the Init export of LMIGuardianDll.dll

The second stage occurs later, when LMIGuardianSvc.exe continues its normal execution and eventually calls the ComMain export.

Image: winMain flow of LMIGuardianSvc.exe

From there, the legitimate service flow leads to a call to StartServiceCtrlDispatcherW. Because that API was previously patched during Init, the call is transparently diverted into the malicious loader function. The loader then restores the original bytes of StartServiceCtrlDispatcherW, ensuring that the hook is removed after use, and proceeds with the next stage of execution, including access to the .hamachi.lng component.

This separation between preparation and execution introduces a dependency on the normal behavior of the host application, effectively gating the malicious logic behind a legitimate execution path. The payload will only run if the application follows the expected sequence of calls, meaning that partial or out-of-context execution is unlikely to trigger it.

From an analysis perspective, this has clear implications. In many sandbox or automated triage environments, the DLL may be executed on its own, a single export may be invoked, or the full application workflow may not be reproduced. Under those conditions, the malware appears largely inactive. The hook may be installed, but without the subsequent API call, the loader is never reached and the payload remains concealed.

In this way, the malware implicitly validates its execution context. Rather than relying on explicit anti-analysis checks (checking for virtual machines, debuggers, hooks, usernames, or process lists), it ensures that its behavior is only exposed when it is exercised in the same way as the legitimate application. This reduces the likelihood of accidental activation during superficial analysis and makes the sample significantly less revealing in incomplete environments.

Defender action: Monitor for changes to the first few bytes of commonly-hooked Windows APIs (NtCreateFile, CreateProcessW, StartServiceCtrlDispatcherW, LdrLoadDll). Legitimate applications rarely patch system API entry points; when they do, the patches are applied by signed system components or documented security tools. Unsigned binaries applying API hooks should trigger investigation.

Shellcode Loader and PE-like Header Format

The .hamachi.lng file contains the next-stage shellcode along with the Deed RAT payload. It is decrypted using AES-128 in CBC mode with an initialization vector of 16 null bytes. The decryption key is derived from the first 16 bytes of the file, while the remainder represents the encrypted payload. Once decrypted, the shellcode is executed directly in memory, completing the transition from staged components to an active backdoor.

What is AES-CBC?

AES-CBC (Advanced Encryption Standard in Cipher Block Chaining mode) is a block cipher that encrypts data in 16-byte blocks. Each block’s ciphertext depends on the plaintext of the current block and the ciphertext of the previous block, making identical plaintext blocks produce different ciphertext when encrypted. The Initialization Vector (IV) seeds the first block. AES-CBC is widely used in both legitimate software and malware because it is fast, well-supported, and considered secure when implemented correctly.

Shellcode resolves the DLLs and Windows API functions required to decrypt, load, and execute the Deed RAT orchestrator. It retrieves function addresses by computing the ELF hash (a string-hashing algorithm derived from Unix ELF binary format tooling) of their names-a technique that hides API imports from static analysis by resolving them at runtime via hash comparison rather than by name-including APIs such as VirtualAlloc, VirtualFree, VirtualProtect, and RtlDecompressBuffer.

The orchestrator itself is stored in encrypted form immediately after the shellcode in memory and is decrypted using RC4.

What is RC4?

RC4 is a stream cipher that generates a pseudo-random byte stream (keystream) which is XORed with plaintext to produce ciphertext, or XORed with ciphertext to recover plaintext. It is fast and simple to implement, but considered cryptographically weak by modern standards due to biases in the keystream. Malware authors continue to use RC4 because it is small, fast, and does not require padding or block-size alignment like AES-CBC.

The RC4 key is embedded at a hardcoded offset within the shellcode, and the encrypted next-stage payload is located directly after the key.

Image: Shellcode layout with RC4 key highlighted, pointing to encrypted orchestrator location.

The resulting payload is then decompressed using RtlDecompressBuffer with the COMPRESSION_FORMAT_LZNT1 format, producing a final executable preceded by a custom PE-like header.

 Image: Decrypted Deed RAT main module 

What is LZNT1?

LZNT1 is a compression format native to Windows, commonly used by Windows for compressing registry hives, paging files, and file-system data. Malware authors use LZNT1 because it is fast, already present on every Windows system (no external library required), and does not require the malware to statically link a compression library like zlib or LZMA.

 The header structure is consistent with the format documented by PT Security in its Space Pirates analysis:

An interesting detail is that the magic DWORD, from which the malware originally derived its name, had been changed from 0xDEED4554 to 0xFF66ABCD. The shellcode first verifies that the magic matches the expected value, then proceeds to load the executable into memory by allocating the required space and copying the contents of the malware’s three sections into their appropriate locations. It then applies the necessary relocations before calculating the entry point from the header structure and invoking it, thereby transferring execution to the Deed RAT orchestrator.

Defender action: Apply memory scanning and shellcode pattern detection as a defensive layer. Memory forensics tools and in-memory YARA scanners can identify characteristic patterns: custom PE-like headers with non-standard magic values (0xFF66ABCD, 0xDEED4554), LZNT1-compressed payloads following RC4 decryption, and ELF hash-based API resolution.

Orchestrator, Plugins, and Configuration Encryption

The overall Deed RAT architecture remained largely unchanged and is consistent with the analysis published by PT Security. The main differences were observed in the algorithms used for string, configuration, and plugin encryption. Together with the changes in the magic values used for modules and configuration data, these modifications suggest that the malware is continuing to evolve.

The orchestrator serves as the main module and is responsible for unpacking and loading the embedded plugins into memory. The plugins are stored as a concatenated series of blobs, each with a custom structure: the first 4 bytes indicate the size of the encrypted plugin data in network byte order (big-endian, most significant byte first), the next 4 bytes provide the seed for the PRNG-based decryption routine (network byte order), and the remaining bytes contain the encrypted plugin content.

The orchestrator processes these blobs sequentially, treating them as entries in a continuous plugin list. It continues parsing and decrypting plugins one after another until it reaches an entry with a size field of 0, which acts as the terminator for the list.

Image: Plugin loading loop from the orchestrator, showing sequential blob parsing and decryption.

Next, the blob data is XOR-decrypted using the byte stream generated by a custom PRNG algorithm. Following this decryption stage, the plugin is only partially recovered, with the header (including the 0xFF66ABCD magic value) becoming visible while the remaining content is left in compressed form. That data is then decompressed using Deflate. The switch from Snappy, used in older variants, to Deflate is particularly noteworthy, as it suggests the malware authors are prioritizing compatibility or payload size over decompression speed.

What is Deflate?

Deflate is a lossless compression algorithm combining LZ77 (dictionary-based compression) and Huffman coding. It is the compression format used by gzip, zip, and zlib. Deflate is ubiquitous in legitimate software and malware alike because it produces compact output, decompresses quickly, and is available in every major operating system and programming language runtime.

What is Snappy?

Snappy is a compression library developed by Google, optimized for speed rather than maximum compression ratio. It is faster than Deflate but produces larger output. Snappy is less common in malware than Deflate or LZNT1, but has been observed in Deed RAT’s older variants.

Image: PRNG algorithm used to generate the XOR decryption byte stream for plugin blobs.

While the plugin module IDs themselves remained unchanged-including Startup (0x30), Config (0x40), Plugin (0x50), Network (0x60), NetSocket (0x70), NetProxy (0x90), Install (0xA0), Inject (0xB0), and the orchestrator with 0x20 - the identifiers used by the orchestrator to invoke plugin functionality have changed.

In the current version, these invocation IDs appear to be shifted by 0x100. A smaller change was also observed in the plugin entry-point logic: whereas older versions used values such as 0x1, 0x2, and 0x4 when calling the plugin entry point to retrieve the module ID and exported API table, the current sample uses updated values offset by 0x10.

Image: Plugin entrypoint calling from the main module on the left, and entrypoint of the Config plugin

The strings utilized within the plugins are decoded with an algorithm that initializes the decoding state from the first input byte, then updates it for each step using the transformation state = 3 * (state + __ROL1__(state, 3)). The resulting state value is then XORed with the next encoded byte to recover the plaintext. Decoding continues until a byte equal to the current state value is encountered, which serves as a terminator, after which the routine null-terminates the output buffer.

The configuration is stored in the Config plugin as an encrypted blob. The first 4 bytes, in network byte order, represent the seed value. The next 4 bytes contain the configuration size, which is obtained by XORing the stored value with that seed. The remaining bytes of the blob are then processed by the PRNG-based decoding routine used in the plugin decryption.

After the blob is decrypted, its contents are interpreted as a structure identified by the magic value 0x46B78C45, which differs from that used in previous versions. The structure contains offsets relative to its beginning, and these offsets point to encoded strings that are decoded using the same string routine employed by the plugin. Some of the strings recovered from one Config module sample are shown below:

The %AutoPath% variable is assigned based on the process's execution context. If the backdoor lacks administrative rights, the path is set to %AppData%. If it possesses administrative rights, the variable is set to %ProgramFiles(x86)% on 64-bit systems, or %ProgramFiles% on 32-bit operating systems.

Defender action: Monitor for outbound HTTPS connections to domains that masquerade as security vendors but are not registered to those organizations. Cross-reference DNS queries and TLS certificate subjects against known-good vendor domains. Attackers rely on defenders skimming logs and assuming virusblocker[.]it[.]com is legitimate without verifying ownership.

What Has Changed Compared to Prior Deed RAT Variants?

Additional indicators reinforce the connection to previously documented Deed RAT activity. The DLL exposes two extra functions, CryptProtectDataNoUI and CryptUnprotectDataNoUI, which do not appear to serve a functional role in the execution chain. Instead, they correspond to cryptographic routines derived from mbedTLS, with strong similarities to dh_client and aescrypt2.c. Their presence, despite not being required, suggests code reuse and possibly an attempt to obscure the true purpose of the DLL.

Image: LMIGuardianDll.dll exported functions

These characteristics closely match a Deed RAT loader described by Trend Micro in its reporting on the Earth Estries threat actor. In particular, the sample identified by MD5 505b55c2b68e32acb5ad13588e1491a5 exhibits the same unusual exports, similar mbedTLS-derived code, and an almost identical execution model. In both cases, StartServiceCtrlDispatcherW is modified to redirect execution, while the actual trigger depends on another function within the process to reach that API call.

Image: Side-by-side comparison of current LMIGuardianDll.dll loader (left) vs. Trend Micro sample loader (right), showing identical hook-and-restore flow for StartServiceCtrlDispatcherW.

An additional point of similarity between the current loader and the older sample is their use of cryptographic code derived from mbedTLS. In the current sample, the AES key schedule function used in the CryptProtectDataNoUI export is also reused by the loader to decrypt the .hamachi.lng payload, suggesting that mbedTLS is statically linked into the loader. Likewise, loader 505b55c2b68e32acb5ad13588e1491a5 contains an RC4 implementation that also closely resembles mbedTLS code. This provides another indication that the two loaders share a similar design and implementation approach.

Although Deed RAT’s overall functionality remains consistent with previously documented variants, the sample analyzed in this intrusion includes several notable implementation changes. These include updates to loader behavior, encryption and decompression logic, magic values, and plugin invocation patterns. Taken together, these differences suggest that while the malware’s core architecture and capabilities have been preserved, its developers continue to refine and evolve the codebase over time.

Lateral Movement and Privilege Abuse

With persistence established on the first compromised host, the attackers expanded their operation. They pivoted to another server using RDP (T1021.001 Remote Desktop Protocol) and authenticated with a domain administrator account, suggesting they had already obtained highly privileged credentials. After opening an interactive remote session, they launched a PowerShell console (T1059.001 PowerShell), and within minutes, LMIGuardianSvc.exe and its associated files appeared on the system. This sequence strongly suggests that the Deed RAT payload was manually downloaded and staged on the second host as part of an effort to create a redundant persistence point elsewhere in the environment.

From that second compromised system, the attackers continued to broaden their access. Evidence shows that they used atexec and smbexec-style utilities (consistent with the Impacket toolkit) (T1021.002 SMB/Windows Admin Shares) to spread the infection to yet another machine, indicating a deliberate attempt to move laterally, replicate their foothold, and preserve operational resilience in case one access point was discovered and removed.

What is Impacket?

Impacket is an open-source Python library that reimplements Windows network protocols – SMB, MSRPC, DCOM/WMI, and Kerberos – allowing attackers to execute remote commands and move laterally across Windows networks from a Linux system without installing agents or malware on target hosts. You can learn more in our explainer “What is Impacket?”.

Defender action: Detect RDP sessions initiated from internal hosts using domain administrator credentials outside of scheduled maintenance windows. Legitimate administrator workflows rarely involve interactive RDP sessions that spawn PowerShell consoles and download executables within minutes.

Second Wave: Terndoor via Mofu Loader

At some stage, remediation actions were taken and the malware was removed from at least one affected system. However, rather than abandoning the intrusion, the attackers returned to the same vulnerable Exchange server nearly a month after the initial compromise attempt. This time, instead of redeploying Deed RAT immediately, they attempted to install a different backdoor identified as Terndoor.

USOShared Sideloading Chain and the vmflt Driver Attempt

During the second wave of the attack, the file C:\ProgramData\USOShared\USOShared.exe (MD5: 762f787534a891eca8aa9b41330b4108) was identified on the system. This file is a renamed copy of the legitimate deskband_injector64.exe, which was abused to sideload the malicious loader C:\ProgramData\USOShared\winmm.dll. The attempt was unsuccessful, as the security solution blocked execution before the malware could complete its installation.

Even so, several execution artefacts were recovered. These included network communication with legitimate service ipinfo[.]io and evidence that the malware attempted to create a service for loading a driver. Traces of this activity were found in the registry, specifically HKLM\SYSTEM\ControlSet001\Services\vmflt\Type with value 1, indicating a kernel driver service (T1014 Rootkit), and HKLM\SYSTEM\ControlSet001\Services\vmflt\ImagePath with the value \??\C:\ProgramData\USOShared\vmflt.sys. In addition, several memory pages were recovered that corresponded to the first page of shellcode memory.

Defender action: Monitor for service creation events where Type = 1 (kernel driver) and the ImagePath points to a non-standard location (C:\ProgramData, C:\Temp, user-writable directories). Legitimate kernel drivers are almost always installed via signed INF files and placed in C:\Windows\System32\drivers\.

Payload Recovery via Memory Page Analysis

At the time, the absence of both winmm.dll and vmflt.sys prevented reliable malware identification. The recovered shellcode fragments were also of limited immediate value, as the first instruction redirected execution to a location outside the initial 4096-byte page, while the remaining bytes looked much random, suggesting the presence of encoded or compressed data.

These artefacts became more meaningful after Cisco Talos published its report on UAT-9244, which it linked to FamousSparrow with high confidence. In particular, the reported Terndoor execution chain also resulted in the deployment of a Windows driver, providing the first strong point of similarity with the malware loaded through winmm.dll in this case.

Analysis then focused on understanding the shellcode structure. Recovered memory pages showed characteristics consistent with Mofu loader (a shellcode loader documented by JPCERT), including a NOP followed by a CALL instruction that transfers execution to code located after the encrypted data. The return address from this call is used to locate the encrypted payload.

That payload is prefixed with a 12-byte header containing a 4-byte seed and two additional 4-byte values describing the encrypted data size. In practice, this means the payload begins 18 bytes from the start of the shellcode. After one round of subtract-XOR-add transformation, the embedded data is recovered as an LZNT1-compressed PE executable.

Image: Recovered Mofu loader memory page showing NOP+CALL prologue and 12-byte header structure.

The inner workings of the Mofu loader are particularly relevant because one of the recovered memory pages closely matched the shellcode immediately after the subtract-XOR-add decryption stage.

Image: Memory page of the shellcode used in the intrusion closely resembling Mofu loader

Applying LZNT1 decompression to the data starting at offset 18 yields a partial payload that was intended to be executed on the affected system. The result is a PE executable (Windows executable format) with the MZ and PE magic values (file header signatures) stripped, a characteristic trace of Mofu loader activity.

Image: Payload decompressed from the Mofu loader shellcode memory page, showing stripped MZ/PE headers.

Corroboration with Cisco Talos UAT-9244 Reporting

Although Mofu Loader is publicly known to have been used to deliver a range of payloads, including SlyMongo, RatelS, Cobalt Strike, and microDown, the partially recovered payload in this case is assessed to be Terndoor. This assessment is supported by multiple technical indicators rather than by a single artefact.

The first indication comes from behavior observed during execution. The payload attempted to drop a driver and create a service for loading that driver, which is consistent with the execution pattern associated with Terndoor. A second strong indicator is the section layout of the partially recovered PE payload: the section names match those of the Terndoor sample documented in the Cisco Talos UAT-9244 article.

Additional evidence was recovered from other memory pages attributed to the payload itself. One of these showed that the malware stores its strings in encrypted form, reconstructs them on the stack, and then decodes them with a one-byte XOR operation.

Another page revealed an RC4 implementation distinguished by its use of a hardcoded key. As illustrated in the figure below, the recovered RC4 logic closely matches the implementation pattern observed in similar samples. In both cases, the key is first copied into a 256-byte buffer, after which the remaining bytes are zero-initialized through a function assessed to be memset, with the size argument hardcoded to 256 - key_size. The key length is also hardcoded in the key-scheduling portion of the RC4 routine. These shared implementation details provide another strong point of similarity.

Image: RC4 implementation fingerprint comparison between the current sample (left) and Cisco Talos sample (right)

Taken together, these behavioral and code-level similarities provide strong evidence that the payload delivered in this intrusion was indeed Terndoor.

The following strings were recovered from one of the payload’s memory pages:

Defender action: Monitor for process creation where the parent is deskband_injector64.exe or other legitimate signed binaries known to be abused for DLL sideloading, and the child process is msdt.exe or another trusted Windows binary. Legitimate workflows rarely involve deskband_injector64.exe launching diagnostic tools.

Third Wave: Deed RAT Returns with Modified Configuration

The final observed wave of malicious activity took place at the end of February, when the attackers once again attempted to deploy Deed RAT using the same execution chain previously documented during the earlier stages of the intrusion. While the underlying deployment method remained consistent, the malware configuration had been modified, indicating that the operators were actively adjusting their tooling while continuing to rely on an access path they still considered viable.

The second Deed RAT sample uses sentinelonepro [.]com:443 as its HTTPS command-and-control (C2) server. In this variant, all three malware components have been relocated to C:\Recovery.

The following table lists the exported strings.
An asterisk (*) denotes a value that has changed since the first variant.

Conclusion and Recommendations

This intrusion should not be viewed as an isolated compromise, but as a sustained and adaptive operation conducted by an actor that repeatedly sought to regain and extend access within the victim environment. Across multiple waves of activity, the same access path was revisited, new payloads were introduced, and additional footholds were established, underscoring a high degree of persistence and operational discipline.

The findings presented in this article add several new elements to the public understanding of this activity cluster. In particular, they document a detailed Deed RAT deployment and loading chain, highlight implementation changes that distinguish the current samples from previously published variants, and show how a second-wave payload consistent with Terndoor was staged through a Mofu loader chain. Together, these observations reinforce not only the persistence of the actor, but also the continued development of its malware ecosystem and the need to treat such intrusions as long-running operations rather than single-point incidents.

Defensive Recommendations

• Patch internet-facing services immediately. ProxyShell and ProxyNotShell exploits against Exchange have been publicly documented since 2021 and 2022 respectively. Attackers will continue to exploit unpatched servers until they are either patched or taken offline. If patching is not immediately possible, segment the Exchange server so that a compromise does not grant domain-wide access.

• Apply runtime behavioral monitoring. Signature-based detection will not catch fileless execution, DLL sideloading, or loaders that gate their execution on the host application’s natural control flow. Detection must watch for behavior, not binary signatures.

• Monitor for API hooking at the kernel level. Legitimate applications rarely patch system API entry points; when they do, the patches are applied by signed system components or documented security tools. Unsigned binaries applying API hooks should trigger investigation.

• Detect lateral movement via RDP and SMB. RDP sessions initiated from internal hosts using domain administrator credentials outside of scheduled maintenance windows should trigger alerts. Similarly, SMB-based remote execution tools (Impacket atexec, smbexec, PsExec) are rarely used in legitimate workflows outside of IT administration; their use should be logged and reviewed.

• Rotate credentials after compromise. If domain administrator credentials are used during an intrusion, they must be rotated immediately after remediation. Attackers will reuse compromised credentials to regain access even after malware is removed.

IOCs and How to Follow Our Research

The full indicator set for this research is available to Bitdefender IntelliZone subscribers. A curated subset is published to our GitHub IOC repository to support other researchers and the wider defender community.

For updates on our research and security advisories, subscribe to the Ctrl-Alt-DECODE newsletter.

Related reading:

• UAC-0063 cyber-espionage operation expanding from Central Asia (Bitdefender Labs, February 2025)
• Technical Advisory: ProxyHell Exploit Chains in the Wild (Bitdefender Labs, 2023)
• Cisco Talos UAT-9244 Reporting (Cisco Talos, 2026)
• Earth Estries Targets Organizations Across Government and Technology Sectors (Trend Micro, 2023)
• Space Pirates: Tools and Connections (PT Security, 2022)
• Mofu Loader Analysis (JPCERT, 2024)

MITRE ATT&CK Mapping