What Happened
Cisco Talos has published research on msaRAT, a new Rust-based remote access trojan deployed by the Chaos ransomware group as part of its post-compromise toolkit. The Chaos group, active since early 2025 and unrelated to the same-named ransomware builder from 2021, gains initial access through spam floods, vishing calls impersonating IT personnel, Quick Assist sessions, and remote monitoring and management tool abuse.
After gaining a foothold, the group deploys msaRAT, which launches a hidden Chrome or Microsoft Edge process on the victim machine. The malware controls the browser through the Chrome DevTools Protocol — a built-in debugging interface — and routes all command-and-control traffic through the browser using WebRTC. Traffic flows from the victim’s browser to a Cloudflare developer domain over HTTPS, then through a STUN request to a Google server, and finally through a Twilio relay to the C2 infrastructure. No direct connection from the infected endpoint to the C2 server is ever established.
From a network monitoring perspective, all C2 traffic appears as ordinary browser-based cloud service traffic originating from chrome.exe or msedge.exe. Chrome and Edge are not vulnerable. The malware simply uses them as a relay, exploiting the trusted status of browser processes on enterprise networks.
Why This Matters for Canadian Organizations
Network-based C2 detection has long struggled with encrypted TLS traffic. Most organizations compensate by monitoring for unusual outbound connections, unexpected process communications, or DNS queries to known-bad domains. msaRAT defeats all three approaches. The C2 traffic is encrypted, flows from a trusted browser process, reaches Cloudflare and Google infrastructure, and resolves only legitimate domains. There is nothing in the network traffic profile to flag.
The Chaos group’s initial access playbook is a particular threat to Canadian mid-market and public sector environments. Vishing attacks impersonating IT staff target help desk and end-user workflows. Quick Assist is enabled by default on Windows systems across most Canadian enterprises and government departments. IT help desks in organizations without strict identity verification protocols for remote session requests are a well-documented entry point for this group.
Canadian security operations centres relying primarily on network-layer inspection, DNS filtering, or firewall-based C2 detection will not see msaRAT in their alert queues. Under OSFI Guideline B-13, organizations are expected to maintain behavioral detection capabilities sufficient to identify anomalous activity at the endpoint layer. A tool like msaRAT — living inside a browser process, communicating through trusted cloud relay infrastructure — is precisely the kind of technique those requirements are meant to address. Organizations without endpoint detection and response coverage on every managed system face a significant blind spot.
What to Do
Update endpoint detection rules to flag chrome.exe or msedge.exe spawned by unusual parent processes, running with remote debugging flags, or launched from non-standard locations. DevTools remote debugging port activity from a browser process the user did not open is an anomaly worth investigating.
Restrict Quick Assist and remote assistance tools to specific, approved workflows. Require secondary approval — ideally through a separate channel — before any remote session is authorized. Train help desk staff to verify caller identity through a callback process before granting any remote access.
Review your endpoint detection and response platform for coverage of Chrome DevTools Protocol abuse and WebRTC-based C2 channels. If your current tooling does not detect these behavioral patterns, raise it as a detection gap with your vendor. Network-only detection is insufficient against this technique.
Source: Cisco Talos, BleepingComputer
