Browser-As-A-Proxy: New msaRAT Malware Routes Command-and-Control Through Chrome and Edge
Executive Summary
A newly documented remote access trojan, msaRAT, marks a structural departure in how ransomware-affiliated tooling communicates with its operators. Rather than relying on obfuscated domains or fronted infrastructure to evade network detection, msaRAT eliminates direct malware-to-command-and-control traffic entirely. It hijacks a victim's own installed Chrome or Edge browser through the Chrome DevTools Protocol, then uses that browser to negotiate a WebRTC connection relayed through legitimate Cloudflare Workers and Twilio TURN infrastructure.
The result is command-and-control traffic that appears, at the host and network layer, indistinguishable from ordinary browser activity. Cisco Talos attributes deployment of msaRAT to the Chaos ransomware-as-a-service group, delivered via a disguised Windows update installer.
For security teams, the practical takeaway is immediate: detection and allowlisting strategies built on process identity and destination reputation are no longer sufficient on their own, and behavioral monitoring for browser automation abuse should be treated as a near-term priority.
Key Finding: msaRAT removes the malicious process from the network path entirely by forcing a victim's legitimate Chrome or Edge browser to carry all command-and-control traffic over a WebRTC relay, rendering process-based and reputation-based detection models structurally blind to the technique.
What Happened
On July 23, 2026, Cisco Talos Intelligence Group published technical analysis describing a previously undocumented Rust-based remote access trojan it has named msaRAT — a designation drawn from internal Chrome DevTools Protocol (CDP) binding names observed in the malware's code (msaOpen, msaClose, msaError, msaMessage). Talos attributes deployment of the tool to the Chaos ransomware-as-a-service group, an affiliate-driven operation whose activity Talos and other researchers have tracked since early 2025. Initial access in the observed cases traces to a dropper disguised as a routine Windows update, distributed via an MSI installer named update_ms.msi and delivered through spam and vishing-based social engineering rather than a novel exploitation technique.
What distinguishes msaRAT from prior tooling attributed to Chaos is not its delivery mechanism but its communication architecture. Conventional RATs typically open a direct network socket from the compromised host to an operator-controlled server, a behavior that—however well obfuscated—still produces a discrete, attributable process making outbound connections. msaRAT, built on the Rust Tokio asynchronous runtime, dispenses with this model entirely. Once resident on a host, it does not communicate over the network itself. Instead, it launches a headless instance of whichever browser is already installed, Chrome or Edge, and connects to that instance using the Chrome DevTools Protocol—the same interface browser vendors expose for legitimate automation, debugging, and testing tooling. Through CDP, msaRAT injects JavaScript into the headless session and uses that injected code to negotiate a WebRTC DataChannel.
The signaling exchange required to establish this channel—the SDP handshake that allows two WebRTC peers to discover one another—is brokered through a Cloudflare Workers endpoint, meaning the initial connection request traverses infrastructure widely allowlisted by enterprise security tooling. Once the channel is established, all subsequent command-and-control traffic is relayed through Twilio's TURN infrastructure, a service designed to route real-time communications traffic around network address translation and firewall restrictions. As an added layer, Talos notes that C2 payloads carried over this channel are independently encrypted with ChaCha20-Poly1305, layered on top of the DTLS encryption WebRTC already provides natively.
Every stage of the malware's external communication—signaling and relay alike—is carried by infrastructure operated by reputable, widely used providers, and every packet observed at the host level originates from a signed, legitimate browser binary rather than the malicious process itself. Talos characterizes this as a deliberate architectural choice: removing the RAT from the network path altogether, rather than merely obscuring it.
BleepingComputer's practitioner-facing coverage and independent analysis from GridinSoft and Cypro have since corroborated the core technical findings, with community discussion on malware.news noting that the technique, while novel in its specific combination of CDP abuse and WebRTC relay, extends a broader and increasingly familiar pattern of adversaries repurposing legitimate cloud and developer platforms as covert infrastructure.
Why It Matters
For SOC Analysts & Detection Engineers
msaRAT poses a structural challenge rather than a signature-matching one. Detection logic that flags "unusual processes making outbound network connections" is, by design, blind to this technique—the process making the connection is always the legitimate, digitally signed browser binary that already has broad network privileges on most enterprise endpoints. Effective detection has to shift toward identifying the conditions under which a browser is launched and controlled, rather than relying on the fact of its network activity.
For Security Leaders & Architects
The more consequential implication concerns policy design. Cloudflare Workers and Twilio TURN are legitimate, widely used commercial platforms with substantial enterprise adoption of their own, which means destination-based blocking or reputation scoring is not a viable standalone control here; blocking the infrastructure outright risks breaking legitimate business functions that depend on it. This pushes the burden toward behavioral and contextual monitoring—a more resource-intensive posture that not every organization is currently staffed or tooled to sustain.
For Policy-Aware Executives & Workforce Development Professionals
msaRAT is best understood as one instance of a broader and durable trend sometimes termed "living off the cloud" (LOTC): the repurposing of trusted developer, communications, and collaboration platforms as covert infrastructure. This pattern complicates not only detection but also attribution and takedown, since disrupting the infrastructure itself means acting against a legitimate provider's service rather than a dedicated malicious host. Organizations should expect this category of technique to recur across other cloud-native relay and signaling services, not remain unique to WebRTC or to Chaos-affiliated tooling.
Operational Implications
Immediate Term: Incident response teams should treat unexplained headless browser processes—particularly those launched with remote-debugging or automation flags by non-browser parent processes such as installers or scripts—as a high-confidence indicator of compromise rather than a benign automation artifact. This requires updating existing triage playbooks, which have historically treated headless browser activity as most associated with adware, scraping tools, or internal QA automation, to reflect this new C2 use case.
Short Term: EDR and network detection engineering built around process-to-network correlation needs augmentation rather than replacement. Behavioral baselining of CDP usage—specifically, remote-debugging-port activation by processes other than expected automation or testing frameworks—and of WebRTC DataChannel creation outside known application contexts represent the two most direct detection opportunities Talos's analysis surfaces. Neither is likely to be a simple signature; both require establishing a baseline of legitimate CDP and WebRTC activity in a given environment before anomalies become reliably distinguishable from normal use.
Long Term: This technique argues for a broader reassessment of how much implicit trust is extended to signed browser processes within detection architectures. Many existing controls were built on the reasonable but now-eroding assumption that a legitimate, vendor-signed browser binary making network connections is inherently lower-risk than an unknown process doing the same. msaRAT demonstrates that this assumption can be directly exploited by an adversary with local code execution, and that architecture decisions premised on it—including some allowlisting and DLP configurations—may need revisiting independent of any specific patch or signature update, since this is a tradecraft disclosure rather than a vulnerability with a remediation path.
Recommended Actions
This is a tradecraft disclosure rather than a vulnerability with a remediation path — actions are stratified by organizational maturity and focus on detection and behavioral controls rather than patching.
- 1 - Capture Browser Launch Arguments: Ensure endpoint logging captures browser process launch arguments, including flags such as
--headless,--remote-debugging-port, and--disable-gpu, retained long enough to support retrospective investigation. - 2 - Escalate Headless Browser Activity in Playbooks: Review incident response playbooks to confirm that headless browser activity from non-standard parent processes (installers, MSI packages, scripting hosts) is explicitly treated as an escalation trigger rather than filtered as noise.
- 1 - Alert on Unauthorized CDP Activation: Deploy or tune EDR rules to alert on CDP remote-debugging-port activation initiated by processes outside an approved automation or QA tooling inventory.
- 2 - Reassess Allowlisting for Abused Infrastructure: Review current allowlisting policies for
*.workers.devand Twilio TURN IP ranges, understanding that blanket allow decisions are no longer a sufficient standalone control; layer behavioral or volumetric monitoring on top of existing allow rules rather than removing them outright, given legitimate business dependencies on both platforms.
- 1 - Build WebRTC Behavioral Baselines: Build or extend behavioral baselines for WebRTC DataChannel creation across the endpoint fleet, distinguishing expected application-driven WebRTC use (video conferencing, collaboration tooling) from unexpected instantiation tied to browser automation.
- 2 - Incorporate CDP Abuse into Red/Purple Team Exercises: Security architecture teams should incorporate CDP-abuse and browser-proxied C2 scenarios into red team and purple team exercises.
- 3 - Track Chaos-Affiliated Tooling Evolution: Threat intelligence functions should track Chaos-affiliated tooling evolution specifically, given the group's demonstrated willingness to invest in architecturally novel C2 techniques rather than iterating on existing malware families.
Across All Maturity Levels: Institutional stakeholders should update ransomware tabletop exercises to include browser-proxied C2 as a distinct initial-detection blind spot, separate from the beaconing-based scenarios most existing tabletops are built around.
Closing Statement
msaRAT does not introduce a new vulnerability to patch or a new exploit to signature; it introduces a new question about where trust is placed in detection architecture. As adversaries continue to route their operations through the same reputable, widely adopted infrastructure that organizations rely on daily, the durable lesson is not specific to WebRTC, Cloudflare Workers, or Twilio TURN—it is that legitimacy of origin and legitimacy of intent are no longer reliable proxies for one another.
Bridging that awareness gap, one architecture at a time, remains the ongoing work of institutional resilience.