Chinese-linked threat actor FamousSparrow has conducted a sustained intrusion campaign against an Azerbaijani oil and gas company, returning to the same compromised entry point three separate times between late December 2025 and late February 2026.
Bitdefender researchers attribute with moderate-to-high confidence the operation to FamousSparrow, a group that overlaps with the broader Earth Estries and Salt Typhoon activity clusters, marking a significant expansion of the actor’s known targeting geography into a region that has become increasingly critical to European energy security.
“Bitdefender Labs tracked a multi-wave intrusion targeting an Azerbaijani oil and gas company from late December 2025 through late February 2026.” reads the report by Bitdefender. “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 timing is not incidental. Following the expiration of Russia’s Ukraine gas transit agreement at the end of 2024 and the disruption of Strait of Hormuz shipments in early 2026, Azerbaijan has rapidly solidified its position as a strategic energy supplier for Europe, delivering gas to thirteen countries, including Germany and Austria. Against that backdrop, the targeting of Azerbaijani energy infrastructure by a China-aligned actor fits a pattern of espionage operations that track geopolitical shifts and follow the energy supply chains that matter to adversaries.
What makes this campaign technically distinctive is not just its persistence, but the methodical way in which FamousSparrow hackers adapted their tooling while preserving the same initial access vector throughout.
The intrusion began on December 25, 2025, when the attackers exploited a vulnerable Microsoft Exchange Server using the ProxyNotShell exploit chain, a vulnerability pair publicly disclosed back in 2022. Web shells with names like key.aspx, log.aspx, and errorFE_.aspx were dropped into publicly accessible directories in the days that followed, establishing the foothold the operators would return to repeatedly.
Despite remediation attempts by the victim organization, the attackers came back. Three times. Each time through the same Exchange server. Each time with a different payload.
The first wave deployed Deed RAT, a successor to ShadowPad used across multiple Chinese espionage groups, through an evolved DLL sideloading technique that stands out from more conventional implementations. Rather than simply replacing a legitimate DLL and executing immediately on load, the malicious library distributed its logic across two exported functions, Init and ComMain, creating a two-stage execution gate tied to the host application’s natural startup flow.
The legitimate LogMeIn Hamachi binary LMIGuardianSvc.exe served as the carrier. During the Init stage, the malicious DLL quietly patched the Windows API function StartServiceCtrlDispatcherW in memory without triggering any payload. Only later, when the application reached ComMain and followed its normal execution path to call that API, did the hook redirect control into the loader, which then restored the original API bytes and proceeded to decrypt and execute the Deed RAT payload from the encrypted .hamachi.lng file.
“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.” continues the report. “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.”
The payload itself went through multiple layers: AES-128 decryption of the .hamachi.lng file, shellcode execution that resolved API functions via ELF hash rather than by name, RC4 decryption of the orchestrator, and finally LZNT1 decompression before a custom PE-like header format, with an updated magic value of 0xFF66ABCD replacing the previously documented 0xDEED4554, was processed to load the final module into memory.
The Deed RAT architecture retained its modular plugin structure, Startup, Config, Network, Proxy, Inject, and others, but with noteworthy implementation changes. Plugin decompression switched from Snappy to Deflate, invocation identifiers shifted by 0x100, and the configuration magic value changed. The C2 address embedded in the first wave’s configuration was virusblocker[.]it[.]com:443, a domain crafted to look like a security vendor.
With persistence established, the attackers moved laterally via RDP using domain administrator credentials, manually staging Deed RAT on a second server within minutes of opening the session. They then spread further using Impacket-style SMB execution utilities, building redundant footholds across the environment.
Nearly a month after the initial compromise, the attackers returned via the same Exchange server and attempted to deploy Terndoor, a backdoor previously observed in attacks against telecommunications infrastructure in South America, through a Mofu loader shellcode chain. The delivery mechanism abused a renamed copy of the legitimate deskband_injector64.exe to sideload a malicious winmm.dll.
“The attempt was unsuccessful, as the security solution blocked execution before the malware could complete its installation.” Bitdefender says. “Even so, several execution artefacts were recovered, including network communication with legitimate service ipinfo[.]io and evidence that the malware attempted to create a service for loading a driver.”
Registry traces showed attempted creation of a kernel driver service pointing to vmflt.sys in C:\ProgramData\USOShared, a non-standard location that legitimate kernel drivers almost never occupy. Recovered memory pages revealed a shellcode structure consistent with Mofu loader: a NOP followed by a CALL instruction using the return address to locate an encrypted payload, prefixed with a 12-byte header containing a seed and two size values, followed by LZNT1-compressed content with stripped MZ/PE headers.
The payload’s behavioral profile, driver installation, injection target strings including msdt.exe, RC4 implementation with a hardcoded key matching documented Terndoor samples, and section names consistent with Cisco Talos reporting on UAT-9244, supported the Terndoor attribution despite the partial recovery.
At the end of February 2026, the attackers made a third attempt using the same LogMeIn Hamachi sideloading chain, this time with a modified Deed RAT configuration. The mutex name changed, the service was renamed HamachiNet, injection targets were updated to include wininit.exe and dwm.exe, and the C2 address became sentinelonepro[.]com:443, masquerading as a well-known endpoint security vendor.
“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.” continues the report.
The files were relocated to C:\Recovery rather than the Hamachi installation directory, suggesting the operators were aware their previous artifacts may have been identified and removed.
The strategic significance runs in two directions. Geopolitically, this is the first documented instance of the FamousSparrow / Earth Estries activity cluster targeting energy infrastructure in the South Caucasus — a region where Chinese economic leverage through Belt and Road infrastructure is growing at the same time that Russian influence is contracting post-Ukraine.
Technically, the operation illustrates something defenders encounter repeatedly but often underestimate: an attacker who keeps coming back through the same door is an attacker who knows that door has not been fully closed.
“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.” Bitdefender says. “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.”
ProxyNotShell was disclosed in 2022. The Exchange server at the center of this campaign was still exploitable through at least late February 2026, more than three years later. Patching internet-facing services remains the single most impactful defensive action available to organizations in sectors that geopolitical actors consider strategically valuable. It is also, evidently, still not happening fast enough.
“Patch internet-facing services immediately. ProxyShell and ProxyNotShell exploits against Exchange have been publicly documented since 2021 and 2022 respectively.” concludes the report. “Attackers will continue to exploit unpatched servers until they are either patched or taken offline.”
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, FamousSparrow)
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。