msaRAT: How Chaos Ransomware Hides Its Command Channel Inside Your Own Browser

Your EDR agent sees Chrome. Your proxy logs see a TLS handshake to Cloudflare, then a WebRTC session relayed through Twilio. Every signal a defender normally trusts says ordinary browsing. What actually happened is a ransomware operator steering that browser through its own remote-debugging port, using it as a command channel that never touches attacker-owned infrastructure.

Cisco Talos published the mechanism on July 23 under the name msaRAT, a Rust implant deployed by the Chaos ransomware-as-a-service group. The full Talos writeup names the technique for what it is: living off the browser. BleepingComputer and The Hacker News both led their coverage with the same detail: the real command server's address never shows up in the traffic capture, because the traffic really is Chrome, doing what Chrome does.

Who needs to read past this paragraph

msaRAT carries no CVE and needs no patch. Read on if you run Windows endpoints anywhere near email or a phone line, because that is how Chaos gets in - phishing, vishing, and remote-monitoring-tool abuse for persistence, the same entry the group has run since it surfaced in February 2025. You can stop here if your fleet has no Chrome or Edge installed and no user who can be phished, a genuinely rare shop. Everyone else should treat this as a detection-engineering gap, not a patch-Tuesday item. There is no version number to bump. The question is whether your telemetry can tell a legitimate process from a legitimate process being walked through an illegitimate purpose.

The group behind it, and why the technique outlasts the sample

Chaos is a ransomware-as-a-service operation that Talos has tracked since February 2025, and its playbook up to this point has been unremarkable: mass phishing, vishing calls to help desks, and installing a remote-monitoring tool once it lands, the same access-and-persistence pattern a dozen other RaaS crews run. msaRAT is the interesting part precisely because the encryptor at the end of the chain has not changed - what changed is how the affiliate operating it talks to the victim host in the hours before the encryptor runs. That is where an incident responder actually gets a chance to catch a Chaos intrusion before it becomes a Chaos payout, and it is the window this technique is built to close.

Treat this the way you would treat any new living-off-the-land technique rather than a one-off curiosity. A browser vendor cannot patch away the fact that Chrome and Edge ship a debugging protocol by design - Selenium, Puppeteer, and a long list of legitimate automation tools depend on it. What changes over time is which legitimate mechanism a criminal group decides to abuse next, and a SIEM tuned only to known-bad domains and file hashes has no way to catch the next one. A SIEM tuned to catch a browser being launched for a purpose no human requested catches this technique, the next vendor's version of it, and anything else that walks through the same debugging API.

How msaRAT turns your own browser against you

The delivery is unremarkable by design: a curl command pulls an MSI installer disguised as a Windows update, and the installer loads a DLL - lib.dll, exported function RUN - directly into process memory. No dropped executable for an AV scanner to catch mid-write. From there, msaRAT locates an installed copy of Chrome or Edge and launches it via CreateProcessW with --headless=new, --remote-debugging-port=9222, --disable-background-networking, and an isolated --user-data-dir that sidesteps the profile locking Chrome 136 added specifically to make this harder.

Once the browser is up, msaRAT opens a WebSocket to its webSocketDebuggerUrl and starts issuing Chrome DevTools Protocol commands - the same debugging API every web developer uses, pointed at a purpose Google never intended. It calls Page.setBypassCSP to clear the page's Content Security Policy, registers five callback bindings through Runtime.addBinding (Talos found them named msaOpen, msaClose, msaError, msaMessage, and dataAck), then injects JavaScript straight from the binary's .rdata section with Runtime.evaluate. That injected script opens a WebRTC data channel, pulls STUN configuration from Google's public server and TURN relay credentials from Twilio's global.turn.twilio.com, and is configured to skip peer-to-peer ICE candidates entirely so every byte routes through the TURN relay rather than a direct connection an analyst could trace. Signaling runs through a Cloudflare Workers subdomain, a second layer of legitimate infrastructure standing between the victim and the operator. On top of the browser's own DTLS transport encryption, msaRAT layers ChaCha20-Poly1305 with an ECDH key exchange, triggered by a single handshake byte (0xFE) once the channel is live.

Why the traffic looked clean on your end

Here is the part worth sitting with. The msaRAT process itself only ever talks to 127.0.0.1:9222 - the local debugging port. Any endpoint tool watching that process for outbound connections sees nothing, because there is nothing to see; the process never opens a socket to the internet. All of the actual network egress originates from chrome.exe or msedge.exe, a signed Microsoft- or Google-shipped binary, headed to Cloudflare and Twilio - two services that show up in nearly every organization's allow-listed SaaS traffic already. Talos put it plainly: "by routing traffic through Twilio's legitimate service, the real IP address of the attacker's server never appears in the network traffic." A blanket block on Cloudflare Workers or Twilio's TURN infrastructure would break real business services for most companies, so the fix cannot be a firewall rule. It has to be a behavioral one.

Hunt the launch pattern, not the traffic

Three things are worth checking today, in order of how cheap they are to run. First, process ancestry: a headless Chrome or Edge with a remote-debugging flag, spawned by an installer, a service, or a scheduled task rather than a user double-clicking an icon, is not a pattern that shows up from normal browsing. Second, the loopback connection those flags create is itself a tell once you know to look for it. Third, Talos shipped concrete indicators - a staging IP at 172.86.126.18:443, the Cloudflare Worker subdomain is-01-ast.ols-img-12.workers.dev, a ClamAV signature (Win.Downloader.ChaosRaas-10060321-0), and Snort rules (2:66839-66841, 3:301587) - all posted to Talos's public IOC repository for anyone who wants to load them today.

# Sysmon Event ID 1: headless Chrome/Edge with remote debugging, spawned
# by a non-interactive parent - the msaRAT launch pattern Talos described.
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=1} |
  Where-Object {
    $_.Message -match '(chrome\.exe|msedge\.exe)' -and
    $_.Message -match '--headless(=new)?' -and
    $_.Message -match '--remote-debugging-port' -and
    $_.Message -notmatch 'ParentImage:.*\\(explorer|cmd|powershell)\.exe'
  } | Select-Object TimeCreated, Message

# Sysmon Event ID 3: the loopback connection to the debug port, or a hit
# on the published msaRAT IOCs (staging IP, Cloudflare Worker, Twilio TURN).
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; Id=3} |
  Where-Object {
    $_.Message -match '127\.0\.0\.1:92\d\d' -or
    $_.Message -match 'is-01-ast\.ols-img-12\.workers\.dev|global\.turn\.twilio\.com|172\.86\.126\.18'
  } | Select-Object TimeCreated, Message

None of this requires new tooling. It requires Sysmon configured to log process creation with command lines and network connections, which most environments running an EDR agent already have turned on somewhere, and a SIEM rule that actually joins the two event types instead of alerting on either in isolation. That correlation step is the one most detection pipelines skip, and it is exactly the gap msaRAT was built to walk through.

Do not let a blanket policy break your own automation

Before you push a org-wide policy disabling remote debugging, find out who in your environment already uses it on purpose. QA teams running Selenium or Puppeteer test suites, RMM tools that take remote screenshots, and some accessibility software all rely on the same Chrome DevTools Protocol msaRAT abuses, and a blanket RemoteDebuggingAllowed=false policy will break their pipelines the same morning it closes the ransomware path. The fix is scoping the exception, not skipping the policy: apply the restriction fleet-wide by default, then carve out named service accounts or build-server hostnames that legitimately need it, and log every use of the exception the same way you log a firewall rule override. An automation account that starts using the debugging port from a workstation it has never touched before is worth an alert on its own.

Restrict remote debugging before you audit the traffic

Chrome and Edge both ship a policy to control this: set RemoteDebuggingAllowed to disabled through Group Policy or your MDM of choice, and a headless browser can no longer expose a CDP endpoint at all, regardless of what an installer tries to pass on the command line. Do that first - it closes the mechanism outright rather than just adding a detection for it. Then add the Sysmon correlation above to your SIEM, load the Talos IOCs into your proxy and EDR block lists, and review any host that already shows the launch pattern for how it got there, since Chaos's entry point is still the ordinary one: a phished user or a vished help desk call, followed by an RMM tool the group installed for persistence before any of this ran.

None of this buys you time against the encryptor once it runs - it buys you the earlier window, the one where an operator is still exploring the host and has not yet pulled the trigger. That is the window Chaos built msaRAT to take away from you, and it is the same window every ransomware playbook depends on defenders having. Close the mechanism, wire in the detection, and the next browser-based C2 channel a different RaaS crew builds has to work harder to earn it back.