Chaos Ransomware's msaRAT: Leveraging Browser-Based Covert C2 Channels to Evade Detection

Key Findings

• Cisco Talos discovered msaRAT, a Rust-based remote access trojan used by the Chaos ransomware group that routes all command-and-control traffic through Chrome or Edge browsers
• The malware never makes direct network connections; it exclusively uses Chrome DevTools Protocol (CDP) to manipulate the victim's browser for C2 communications
• msaRAT establishes WebRTC DataChannels through Cloudflare Workers for signaling and Twilio TURN relays for actual C2 traffic, making the attacker's infrastructure invisible to network monitoring
• The RAT employs double-layer encryption using ChaCha-Poly1305 on top of DTLS protection, significantly complicating detection and interception efforts
• Initial infection occurs through a downloaded MSI file masquerading as a Windows update that loads the malware DLL directly into memory

Background

Chaos is a ransomware-as-a-service group that emerged in February 2025, targeting large organizations with double extortion tactics. The group relies on spam emails and voice-based social engineering (vishing) for initial access, then uses remote monitoring and management tools to establish persistence and file-sharing software for data exfiltration. Before deploying the encryption payload, Chaos operators now use msaRAT for post-compromise reconnaissance and command execution.

Infection Chain

The attack begins with a curl command that downloads an MSI installer named "update_ms.msi" from an attacker-controlled server. The command specifies port 443 but uses plain HTTP, allowing it to bypass firewalls that only filter by port number without inspecting the actual protocol. The installer is configured to impersonate a Windows update and contains a custom action that triggers upon installation completion. This action loads lib.dll directly into memory from the MSI's Binary table, effectively executing the RAT payload without writing it to disk.

msaRAT Technical Architecture

msaRAT is built using Tokio, an asynchronous runtime for Rust that enables concurrent operations. Upon execution, the malware initializes Tokio by first checking the TOKIO_WORKER_THREADS environment variable. If not set, it queries the system for CPU count via the Windows GetSystemInfo API to determine how many worker threads to spawn. The Tokio runtime then creates OS threads matching this count to handle asynchronous tasks. This architecture allows the malware to manage multiple operations simultaneously while maintaining a low profile.

Browser Discovery and Hijacking

msaRAT searches for Chrome or Edge browsers using a defined priority order through environment variables, falling back to registry lookups if necessary. If no browser is found, the malware cannot establish its C2 channel and the attack effectively stalls. Once located, msaRAT launches the browser in headless mode with remote debugging enabled on a local port. The malware connects to the browser through its debugging interface and bypasses Content Security Policy restrictions using CDP commands. It then injects JavaScript code into the browser that handles all actual network communications on behalf of the RAT process.

WebRTC C2 Communication

The malware uses a sophisticated multi-stage approach for establishing command-and-control communications. First, the injected JavaScript performs an SDP Offer/Answer exchange with a Cloudflare Workers endpoint to set up a WebRTC connection. Critically, msaRAT deliberately omits ICE candidates from the WebRTC negotiation, preventing direct peer-to-peer connections and forcing all traffic through Twilio's TURN relay service. Once the WebRTC DataChannel is established, the Cloudflare Workers endpoint drops out of the communication path entirely, and all subsequent C2 commands flow exclusively through the encrypted DataChannel.

Evasion and Defense Bypass

From a network perspective, defenders see only legitimate traffic: HTTPS requests from the browser to Cloudflare and WebRTC traffic to Twilio, both commonly allowed services. The actual RAT process never initiates external network connections—it communicates exclusively with the local browser on 127.0.0.1. The attacker's server address never appears in network traffic. This design makes blocking the C2 infrastructure extremely difficult without disrupting legitimate business operations, since blocking Cloudflare Workers would impact many standard web services. The malware process remains invisible to network monitoring tools while appearing as normal browser activity to security systems.

Encryption and Protection Mechanisms

msaRAT implements two layers of encryption for all C2 traffic. The WebRTC DataChannel is protected by DTLS encryption, which the browser handles automatically. Beyond this, the malware encrypts its payload before passing data to the browser using ChaCha-Poly1305 encryption with keys derived through an ECDH handshake at connection initialization. This dual-encryption approach means that even if an attacker strips the DTLS layer, the payload remains encrypted and unreadable. The combination ensures confidentiality and integrity of C2 communications while maintaining operational security.

Sources

• https://blog.talosintelligence.com/chaos-msarat-living-off-the-browser-to-build-covert-c2-channel/
• https://securityaffairs.com/195876/malware/chaos-ransomware-deploys-browser-based-msarat-to-evade-network-detection.html
• https://radar.offseq.com/threat/chaos-ransomwares-msarat-living-off-the-browser-to-build-a-covert-c2-channel-586143cde7651f57