Pierluigi Paganini
July 23, 2026
Cisco Talos disclosed msaRAT, a Rust-based remote access trojan attributed to the Chaos ransomware group that routes its entire command-and-control channel through the victim’s own Chrome or Edge browser.
The malware process itself never makes a network connection. Everything it sends and receives goes through the browser via Chrome DevTools Protocol, the same debugging interface developers use to inspect web pages.
“msaRAT never touches the network directly — it controls its C2 communication channel exclusively through Chrome DevTools Protocol CDP), a browser debugging API. The binary contains a Cloudflare Workers endpoint (“is-01-ast[.]ols-img-12[.]workers[.]dev”), but rather than making HTTP connections to this domain itself, it offloads that entirely to the browser.” reads the report published by Cisco Talos. “This endpoint is dedicated solely to signaling relay (SDP Offer/Answer exchange) for establishing a WebRTC connection; once the WebRTC connection is established, Cloudflare Workers drops out of the communication path entirely. All subsequent C2 commands are exchanged exclusively over the WebRTC DataChannel.”
What a network defender sees on the wire is a browser process making HTTPS requests to Cloudflare and WebRTC traffic to Twilio’s relay service, both legitimate, both commonly allowed. The attacker’s server address never appears in the traffic at all.
The infection starts unremarkably. After gaining access to a Windows machine, the attacker runs curl to download an MSI file named update_ms.msi from an attacker-controlled server on port 443, though the traffic runs over plain HTTP. Firewalls that filter by port number without inspecting the actual protocol let it through. The MSI impersonates a Windows update and loads the RAT DLL directly into memory via a custom installer action. From there, msaRAT looks for Chrome or Edge through environment variables in a defined priority order, then falls back to a registry lookup for Chrome if nothing is found. No browser means no C2 channel, the CDP manipulation simply doesn’t execute.
Once it finds a browser, msaRAT launches it in headless mode with remote debugging enabled, connects to it over the local debugging port, bypasses Content Security Policy using a CDP command, and injects JavaScript that handles all the actual network work.
“By intentionally omitting the ICE candidates that are normally present in standard WebRTC communications, P2P connections are prevented from being established, resulting in a design where all communications are always routed through TURN.” Talos continues. “By routing traffic through Twilio’s legitimate service, the real IP address of the attacker’s server never appears in the network traffic, and the dual-layer infrastructure combining Twilio with Cloudflare Workers makes it significantly difficult to trace the attacker’s infrastructure.”
Cloudflare Workers handles the SDP signaling to set up the WebRTC channel, then drops out of the picture entirely. All subsequent commands flow over the WebRTC DataChannel through Twilio’s relay.
The communication is double-encrypted. WebRTC DataChannel is already protected by DTLS, which the browser handles automatically. On top of that, msaRAT encrypts the payload itself using ChaCha-Poly1305 with a key derived through an ECDH handshake at connection time.
“Separately, msaRAT encrypts the data itself using a ChaCha-Poly1305-based encryption scheme before passing it to the browser, resulting in double-layer encryption. This design ensures that even if DTLS is stripped, an adversary-in-the-middle cannot read the contents.” reads the report. “The ChaCha-Poly1305-based encryption key is derived through an ECDH key exchange performed at the time the C2 connection is established.”
The RAT process itself is confined entirely to 127.0.0.1. All external traffic originates from the browser process, not the malware. Blocking the Cloudflare Workers domain used for signaling would disrupt legitimate Cloudflare deployments — a structural problem for defenders trying to take targeted action.
Talos found msaRAT deployed after initial access and before the ransomware encryptor ran, which fits Chaos’s established pattern of pre-encryption reconnaissance.
“As a result of this design, all network communication from the RAT process itself is limited to “127.0.0[.]1”, and all external communications are observed as originating from a legitimate browser process.” concludes the report. “Since browser-based WebRTC communication is commonplace even in enterprise environments, C2 traffic is effectively buried within normal web traffic from the perspective of firewalls and network monitoring tools.”
Detection signals to watch for: a browser process spawned with remote-debugging flags from an MSI installer, curl.exe or certutil.exe activity in C:\ProgramData, and HeadlessChrome user-agent strings in HTTP requests. Talos has published a ClamAV signature (Win.Downloader.ChaosRaas-10060321-0) and Snort rules, with full indicators available in their GitHub repository.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, newsletter)
