On 23 July 2026 Cisco Talos disclosed msaRAT, a new Rust-based remote access trojan used by the Chaos ransomware group. Instead of connecting to its command-and-control server directly, msaRAT hijacks a headless Chrome or Edge browser and routes traffic through a WebRTC channel relayed by Twilio, so the malware hides inside ordinary browser activity. Here is what defenders need to know and do.
The most effective place to hide ransomware command traffic may be the browser already installed on every machine.
On 23 July 2026 Cisco Talos disclosed a new Rust-based remote access trojan it calls msaRAT, attributed to the Chaos ransomware group. The name comes from function bindings inside the code: msaOpen, msaClose, msaError and msaMessage. What makes msaRAT unusual is how it talks to its operators. The implant never opens a network connection of its own. It locates Chrome or Edge on the victim machine, launches the browser in headless mode with remote debugging enabled, and drives it through the Chrome DevTools Protocol. The browser then carries the command-and-control traffic over a WebRTC channel, using a Cloudflare Workers domain for signalling and a Twilio relay for the live link, so the malicious traffic is buried inside normal web activity.
Your own browser can become the command channel
Cisco Talos found that the Chaos ransomware group hides its command-and-control traffic inside a normal Chrome or Edge process. The implant never connects out on its own; it drives a headless browser over a debugging interface and pushes traffic through legitimate services, so the malware blends into everyday web activity and slips past tools that watch for suspicious outbound connections.
What Cisco Talos reported
The findings, according to the Talos analysis published on 23 July 2026:
- msaRAT is a new Rust-based remote access trojan attributed to the Chaos ransomware group, written on the Tokio asynchronous runtime.
- It controls its command-and-control channel only through the Chrome DevTools Protocol, never connecting to the network directly.
- Signalling runs through a Cloudflare Workers domain; the live channel is a WebRTC DataChannel relayed by a Twilio TURN server.
- The traffic is double-encrypted, with the browser’s own DTLS layer on top of the malware’s ChaCha20-Poly1305 encryption.
The msaRAT technique in numbers
The details come from the Cisco Talos analysis published on 23 July 2026. Talos attributes msaRAT to the Chaos ransomware group and describes the implant as written in Rust on the Tokio asynchronous runtime, with browser-driven remote code execution and covert tunnelling as its core capabilities.
Why hiding inside the browser works so well
msaRAT never touches the network directly. It controls its command-and-control channel exclusively through the Chrome DevTools Protocol, a browser debugging API.
How the attack unfolds
The browser trick is only the final stage. The earlier steps are familiar, and match how a ransomware attack usually unfolds. Talos describes the following sequence, from initial access to a working covert channel.
The technique in four design details
Four design details inside msaRAT
Cisco Talos analysis of the Chaos ransomware implant, July 2026
What defenders should change
The table contrasts what most detection quietly assumes with what msaRAT actually does, and the practical takeaway a security team can act on for each.
| Detection assumption | What msaRAT does instead | Defensive takeaway |
|---|---|---|
| Malware opens its own network socket | The implant only talks to 127.0.0.1 and lets the browser carry all external traffic | Do not rely on process-to-network mapping alone; correlate parent and child process behaviour |
| C2 traffic reaches an attacker server | Signalling goes to a Cloudflare workers.dev domain, then media flows through a Twilio TURN relay | Anonymising relays hide the real endpoint; treat unexpected WebRTC from servers as suspicious |
| Browsers are launched by users | A browser is spawned headless with remote-debugging flags by an installer | Alert on browser processes started with headless and remote-debugging flags from non-user parents |
| Signature antivirus catches the dropper | The payload loads in memory from an MSI posing as a Windows update | Use behaviour-based EDR with tamper protection, not signatures alone |
What goes wrong if you treat this like a normal RAT
The whole design is built to defeat the assumptions network monitoring usually relies on. These are the failure modes it exposes.
- ⛔ Trusting that a quiet host with no odd outbound connections is clean, when the implant deliberately keeps its own traffic on 127.0.0.1.
- ⛔ Watching only for known C2 domains, when signalling hides inside Cloudflare’s developer platform and the media rides a Twilio relay.
- ⛔ Allowing WebRTC broadly on servers and workstations, when it is exactly the channel this malware abuses.
- ⛔ Relying on signature antivirus, when the payload loads in memory from an MSI dressed up as a Windows update.
- ⛔ Ignoring headless browser processes, when a browser launched with remote-debugging flags is the core of the technique.
This is an evasion upgrade, not a new ransomware family
Chaos is an established ransomware-as-a-service operation, active since early 2025, that uses double extortion. msaRAT does not change what the group encrypts or steals; it makes their command channel far harder to spot on the network. Teams that watch only for suspicious outbound connections from odd processes may miss it entirely, because the traffic leaves from a legitimate browser.
What to do this week
None of the following needs a new budget line. Each closes one of the specific gaps this technique exploits, from headless browsers to anonymised relays. For the full checklist, see our guide on preventing a ransomware attack.
- ✅ Alert when a browser process starts with headless and remote-debugging flags, especially if its parent is an installer or a script.
- ✅ Treat WebRTC traffic from servers and non-browsing workstations as an anomaly worth investigating.
- ✅ Move detection from signatures to behaviour: enable EDR with tamper protection so an in-memory payload is caught at execution.
- ✅ Watch the ProgramData folder for curl.exe and certutil.exe writing executables or MSI files.
- ✅ Deploy the Talos ClamAV signature and Snort rules, and load the published indicators of compromise into your tooling.
- ✅ Keep at least one backup copy immutable or offline, since Chaos steals and encrypts under double extortion.
Detection is possible if you watch the browser, not just the network
Talos published ClamAV and Snort coverage plus indicators of compromise. The most durable signals are behavioural: a browser started headless with remote-debugging flags by an installer, curl or certutil writing to ProgramData, and HeadlessChrome user-agent strings from a server. If you are already dealing with an incident, preserve the ransom note and one encrypted sample before reimaging: it is the starting point for recovering encrypted files.
Sources
- Cisco Talos, Chaos ransomware’s msaRAT: living off the browser to build a covert C2 channel
- The Hacker News, Chaos Ransomware Uses msaRAT to Route C2 Traffic Through Headless Chrome and Edge
- HelpRansomware, how a ransomware attack unfolds
- HelpRansomware, preventing a ransomware attack
- HelpRansomware, recovering encrypted files
Juan Ricardo Palacio
Co-Founder and CEO for the Americas, HelpRansomware
Juan Ricardo Palacio is an electronic engineer, entrepreneur, and specialist in telecommunications, cybersecurity, and digital forensics, with more than 25 years of professional experience. As Co-Founder of HelpRansomware, he works across cyber resilience, ransomware incident response, data recovery, cryptography, and reverse engineering, supporting companies and organizations through high-impact cyber incidents.
📰 Featured and quoted in Forbes Georgia, Business Insider Africa, LA Weekly, and Il Sole 24 Ore.
📅 Last updated: 24 July 2026
