FamousSparrow spia l’Azerbaigian: il gruppo APT cinese colpisce l’industria petrolifera del corridoio energetico europeo

Bitdefender Labs ha documentato un’operazione di cyberspionaggio cinese di ampio respiro contro l’industria petrolifera e del gas dell’Azerbaigian, attribuita con confidenza medio-alta al gruppo FamousSparrow — noto anche come Earth Estries — un attore APT allineato con Pechino. L’operazione, durata oltre due mesi tra dicembre 2025 e febbraio 2026, assume una rilevanza geopolitica straordinaria: l’Azerbaigian è diventato un corridoio energetico strategico per l’Europa dopo la scadenza del contratto di transito del gas russo attraverso l’Ucraina e le perturbazioni nello Stretto di Hormuz del 2026.

Il contesto geopolitico: perché l’Azerbaigian è nel mirino cinese

Comprendere questa intrusione richiede un passo indietro sul panorama energetico europeo. A fine 2024, è scaduto il contratto di transito del gas naturale russo attraverso l’Ucraina, eliminando uno dei principali canali di approvvigionamento per l’Europa orientale. Nel primo trimestre del 2026, la sospensione delle spedizioni di GNL dal Qatar e le perturbazioni nello Stretto di Hormuz hanno ulteriormente ridotto le alternative disponibili. In questo scenario, l’Azerbaigian ha consolidato il proprio ruolo di partner energetico strategico, espandendo le forniture a 13 paesi europei — incluse nuove consegne a Germania e Austria — con un volume export cresciuto del 56% dal 2021.

Accesso iniziale: lo stesso server Exchange sfruttato tre volte

Il 25 dicembre 2025, il processo w3wp.exe (worker IIS di Microsoft Exchange) ha tentato di scrivere una web shell malevola in una directory pubblica del server. Il vettore era la catena exploit ProxyNotShell (CVE-2022-41040, CVE-2022-41082), documentata già dal 2022. Ulteriori tentativi di deploy di web shell sono stati registrati il 26 e 29 dicembre, con filename quali key.aspx, log.aspx, errorFE_.aspx e signout_.aspx.

Ciò che rende questa intrusione particolarmente significativa è la disciplina operativa: il medesimo server Exchange vulnerabile è stato ri-sfruttato per tre ondate distinte nell’arco di due mesi, nonostante i tentativi di remediation della vittima. Ogni volta che la difesa rimuoveva il malware, il gruppo tornava attraverso lo stesso punto di accesso, cambiando il backdoor ma preservando il canale.

Prima ondata: Deed RAT tramite la triade LogMeIn Hamachi

Dopo aver stabilito un foothold via web shell, gli attaccanti hanno distribuito il backdoor Deed RAT attraverso una catena DLL sideloading a tre componenti che sfrutta il legittimo software LogMeIn Hamachi:

• LMIGuardianSvc.exe — binario legittimo LogMeIn Hamachi (MD5: 0554f3b69d39d175dd110d765c11347a)
• LMIGuardianDll.dll — loader malevolo che patcha una Windows API e prepara il payload
• .hamachi.lng — payload Deed RAT cifrato con AES-128-CBC

Il meccanismo di evasione è raffinato: la DLL distribuisce la logica malevola su due export separati, Init e ComMain. La funzione Init patcha silenziosamente l’API Windows StartServiceCtrlDispatcherW in memoria, poi termina senza rivelare comportamenti sospetti. Il payload si attiva solo quando l’applicazione legittima raggiunge la chiamata patchata nel suo flusso naturale. Il risultato pratico: le sandbox di analisi automatica che eseguono la DLL in isolamento non osservano alcun comportamento malevolo — il malware rimane completamente inerte senza il contesto applicativo completo.

Seconda ondata: tentativo con Terndoor via Mofu Loader

Circa un mese dopo, FamousSparrow è tornato con un secondo backdoor: Terndoor, caricato attraverso il Mofu Loader. La catena sfruttava USOShared.exe (rinominato da deskband_injector64.exe) per sideloadare winmm.dll malevolo. Il tentativo è stato bloccato dalla soluzione di sicurezza, ma le tracce forensi hanno rivelato il tentativo di installare un driver kernel (vmflt.sys) per persistenza a livello rootkit — una tecnica documentata da Cisco Talos nel report UAT-9244.

Terza ondata: Deed RAT con C2 aggiornato

A fine febbraio 2026, gli attaccanti sono tornati per la terza volta con Deed RAT aggiornato. Le modifiche principali: magic DWORD aggiornato da 0xDEED4554 a 0xFF66ABCD, compressione plugin da Snappy a Deflate, nuovi target per l’injection (wininit.exe, dwm.exe), e nuovo C2: sentinelonepro[.]com:443. La scelta di un dominio che imita SentinelOne, un noto vendor di sicurezza, è emblematica della cura con cui FamousSparrow costruisce l’infrastruttura per eludere l’attenzione degli analisti.

Movimento laterale: RDP, Domain Admin e Impacket

Con persistenza stabilita sul primo host, gli attaccanti si sono spostati lateralmente via RDP verso un secondo server, autenticandosi con un account Domain Administrator — a indicare che le credenziali privilegiate erano già state compromesse. Da quel secondo host hanno poi usato utility in stile Impacket (atexec, smbexec) per propagarsi su un terzo sistema. La sequenza — accesso RDP, apertura console PowerShell, download del malware in pochi minuti — è la firma di un attore con un playbook collaudato.

Indicatori di compromissione

# Deed RAT - Prima ondata
MD5 LMIGuardianSvc.exe:  0554f3b69d39d175dd110d765c11347a
Path installazione:       C:\Program Files (x86)\LogMeIn Hamachi\
Magic header:             0xFF66ABCD (vecchio: 0xDEED4554)
C2 Prima variante:        HTTPS://virusblocker[.]it[.]com:443
C2 Terza variante:        HTTPS://sentinelonepro[.]com:443
# Web shell ProxyNotShell (Exchange)
File:  key.aspx, log.aspx, errorFE_.aspx, signout_.aspx
Path:  directory accessibili via web su Exchange server
# Terndoor - Seconda ondata
Loader:        C:\ProgramData\USOShared\USOShared.exe
DLL malevola:  C:\ProgramData\USOShared\winmm.dll
Driver kernel: C:\ProgramData\USOShared\vmflt.sys
Registry:      HKLM\SYSTEM\ControlSet001\Services\vmflt
# IOC completi: github.com/bitdefender/malware-ioc/
# File: 2026_05_13-famoussparrow-iocs.csv

Due righe per i difensori

• Patch immediata dei server Exchange esposti: ProxyShell e ProxyNotShell sono vulnerabilità note dal 2021-2022. Qualsiasi Exchange non patchato esposto a internet deve essere considerato compromesso
• Monitorare w3wp.exe: il processo IIS worker non dovrebbe mai scrivere file .aspx in directory pubblicamente accessibili nel contesto MSExchangePowerShellAppPool
• Rilevamento API hooking: monitorare modifiche ai primi byte di API Windows critiche (StartServiceCtrlDispatcherW, CreateProcessW) da parte di binari non firmati
• Alert RDP con credenziali DA: sessioni RDP da host interni con account Domain Administrator al di fuori delle finestre di manutenzione devono innescare alert immediati
• Rotazione credenziali post-compromissione: qualsiasi dichiarazione di remediation completata che non includa la rotazione delle credenziali Domain Admin è incompleta per definizione

La capacità di FamousSparrow di tornare sullo stesso accesso per tre ondate consecutive, adattando il toolset ma mantenendo il canale di ingresso, è la lezione operativa centrale di questa campagna: la remediation che rimuova il malware senza affrontare la vulnerabilità sottostante e ruotare le credenziali non è remediation — è una pausa.