Malware News Cisco Talos found a new Rust-based RAT attributed to the Chaos ransomware group. msaRAT is implemented using the Tokio asynchronous runtime.......

Khushal

Level 16
Thread author
Verified
Top Poster
Well-known
Apr 4, 2024
757
4,979
1,469
1784913840899.png

  • Cisco Talos has discovered a new Rust-based remote access trojan (RAT) we call “msaRAT” attributed to the Chaos ransomware group. The name is derived from the binding names found in the binary: “msaOpen,” “msaClose,” “msaError,” and “msaMessage”.
  • msaRAT is implemented using the Tokio asynchronous runtime, with primary capabilities of browser-leveraged remote code execution and covert tunneling to establish command-and-control (C2) communications.
  • This RAT never touches the network directly — it controls its C2 communication channel exclusively through Chrome DevTools Protocol (CDP), a browser debugging API. The binary contains a Cloudflare Workers endpoint, but it never makes HTTP connections to that domain itself; it offloads that work entirely to the browser.
  • msaRAT manipulates the browser via CDP, performs signaling (SDP Offer/Answer exchange) with Cloudflare Workers, and establishes a WebRTC DataChannel between the browser and the C2 server using Twilio TURN (Traversal Using Relays around NAT) as a relay.
 
  • Like
Reactions: harlan4096
Why this technique matters

This is a notable example of abusing a legitimate browser debugging interface rather than implementing conventional socket-based C2 inside the malware. The RAT can use Chrome as its network-capable component, which may reduce the value of simple process- or firewall-based detections that focus on the malware binary making outbound connections.

Important defensive points include:

  • Chrome DevTools Protocol should not be exposed beyond the local host. Review systems for Chrome or Chromium processes started with remote-debugging options such as --remote-debugging-port or --remote-debugging-address.
  • Monitor unusual child processes, command lines, and parent-child relationships involving Chrome or Chromium. A non-browser executable launching or automating a browser is not automatically malicious, but it deserves investigation in context.
  • Look for unexpected connections to local CDP endpoints, particularly ports commonly associated with remote debugging. Port numbers alone are not sufficient for a verdict because legitimate development tools also use CDP.
  • Review endpoint telemetry for unfamiliar binaries interacting with browser profiles, browser automation interfaces, WebRTC components, or DevTools JSON endpoints.
  • Network controls should account for browser-mediated communications. Blocking direct connections from the RAT process may not help if Chrome is being used as the network channel.
  • Apply browser, operating-system, and endpoint-security updates, and restrict unnecessary developer or remote-support software.

WebRTC and TURN traffic can make traditional domain- or process-based attribution more difficult, and encrypted traffic limits content inspection. Detection should therefore combine command-line telemetry, process behavior, local CDP access, browser launches, and the indicators published by Cisco Talos.

The presence of Chrome DevTools Protocol activity alone does not prove infection. Developers, testing frameworks, accessibility tools, and remote-support products can legitimately use it. Any suspected compromise should be investigated with reputable endpoint security software and the original Talos indicators rather than relying on a single event or port.

Sources


The key takeaway is that browser automation and debugging interfaces should be treated as security-sensitive attack surfaces, especially when they are enabled on endpoints that do not require them.