Project CAV3RN usa Google Apps Script e DNS per nascondere il C2 contro Israele

🛡️ Executive Summary

• Project CAV3RN aggiunge GoogleService.dll, modulo .NET 8 NativeAOT che sceglie dinamicamente tra HTTPS diretto e Google Apps Script tramite risposte DNS.
• Il DNS non funge soltanto da segnale: può validare e ricostruire il deployment ID di Apps Script, permettendo agli operatori di sostituire rapidamente il relay.
• Kaspersky documenta anche un broker DLL aggiornabile a runtime e mantiene con bassa confidenza l’associazione di CAV3RN con OilRig, noto anche come APT34.

Project CAV3RN continua a evolvere e aggiunge una nuova architettura di comando e controllo progettata per confondersi con traffico legittimo verso Google. Dopo avere utilizzato eventi di calendario Outlook e Microsoft Graph come canale C2, il framework di cyberspionaggio osservato contro obiettivi in Israele introduce ora un modulo capace di scegliere dinamicamente, per ogni transazione, tra una connessione HTTPS diretta e un relay costruito attraverso Google Apps Script. A decidere quale percorso utilizzare sono risposte DNS controllate dagli operatori, che possono anche verificare e sostituire l’identificativo del deployment Google. La nuova analisi di Kaspersky mostra inoltre un broker locale capace di scoprire, caricare e aggiornare DLL senza riavviare il processo, consolidando CAV3RN come framework modulare pensato per operazioni di spionaggio persistenti.

CAV3RN passa da Outlook a Google Apps Script senza abbandonare il DNS

La nuova analisi tecnica pubblicata dal Global Research & Analysis Team di Kaspersky amplia una campagna monitorata almeno dal dicembre 2025 e già profondamente modificata durante il 2026. In una fase precedente CAV3RN aveva sostituito il proprio semplice schema downloader-executor-uploader con un controller e plugin separati, arrivando poi a utilizzare una DLL .NET NativeAOT che trasformava eventi del calendario Outlook datati 2050 in un dead-drop per comandi e risultati. Quella evoluzione era stata ricostruita anche attraverso HOLLOWGRAPH e l’abuso dei calendari Microsoft 365 come canale C2, dove Microsoft Graph consentiva al malware di comunicare attraverso infrastrutture normalmente autorizzate nelle reti aziendali. La variante individuata all’inizio di agosto non elimina questa filosofia ma cambia provider: il nuovo componente GoogleService.dll, compilato con Microsoft .NET 8 NativeAOT, può contattare direttamente un backend controllato dagli attaccanti oppure inviare le richieste attraverso Google Apps Script. È quindi il servizio cloud a cambiare, non la strategia di fondo: trasformare piattaforme legittime ad alta reputazione in intermediari tra vittima e infrastruttura C2.

GoogleService.dll utilizza il DNS come vero piano di controllo

La parte più sofisticata della nuova architettura è il ruolo del DNS, che non viene utilizzato semplicemente per risolvere un indirizzo IP. Prima di inviare un risultato o cercare nuovi comandi, GoogleService.dll effettua una query A verso un sottodominio generato dinamicamente di studiotikva.com. Nel nome vengono incorporati un nonce casuale, lo stato degli errori precedenti e l’identificatore del client convertito in esadecimale.

Il malware interpreta quindi l’ultimo ottetto dell’indirizzo IPv4 restituito come istruzione, decidendo se utilizzare Google Apps Script, il canale HTTPS diretto, chiudere la transazione oppure generare un’eccezione. Il meccanismo costruisce di fatto un control plane DNS separato dal data plane, permettendo all’operatore di modificare il percorso delle comunicazioni senza riconfigurare manualmente ogni impianto. L’approccio sviluppa ulteriormente la capacità di resilienza già vista nella prima versione CAV3RN, dove record AAAA trasportavano nuovi parametri Microsoft Entra ID se il canale Outlook non era più disponibile. Il DNS diventa così una componente operativa dell’orchestrazione e non un semplice fallback di rete.

Il deployment Google può essere ricostruito pezzo per pezzo via DNS

CAV3RN utilizza inoltre il DNS per verificare che il deployment ID di Google Apps Script memorizzato localmente sia ancora valido. Il malware calcola l’MD5 dell’identificatore conosciuto e confronta i primi quattro byte con quelli ricevuti attraverso una specifica query. Se i valori non coincidono, il framework avvia una procedura di recovery che ricostruisce un nuovo deployment ID attraverso più risposte DNS. Kaspersky ha osservato una sequenza composta da una risposta iniziale e 18 risposte successive, sufficienti a recuperare un identificatore Google Apps Script lungo 74 caratteri. Questa capacità rende molto più semplice la rotazione del relay: gli operatori possono sostituire il deployment Google compromesso, bloccato o rimosso e comunicare il nuovo valore agli impianti senza utilizzare il precedente C2. È un livello di resilienza significativo perché una difesa basata esclusivamente sull’identificatore Apps Script o sull’URL osservato rischia di diventare rapidamente obsoleta. La stessa tendenza a utilizzare servizi cloud come strati intercambiabili del C2 compare anche in altri malware, come Chaos e msaRAT, che trasformano browser, Cloudflare Workers e relay WebRTC in infrastruttura di comando.

Google Apps Script nasconde il backend dietro un servizio affidabile

Quando il DNS seleziona la modalità Google, il malware costruisce un URL nel formato script.google.com/macros/s/{deployment-ID}/exec e invia una richiesta POST contenente metodo richiesto, header, body e una chiave di autenticazione. A una normale visita HTTP il deployment può restituire una pagina innocua con il messaggio “This application is running normally”, mentre le richieste formattate correttamente vengono inoltrate verso il backend dell’operatore. Durante un timeout Kaspersky è riuscita a osservare l’endpoint upstream api.studiotikva.com/ac, dimostrando il ruolo di relay applicativo svolto da Google Apps Script. Dal punto di vista della rete, però, il computer compromesso comunica inizialmente con infrastruttura Google autentica. Bloccare indiscriminatamente script.google.com è irrealistico in molte organizzazioni e può generare un impatto operativo elevato. È lo stesso vantaggio ricercato dai malware che abusano di Microsoft Graph: la reputazione del provider cloud viene utilizzata come parte della tecnica di evasione e obbliga le difese a osservare modalità di utilizzo, processi sorgente, pattern delle richieste e contesto dell’identità invece del semplice dominio di destinazione.

Se Google fallisce CAV3RN passa direttamente a HTTPS

Il relay Google non rappresenta comunque un punto singolo di fallimento. In base allo stato trasmesso attraverso le query DNS, GoogleService.dll può contattare direttamente https://api.studiotikva.com/api/v1/update/check, inviando un header personalizzato X-Client-Id. Le richieste prive dell’identificativo previsto ricevono una risposta generica di fallimento, mentre i client validi possono ottenere pacchetti di tasking codificati in Base64 e protetti con una trasformazione XOR 0xAC. Il backend può quindi funzionare sia dietro Apps Script sia come normale server HTTPS. Questa doppia modalità permette agli operatori di scegliere il percorso più affidabile in funzione delle condizioni della rete compromessa o dello stato dell’infrastruttura. La progettazione modulare del trasporto richiama quanto già osservato nel framework Cavern Manticore impiegato contro organizzazioni governative e IT israeliane, dove controller, moduli post-exploitation e canali C2 sono separati per consentire aggiornamenti indipendenti e una maggiore resistenza alla rimozione di singoli componenti.

rnp.dll diventa il broker centrale dei moduli

La seconda novità importante riguarda rnp.dll, broker locale compilato in Microsoft Visual C++ e mascherato attraverso esportazioni che imitano la libreria OpenPGP RNP. Il componente scandisce la directory dell’host alla ricerca delle DLL appartenenti al framework e le raggruppa in base al campo CompanyName, caricando per ciascun gruppo la versione più recente che implementa le funzioni attese. La scansione viene ripetuta ogni secondo, permettendo di aggiungere un nuovo componente o distribuire un upgrade senza riavviare il processo principale. Il broker svolge inoltre il routing interno dei messaggi: il modulo C2 riceve un task, identifica la destinazione e lo inoltra alla DLL appropriata attraverso callback registrate. I comandi interni consentono di elencare componenti caricati, percorsi individuati e rispettive versioni. È un’architettura molto diversa da quella di una backdoor monolitica: l’operatore può modificare trasporto, ricognizione, esfiltrazione o funzionalità post-compromissione in modo indipendente, mantenendo inalterato il resto dell’impianto. Questo modello è diventato sempre più comune nelle operazioni di spionaggio avanzato, come mostra Mirage Kitten con NightLedger e tunnel WebSocket separati per accesso e movimento laterale.

Studio Tikva offre una copertura costruita per il contesto israeliano

L’infrastruttura osservata ruota attorno a studiotikva.com, dominio registrato originariamente nel febbraio 2024, in passato associato a una normale pagina Wix e a infrastruttura ospitata in un data center israeliano. Il dominio è scaduto nel febbraio 2026 ed è stato registrato nuovamente il 12 maggio, per essere poi delegato a nameserver controllati direttamente dall’operatore una settimana dopo. Kaspersky sottolinea che potrebbe essere appartenuto inizialmente a una vera attività israeliana e che non esistono elementi sufficienti per stabilire esattamente quando sia passato sotto il controllo dell’attaccante. Successivamente il dominio ha ospitato un sito generico “Studio Tikva”, nome plausibile localmente perché tikva significa “speranza” in ebraico. La costruzione di un’identità geograficamente coerente riduce l’anomalia visiva di un dominio eventualmente osservato da analisti o personale IT. Gli indirizzi del C2 e dei nameserver risultano invece ospitati presso RouterHosting negli Stati Uniti, mostrando ancora una volta come localizzazione del bersaglio, identità apparente del dominio e posizione fisica dell’infrastruttura possano essere completamente differenti.

Il collegamento con OilRig resta a bassa confidenza

L’attribuzione richiede particolare cautela. Nel precedente rapporto Kaspersky aveva associato Project CAV3RN a OilRig, conosciuto anche come APT34, con bassa confidenza, e la nuova analisi non modifica formalmente quel livello. Il collegamento deriva soprattutto da comportamenti già osservati nell’ecosistema OilRig: abuso di servizi Microsoft-hosted per il C2, uso di allegati o oggetti cloud per scambiare comandi, meccanismi secondari per recuperare nuove credenziali e impiego di infrastrutture compromesse nella regione bersaglio. La precedente variante utilizzava inoltre una mailbox Microsoft 365 appartenente a uno studio legale israeliano compromesso, comportamento compatibile con campagne storicamente associate al gruppo. Kaspersky precisa però di non avere trovato riuso diretto di codice né sovrapposizioni infrastrutturali definitive. Parlare quindi di “malware iraniano confermato” sarebbe più forte di quanto supportato dall’evidenza disponibile. La valutazione corretta è che CAV3RN opera contro obiettivi israeliani e presenta caratteristiche coerenti con precedenti tool OilRig, ma il legame resta probabilistico.

I servizi cloud legittimi diventano la vera superficie C2 da monitorare

Il passaggio da Outlook Calendar a Google Apps Script è probabilmente il dato strategico più importante dell’evoluzione di CAV3RN. Il framework dimostra di non essere legato a un provider specifico ma a un principio: utilizzare servizi cloud universalmente affidabili come livelli di trasporto sostituibili. Se Microsoft Graph viene bloccato o compromesso, il malware può recuperare nuovi parametri attraverso DNS; se il relay Google viene rimosso, il deployment ID può essere rigenerato e distribuito attraverso gli stessi record DNS; se Apps Script non funziona, esiste ancora il canale HTTPS diretto. Per i SOC questo significa che indicatori statici come domini, IP e hash rimangono utili ma hanno vita operativa limitata. Diventano più importanti la presenza di DLL NativeAOT inattese, query DNS con sottodomini ad alta entropia, accessi anomali a Apps Script da processi non browser, configurazioni conf.json sospette e traffico verso servizi cloud che non corrisponde al normale comportamento dell’endpoint. CAV3RN non inventa il cloud C2, ma ne mostra una versione sempre più resiliente: un framework nel quale Google, Microsoft, DNS e server propri possono diventare alternativamente parti dello stesso circuito di comando, rendendo la fiducia nelle piattaforme legittime uno strumento direttamente sfruttabile dall’attaccante.