CTI Roundup: BERT Ransomware, TGR-CRI-0045, XWorm

In this week’s roundup, Tanium’s Cyber Threat Intelligence (CTI) team looks at the recently emerged BERT ransomware group, which is now targeting Windows and Linux platforms across the technology, healthcare, and event services sectors. Next up, the team looks at a campaign conducted by an initial access broker (IAB) that’s temporarily being tracked as TGR-CRI-0045. Finally, we explore XWorm’s evolution into a highly adaptable remote access trojan (RAT).

BERT ransomware targets Windows and Linux platforms

Trend Micro shared details of the newly emerged BERT ransomware group. The group, which has been active since April 2025, is now targeting organizations across Asia, Europe, and the United States with multi-platform attacks on both Windows and Linux systems.

Despite having simple code, BERT uses aggressive tactics like concurrent encryption and ESXi shutdowns to maximize disruption and ransom leverage.

How does the BERT Windows variant work?

According to Trend Micro, the group uses a straightforward code structure for the Windows version of its ransomware with specific strings that will terminate processes.

Trend Micro found that the public key, file extension, and ransom note were all easily accessible in the code, and it identified the use of standard AES for encryption.

[Read also: The art of ransomware negotiation]

Trend Micro also identified additional samples of BERT that had been uploaded in the wild. Many of these appeared to be older versions that lacked encryption and other things seen in their own internal telemetry, indicating that there have been multiple iterations of BERT.

In addition, Trend Micro identified a PowerShell script that acts as the loader for the actual BERT ransomware payload. This PowerShell script “escalates privileges, disables Windows Defender, the firewall, and user account control (UAC), then downloads and executes the ransomware from a remote IP address.”

Evolution of BERT variants

Older variants would first enumerate drives and drop the ransom note in every directory. They would then collect the necessary file paths, store them in an array, and proceed with encryption.

The newer variant uses ConcurrentQueue and creates a DiskWorker on each drive to improve the encryption process. This approach enables multi-threaded encryption, allowing BERT to begin encrypting files as they are identified rather than waiting to collect all file paths—significantly increasing speed and impact.

What to know about the Linux variant

In May, Trend Micro came across a BERT Linux variant that uses 50 threads to maximize encryption speed. This variant accepts three command-line parameters:

1. To specify the target directory to encrypt
2. To set the number of threads for encryption (default is 50)
3. To enable silent mode

When the ransomware is executed without these parameters, it will shut down virtual machines, terminating all running virtual machine processes within the ESXi host. Once this variant completes its encryption routine, it will append .encrypted_by_bert to each file and drop the ransom note.

Trend Micro believes the group may have derived this variant from the Linux variant of REvil.

Analyst comments from Tanium’s Cyber Threat Intelligence team

It’s only been a few months since BERT emerged, but it already has variants targeting both Windows and Linux systems—highlighting a growing trend among threat actors of designing malware and ransomware to exploit hybrid environments.

The takeaway is that BERT’s codebase is relatively simple, but the group behind it excels at operationalizing attacks. It’s a reminder that the effectiveness of a threat doesn’t always correlate with its technical complexity.

TGR-CRI-0045 exploits leaked machine keys to access organizations

Palo Alto recently uncovered a campaign carried out by an IAB, which they are temporarily tracking as TGR-CRI-0045.

This actor was observed exploiting leaked ASP.NET machine keys to hijack sessions and gain unauthorized access to Microsoft Internet Information Services (IIS) servers, enabling stealthy persistence and further compromise.

How this IIS exploit was discovered

Earlier this year, Palo Alto responded to web server intrusions in two different customer environments. Both intrusions involved a command shell execution coming from an IIS worker process and displayed common characteristics.

The investigation revealed that the attacker “executed commands loading managed .NET assemblies (C# code) directly into memory (reflective loading).” This exploit targeted View State, which is a parameter within ASP.NET sites that run on Microsoft IIS.

TGR-CRI-0045 exploit chain explained

Websites use View State to manage interactions between browsers and servers. As it turns out, the _VIEWSTATE parameter is vulnerable due to deserialization techniques that attackers can use to enable remote code execution. However, this can only occur if the attacker has the correct machine key.

Attackers have been known to either use lists of leaked machine keys or extract the keys from running servers directly. Once they have these keys, regardless of the method, they can create the deserialization payload and target the server.

According to Palo Alto, TGR-CRI-0045 likely used tools like ysoserial.net—an open-source payload generator for creating malicious deserialization payloads.

Understanding the assemblies

Palo Alto identified five .NET assembly subsets that were loaded into memory after the actor exploited View State. These include:

1. cmd /c: Executes arbitrary system commands on the compromised server
2. Winner: Likely used to verify successful exploitation or environment readiness
3. File upload: Enables the attacker to upload malicious files or tools directly to the server for further exploitation or persistence
4. File download: Allows the attacker to exfiltrate sensitive data or retrieve payloads from the compromised environment
5. Reflective loader: Injects and executes .NET assemblies directly in memory without touching disk, a key evasion technique that avoids writing artifacts to disk and helps bypass traditional detection methods

These assemblies all shared similar data handling characteristics and make the same calls to terminate HTTP responses.

[Read also: Protect your prompts: Injection threats are coming for your AI tools]

What happens after exploitation?

This actor’s post-exploitation activity included reconnaissance of both the compromised host and the network. Palo Alto notes that the actor consistently used the WindowsTemp111t path as their staging directory.

For privilege escalation, the actor used a custom binary updf, which can execute commands with SYSTEM privileges and can create new local users and add said users to the local admin group.

The actor also commonly downloaded an ELF binary named atm, used TxPortMap to identify what servers could be reached from the initially compromised device, and performed reconnaissance via the command shell assembly.

Analyst comments from Tanium’s Cyber Threat Intelligence team

Palo Alto’s analysis reveals how IABs are evolving in terms of technical sophistication. They no longer solely rely on traditional techniques like phishing or brute forcing.

The analysis also highlights how secrets management like machine keys should be treated the same as credentials or API tokens, as misuse can result in serious security incidents.

The report includes remediation and hardening guidance, along with a larger summary of the implications of in-memory IIS tradecraft.

XWorm evolves into a modular and evasive RAT

According to Splunk, XWorm has evolved into a modular remote access trojan that leverages shifting file formats, scripting languages, and obfuscation techniques to evade detection and deliver payloads.

Splunk’s analysis highlights the malware’s modular design and its links to ransomware operations. The report also provides actionable detection strategies to help defenders counter its stealthy behavior.

The anatomy of an XWorm phishing attack

Splunk notes that XWorm is cycling through file formats and scripting languages as part of a broader defense evasion strategy. The malware also uses a range of droppers, stagers, and loaders in its infection chain.

The analysts dove deeper into XWorm to identify the various file formats it uses. The team pulled 1,000 XWorm samples from Malware Bazaar, looking for more unique file types instead of traditional EXE and DLL files. The most frequently used file types include VBS, batch, JavaScript, and PowerShell. These types of files are often delivered via email.

Similarly, Splunk looked at filenames to understand what type of social engineering lure may be used most often by XWorm. They found multiple recurring themes including invoices, receipts, and shipping notifications.

Some of the script components will download the main XWorm payload directly from the C2 server. During the investigation, Splunk came across HTA files and PowerShell stagers that acted as the initial stage and were responsible for downloading the next stage payload.

How XWorm deploys its payloads

Splunk identified VBS and batch script stagers that were obfuscated to make the code analysis more difficult and evade detection.

These scripts decode and decrypt two executables directly in memory—a common technique to avoid writing to disk and evade detection. These executables act as the next-stage stager and loader, responsible for delivering additional components and ultimately deploying the XWorm payload:

1. Stager: Bypasses AMSI (Antimalware Scan Interface) to disable script scanning
2. Loader: Tampers with Windows ETW (Event Tracing for Windows) to evade runtime monitoring

Both are designed as anti-analysis mechanisms to reduce visibility and hinder detection.

The stager also establishes persistence and escalates privileges by creating registry run keys and scheduled tasks. It attempts to decompress GZIP data from its resource sections, use DLL side loading to masquerade malicious code as legitimate libraries, and injects shellcode into target processes to execute payloads in memory.

What the XWorm payload does after infection

The final XWorm payload is a decrypted executable (payload.exe). XWorm uses WMI (Windows Management Instrumentation) to perform host reconnaissance, including identifying available webcams. Like other types of malware, XWorm uses Microsoft Defender’s exclusion settings to prevent its directory from being scanned.

Splunk also identified a function called RunDisk() that executes a PowerShell component with a modified execution policy. The malware attempts to propagate via removable drives and includes a function to process backdoor commands. Similar to the stager and loaders, the malware uses registry run keys and scheduled tasks for persistence.

Analyst comments from Tanium’s Cyber Threat Intelligence team

XWorm is highly adaptable and poses several unique challenges for defenders.

Its evolution reflects a broader trend toward increased modularity and enhanced evasion capabilities. This, combined with its use of rotating file formats and scripting languages, is likely to improve its success rate and increase its appeal among threat actors.

Splunk’s analysis also emphasizes the importance of behavioral detections for things like suspicious registry activity, as opposed to static indicators.

Do you have insight into these stories that you want to share? Head over to Tanium’s discussion forum to start a conversation.

For further reading, catch up on our recent cyber threat intelligence roundups.