Chaos nasconde msaRAT nel browser e costruisce un canale C2 invisibile

🛡️ Executive Summary

• msaRAT è un trojan Rust attribuito al gruppo Chaos che usa Chrome o Edge come intermediari per ogni comunicazione esterna.
• Il malware controlla il browser tramite Chrome DevTools Protocol e costruisce un DataChannel WebRTC instradato attraverso Twilio TURN.
• Cloudflare Workers gestisce la negoziazione iniziale, mentre la doppia cifratura nasconde comandi, shell remota e trasferimenti di dati.

Il gruppo ransomware Chaos ha sviluppato un trojan di accesso remoto capace di trasformare Chrome o Microsoft Edge in un’infrastruttura di comando e controllo. Il malware, denominato msaRAT da Cisco Talos, non apre direttamente connessioni verso i server degli attaccanti. Avvia invece un browser in modalità headless, lo controlla attraverso il Chrome DevTools Protocol e gli affida la costruzione di un canale WebRTC cifrato. Cloudflare Workers viene utilizzato per la negoziazione iniziale, mentre il traffico operativo passa attraverso i relay TURN di Twilio. Il risultato è un C2 che appare generato da un normale browser e si confonde con comunicazioni web legittime, rendendo meno efficaci firewall, proxy ed EDR concentrati sul processo malevolo.

Chaos introduce un RAT Rust prima della cifratura

Chaos opera come gruppo ransomware-as-a-service almeno dal febbraio 2025 e associa la cifratura dei sistemi alla sottrazione dei dati, esercitando pressione sulle vittime attraverso la doppia estorsione. Le intrusioni attribuite al gruppo iniziano spesso con email di phishing, chiamate fraudolente e tecniche di vishing, seguite dall’abuso di strumenti legittimi di gestione remota e servizi di condivisione dei file. msaRAT viene eseguito nella fase precedente al ransomware, quando gli operatori devono consolidare l’accesso, impartire comandi e preparare l’ambiente per esfiltrazione e cifratura. Il payload viene scaricato attraverso curl.exe come pacchetto MSI denominato update_ms.msi nella directory ProgramData. L’installer imita un aggiornamento Windows e carica direttamente in memoria una DLL contenente il RAT attraverso una custom action, riducendo il numero di file evidenti depositati sul sistema. La richiesta utilizza la porta 443 ma trasporta traffico HTTP non cifrato, espediente capace di superare controlli configurati soltanto in base alla porta e non al protocollo effettivo. Il comportamento conferma la tendenza dei gruppi ransomware a combinare strumenti amministrativi, componenti firmati e tecniche living-off-the-land capaci di confondersi con le normali attività Windows.

Tokio permette al malware di gestire più operazioni insieme

La DLL di msaRAT è scritta in Rust e utilizza Tokio, runtime asincrono progettato per eseguire più attività concorrenti senza bloccare l’intero processo. Durante l’avvio, il malware determina il numero di core disponibili e crea una quantità corrispondente di worker thread, salvo configurazioni specificate attraverso la variabile TOKIO_WORKER_THREADS. Questa struttura permette al RAT di ricevere frame dal C2, inviare comandi al browser, processare eventi del Chrome DevTools Protocol ed eseguire lo scambio delle chiavi crittografiche simultaneamente. La concorrenza assume un valore particolare in un impianto nel quale il malware non possiede direttamente il socket esterno, ma deve coordinarsi costantemente con JavaScript, WebSocket locali e WebRTC.

Anche durante la negoziazione ECDH o il trasferimento di dati voluminosi, il processo può continuare a ricevere istruzioni e monitorare lo stato del browser. Rust non rende automaticamente il malware più sofisticato, ma offre prestazioni, gestione della memoria e portabilità utili per costruire impianti modulari. La scelta si inserisce nella crescita dei RAT e loader sviluppati con linguaggi moderni per eludere analisi e controlli tradizionali, con la differenza che msaRAT delega la parte più visibile della rete a un processo considerato normalmente affidabile.

Chrome ed Edge diventano il vero processo di rete

Dopo l’esecuzione, msaRAT cerca le installazioni di Google Chrome o Microsoft Edge attraverso variabili d’ambiente, percorsi standard e chiavi del registro. Se individua un browser compatibile, lo avvia in modalità headless con il debugging remoto abilitato. Il malware interroga quindi l’endpoint locale del browser per ottenere l’indirizzo WebSocket associato alla sessione DevTools, crea una nuova scheda e abilita i domini Page e Runtime. Attraverso il comando Page.setBypassCSP, disattiva per quella sessione le restrizioni della Content Security Policy e prepara l’ambiente all’iniezione di JavaScript. I comandi Runtime.addBinding registrano callback denominate msaOpen, msaClose, msaError, msaMessage e dataAck, utilizzate come ponte tra il codice eseguito nel browser e il RAT. Infine, Runtime.evaluate inserisce lo script che costruirà il canale di comunicazione.

Dal punto di vista del sistema operativo, il processo msaRAT comunica quasi esclusivamente con 127.0.0.1, mentre tutte le connessioni esterne risultano originate da Chrome o Edge. La tecnica supera il normale abuso delle credenziali del browser osservato in campagne come ShotBird e GhostClaw contro Chrome e gli ambienti di sviluppo: il browser non è soltanto il bersaglio o il contenitore di dati, ma diventa una componente attiva dell’infrastruttura criminale.

Cloudflare Workers nasconde la fase di segnalazione

Il codice JavaScript iniettato contatta un endpoint ospitato sul dominio workers.dev per ottenere la configurazione necessaria alla connessione WebRTC. Cloudflare Workers non trasporta per l’intera durata i comandi del RAT, ma gestisce la fase di signaling: distribuisce i parametri STUN e TURN, riceve l’SDP Offer prodotto dal browser e restituisce l’SDP Answer preparato dall’infrastruttura degli attaccanti. Il traffico proviene da un browser legittimo, utilizza indirizzi appartenenti alla rete Cloudflare e può presentare intestazioni Origin e Referer costruite per sembrare associate a domini Microsoft. Bloccare indiscriminatamente workers.dev provocherebbe disservizi a numerose applicazioni reali, rendendo poco praticabile una regola di negazione generale. Questa caratteristica permette agli operatori di nascondere l’infrastruttura di coordinamento dietro un servizio cloud ampiamente autorizzato nelle reti aziendali. Una volta completata la negoziazione, Cloudflare esce dal percorso operativo e il browser trasferisce direttamente i dati sul canale WebRTC. L’abuso dei servizi cloud come strato intermedio prosegue un modello ormai consolidato, nel quale gli attaccanti sfruttano reputazione, certificati e disponibilità di piattaforme legittime per evitare domini appena registrati o server facilmente sequestrabili.

WebRTC e Twilio occultano l’indirizzo del C2

Per costruire il collegamento, il browser crea una RTCPeerConnection e un WebRTC DataChannel con nome casuale. Un server STUN di Google consente di determinare l’indirizzo esterno del sistema infetto, mentre il servizio TURN di Twilio opera come relay quando non è possibile o non è desiderabile una connessione peer-to-peer diretta. La configurazione degli attaccanti omette deliberatamente i normali candidati ICE nell’SDP Answer e indica un indirizzo non utilizzabile, costringendo la comunicazione a passare sempre dal relay TURN. In questo modo, l’indirizzo IP reale del server C2 non appare nel traffico osservato dalla vittima. I sistemi di sicurezza vedono Chrome o Edge comunicare con infrastrutture Twilio attraverso WebRTC, un comportamento compatibile con videoconferenze, chiamate browser e applicazioni collaborative. Il malware si nasconde quindi non attraverso un protocollo sconosciuto, ma all’interno di una tecnologia necessaria a moltissimi servizi aziendali. La tecnica richiama il principio living-off-the-land applicato alla rete: invece di installare un proprio stack di comunicazione, msaRAT riutilizza browser, WebRTC, Cloudflare e Twilio. Il blocco basato esclusivamente sulla reputazione degli indirizzi diventa inefficace perché i nodi osservabili appartengono a fornitori legittimi e condivisi da utenti non compromessi.

Il canale dispone di cifratura su due livelli

WebRTC protegge normalmente i DataChannel attraverso DTLS, ma msaRAT aggiunge una seconda cifratura applicativa basata su ChaCha-Poly1305. Quando il C2 invia il frame iniziale di handshake, il malware riceve la chiave pubblica del server, genera una propria coppia di chiavi e utilizza ECDH per ricavare un segreto condiviso. Il RAT cifra quindi i dati prima di consegnarli al JavaScript, mentre il browser applica successivamente la protezione DTLS prevista dal protocollo. Anche un sistema capace di ispezionare o rimuovere il livello WebRTC non potrebbe leggere direttamente comandi e risultati. Per trasferire dati binari attraverso Runtime.evaluate, msaRAT converte i buffer in Base64 e li ricostruisce all’interno della pagina headless. Il codice implementa anche una coda e un sistema di flow control: quando il buffer del DataChannel supera una determinata soglia, l’invio viene rallentato fino a quando lo spazio torna disponibile. La presenza di questi meccanismi indica che l’infrastruttura è progettata per sostenere non soltanto brevi comandi di shell, ma anche screenshot, file e flussi più consistenti. Il RAT può quindi mantenere un canale affidabile e interattivo, pur delegando interamente il trasporto esterno al browser.

Il browser diventa una reverse shell indiretta

Una volta aperto il DataChannel, msaRAT entra in un ciclo di attesa sul WebSocket locale del Chrome DevTools Protocol. Gli eventi generati dal JavaScript vengono restituiti alla DLL attraverso le binding registrate, consentendo al malware di ricevere comandi, inviare risultati e reagire a errori o disconnessioni. Il browser svolge la funzione di proxy applicativo tra il C2 e il codice nativo: riceve i frame cifrati via WebRTC, li converte e li passa al RAT; il processo inverso trasporta verso l’esterno output e dati raccolti. Il canale può sostenere una reverse shell controllata da remoto, permettendo agli operatori Chaos di proseguire ricognizione, movimento laterale e preparazione del ransomware. L’architettura riduce gli indicatori di rete associati alla DLL e rende meno efficace la correlazione tra processo e destinazione esterna. Un EDR potrebbe osservare un installer che carica una libreria e avvia Chrome con parametri insoliti, ma un firewall vedrebbe soltanto connessioni del browser verso fornitori noti. La rilevazione richiede quindi l’unione di telemetria endpoint e rete, invece di trattare i due livelli separatamente.

Le difese devono controllare l’avvio anomalo dei browser

La tecnica non è invisibile e lascia numerosi segnali utili. Gli ambienti aziendali dovrebbero rilevare l’avvio di Chrome o Edge in modalità headless da parte di msiexec.exe, DLL sconosciute, processi residenti in ProgramData o strumenti come curl.exe. Anche l’apertura di porte locali per il debugging remoto, l’utilizzo di flag DevTools inattesi e le connessioni WebSocket verso endpoint su localhost possono indicare un abuso. Sul piano della rete, la combinazione tra un browser headless, richieste a sottodomini workers.dev, signaling WebRTC e traffico TURN prolungato merita una correlazione, soprattutto sui server o sulle postazioni che non utilizzano normalmente videoconferenze browser. Le intestazioni che fingono una provenienza Microsoft non devono sostituire la verifica del dominio reale e del contesto del processo. Segmentazione, application control e restrizioni sull’esecuzione di MSI scaricati possono interrompere la catena prima che il RAT venga caricato. Le organizzazioni devono inoltre evitare regole firewall basate esclusivamente sulla porta: una comunicazione HTTP in chiaro sulla 443 deve essere identificata per protocollo e non trattata automaticamente come HTTPS.

Living-off-the-browser estende il problema delle applicazioni fidate

msaRAT dimostra che il browser è diventato abbastanza potente da sostituire componenti tradizionalmente incorporati nel malware. Può eseguire JavaScript, aprire WebSocket, negoziare WebRTC, applicare cifratura, attraversare NAT e comunicare con servizi cloud globali. Le stesse capacità che rendono possibili applicazioni collaborative e comunicazioni in tempo reale possono essere orchestrate da un processo locale attraverso CDP. Il problema non riguarda quindi una vulnerabilità specifica di Chrome o Edge: il malware sfrutta funzioni di debugging e networking previste dal prodotto, dopo avere ottenuto l’esecuzione sul sistema. Disabilitare completamente CDP o WebRTC non è sempre praticabile, ma gli amministratori possono limitarne l’uso, controllare i parametri di avvio e impedire che processi non autorizzati lancino browser separati in modalità headless. Chaos sposta il command-and-control da un eseguibile sospetto a una catena di servizi legittimi, obbligando i difensori a riconoscere il comportamento complessivo invece di affidarsi alla reputazione del singolo processo, dominio o provider.