A screenshot of a message from TeamPCP’s Telegram account, announcing the supply chain hacking contest. Image: dataminr.com.

A screenshot of the Matrix chat server “Cybercats,” whose members used hacker handles associated with multiple distinct cybercrime groups that have occasionally collaborated on a series of supply chain and data ransom attacks over the past nine months.

The data leak site for the extortion group or handle “xpl0itrs.”

The data leak site of Fulcrum Security, a.k.a. Fulcrumsec.

DMT Host/EllisD25, posting on the English-language cybercrime community DarkForums in September 2025. Image: ke-la.com.

A cached copy of the domain rubenthomson.com from 2017 shows a login page underneath a banded stack of money. Image: archive.org.

The Upwork profile for Ruben Thomson in Cottesloe, Australia.

Business reviews in Western Australia left by the Google account sheepstealing at gmail.com.

Australian companies connected to Ruben Thomson. Image: abr.business.gov.au.

The HackerOne profile for “Ruben Thomson” uses the nickname Deadcatx3, which multiple security firms have concluded is an alias used by TeamPCP. Image credit: flare.io.

An image posted by the TeamPCP leader to Telegram, advertising his acquisition of some type of psychoactive substance, most likely a synthetic version of the powerful hallucinogen known as DMT.

Written by: Kelli Vanderlee, Stuart Carrera

For years, the cybersecurity industry's understanding of software supply chain compromise has been anchored by a few watershed events, including Russian cyber espionage actor ICE RELIC’s (formerly known as APT29) 2020 compromise of SolarWinds and North Korean cyber espionage actor UNC4736's 2023 compromise of 3CX. However, Google Threat Intelligence Group (GTIG) has been tracking growth in threat activity targeting open source software repositories to conduct supply chain compromises over the past several years. A series of large scale open source software supply chain compromise campaigns in 2025 and the first half of 2026 underscore how important it is that organizations implement defensive strategies that directly address this threat vector. 

In this blog post, GTIG and Mandiant discuss trends we have observed in threat actor use of software supply chain compromise, and provide mitigation and hardening recommendations that incorporate insights we have developed as a result of supporting customers through recent campaigns in which threat actors manipulated open source packages. 

Open Source Supply Chain Compromise Grows in Volume and Impact in 2025 and Early 2026

The majority of the most impactful and far-reaching supply chain compromise incidents that GTIG tracked in 2025 and early 2026 involved the compromise of code repositories, software dependencies and developer tools (T1195.001). Open source supply chain compromises offer attackers the same efficiency, scale, and initial stealth as traditional supply chain compromises, but typically require significantly less planning and resources to execute. However, open source supply chain compromises are also noisy once enabled; malicious open source packages are often discovered and publicized much more quickly than traditional supply chain compromises. 

GTIG assesses with high confidence that the growth in very large-scale, open-source supply chain compromise campaigns, including use of worms and iterative compromises in 2025 and early 2026, represent a significant expansion in use of this tactic compared to prior years. We anticipate that threat actors will emulate the tactics of these campaigns and contribute to growth in open-source supply chain compromise through the rest of 2026 and years to come. GTIG identified several notable supply chain compromises in 2025 and early 2026 that we believe exemplify this trend of exceptionally large campaigns, as measured by size and/or impact (Figure 1). 

For example from February to May 2026, UNC6780 (aka "TeamPCP") conducted extensive open source supply chain compromises targeting ecosystems like PyPI, npm, and Docker Hub. Initial infection vectors varied across incidents, and included abuse of the pull_request_target GitHub Actions trigger to obtain base repository secrets and write permissions. The threat actor typically used compromised packages to deploy credential stealers, including SANDCLOCK, to obtain high value secrets. In incident response engagements, we observed UNC6780 attempting to pivot from compromised artificial intelligence (AI) software to broader network environments. UNC6780 has monetized stolen credentials through either direct sale of the stolen data, or through partnerships with ransomware and data theft extortion groups. 

In March 2026, GTIG observed the introduction of a malicious dependency in the legitimate axios package. GTIG analysis and the maintainer's post mortem indicate that the maintainer account was compromised via social engineering and used to publish the updated versions. We identified the malicious dependency as a dropper that deploys the WAVESHAPER.V2 backdoor, and attributes the activity to North Korean actor MIDNIGHT NEPTUNE (formerly known as UNC1069). While the malicious versions of axios were removed from the npm registry within three hours of their release, the scope of the compromise is estimated to be broad, as the package has over 100 million weekly downloads. GTIG supported customers in at least 15 industry verticals and 13 different countries affected by this incident. Further, axios is also a dependency for tens of thousands of other packages, and open sources reported that the malicious axios update had spread to several of these.

AI Likely to Accelerate Open Source Supply Chain Compromises

GTIG anticipates AI will accelerate the growth of open source software supply chain compromise. Integration of AI into open source software development practices, including "vibe coding," increases attacker opportunities both to manipulate AI functionalities and to take advantage of AI to speed and scale their own operational planning. Open sources have documented multiple instances of threat actors planting malicious resources on open source AI communities and inserting malicious code into open source Model Context Protocol (MCP) packages. MCP is a standardized protocol for AI to interact with tools and data. Malicious packages have also tricked AI coding agents, which have unwittingly incorporated them into projects. North Korean threat actors reportedly uploaded malicious cryptocurrency-themed packages, and subsequently an AI coding agent co-authored a commit integrating one of the malicious packages as a dependency to a legitimate cryptocurrency trading project. 

Thousands of Malicious Open Source Packages Detected

Corroborating GTIG's findings, statistics compiled by the Open Source Security Foundation (OpenSSF), a cross-industry, non-profit collaboration under the Linux Foundation, indicate that the number of malicious open source software packages identified increased exponentially, or 1,444% from 2024 to 2025 (Figure 2).

Traditional Supply Chain Compromise Remains Rare

In contrast to what we observed in the open source ecosystem, GTIG assesses with high confidence that traditional software supply chain compromise, the manipulation of source code or update/distribution mechanisms (T1195.002), remains rare. The handful of identified cases in 2025 and early 2026 were predominantly cyber espionage incidents with intentionally limited targeting scopes. 

In the most significant case, North Korean threat actor UNC4899 reportedly used social engineering to compromise a developer's machine at a web3 organization. The threat actor used this access to inject malicious code into the frontend systems, specifically impacting smart contract functionality to alter transactions initiated by a third party organization that utilized the multi-signature wallet with the targeted organization. This compromise was tailored to a single victim, but did not directly touch the targeted organization's infrastructure. The compromise ultimately led to a cryptocurrency theft of assets with an estimated value of $1.4B USD.

Other examples include the compromise of hosting infrastructure serving updates of Notepad++ from June to December 2025, activity GTIG attributes to UNC6688. GTIG observed organizations in South Korea and France affected by this activity.  GTIG also tracked the early 2026 compromise of DAEMON Tools installers. During this campaign, UNC6863 deployed SLICKDEMON to perform broad-spectrum reconnaissance and filter for targets of strategic interest. Following this profiling stage, the group selectively delivered the shellcoded loader BADFALL to facilitate hands-on-keyboard activity and bridge the deployment of the advanced QUIC RAT. The campaign targeted Russia, Brazil, and Turkey, with follow-on exploitation of government and scientific entities in Belarus and Thailand.

In addition to likely cyber espionage incidents, we observed suspected financially motivated compromises with broader distribution. In two separate incidents threat actors compromised underlying software used in consumer-facing websites: in one case, automotive dealership websites served ClickFix lures leading to the installation of SHADOWLADDER (aka SectopRAT), and in another, eCommerce websites were infected with web skimmers.

Mitigation Recommendations

To effectively mitigate and harden against software supply chain compromises, organizations should adopt a multi-tiered defensive strategy designed to minimize exposure and strengthen resilience against potential compromises.

Administrative Oversight and Risk Governance

• Cataloging Assets and Dependencies: Maintain a tiered, continuous inventory of all applications, third-party vendors, and services based on operational importance to detect single points of failure and security risks.

• Software Bill of Materials (SBOM): Implement an automated SBOM for all internal and third-party software packages, allowing security teams to continuously monitor and cross-reference active code inventories against newly disclosed vulnerabilities.

• Action Bill of Materials (ABOM): Maintain a dedicated ABOM to inventory every third-party pipeline vendor and development utility in use, linking it to your container image inventory to track exactly which external actions are building your production images.

• Software Development Lifecycle (SDLC) Threat Modeling and Attack Chain Mapping (Wiz SITF): Align your software supply chain risk management with capabilities such as the Wiz SDLC Infrastructure Threat Framework (SITF) to transition from treating security as a checklist of isolated controls to a holistic threat model. With this freely available framework, organizations can map recent incidents, threat actor campaigns, and red team exercises directly to Wiz SITF Reference IDs indexing each risk to its specific lifecycle stage: Version Control Systems (VCS), continuous integration and continuous delivery (CI/CD) pipelines, package registries, or production infrastructure. This methodology allows security teams to model complex "attack chains" where minor, isolated weaknesses (e.g., a lockfile bypass combined with an overprivileged pipeline token) are chained together by sophisticated threat actors to execute critical, high-impact breaches

• Active Risk Monitoring:  Maintain a dedicated supply chain risk register and a centralized remediation tracker to systematically group development lifecycle (SDLC) threats into clear operational domains: Governance, Identity, Pipeline Logic, and Supply Chain Hygiene. If using Wiz SITF, each vulnerability must be mapped to its exact pipeline stage with a unique Wiz SITF Reference ID. Instead of treating vulnerabilities as isolated bugs, prioritize the blocking of complex "attack chains" (such as a leaked token combined with missing branch protections and overprivileged OIDC trust) that pose the highest breach risk. Ensure each logged item has a designated owner, a targeted completion date, and clear tracking of technical dependencies.

• Standardized Configuration & Change Control: Form a Change Advisory Board (CAB) to manage the rollout of all enterprise software and hardware. Ensure every modification includes a pre-deployment risk review, post-deployment monitoring, and a verified plan for recovery or backout.

• Staff Security Education: Deploy ongoing training initiatives centered on supply chain hazards, social engineering techniques, and internal procedures for reporting incidents.

• Node.js (npm/pnpm): Enforce cooldown controls by using the minimumReleaseAge configuration. Setting this value to at least 24 hours (1440 minutes) ensures that freshly published, potentially poisoned packages are quarantined until the broader security community has had time to identify and remove them. Ensure that older, unsupported package manager versions (such as legacy Yarn or pnpm versions) are modernized, as they will silently ignore these cooldown boundaries.

• Python (pip): Ensure that Python project environments do not pull dependencies directly from the public PyPI registry, which bypasses internal release-age policies and gating controls. All configurations must specify a secure, vetted private --index-url in their configuration files to ensure consistent quarantine and vetting of upstream packages.

Vendor Lifecycle Management

• Vendor Security Vetting: Conduct rigorous due diligence prior to procurement by assessing third-party security frameworks against industry standards such as ISO 27001 or SOC 2.

• Cybersecurity Provisions in Contracts: Integrate specific security mandates into vendor agreements, including strict timelines for incident notification, persistent audit rights, and clear liability terms.

• Hardware Provenance and Verification: Use supply chain tracing to confirm the integrity of components, establish methods for detecting counterfeit items, and secure the logistics of repairs and replacements.

Security Architecture and Engineering Controls

Identity and Access Management

• Automated System and Workload Identities: Transition third-party integrations and build-system processes away from static, long-lived administrative Personal Access Tokens (PATs). Instead, mandate the use of dedicated GitHub Apps or short-lived system tokens via federated OpenID Connect (OIDC) for automated machine integrations. This ensures that credentials used by system-to-system workflows expire in a matter of minutes, neutralizing the risk of a persistent compromise if an automation pipeline is breached.

• Developer and User Identity Controls (command-line interface (CLI) and Repository Access): Enforce strict access control boundaries for programmatic developer sessions. Because Okta-linked SAML SSO is only capable of verifying identity during the initial creation or authorization of personal tokens and keys, continuous session state cannot be challenged over programmatic CLI connections. Therefore, session security must be enforced through credential expiration and hardware-backed controls.

• Enforce Strict Token Expiration: Strictly limit the allowable lifespan of all personal access tokens (PATs) and programmatic application programming interface (API) keys to a minimum threshold (e.g.a maximum 7-day limit). This guarantees that credentials expire regularly, forcing developers to re-authenticate through the primary SSO gateway.

• Consider Restricting Personal Access Tokens to Neutralize Git-over-HTTPS & Mandate FIDO2 Secure Shell (SSH): To protect developer environments against credential theft, organizations should consider restricting Personal Access Tokens (PATs) globally across GitHub Enterprise Cloud. Because GHEC has no direct protocol-disable switch, administrators should consider disabling classic PATs and enforcing short token lifespans to effectively block unauthorized programmatic HTTPS connections. This protocol containment helps encourage developers to shift entirely to SSH authentication. To secure this transport layer, consider mandating the use of hardware-backed FIDO2 security keys to cryptographically verify physical token possession for all command-line repository actions.

• Isolated CI/CD Execution: Utilize ephemeral runners for build pipelines that are purged immediately after completing a single task. This prevents malicious actors from maintaining a persistent presence between different build phases.

• Workflow Trigger Governance (pull_request_target): Strictly limit and secure the use of highly privileged triggers such as pull_request_target in automated environments. Multiple prominent supply chain campaigns have actively exploited vulnerable workflows using this trigger as their initial entry vector.

Infrastructure Protection

• Zero Trust and Least Privilege: Maintain rigorous control over managed service providers (MSPs) and third-party vendors by enforcing role-based access control (RBAC), multifactor authentication (MFA), and frequent audits of access rights.

• Network Micro-Segmentation: Segregate vital hardware and software from the rest of the enterprise network. Use allow-list-only firewall rules to block unauthorized outbound traffic and disrupt command-and-control (C2) activities.

Secure Development Ecosystems

• Pipeline and Sandbox Isolation: Ensure that testing environments, CI/CD pipelines, and informal scripting sandboxes are physically or logically isolated from production assets.

• Artifact Management: To secure the supply chain, organizations can integrate Google's Assured Open Source Software into their internal workflows to defend against dependency confusion and malicious hijacking. This process provides "provenance" cryptographically signed evidence that the code has not been tampered with and originates from a verified source thereby establishing a higher level of trust for third-party dependencies.

• Quarantine Gates: Require all binaries, packages, and container images to be hosted in monitored internal repositories. To defend against zero-day dependency hijackings, implement localized "quarantine gates" by enforcing cooling windows on newly published third-party assets.

• Lifecycle Script Sandboxing (ignore-scripts): Mitigate the critical threat of arbitrary code execution by disabling the automatic running of package install scripts. Attackers commonly hijack dependencies and add malicious post-installation execution scripts to steal credentials from developer environments and runners during routine installs. Organizations should mandate ignore-scripts=true in their repository-level .npmrc files and configure native allowlists, such as pnpm's onlyBuiltDependencies, to restrict execution exclusively to verified, essential tools.

• Software Composition Analysis (SCA) with Google OSV-Scanner: Integrate Google's open source OSV-Scanner tool into CI/CD build pipelines to continuously scan project dependencies for known security flaws. This tool provides an officially supported frontend to the OSV.dev database that maps a project's list of dependencies with the specific vulnerabilities affecting them.

• High-Fidelity Vulnerability Detection: Unlike traditional scanners that rely on imprecise name matching, the OSV schema stores vulnerability data in a machine-readable format that maps unambiguously onto version ranges and commit hashes. This results in fewer false positives and produces highly actionable remediation notifications, significantly reducing development team triage overhead.

• Authoritative & Collaborative Threat Intel: The underlying OSV.dev database aggregates high-quality threat intelligence from authoritative open sources, allowing the broader developer community to suggest continuous improvements. Utilizing OSV-Scanner helps developers identify impactful third-party open source vulnerabilities in their applications and focus remediation on genuine risks.

• Hardware-Backed Key Protection: Secure code-signing certificates using Hardware Security Modules (HSMs) or vaulting solutions. Monitor public transparency ledgers and logs to detect any unauthorized certificate activity.

• Hardened Distribution Points: Audit and lock down software delivery channels, such as Content Delivery Network (CDN) endpoints and FTP servers, to ensure legitimate binaries cannot be replaced by compromised payloads.

• Audit NPM Package Maintainer Accounts for Stale or Expired Recovery Email Domains: Expired maintainer email domains are a critical risk because attackers can purchase them to intercept password reset emails, take over the package registry account, and publish malicious code to downstream users. To identify vulnerable packages, organizations can perform the following:

• Deploy automated scanning tools to audit the entire dependency tree and verify the domain name system (DNS) resolution and registration status of all maintainer email domains.

• For defense-in-depth, pipelines must disable package execution scripts and employ cold periods.

• Use by default ephemeral, single-use runners to prevent compromised packages from accessing persistent build environments. 

• Isolate runners in a restricted network segment with strict egress filtering blocks any unauthorized connection to external domains even if an active exploit is triggered.

Integration with Native Ecosystem Guardrails    

• These organization-controlled quarantine policies must operate in conjunction with native platform-level security updates to achieve a Defense-in-Depth posture. Relying solely on client-side configurations or automated update tools in isolation creates single points of failure. The following native platform controls must be orchestrated alongside standard controls:

• Dependabot Native Cooldowns (July 2026): Dependabot now enforces a default three-day cooldown on version updates to allow for the public discovery of upstream compromises (such as the historical chalk and debug hijackings) before automated Pull Requests are generated].

• PyPI Server-Side Immutability (July 2026)]: PyPI now natively rejects new file uploads to any release older than 14 days. This prevents adversaries possessing compromised tokens from retroactively poisoning legacy, pinned dependencies (as observed in the LiteLLM and Telnyx compromises) .

• npm v12 Install-Time Defaults (July 2026): npm v12 disables all lifecycle scripts by default (allowScripts: off) , replacing manual, workflow-level ignore flags with explicit, commit-verified package allow-lists 

By explicitly aligning baseline configurations including .npmrc and pip.conf registry pinning, immutable installation protocols via npm ci, and runner isolation with these native platform-level guardrails, while committing to the continuous evaluation and adoption of new upstream security features as they are released, the organization establishes a resilient, multi-layered security boundary across the entire software supply chain

Continuous Verification, Monitoring, and Response

Automated Ingestion and Validation

• Automate SBOM Management: Implement a Software Bill of Materials (SBOM) for all third-party and internal software. This enables continuous monitoring for emerging vulnerabilities like Log4j through automated cross-referencing. Automate and scale this process by feeding SBOMs into central vulnerability management platforms that continuously cross-reference deployed inventory against newly disclosed exploits.

• Security Analysis Integration: Incorporate automated dynamic application security testing (DAST) and static application security testing (SAST) tools within development pipelines to identify and block compromised third-party code before it is compiled.

• Verification of Cryptographic Integrity: Prior to installing updates, use automated systems to validate digital signatures and hashes against vendor-provided specifications.

• Implement autonomous security verification: Organizations should look to integrate advanced security workflows directly into their CI/CD pipelines. These systems can behaviorally evaluate threats by executing simulations in isolated sandboxes, cross-reference those flags with cloud context to determine a flaw's actual reach, and automatically generate tested code patches to rapidly remediate verified risks at scale.

Proactive Threat Hunting and Monitoring

• Egress and Proxy Analysis: Establish network traffic baselines to identify suspicious egress flows to external repositories or unrecognized Internet Protocol (IP) addresses.

• Comprehensive Endpoint Security: Utilize endpoint detection and response (EDR) tools across infrastructure and developer workstations to detect post-execution malicious activities from supply chain compromises.

• Log Aggregation and Alerting: Unified log management should alert on the following anomalies:

• Development Systems: Watch for unauthorized code changes, build parameter adjustments, or irregular user activity.

• CI/CD Integrity: Alert on unauthorized workflow modifications or anomalous triggers (e.g., repository_dispatch) that bypass standard code-review gates.

• Injection Detection: Monitor logs for shell-escape characters or command-substitution patterns within untrusted input variables.

• Credential Misuse: Track authentication hits on long-lived static keys from unrecognized IP addresses or regions.

• Physical Assets: Record all firmware modifications, including installation status and source information.

Incident Response Strategies

• Specific Supply Chain Playbooks: Perform tabletop exercises and document response plans for:

  • Upstream Package Takeover: Maintainer account takeover (ATO) on public registries leading to direct runtime application code manipulation

  • Dependency Confusion Exploits: Malicious registration of lapsed administrative recovery domains or unscoped internal namespaces on public registries to hijack local developer and build runner installations.

  • Automated Pipeline Harvesting: Pipeline poisoning of CI/CD environments via runner exploitation to harvest credentials and perform unauthorized package publication.

  • Developer Workstation & IDE Compromise: Targeted social engineering, malicious IDE extensions, or typosquatted local dependencies designed to exfiltrate private cryptographic keys, API tokens, and local session credentials.

• Operational Re-evaluation: Create processes for immediate vendor re-mapping and security re-assessment during industry-wide security events.

Recommendations for mitigation strategies are also available publicly via:

• Google's Supply-chain Levels for Software Artifacts (SLSA) 

• Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations (NIST SP 800-161 Rev. 1) from the US National Institute of Standards and Technology (NIST)

• Securing the Software Supply Chain: Recommended Practices Guide for Developers from the US National Security Agency (NSA)

• WIZ SDLC Infrastructure Threat Framework (SITF) SDLC Infrastructure Threat Framework

Acknowledgements

This analysis would not have been possible without the assistance of Matthew McWhirt and Michael Veal.

Update (July 30): A table listing the new names of select prominent threat actors was appended to this post. 

Introduction 

Today, Google Threat Intelligence Group (GTIG) will begin rolling out a unified naming schema for tracking threat actors. This new naming taxonomy represents an effort to standardize tracking across platforms and public reporting.

Why are we Adopting a Different Naming System?

Historically, Mandiant and Google’s Threat Analysis Group (TAG) maintained distinct tracking systems, relying on parallel naming schemas that grew independently over time. The creation of GTIG has necessitated a new, fused tracking system, and a new naming system. Thinking to the future, GTIG’s new system will rely on cryptonyms. Relying on sequential numbers or disparate identifiers (e.g. APT1) fails to provide defenders the critical context needed to operate quickly. Threat tracking shouldn’t be an exercise in memorization, but rather one of intuition. The new naming convention aligns with industry standard threat actor naming systems. 

Our New Schema

Our new schema utilizes a cryptonym-based approach, employing memorable two-word combinations for each distinct threat actor:

• The first word is a unique and memorable term chosen to represent the specific actor, particularly names that may have been used in prior public reporting. If no previously used term exists, this word is randomly generated to remove bias, then vetted by our analysts.

• The second word categorizes threat clusters by motivation, attribution, or activity type based on which category we consider to be most important for defense and response strategies.

The table below provides a sample of how threat actor categories will map to the second word in each cryptonym:

Table 1: Examples of Google’s new threat actor naming system categories

We know there are many threat actor tracking schemas in the industry, so we are intentionally seeking to keep this system as simple as possible to streamline operations and facilitate mapping to other naming taxonomies. However, a significant caveat remains: because no two organizations have the exact same visibility into the threat landscape, direct, apples-to-apples comparisons between threat actors are rarely possible. Transitioning to a convention that is simpler to follow and remember is a practical step toward managing a highly intricate tracking problem. 

A Work in Progress

We have initially prioritized renaming several dozen of the most active groups, and will continue this process on a rolling basis. Previous names will remain indexed and searchable in the Google Threat Intelligence (GTI) platform, with MITRE ATT&CK mappings and other vendor aliases preserved, see Figure 1. 

We will continue to use UNC, or “uncategorized” designations for threat clusters that are still in the early stages of investigation, as described here.

Selection of Re-Named Threat Actors

Table 2: Selection of Re-named Threat Actors

Written by: Jules Czarniak

Introduction 

As highlighted in the Mandiant M-Trends 2026 report, the mean time-to-exploit (TTE) has dropped to -7 days, meaning vulnerabilities are often exploited a week before a patch even exists. 

To keep pace, many security teams are exploring how to integrate large language model (LLM) agents into their codebases, development environments and continuous integration and continuous delivery (CI/CD) pipelines for automated vulnerability discovery and remediation. However, deploying privileged artificial intelligence (AI) agents without mature integration processes introduces new architectural risks. 

In response to customer inquiries about how to safely integrate AI capabilities into vulnerability management workflows, this blog provides actionable guidance from Mandiant Consulting about how to establish operational guardrails for AI assisted vulnerability management, including several detailed scenarios. What each of these examples show is that security teams can accelerate workflows with AI while also upholding the structural integrity of their environments. We suggest that combining AI capabilities with deterministic controls and human intelligence in strategic ways maximizes benefits and reduces risk. 

Establish Operational Guardrails to Safely Deploy AI Agents

To safely adopt advanced AI capabilities without introducing unpredictable failures into deployment pipelines, organizations should ground their approach in established industry standards. While guidelines like the NIST AI Risk Management Framework (RMF) and the OWASP Top 10 for LLMs provide comprehensive baselines for identifying risks, operationalizing these controls requires a structural blueprint.

Frameworks like Google’s Secure AI Framework (SAIF) and Google’s approach to secure AI Agents provide a practical path forward, demanding that organizations extend existing deterministic controls directly into the AI execution environment. When deploying AI agents, security teams should navigate specific operational and structural risks:

• Pre-agent data security and Defense-in-Depth: Agents should not be able to access personally identifiable information (PII), protected health information (PHI), or other sensitive data. Organizations should enforce data security before the prompt reaches the model. This includes strictly using non-production environments populated with synthetic data for testing. For production, security teams should deploy a hybrid defense-in-depth model. This includes Layer 1 deterministic policy engines acting as chokepoints, alongside Layer 2 reasoning-based defenses like specialized guard models (such as Model Armor or similar provider-agnostic guardrails) to filter out sensitive data and block malicious prompt injections before they reach the agent layer. Crucially for vulnerability discovery, security teams should treat the codebase itself as an untrusted input. Threat actors can embed indirect prompt injections within source code comments or third-party dependencies (e.g., hidden instructions telling the agent to ignore vulnerabilities or exfiltrate environment variables), making input sanitation a requirement even for internal scanning.

• Cloud provider limitations and zero data retention (ZDR): Many cloud and LLM providers block or throttle automated offensive security probing by default to prevent abuse. Organizations should establish clear rules of engagement and authorized testing agreements to navigate acceptable use policies. Furthermore, organizations should enforce strict zero data retention (ZDR) agreements with their LLM providers to guarantee that proprietary code and discovered vulnerabilities are never used to train external models.

• Workload isolation: Agent workloads should execute in strictly isolated, unprivileged containers with dynamically limited privileges. By relying on robust sandboxing to prevent privilege escalation, if an agent hallucinates a destructive command or is hijacked via prompt injection, the blast radius remains contained.

• Red Teaming: Before deploying autonomous vulnerability scanners that can dynamically spin up sandboxes and execute code, organizations should subject the AI agents themselves to human-led red teaming as part of comprehensive assurance efforts. This validates the agent's resilience against jailbreaks, recursive logic loops, and complex prompt injections, ensuring the security tooling does not become the attack vector.

• Least-Privileged Machine Identities and Human Controllers: While workloads should be isolated, agents inherently require privileges to generate pull requests and commit code. Security teams should ensure these agents operate under distinct, strictly scoped machine identities that tie back to human controllers to ensure accountability and user consent. Organizations should use short-lived, just-in-time (JIT) tokens bound exclusively to the specific repository and branch under review. This enforces the principle of limited agent powers and ensures that even if an agent’s container is compromised via prompt injection, the threat actor cannot pivot to modify adjacent enterprise codebases.

• Supply chain resilience for skills: As developers augment AI with third-party skills and model context protocol (MCP) servers, security teams should treat these integrations as untrusted supply chain components. MCP plugins introduce the risk of supply chain poisoning, where a previously benign integration is silently updated with malicious dependencies. Additionally, security teams should evaluate the underlying agent orchestration frameworks themselves (e.g., LangChain, AutoGen) for inherent vulnerabilities, such as session memory poisoning or recursive loop hijacking.

• Toxic flow analysis (TFA) and Observable Actions: The objective of TFA is to monitor data paths at runtime, ensuring agents do not exfiltrate sensitive internal context to unvetted external endpoints. Agent actions, inputs, reasoning, and outputs must be fully observable and transparently logged. While implementing dynamic taint tracking for LLMs remains a complex architectural challenge, organizations should clearly separate this runtime observability from static supply chain controls. Integrating threat intelligence to hash and vet incoming agent tools provides a necessary baseline for verifying integrity before deployment. However, because static controls cannot address behavior post-deployment, mitigating data exfiltration ultimately requires active runtime monitoring and secure, centralized logging to trace and restrict the actual flow of data.

By operationalizing these tools within frameworks that demand verifiable integrity and structural resilience, organizations can safely bridge the gap between AI velocity and enterprise defense.

The need for human-led threat modeling

While LLMs excel at identifying syntax patterns, source code itself rarely contains the full picture of unwritten business intent. Some organizations attempt to solve this by connecting LLM agents to internal wikis, design documents, and issue trackers using retrieval-augmented generation (RAG).

While RAG gives the model access to external business context, it is not a perfect fix. Corporate documentation is frequently stale, contradictory, or incomplete. An AI agent might retrieve an outdated architecture diagram and confidently hallucinate a secure path that no longer exists in production. Because LLM agents struggle to resolve conflicting, undocumented human assumptions, human-led threat modeling remains a critical security control across both legacy applications and modern agent workflows.

Security teams should apply threat modeling during both the pre-build system design phase to establish a secure foundation, and during post-build architecture reviews. While an AI agent might successfully identify a poorly configured internal endpoint locally, a human threat modeler asks the structural question: why does that microservice possess broad database read permissions in the first place? 

Identifying architectural vulnerabilities requires reasoning about business risk, data sensitivity, and operational constraints. To structure this process, organizations can use industry frameworks like PASTA (Process for Attack Simulation and Threat Analysis) or service offerings like the Mandiant Threat Modeling Security Service to map trust boundaries, uncover structural design flaws, and prioritize compensating controls. Securing fundamental architecture through human oversight is a necessary component when relying on automated agents to find bugs in a poorly designed system.

Once these AI agents are safely sandboxed, as guided by SAIF, and the architecture is verified through threat modeling, organizations can typically apply them to two different problem spaces: Enterprise Vulnerability Management (to assist in managing the volume of known CVEs in commercial off-the-shelf (COTS) software and infrastructure) and Product Security (to identify vulnerabilities in 1st-party (1P) code).

Track 1: Enterprise Vulnerability Management

Foundational security and discovery 

While the second track of this post explores how AI agents can uncover complex zero-days in custom code, organizations should manage the scale of enterprise infrastructure in tandem with these AI deployments. Even as new AI capabilities dominate headlines, organizations should still address foundational security challenges, such as secrets sprawl, unmanaged service accounts, missing FIDO2 MFA, and legacy VPN concentrators. Although vulnerability exploitation was the primary initial infection vector in intrusions Mandiant investigated last year, threat actors consistently rely on missing foundational controls and unpatched edge devices to secure and escalate their foothold after exploiting a vulnerability.

Furthermore, AI cannot replace foundational visibility. As security teams deploy AI agents, they should simultaneously close these tactical entry points by maximizing dynamic discovery capabilities like External Attack Surface Management (EASM), Cloud Security Posture Management (CSPM), and Continuous Threat Exposure Management (CTEM). In hybrid and cloud environments, tools like Wiz can be used to map this initial footprint.

Risk-based vulnerability management 

Vulnerability management teams are already overwhelmed by the current volume of findings generated by traditional scanners. As organizations scale dynamic discovery tools, such as EASM, CSPM and CTEM, alongside automated AI agents, this influx of findings will compound the problem. To manage this influx, telemetry from these diverse discovery methods must first be normalized and deduplicated. This normalized data serves two purposes: it feeds directly into the risk engine, and it acts as a live overlay to correct stale records in the configuration management database (CMDB). By evaluating the deduplicated vulnerabilities alongside this newly updated asset context and frontline threat intelligence, the RBVM engine calculates a custom risk score that allows security teams to dynamically prioritize remediation.

A mature RBVM methodology calculates a customized risk score on a 0 to 100 scale using a weighted average. A sample formula for calculating this risk-based score is:

Final Score = (W_1 * S_vuln) + (W_2 * S_asset) + (W_3 * S_threat)

The variables and weights (W) are customized to the organization's risk appetite (for example, 0.20 for vulnerability, 0.40 for asset, and 0.40 for threat, summing to 1.0), while the underlying variables (S) are scored on a 0 to 100 scale and defined as follows:

• Vulnerability severity (S_vuln): The inherent technical severity of the flaw. This is calculated by taking the CVSS Base Score (which natively accounts for confidentiality, integrity, and availability impact) and multiplying it by 10.

• Asset context (S_asset): A combined metric of exposure and data sensitivity. Scores range from 100 for internet-facing assets holding customer data, down to 25 for internal-only assets with no sensitive data. To translate this impact into monetary terms for non-technical stakeholders, organizations can incorporate Factor Analysis of Information Risk (FAIR) principles into this metric. However, this approach requires highly accurate, continuously updated financial data that many enterprises struggle to maintain at scale.

• Threat context (S_threat): The real-world urgency of the vulnerability. Scores range from 100 if actively exploited by threat actors relevant to the organization's profile, 75 if a proof-of-concept exists or if it is a vulnerability class easily exploited by autonomous AI agents, down to 25 if the exploit is theoretical and highly complex. Organizations should also map the Exploit Prediction Scoring System (EPSS) probability percentage directly into this variable. This allows the threat score to automatically scale up or down as real-world exploitation telemetry shifts, aligning static vulnerability data with active threat intelligence.

An asset's customized risk score should directly influence internal remediation service-level agreements (SLAs), unless external compliance-driven mandates, such as CISA Binding Operational Directives (BODs), or relevant equivalents, override internal prioritization. A risk-driven and threat-intelligence-driven vulnerability prioritization methodology will help organizations focus resources on managing and mitigating the most critical security vulnerabilities first. This is an area where LLMs can support the vulnerability management process, particularly by helping teams synthesize unstructured threat intelligence to surface relevant risk contexts more efficiently. Enforcing strict SLOs for patching, while requiring formal risk acceptance documentation for any patching exceptions, will help reduce the number of vulnerabilities available to threat actors and increase the visibility of outstanding risks across the organization. Furthermore, organizations should integrate RBVM data directly into their security orchestration, automation, and response (SOAR) platforms for automated alert enrichment.

Containment and Observability

Modern architecture blueprints must prioritize attack surface reduction under the assumption that vulnerabilities will inevitably be exploited. Moving away from traditional perimeter defenses, organizations should align with zero trust principles, ensuring that security boundaries are established around every asset, workload, and identity.

A component of this alignment is the implementation of strong authentication principles. Organizations should eliminate implicit trust by enforcing continuous, context-aware authentication and authorization. Utilizing Zero Trust Network Access (ZTNA) solutions, such as Identity-Aware Proxies (IAP), shields critical management interfaces (e.g., SSH, RDP) and internal systems from direct internet exposure, granting access only to verified identities and compliant devices.

For public-facing applications and APIs, attack surface reduction involves deploying Layer 7 inspection at the load balancer or API gateway level. This hardening layer enforces strict schema validation, intercepting and neutralizing malformed inbound traffic and potential exploits before they can interact with internal application logic.

Securing the software supply chain is equally vital in modern blueprints, and organizations should align with frameworks like Supply-chain Levels for Software Artifacts (SLSA) across both dependency and build tracks. Security policies should mandate that third-party dependencies are routed through a centralized artifact repository equipped with automated curation services, such as Google Assured Open Source Software (OSS) or an equivalent solution, preventing untrusted code from entering the development lifecycle. Furthermore, maturing toward advanced SLSA build levels (e.g., SLSA level 3) through the implementation of isolation, ephemerality and reproducibility requirements via  ephemeral compute infrastructure for CI/CD runners reduces the likelihood of attacker persistence by ensuring environments are short-lived and automatically cycled.

To complement these pre-build controls, runtime observability should be established across all production workloads. This requires monitoring both infrastructure-level behavior and the specific runtime libraries actively executing in production, which surfaces true exploitable risk far beyond a static Software Bill of Materials. In tandem with monitoring workloads, organizations should secure how they authenticate by implementing workload identity federation. By removing static credentials and instead using short-lived tokens backed by strong cryptographic identity verification, organizations can reduce the risk of credential theft and unauthorized lateral movement.

Within the internal environment, microsegmentation should be enforced to break down flat networks into granular security zones. Routing application traffic through a Secure Access Service Edge (SASE) architecture integrates network routing directly with robust identity controls, rendering internal services completely invisible to unauthenticated users and containing threats to their initial point of entry.

Finally, automated containment and incident response within a zero trust framework must rely on deterministic, auditable tooling. Endpoint detection and response (EDR) platforms and SOAR playbooks should handle high-fidelity containment tasks through hardcoded execution logic. While AI tools accelerate triage and policy recommendation, actual execution capabilities must remain restricted to well-defined, pre-tested workflows to maintain total architectural predictability.

Track 2: Product Security & Development (1P Code)

Deterministic and probabilistic tooling

Integrating LLM agents into vulnerability management and security workflows requires recognizing the differences between deterministic and probabilistic tooling. Traditional SAST and DAST tools utilize fixed methodologies to evaluate vulnerabilities through structural code parsing or definitive runtime observations. LLMs, however, evaluate source code by processing tokens simultaneously to calculate statistical and semantic relationships, rather than tracing deterministic execution tracks.

While techniques like Chain of Thought (CoT) prompting allow models to bridge this gap by decomposing complex code paths into intermediate reasoning steps, this process remains bounded by architectural limitations. Even when a model possesses a context window large enough to ingest entire repositories, it may experience attention degradation across long inputs, often failing to correctly weight intervening validation or sanitization logic within the prompt. For example, if a variable is tainted on line 10 but sanitized on line 500, attention degradation can cause the model to lose track of the sanitization logic. Furthermore, when enterprise codebases require chunking to fit within context limits, the resulting fragmentation may cause the model to lose track of end-to-end data flows.

Consequently, probabilistic engines are effective at uncovering localized, static anomalies, such as hardcoded credentials or outdated dependencies, but frequently misjudge complex vulnerabilities split across fragmented chunks or extended context windows. Notable exceptions occur when these probabilistic models are coupled with deterministic feedback loops. For instance, when analyzing C++ memory corruption, an LLM can be equipped with a test harness to iteratively execute code and definitively prove a crash. While these dynamic validation applications are detailed in subsequent sections, the baseline limitation for static analysis across standard enterprise codebases remains: models struggle to consistently evaluate dispersed logic.

Binary and architectural oracles

Many security programs are moving toward agent workflows where an agent autonomously spins up a test environment and uses tools to execute payloads and verify its findings. This is a promising approach, but it is important to understand where it is most effective.

Agent workflows perform well against bug classes with binary and observable oracles, meaning the system provides an objective, 'crash or no crash' feedback loop. For example, if a model is hunting for memory corruption in a C++ kernel, a successful exploit is undeniable: the payload executes, and a resulting crash definitively proves the vulnerability. This explains why the industry is currently seeing a surge in AI-discovered vulnerabilities across memory-unsafe targets like web browsers and operating systems.

However, enterprise software is heavily dominated by vulnerabilities that require architectural oracles for validation. Vulnerabilities like authorization bypasses, complex business logic flaws, and indirect server-side request forgeries require an understanding of business context and cross-service trust boundaries. If an agent's payload fails to produce a clear outcome, it can't reliably distinguish whether the vulnerability is a hallucination or if it simply constructed the payload incorrectly. An agent's malformed payload might even crash an unrelated background process and cause the model to hallucinate a success and report a false confirmation. Complex enterprise architecture contains unwritten business intent that a probabilistic engine can't inherently know.

Targeted deployment and human impact

Organizations adopting LLMs for vulnerability discovery face a massive staffing challenge. LLMs can generate findings significantly faster than human engineers can triage them. If every LLM-generated alert requires manual review, security teams will quickly face burnout and/or suffer alarm fatigue.

Rather than indiscriminately pointing agents at all available codebases and risking an influx of unverified output, security teams need a selective deployment strategy. Mature programs should maintain SAST and DAST for baseline hygiene and deterministic rule enforcement, and reserve intensive agent audits for high-impact components with clear binary oracles.

Organizations can prioritize agent audits on systems where the technology's strengths align with the broader risk profile:

• Memory-unsafe codebases: Legacy or high-performance components written in memory-unsafe languages such as C, C++, or Assembly are strong candidates for LLM audits. These languages are susceptible to memory corruption flaws, such as buffer overflows and use-after-free conditions. Because these vulnerabilities trigger definitive failure states like segmentation faults, they work well with automated sandboxes where agents can compile the code with memory sanitizers and write proof-of-concept inputs. This approach is also effective for auditing the native extensions where safe languages call unsafe internal libraries, such as Python C extensions or the Java Native Interface (JNI).

• Systems highly exposed to outside content: First-party data ingestion pipelines, custom API gateways, or proprietary edge proxies. A prerequisite here is direct access to the source code, this strategy is strictly for internally developed or fully open-source codebases where the organization can inspect the logic. Because these systems directly parse untrusted internet traffic, targeting their source code for LLM-driven audits yields the highest risk-reduction ROI.

• Shared internal libraries and utilities: Core serialization/deserialization packages, common utility functions, and custom middleware wrappers (such as internal message-queue parsers) maintained in-house. Because the enterprise owns the source code for these shared building blocks, agent tools can easily hook into them within automated test harnesses to fuzz inputs and catch low-level logic or parsing bugs with high fidelity.

• Foundational security boundaries: Internally developed centralized authentication services, custom OAuth providers, and internal credential brokers. While testing complex identity boundaries generates higher logic-based noise, having full access to the source code allows teams to pair agents with deterministic checks to safely triage findings, given that the blast radius of an authentication failure justifies the human effort.

To filter the noise generated by LLMs, organizations should establish routing rules. Require the agent to generate a fully reproducible, deterministic test harness (such as a compiled binary or a Python test script) that attempts to prove the exploit. This harness must execute automatically in an isolated, monitored sandbox. If the sandbox execution fails (due to a syntax error or a failed exploit), the ticket is discarded, sparing human resources. However, organizations should enforce execution timeouts and iteration limits on these test harnesses. Without hard limits, an autonomous agent attempting to prove a vulnerability can fall into an infinite loop: writing a script, failing, rewriting, and failing again, exhausting API token budgets and compute resources against a single dead-end vulnerability, creating significant cost overruns without advancing the security review. To manage these expenses, organizations should incorporate FinOps principles to balance the compute and API costs of LLM audits against the traditional expenses of manual triage.

However, a successful execution in the sandbox does not guarantee an actionable, high-priority risk. In practice, autonomous agents frequently produce working PoCs for genuine technical flaws that are ultimately irrelevant; or warrant a lower remediation priority within the context of the system's threat model. For example, the agent might successfully exploit an unreachable dead-code path, or trigger a bug that requires administrative access to execute and yields no further escalation of privilege. Therefore, a human engineer should be assigned to review and prioritize the ticket only if the sandbox registers a successful execution, validating environmental context, reachability, and true business impact as part of the review.

This workflow reduces the volume of alerts, but it is important to understand that the security team's workload does not disappear. The engineer's primary job shifts from manually hunting for the initial vulnerability to auditing the LLM-generated proof to ensure it represents a meaningful risk rather than an unexploitable or contextually irrelevant finding. Leadership should properly staff and train teams for this new reality. Deploying LLM agents does not remove the need for skilled practitioners; it redirects their workload toward complex validation. Equally important is training teams to recognize the risk of false negatives. A hyper-focus on filtering AI-generated noise can create a false sense of security. If an exploit relies on a novel technique or a zero-day vulnerability that was not heavily weighted in the model's training data, the agent will likely scan right past it in silence. LLMs augment discovery, but they do not guarantee exhaustive coverage.

When integrating LLMs into SAST triage pipelines, human engineers should also verify the broader architectural integrity. Prompting an LLM with specific SAST warnings can induce contextual narrowing, where the agent becomes hyper-fixated on resolving a localized syntax error and misses broader architectural flaws existing in the same file. Furthermore, if the agent's mandate extends beyond discovery to automated remediation (such as writing and proposing code fixes), this human-in-the-loop validation becomes critical to ensure the LLM does not inadvertently introduce new regressions or bypass intended business logic.

Remediation and hardening

LLM-assisted code remediation

A primary goal of integrating large language models (LLMs) into the software development lifecycle is automated remediation. To achieve this, organizations are deploying these capabilities through two primary execution methods: directly within the integrated development environment (IDE) or as a centralized pipeline runner. Examples include CodeMender, although as of time of writing, it is not publicly available.

IDE-integrated method 

This method shifts remediation as far left as possible by operating as an active pair-programmer. Tools running continuous static analysis in the background of the IDE surface vulnerabilities directly to the developer via editor diagnostics like inline indicators or hover tooltips.

• Localized scope: The developer can trigger the LLM agent to analyze the localized data flow and generate a targeted patch (such as implementing parameterized SQL queries). By constraining the LLM to localized, syntax-level fixes, the scope of the change remains contained. This prevents the agent from attempting sprawling, multi-file refactors that frequently break complex architectural logic.

• Human-in-the-loop: The developer reviews the AI-generated patch before the code is committed.

• Managing false positives: Local IDE agents allow developers to manage false positives dynamically. Suppressing alerts anchored to specific line text reduces alert fatigue and preserves developer trust.

CI/CD runner method 

The runner method executes asynchronously within the CI/CD pipeline to use an LLM to review committed code and automatically propose remediation.

• Restricted execution and deterministic validation: Asking a centralized runner to automatically rewrite a complex, multi-file authorization flaw directly in the main branch introduces a high risk of breaking logic errors. To mitigate this, agents must be restricted to generating pull requests (PRs). Once a PR is generated, it must automatically execute standard regression suites alongside the deterministic test harness. By rerunning the initial PoC against the patched code, the workflow repurposes the exploit script as a validation oracle to prove the vulnerability has been remediated. A human engineer then reviews the PR to validate the architectural logic before merging.

In all cases security teams should define a clear boundary between the two methods rather than rely on a single approach. IDE agents provide immediate, syntax-level support. They catch and resolve low-complexity errors locally before developers commit code. Centralized CI/CD runners handle broader organizational baselines. They propose complex, repository-wide fixes for vulnerabilities that bypass local environments.

Post-deployment controls 

Even with human review and deterministic test harnesses, AI-generated patches can still introduce logic regressions in production. Organizations should implement strict post-deployment controls:

• Automated rollbacks: Treating LLM-generated code with the same post-deployment scrutiny as any major architectural change ensures that if an unforeseen regression traverses the CI/CD pipeline, the environment can revert to a known good state.

• Mitigating model drift: Relying on managed AI services introduces the ongoing risk of model drift. To prevent silent weight updates from breaking test harnesses, organizations need to pin specific model API versions to frozen releases. When a pinned version reaches its end-of-life, organizations will face a forced migration. Mitigating this pipeline fragility requires combining model pinning with deterministic regression suites.

• Compliance and auditability: If an AI agent automatically closes a security ticket or generates a patch in the CI/CD pipeline, organizations should maintain immutable audit logs to satisfy frameworks like SOC 2 ,PCI-DSS, FedRAMP, and CMMC. National security deployments must also account for data sovereignty requirements. This logging should record the specific model version that proposed the fix, the deterministic test results that validated it, and the human engineer who approved the merge. Furthermore, because emerging legislation like the EU AI Act emphasizes human oversight for high-risk applications, security teams should carefully evaluate how autonomous remediation workflows align with these evolving global regulatory standards.

Conclusion

Leveraging LLMs in vulnerability management is a multi-layer solution: Integrating it requires separating workflows by layer. At the enterprise infrastructure level, Risk-Based Vulnerability Management (RBVM) and exposure management are necessary to process the volume of findings and configuration drift. At the product and code security level, LLM-enabled vulnerability assessment and remediation must operate alongside foundational deterministic controls, such as SAST and DAST, to audit custom, open-source, or third-party code.

Although LLMs can help manage technical debt and accelerate vulnerability discovery, they do not replace secure-by-design principles. The fact that LLM agents are proving exceptionally capable at identifying and exploiting localized memory corruption in memory-unsafe codebases, alongside other primary vectors, should serve as a wake-up call. 

As a long-term strategy aligned with NSA guidance on Software Memory Safety, organizations need to phase memory-safe languages into new internal development. LLMs are beginning to expand what is possible here by reducing the manual labor required for code migration. Converting existing C or C++ codebases to Rust has historically been unrealistic due to the large volume of engineering hours needed. While fully automated translation is not a turn-key solution, using LLMs to assist engineers with the bulk of the conversion can make these long-term migrations operationally viable. Beyond internal efforts, organizations should use procurement requirements to incentivize vendors to reduce their reliance on memory-unsafe languages and establish secure configuration defaults over time. Bridging the gap between AI velocity and enterprise defense means building an automated pipeline to manage the current backlog, while architecting systems where entire classes of vulnerabilities and misconfigurations are eliminated by design.

Acknowledgements

This analysis would not have been possible without the assistance of Google Threat Intelligence Group (GTIG) and other broader Google teams.

Written by: Corné de Jong

Introduction 

Mandiant security assessments frequently identify publicly exposed serverless applications that lack authentication, often as a result of specific business requirements. Serverless deployments typically run custom-developed code that incorporates third-party packages, making them targets for a wide range of application-level attacks, including:

• Local and Remote File Inclusion (LFI/RFI)

• Command Injection

Successful exploitation of these vulnerabilities can grant an attacker full control over the underlying container instance. Such access can serve as a foothold that may ultimately lead to a full compromise of the victim’s cloud environment.

Based on lessons learned in customer engagements, in this blog post we describe attack scenarios and provide actionable guidance on how to secure serverless environments. While this analysis focuses on hardening strategies for Google Cloud Run services and functions that must remain publicly accessible, these principles apply universally to any public serverless deployment.

What are Serverless Applications?

Serverless applications, also described as Function-as-a-Service (FaaS), allow the deployment of individual blocks of code as microservices within a flexible, decoupled, and event-driven cloud architecture without the need to manage underlying infrastructure. These services enable applications and automations to scale automatically and deploy instantly, removing operational overhead. Serverless services underpin major e-commerce, media, payment processing applications, and AI usage. 

The rapid expansion of generative AI adoption is a significant driver of increased serverless architecture use. AI workflows, including chatbot interactions, image generation, “vibe-coding”, and multi-step AI agents rely on serverless functions to complete tasks for users. This growth has made securing serverless environments a more pressing challenge for enterprise security teams. 

Risks of Serverless Application Attacks

Publicly exposed serverless workloads can serve as an initial access point for threat actors. As noted, these services may contain vulnerabilities within the code, imported packages, or the underlying runtime environment.

Once an entry point is exploited, attackers typically attempt to escalate privileges or move laterally. Common techniques observed include:

• Extracting secrets stored directly within the application code.

• Reviewing application logic and sensitive data to identify further attack vectors within the environment.

• Exfiltrating service account bearer tokens from the metadata server following successful Remote Code Execution (RCE).

Leveraging these compromised secrets or service accounts allows threat actors to pivot to adjacent systems and workloads, potentially resulting in a total environment takeover if proper hardening strategies are not in place.

Example Attack Scenarios

The following simplified scenarios illustrate how serverless functions can be compromised and how attackers pivot after achieving initial code execution.

Local File Inclusion (LFI) 

In the following Cloud Run example, a Python/Flask function accepts user-controlled input to open a file without performing proper validation. This pattern is an example of a Local File Inclusion (LFI) vulnerability.

import functions_framework

@functions_framework.http
def hello_http(request):
    request_json = request.get_json(silent=True)
    request_args = request.args
    if request_json and 'file' in request_json:
        file = request_json['file']
    elif request_args and 'file' in request_args:
        file = request_args['file']
 
# VULNERABILITY: The 'file' parameter is used directly in open() 
# without validation, allowing arbitrary file access
    with open(file, 'r') as resp:
          filedata = resp.read()
    return 'local file data {}!'.format(filedata)

Figure 1: Vulnerable Python/Flask function accepting unvalidated user input to open files

This vulnerability allows an attacker to request sensitive files from the Cloud Run instance by using curl to send a POST request via the file parameter:

curl -X POST https://cloudrun01-abc.europe-west3.run.app/ -H "Content-Type: application/json" -d '{"file": "main.py"}'

Figure 2: curl POST request targeting the file parameter

The response provides the complete main.py source code. An attacker can analyze the code for:

• Hardcoded secrets such as API keys, database credentials, or authentication tokens

• Business logic flaws and additional injection points

• Internal service endpoints and architecture details

• Import statements revealing the technology stack and potential CVE exposure

Additionally, attackers can leverage standard ../ directory traversal sequences to retrieve sensitive system files:

curl -X POST https://cloudrun01-abc.europe-west3.run.app/ -H "Content-Type: application/json" -d '{"file": "../../../etc/passwd"}'

Figure 3: curl POST request leveraging directory traversal sequences

An LFI vulnerability allows an attacker to retrieve and fuzz various files directly from the container. Key examples include:

• requirements.txt, package.json, go.mod: Used to identify installed packages and versions with known vulnerabilities.

• .env files: Frequently contain sensitive environment variables or hard coded secrets.

• Application configuration files: May contain database credentials, API keys, or service endpoints if not securely managed.

• /etc/passwd, /proc/self/environ: Contains user information, environment variables.

• Application logs: may contain auth tokens or PII data.

Best Practice: Never store secrets or credentials within the source code or local container files. Utilize a dedicated secrets management solution, such as Secret Manager.

Code Execution/Command Injection

In the following scenario, a Python function uses shell execution methods with unsanitized user input, allowing an attacker to execute arbitrary commands.

import functions_framework
import subprocess


@functions_framework.http
def hello_http(request):
  request_json = request.get_json(silent=True)
  request_args = request.args
  if request_json and 'input' in request_json:
      input = request_json['input']
  elif request_args and 'input' in request_args:
      input = request_args['input']
  result = subprocess.run(input, shell=True,capture_output=True, text=True)
  return format(result)

Figure 4: Python function utilizing shell execution with unsanitized user input

This allows an attacker to execute a subsequent curl request targeting the GCP metadata service to retrieve the service account’s bearer token. 

The following request extracts the service account's OAuth 2.0 bearer token, which remains valid for 1 hour:

curl -X POST https://cloudrun02-abc.europe-west3.run.app/ -H "Content-Type: application/json" -d "{\"input\": \"curl 'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token' -H 'Metadata-Flavor: Google'\"}"

Figure 5: Extraction of a GCP service account bearer token via a curl request

Once obtained, an attacker can use it on an attacker-controlled system to execute Google Cloud CLI commands. For example the CLOUDSDK_AUTH_ACCESS_TOKEN environment variable can be set using the stolen bearer token.

export CLOUDSDK_AUTH_ACCESS_TOKEN=”obtain bearer token”

Figure 6: Defining CLOUDSDK_AUTH_ACCESS_TOKEN environment variable

Attackers can then leverage Google Cloud Cloud CLI within the security context of the Cloud Run Compute service account. If deployed without best practices and thoughtful configuration controls, for example, if the  Cloud Run service runs as the default compute service account with Editor permissions, this would be equivalent to a full GCP project takeover, and allow the attacker to:

• Read/write/delete most GCP resources

• Deploy new services and modify existing configurations

• Access secrets and encryption keys

• Exfiltrate data across all accessible storage systems

• Establish persistent backdoors through new service accounts or SSH keys.

Hardening Recommendations

Mandiant recommends that organizations implement parallel approaches for effective serverless security:

• Secure Software Development Lifecycle (S-SDLC): integrate security scanning, code review, least-privilege IAM into CI/CD pipelines before deployment and integrate continuous security testing; 

• Vibe Coding: Mandiant recommends multi-layered security enforcement for AI-generated code or "vibe coding." Organizations should isolate AI experimentation within dedicated sandbox environments and enforce strict data egress controls to protect production systems and internal data. Furthermore, development environments should be restricted to approved IDEs with human-in-the-loop capabilities, utilizing only verified plugins operating under least privilege to mitigate supply chain vulnerabilities. Finally, organizations must ensure this AI-generated software follows Secure Software Development Lifecycle (S-SDLC) controls while establishing clear internal guidelines regarding permitted use cases. Comprehensive security fundamentals for vibe coding are documented in detail within the Wiz Vibe Coding Security Fundamentals blog.

• Compensating Runtime Controls: Implement the following defense-in-depth measures to limit and contain compromise even when application vulnerabilities exist;

Segregate Public Services

Host public-facing Cloud Run services consumed by untrusted external entities in a dedicated, isolated Google Cloud project. This ensures a compromise does not provide an immediate path to critical internal resources. The implementation of this 'Service Project' model is beyond the scope of this post; however, it is documented in detail within the secured serverless architecture blueprint.

Identity and Access Management (IAM)

Mandiant recommends using a custom service account for service authentication rather than the default Compute Engine service account, following the principle of least privilege. Grant only the specific permissions necessary for the Cloud Run function to operate, for example:

• Cloud Storage Bucket Access: If the service only requires read access to objects from a Cloud Storage bucket, grant the Storage Object Viewer (roles/storage.objectViewer) role restricted to that specific bucket.

• Secret Manager Access:  If the service requires access to secrets, grant the Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) role only to the individual secrets required. For further details on secret access from Cloud Run, refer to the GCP documentation on configuring secrets.

Layer 7 Application Load Balancer (ALB) Architecture

Restrict ingress traffic for serverless functions to internal only and use an external Layer 7 ALB to manage internet exposure. This provides:

• Centralized Traffic Management: Granular control over headers and SSL policies.

• Cloud Armor Integration: Web Application Firewall (WAF) support to harden applications against vulnerabilities such as Local/Remote File Inclusion (LFI/RFI) and Server-Side Request Forgery (SSRF).

• Traffic Shaping: Implementation of rate limits and request limitations to prevent abuse.

• Enhanced Visibility: Robust logging and log-forwarding capabilities for security monitoring.

• Identity-Aware Proxy (IAP): integration support for scenarios requiring specific identity-based authentication for internal users.

Web Application Firewall (WAF) — Cloud Armor

Cloud Armor provides WAF protections that can be integrated with the Load Balancer to filter malicious traffic. The following examples demonstrate how to configure Cloud Armor security policies to block the specific local file inclusions, remote code execution and traversal attacks previously outlined.

Local File Inclusion

The lfi-v33-stable preconfigured WAF rules can block common local file inclusion attacks (local file inclusion reference).

evaluatePreconfiguredWaf('lfi-v33-stable', {'sensitivity': 3})

Figure 7: Cloud Armor lfi-v33-stable WAF rule configuration

Blocking a path traversal request ../../../etc/passwd resulting in a 403 forbidden:

curl -X POST https://exampleabc01.com -H "Content-Type: application/json" -d '{"file": "../../../etc/passwd}'
<!doctype html><meta charset="utf-8"><meta name=viewport content="width=device-width, initial-scale=1"><title>403</title>403 Forbidden

Figure 8: Verification of Cloud Armor blocking path traversal request, resulting in a 403 forbidden

Remote Code Execution

The rce-v33-stable preconfigured WAF rules can block remote code execution attempts (remote code execution reference).

evaluatePreconfiguredWaf('rce-v33-stable', {'sensitivity': 3})

Figure 9: Cloud Armor rce-v33-stable WAF rule configuration

Blocking the remote code execution request from the previous example results in a 403 forbidden:

curl -X POST https://exampleabc01.com -H "Contencurl -X POST https://exampleabc01.com -H "Content-Type: application/json" -d "{\"input\": \"curl 'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token' -H 'Metadata-Flavor: Google'\"}"
<!doctype html><meta charset="utf-8"><meta name=viewport content="width=device-width, initial-scale=1"><title>403</title>403 Forbidden

Figure 10: Verification of Cloud Armor blocking Remote Code execution, resulting in a 403 forbidden

Serverless Architecture Controls

Hardening Cloud Run services is only one part of a secure architecture. Because these services often connect to other Google Cloud resources, a single compromise can expose additional services. Implementing defense-in-depth is critical. Specifically, when using direct VPC egress or VPC Access connectors, use VPC Service Controls to restrict lateral movement and exfiltration through granular access policies.

Secure Software Development Lifecycle (S-SDLC)

While the previously outlined hardening strategies are critical, the ideal standard remains the proactive identification of vulnerabilities during the initial development stages. A deep dive into "Shift-Left" security is beyond the scope of this analysis, which focuses on mitigating risks within existing code. However, a Secure Software Development Lifecycle (S-SDLC) remains a fundamental principle. Robust code validation and continuous security testing are essential to neutralize threats before serverless functions are published externally.

Cloud Run Threat Detection

Beyond the hardening recommendations outlined in this post, Google Cloud Security Command Center (SCC) provides built-in services to detect control plane attacks against Cloud Run resources. These include detectors for credential access, reconnaissance, and the execution of scripts or reverse shells. The Cloud Run Threat Detection service is available for Premium and Enterprise tiers.

Conclusion

Serverless applications drive agility and rapid business value. While "vibe-coding" has made it easier than ever to deploy code, this breakneck speed demands that teams integrate security early in the development lifecycle, move beyond default configurations, and prioritize a defense-in-depth strategy centered on identity and architecture. 

Acknowledgements

This analysis would not have been possible without the assistance of Ischa Rijff, Phil Pearce, and Juraj Sucik.

Written by: Shebin Mathew

Introduction 

The "Golden SAML" technique, first described by CyberArk researchers in 2017, and further detailed by Mandiant researchers in 2021, remains one of the most effective methods for threat actors to forge identity assertions in the Microsoft ecosystem. By obtaining the private key of an ADFS token-signing certificate, an attacker can authenticate as any user to any SAML-federated application, bypassing multifactor authentication (MFA), conditional access, and all identity-based controls.

However, during a recent red team engagement, Mandiant discovered that when ADFS certificates are manually rotated, configuration drift can silently leave active signing keys exposed in Machine DPAPI. Specifically, Mandiant discovered that in environments where AutoCertificateRollover is disabled and certificates are manually rotated, the database often becomes a 'ghost'—a record that still exists, still decrypts successfully, but references a certificate no longer used for token signing by the ADFS service. This attack vector warrants attention because the underlying configuration is commonly deployed in enterprise environments. The technique avoids direct interaction with components such as LSASS and the live ADFS service process, which are often subject to enhanced monitoring in enterprise environments, and may therefore result in lower visibility depending on the organization’s telemetry coverage. This post details how adversaries may exploit this TTP to forge high-privilege SAML tokens and provides the blueprint to defend against it.

Technical Insight: Encountering the ‘Ghost Certificate’

Analysts followed the standard DKM extraction path, retrieving the encrypted blob from the WID database and decrypting it using the DKM material stored in Active Directory. The extraction succeeded, but the recovered certificate was no longer valid for token signing, and Entra ID rejected the resulting tokens with AADSTS500172 due to invalid signing material. Although structurally correct, the artifact is not usable for authentication, as the active signing key resides in the system’s machine-scoped cryptographic store, protected by Windows Machine DPAPI and managed through the operating system’s cryptographic subsystem. Successfully obtaining this active key allows an attacker to forge valid SAML assertions for any user, bypassing the need for user credentials and multi-factor authentication, and granting unauthorized access to any SAML-federated application including Microsoft 365 and Entra ID within the organization's environment.

Analysis revealed that AutoCertificateRollover had been disabled and a manual rotation had been performed. Confirmation was obtained directly via Get-AdfsProperties, which returned AutoCertificateRollover: False, indicating that certificate lifecycle management had been delegated to manual administrative processes. While the ADFS service used a new valid key for signing, the WID configuration database was never updated to reflect the new certificate—leaving an expired "ghost" entry as the only record. This drift condition surfaces via Microsoft Event ID 385, which indicates certificate validity warnings in the ADFS service. Notably, this event self-resolves when AutoCertificateRollover is re-enabled and a subsequent certificate rollover is performed; in environments where it is disabled and manual rotation is performed without a corresponding database update, it is the observable symptom of this drift condition.

ADFS maintains private keys in two protection contexts. In Location 1 (User DPAPI), encrypted key blobs may exist on disk, but the DPAPI protection is tied to the service account's SID and associated DPAPI masterkey material. In the assessed environment, the domain DPAPI backup key approach successfully decrypted masterkey material for interactive user profiles, but returned no decryptable material associated with the ADFS service account profile. All subsequent offline decryption attempts similarly failed, consistent with the masterkey not being recoverable through the evaluated on-disk recovery approach in this environment—though this observation is bounded to the assessed environment and does not represent a universal architectural property of all ADFS deployments.

Location 2 (Machine RSA) does not rely on a user-specific logon session. Instead, the key material is protected using Machine DPAPI, leveraging the DPAPI_SYSTEM LSA secret together with machine masterkeys available to sufficiently privileged SYSTEM-level contexts.

Why the WID Path Misses This Key

In ADFS environments experiencing configuration drift—commonly arising during manual certificate rotations where AutoCertificateRollover is disabled—the ADFS service host can successfully bind to a newly provisioned signing certificate at the operating-system level, ensuring continued service operation. However, the WID configuration database may not reflect the current signing certificate, resulting in stale certificate metadata.

This divergence between configuration and runtime state is the condition that ADFS Event ID 385 is designed to flag. As a consequence, extraction techniques that rely solely on the WID database and DKM material may return certificates that are no longer used for active signing, leading to rejected assertions in downstream federation scenarios.

Understanding How the Machine DPAPI Store Becomes Populated

Understanding how the Machine DPAPI store becomes populated requires examining how ADFS persists its token-signing key material. During initial deployment, automatic certificate rollover, or manual certificate rotation, ADFS persists its RSA private key material in the machine-scoped CAPI key store at C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\, protected using machine DPAPI context rather than a user-bound DPAPI context. SharpDPAPI /machine enumeration in the assessed environment confirmed that the active machine key material resided under this path, while the CNG Crypto\Keys store was not observed in use in the assessed environment.

The protection chain relies on the DPAPI_SYSTEM LSA secret together with machine masterkeys associated with the S-1-5-18 security context, stored in C:\Windows\System32\Microsoft\Protect\S-1-5-18\ as DPAPI-protected key material—both components ultimately resolvable only within highly privileged SYSTEM-level contexts on the host. The corresponding certificate is enrolled into the LocalMachine\My certificate store, from which ADFS retrieves the associated private key during token-signing operations.

The architectural rationale for machine-scoped key storage is operational resilience. A machine-scoped key remains usable across service account password changes, gMSA rotations, system reboots, and service restarts without requiring key reprovisioning or dependency on a specific interactive logon session. This design ensures that the ADFS service can consistently access the signing key regardless of changes to the underlying service account credentials.

However, this same design choice has important security implications. Because the private key is protected using Machine DPAPI rather than a user-bound DPAPI context, a sufficiently privileged local process capable of accessing the machine key store and associated DPAPI artifacts may be able to recover the key material independently of the original service logon session. As a result, under certain conditions, recovery of the active ADFS token-signing private key may be achievable without direct interaction with LSASS memory or the live ADFS service process itself, potentially reducing visibility to defenses primarily focused on credential dumping or process-memory access behaviors.

Attack Flow: Machine DPAPI Key Recovery to SAML Forgery

The recovered key was used to forge a SAML assertion impersonating a Global Administrator identity, which Entra ID accepted as a valid authentication assertion, resulting in authenticated access at Global Administrator privilege level within the federated Microsoft 365 tenant.

Detection and Hunting

Defenders should prioritize visibility into operating system-level cryptographic operations and identity issuance behavior, rather than relying solely on application-layer configuration stores.

• SACL-Based Object Access Monitoring: Configure object access auditing via SACLs on C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\ and C:\Windows\System32\Microsoft\Protect\S-1-5-18\. When configured correctly, this generates Security Event ID 4663 for file access attempts. Coverage depends on SACL configuration and access paths; treat this as supporting evidence in correlation-based detection rather than a stand-alone signal.

• ADFS Token Issuance Consistency: Monitor for inconsistencies between primary authentication events and token issuance events in ADFS audit logs. Relevant events include token issuance and claims processing records (Event IDs 299, 1200-series, depending on ADFS version and audit configuration). The objective is to identify token issuance that cannot be clearly correlated to a preceding authentication context. This is most effective when normal authentication patterns per relying party trust are baselined.

• Federated Identity Monitoring in Entra ID: Entra ID sign-in logs will record an accepted forged assertion as a standard federated sign-in event. Detection requires cross-correlating Entra ID sign-in records against ADFS-side issuance logs—neither source in isolation is sufficient. For privileged accounts, focus on unexpected Internet Protocol (IP) ranges, claim set deviations,and user-agent inconsistencies.

Mitigation and Remediation

ADFS infrastructure should be treated as Tier 0 identity infrastructure, equivalent in criticality to Domain Controllers. If SYSTEM access is achieved on an ADFS host, the signing key must be considered compromised.

• Hardware-Backed Key Protection: Migrate token-signing certificates to a Hardware Security Module (HSM). HSM-backed keys ensure private key material does not exist in software-accessible storage on the host, eliminating the Machine DPAPI extraction path entirely.

• gMSA Service Identity: Run ADFS services using Group Managed Service Accounts to automate credential rotation and reduce operational drift in service identity management. While this does not directly address machine-scoped key protection, it eliminates manual credential management as a contributing factor to configuration drift.

• Tier 0 Administrative Controls: Govern ADFS servers with strict Tier 0 controls: restricted administrative access pathways, dedicated Privileged Access Workstations (PAWs), separation from general server administration domains, and enhanced privileged access monitoring.

• Certificate Rotation and Configuration Validation: If compromise is suspected, rotate the token-signing certificate and validate consistency across ADFS configuration, the  LocalMachine\My store, and federation metadata. Do not rely on a single source of truth. For environments with AutoCertificateRollover disabled, manual rotation must include updating ADFS via Set-AdfsCertificate—installing the certificate alone is insufficient. Validate using Get-AdfsCertificate after rotation. If Event ID 385 appears afterward, investigate for configuration inconsistency. 

• Multicloud Scope Awareness: A compromised ADFS token-signing key affects all SAML relying party trusts, not just Microsoft services. Organizations using ADFS for identity federation across other software-as-a-service (SaaS) platforms should treat ADFS as Tier 0 infrastructure and audit all relying party trusts. Migrating away from ADFS-based federation (e.g., to native OIDC federation) removes this specific attack path.

Background

Today, in coordination with the FBI, Lumen, and others, Google took action against the NetNut residential proxy network, also known as Popa. This action builds on our disruption of the IPIDEA proxy network that took place in January 2026, and is a continuation of Google’s objective to dismantle malicious residential proxy networks.

Actions Taken

As a part of this disruption we took the following actions:

1. Disabled Google accounts and associated Google services used by NetNut for malware command and control (C2), which directly violates Google’s Terms of Service and Acceptable Use Policy. 

2. Shared technical intelligence on NetNut software development kits (SDKs) and backend C2 infrastructure with platform providers, law enforcement, and research firms to help drive ecosystem-wide awareness and enforcement.

3. We ensured Google Play Protect, Android’s built-in security protection, automatically warned users and disabled applications known to incorporate NetNut SDKs, and the system will continue to protect users against future install attempts. These efforts to help keep the broader digital ecosystem safe supplement the protections we have to safeguard Android users on certified devices.

We believe our coordinated actions have caused significant degradation to NetNut’s proxy network and its business operations, reducing the available pool of devices for the proxy operator by millions. In addition to selling access to the network under the NetNut brand, NetNut has a robust reseller program that allows whitelabeling of its network. Google has high confidence that many popular residential proxy brands are in fact whitelabeling the NetNut botnet. While we expect this disruption to have a larger ripple effect across the residential proxy ecosystem, observations after the disruption of IPIDEA proved that individual networks can appear resilient. What we have observed is that when faced with the degradation of their own botnet, proxy operators begin buying capacity from their competitors, effectively becoming a reseller. We recognize that creating a lasting disruption in this fluid ecosystem means we must scale our efforts to target the infrastructure of several interconnected providers. We will continue to observe the composition of the NetNut network and map out how its peers adapt to this action.

Why it Matters

NetNut is among the largest and most popular residential proxy networks. Estimating the size of residential proxy networks is extremely challenging, but Google Threat Intelligence Group (GTIG) estimates the size of the NetNut network to be at least 2 million devices, distributed across the world. Public reporting by KrebsOnSecurity and others, confirmed by Google, illustrates that NetNut populates its botnet by distributing SDKs for devices commonly found in homes, such as smart TVs and streaming boxes. GTIG has also identified NetNut botnet plugin components for large-scale botnets such as Badbox 2.0.

Residential proxy networks sell the ability to route traffic through IP addresses owned by internet service providers (ISPs), allowing attackers to mask malicious activity by hijacking these IP addresses. A robust residential proxy network requires controlling millions of residential IP addresses to sell to customers for use. To accomplish this, operators need code running on home devices to enroll them into the malicious network as exit nodes. Home devices become part of proxy networks either because they are pre-installed with malware before purchase or because users unknowingly download applications containing hidden proxy code. This creates serious risks for unsuspecting device owners, as their home IP addresses can be used by attackers as a launchpad for hacking and other unauthorized activities. Consequently, users can have their legitimate traffic flagged as suspicious, or blocked by their service providers.

In a single week during June 2026, GTIG observed 316 distinct threat clusters using suspected NetNut exit nodes, including cybercriminal and espionage groups. These bad actors can use NetNut to mask their origin IP address when accessing victim environments, accessing their own infrastructure, and conducting password spray attacks. Furthermore, when a consumer device becomes an exit node, unauthorized network traffic passes through it. This means bad actors can access other private devices on the same home network, effectively exposing them to Internet threats. Public reports by Synthient, Spur, Nokia Deepfield, and others have documented the use of NetNut to infect devices with variants of Mirai DDoS botnets.

Empowering and Protecting Consumers

Consumers should be extremely wary of applications that offer payment in exchange for "unused bandwidth" or "sharing your internet." These applications are primary ways for malicious proxy networks to grow, and could open security vulnerabilities on the device’s home network. We urge users to stick to official app stores, review permissions for third-party VPNs and proxies, and ensure built-in security protections like Google Play Protect are active.

Consumers should be careful when purchasing connected devices, such as set top boxes, to make sure they are from reputable manufacturers. For example, to help you confirm whether or not a device is built with the official Android TV OS and Play Protect certified, our Android TV website provides the most up-to-date list of partners. You can also take these steps to check if your Android device is Play Protect certified.

Future Work

As we noted earlier this year, the residential proxy industry appears to be rapidly expanding, and this coordinated disruption is not the end of our work combating malicious residential proxy networks. This industry is deeply connected and operators depend on overlapping botnet networks that are constantly resold. While point-in-time disruptions are a critical tool to protect our users, continued and coordinated effort is needed to reduce malicious proxy networks in the long run. We encourage mobile platforms, ISPs, and other tech platforms to continue sharing intelligence and to take direct action to block malicious C2 infrastructure.

Written by: James Sadowski, Alden Wahlstrom

Introduction

Four years into Russia’s full-scale invasion of Ukraine, the pro-Russia influence ecosystem has evolved from a tool of war back into a global strategic asset. Since the mobilization of this ecosystem to support frontline objectives, we have witnessed the expedited development of new influence assets linked to multiple, expansive, covert information operations (IO) campaigns and a revitalization of pro-Russia hacktivism at an unprecedented scale. While this threat activity initially adapted to encompass Ukraine-related priorities, it is gradually pivoting back to established Russian influence objectives for which the ecosystem was originally honed. This shift is significant because it likely signals increased focus outside of Ukraine, warning that pro-Russia influence activity targeting the European Union (EU), North Atlantic Treaty Organization (NATO), and other top targeting priorities may intensify. 

Ultimately, the war in Ukraine has provided a critical feedback loop for Russia to refine its influence activity, lessons that we anticipate will be applied as the ecosystem continues to reorient toward global strategic objectives while maintaining focus on Ukraine. Further, recent pro-Russia IO indicates the continued expansion of already diverse tactics, and the increasing use of generative AI tooling for planning, research, and content creation marks a forward trend in pro-Russia IO. Meanwhile, new and different actors have adopted IO tactics to meet an increasingly diverse set of challenges, signaling growing Russian reliance on influence tactics. Together, these trends likely demonstrate the Kremlin's perception of these tactics as cost effective and successful. The interconnected nature of the ecosystem's disparate components makes it resilient to limited scope disruptions, which defenders must consider to effectively mitigate pro-Russia influence threats. 

The Ecosystem at a Glance: Objectives, Targeting, and Tactics

Russia's modern approach to information operations is built on the conceptual foundation of Soviet-era "active measures" adapted for the digital age. Alongside disruptive cyberattacks dating back to the early 2000s, the Kremlin has increasingly harnessed internet-based platforms for espionage and information operations. Russia's approach has evolved from rudimentary, singular operations into a complex, self-sustaining environment intentionally curated by the Russian Government that blends overt, covert, and independent elements to advance Kremlin interests both at home and abroad.

Core Influence Objectives 

GTIG’s observations suggest the primary strategic motivations driving the pro-Russia influence ecosystem fall into five categories, each aiming to achieve military and/or political objectives through psychological manipulation of the target audience (Figure 1). Collectively, these objectives informally depict a global influence strategy: through the furthest reach of its influence, the Kremlin seeks to diminish Western primacy and advance Russia's global position; within its surrounding region, it strives to retain and return Moscow's dominance; and at home, it works to ensure the stability of the political regime.

Targeting 

Pro-Russia influence operations are pivoting from the near singular focus on Ukraine that dominated the ecosystem since 2022. We expect influence operations advancing Russia's war-specific interests to continue. However, as Russia seeks to reemerge from international isolation, we have increasingly observed a concurrent focus on pre-war pro-Russia influence objectives. 

The current and historical targeting scope of each ecosystem component exposes both the Kremlin's global ambitions and the realistic limitations of its power projection. State-owned media organizations produce content intended to serve populations across six continents, but in recent years, sanctions and other factors have limited its production and distribution. Meanwhile, covert operations have appeared more limited in scope, primarily targeting the West and countries surrounding Russia, with intermittent operations targeting the Middle East and Africa, indicating that finite resources necessarily limit these operations (Figure 2).

Top Regional Targets

• The United States and Europe: The Kremlin has long viewed the West as a top adversary of Russia. Accordingly, the US and Europe are top targets of covert pro-Russia information operations, especially aimed at undermining political stability within these countries and the unity between them. NATO and the EU embody the collective "West" and are Russia's perceived top adversaries, second only to the US independently.

• Russia's "Near Abroad": Since the dissolution of the Soviet Union, Moscow has asserted that the countries that formerly comprised part of the USSR now reside in Russia's so-called "sphere of influence." Covert influence targeting this region directly reflects Moscow's assertion that Russia is a world power entitled to special privileges within its neighborhood. 

• The Middle East and Africa: Over the past decade, Russian efforts to reassert itself as a global power have included high-profile investments in cultivating Russia's standing in the Middle East and Africa. Covert pro-Russia influence activity is likely deployed in tandem as intended support for other Russian initiatives in these regions.  

• Russia Domestic: Internally targeted covert IO is a well-established component of pro-Russia influence activity, deployed by regime-aligned actors to promote Kremlin policies and repress opposition voices. 

Targeted Entities and Global Events

• The Olympics: Russia has long viewed Olympic participation as a point of national prestige, and GTIG has observed notable Russian influence activity targeting the Olympics in the face of Russian participation bans. 

• War in Ukraine: The war in Ukraine has been a key driver of Russia's influence activity, including attempts to influence events on the ground as well as influence activity intended to advance Moscow's interests elsewhere vis-a-vis the war. GTIG expects that Ukraine will remain a priority in Russia's targeting calculus during the post-conflict phase following any future peace agreements.

• Elections: Election targeting aligns with multiple Russian influence objectives, including attempting to undermine confidence in democratic institutions as well as internally weakening perceived Western adversaries. These operations regularly target elections in countries that are already prioritized by ongoing pro-Russia influence activity. 

• Ad Hoc Geopolitical Flashpoints and Global Events: Russian influence actors have a history of pivoting activity to engage with emerging geopolitical developments and events, such as the COVID-19 pandemic or the 2026 Middle East conflict. This flexible target selection often overlaps or is aligned with other Russian priorities, making previously observed Russian influence activity helpful in anticipating which events may be appropriated.

Tactics 

Converging geopolitical and technological developments make the evolution of pro-Russia influence tactics a particularly important space to monitor right now. The pro-Russia influence ecosystem expanded to support the war effort, bringing change across the spectrum of activity and providing operators the opportunity to hone their tactics, techniques, and procedures (TTPs) in the rapid feedback loop of war. Meanwhile, the emergence and increased democratization of generative AI tooling has brought both promised and already realized opportunities to support all phases of the IO lifecycle. The following are a sample of key tactics that illustrate how pro-Russia actors currently blend well-tested methods with new technological developments to reach audiences through diverse means:

• Generative AI: GTIG has observed pro-Russia influence actors increasingly leverage AI tooling to support different stages of their operations, including support for planning and general research as well as content creation.

• Google Threat Intelligence Group (GTIG) is closely tracking the transition from nascent AI-enabled operations to the maturing, industrial-scale application of generative models within adversarial workflows across threats ranging from espionage and crime to IO. Please see our latest AI threat tracker for more information on how this threat is developing based on our insights, and what Google is doing to protect our customers. 

• Narrative Resonance: Hijacking existing ideological and emotional fissures within a society provides pro-Russia influence actors tailored narratives to target audiences and potentially increases potential engagement and impact. 

• Cyber-Enabled IO: Influence campaigns frequently coincide with destructive cyberattacks, such as the deployment of wiper malware alongside website defacements containing false surrender messages, or the historic use of "hack and leak" campaigns in which exfiltrated data, sometimes manipulated, is then publicized through an actor-controlled false persona. In some instances, Russian actors may even leverage direct cyber espionage targeting as a way to achieve psychological effects, intending to influence victims' behavior through intimidation.

• Media Mimicry: Pro-Russia actors have attempted to mimic legitimate media at scale and through a variety of means, including via the wholesale appropriation of legitimate media brands or developing inauthentic media brands that generally masquerade as independent news sources. These tactics are intended to add a veneer of legitimacy to the promoted narratives. 

• Direct Dissemination: Pro-Russia influence actors have used closed communication channels, such as emails, SMS text messages, and messenger apps, to disseminate various types of pro-Russia narratives as an adjunct to or outside typical social media-focused operations. 

Core Ecosystem Components 

The current pro-Russia influence ecosystem operates across a spectrum from official government communications to deniable covert actions conducted by intelligence services and "patriotic" proxies. GTIG identified six core components that represent key activity types (Figure 3). While many elements are state-directed or state-affiliated, the ecosystem is also a cultivated, self-sustaining system: various actors, often without explicit direction, amplify Kremlin-friendly narratives and pursue actions that advance Russia's strategic interests. This fluidity provides resilience and complicates attribution, mirroring the longstanding Kremlin strategy to co-opt non-state actors, including criminal networks for finance or illicit logistics, to achieve state objectives without direct attribution. Although each of the core ecosystem components serves as a unique lever the Russian Government can employ to achieve desired objectives, they are regularly used together. For instance, while the entire pro-Russia hacktivist landscape is not state-sponsored, the Russian intelligence services have used both genuine and fabricated hacktivist personas to launder stolen data as part of blended cyber espionage and IO hybrid operations.

An Interconnected Ecosystem Enhances Influence Utility

Figure 4 illustrates the complex, interconnected nature of the pro-Russia influence ecosystem by mapping relationships between a selection of key actors and organizations across five of the core components. The ecosystem functions as a cohesive unit, not only through shared objectives, but also through direct cross-component interactions. The Russian Government functions as the sixth core ecosystem component, setting the policy and talking points that inform the ecosystem’s promoted narratives and sponsoring overt and covert assets throughout the other five components diagrammed in Figure 4. Through these levers, the Kremlin fosters the cross-component links that underpin the ecosystem, enhancing its overall utility as a versatile tool of state influence.

10 Key Dynamics for Understanding the Pro-Russia Influence Ecosystem

The scope and diversity of activity in the pro-Russia influence ecosystem challenges defenders tasked with enumerating, tracking, and countering its threats. GTIG has distilled 10 key ecosystem dynamics based on our current understanding of its components and how they each enable covert influence activity. These dynamics frame critical aspects of how activity manifests within the ecosystem, providing a high-level guide to understand and track these threats.

Large-scale IO campaigns are an integral element of the pro-Russia influence ecosystem. Major pro-Russia IO campaigns have been an enduring feature of the pro-Russia ecosystem, with new campaigns emerging as previous ones fall into inactivity. Maintaining extensive IO campaigns and their associated established influence infrastructure enables proactive messaging on strategic issues and underpins a capability that can be rapidly adapted for emerging domestic and global priorities.

• Long-established IO campaigns, like Secondary Infektion, pivoted to meet new strategic needs as Russia’s 2022 invasion of Ukraine began. New IO campaigns, such as “Operation Overload,” subsequently emerged to support the war effort; while Secondary Infektion has become dormant, these “successor” campaigns have since been leveraged to advance other global Russian influence objectives beyond the war itself. 

Pro-Russia actors often prioritize persistence and the range of tactics they leverage reflects this. In the face of public exposure and disruption, pro-Russia actors and their infrastructure have often remained persistent, sometimes making tactical adjustments to mitigate the effects of detection and disruption and other times continuing operations unabated. 

• These persistence tactics include the Doppelganger campaign and overt Russian media’s respective cycling of domain infrastructure and/or use of mirror domains to overcome exposure, platform bans and sanctions. Influence operators also frequently continue using compromised assets, sometimes mocking their exposure, as seen with the legacy US-targeted NAEBC campaign and the APT44-affiliated hacktivist persona XakNet Team.

Pro-Russia and Russian cyber espionage groups leverage IO tactics to support their operations and weaponize stolen data and/or illicit access. While less frequent, this hybrid activity is a critical dynamic within the pro-Russia influence ecosystem. GTIG has previously observed operations used to shape narratives around cyberattacks and influence events on the ground and to conduct foreign political interference, including the repeated targeting of foreign elections, reported in Spring 2024. We have attributed some observed instances of this to Russian government-sponsored threat actors.

• Russian state sponsored or pro-Russia hacktivist groups have long relied on public advertisement of real or claimed data exfiltration to highlight their operations, intimidate targets, or sway public opinion. In 2022, UNC4057 (COLDRIVER) used data stolen from espionage targets in a high profile hack-and-leak operation seeking to exacerbate divisions in UK politics. More recently, the self-proclaimed hacktivist group PalachPro claimed in February 2026 to have gained unauthorized access to a Ukrainian government online portal and publicly posted screenshots of the claimed compromise. The Ukrainian government has previously noted that the portal does not store the type of data the threat actor claimed to compromise, suggesting the public posting was likely intended as influence activity, attempting to create the illusion of a more serious threat.

Pro-Russia hacktivists serve a direct influence function. Modern pro-Russia hacktivism has evolved into an important component of the influence ecosystem that blends state-backed actors leveraging hacktivist tactics with an evolving cohort of likely third-party hacktivist actors that support Russia's geopolitical interests. Pro-Russia hacktivist groups gain domestic and foreign attention for strategic messaging via their claimed threat activity, amplify narratives directly seeded in overt ecosystem segments, and at times also support traditional IO activity or create a means of plausible deniability for state-sponsored espionage actors. 

• The self-proclaimed hacktivist group NoName057(16) emerged following the Russian invasion of Ukraine in 2022, primarily targeting Ukraine and its partners and allies with DDoS attacks and various network intrusions. It has targeted high profile events, such as the Milano Cortina Winter Olympics, institutions like the French National Assembly, and critical infrastructure and transportation targets in Germany. Often their messaging cites grievances with overt acts of Western support for Kyiv, suggesting the group advances Russian interests not only through the targeting of perceived Russian adversaries but also in gaining attention for its pro-Russia messaging. 

Established ecosystem components facilitate the cultivation of new assets and activity. Inter-ecosystem cross-promotion helps overcome challenges of audience building by directing traffic toward new assets, operations, and narratives, enabling rapid deployment of new and existing IO capabilities. This directly supports a self-sustaining cycle that maintains and expands the ecosystem. 

• The hacktivist persona JokerDNR played a significant role in amplifying the APT44-linked persona Solntsepek when its doxxing-focused Telegram channel first launched and then again as it began claiming cyber espionage activity. 

Domestic Russian audiences are a longstanding target of the pro-Russia influence ecosystem. Internally directed influence activity has often involved the promotion of Kremlin policies and talking points and the denigration of opposition voices and ideas, conducted by both overt and covert segments of the ecosystem. 

• Ahead of Russia’s March 2024 presidential election, GTIG identified the hybrid espionage and influence actor UNC5101 register domains and conduct associated influence operations attempting to deceive Russian opposition voters about the timing of an anti-Putin protest.

Ecosystem actors respond to the same set of internal shifting circumstances and external geopolitical developments, often leading to seemingly similar, but ultimately distinct, activity. These shared drivers and general motivational alignments encourage actors to "spontaneously" coalesce around a particular topic or narrative. While this can appear superficially similar, this phenomenon is distinct from instances of actor coordination and campaign linkages, which is less common. 

Systemic flexibility is a central feature, with influence assets able to mobilize both incrementally and at scale to advance Russian interests. The Russian Government is able to mobilize assets across the ecosystem to respond to strategic events. Meanwhile, individual or aligned actors can separately mobilize to address tactical needs, allowing the ecosystem to concurrently message on multiple issues across different geographies (Figure 7). 

• Russia demonstrated its ability to focus the ecosystem on a single strategic issue like the Russian invasion of Ukraine. Simultaneously, discrete assets have addressed tactical events, such as when Portal Kombat briefly promoted narratives about a Russian drone incursion into Poland concurrently with other covert pro-Russia influence activity.

Overt Russian media contributes to, and is connected with, multiple covert influence components. The overt components of Russia's influence infrastructure play a critical role within the broader Russian influence ecosystem beyond the commonly understood function of providing a public platform for government-aligned narratives and official talking points; overt media helps to drive (inform targeting) and amplify covert pro-Russia influence activity, seeding desirable narratives within the ecosystem and providing an indirect conduit between the Kremlin and a disparate array of influence actors. Overt media outlets have directly coordinated their activity with covert actors and have increasingly employed IO tactics to disseminate their own content in the face of sanctions and platform bans (Figure 8). 

• US Government sanctions in late 2024 indicated that Russian state media company Russia Today (RT) directly conducted covert influence operations, including on behalf of the Russian intelligence services. Further, RT employees reportedly interacted with members of the self-proclaimed hacktivist group RaHDit, which has claimed to collaborate with multiple other pro-Russia hacktivist groups, illustrating the layered connections between overt media, Russian intelligence services, and hacktivist groups.

Outsourcing IO capability development and campaign execution to third-party organizations and proxies enables scaling and obfuscation. Outsourcing is used for developing custom tooling and bolstering both human and organizational capacity. While custom tool development facilitates operators in all phases of the IO lifecycle, Russian government actors can flexibly leverage different models for outsourcing campaign execution based on their specific needs. Proxy actors can also generate plausible deniability (Figure 9). 

• GTIG reported how Russian IT contractor NTC Vulkan (Russian: НТЦ Вулкан) worked with the Russian intelligence services, including providing tooling and support for the GRU unit that sponsors APT44 activity. Separately, US government sanctions detailed how the Doppelganger campaign is supported by multiple Russian contractors under the sponsorship of the Russian Presidential Administration.

Conclusion

Multiple factors are propelling the evolution of the pro-Russia influence ecosystem we have observed since Moscow’s full scale invasion of Ukraine four years ago. The Kremlin mobilized the entire ecosystem to support the ongoing conflict, which has provided rapid feedback and driven significant investment in new and established overt and covert influence assets. At the same time, pro-Russia actors are increasingly experimenting with generative AI to enhance their workflows. This condensed period of adaptation, alongside signals suggesting Russia's growing reliance on IO tactics to navigate new challenges, raises concerns regarding how a potentially diversifying pool of actors will leverage advancements in tradecraft and scalability. As Russia seeks to emerge from international isolation and reorients its influence ecosystem back toward global objectives, it is critical for defenders to understand how this ecosystem provides the Kremlin with a durable influence capability in order to better anticipate future Russian influence threats.

Additional Tools and Resources

For mitigation and hardening recommendations, please review the following:

• How to Understand and Action Mandiant's Intelligence on Information Operations

• Proactive Preparation and Hardening to Protect Against Destructive Attacks

• Linux Endpoint Hardening to Protect Against Malware and Destructive Attacks

• Distributed Denial of Service (DDoS) Protection Recommendations

Google offers a suite of free of cost tools to help protect high-risk users from the most pervasive digital attacks, to which politicians, journalists, and campaigns are often most vulnerable. Examples include protecting accounts from targeted attacks with Advanced Protection Program and safeguarding campaign websites from DDoS attacks with Project Shield.