Cavern: il framework .NET che sfida gli analisti con tre…

Check Point Research ha svelato Cavern, un framework C2 modulare in .NET usato dall'attore iraniano Cavern Manticore. Tre formati di compilazione come arma anti-analisi.

Il 6 luglio 2026 Check Point Research ha pubblicato l'analisi tecnica di "Cavern", un framework di comando e controllo modulare interamente costruito su .NET e impiegato dall'attore minaccia "Cavern Manticore" contro obiettivi israeliani nei settori governativo e IT. La peculiarità del framework non risiede nell'offuscamento tradizionale, bensì in una scelta architetturale deliberata: i moduli vengono compilati in tre formati binari distinti, costringendo chi analizza il campione a switchare strumenti e metodologie per ogni componente.

Punti chiave

Cavern Manticore è un attore Iran-MOIS-linked con sovrapposizioni tecniche documentate con MuddyWater e Lyceum, quest'ultimo identificato da ESET come subgroup di OilRig (APT34) con focus esclusivamente israeliano.
Il framework "Cavern" adotta tre formati di compilazione .NET come layer anti-analisi primario: IL-only, Mixed-Mode C++/CLI e NativeAOT, ciascuno con toolchain di reverse engineering dedicata.
La catena di esecuzione inizia con l'abuso della feature di aggiornamento software SysAid, prosegue con DLL sideloading tramite WinDirStat.exe legittimo e una uxtheme.dll trojanizzata con 82 funzioni stub e una sola funzionale.
I moduli specializzati coprono post-exploitation su file system, database SQL, LDAP, rete e tunneling SOCKS5/WebSocket, con AppDomain isolation come misura anti-forensics.

Il .NET come piattaforma d'attacco, non solo d'impresa

La scelta di .NET come fondamento del framework non è casuale. Secondo Check Point Research, la stessa piattaforma che semplifica lo sviluppo enterprise viene sfruttata per costruire malware che elude la detection tradizionale. La maggior parte dei campioni analizzati ottiene zero o detection rate molto bassa su VirusTotal. Il meccanismo non si basa su tecniche di offuscamento convenzionali, ma sulla diversificazione dei formati binari: IL-only (decompilabile trivialmente), Mixed-Mode C++/CLI (che richiede di analizzare sia il codice gestito che quello nativo), e NativeAOT (compilazione ahead-of-time che produce binari nativi senza metadata .NET).

Questa tripartizione costringe l'analista a operare con toolchain differenti per ciascun modulo. Nel caso del Mixed-Mode C++/CLI, come osserva CPR, "the analyst has to reverse the same binary twice in two different toolchains". Il NativeAOT rappresenta il caso più ostico: il 60% delle funzioni viene matchato tramite FLIRT signatures, ma il restante 40% richiede analisi manuale estesa. I moduli NativeAOT risolvono le API sensibili tramite P/Invoke gestiti da runtime descriptor tables, nascondendo le importazioni dalla tabella visibile in static analysis.

Come funziona la catena di esecuzione

L'infezione inizia con l'abuso della funzione di aggiornamento software di SysAid. Da lì, l'esecutore legittimo WinDirStat.exe carica una uxtheme.dll compromessa, un classico schema di DLL sideloading. La DLL malevola esporta 83 funzioni che mimano la libreria theming di Windows: 82 sono stub vuoti, la funzione effettiva è EnableThemeDialogTexture (ordinale #20), che attiva il payload del backdoor.

Il modulo "Cavern Agent" (uxtheme.dll, formato Mixed-Mode C++/CLI) si connette al modulo di comunicazione "n-HTCommp.dll" (NativeAOT). Da questo punto, l'operatore può caricare dinamicamente i moduli specializzati: "mhm.dll" per il file system, "db.dll" per l'interazione con database SQL, "ode.dll" per le query LDAP, "n-ten.dll" per le operazioni di rete, e "n-sws.dll" per il tunneling via SOCKS5 e WebSocket. Il framework condivide 61 command IDs nel tipo Command.Type enum tra i moduli IL-only, garantendo interoperabilità.

Il contesto degli attori: da OilRig a Cavern Manticore

Check Point Research esplicita il collegamento di Cavern Manticore con il MOIS (Ministry of Intelligence and Security) iraniano e le sovrapposizioni tecniche con MuddyWater e Lyceum. ESET, in un aggiornamento del 5 giugno 2025, ha ridefinito Lyceum come subgroup di OilRig (APT34), specificando che le attività descritte in precedenti report ricadono sotto questa etichetta. La ricostruzione di ESET documenta backdoor .NET storiche di Lyceum — Solar, Mango, DanBot, Shark, Milan — con targeting esclusivamente israeliano. Il brief non specifica se Cavern Manticore sia formalmente un ulteriore subgroup di OilRig o un attore distinto con cui Lyceum condivide tooling.

La convergenza tra le fonti è sul targeting geografico e settoriale (Israele, governo e IT) e sull'adozione sistematica di .NET per l'intero arsenale. La fonte non specifica se il framework Cavern sia usato esclusivamente da Cavern Manticore o condiviso con altri subgroups MOIS. Non emergono sovrapposizioni infrastrutturali che colleghino l'attore a campagne documentate anteriormente al 2026.

"the compilation format itself becomes the anti-analysis layer" — Check Point Research

Cosa fare adesso

Per le organizzazioni israeliane nei settori governo e IT, il primo passo è verificare la presenza di WinDirStat.exe in ambienti dove non è previsto: il sideloading di uxtheme.dll dipende dalla coesistenza di questo eseguibile con la DLL trojanizzata. I team di sicurezza devono controllare le firme dei file uxtheme.dll nelle directory di applicazioni di terze parti, non solo in System32 dove risiede la versione legittima.

Gli analisti di minacce devono aggiornare le toolchain per includere il supporto a NativeAOT e Mixed-Mode C++/CLI: il 60% di match con FLIRT signatures su NativeAOT significa che il 40% rimanente richiede analisi manuale con strumenti come Ghidra o IDA Pro configurati per il codice nativo puro. Le piattaforme di analisi automatica che si affidano esclusivamente a decompilatori .NET standard (dnSpy, ILSpy) falliranno su due dei tre formati usati da Cavern.

Per i provider di sicurezza gestita, la priorità è mappare l'uso di SysAid come vettore di aggiornamento software: il brief documenta l'abuso di questa feature specifica, non di una vulnerabilità del prodotto. Il controllo deve concentrarsi sui processi di aggiornamento che caricano eseguibili esterni al percorso di installazione previsto.

Le domande che restano aperte

Quanto è diffuso il framework al di fuori dei target israeliani?

Il brief non documenta campagne con Cavern contro obiettivi in altre regioni. Il targeting geografico rimane circoscritto a Israele nei fatti verificati disponibili.

I moduli NativeAOT sono effettivamente "più invisibili" o solo più laboriosi da analizzare?

Secondo CPR la maggior parte dei campioni ottiene zero o detection molto bassa su VirusTotal. La bassa detection si correla con la complessità analitica, non necessariamente con una maggiore sofisticazione nel runtime: il codice nativo precompilato sfugge alle euristiche .NET standard.

Esiste una difesa specifica contro il sideloading di WinDirStat?

Il dossier non menziona contromisure o patch specifiche per l'eseguibile legittimo abusato. L'assenza di CVE assegnati nel brief suggerisce che la vulnerabilità risiede nella configurazione del caricamento DLL piuttosto che in un difetto del software stesso.

Il framework Cavern dimostra che la modularità non riguarda solo la funzionalità malware, ma anche la distribuzione della complessità analitica: ogni modulo è un problema separato per chi deve investigare. Gli attori che dispongono di risorse per progettare il processo di build come arma anti-forensics alzano il costo della difesa non con nuovi zero-day, ma con l'inerzia degli strumenti esistenti.

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti