FamousSparrow Azerbaijan intrusion

FamousSparrow Three-Wave Intrusion of an Azerbaijani Energy Operator: ProxyNotShell Re-exploitation and a Wave-1 DLL-Sideload Loader That Overrides Two Hamachi Exports to Defeat Sandbox Analysis

Background. FamousSparrow has been tracked publicly since 2021 as a China-nexus espionage cluster targeting hotels, government and engineering firms; Bitdefender's 2026-05-13 write-up cites tooling and infrastructure overlap with the Earth Estries cluster, and The Hacker News summary additionally notes Salt Typhoon overlap. Recent primary technical detail has been sparse — the Bitdefender Labs publication on 2026-05-13 is the first multi-wave intrusion case study against an energy-sector victim published in some time (Bitdefender Labs, 2026-05-13; The Hacker News, 2026-05-13). The Azerbaijan targeting is geopolitically novel for the cluster: Bitdefender characterises Azerbaijani gas-export expansion to 13 European countries (with new flows to Germany and Austria) following the post-Ukraine-transit reconfiguration, making extraction and transit infrastructure intelligence operationally valuable to Chinese state actors monitoring European energy supply dependencies.

Victim, time-frame, framing. Bitdefender Labs documented a three-wave intrusion against an unnamed Azerbaijani oil and gas operator spanning December 2025 to February 2026, attributed with moderate-to-high confidence to FamousSparrow (also tracked as UAT-9244 in Talos taxonomy). The operationally most consequential framing is not the attribution but the fact that all three waves re-used the same Exchange initial access vector despite the victim's attempted remediation — the structural lesson is patch-completeness verification rather than novel-zero-day defence.

Vulnerability mechanics & initial access. Initial access in every wave exploited the ProxyNotShell chain — CVE-2022-41040 (SSRF in the Exchange front-end Auto-discover handler) chained with CVE-2022-41082 (deserialisation in the back-end PowerShell remoting endpoint) against an on-premises Microsoft Exchange Server. The vulnerable surface is the front-end Exchange Autodiscover.svc accepting a crafted IIS request that triggers internal SSRF to the Mailbox role's PowerShell remoting endpoint; the deserialisation in the chained PowerShell context yields code execution under the Exchange application-pool identity (typically LocalSystem on the mailbox server). The re-exploitation across three waves indicates either incomplete cumulative-update application (Microsoft's HealthChecker.ps1 is the canonical verification harness) or a persistence foothold — likely a web shell or scheduled task — that survived clean-up rounds and re-armed the same vulnerable code path.

Exploitation chain mapped to ATT&CK. Each wave deployed distinct payload combinations on top of the same initial-access foothold:

• T1190 Exploit Public-Facing Application — ProxyNotShell against Exchange (each wave).
• T1505.003 Server Software Component: Web Shell — surviving persistence from an earlier wave is the most plausible explanation for re-exploitation across remediation attempts.
• T1059.001 Command and Scripting Interpreter: PowerShell — Exchange PowerShell remoting deserialisation gadget yields PowerShell execution; subsequent reconnaissance and tooling drop.
• Wave 1: Deed RAT (Snappybee) deployed via DLL sideloading against a signed LogMeIn Hamachi binary — Deed RAT is the ShadowPad successor lineage (encrypted C2, file I/O, command execution, process injection). The sideloading is the technique-novelty highlight: per Bitdefender the malicious DLL overrides two of Hamachi's exported functions (Init, ComMain) and patches StartServiceCtrlDispatcherW, so the payload only executes when Hamachi's own service-start path runs. T1574.002 Hijack Execution Flow: DLL Side-Loading is the ATT&CK umbrella, but the override-and-patch detail is what defeats sandbox harnesses: stub harnesses that call DllMain or a small set of obvious exports never trigger Init / ComMain in the right order and the payload stays dormant.
• Wave 2: TernDoor deployed via DLL sideloading against a renamed-but-legitimate deskband_injector64.exe — Bitdefender records the second wave as introducing TernDoor as a second backdoor family. The sideloading host is deskband_injector64.exe renamed USOShared.exe and placed in C:\ProgramData\USOShared\; the malicious loader is winmm.dll in the same directory. (No legitimate Microsoft "USOShared" signed binary is involved — the directory name is reused for camouflage.)
• Wave 3: Modified Deed RAT with updated C2 infrastructure — Bitdefender's third wave is an evolution of Wave 1's implant (refreshed C2, no novel sideloading host), confirming the operator's preference for iterating on the Deed RAT line rather than abandoning it.
• T1078 Valid Accounts + T1021.001 RDP / T1021.002 SMB — lateral movement via Impacket, RDP, SMB tooling once the Exchange-server foothold is established.

Named clusters and shared tooling. Bitdefender's overlap assessment places FamousSparrow / UAT-9244 in operational relationship with Earth Estries (Trend Micro taxonomy); The Hacker News summary additionally connects the cluster to Salt Typhoon (Microsoft taxonomy). Implants observed include Deed RAT (Snappybee), TernDoor, Mofu Loader and ShadowPad ancestry; the LogMeIn Hamachi sideloading host is freshly observed for this cluster and indicates active tooling rotation rather than reuse of a known signed-binary host.

Detection and hunt concepts. Defender-actionable, behavioural — not IOCs:

• Exchange patch-verification audit: Run Microsoft's HealthChecker.ps1 against every on-premise Exchange server and review the output for Exchange Build and Hotfix Applied lines. CU-level patch status alone is insufficient — the cumulative-update installer occasionally rolls back fixes if an OWA front-end customisation conflicts. Cross-reference IIS log analysis for repeated POST requests to /autodiscover/autodiscover.json with non-empty bodies, especially when the same external IP returns over a span of days — the ProxyNotShell exploitation pattern leaves this footprint.
• Web-shell survival sweep: Audit the Exchange FrontEnd\HttpProxy\owa\auth\ and FrontEnd\HttpProxy\ecp\auth\ directories for files modified post-patch, and the Exchange transport-agents folder for unsigned scheduled tasks. Persistence outliving clean-up was the structural enabler of re-exploitation in this case.
• LogMeIn Hamachi / signed-binary sideload anomalies: Hunt for hamachi*.exe or logmein*.exe loading DLLs from non-standard installation paths, or any legitimately signed binary whose child process tree spawns cmd.exe / powershell.exe with encoded arguments. The export-override gating makes the loader resilient against generic sandbox detection, but the eventual payload still spawns shell children — Sysmon event ID 1 with ParentImage filter on known signed binaries and CommandLine patterns for -EncodedCommand / -enc remains effective. Wave 2's sideloading is the same class of abuse using a renamed legitimate binary — extend the hunt to deskband_injector64.exe running from non-standard paths (Bitdefender placed it as C:\ProgramData\USOShared\USOShared.exe) and to any winmm.dll load from a ProgramData subdirectory rather than from the system search path.
• DLL load-order anomaly hunt: T1574.002 sideloading depends on a writable DLL search path adjacent to the host binary. Hunt Sysmon event ID 7 (Image Load) records for the Hamachi process loading DLLs from %LOCALAPPDATA%\Temp\ or other writable user-context paths rather than from the legitimate Program Files\LogMeIn Hamachi\ install directory.
• Lateral-movement signatures: alert on Impacket execution patterns (smbexec.py / wmiexec.py) — process command lines containing \\127.0.0.1\admin$ and Win32 service installations with randomly-named binaries (__output style) on member servers. RDP from Exchange servers to non-administrative workstations is anomalous regardless of source-account legitimacy.

Hardening / mitigation. Concrete configuration toggles, not advice:

• Exchange: Apply the latest cumulative update and verify with HealthChecker.ps1; deploy Microsoft's mitigation script for ProxyNotShell-class URL rewriting if running an Exchange version still affected. Consider the broader move to Exchange Online for organisations that have not migrated — on-premises Exchange remains a top initial-access vector across China-nexus campaigns.
• Application-allow-listing: Enforce Windows Defender Application Control (WDAC) or AppLocker policies that disallow LOLBin-style execution of logmein*.exe / hamachi*.exe from %TEMP% / %LOCALAPPDATA% paths. Even legitimately signed binaries should not run from user-writable directories.
• EDR / Microsoft Defender for Endpoint: enable "Block executable content from email client and webmail" and "Block all Office applications from creating child processes" ASR rules; these do not directly catch the Hamachi sideload but harden adjacent ingress paths.
• Conditional Access: Require modern-authentication and device-compliance for OWA / EAS / Outlook desktop where Exchange Online or hybrid mailboxes are in use; legacy authentication on hybrid setups continues to expose ProxyNotShell-adjacent paths.

Operationally critical context for Swiss / EU public-sector SOCs. Per Bitdefender, Azerbaijani gas exports now reach 13 European countries including Germany and Austria — so energy-sector intelligence collection against an Azerbaijani operator is structurally collection against the upstream end of European energy supply. The ProxyNotShell-re-exploitation pattern documented here is not Azerbaijan-specific — any organisation in CH / EU with an on-premise Exchange server that received CU patches but lacks HealthChecker.ps1-level verification carries the same exposure. The Wave-3 export-gated sideloading technique generalises to any legitimate signed binary an operator chooses to abuse; defenders should treat it as a class problem (DLL sideloading from signed hosts) rather than a Hamachi-specific signature.