Cavern si nasconde tra DNS, Google Apps Script e calendari Microsoft 365
APT

Immagine illustrativa generata con AI

Cavern si nasconde tra DNS, Google Apps Script e calendari Microsoft 365

Scopri come il framework Cavern utilizza DNS, Google Apps Script e calendari Microsoft 365 per nascondere i canali C2 in attacchi iraniani.

Testo generato da intelligenza artificiale, pubblicato senza revisione umana. Trasparenza IA

Un framework iraniano amplia i propri canali C2

Kaspersky ha documentato nuovi componenti di Cavern, noto anche come Cav3rn, un framework modulare di comando e controllo collegato ad attori iraniani attivi contro organizzazioni in Israele.

La nuova analisi, rilevata il 17 agosto 2026, arriva dopo un monitoraggio iniziato a dicembre 2025. Check Point Research aveva reso pubblico Cavern all’inizio di luglio 2026, descrivendolo come un impianto composto da un Agent centrale e numerosi plugin per le attività successive alla compromissione.

Il framework è progettato per mantenere la persistenza, ridurre le tracce forensi e adattare le funzionalità alla singola operazione. I moduli possono occuparsi di file, database SQL, Active Directory, rete e tunneling.

L’attività è stata associata a Cavern Manticore, gruppo ritenuto vicino al Ministero iraniano dell’Intelligence e della Sicurezza. Sono emersi inoltre elementi di sovrapposizione con MuddyWater e con Lyceum, sottogruppo di OilRig.

GoogleService.dll sceglie dinamicamente il percorso delle comunicazioni

Il componente più significativo individuato da Kaspersky è GoogleService.dll. Il modulo legge il file locale conf.json e interroga il DNS tramite record A per decidere, transazione per transazione, quale canale di comunicazione utilizzare.

Le possibilità sono due:

  • una connessione HTTPS diretta verso l’indirizzo indicato nella configurazione;
  • un passaggio attraverso un deployment di Google Apps Script.

Quando viene selezionata la modalità basata su Google, il malware invia le richieste allo script. Quest’ultimo agisce da relay e inoltra il traffico al backend controllato dall’operatore. Nella modalità diretta, invece, il componente contatta senza intermediari l’indirizzo configurato.

La stessa infrastruttura DNS può comunicare un nuovo deployment ID per il relay Google. In questo modo l’attaccante può sostituire il canale Apps Script senza distribuire necessariamente una nuova versione della DLL già presente sul sistema.

La scelta dinamica complica il rilevamento. Un’organizzazione potrebbe bloccare un dominio o un indirizzo noto, ma il traffico successivo potrebbe passare da HTTPS verso un servizio legittimo utilizzato normalmente dagli utenti. Il dominio, da solo, diventa quindi un indicatore meno affidabile.

A completare l’architettura c’è rnp.dll, un broker locale che individua e carica le DLL disponibili, instrada i messaggi tra i componenti e permette di aggiornare i moduli mentre l’impianto è in esecuzione.

Questa struttura consente agli operatori di aggiungere capacità, cambiare il percorso del C2 e distribuire le funzioni senza sostituire l’intero framework.

Dal controllo dei sistemi al tunneling nella rete compromessa

Cavern dispone di plugin per operazioni sui file, enumerazione di database SQL e ricognizione di Active Directory. Include anche funzioni per la scoperta della rete, brute force LDAP e tunneling attraverso proxy SOCKS5 o WebSocket.

Il risultato è un impianto adatto a diverse fasi dell’intrusione. Dopo l’accesso iniziale, gli operatori possono raccogliere informazioni sull’ambiente, cercare account e sistemi di interesse, eseguire comandi e trasferire dati.

Il tunneling permette inoltre di utilizzare la rete compromessa come punto di transito. Il traffico dell’attaccante può così raggiungere altri sistemi o servizi passando da infrastrutture interne già considerate attendibili.

Secondo Kaspersky, il passaggio a un’architettura estensibile basata su plugin sarebbe avvenuto alla fine di aprile 2026. L’azienda collega Cavern a OilRig, noto anche come APT34, con bassa confidenza.

La valutazione si basa su analogie operative, non su una prova diretta. Non sono stati osservati riutilizzi del codice o sovrapposizioni infrastrutturali. Tra gli elementi considerati figurano l’uso di servizi Microsoft ospitati per il C2, meccanismi simili a quelli presenti in OilBooster per ottenere token OAuth refresh sostitutivi e l’impiego di infrastrutture compromesse appartenenti a organizzazioni nelle aree bersaglio.

Anche la storia del dominio studiotikva[.]com suggerisce continuità nello sviluppo. Il dominio era stato registrato per la prima volta a febbraio 2024, è scaduto a febbraio 2026 ed è stato registrato nuovamente tre mesi dopo.

HOLLOWGRAPH trasforma il calendario di Microsoft 365 in un C2

Un altro modulo collegato all’attività è HOLLOWGRAPH, progettato per usare Microsoft Graph API e i calendari Microsoft 365 come canale di comando e controllo.

Il meccanismo è bidirezionale. Gli operatori inseriscono istruzioni negli eventi del calendario presenti nella casella compromessa. Il malware legge questi contenuti e li interpreta come comandi.

Per l’esfiltrazione, l’impianto crea nuovi eventi contenenti dati sottratti e cifrati. I file vengono aggiunti come allegati agli eventi. Le attività sono collocate al 13 maggio 2050, una data distante che dovrebbe ridurre la possibilità che l’utente riconosca immediatamente gli appuntamenti come anomali.

HOLLOWGRAPH usa anche il tunneling DNS per aggiornare le credenziali Microsoft Entra ID, il nome attuale di Azure AD, necessarie per autenticarsi a Microsoft Graph. I nuovi valori vengono salvati in un file di testo sul disco.

La DLL è stata compilata con .NET NativeAOT ed è stata rilevata per la prima volta in natura il 7 giugno 2026. L’abuso di Microsoft Graph rende il traffico più difficile da distinguere dalle normali attività cloud, soprattutto nelle organizzazioni che utilizzano intensamente Outlook e Microsoft 365.

Per i difensori, la visibilità non può limitarsi ai domini risolti dal malware. Occorre correlare accessi a Graph API, creazione insolita di eventi, allegati cifrati e autenticazioni provenienti da host che normalmente non interagiscono con le caselle interessate.

APT42 colpisce con esche professionali e TAMECAT

La stessa attività di monitoraggio ha evidenziato una campagna distinta attribuita ad APT42. Il gruppo ha condotto attacchi di spear phishing contro persone collegate al settore dell’energia nucleare, con episodi rilevati ad aprile e maggio 2026.

I messaggi utilizzavano file LNK presentati come documenti PDF. Le esche facevano riferimento a inviti per podcast e interviste, una tecnica coerente con la costruzione di un rapporto professionale credibile prima della distribuzione del malware.

La catena porta all’installazione di TAMECAT, framework modulare di sorveglianza e raccolta. Le sue funzioni comprendono discovery, esecuzione arbitraria di comandi, furto di credenziali e cookie dei browser, acquisizione delle caselle Outlook in formato .ost e cattura di schermate.

Sono disponibili anche canali C2 ed esfiltrazione di riserva. Se il percorso principale non funziona o viene individuato, l’operatore può quindi tentare modalità alternative per mantenere il controllo e trasferire i dati.

APT42 è stato inoltre osservato nell’uso di strumenti di intelligenza artificiale generativa. L’AI sarebbe stata impiegata per accelerare lo sviluppo di tool, cercare tecniche di sfruttamento, tradurre contenuti, individuare indirizzi email ufficiali e analizzare organizzazioni d’interesse.

Cosa devono controllare le organizzazioni

Cavern e TAMECAT non sfruttano una vulnerabilità di prodotto descritta con CVE. Non sono quindi disponibili punteggi CVSS, classificazioni formali di gravità o patch dedicate.

Il rischio riguarda invece la compromissione degli endpoint e l’abuso di servizi legittimi. Le conseguenze possono includere accesso persistente, furto di file, credenziali, cookie e caselle email, ricognizione di directory e reti, esecuzione remota e uso dell’infrastruttura aziendale per il tunneling.

Le organizzazioni dovrebbero prestare attenzione a DLL sconosciute come GoogleService.dll, rnp.dll e HOLLOWGRAPH, al file conf.json, a file di testo contenenti credenziali Entra ID e a processi che effettuano richieste DNS anomale prima di collegarsi a servizi cloud.

Vanno inoltre analizzati:

  • deployment Google Apps Script non riconducibili a utenti o applicazioni aziendali;
  • eventi Microsoft 365 creati in massa o datati 13 maggio 2050;
  • allegati cifrati inseriti in eventi del calendario;
  • accessi insoliti alle API Microsoft Graph;
  • file LNK distribuiti come presunti PDF;
  • connessioni SOCKS5 o WebSocket originate da workstation;
  • richieste DNS con caratteristiche compatibili con un tunneling.

Non sono state indicate mitigazioni specifiche dal vendor. La difesa deve quindi combinare EDR, monitoraggio DNS, controllo delle applicazioni autorizzate, revisione dei log Microsoft 365 e analisi dei comportamenti anomali.

Kaspersky considera probabile un’ulteriore espansione di Cavern. La modularità, la capacità di aggiornarsi durante l’esecuzione e la disponibilità di più canali C2 indicano un framework ancora in sviluppo e utilizzato operativamente.

Leggi anche

Fonti

Questo articolo è una rielaborazione originale basata sulle fonti seguenti.

Argomenti correlatiCavernC2DNSGoogle Apps ScriptMicrosoft 365cybersecurity
Torna alla home