LONDON (IT BOLTWISE) – Eine neue Beobachtung zur Chaos-Ransomware zeigt, dass das eigentliche Kommando-und-Kontroll-System nicht über typische Netzwerk-Endpoints läuft, sondern über den kompromittierten Browser des Opfers. Das Rust-basierte Implant msaRAT startet Chrome oder Edge im headless Modus und spricht darüber das Chrome DevTools Protocol an. Für den Datenkanal nutzt es WebRTC, wobei die Weiterleitung über eine TURN-Infrastruktur erfolgt, die auf Cloudflare-Worker-Sequenzen und Twilio-Relay basiert. Für Verteidiger wird damit weniger der Patch für eine Browser-Schwachstelle relevant, sondern vor allem die Erkennung von ungewöhnlichen Headless-CDP-Verhalten im System.
Im Umfeld von Ransomware ist das Muster meist klar: Ein Erstzugriff führt zu Post-Exploitation, anschließend meldet sich die Schadsoftware mit klassischen HTTP(S)-Requests oder per fest verdrahteten Protokollen. Bei der Chaos-Ransomware setzt das Kommando-und-Kontroll-(C2)-Verhalten jedoch an anderer Stelle an: Das Implant msaRAT leitet Befehle über den bereits vorhandenen Browser des Opfers aus, und zwar so, dass die externen Verbindungen im Verkehr nicht wie „eigene“ Malware-Kommunikation aussehen. Der zentrale Punkt der Analyse ist dabei technisch unspektakulär und operativ wirkungsvoll zugleich: Das Implant eröffnet keine eigene Outbound-Verbindung. Stattdessen steuert es Chrome oder Edge lokal per Loopback, startet den Browser headless und nutzt dessen Debugging-API, um alle relevanten Daten nach außen über einen WebRTC-Datenkanal zu transportieren.
Der Ablauf beginnt mit der Browser-Erkennung: msaRAT sucht zunächst über Umgebungsvariablen nach Chrome oder Edge und wechselt erst danach in eine Registry-Abfrage, falls die Variablen keinen passenden Pfad ergeben. Wird kein kompatibler Browser gefunden, wird der CDP-basierte Weg übersprungen. Wenn ein Browser vorhanden ist, startet das Implant Chrome oder Edge ohne sichtbares Fenster mit dem Flag –headless=new. Anschließend aktiviert es das Debugging-Interface über –remote-debugging-port, und es verwendet einen separaten –user-data-dir-Ordner. Besonders relevant für die Verteidigung ist: Laut der Auswertung zeigt msaRAT keine Hinweise darauf, Profil- oder Cookie-Daten aus dem üblichen Nutzerprofil anzufassen. Damit verändert sich das Risiko weniger in Richtung „Browser-Patching“, sondern mehr in Richtung „Prozessverhalten und Telemetrie“.
Die eigentliche C2-Komponente versteckt sich im Zusammenspiel aus Chrome DevTools Protocol (CDP) und WebRTC-Signalisierung. msaRAT fordert über CDP einen debuggbaren Target an und verbindet sich mit der zurückgelieferten WebSocket-URL. Danach öffnet es eine Tab-Instanz, deaktiviert per Page.setBypassCSP eine Content Security Policy und registriert mehrere Callbacks über Runtime.addBinding. In der JavaScript-Injektion, die über Runtime.evaluate aus einem Klartext-Blob im Binärformat (.rdata) eingespeist wird, werden die Transportlogik und die Callback-Namen festgelegt; vier davon (msaOpen, msaClose, msaError, msaMessage) dienten der Auswertung als Namensanker, ergänzt um dataAck für die Bestätigung von Datenpaketen. Diese JavaScript-Komponente lädt STUN- und TURN-Konfiguration von einem Cloudflare Worker-Endpunkt; die Requests sind dabei mit manipulierten Origin- und Referer-Headern getarnt, sodass sie wie legitimer Microsoft-zugehörige Navigation wirken sollen.
Technisch baut das Skript daraus eine WebRTC-Peer-Connection und übermittelt über denselben Signalisierungsendpunkt ein SDP-Offer. Auffällig ist dabei ein Detail, das die Angriffsfläche reduziert und gleichzeitig die Kontrolle erhöht: Die Antwort enthält keine ICE-Kandidaten und setzt die Verbindungsadresse auf 0.0.0.0. Dadurch kann keine direkte Peer-to-Peer-Verbindung entstehen; der komplette Datenkanal läuft über die TURN-Infrastruktur, in diesem Fall über Twilios Relay-Umgebung (global.turn.twilio.com). Der weitere Ablauf „entkoppelt“ die Signalisierung vom Datenpfad: Sobald der Data Channel aktiv ist, fällt der Worker aus dem Pfad. Der Datenkanal ist dabei doppelt verschlüsselt, erst auf WebRTC-Ebene über DTLS, und zusätzlich mit einem ChaCha-Poly1305-basierten Schema, das mit einem ECDH-Schlüsselaustausch startet. Direkt nach dem Verbindungsaufbau soll ein kurzer 0xFE-Handshakeframe vom C2 eintreffen; erst danach werden die verschlüsselten Kommando-Frames übertragen.
Das Implant übergibt empfangene Befehle an cmd.exe im Muster „/e: ON /v: OFF /d /c“. Für die Abwehr heißt das: Selbst wenn der Netzverkehr wie Browser-Traffic wirkt, bleibt auf Host-Ebene ein charakteristisches Zusammenspiel aus Installer-/Service-Prozess, headless Browser und lokaler Debug-Port-Kommunikation zurück. Die Analyse deutet zudem darauf hin, dass die Flow-Control und die Send-Queue so konstruiert sind, dass größere Payloads stabil transportiert werden können, etwa Screenshots oder Dateien. Die Historie der verwendeten Bausteine ist dabei nicht wirklich neu: In früheren Beobachtungen wurde gezeigt, dass TURN-Infrastrukturen aus WebRTC-Umgebungen auch zur Übertragung eines kompletten C2-Streams geeignet sind; ebenso wurde in einem anderen Fall die Idee dokumentiert, WebRTC Data Channels für das Umgehen klassischer HTTP-Inspektion zu missbrauchen. msaRAT kombiniert diese Teile nicht als „neues Transportprotokoll“, sondern als Umgehungsstrategie: Ein Chaos-verbundener Rust-Implantationscode treibt einen headless Browser über CDP an und „verlagert“ damit das Offsite-Kommunikationsprofil in Richtung legitimer Browser-Interaktionen.
Der Weg ins System wirkt weniger spektakulär als das spätere C2-Design. Laut der Auswertung kommt das Implant nach bereits vorhandener Kompromittierung; es wird vor dem eigentlichen Encryptor-Teil geliefert. Wie die Maschine genau erreicht wird, bleibt in der Beschreibung offen. Das Playbook der Gruppe umfasst verschiedene Formen von anfänglicher Zugangserzeugung und Persistence, und beim eigentlichen Drop beschreibt die Analyse eine Installation, die per curl.exe eine MSI-Datei von einem angegebenen IP-Ziel lädt und unter C: \programdata\update_ms.msi ablegt. Entscheidend ist hier das Detail, dass der Zugriff über Port 443 erfolgt, aber mit „plain HTTP“ statt TLS; wenn Firewallregeln nur portbasiert ohne Protokollerkennung greifen, kann das die Zustellung erleichtern. Die MSI imitiert dabei Eigenschaften einer Windows-Update-Quelle, und über eine Custom Action wird am Ende der Installation ein eingebettetes DLL-Segment direkt in den Speicher geladen, ohne dass ein klassischer separater Drop im Dateisystem zwingend sein muss. Die DLL stellt dann das Rust-Implant bereit, das über eine exportierte Funktion für den Installer startet.
Für die Detektion ergibt sich daraus eine klarere Handlungslogik als bei einer reinen Browser-Schwachstellen-Kampagne. Da msaRAT als Post-Compromise-Schadcode beschrieben wird und keine spezifische Chrome- oder Edge-Schwachstelle voraussetzt, lässt sich das Problem nicht mit „Browser aktualisieren“ eindämmen. Es bleibt vor allem prozess- und telemetriegetrieben: Abfragen Sie in Windows-Fleets nach Chrome/Edge-Instanzen, die durch einen Installer, ein Service-Objekt oder eine nicht-interaktive Parent-Process-Konstellation gestartet wurden, und achten Sie auf Parameter wie –headless=new sowie –remote-debugging-port. Ergänzend lässt sich die Kette über loopback-Verbindungen zum Debug-Port und über ausgehende WebRTC-Signalisierungsmuster korrelieren; in Umgebungen mit CDP-Logs sind insbesondere Runtime.addBinding und Runtime.evaluate sinnvolle Schwerpunkte. Zwar liefern die veröffentlichte Analyse- und IOC-Sammlung nutzbare Netzwerkindikatoren (unter anderem ein Staging-IP sowie ein Worker-Hostname), aber die Wirksamkeit ist begrenzt, weil gerade Worker-Domains und Relay-Ziele kontextabhängig austauschbar sind und ein Blocking gegen WebRTC-Relay-Services schnell Kollateralschäden für legitime Real-Time-Anwendungen erzeugen würde. Genau deshalb sollte das Vorgehen „Tradecraft-basiert“ bleiben: nicht pauschal WebRTC kaputtmachen, sondern die Kombination aus headless Browser, CDP-Steuerung und charakteristischem Transportverhalten auf Host- und Netzwerkebene zusammenführen.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- NIEDLICHER BEGLEITER: Eilik ist der ideale Begleiter für Kinder und Erwachsene, die Haustiere, Spiele und intelligente Roboter lieben. Mit vielen Emotionen, Bewegungen und interaktiven Funktionen.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!
- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "Chaos-Ransomware nutzt msaRAT: C2 läuft über Headless Chrome/Edge und WebRTC-Tunnel" für unsere Leser?
#Sophos
#AmazonPrime
#Bestseller
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "Chaos-Ransomware nutzt msaRAT: C2 läuft über Headless Chrome/Edge und WebRTC-Tunnel" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »Chaos-Ransomware nutzt msaRAT: C2 läuft über Headless Chrome/Edge und WebRTC-Tunnel« bei Google Deutschland suchen, bei Bing oder Google News!