Chaos Ransomware Group Employs 'Living Off the Browser' Technique with msaRAT
The **Chaos ransomware group** has been observed utilizing a novel command-and-control (C2) mechanism, dubbed **msaRAT**, that leverages a victim's own browser to establish covert communication channels. Detailed by **Cisco Talos**, this Rust-based implant operates by driving a headless browser instance, effectively masking its C2 traffic within legitimate browser activity.

Cybersecurity researchers at **Cisco Talos** have uncovered a sophisticated technique employed by the **Chaos ransomware group**, involving a Rust implant named **msaRAT**. This malware establishes a covert command-and-control (C2) channel by operating entirely within the victim's web browser, specifically **Google Chrome** or **Microsoft Edge**, without initiating any direct outbound connections of its own.
### Chrome Does the Talking
The **msaRAT** implant functions by launching a browser in headless mode and manipulating it via the **Chrome DevTools Protocol (CDP)**, the browser's debugging API. All C2 communications are then routed through a **WebRTC** data channel, relayed by **Twilio's TURN service**. This approach effectively conceals the attacker's server address, as network defenders observe only legitimate browser traffic directed towards **Cloudflare** and **Twilio**.
The malware prioritizes finding **Chrome** or **Edge** through environment variables, then falls back to the registry. If a suitable browser is found, it's launched using `--headless=new` and `--remote-debugging-port` flags, pointing to a dedicated user profile directory. This bypasses recent security enhancements in **Chrome 136** that prevent remote debugging against the default profile, a change implemented after infostealers began exploiting the feature for cookie theft.
Once connected via **CDP**, **msaRAT** creates a new browser tab, disables **Content Security Policy (CSP)**, and injects JavaScript code stored in its binary. This JavaScript fetches **STUN** and **TURN** configuration from a **Cloudflare Worker** and establishes a **WebRTC** peer connection. The C2 channel is then routed through **Twilio's** relay, ensuring no direct peer-to-peer link is formed.
Traffic on this channel is doubly encrypted: first by the browser's **DTLS**, and then by a **ChaCha-Poly1305** scheme, further obscuring communication. Incoming command frames are executed via `cmd.exe`, indicating the malware's capability to exfiltrate data like screenshots or files.
This technique isn't entirely new. Researchers at **Praetorian** demonstrated in August 2025 how conferencing platforms' **TURN** infrastructure could facilitate C2, and **Sansec** discovered a skimmer in March 2026 using **WebRTC** data channels to bypass HTTP inspection for data exfiltration. **msaRAT** combines these concepts within a **Chaos**-linked Rust implant.
### The Way In Is the Same as Ever
**msaRAT** is deployed post-compromise, preceding the ransomware encryptor. While the initial access vector for this specific incident is not detailed, the **Chaos group's** documented playbook includes spam campaigns, vishing, exploiting **Microsoft Quick Assist**, and utilizing **RMM tools** for persistence.
The implant is typically downloaded via a simple `curl` command over plain HTTP on port 443, often disguised as a Windows update within an MSI package. This MSI then loads an embedded DLL, which is **msaRAT** itself, written in Rust and exporting a `RUN` function for the installer to call.
### Hunting Notes for Defenders
Since **msaRAT** is a post-compromise tool and doesn't exploit a browser vulnerability, patching browsers won't mitigate the technique directly. Defenders should focus on process behavior. Look for instances of **Chrome** or **Edge** being launched by non-interactive parents (like installers or services) with the `--headless=new` and `--remote-debugging-port` flags enabled.
Correlate such browser processes with loopback traffic to the debugging port and outbound **WebRTC** connections. If telemetry captures **CDP** messages, `Runtime.addBinding` and `Runtime.evaluate` are key indicators. Organizations using browser automation or CI/CD pipelines will need to fine-tune their monitoring to differentiate legitimate headless browser activity from malicious use.
As of July 23, 2026, **Cisco Talos** has not published file hashes for **msaRAT**. Public indicators include the staging IP address and the **Cloudflare Worker** hostname, available in their [IOC repository](https://github.com/Cisco-Talos/IOCs/blob/main/2026/07/chaos-msarat.txt).
**Talos's** detection coverage includes:
* **ClamAV**: `Win.Downloader.ChaosRaas-10060321-0`
* **Snort 2**: `1:66839`, `1:66840`, `1:66841`
* **Snort 3**: `1:66839`, `1:301587`
It's crucial to note that `workers.dev` is a legitimate **Cloudflare** domain, and **Twilio** provides legitimate **STUN/TURN** services. Blocking these entirely could disrupt legitimate applications. This emphasizes the need to focus on the *technique* β a headless browser spawned by an installer β rather than solely on network indicators that can be easily changed by attackers. The **msaRAT** technique is particularly effective on Windows fleets where **Chrome** or **Edge** are commonly installed and allowed outbound network access.