msaRAT: Chaos ransomware hides its C2 in the browser

Cisco Talos has detailed a new remote access trojan (RAT) called msaRAT, attributed to the Chaos ransomware group. What is interesting is not that another RAT exists, but how it communicates: msaRAT never connects to its command server directly — it runs the entire command-and-control (C2) channel through a legitimate browser process. It is a practical example of the “living off the browser” technique.

We stick to the technical description published by the researchers — no speculation about victim counts or specific targets, which were not disclosed.

How “living off the browser” works

msaRAT is written in Rust (using the asynchronous Tokio runtime) and launches its own instance of Chrome or Edge on the victim machine, driving it through the Chrome DevTools Protocol (CDP) — the debugging interface built into both browsers. The browser then carries the C2 traffic over a WebRTC channel.

According to Talos, outbound traffic leaves from the legitimate browser process and looks like ordinary activity: HTTPS to a Cloudflare developer domain, a STUN request to a Google server, then WebRTC to a Twilio relay. To network-detection systems this resembles normal browser usage, not malware communication.

Why this is a problem for defenders

Many detection rules assume malware connects to a suspicious address using its own process. Here that signal is absent: the connection is initiated by a trusted browser process, and the traffic goes to popular, legitimate services. The classic indicators — an unusual process reaching an unknown IP, a standalone C2 beacon — simply do not appear.

That does not make the attack undetectable. It means detection must shift from the network to the host: who launches the browser in remote-debugging mode (flags like --remote-debugging-port) and why, where a headless Chrome instance comes from without user interaction, and what child processes it spawns. This is the case for mature security monitoring built on EDR telemetry, not just the firewall.

Context: this is a ransomware group’s tool

msaRAT is not a standalone threat in a vacuum — Talos ties it to Chaos ransomware operations. The RAT is used to maintain access and control, and its covert C2 makes detection harder in the stage before encryption. Effective ransomware defence is therefore the same chain as ever: limit the entry, detect the intermediate activity, keep working backups. We laid out the fundamentals in ransomware: how to defend.

What to do

1. Monitor unusual browser launches. Watch for Chrome/Edge started with remote-debugging flags and for headless instances without a user session. That is a signal worth an EDR alert.
2. Restrict remote debugging. Where possible, block or control the use of --remote-debugging-port via policy on workstations and servers.
3. Do not rely on network detection alone. Since the traffic flows through a trusted process to legitimate services, you need host–process–network correlation, not just connection analysis.
4. Keep offline backups. Against ransomware groups, recoverability is the last line of defence — stick to the 3-2-1 model with an isolated copy.
5. Rehearse incident response. Detecting the RAT is the beginning, not the end. A prepared procedure shortens the time between the alert and cutting off access.

The bottom line

msaRAT shows where C2 concealment is heading: instead of masking their own traffic, attackers borrow the credibility of a trusted process. The answer is not a single rule but shifting visibility onto the host and its processes. If you want to check whether your monitoring would catch such a channel, let’s talk about detection testing.

Sources: Cisco Talos, The Hacker News, BleepingComputer, Help Net Security.