TL;DR: We built the first RDP client outside of Windows to support WebAuthn redirection, beating Microsoft's own macOS, iOS and Linux clients to it (since then FreeRDP has added support too, which we’re happy to see). No browser API could do what we needed, the protocol spec was missing entire commands, and we discovered that Microsoft's Windows implementation routes through internal, undocumented code paths we had to reverse-engineer. This is the story of what we found.
Prisma Browser offers support for more than the standard secure web browser. We often build support for protocols that go beyond web applications. We develop tailored solutions for Prisma Browser to enable its users to solve complicated security issues. One useful example is Remote Desktop Protocol (RDP).
IT operations frequently require SSH, while remote users need to access legacy and on-premises applications using protocols such as RDP. In the past, these were only accessible via thick clients, which required opening risky network tunnels, or through remote session hops that translate traffic into browser-native protocols like HTML5. This translation often impacts performance and breaks core functionality.
To meet this need, we have developed native clients directly inside the browser. Doing this has also surfaced a demand for even more flexibility and features within these native clients. This post covers one of our recent announcements that not only fills a critical gap but makes our native clients superior to the common thick applications used today.
It all started when someone asked: "Can we support security keys? If a user is on a website inside the remote session and it asks for their YubiKey, can we just redirect that to their local machine?"
Sure. Microsoft has a protocol for that: [MS-RDPEWA], the WebAuthn Virtual Channel Extension. There's a spec. How hard can it be?
Two weeks, one IDA Pro license and several existential crises later, we had it working.
Obligatory AI Section
Two years ago, the reverse-engineering part of this work would have taken days, easily. Today, it took a few hours with AI to write a working IDA model context protocol (MCP) bridge, then a few more hours using that bridge to ask the binary the right questions and find the pieces we needed.
AI did not reverse-engineer the feature for us. The hard parts were still knowing what to ask, validating every answer, setting breakpoints, comparing traces and proving the protocol behavior end to end. But the workflow changed dramatically: Instead of clicking through disassembly for days, we could build a tool, connect it to IDA and iterate in minutes.
Reading the Spec
The [MS-RDPEWA] specification describes a dynamic virtual channel (DVC) called Microsoft::Windows::RDP.Webauthn. The server sends CBOR-encoded WebAuthn requests, the client talks to a local authenticator and sends back the response. Four commands:
Command
ID
Purpose
WEB_AUTHN
5
MakeCredential or GetAssertion
IUVPAA
6
"Got a platform authenticator?"
CANCEL
7
Cancel current operation
API_VERSION
8
Version negotiation
Clean. Straightforward. Surely the hard part is just wiring it up. We'll get back to that.
Note: When we did this work the spec stopped here. The [MS-RDPEWA] 3.0 revision (March 2026) has since documented two more commands, GetCredentials (9) and GetAuthenticatorList (12), gated to Windows 11 24H2+ and Server 2025+ via KB5065789.
"Just call navigator.credentials"
Our initial plan: receive the WebAuthn request from the server, call navigator.credentials.create() in the extension, send back the response.
Here's the problem. When a user visits okta[.]com inside the remote session and triggers WebAuthn, the server intercepts the ceremony. It computes clientDataHash = SHA-256(clientDataJSON), where clientDataJSON contains the page's origin, the challenge and the ceremony type. Then it sends that 32-byte hash over the RDP channel.
On the client side, navigator.credentials.create() insists on constructing its own clientDataJSON, with its own origin: chrome-extension://..., not hxxps://okta[.]com. It hashes that, hands it to the authenticator, and the authenticator signs over it.
When the assertion gets back to Okta's server: hash mismatch. Signature verification fails. SHA-256 is a one-way function. There's no going around this.
We briefly considered reconstructing the clientDataJSON ourselves from the known challenge and origin. Three reasons that doesn't work:
Browsers don't produce byte-identical JSON for the same inputs (field ordering, encoding).
Native apps using WebAuthn SDKs add more variability.
Older Windows servers don't even send the ingredients. They send only the 32-byte hash. No origin. No challenge in cleartext. Just the hash.
Building a Custom Browser API
No existing browser API can accept a pre-computed clientDataHash and pass it directly to an authenticator. Not navigator.credentials. Not chrome.webAuthenticationProxy (designed for the opposite direction). Not remoteDesktopClientOverride (requires the original JSON). Not WebHID (USB-only, no Touch ID, no phone-as-authenticator).
Since we built this, the W3C WebAuthn working group has started standardizing exactly this case (the remoteClientDataJSON extension, editor's draft section 10.1.6). It is not yet in any shipping browser, so the custom API below is still required, but the direction is encouraging.
So we built one: a custom extension API with makeCredential() and getAssertion() methods identical to navigator.credentials in every way except one. The caller supplies the clientDataHash directly; it goes straight to the authenticator.
The upside of being a web-based RDP client inside Chromium: We get Chromium's entire FIDO2 stack for free. Authenticator discovery across USB, BLE, NFC and platform authenticators. Cloud-assisted Bluetooth low energy (caBLE)/Hybrid transport for phone-as-authenticator. Touch ID and Windows Hello integration. The credential selector UI. Our custom API is a thin wrapper reusing all of this machinery.
Why not just use libfido2, the way FreeRDP does? Because FreeRDP is a native client and we are not. libfido2 reaches authenticators over USB or NFC by opening raw HID devices directly, which a native process can do but code inside a browser cannot.
From WebAssembly there is no raw HID access. The only in-browser transport is WebHID, which is USB-only (no Touch ID, no Windows Hello, no phone-as-authenticator). Getting true device access would mean shipping a separate native helper outside the browser, defeating the point of an in-browser client. And even then, libfido2 alone would not give us platform authenticators or phone-as-authenticator over caBLE/hybrid.
By wrapping Chromium's own FIDO2 stack we get all of those for free. That is also why, on Windows, our path runs into Chromium's WebAuthn machinery and its clientDataJSON requirement, while a native libfido2 client does not.
This worked. YubiKey blinks. User touches it. Registration succeeds. We celebrated for approximately 90 seconds before the next problem emerged.
"It Works on This Windows Version But Not That One"
Our WebAuthn redirection worked beautifully against some Windows servers and completely failed against others. Same client code, same authenticator, same relying party.
Here's why. On Windows, every browser (including Chromium) calls WebAuthNAuthenticatorMakeCredential from webauthn.dll. This public API unconditionally requires the full clientDataJSON:
Our approach of passing a raw hash directly works on macOS and Linux (where we control the authenticator stack) but hits a wall on Windows.
The deeper issue: Not all Windows servers send the same data. Newer Windows servers (API version 9, currently only Windows 11 25H2+) additionally transmit clientDataJSON, remoteWebOrigin and the full W3C credential options over the wire. Microsoft published the v9 struct changes to webauthn.h in September 2025. If both sides are v9, you get the new fields and everything is straightforward.
But older Windows servers (Windows 10, Server 2019/2022, Windows 11 through 24H2) send only the 32-byte hash. This is the vast majority of enterprise environments.
So how does Microsoft's own mstsc.exe handle older servers? It uses the same webauthn.dll. But how it actually processes a hash-only request is undocumented.
Time to break out IDA Pro.
Reverse Engineering mstsc.exe
Before diving into disassembly, we had one paranoid question to answer first: what if the server is just... cheating? Like, what if it quietly detects that it's talking to mstsc.exe and slips it a clientDataJSON in some side channel, and the whole thing only works because Microsoft wrote both ends and decided third parties were on their own? We had to know before spending days in a disassembler.
So we hooked mstscax.dll with Frida and intercepted the WebAuthn DVC channel in both directions across two complete FIDO2 ceremonies. Result: no clientDataJSON on the wire. The server sends a 32-byte clientDataHash. The client sends back a CTAP2 response. No JSON anywhere. So mstsc.exe is dealing with the exact same problem we are. But it works. Sorry I doubted you, Microsoft.
mstsc.exe never calls the public WebAuthn API.
webauthn.dll has a “dual personality”:
Public API (WebAuthNAuthenticatorMakeCredential, etc.): documented, stable, used by browsers and apps, requires clientDataJSON.
The DVC plugin path: an exported function VirtualChannelGetInstance() creates a WebAuthNDVCPlugin (implementing IWTSPlugin). This plugin handles everything through private, unexported functions that are perfectly happy with just clientDataHash and no JSON.
Microsoft does acknowledge this dual role. The IWTSPlugin MSDN page notes: "The IWTSPlugin interface is implemented by %System32%\webauthn.dll to enable the Remote Desktop WebAuthn redirection functionality." The page also points you to VirtualChannelGetInstance (which has its own reference page) to obtain the interface. What it omits is what the plugin does with a hash-only request.
VirtualChannelGetInstance takes a GUID parameter, and Microsoft documents the prototype on its reference page (noting it is not shipped in a header, so you declare it yourself). The GUID is IID_IWTSPlugin, which has shipped in tsvirtualchannels.h in the Windows SDK for years. It is a genuine third-party integration point; what Microsoft does not document is how the plugin handles a hash-only request, which is the behavior we reverse-engineered to replicate in our own Windows code path.
The private CtapCborDecodeRpcRequest treats clientDataJSON as optional. If it's in the CBOR, use it. If not, pass through the hash. The public API is strict; the private plugin path isn't.
What We Ended Up With
A DVC plugin for the WebAuthN_Channel, implemented in C as part of our existing WebAssembly (Wasm) client
A custom Chromium extension API that accepts pre-computed clientDataHash values, supporting USB keys, Touch ID, Windows Hello and phone-as-authenticator via caBLE/Hybrid
A TypeScript protocol layer handling CBOR encoding/decoding for MS-RDPEWA, including parts that were undocumented when we built it
A detailed reverse-engineering report on webauthn.dll's dual nature
Works on both newer Windows servers (with clientDataJSON) and older ones (hash only). Supports registration and authentication. Handles the commands that were undocumented at the time. When we shipped it, no other non-Windows RDP client did this. FreeRDP has since added support (version 3.25.0, April 2026), which is great news.
Since We Wrote This…
Microsoft updated the MS-RDPEWA spec (version 3.0, March 2026) to document commands that were previously missing
The W3C is standardizing the browser side via the remoteClientDataJSON extension
FreeRDP shipped a non-Windows implementation in version 3.25.0 (April 2026)
We have folded these in, in the text above. The reverse engineering was necessary when we did it, and the cross-platform challenge is unchanged.
Takeaways
The protocol is platform-agnostic; the implementation knowledge is not. MS-RDPEWA defines a clean wire protocol. But implementing it correctly required reverse-engineering mstsc.exe, because the spec was missing commands, field definitions and protocol extensions (Microsoft has since documented some of these in the MS-RDPEWA version 3.0 revision, March 2026).
The Windows version split is the core architectural challenge. Newer servers send clientDataJSON. Older servers send only the hash, requiring an approach that no standard browser API supports. Microsoft handles this through webauthn.dll's DVC plugin; a documented entry point, but one that only works on Windows and whose hash-only behavior is undocumented. If you're not on Windows, you're on your own.
Microsoft’s documentation gaps aren’t edge cases. Niche details such as a missing command, undocumented protocol fields, the undocumented behavior behind the plugin or a spec example with the wrong command number are things that must be fixed for the implementation to work at all.
When we shipped it, this was the first implementation of WebAuthn redirection outside of Windows. Since then FreeRDP has added support too (version 3.25.0, April 2026), which is great to see. Microsoft's own macOS, iOS, Android and Linux RDP clients don't support it. We hope this post explains why, and what developers can do to leverage this knowledge to improve their own RDP clients.
Unit 42 researchers found that large language models (LLMs) consistently hallucinate web domains for legitimate brands. Adversaries are actively weaponizing this vector by registering these nonexistent domains to intercept traffic generated by AI systems. We call this phenomenon phantom squatting, and it poses a significant risk to the software supply chain.
Our proactive monitoring of registration for high-priority hallucinated domains yielded real-world detections across multiple sectors. We were able to predict use of these domains from 18–51 days ahead of adversary registration.
A standout case reveals an attacker who leveraged an AI coding assistant to build a full phishing kit named Montana Empire. This kit targeted a domain our detection pipeline identified as a high-risk hallucination target 23 days earlier, demonstrating the full cycle from AI-assisted attack development to LLM-hallucinated domain prediction.
To detect the risk posed by phantom squatting, we analyzed 913 global brands and executed 685,339 URL queries across multiple configurations of two distinct LLM models. This generated 2.1 million URLs and revealed over 13,229 confirmed malicious URLs. Furthermore, we discovered approximately 250,000 hallucinated domains that remain unregistered, presenting a significant opportunity for adversaries to exploit the software supply chain through preemptive registration.
Palo Alto Networks customers are better protected from phantom squatting through the following products and services:
The software supply chain threat landscape is shifting. For decades, supply chain attacks focused on predictable artifacts such as tampered build tools, malicious dependencies and compromised update servers. Defenders built protections around these predictable attack surfaces using package integrity checks, signed binaries and dependency auditing tools.
However, this model is becoming less effective. LLMs are no longer peripheral utilities, they are active participants in the software development lifecycle.
People consult AI coding assistants for documentation links. In doing so AI agents perform autonomous web research on behalf of developers, then formulate and execute HTTP requests against URLs the models themselves generate.
Enterprise continuous integration and continuous delivery (CI/CD) pipelines integrate AI assistants that recommend third-party service endpoints. For example, a developer querying a pipeline assistant to configure a cloud deployment notification might receive a recommended webhook URL such as hxxps[:]//api.build-notifier[.]io/v1/pipeline/events. Such a URL could be entirely fictitious and an adversary could have pre-registered it to intercept automated build telemetry or secrets.
In each case, downstream consumers often trust the LLM's output including the URLs it generates, without independent verification. This situation fundamentally alters the attack surface. When an LLM produces a URL, that artifact may be:
Ingested directly by autonomous AI agents that retrieve the resource
Integrated by developers into production-grade code
Suggested by AI coding assistants as the authoritative endpoint for third-party services
Included in documentation generated through large-scale automation
In these scenarios, an LLM functions as a trusted supply chain dependency. However, as with any trusted architectural component, it is susceptible to systematic exploitation.
From Slopsquatting to Phantom Squatting: Extending the AI Supply Chain Attack Taxonomy
Prior research on slopsquatting established the foundational attack pattern. LLMs frequently hallucinate software package names that do not exist in any legitimate registry.
Phantom squatting extends this adversarial logic from software packages to web infrastructure. Just as an LLM might hallucinate a library name, it can generate fictitious domains for web portals, API endpoints or corporate services for a target brand.
Throughout this article, we use the term phantom domain to specifically refer to a hallucinated domain that an adversary has or could weaponize.
The adversarial logic is illustrated by the following scenarios:
A coding assistant generates a plausible but unregistered benefits portal URL, allowing an adversary to preemptively register it.
An AI research agent produces a plausible banking portal domain that an adversary could have already registered to capture traffic.
A developer integrates an AI-generated API endpoint into their code, unknowingly directing application data to an attacker-controlled server.
This is no longer a theoretical risk. Our research confirms this vector is currently active in the wild.
Why Existing Supply Chain Defenses Miss This Threat
Typically, URL filtering and threat intelligence frameworks operate under a critical, shared assumption, that malicious infrastructure possesses a detectable reputation. Typical block lists rely on historical reports of malicious activity, while threat feeds require a domain to be observed within an active campaign before classification. Reputation scoring models require a domain to maintain a presence long enough to accumulate telemetry signals.
A phantom domain effectively exploits a zero-reputation bypass. At the moment an adversary registers and weaponizes a hallucinated domain it:
Carries no threat intelligence history
Has not established a reputation score
Lacks any blocklist entries
The infrastructure is nascent, the content is original and conventional defensive perimeters have no actionable signal. By the time threat intelligence systems synchronize, people have already been funneled to the site by an AI system they consider authoritative.
This shows the structural advantage of phantom squatting over legacy phishing. The fake domain is born clean because it comes from the LLM’s own internal vocabulary. These are the same language patterns that make the model’s output seem legitimate.
Threat Model: The Phantom Squatting Attack Lifecycle
Figure 1 shows the phantom squatting attack lifecycle operates across four distinct phases:
Discover
Act
Lure
Bypass
Figure 1. The phantom squatting attack lifecycle across four phases.
Discover: Adversarial Probing of LLM Hallucination Patterns
The adversarial lifecycle begins by mapping a target brand's hallucination surface — the collection of phantom domains an LLM generates in response to diverse prompt strategies. This phase, which we define as adversarial hallucination probing, involves systematically querying models. Attackers could use realistic prompts that mimic everyday user operations, with the primary objective of observing and mapping the resulting hallucination patterns.
Act: Registering Hallucinated Phantom Domains Before Defenders React
Armed with a prioritized inventory of phantom domains, adversaries proceed to preemptively register those most valuable for attacks. For generic top-level domains (TLDs), the barriers to entry are negligible. Registration is both economical and nearly instantaneous. Our analysis confirms that threat actors operate with significant speed, often well within the window of any feasible defensive response.
In observed real-world telemetry, these domains transitioned from initial registration to active malicious content deployment within hours. In the case of Montana Empire, the adversary had even staged the server-side phishing kit prior to the domain’s registration, demonstrating a highly optimized zero-reputation bypass strategy.
Lure: LLMs as Unwitting Attack Delivery Mechanisms
Following the registration and subsequent weaponization of a phantom domain, the LLM itself functions as the primary attack delivery mechanism. Any user or autonomous AI agent that issues a query triggering the hallucinated URL receives an authoritative, high-confidence recommendation to navigate directly to attacker-controlled infrastructure.
This represents a defining characteristic of the phantom squatting threat. The delivery vector bypasses traditional phishing emails, malvertising or watering hole attacks. Instead, the delivery mechanism is the trusted AI assistant already integrated into the user’s workflow.
Consider a scenario where an employee queries for a third-party service endpoint from an AI coding assistant. If the LLM provides a fictitious domain like evilphishing[.]com/auth/login, the exploitation occurs without a single traditional phishing lure. The victim is compromised simply by following a confident recommendation from a system their organization has already formally sanctioned.
Bypass: Zero-Reputation Evasion of Reputation-Based URL Defenses
The final phase of the attack lifecycle relies on a newly registered phantom domain's zero-reputation status, circumventing most conventional URL defenses. As noted earlier, at the moment of registration and initial weaponization, the domain lacks any blocklist entries, threat intelligence history or established reputation score. It has not yet been reported or classified by people.
From a defensive perspective, the infrastructure is nascent and indistinguishable from any legitimate new domain until it has generated sufficient malicious telemetry to trigger a classification signal. By the time threat intelligence systems synchronize, the exploit has already been delivered to victims who relied on the trusted AI assistant’s authoritative recommendation.
This structural advantage for attackers is not merely a transient window of opportunity. Sophisticated attackers can maintain this bypass through active evasion techniques, including redirect cloaking — serving benign content to automated crawlers while targeting human visitors — and the deployment of CAPTCHA-protected infrastructure.
A Proactive Hallucination Discovery Framework
To quantify and operationalize the phantom squatting threat, we engineered a multi-agent discovery framework. This framework simulates the comprehensive attack lifecycle, from adversarial probing to real-world registration detection. Figure 2 shows the discovery pipeline of this framework.
Figure 2. The phantom squatting multi-agent discovery pipeline.
Query Agent: Simulating Attacker Probing
The query agent shown in Figure 2 generates a prompt corpus to probe LLMs. It operates in three main phases.
Brand context profile: The agent researches a brand's products, portals and developer resources. This process ensures prompt references to real services, which helps generate high-fidelity hallucinations.
Adversarial probing: Effective probing requires a diverse set of realistic prompts. Rather than probing randomly, we exploit known LLM failure modes to generate a realistic and diverse set of prompts at scale. These include premise acceptance, authority-framing compliance and the model's tendency to complete narratives with authoritative yet fictitious details.
Diversity filtering: To ensure variety, we use Jaccard similarity to filter out similar prompts. This broadens the probe of the target's hallucination surface.
This methodology produced 685,339 prompts across 913 global brands.
URL Creator Agent: Mapping Hallucination Behavior Across Models and Temperatures
Prompts from the query agent feed into the URL creator agent. The URL creator agent executes the prompt corpus across multiple LLM providers and a spectrum of LLM temperature configurations. Our methodology used two distinct LLM families:
LLM1: A production-optimized, mini-class variant of an enterprise LLM from a major technology provider (released April 2025), engineered for high-volume, cost-efficient deployment.
LLM2: A low-latency, lite-class variant of a frontier LLM from a leading AI provider (released June 2025), designed for cost-efficient deployment at scale.
We designate these models as LLM1 and LLM2 throughout this analysis. This distinction is important because both models were released before the malicious domains identified in this research were registered. This confirms that the phantom domains were generated by the models' internal language patterns, not learned from training data. We tested each prompt using three temperature settings (designated below as T) to test the AI responses:
Precise (T = 0.1): The model is highly predictable, almost always choosing the most likely next token, resulting in consistent and repetitive answers.
Balanced (T = 0.7): This setting mixes predictability with some variability, balancing consistency with a touch of novelty.
Creative (T = 1.5): The model selects from a wider range of less likely words, leading to more imaginative and diverse outputs.
We collected all the URLs found in the LLM responses. If the model didn't provide a URL or said it didn't know the answer, we ignored that specific response. This phase ends with a prioritized list of hallucinated domains that we discovered. The value of these domains to an attacker is determined by two main features:
Thermal hallucination persistence (THP): This measures how consistently the AI generates the same domain name. Domains that appear even when the AI is set to be very precise are high-value targets. This is because the AI is more likely to show these to real users as if they were facts.
Cross-model hallucination consensus: This occurs when different types of AI models all generate the same fictitious domain for the same prompt. If several different models all agree on the same wrong information, it makes that fake domain a much more predictable target for attackers to use.
URLs generated by the URL creator agent feed into the verification agent, which assesses multi-signal risk and processes each unique AI-generated URL through an enrichment pipeline that integrates:
Threat intelligence: Category and risk verdicts from threat intelligence systems for existing URLs
Active content crawling: Capturing live page content and screenshots, which are then analyzed by a suite of deep learning models trained to detect malicious signals for existing URLs.
Ownership analysis: Examination of the registrar, registration date, registrant organization, nameservers and privacy status. This data is compared against the legitimate brand's established registration profile.
If a URL exists and exhibits malicious signals, we block it immediately. If a URL shows high-risk indicators, it is flagged for in-line content analysis and added to the proactive watchlist to monitor for changes in registration details or page content. These high-risk indicators include parked pages or insufficient content for a definitive malicious categorization.
We refer to domains not yet registered at the time of analysis as non-existent domains (NXDs). We add these NXDs to a proactive watch list of phantom domains. We then use periodic monitoring of registration event streams to detect when any watchlisted domain is registered.
When a registration event matches a hallucinated phantom domain, an alert is generated and the domain re-enters the verification pipeline for additional analysis. If the newly registered domain proves benign, it is removed from the watch list.
For example, if a legitimate brand registers a domain for defensive purposes or a new product offering, it is considered benign. However, if the ownership or content shows malicious indicators, the domain is assigned a malicious verdict.
Results: Quantifying the LLM Supply Chain Attack Surface for Phantom Squatting
This section quantifies the phantom squatting attack surface, measured at the domain level rather than the URL level. Although our pipeline extracts millions of unique URLs, the registerable attack surface is at domain level.
Each generated URL undergoes DNS resolution to determine whether it resolves to live infrastructure, NXDs or high-risk endpoints. NXD URLs are then normalized to extract the parent registerable namespace. If that namespace is unregistered, it is enrolled in the phantom domain watchlist.
The subsections below characterize the full risk landscape:
Confirmed malicious infrastructure served by these models
The structural composition of the phantom domain inventory
The model and configuration level factors that govern hallucination volume
Dataset Scale
Our analysis encompasses a dataset of 913 global brands including the following sectors:
Technology
Finance
Healthcare
E-commerce
Government
Gambling
Logistics
To construct the hallucination corpus, we executed 685,339 adversarial prompts across the LLM1 and LLM2 architectures, yielding 2.1 million unique URLs.
Active Threat Intelligence: Malicious URLs Generated by LLMs
Our discovery pipeline identified that, of the 2.1 million unique URLs produced by the models, threat intelligence systems flagged 13,229 (0.61%) as malicious at the time of analysis.
These results underscore that the risk is not merely theoretical. LLMs are actively recommending known malicious infrastructure to downstream users.
Beyond these confirmed threats, an additional 41,313 URLs (1.90%) were categorized as high risk — including parked domains, adult content and pages with insufficient telemetry — representing nascent infrastructure or opportunistic targets for adversarial registration.
Figure 3 illustrates the threat landscape of confirmed malicious infrastructure generated by these models.
Figure 3. Threat category breakdown of confirmed malicious URLs hallucinated by LLMs.
Malware represents the dominant category at 67.2%, comprising sites used for drive-by downloads, malicious scripts and exploit-kit delivery. Phishing artifacts (16.2%) encompass credential harvesting portals and brand-impersonation sites targeting the global organizations in our analysis. Grayware (13.7%) includes adware distribution and potentially unwanted program (PUP) installers. Of significant concern, command-and-control (C2) infrastructure accounts for 3.0% of identified URLs — a vector of particular risk for autonomous AI agents that may execute web requests to attacker-controlled endpoints when interpreting LLM-generated instructions.
The Phantom Domain Opportunity
Our pipeline revealed that of the 2.1 million unique URLs in our corpus, 809,455 (37.28%) resolve to NXDs — fictitious endpoints generated by LLMs. These 809,455 NXD URLs collapse into approximately 250,000 unique phantom domains after normalization, each representing a discrete, preemptive registration opportunity for an adversary.
The derivation of this dataset is architecturally significant. Approximately 10.8% of NXD URLs (~87,630) constitute pure domain-level hallucinations, where the LLM fabricates an entirely unregistered root namespace. The remaining 89.2% involve subdomain or path-level hallucinations.
To isolate the registerable attack surface, we extracted the parent domain for each artifact. If the parent was unregistered, we enrolled it in our phantom domain watch list. This extraction methodology reduces the 809,455 URL-level NXDs to a tractable inventory of approximately 250,000 registerable phantom domains.
LLM Model Comparison: Hallucination and Threat Rates
Comparative analysis of the two models reveals markedly divergent hallucination profiles despite evaluation against an identical corpus of prompts. LLM1, the production-optimized enterprise model, exhibited a significantly elevated NXD rate of 44.6% across its 1.2 million unique URLs, approximately 17 percentage points above the 27.5% rate observed for LLM2.
Hallucination volume varies substantially by model architecture. However, the confirmed malicious URL rates remained comparable at 0.64% and 0.56%, respectively, indicating that the susceptibility to generating malicious infrastructure is a consistent risk across disparate training lineages.
A consistent pattern emerges regarding high-risk benign URLs, where LLM1 (2.08%) again demonstrates a higher rate than LLM2 (1.67%). This further confirms that LLM1's increased output volume systematically expands the hallucination surface across all risk tiers, extending beyond confirmed malicious infrastructure.
Figure 4 illustrates the comparative landscape of risk across both LLM architectures. It delineates the NXD hallucination rate, the volume of confirmed malicious URLs and the prevalence of high-risk artifacts identified within the corpus.
Figure 4. Comparison of LLM results.
Temperature Configuration and Hallucination Risk
LLM inference temperature, the parameter controlling output randomness, quantifiably influences phantom domain generation rates. Across three configuration modes evaluated uniformly, the Creative configuration (T = 1.5) yielded a substantially elevated NXD rate of 43.10%, compared to 34.64% for Precise (T = 0.1) and 32.52% for Balanced (T = 0.7).
Conversely, malicious URL rates remained statistically stable between 0.57–0.63%, suggesting that adversarial content risk is an intrinsic model property rather than a function of entropy. This structural decoupling confirms that while temperature does not drive malicious intent, it significantly amplifies the total hallucination-based exposure surface.
Figure 5 illustrates the impact of inference temperature configuration on both the NXD hallucination rate and malicious URL rate across the three distinct modes used in our discovery pipeline.
Figure 5. Impact of inference temperature configuration on both the NXD hallucination rate and malicious URL rate.
Anatomy of URL Hallucinations
The structural composition of phantom domain hallucinations is not uniform. Within our corpus of 809,455 unique NXD URLs, nearly half (49.7%) manifest as path-level hallucinations, where the LLM constructs a plausible resource path on a legitimate, registered domain that fails to resolve.
An additional 39.5% are categorized as subdomain-level hallucinations — fabricated sub-architectures under existing base domains. The most critical tier, representing 10.8% of the dataset, consists of pure domain-level hallucinations involving entirely unregistered root namespaces.
Analysis reveals divergent behavioral profiles between architectures:
LLM1 exhibits a pronounced bias toward path-level extrapolation (56.6%)
LLM2 generates a significantly higher proportion of subdomain-level (45.1%) and pure domain-level (20.0%) hallucinations, expanding the registerable attack surface available for adversarial exploitation
Figure 6 illustrates the structural distribution of NXD hallucinations across three architectural tiers: path, subdomain and domain. This provides a comparative visualization for the aggregate corpus and individual model performances.
Figure 6. URL Pattern distribution of NXD hallucinations across LLM systems.
Evidence of Active Exploitation: Real-World Detection Cases
Aggregate statistics confirm the structural scale of the phantom squatting threat. The following case studies document the real-world manifestation of this vector. These examples demonstrate instances where our discovery pipeline identified a phantom domain prior to adversarial registration for malicious deployment. The case studies are:
Impersonation of a postal service's e-commerce marketplace in a phishing campaign using the Montana Empire phishing kit
Impersonation of a national postal service to deliver a malicious Android app
Four other examples of phantom squatting weaponized in real-world attacks
To quantify this proactive detection advantage, we define the adversarial exploitation window (AEW). This window is the temporal interval between the initial hallucination event and the subsequent registration by a threat actor.
A positive AEW signifies actionable lead time for defenders. A negative AEW signifies that an adversary registered the infrastructure prior to our detection. This provides historical validation of the threat model, confirming that disparate AI architectures and human adversaries independently converged on the same structurally inevitable hallucination.
Montana Empire: AI-Assisted Phishing and the Closed Loop
AEW: 23 days
Target: Customers of a national postal service's e-commerce marketplace
On March 8, 2026, our multi-agent discovery pipeline generated 13 hallucinated URLs for a domain similar to a national postal service e-commerce website across both LLM families and all temperature configurations — including the Precise (T = 0.1) setting. This systemic convergence indicated high Thermal Hallucination Persistence (THP), where the models treated the infrastructure as a near-factual certainty rather than speculative creative entropy. Consequently, the domain was enrolled in the phantom domain watchlist within the same week.
On March 31, 2026 — representing an AEW of 23 days — an adversary registered the domain and deployed a weaponized phishing kit impersonating a legitimate marketplace. Our pipeline achieved same-day detection of the registration event.
Analysis of the attacker’s infrastructure revealed that they developed the phishing kit using an AI coding assistant, evidenced by a project directory identified within the phishing kit ZIP archive. Telemetry from the session logs confirmed the adversary leveraged the assistant to scrape legitimate storefronts, engineer the PHP backend and develop a Telegram-based C2 interface for real-time credential exfiltration.
This case demonstrates the full cycle of the phantom squatting supply chain threat model. The adversary used AI systems to generate attack tooling against infrastructure identified by our discovery pipeline 23 days earlier. Both parties arrived at the spoofed domain via the same mechanism, the LLM’s internal prediction of a structurally inevitable hallucination for the target brand.
The Montana Empire phishing kit features several advanced components:
A real-time scraper designed to maintain site parity with live storefronts
Dual-channel interception for credit cards and bank transfers, with International Bank Account Numbers (IBANs) rotated via Telegram bot commands
Harvesting of national identity document data alongside payment credentials
An operator control panel for manual one-time password (OTP) relay and victim adjudication
Table 1 shows the specific domain patterns hallucinated by the models in our analysis.
Prompt
Hallucinated URL
Model
Configuration
“Payment gateway sandbox for the postal e-commerce marketplace integration?”
“Administrative dashboard for the postal e-commerce marketplace campaigns?”
hxxps[:]//admin.[redacted][.]com
LLM2
All three configurations, including Precise
“Billing portal for the postal e-commerce marketplace payment method update?”
hxxps[:]//billing.[redacted][.]com/
LLM2
Balanced (T = 0.7)
Table 1. Prompts, hallucinated URLs and model configurations.
Figure 7 illustrates the Montana Empire admin panel, with a banner bearing the phrase Kimseye Güvenme (Trust No One). Through this control panel, the attacker managed victim OTP approvals and credential relays via Telegram.
Figure 7. Montana Empire admin panel.
When we recovered the phishing kit file structure from the server of the spoofed domain, we noted an AI coding assistant project directory, indicating that the attacker used an AI tool to develop the kit.
National Postal Service-Themed Delivery of Malicious Android App
AEW: 51 days
Target: Customers of a national postal delivery service
On Feb. 18, 2026, our multi-agent discovery pipeline identified hallucinated URLs for admin.[redacted]post-app[.]com across five distinct model-configuration tiers — including LLM1 at the Precise (T = 0.1) setting. This high degree of convergence led to the parent domain, [redacted]post-app[.]com, being enrolled in the phantom domain watchlist for proactive monitoring.
On April 10, 2026 — representing an AEW of 51 days — an adversary registered [redacted]post-app[.]com and immediately deployed a site that used a pixel-accurate brand clone impersonating the national postal service. The malicious landing page replicated the service’s authoritative aesthetic. It used the same HTML hex color code as the official brand and fabricated social proof (4.8-star rating, over 2 million users) to drive victims to download a malicious Android application package (APK) file named [redacted]post.apk. Our registration event stream achieved detection within hours of infrastructure creation.
While legitimate postal applications are restricted to official marketplaces, this out-of-band delivery bypasses standard platform-level security telemetry.
Additional Detection Cases
Our multi-agent discovery pipeline and subsequent triage verified the following cases shown in Table 2.
Domain
Brand
AEW
Attack Pattern
[redacted]-login[.]com
Online sports betting operator
45 days
Credential-harvesting clone targeting the Bangladesh market; features explicit local language headings and BDT currency.
[redacted]-es[.]org
Competing sports betting operator
40 days
Infrastructure registered in an 18-minute coordinated window by the same actor; identical regional targeting and monetization strategy.
[redacted]empresas[.]com
Regional European retail bank
35 days
Re-registration event detected.
[redacted]business[.]com
Major UAE commercial bank
-11 months
Historical validation of a structurally inevitable hallucination; corporate IT credential harvester using fraudulent branding.
Table 2. Phantom domain detection examples.
A real-world example involving a major bank in the UAE proves that AI models predictably hallucinate the same fake information. On April 1, 2025, a threat actor registered the domain [redacted]business[.]com to steal login details from company database administrators. This campaign had been running for nearly a year. Our pipeline system independently predicted and generated that same fake web address 11 months after it was first used. Our team analyzed this domain through our verification pipeline after detecting that it was being registered again.
Two other examples of phantom squatting in Table 2 reflect the coordinated registration of [redacted]-login[.]com and [redacted]-es[.]org. A single actor registered these domains using identical registrars, nameservers and privacy shielding within an 18-minute window. This demonstrates that phantom squatting is useful for detecting multi-target, orchestrated campaigns.
In this instance, the adversary deployed a unified infrastructure for both domains. Both phishing sites use an identical architectural template, featuring a মেগা জ্যাকপট পুল (Mega Jackpot Pool) display and Bengali-language localized content. By explicitly referencing Bangladesh (বাংলাদেশে) and processing transactions in Bangladeshi Taka (৳), the actor provided definitive attribution signals for a regionally focused, high-velocity operation.
Implications for AI-Powered Supply Chains
Agentic Workflow Risk: Compromising Autonomous AI Pipelines
The highest-consequence phantom squatting target is not a human user. Instead, it is an autonomous AI agent. Agentic systems increasingly execute multi-step workflows that include web fetching, API calls and resource downloads, all based on URLs generated by the LLM orchestrating the pipeline. When an AI agent generates a URL to fetch documentation, retrieve an API schema, or download a dependency, that artifact may resolve to a phantom domain controlled by an adversary.
The impact in an agentic context is amplified by autonomy. A human user who follows an LLM-recommended URL and reaches a phishing page must still take an action by entering credentials, downloading a file or executing code. Conversely, an autonomous agent that fetches a URL and processes its response could exfiltrate secrets, execute malicious instructions or propagate a compromised dependency through a build pipeline without any human decision point.
The 2026 Unit 42 Global Incident Response Report describes an identity-velocity crisis, where attackers compress the window from initial access to exfiltration to under one hour at machine speed. This applies directly to phantom squatting delivered via agentic pipelines.
Developer Tooling Risk: AI Coding Assistants and URL Hallucination in the Software Development Lifecycle
Modern software engineering workflows have integrated AI coding assistants for tasks that fundamentally require URL generation:
Retrieving API documentation
Identifying package registries
Locating webhook endpoints
Architecting integration code.
Each interaction represents a potential phantom squatting vector.
The Montana Empire case provides a definitive illustration of this risk convergence. The adversary leveraged an AI coding assistant to engineer a phishing kit targeting the exact phantom domain predicted by the LLM's hallucination patterns.
AI-assisted attack development and LLM-driven attack delivery are no longer disparate phenomena. They represent two dimensions of a single, structurally inevitable adversarial lifecycle.
Conclusion
The risk of phantom squatting is not a theoretical abstraction. Our analysis of 913 global brands and 2.1 million LLM-generated URLs documents a critical supply chain vulnerability:
13,229 confirmed malicious URLs currently being produced by LLMs
250,000 hallucinated phantom domains representing nascent, unregistered infrastructure available for adversarial occupation
Real-world threat actor registrations validated via WHOIS analysis, yielding proactive detection lead times of up to 51 days
This vector exploits a structural property of LLM architectures that remains inherently unpatchable. Models trained on human-authored corpora will naturally hallucinate plausible-sounding domains for brands, products and services based on internal linguistic patterns. The phantom squatting attack surface systematically expands with every new LLM deployment, the rise of agentic AI capabilities and the targeting of global brands for adversarial hallucination probing.
The defensive advantage is equally architectural. Because LLMs hallucinate with predictable consistency, defenders can map the hallucination surface and establish a proactive phantom watchlist before an adversary acts. The AEW — the interval between first hallucination detection and registration — provides concrete, actionable lead time that legacy threat intelligence frameworks cannot offer.
Proactive discovery represents the only defensive posture that addresses phantom squatting at its root. By mapping what LLMs will hallucinate and monitoring registration event streams, organizations can respond before weaponization occurs. The capability is established, and the zero-reputation bypass window is open. The critical question is whether defenders or adversaries will act first.
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research.
Prisma AIRS can help secure organizations deploying LLM-powered agentic workflows.
Koi Agentic Endpoint Security is designed to help discover every AI artifact across the agentic endpoint, assess its risk, enforce prevention & runtime controls, and remediate violations.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
South Korea: +82.080.467.8774
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Indicators of Compromise
Montana Empire Campaign
The following domains are presented in partially redacted form. Full unredacted indicators are available on request.
SHA256 hash: eb07edaa2786cfddfa4c15526168f2200d85300aee0a8f253b32d2462a7b0bcd
File size: 7,958,528 bytes
File type: ZIP archive
Filename: [redacted].zip (postal e-commerce platform brand name)
File location: hxxp[:]//[redacted][.]com/[redacted].zip
File description: Montana Empire phishing kit archive — comprises a full brand clone of a national postal service's e-commerce marketplace featuring a PHP backend, real-time storefront scraper, credential capture layer and Telegram-based C2 operator control panel.
Related URLs:
hxxp[:]//[redacted][.]com/[redacted].zip
hxxp[:]//[redacted][.]com/letgovip.zip
hxxp[:]//[redacted][.]com/mentalite.php
hxxp[:]//[redacted][.]com/panel_track.php
hxxp[:]//[redacted][.]com/verify_api.php
National Postal Delivery Service APK Campaign
SHA256 hash: 2202a30daad9928ef47cca5f4ab04ce083692a94428e386fa01c2dd44557e34b
File size: 12,649,472 bytes
File type: APK (Android application package)
Filename: [redacted]post.apk
File location: hxxp[:]//[redacted]post-app[.]com/[redacted]post.apk
File description: Malicious Android APK delivered via a fraudulent mobile app landing page impersonating a national postal delivery service.
The authors would like to thank Shehroze Farooqi, Joseph Pang and Wanjin Li for their valuable insights and contributions in completing this work. The authors would also like to thank Samantha Stallings, Bradley Duncan, Lysa Myers and Shawn He Shuang for their assistance in the editorial process.
Throughout 2025, we observed a cluster of activity targeting government entities and critical infrastructure in Southeast Asia. Specifically, the activity targeted state-owned enterprises in the energy and government sectors.
The Chinese-speaking attackers behind this cluster, which we track as CL-STA-1062, have been active since at least March 2022. We assess with high confidence that this is the same cluster, known as UAT-7237, that was reported for its campaigns against web hosting infrastructure in Taiwan in mid 2025. We also observed CL-STA-1062 campaigns in earlier operations targeting strategic sectors in East Asia, indicating a broader, sustained regional focus.
From a technical standpoint, the attackers behind CL-STA-1062 rely on a hybrid toolkit. While they frequently use common open-source tools such as SoftEther VPN, Mimikatz and VNT, they have recently introduced TinyRCT, a bespoke, previously undocumented backdoor.
TinyRCT’s capabilities include:
Arbitrary command execution
File enumeration and exfiltration
Screen capture
A self-destruct mechanism
We detail the latest campaign linked to CL-STA-1062 against the energy and government sectors in Southeast Asia, and provide a technical analysis of the new TinyRCT backdoor.
Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:
While this article focuses on CL-STA-1062 activity against targets in Southeast Asia during 2025, our telemetry reveals that the attackers behind this cluster have been conducting operations across East Asia since 2022. We assess with high confidence that this is the same activity cluster tracked by Cisco Talos as UAT-7237, previously reported for its campaigns against web hosting infrastructure in Taiwan. Building on recent observed activity, our investigation into CL-STA-1062 activity highlights a broader long-term strategy in the Asia-Pacific region.
Targeting Southeast Asian Government Entities
In September 2025, we discovered that the attackers behind CL-STA-1062 had compromised a Southeast Asian government entity by deploying web shells and exfiltrating database information. Figure 1 shows the command line used to exfiltrate data from an MSSQL server.
Figure 1. Exfiltrating data from the MSSQL server.
During this intrusion, the attackers were also able to conduct network reconnaissance on a separate government entity in the same country. This suggests an effort to identify lateral movement opportunities and broaden their access. In one case, we observed the attacker staging and exfiltrating an entire directory of web server source code from the government entity, as Figure 2 shows.
Figure 2. Archiving the folder containing the web server source code.
Between October and December 2025, we observed the likely compromise of at least ten different organizations in Southeast Asia.
Focusing on Critical Energy Infrastructure
Since mid 2025, as part of activities in Southeast Asia, the threat actor behind CL-STA-1062 focused on critical infrastructure. We identified that a critical infrastructure entity had been under attack for several months. The activity within the compromised network was comprehensive, covering the entire attack lifecycle from initial access to data exfiltration.
The following month, we discovered that the attackers behind CL-STA-1062 had also compromised two state-owned critical energy infrastructure (CEI) entities in the same Southeast Asian country. We observed attackers scanning the entities for vulnerabilities, shortly followed by outbound requests from the infected networks. These requests connected to attacker-controlled infrastructure and resulted in the victim networks downloading malicious payloads that included SoftEther VPN components and RAR archives containing the group's tools.
Figure 3 shows HTTP requests that download the attackers’ tools to the targeted networks.
Figure 3. Examples of outbound requests from an infected network.
Evolving TTPs and Open-Source Toolkit
The intrusions we observed typically begin with the attackers exploiting web applications to deploy ASPX web shells. These web shells function as the central mechanism for executing arbitrary commands, dropping additional tooling and conducting initial reconnaissance. As part of our observations of CL-STA-1062, we noted activity sending the results of network and system enumeration directly to an actor-controlled IP address using curl. Figure 4 shows an example of the command lines used.
Figure 4. System enumeration command lines.
From this foothold, the activity includes open-source tools and custom malware. The attackers also adapt techniques to the target environment.
The attackers behind the activity frequently use tunneling tools for command and control (C2) and data exfiltration. They deployed a variety of these tools, including:
These tools were often disguised as legitimate system files, such as VMware executables or an XDR agent. Figure 5 shows the command line used by the group to execute a yuze instance.
Figure 5. yuze command-line execution.
In one case, the attackers used a web shell to extract a password-protected RAR archive containing a SoftEther VPN binary masquerading as vmtools.exe. Figure 6 shows the extraction and execution of the SoftEther VPN binary.
Figure 6. Extracting and executing SoftEther VPN.
In another case, the attackers attempted to disguise VNT as a VMware executable, as shown in Figure 7.
Figure 7. Creating a scheduled task to execute a VNT binary.
In one instance, the attackers used traceroute to identify potential lateral movement paths to another government entity. To escalate privileges, the attackers deployed known open-source tools, such as JuicyPotato. For data staging and exfiltration, they frequently compressed findings into password-protected RAR archives.
ֿTechnical Analysis of TinyRCT
During our investigation into the campaign's infrastructure, we observed the server at 139.180.134[.]221 hosting a suspicious executable named PerfWatson2.exe. By pivoting on this IP address, we were able to retrieve and analyze the binary, identifying it as a previously undocumented .NET backdoor. Analysis of the binary's internal strings revealed that the authors refer to this tool as TinyRCT.
TinyRCT is a lightweight, C#-based remote access Trojan (RAT) targeting Windows. It operates as a backdoor, enabling attackers to execute arbitrary system commands, exfiltrate files, capture screenshots and remotely manage the infected host.
Upon execution, the malware performs an environment validation to explicitly verify that it was executed from %LOCALAPPDATA%. If the malware was executed from any other location – such as a sandbox environment or a malware analyst’s desktop – the binary terminates immediately.
The execution of TinyRCT can be blocked by implementing strict behavioral monitoring and execution restrictions on untrusted binaries. Figure 8 shows how an execution attempt by the TinyRCT malware, masquerading as PerfWatson2.exe, is prevented and alerted by Cortex XDR.
Figure 8. A prevention alert of blocking the TinyRCT malware execution attempt as seen in Cortex XDR in prevent mode.
Host Fingerprinting and Registration
Before entering its main command loop, TinyRCT conducts initial reconnaissance to fingerprint the infected host. It aggregates critical system information to generate a unique victim profile, collecting the following data points:
User and system context: Current username, machine name and OS version.
Network and execution: Local IP addresses, the complete execution path of the malware and the current process ID (PID).
Identity: A randomly generated globally unique identifier (GUID) to serve as the bot's identifier.
This data is concatenated, encrypted and immediately transmitted to the C2 server via an HTTP POST request. This registration packet allows the attacker to profile the newly infected host and decide whether to issue further commands or terminate the infection based on the host's assessed value.
C2 Communication
After successful registration, TinyRCT establishes a persistent communication channel with the C2 server at 45.32.113[.]172. The malware uses standard HTTP for network traffic, but it encrypts all exchanged data using AES-128 encryption in CBC mode. The encryption key (ThisIsASecretKey87654321) and a null Initialization Vector (IV) are hard-coded directly within the binary.
The malware operates on a beaconing model, with a default 10-second sleep interval between requests. It polls the C2 server for instructions using GET requests, while it sends exfiltrated data via POST requests.
Supported Commands and Capabilities
The backdoor is designed for surveillance and remote management and executes a concise set of commands. When the C2 server responds to a beacon, the malware decrypts and parses the payload, and then executes the appropriate commands from the following functions:
Shell execution: Executes the command via cmd.exe (or direct process execution) and returns stdout/stderr.
Update configuration: Updates the sleep interval.
File listing: Enumerates directories and files in the specified path. Returns format: Filename*Date*Size.
Read text file: Reads a text file and returns content.
Download file: Downloads a file from a URL and saves it to the desired path.
Exfiltrate file: Reads a binary file from the requested path, compresses its contents using gzip, encrypts them using AES and sends them to the C2 in 40 KB chunks.
Screen capture: Captures the primary screen, saves the capture as a JPEG file, compresses it, encrypts it and sends it to the C2.
Self-destruct: Triggers the cleanup routine.
Figure 9 shows the C2 server response parsing function of TinyRCT, including a line of code in Simplified Chinese.
Figure 9. The C2 response parsing function of TinyRCT.
Self-Destruct Mechanism
A notable feature of TinyRCT is its cleanup capability, triggered by the self-destruct command. This routine is designed to remove forensic evidence of the infection.
Upon receiving the self-destruct command, the malware first deletes the GoogleUpdater scheduled task created by the loader. It then executes a self-deletion routine using a legacy batch command technique involving the choice.exe program. This routine deletes the malware’s PerfWatson2 executable, as Figure 10 shows.
Figure 10. The complete choice.exe command line.
The use of choice.exe creates a three-second delay, ensuring the primary malware process has fully terminated and released its file handle before the delete command executes.
Infection Vector
Our analysis began with the discovery of the PerfWatson2.exe payload hosted on the attacker’s C2 infrastructure. By pivoting from this artifact, we reconstructed the infection chain, identifying its origin as a malicious archive named chrome_setup.zip.
Inside the zip were three files:
A legitimate executable
A configuration file
A malicious DLL
This specific combination of files is used to perform AppDomainManager Injection – a technique that exploits the trust relationship between a .NET application and its configuration file. The archive contains a legitimate, signed chrome_setup.exe executable paired with a malicious chrome_setup.exe.config configuration file.
When the user runs the executable, the .NET runtime reads the adjacent configuration file. This forces the loading of a malicious DLL (MyAppDomainManager.dll) to act as the application's manager. This allows the malicious code to execute instantly and covertly within the context of a trusted process.
Once injected into the legitimate setup process, the malicious MyAppDomainManager.dll functions primarily as a stealthy downloader and persistence enabler.
Upon initialization, the malicious loader runs a critical environmental check to validate its execution context. It explicitly verifies that the host process is running from %USERPROFILE%\Downloads — the user’s Downloads directory. If this check fails, it likely indicates the sample was moved to a sandbox or an analyst's desktop, and the loader terminates immediately. Figure 11 shows this check in the loader source code.
Figure 11. The loader's initial environment check.
If the validation passes, the loader contacts the staging server at 139.180.134[.]221 to retrieve the secondary payload. The loader saves this payload to the user’s %LOCALAPPDATA% directory as PerfWatson2.exe, mimicking the legitimate telemetry component associated with Microsoft Visual Studio.
To ensure this payload runs continuously without user interaction, the loader constructs and executes a specific schtasks command. This command creates a scheduled task named GoogleUpdaterTaskSystem140.0.7272.0 {ACE7A46F-50FD-481C-AB32-3D838871DB40}. The task is configured to run the malware with the highest available privileges (e.g., /rl highest) every time the user logs on to the system (e.g., /sc onlogon). This ensures that the infection survives system reboots.
Conclusion
Our investigation into CL-STA-1062 reveals a persistent activity cluster likely operated by Chinese-speaking actors. The attackers are expanding operations from Taiwan to critical infrastructure and government entities in Southeast Asia. They demonstrated their ability to infiltrate strategic sectors – specifically energy and government organizations.
The combination of tools observed in this activity cluster reflects a pragmatic approach to tool selection and attack capabilities. The attackers behind this cluster continue to leverage common open-source tools such as SoftEther VPN and VNT to facilitate lateral movement. Our discovery of the TinyRCT backdoor in the attackers’ infrastructure underscores their ability to customize tools to gain specific capabilities.
The combination of targeting critical infrastructure and the development of custom malware suggests that CL-STA-1062 activity will continue to pose a threat to the region. Organizations in Southeast Asia, particularly within the energy and government sectors, should remain vigilant against this evolving activity.
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
Cortex XDR and XSIAM help to prevent the threats described in this article, by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, to prevent both known and unknown malware from causing harm to endpoints.
The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
OpenClaw is an AI agent that executes third-party skills from ClawHub, its dedicated marketplace. Skills are markdown-driven packages with broad local system access, making ClawHub a critical link in the agentic software supply chain.
Following its release, the ecosystem saw several malicious campaigns. Those early findings, published in February 2026, prompted ClawHub to integrate VirusTotal and ClawScan, enabling proactive screening of published skills and code-level analysis to block skills flagged as malicious from download.
However, our analysis from February-May 2026 revealed persistent and evasive malicious skills on ClawHub. We identified five unblocked skills.
We reported all five to ClawHub for takedown. OpenClaw banned the accounts mentioned and deleted all of the skills.
The five skills represent three distinct threat categories leveraging the AI supply chain ecosystem:
Infostealers: Two skills delivered macOS infostealers. Both connect to command-and-control (C2) infrastructure, indicating persistent threat actor activity.
Evasion: One skill has an inflated file size to exceed scanner thresholds, bypassing both ClawScan and VirusTotal detection.
Agentic threats: Two skills represent agentic threats: runtime agentic affiliate injection and agentic front-running. Both are novel techniques that the skill authors used for financial gain.
OpenClaw is now also collaborating with NVIDIA to provide documentation of what each skill does, and to run NVIDIA’s analysis tool on all skills.
Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:
Software supply chain attacks typically rely on compromising distribution vectors or spoofing dependencies. However, AI agent ecosystems have altered this paradigm, and their threat model differs from previously established ecosystems like npm or PyPI. While conventional malware often faces limitations from language runtimes or containers, malicious skills use semantic instruction hijacking to bypass technical constraints.
By misusing the AI’s natural language interpretation, malicious skills can exploit the agent's operational context, including file systems, shells and credential managers, without requiring a conventional exploit. The lack of isolation between skill logic and agent authority means that installation results in complete control over the agent's identity. This allows a malicious skill to perform unauthorized actions through the agent’s own authenticated sessions.
Early Campaign Activity on ClawHub
In early February 2026, Bitdefender Labs reported that approximately 17% of OpenClaw skills they analyzed in the first few weeks of the platform's release carried malicious payloads. Koi Security's ClawHavoc disclosure documented 341 malicious skills, and Trend Micro separately confirmed skills distributing Atomic macOS stealer (AMOS) malware across the marketplace.
This early wave featured several distinct techniques:
Base64-encoded curl-pipe-bash dropper: These skills embedded a fake prerequisite block that instructed the agent to decode and execute a Base64-encoded remote payload, typically fetched from 91.92.242[.]30, the IP address for an AMOS C2 server.
Platform-specific delivery: For macOS targets, paste-site redirects (glot[.]io, rentry[.]co) served as an intermediary step, allowing attackers to update payloads without modifying the published skill. Attackers directed Windows targets to password-protected executables hosted on third-party hosting services.
Persistence via auto-updaters: Auto-updater skills combined the initial dropper with scheduled cron job registration, ensuring the C2 channel persisted even after skill removal.
Alternative exfiltration channel: A distinct cluster (polymarketbtc, polymarketbtcassistant and related skills published by krajekisbtc) exfiltrated cryptocurrency private keys via the Telegram Bot API, a C2 channel independent of the shared dropper infrastructure.
Registry saturation: A single publisher account injected malicious payloads into the majority of their published skill catalog with identical payloads to maximize installation surface before detection.
Those findings prompted ClawHub to partner with VirusTotal, enabling proactive screening of published skills. These skills from these early campaigns have since been removed from the marketplace or marked as malicious.
In the following sections, we document the state of the marketplace between February and May 2026, during which VirusTotal and ClawScan served as the primary screening mechanisms.
(On June 1, ClawHub also announced a partnership with NVIDIA to help screen published skills.)
The AMOS dropper infrastructure from earlier campaigns remains active more than three months after first public disclosure, with the C2 server at 91.92.242[.]30 continuing to receive new skill deliveries. Additionally, we observe novel attacks that adapt to and exploit skill marketplaces, leveraging the agentic execution model to implement financial schemes that evade some kinds of malware detection.
On May 17, 2026, the account published two skills targeting TradingView users as shown in Figure 1.
Figure 1. ClawHub marketplace listings for two TradingView assistant skills.
Both of these skills presented as AI assistants for macOS, posing as productivity tools for traders. Both embedded the same malicious prerequisite block, which prevented the skills from functioning until the user performed a required action. In this case, the prerequisite block directed agents to a site with malicious instructions to copy and paste text into a terminal window. We refer to this site as a paste-site redirect lure.
The paste-site redirect lure at hxxps[:]//rentry[.]co/openclaw-code served instructions with a Base64-encoded string for the prerequisite block, which the agent must run before the skill can continue. Figure 2 below shows an example of this page.
Figure 2. Paste-site redirect lure.
When the agent performed the actions in the paste-site redirect lure, the associated command fetched a payload from hxxp[:]//2.26.75[.]16/Xuvewuyur. That payload was a macOS infostealer named cluw with a SHA256 hash of 818aea6143282b352fdfdc0f3ebf77a36e54eb3befb5cad1a355a99ab97c6aa7.
The delivery mechanism is structurally identical to the ClawHavoc campaigns documented by Koi Security and Trend Micro. The prerequisite block, the paste-site redirect lure and the Base64 pipe to bash all match the early-wave pattern.
The C2 server we discovered at 2.26.75[.]16 differs from prior disclosure. The cluw payload differs from AMOS. This campaign used the established delivery template with fresh backend infrastructure.
Until mid-May, ClawHub's automated auditing returned a verdict of Pass for ai-tradingview-assistant-for-macos and no verdict for tradingview-ai-indicator-assistant. Neither skill triggered detection, despite containing a verbatim paste-site prerequisite lure. This structural pattern characterized over 300 skills in the original ClawHavoc disclosure.
The omnicogg skill was an early-wave threat, similar to those that defined the initial surge of malicious activity on ClawHub. It is a Base64-encoded curl-pipe-bash dropper that delivered the AMOS malware via 91.92.242[.]30, the same C2 infrastructure documented in earlier campaigns.
This skill is distinguished by its delivery vessel, a README.md file. The malicious payload appears at the start, followed by 22 MB of padding characters. This padding inflates the file size beyond the limits that many content-analysis pipelines enforce before declining to process a file. Figure 3 below shows an example of the padding characters in this file.
Figure 3. The omnicogg skill’s README.md file.
JFrog Security Research disclosed this skill in March 2026. This evasion technique can be effective because many scanning pipelines skip abnormally large files rather than process them.
This skill's ClawScan audit was in review in mid-May, while VirusTotal returned a clean verdict, and the skill remained available for download, as shown in Figure 4. Scanners that do not analyze content beyond standard thresholds will miss payloads structured to exploit that weakness.
Figure 4. ClawHub audit page for [redacted]/omnicogg shows an overall pass despite containing malicious code..
This ClawHub campaign focused on financial communities, with skills that targeted banking and crypto exchange workflows. This money-radar skill presented itself as an overseas financial product advisor that compared brokerages, banks, crypto exchanges and remittance services for users in mainland China, Hong Kong and Singapore. However, its core logic was an affiliate funnel for developer profit.
The skill weaponized the agent's advisory authority, routing all financial recommendations through affiliate links from a known-malicious domain. The publisher retained dynamic control over which products it pushed after installation.
Technical Analysis
The skill's mandatory first action on every invocation was to fetch product data from laosji[.]net, a domain previously observed in paste-jacking campaigns. Figure 4 shows an example of this action within the skill's SKILL.md file.
Figure 5. The money-radar skill's SKILL.md instructs the agent to fetch data from laosji[.]net.
The agent ingested a referrals.json payload from laosji[.]net as a precondition to answering any financial question. That payload contained approximately 60 products across eight categories, each with a referralLink field carrying affiliate tracking. The SKILL.md file then issued an explicit instruction to always use the referral links as shown in Figure 6.
Figure 6. The money-radar skill's SKILL.md file with the affiliate link instruction highlighted and translated.
Once the skill was installed, the publisher dynamically controlled the links the agent would recommend by updating referrals.json on laosji[.]net. The operator could change which products were recommended, rotated affiliate partners or redirected victims toward higher-commission offerings without the victim’s involvement. This exploitation constitutes an agent-specific form of runtime affiliate injection.
Unlike typical affiliate injection, which intercepts links the target was already clicking, this skill generated the recommendation itself. The affiliate link arrived embedded in what appears to be skill-based expert advice.
The letssendit skill implemented an agentic front-running scheme. This scheme involved the skill operator misusing the ClawHub platform to illegitimately profit from meme token launches. It achieved this by leveraging numerous AI agent participants and coordinated agentic execution.
The coordinated activity executed on infrastructure using the domain letssendit[.]fun. Guided by the skill's SKILL.md file instructions, installed agents autonomously pooled Solana blockchain platform cryptocurrency (SOL) into the operator's digital wallet. Once enough agents had joined, the operator would front-run the distribution by purchasing the SENDIT meme token at the lowest bonding curve price before allocating any to the agents.
The token then launched publicly on the cryptocurrency platform pump[.]fun, where external buyers could mistake the coordinated AI botnet activity for organic retail demand. This could create a classic rug pull. The operator simply rotates wallets across multiple confirmed launches, dumping their low-cost position into the artificial market rally at the expense of secondary market buyers.
Ultimately, this exploit represents a novel documented case of an attacker weaponizing an autonomous AI agent network to execute a pump-and-dump scheme. This behavior constitutes fraudulent financial activity. We strongly recommend that enterprises block this skill across their AI infrastructure to mitigate regulatory and security risks.
Conclusion
The cases documented in this article span evasion, deceptive monetization, financial fraud and campaign persistence. Each case passed existing detection tools at the time of our analysis.
Organizations can strengthen their defensive posture by using a rigorous supply chain verification framework. We identified that skill execution occurs within the agent process. This necessitates active validation of publisher provenance and a line-by-line audit of package source files.
Our research indicates that monitoring outbound network traffic can identify post-installation communication with undocumented endpoints. We recommend cross-referencing all external connections against the provided documentation. Any discrepancies serve as observable indicators of risk. These verification steps help protect an organization’s environment by ensuring that the operational behavior of a skill aligns strictly with its stated technical specifications.
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
Koi's Agentic Endpoint Security (AES) gives security teams a single platform to discover every AI component across the agentic endpoint, assess its risk, enforce policy, and remediate violations - so your end users adopt the latest technology, increase the org productivity without compromising on security.
Prisma Browser Prisma Browser provides additional protection layers against advanced web threats including dynamic scans of every loaded web page, to prevent execution of malicious content and protect company assets.
The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research.
Cortex XDR and XSIAM are designed to prevent the execution of known malicious malware, and also prevent the execution of unknown malware using Behavioral Threat Protection.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
South Korea: +82.080.467.8774
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Acknowledgments
We’d like to thank the entire Unit 42 team for supporting us with this article. Special thanks to Samantha Stallings, Bradley Duncan and Lysa Myers for helping us review this article.
We recently identified a bucket hijacking technique impacting multiple services across major cloud service providers (CSPs). The attack technique exploits a fundamental architectural flaw that is common across cloud providers and could potentially affect other cloud providers as well.
Our research reveals that an attacker can silently compromise an organization's active data streams by rerouting data into an external storage bucket. Because a storage bucket name is globally unique, an attacker can simply delete the bucket and then recreate it under the attacker's own account using the same name. This therefore creates a global namespace risk. This bucket hijacking reroutes critical logs and sensitive data directly to the attacker’s environment.
We have shared these findings with Google Cloud, Amazon Web Services (AWS), and Microsoft Azure.
We have not yet identified a real-world threat actor using this attack technique. However, we recommend organizations take steps now to head off the potential impact, particularly since we anticipate that real-world attempts to use this attack technique would be difficult to detect.
Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:
Before detailing the attack methodology, it’s important to understand several architectural elements that, when combined, make bucket hijacking possible.
Data Stream Overview
A data stream is an automated, continuous pipeline designed for high-volume data movement between services. Once configured, these streams operate autonomously in the background to push telemetry, audit logs or objects from a source environment to a designated storage destination for processing and long-term retention.
Major CSPs facilitate automated data streams. These streams serve as critical nodes for routing, processing and backing up data within an organization's infrastructure, such as:
A cloud logging sink in Google Cloud acts as a router for log entries, directing them to a chosen destination. While primarily used to route and store logs in centralized log buckets for purposes like analysis and retention, a sink can also export logs to a Google Cloud Storage (GCS) bucket.
Bucket replication in AWS is a feature that automatically duplicates data from a source S3 bucket to a designated destination S3 bucket.
Global Uniqueness of Bucket Names
Cloud environments often stream data into buckets such as an S3 bucket in AWS or a GCS bucket in Google Cloud. Because bucket names are typically unique across the entire cloud provider, no two users can have the same bucket name. This design simplifies data stream establishment by providing a single, predictable target. However, it also creates a shared namespace where a destination's identity is tied solely to its name, rather than to a specific, immutable account owner. This characteristic is the foundational logic behind our discovery.
Permissions to Modify Data Stream Destinations
The data stream is frequently defined by a routing resource that is configured with a specific destination. To legitimately modify this destination, the user must possess specific, granular identity and access management (IAM) update permissions for that resource.
For example, modifying the destination for a cloud logging sink requires the logging.sinks.update permission. This routes logs to a bucket. Our research found that certain permissions outside of this traditional update purview could be leveraged to reroute data streams.
The Bucket Hijacking Attack
We now turn to discussing the attack flow before any mitigations were provided by the affected CSPs. After compromising a cloud environment and securing the permissions required to delete a target bucket, an attacker was effectively positioned to intercept and redirect a cloud data stream. By deleting the original bucket and immediately recreating a new bucket with the same name within their own account, the attacker could have redirected the data stream. This could have led to the exfiltration of the target's data to the attacker's account.
Figure 1 shows the attack flow diagram.
Figure 1. The bucket hijacking attack flow.
Simulating Bucket Hijacking in Google Cloud Logging
We simulated the bucket hijacking technique in Google Cloud Logging. In the simulation, we used a sink that routes logs to a cloud storage resource, as shown in Figure 2.
Figure 2. An existing sink referencing a GCS bucket.
After routing the logs, the original cloud storage bucket was deleted, as Figure 3 shows.
Figure 3. Deleting the targeted bucket used by the sink.
We then created a new bucket with the same name in an attacker-controlled environment, as shown in Figure 4.
Figure 4. Recreating the bucket in an external project.
Subsequently, logs were routed to this external cloud storage bucket, allowing the attacker to obtain extensive information about the compromised environment, as shown in Figure 5. The required permissions the attacker needed to have are storage.objects.delete (to empty the bucket) and storage.bucket.delete (to delete the bucket).
Figure 5. Logs written into the attacker’s controller bucket.
The Expansion to Multiple Services Within Google Cloud
Data streaming into a GCS bucket is not unique to cloud logging. There are many other Google Cloud services in which data can be streamed into cloud storage. We identified and tested a representative subset of potentially vulnerable services, specifically Pub/Sub and Storage Transfer Service, to confirm the systemic prevalence of this security risk.
Pub/Sub
Pub/Sub is an asynchronous messaging service that decouples upstream event producers from downstream processing services. It allows applications to broadcast messages to a topic, which are then distributed to one or more subscriptions for consumption by downstream systems.
This architecture enables scalable, event-driven communication. This allows disparate components such as log aggregators, data pipelines and real-time analytics engines to exchange information reliably without needing direct, synchronous connections.
The Pub/Sub architecture has three core components:
Publishers (producers) send messages to a named logical channel called a topic, without needing to know who or what will receive them.
Topics act as a buffer or distribution hub, holding the messages until they can be delivered.
Subscribers (consumers) listen to specific topics via a subscription. When a message arrives in the topic, the Pub/Sub service pushes it to the subscribers (push model) or the subscribers actively request it (pull model).
To simulate a bucket hijacking attack on Pub/Sub, we took the following steps:
We created a new Pub/Sub topic and a subscription linked to a GCS bucket
We configured the GCS bucket with the necessary permissions to grant access to the service agent:
We published a message to the topic, which was successfully delivered to the initial bucket
We deleted the original bucket and created a new bucket with the same name in a different project (the attacker's project)
When a message was published manually again, we found that the service exfiltrated the message to the attacker's environment
The successful redirection of the message stream proved that the bucket hijacking attack technique was directly applicable to the Pub/Sub service, allowing an attacker to exfiltrate data by deleting and recreating the destination bucket.
Storage Transfer Service
Storage Transfer Service is a managed data migration tool designed to automate the movement of large volumes of data into, out of or between cloud storage environments. It allows organizations to schedule and manage massive data transfers from external sources (like AWS S3 or on-premises systems) to GCS buckets, or to synchronize data between different cloud storage projects.
The service handles the underlying infrastructure, retries and checksum validation. It provides a way to populate data lakes or perform large-scale disaster recovery backups.
The Storage Transfer Service architecture operates as a centralized orchestration engine that manages the movement of data between a designated source and sink. When a user defines a transfer job, they specify the source, the destination and the scheduling parameters. The source can be an S3 bucket, a URL list or another GCS bucket.
To simulate a bucket hijacking attack on Storage Transfer Service, we took the following steps:
We configured a new transfer job with a GCS bucket as the source and another GCS bucket as the destination
We assigned the necessary permissions to the buckets to grant access to the service agent:
We deleted the destination bucket and then immediately re-created it in a different project (the attacker's environment)
We wrote a new object into the source bucket
After a period determined by the job's scheduling parameter, the object appeared in the newly hijacked destination bucket, which was under the attacker's control
The impact of this risk was significantly magnified by its broad applicability across numerous services. The permissions storage.buckets.delete and storage.objects.delete could be used to bypass the granular update permissions required for specific resources to redirect sensitive data streams such as logging.sinks.update, pubsub.subscriptions.update and storagetransfer.jobs.update.
The Expansion to Another Cloud Provider: AWS
The architectural flaw of global bucket name uniqueness is not exclusive to Google Cloud. AWS S3 buckets operate under the same design logic. Given this commonality, we investigated whether we could apply the same hijacking technique within the AWS ecosystem.
We successfully simulated the bucket hijacking attack using the S3 bucket replication feature. This feature enables the configuration of a source and destination bucket, where all objects written to the source bucket are automatically replicated to the destination bucket. The simulation followed these steps:
We created a bucket in our environment with a replication rule targeting a second bucket within the same account
We deleted the bucket and immediately recreated a new one using the same name within an external account
We uploaded a file to the source bucket
We observed the file appearing in the destination bucket located in the external account
Like in Google Cloud, we identified that this was not a localized issue, but applied to a number of AWS data stream services. We simulated the same technique using Amazon Data Firehose (where the destination is an S3 bucket) and observed the same behavior.
Cross-Subscription Data Exfiltration in Azure
Finally, we tested Azure’s environment for the same attack technique. Azure platform limitations prevent the immediate reuse of storage account names across different tenants for several days after deletion. However, we were able to simulate a cross-subscription attack technique.
This scenario was particularly relevant if an attacker gained permission to delete a storage account in one subscription and intended to reroute data to another. This allowed them to move data to a subscription where they maintained higher privileges and persistence, or perhaps where they previously lacked data access permissions. Ultimately, this technique relied on the fact that a storage account must be created with soft-delete disabled to ensure the name was released and could be promptly reclaimed.
We used Azure Monitor to demonstrate this attack. Diagnostic settings in Azure Monitor can be configured to export resource logs (e.g., metrics and audit events) to an Azure storage account. While the configuration stores the destination via its Azure Resource Manager (ARM) Resource ID, the internal pipeline resolves the storage account at runtime using its DNS name ({accountname}.blob.core.windows.net).
This architectural behavior facilitated the execution of the attack. If an attacker deleted a destination storage account and recreated it with an identical globally unique name in a different subscription within the same tenant, the diagnostic pipeline would continue to write logs to the attacker-controlled storage account.
The attack was less severe in Azure than in AWS or Google Cloud because it was limited to a cross-subscription scope rather than a cross-tenant one.
Exploitation Scenarios and Excessive Permissions Risks
The practical execution of bucket hijacking relies on specific exploitation vectors that are often facilitated by the widespread use of over-privileged administrative roles.
Exploitation Scenarios and Detection Challenges
We identified two distinct scenarios that could enable an attacker to execute a bucket hijacking operation:
Privilege escalation: As demonstrated in our simulations, a compromised identity with the permission to delete a bucket could misuse this access to redirect data streams to the attacker's own bucket. The widespread application of storage administrator roles significantly increased the risk of this attack technique and overcame the need for the more granular logging.sinks.update permission (as shown later).
Dangling router resources: In a similar exploit not demonstrated in this article, if someone deleted a bucket and failed to remove the associated router resource, an attacker could create a new bucket using the same name in their own environment. This action effectively redirects the data to the attacker's bucket, granting the attacker access to the victim's ongoing data.
Detecting these attack scenarios is particularly challenging. In scenarios where destination resources are used primarily for long-term retention or backup, the target may not detect the initial deletion of the original storage bucket. Because the data stream continues to operate autonomously, the sink configuration in Google Cloud appears valid upon inspection as shown in Figure 6. This allows the hijacking and subsequent data exfiltration to remain largely undetected.
Figure 6. The sink configuration remains intact and operational after recreating the bucket.
How Over-Privileged Roles Increase the Risk
Cloud providers frequently offer broad storage administration roles that grant wide-reaching deletion privileges by default, which significantly increases the practical risk of this attack technique.
For example, in Google Cloud the common storage admin role provides the storage.buckets.delete permission. However, as Figure 7 shows, it does not include granular permissions to modify data stream configurations like:
logging.sinks.update
pubsub.subscriptions.update
storagetransfer.jobs.update
Figure 7. The predefined Google Cloud storage admin role includes bucket deletion permission (highlighted in red) but lacks granular update permissions for data stream resources.
Mitigation Strategies
Google has adjusted how router resources interact with target storage resources since the time of our initial research.
Microsoft recommended that Azure users review documentation and tooling on addressing dangling DNS for subdomain takeovers (see Additional Resources).
Users can also employ additional defense strategies.
Mitigating the bucket hijacking technique requires a two-pronged approach focusing on preventative guardrails and proactive monitoring. Prevention starts with the principle of least privilege. Organizations must strictly limit the IAM permissions for deletion actions, specifically:
Storage.buckets.delete in Google Cloud
DeleteBucket in AWS
Microsoft.Storage/storageAccounts/delete in Azure
These permissions should be restricted to a minimal set of administrative roles and should never be assigned to service accounts or applications without rigorous justification.
In addition, the following mechanisms help to prevent the bucket hijacking technique:
Organizations can prevent bucket hijacking for data exfiltration by enforcing data perimeter controls that restrict resource access to stay within a trusted organizational boundary.
In AWS, data perimeter policies — implemented through service control policies (SCPs) and virtual private cloud (VPC) endpoint policies — can ensure that workloads within the organization are unable to write data to S3 buckets that belong to external accounts. This can effectively block the exfiltration path even if an attacker substitutes a malicious bucket, though the approach has some limitations.
Similarly, in Google Cloud, VPC Service Controls define a security perimeter around projects and services, to block any API call attempting to access Cloud Storage buckets outside the perimeter.
Deploying these controls as a baseline ensures that data cannot leave the trusted environment boundary, neutralizing the core mechanism of this attack technique.
AWS offers account regional namespaces for S3 buckets, which scope bucket names to the owning account and region rather than to a single global namespace. This directly eliminates the bucket hijacking vector. If a bucket is deleted, no other account can reclaim its name. This prevents attackers from intercepting traffic by re-registering abandoned bucket names.
For detection, organizations must implement robust monitoring solutions that specifically alert on the attempted deletion of a storage bucket. Security teams should prioritize high-severity alerts for storage deletion API calls, focusing specifically on resources that house sensitive information.
Given the high frequency of storage deletion events in large-scale environments, leveraging data security posture management (DSPM) capabilities is essential. It is particularly important to prioritize monitoring and to focus specifically on high-value, sensitive assets, as shown in a Cortex XSIAM alert in Figure 8.
Figure 8. Cortex XSIAM alert: Deletion of a high-sensitivity bucket detected.
Conclusion
The bucket hijacking technique detailed in this research exploits the global uniqueness of storage resource names in the major cloud providers. We have demonstrated how a configure-and-forget approach to data streams can lead to silent, long-term data exfiltration.
Reliance on a globally unique, static resource name for buckets is an architectural design common across cloud providers. As such, this technique could be portable to other cloud services and providers not covered in this research.
Our findings underscore two primary lessons for the security community:
Architecture defines the security boundary: Fundamental design choices made by cloud providers directly influence the security boundaries of our environments. A robust mitigation strategy must include awareness of these architectural nuances and the implementation of guardrails.
A cross-cloud exploitation methodology: While cloud providers are often managed as distinct ecosystems, their shared design philosophies allow identical attack techniques to be applied across providers. Our simulations prove that a specific architectural observation can evolve into a universal methodology for hijacking sensitive data streams. We encourage the security industry to adopt a cloud-agnostic mindset. A design flaw discovered in one provider could be a blueprint for exploiting another.
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
Cortex Cloud customers are better protected from the techniques discussed in this article with cloud runtime security operations through the collection, analysis, detection, alerting and prevention of malicious operations on cloud platform and SaaS application audit logs. Cortex has several out-of-the-box rules built into the Analytics module that detect data movement to external buckets. Using behavioral and static alerting techniques on cloud logs during cloud operations runtime, the techniques discussed within the article can be identified. When this occurs, they trigger alerts, which provide early warning and, in some cases, prevention operations to prevent further compromise from these attacks.
Cortex Cloud Identity Security can also protect organizations from the techniques discussed in the article. Identity Security encompasses:
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
South Korea: +82.080.467.8774
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
We discovered a vulnerability in the Google Cloud Vertex AI software development kit (SDK) for Python, and responsibly disclosed it to Google. Before Google’s fix, the vulnerability would have allowed an attacker operating entirely from their own Google Cloud project to hijack a victim's model upload and poison it. By exploiting this flaw in vulnerable versions of the SDK, an attacker can achieve remote code execution (RCE) within a target’s Vertex AI serving infrastructure, with zero initial access to the victim's project.
The root enabler of this attack is a predictable default bucket name, combined with a missing ownership check in the SDK's staging logic. When a Vertex AI user uploads a model without specifying a custom staging bucket, the SDK constructs a bucket name using a deterministic pattern based on the project ID and region.
An attacker who knows the victim's project ID can preemptively create this bucket in their own project, a technique known as bucket squatting. The SDK then silently uploads the victim's model artifacts to the attacker-controlled bucket. Subsequently, within a narrow window of opportunity, the attacker replaces the legitimate model with one that carries a malicious payload. Once the victim deploys the compromised model, the attacker's code executes. In vulnerable SDK versions, this can lead to data exfiltration, lateral movement and further compromise of the victim's cloud environment.
We refer to the process of exploiting this vulnerability as Pickle in the Middle because it relies in part on deserializing a built-in module called pickle, as explained below in Pickle Deserialization as Attack Vector.
We reported the vulnerability to the Google security team, and they accepted our findings. The issue affected google-cloud-aiplatform SDK versions 1.139.0 and 1.140.0, which was the latest at the time of testing. Google completed the fixes to address this issue in v1.148.0, which was released April 15, 2026.
We recommend that developers upgrade to fixed versions of the SDK.
Palo Alto Networks customers are better protected from the threats discussed discussed in this article through the following products and services:
Vertex AI is a machine learning platform for training and deploying ML models and AI applications. The Vertex AI SDK for Python is the primary client library that developers use to interact with the platform programmatically. We focused our research on the Vertex AI SDK for Python (google-cloud-aiplatform), as many enterprises rely on it to create and manage their AI/ML pipelines, applications and models.
The Vertex AI Model Registry is a centralized repository within Vertex AI where users store, version and manage their ML models. When a user uploads a model to the Model Registry via the SDK, the SDK first stages the model artifacts in a Google Cloud Service (GCS) bucket before registering them with the service. The Model Registry then references these staged artifacts. When the model is deployed to an endpoint, Google's internal infrastructure (specifically, a Per-Product, Per-Project Service Account or P4SA) loads them into a serving container. Figure 1 shows the intended model upload flow.
Figure 1. Uploading a model to Model Registry.
Bucket Squatting
Bucket squatting is a class of vulnerability that takes advantage of the global uniqueness of cloud storage bucket names. Since no two buckets across all of Google Cloud can share the same name, an attacker who is able to predict a bucket name can preemptively create it in their own project. Any subsequent attempt to use a bucket with that name, even from a different project, silently falls back to the attacker's bucket.
Service Agents and Tenant Project
In Google Cloud, many managed services operate through service agents (P4SAs). These are Google-managed service accounts that allow Google Cloud services to access resources. In the case of Vertex AI, the P4SA is responsible for reading model artifacts from the staging bucket and loading them into the serving infrastructure.
Tenant projects are Google Cloud projects that are owned by Google and used to host resources of a managed service. The identities and resources available inside these tenant projects are important aspects to research because they bridge the boundary between Google's infrastructure and the customer's resources. Vertex AI uses tenant projects to host resources such as Kubernetes clusters, containers and service accounts that allow the service to function.
Pickle Deserialization as Attack Vector
Joblib is a set of tools that provides lightweight pipelining in Python. pickle is a built-in module used for serializing and deserializing object structures. ML models in the Python ecosystem are commonly serialized using pickle – or its Joblib wrapper. A critical property of pickle is that deserialization can be leveraged to execute code. Specifically, Python's pickleprotocol supports a __reduce__ method that defines how an object should be reconstructed. An attacker who controls a pickle file can define a __reduce__ method that executes arbitrary Python code the moment joblib.load() or pickle.load() is called, before any type of validation occurs. This is a well-known property of pickle (and joblib), and it is the mechanism we used to turn model poisoning into remote code execution.
The Vulnerability
The Vertex AI SDK for Python model upload functionality is vulnerable to bucket squatting in versions 1.139.0 and 1.140.0, the latest versions that were available at the time of testing. When a user does not explicitly provide a staging bucket name, the SDK constructs a bucket name deterministically from the project ID and region, and then checks whether the bucket exists. If the bucket does not exist, the SDK creates it. However, if the bucket exists, the SDK does not verify whether the bucket belongs to the caller's project. This means that an attacker can create a bucket with the same name in their own project, and then wait for the victim to upload a model. Once uploaded, the attacker can replace it with a malicious model. This model carries a payload that executes arbitrary code when deployed and loaded, abusing the pickle deserialization mechanism.
Discovery Methodology
As part of this research, we incorporated a large language model (LLM) into the discovery and code-analysis phase. Analysis that once took days can now be executed significantly faster. By iteratively narrowing the model's focus and instructing it to look for specific patterns, we found paths that led to resources provisioned on the cloud, affected by user-controlled or project-derived inputs.
The vulnerable code was located in gcs_utils.py, inside the stage_local_data_in_gcs() function:
1
2
3
4
5
6
staging_bucket_name=project+"-vertex-staging-"+location# ← Deterministic predictable name
ifnotstaging_bucket.exists():# ← Only checks existence, NOT ownership
staging_bucket=client.create_bucket(...)
staging_gcs_dir="gs://"+staging_bucket_name
The function constructs the bucket name deterministically from the project ID and region (e.g., my-project-vertex-staging-us-central1). It then calls staging_bucket.exists() to check whether the bucket already exists. The bucket.exists() call returns True for any bucket with that name, regardless of which project owns it.
If the bucket exists, even in a completely different project, the SDK proceeds to upload model artifacts to it without any further verification. Once the model is uploaded, the attacker has a limited window of opportunity to replace it with a compromised one. This malicious model carries a payload that executes arbitrary code when the model is deployed and loaded. After this window, the AI Platform Service Agent (service-PROJECT_NUMBER@gcp-sa-aiplatform.iam.gserviceaccount[.]com) reads the model and the attacker loses their ability to replace it. Our tests show that this window is approximately 2.5 seconds, requiring near-real-time attacker operation, as shown in Phases 2-4 below.
The Attack Chain
Prerequisites
The success of this attack depends on the following conditions:
The victim’s default staging bucket does not already exist in the target region. This is the case for any project that has not yet used Vertex AI in that region or has not used the default staging bucket name.
The victim does not specify an explicit staging_bucket parameter when calling SDK methods like Model.upload(). When no bucket is specified, the SDK falls back to the deterministic default name.
On the attacker's side, the only requirements are a Google Cloud project – in any organization, using any billing account – and knowledge of the victim's project ID, which is often publicly discoverable.
High-Level Flow
The flow of attack phases reflects the key findings of our research:
Predictable bucket name and lack of ownership verification, enabling bucket squatting
Race condition window that can be exploited to hijack the model upload
Pickle deserialization as an RCE vector
Phase 1: Bucket Squatting
The attacker preemptively creates a bucket with the predicted name of the target's staging bucket, in the attacker's own project. The attacker then configures identity and access management (IAM) permissions so that any authenticated Google Cloud identity can read from and write to the attacker’s bucket. This is critical, as the victim's identity (that uploads the model) and Vertex AI’s service agent (which reads the model) must both be able to interact with the bucket.
The code snippet below illustrates how any authenticated user could interact with the bucket.
The legacyBucketReader role ensures that when the victim’s SDK checks whether the bucket exists, the bucket.exists() returns a True response. The objectCreator role allows the victim's SDK to upload artifacts. The objectViewer role allows the Vertex AI service agent to read the artifacts later.
Phase 2: Preparing the Model Replacement Function
The attacker deploys a Cloud Function, which is a serverless compute service in Google Cloud that executes code in response to events. The function is configured with a trigger on google.storage.object.finalize, which fires every time a new object is created (or overwritten) in the specified bucket. This means that the function automatically executes whenever the victim uploads a model artifact to the squatted bucket.
The attacker-created Cloud Function's logic is straightforward. When it detects a new model.joblib file in a vertex_ai_auto_staging path, it downloads the original file and replaces it with a pre-generated malicious payload.
The malicious payload is a joblib serialized Python object with a crafted __reduce__ method. To check the usage of this method, we set up a webhook that receives the victim's service account credentials. When the model is deserialized, it executes code that queries the Google Compute Engine (GCE) metadata server for the serving container's service account credentials and exfiltrates them to an attacker-controlled endpoint.
The reason we use a Cloud Function rather than polling the bucket is timing. According to our tests, the window between the victim's upload and the service agent read is approximately 2.5 seconds. A Cloud Function triggered by google.storage.object.finalize reacts within approximately 800 ms, leaving enough time to replace the file before the service agent reads it. In this way, the attacker wins the race. The victim uploads a legitimate model, but by the time the service agent reads it, the file has been swapped.
Phase 3: Victim Uploads a Model
The victim runs standard SDK code, without unusual configuration or security mistakes, as shown in the following code block:
Because no staging_bucket is specified, the SDK constructs the default name, finds that the bucket exists (which the attacker prepared in Phase 1) and uploads the model artifacts to the existing bucket’s location – the attacker’s project.
Phase 4: The Replacement
As a result of the victim's upload, the Cloud Storage finalize event triggers the attacker's Cloud Function, which immediately replaces the victim's legitimate model with the malicious payload. The entire swap occurs within the opportunity window, well before the P4SA reads the artifact. The service agent then reads the poisoned model instead of the original one, without the victim's knowledge.
The following timeline, captured from our proof of concept, illustrates the replacement flow:
T+0 ms Victim SDK uploads model.joblib (601 bytes)
T+804 ms Cloud Function detects new model
T+1,433 ms Cloud Function replaces new model with RCE payload (601→2,945 bytes)
T+2,460 ms P4SA reads the REPLACED model from the staging bucket
Phase 5: Victim Deploys the Model
The victim deploys the model to an endpoint using standard SDK calls, as shown in the following code block:
The victim has no indication that the model artifacts were tampered with.
Phase 6: Code Execution
When the serving container starts, it calls joblib.load() to deserialize the model. The __reduce__ method in the poisoned payload executes immediately, before the container performs any type validation on the loaded object. In our proof of concept, the payload:
Queries the GCE metadata server for the service account email and OAuth access token
Exfiltrates the credentials to an attacker-controlled webhook
Figure 2 shows the six phases of the attack chain.
Figure 2. Attack chain flow.
Token Exfiltration, Post-Exploitation and Impact
The OAuth token that was exfiltrated to the attacker’s webhook belongs to a service account running in Google's managed tenant project, named custom-online-prediction@<tenant-project>.iam.gserviceaccount[.]com. This token has cloud-platformscope – the broadest possible scope in Google Cloud.
We found that this token allows access to several tenant project resources that extend well beyond the scope of the individual deployment:
Cross-deployment model theft: The service account can access GCS buckets belonging to other model deployments within the same tenant project. In our testing environment, we were able to discover and read model artifacts from other deployments, including a complete TensorFlow model with trained weights.
BigQuery reconnaissance: The token can enumerate all BigQuery datasets and table names in the victim's project, and read dataset access control lists. This exposes data schema, naming conventions and the identities of other service accounts with data access. This is valuable information for lateral movement.
Tenant infrastructure intelligence: The token can read Cloud Logging from the Google-managed tenant project, revealing internal infrastructure details like:
Google Kubernetes Engine (GKE) cluster names
Active prediction deployments from other workloads
Google-internal container image URIs
Kubernetes system identities
Mitigation and Collaboration With Google
We reported this vulnerability to the Google security team. Google deployed fixes in v1.144.0 on March 31, 2026 and in v1.148.0 on April 15, 2026.
Figure 3 shows the first fix: the addition of a uuid4 variable with a randomly generated value to the end of the bucket naming routine in the gcs_utils.py script.
Figure 3. Change log for the first fix. Source: GitHub.
Figure 4. Change log for the second fix. Source: GitHub.
Disclosure Timeline
March 5, 2026: Vulnerability reported to Google Cloud via the Vulnerability Reward Program
March 9, 2026: Google assigned top priority to the report
March 10, 2026: Google acknowledged the vulnerability, assigned top severity and reported to the product team
March 31, 2026: Google deployed the first fix to production
April 15, 2026: Google deployed the second fix to production
Conclusion
The growing role of AI in production systems highlights the importance of continuously examining the security resilience of the platforms that support it. This research is one contribution to that effort, and we appreciate Google's collaboration in resolving the vulnerability.
Our research shows that cloud security extends into the developer toolchain and machine learning model lifecycle. The vulnerability that we discovered demonstrates how seemingly minor design flaws can lead to a critical security issue. In vulnerable versions of the SDK, this attack requires no access to the victim's project and no social engineering tactics, and could result in model poisoning, credential theft and cross-tenant compromise.
Google Cloud worked closely with Palo Alto Networks Unit 42 to resolve this issue through our Vulnerability Rewards Program (VRP). They deployed a permanent fix for the Vertex AI SDK for Python in version 1.148.0 on April 15, 2026.
We recommend that all developers update their SDK to version 1.148.0 or later to ensure the new bucket ownership checks are active. As an added best practice, when specifying an artifact_uri that isn't set to a Cloud Storage (gs://) location, users should set the staging_bucket parameter to a Cloud Storage location to help ensure full asset isolation.
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
Cortex Cloud
Organizations are better equipped to close the AI security gap through the deployment of Cortex AI-SPM, which delivers comprehensive visibility and posture management for AI agents across AWS, Azure and GCP environments, as described within this article. Cortex AI-SPM is designed to mitigate critical risks including, over-privileged AI agent access, misconfigurations, and unauthorized data exposure. Cortex AI-SPM enables security teams to enforce compliance with NIST and OWASP standards, monitor for real-time behavioral anomalies, and secure the entire AI lifecycle within a unified cloud security context.
Cortex Cloud Identity Security can also protect organizations from the techniques discussed in the article. Identity Security encompasses:
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
South Korea: +82.080.467.8774
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
This marks the beginning of our series, Inside the Modern SOC: Trends and Insights from Unit 42 Managed Services. This series draws directly from Unit 42 customer environments, security operations center (SOC) assessments, threat hunting engagements and frontline investigation experience to highlight the operational patterns shaping modern security operations.
Through our work helping organizations detect, investigate and respond to threats, one theme continues to surface: The speed gap has become one of the defining operational challenges facing today's SOC. Drawing on findings from the 2026 Unit 42 Global Incident Response Report, we can see that attack timelines have compressed dramatically as adversaries use AI to move faster and automate more of the attack lifecycle. In the fastest cases, attackers moved from initial access to confirmed data exfiltration in just over an hour (72 minutes), representing a 4X year-over-year acceleration.
When security operations still rely on manual triage and fragmented workflows, defenders are forced to operate on a timeline modern attackers have already outpaced. This is not a personnel problem; it’s a process problem. By the time an alert is validated through manual steps, the adversary has often already achieved their objective.
Anatomy of a Modern Identity-Driven Attack
Across recent Unit 42 investigations, we continue to see a consistent pattern: attackers leveraging compromised credentials, identity manipulation, privilege escalation and rapid lateral movement to compress attacks that once unfolded over days into hours, or even minutes. Threat actors such as Muddled Libra (aka Scattered Spider) and Spoiled Scorpius, distributors of RansomHub ransomware, exemplify this broader trend.
The Attacker's Playbook in Action
The Social Entry: Initial access is often gained through compromised credentials, MFA manipulation, help-desk impersonation or other identity-based tactics. This pattern appeared across many of the investigations we handled over the past year. According to the 2026 Unit 42 Global Incident Response Report, 65% of initial access is driven by identity-based techniques.
The Rapid Escalation: Once inside, attackers frequently attempt privilege escalation and administrative account abuse within minutes or hours of gaining access. Unit 42 has observed suspicious identity activity quickly escalating into abnormal administrative behavior and signs of privilege escalation.
The Multi-Surface Pivot: Attackers increasingly move across identity, endpoint, cloud and Software as a Service (SaaS) environments. Once elevated privileges are obtained, they may provision cloud resources, create rogue virtual machines, mount virtual drives or establish persistence to support data staging and exfiltration.
The Rapid Impact: Unit 42 investigations continue to show attackers compressing the time between initial access and business impact. In some cases, threat actors such as Spoiled Scorpius have exfiltrated hundreds of gigabytes of data within hours of gaining access through improperly secured remote access infrastructure.
From a tooling perspective, the warning signs were often already present across the organization's identity and endpoint security controls. Multiple alerts had been generated, but without automated correlation, each appeared low priority in isolation. Connecting these signals manually takes time, a luxury attackers no longer allow.
How Our Unit 42 Managed Services Team Responds
In investigations involving identity-driven attacks, our analysts use the Cortex SecOps platform to quickly connect unusual privileged account activity, PowerShell execution, abnormal authentication patterns, privilege escalation attempts and lateral movement indicators to understand the full scope of an incident. Additional context, including device history, process activity, threat intelligence and behavioral analytics, helps determine whether activity is legitimate or indicative of attacker behavior. By analyzing these behaviors in context, our teams can quickly identify high-confidence incidents and contain compromised accounts before activity expands further across the environment.
Organizations using Managed XSIAM extend this model through AI-driven correlation, integrated response workflows and continuous SOC engineering that helps reduce investigation and response times. This shift from sequential investigation to real-time correlation helps security teams keep pace with compressed attack timelines. Instead of spending critical minutes manually stitching together fragmented alerts, analysts can move quickly from detection to confident response.
Advice for SOC Leaders: Re-Engineer for Velocity
Closing the speed gap requires evolving how your security operations function. Modern threats require an operating model that matches attackers’ velocity.
Move Beyond Sequential Workflows: Shift from linear "Triage → Investigate" models to workflows where enrichment happens automatically in parallel. Analysts should not need to manually search multiple tools to understand whether an alert is serious.
Correlate by Default: Related signals across identity, endpoint, cloud and network activity should automatically group into unified incidents. This reduces investigation time and helps eliminate analyst fatigue caused by fragmented tooling. Per the Unit 42 Global Incident Response Report, in 87% of incidents investigators reviewed evidence from two more distinct sources to establish what occurred. Complex cases drew on as many as 10 sources.
Operationalize Response: Predefine containment actions for common attack scenarios such as compromised accounts, suspicious PowerShell execution, malware activity or unauthorized remote access. When attackers move in minutes, response decisions cannot begin from scratch every time.
Prioritize Behavior Over Indicators: Focus on attacker behaviors such as rapid privilege escalation, impossible-travel logins, unusual access patterns or abnormal process execution chains. These behaviors often reveal malicious intent earlier than static indicators alone.
What's Next
In our next entry in this series, we'll explore another trend keeping security leaders up at night: Attackers have stopped "breaking in" and started "logging in." We'll examine how identity-based attacks are rapidly replacing malware as the preferred path to compromise and what organizations can do to defend against them.
The Unit 42 Managed Services Edge
We help organizations close the speed gap by combining expert-led operations with real-time detection, investigation, and response. Unit 42 Managed Detection and Response (MDR) combines AI-driven automation with world-class threat hunters, analysts, and responders who proactively uncover threats, investigate high-risk activity, and act quickly when minutes matter. Together, these capabilities help organizations accelerate detection, investigation, and containment while improving security outcomes.
For organizations pursuing broader SOC modernization, Managed XSIAM extends these capabilities with 24/7 expert-led operations, integrated response, continuous SOC engineering, and a breach response guarantee that includes 250 hours of Unit 42 Incident Response support. Together, these capabilities help organizations reduce operational complexity, strengthen security outcomes, and build a more resilient security operation prepared for today's threat landscape.
Forensic examiners are constantly hunting for data that reveals not just what happened on a system, but the user's intent behind it. With the release of macOS Tahoe 26, a new artifact has surfaced that provides exactly this level of granularity. We have identified a new Biome stream, App.MenuItem, which logs specific menu selections made by users across the operating system.
This artifact offers a step-by-step record of user actions — from compressing files to emptying the trash — providing critical context for user activity across the operating system. This blog outlines where to find this artifact, how to process it and what stories the data can tell.
Apple Biome – A Gold Mine for Forensic Investigators
The Apple Biome system has long been a gold mine for forensic investigators, tracking everything from app usage to media consumption. In macOS Tahoe 26.x, Apple appears to have introduced a new stream specifically designed to track menu selections, likely to facilitate user suggestions or learning behavior.
Location and Structure
The artifact is located at ~/Library/Biome/streams/restricted/App.MenuItem/local. Unlike simple logs, this file contains SEGB-encapsulated protobuf entries. SEGB is the file format used by the Biome. While this format requires specific tooling to parse, the payoff is significant. The stream captures the exact text of menu items selected by the user, along with the timestamp of the activity, providing a narrative of their interaction with the interface.
Parsing the Artifact
Because standard forensic tools may not yet parse this specific stream, examiners can utilize open-source tools like ccl-segb to extract the raw data. In our testing, this artifact is not parsed by the most common commercially available digital forensic tools available.
To process the file:
Export the file(s) from the directory ~/Library/Biome/streams/restricted/App.MenuItem/local.
Run the ccl-segb Python script: python ccl_segb_cli.py <exportedfilename> > outputfilename.txt.
Convert the resulting text output into a CSV format for easier filtering and analysis using a Python script.
Analyzing User Intent
The true value of App.MenuItem lies in its ability to reconstruct a user's workflow. Where a file system event might simply show a file was deleted, this artifact can show the deliberate action of selecting "Move to Trash" followed by "Empty Trash.”
Consider the following sequence of events observed in our sample analysis:
18:32:37: The user navigates using Go > Go to Folder… in Finder.
18:36:59: In TextEdit, the user selects File > Save…, followed by typing "u42validation".
18:37:54: The user highlights a folder named "stolendata" and selects Compress “stolendata”.
18:38:19: The user selects Move to Trash.
18:38:41: The user interacts with the Dock to select Empty Trash.
In this scenario, we see a clear pattern: data creation, compression (likely for exfiltration) and subsequent cleanup. We even see interaction with specific UI elements, such as Copy and Paste Item later in the timeline.
Limitations
While powerful, this artifact is not without limitations. It relies on the menu item text itself. If a menu option does not explicitly contain the file or folder name (e.g., a generic "Open" command vs. "Compress 'Report'"), the specific target of the action might not be visible in this stream alone. However, when correlated with file system logs, App.MenuItem provides the "human" context that technical logs often miss.
Final Thoughts
The discovery of the App.MenuItem artifact in MacOS Tahoe 26 adds a powerful new layer to forensic investigations. By capturing the specific menu choices a user makes, examiners can reconstruct digital intent with greater precision than before. Whether you are investigating data exfiltration or trying to understand a sequence of events, this Biome stream provides a narrative view of user behavior.
As macOS continues to evolve, so must our forensic methodologies. We encourage all examiners working with Tahoe images to verify if this artifact is present and incorporate it into their standard analysis workflows.
AI agents now extend their capabilities by installing third-party skills the way smartphones install apps. Anyone can publish a skill to a public registry. Anyone can install one into a production agent. And until now, no automated tool has verified what a skill does before it gains privileged access to credentials, files and shell commands inside that agent.
We introduce Behavioral Integrity Verification (BIV), an audit primitive that compares what a skill claims to do against what it does, across all three of its surfaces:
Metadata
Executable code
Natural-language instructions
Applied at registry scale, BIV finds that most skills deviate from declared behavior. The vast majority of those gaps are sloppy documentation, not malice. But a smaller, dangerous slice carries multi-stage attack chains, where individually benign-looking capabilities combine into credential theft, remote code execution or silent data exfiltration.
The agent-skill ecosystem now stands where mobile applications and browser extensions were a decade ago. Extensibility has outpaced the supply-chain audit primitives that should gate it. Security teams running large language model (LLM) agents in production should inventory the third-party skills installed and require a behavioral-integrity check before installation rather than after.
Palo Alto Networks customers are better protected from this type of issue through the following products and services:
Enterprises now deploy LLM agents to automate tasks across code generation, IT operations, customer support and internal workflows. These agents are extended with skills, the agent equivalent of an app: a small package that bundles executable code with a YAML manifest and a natural-language SKILL.md file telling the agent when and how to use it.
Once installed, a skill runs inside the agent's privileged context. It can read environment variables, call external services, write files and execute shell commands on behalf of the organization.
Public agent-skill registries now host tens of thousands of these packages. Anyone can publish. Anyone can install.
The platforms that came before, package managers, mobile app stores and browser extension marketplaces, all eventually grew automated audit ecosystems after attackers turned the openness against users. The agent-skill ecosystem has not.
The audit problem in this ecosystem differs from anything earlier platforms faced. A skill's behavior splits across three modalities:
Metadata
Executable code
Natural-language instructions
The metadata declares what the skill is supposed to do. The code and instructions together drive what it does. No existing scanner reads all three, and the registry has no automated way to verify that the two sides match. BIV is the audit primitive that compares them.
The Method: Declared Vs. Actual Behavior
BIV asks one question of every skill: Does what it says match what it does?
To answer that question consistently across tens of thousands of skills, BIV needed a shared vocabulary. We used a fixed taxonomy of 29 capabilities organized into seven families:
Network
File system
Process execution
Environment
Encoding
Credentials
Instruction-level threats
Two parallel tracks populate the taxonomy:
The declared track reads the metadata. Deterministic parsers handle structural fields like YAML frontmatter and schemas. An LLM then reads natural-language descriptions (README, SKILL.md prose) to extract claimed capabilities, ensuring each claim is grounded in a quoted source span.
The actual track reads the code and instructions. Static analyzers cover code across multiple scripting languages (Python, JavaScript, shell) using abstract syntax tree (AST)-level taint analysis, regex and pattern matching. Separately, an LLM reads the natural-language instructions to surface prompt-injection and instruction-override motifs that traditional parsers miss.
A skill passes when its actual capability set fits inside its declared capability set. A skill fails when it does something it never disclosed (an under-specification, the operationally dangerous direction) or declares a permission it never exercises (an over-specification, almost always benign template residue).
Three filters keep the LLM components honest:
The first rejects any output that echoes the taxonomy verbatim.
The second rejects capability claims not anchored in a quoted source span.
The third requires domain-specific keywords in context for high-risk capabilities.
The pipeline ships with file-and-line evidence pointers, so every flagged deviation is auditable by hand.
Findings in the Wild
We crawled the OpenClaw agent-skill registry in early 2026 and ran BIV across all 49,943 listed skills. BIV surfaced 250,706 behavioral deviations, with 80.0% of skills (39,933) showing at least one mismatch between declaration and behavior.
A clustering pass over the deviation explanations produced a 137-cluster taxonomy and, notably, four novel compound threat categories. Each is a multi-step pattern:
Data lineage violations (FILE_READ → FILE_WRITE, mostly benign data-pipeline boilerplate)
The threat lives in the chain, not the link. A scanner that checks one capability at a time sees a file read in one row and a network send in another and flags neither in isolation. BIV's contribution is the link between them.
A capability mismatch tells us that something undeclared is happening, not whether the developer was sloppy or hostile. BIV separates the two with a two-step intent classifier.
A deterministic rule engine resolves roughly two-thirds of cases at near-zero cost. An LLM classifier handles the rest by reasoning across a skill's full deviation list, so a multi-step chain is judged as a unit. Figure 1 breaks down 163,754 classified deviations by root cause.
Figure 1. Intent classification of 163,754 clustered deviations.
Our analysis of this breakdown reveals that the skill ecosystem's primary failure mode is specification immaturity, not pervasive malice. Specifically, the classified data highlights two key themes:
81.1% were traced to developer oversight. Documentation errors lead, followed by legitimate helper code, unused declarations and framework dependencies. These call for documentation outreach at the registry, not security review.
18.9% were traced to adversarial intent. This adversarial slice concentrates sharply in data theft and espionage (60% of the adversarial total), then payload and infrastructure, and agent hijacking. Financial, destructive and social engineering combined come to under 1%.
When analyzed at the skill level, the registry decomposes into three governance tiers. The top tier is 5.0% of the registry (2,490 skills) that carry multi-stage attack chains and warrant mandatory security review. The middle tier is 16.8% that carry single-stage adversarial deviations and warrant contextual review. The remaining 72.5% are benign skills whose declared metadata simply needs to catch up to the code.
The top tier has structure worth leveraging. The 2,490 skills carrying multi-stage chains are not 2,490 unrelated alerts.
Two patterns dominate:
Silent credential exfiltration (read a secret, transmit it)
Instruction-override hijacking (take over the agent's decision loop, then exfiltrate)
Together, they cover 88% of all multi-stage chains. For an analyst running incident response or a registry operator setting review policy, this is operationally significant. The first 88% of the review effort can target two well-defined patterns instead of a flat list.
Where the Real Risk Concentrates
The adversarial fraction of deviations varies sharply across the seven capability families. A registry-wide threshold either over-blocks routine I/O skills or under-reviews the genuinely dangerous categories. Figure 2 plots each category by its adversarial fraction and deviation volume, with compound threat categories indicated by red stars.
Figure 2. Per-category adversarial fraction plotted against deviation volume.
As the plot illustrates, three of the four compound threat categories sit in the high-adversarial region. Data lineage violations, dominated by benign data-pipeline boilerplate, is the outlier. We noted the following trends in other threat categories:
Instruction manipulation: 96% adversarial. The smallest established capability surface but the highest signal-to-noise ratio. Almost every undeclared prompt-control directive is suspect. This is the agent-specific attack surface that no prior third-party platform had to defend.
Credentials: 56% adversarial. It reflects the operational value of secrets to attackers.
Network: 37% adversarial. Mid-band; legitimate uses compete with exfiltration motifs.
File system (10%) and process execution (12%): Predominantly benign. Routine I/O and command invocation dominate raw volume but rarely indicate hostile intent on their own.
Operationally, this argues for per-category review tiers keyed to BIV's per-capability severity (Critical for credentials and instruction-level capabilities; high for network, process and environment access; medium for file system and encoding). A single threshold is the wrong instrument for this surface.
Beyond the per-capability picture, multi-stage compound chains define the highest-priority hunt patterns. The two dominant exfiltration patterns described above cover 88% of multi-stage chains; four long-tail patterns cover dropper-style payload delivery, encoding-based evasion, persistence and reconnaissance-then-exfiltration. Any installed skill matching one of these six patterns warrants mandatory review.
Conclusion
The agent-skill ecosystem mirrors an inflection point seen in mobile applications and browser extensions a decade ago, where extensibility similarly outpaced audit capabilities. Each of those earlier ecosystems stabilized only after automated cross-modality auditing became routine.
The proposed BIV method reduces the multi-modality audit problem to a typed comparison over a shared capability vocabulary. The same structured evidence supports a registry-scale deviation taxonomy and a two-step root-cause classifier.
The registry-scale findings reveal a clear operational strategy. Documentation interventions at the registry can address the 81.1% non-adversarial bulk. Security review efforts can then focus on the 18.9% that matters, specifically targeting the two dominant attack patterns.
The following limitations should be acknowledged.
BIV is static-only, dynamic dispatch and obfuscated payloads escape AST-level analysis.
Flagged skills are classifier-predicted candidates for review, not runtime-confirmed exploits.
The pipeline is not robust against an adversary who has read this paper and crafts descriptions calibrated to confuse the LLM adjudicator.
Backbone backdoors, retrieval-corpus poisoning and runtime memory poisoning fall outside scope and require complementary runtime defenses.
For organizations deploying LLM agents in production today, the action is concrete. Inventory the third-party skills installed and implement a behavioral-integrity check before installation rather than after.
We detailed the full methodology and complete registry-scale analysis behind this post in our research paper.
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
Prisma AIRS is designed to provide layered, real-time protection for AI systems by detecting and blocking threats, preventing data leakage and enforcing secure usage policies across a variety of AI applications.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
South Korea: +82.080.467.8774
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Cloud logging services provide comprehensive visibility into actions performed within cloud resources, making them essential for security monitoring. However, this reliance also makes logging services a high-value target for attackers. An attacker who exploits these services could create weak spots, evade detection, and in certain scenarios, establish continuous visibility within a target’s environment.
Services such as Amazon Web Services (AWS) CloudTrail and Google Cloud are powerful for defenders, and prime targets for attackers seeking to remain undetected by disrupting the flow of logs. Attack techniques against cloud logging services primarily fall into two categories:
Defense Evasion: Attackers aim to bypass detection systems, to execute attacks unnoticed. This may involve modifying resources within the cloud logging service.
Continuous Visibility: Attackers attempt to transfer logs to their own accounts, establishing continuous visibility over the victim's environment.
Understanding these attack scenarios enables organizations to implement the appropriate configurations and detect service misuse.
Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:
Serving as the authoritative system of record for every event, cloud logging services provide complete visibility into all actions within cloud environments. This comprehensive data enables analysis of past behaviors for both operational debugging and security investigations.
Each cloud provider implements logging services in a unique way. Our recent Cloud Logging for Security article provides an overview of these various services across different cloud providers. In this article, we analyze and demonstrate attack techniques that target the primary logging services within each major cloud provider.
Before examining the logging capabilities offered by major cloud providers, we outline the fundamental components and mechanisms for log delivery. Our analysis focuses on AWS CloudTrail and Google Cloud Logging. Both of these widely used services are designed to provide comprehensive audit trails and operational insights. While this article focuses on specific services, the attack techniques presented may also apply to other cloud logging services.
Background: How Cloud Service Providers Handle Logs
AWS CloudTrail
AWS CloudTrail's primary resource for configurable log collection and delivery is known as a trail. A trail acts as a configuration that specifies how CloudTrail records AWS application programming interface (API) calls and related events in an AWS account. These events include actions taken by users, roles or AWS services.
The main function of a trail is to deliver these captured logs to an Amazon S3 bucket. S3 is a highly scalable, durable, secure object storage service. When a trail is configured, it continuously writes log files containing event records to the designated S3 bucket.
The S3 bucket serves as a centralized, long-term repository for CloudTrail logs. This enables auditing, security analysis and compliance efforts. CloudTrail supports sending native event trails to either the CloudTrail Lake feature, EventBridge or CloudWatch Logs. However, for enterprises with integrations to third-party products, these features might not be relevant or usable.
Google Cloud Logging
Cloud Logging is a fully managed service that collects logs from all of an organization’s Google Cloud resources. Cloud Logging leverages a resource called a sink as the primary mechanism for log delivery. A sink functions as a router that sends log entries to a specific destination. While a sink primarily routes and stores logs in centralized log buckets for analysis and retention, it also offers the flexibility to export logs to other powerful Google Cloud services. For example, logs can be routed to a cloud storage bucket for cost-effective long-term archival. When a sink is configured, it exports log entries that match specific criteria defined by a filter to a designated log bucket.
Defense Evasion
Sophisticated techniques enable attackers to remain undetected within a compromised cloud environment. These methods could involve manipulating or evading logging mechanisms, which are crucial for security monitoring and incident response. Obscured activities can extend an attacker's presence, facilitate data exfiltration or inflict more harm before being discovered.
A wide array of security products including the following are fundamentally dependent on this log data to function:
Security information and event management (SIEM)
Security orchestration, automation and response (SOAR) platforms
By disabling, altering or deleting these logs, an attacker can effectively hide themselves from these defensive systems, compromising the security integrity of the entire cloud environment. Attackers often use the following five techniques to accomplish this:
Stop logging
Delete the log storage destination
Delete the log router
Impair logging via attacker-controlled encryption key
Log poisoning
Technique 1: Stop Logging
The most direct method to suspend log flows is to disable the logging mechanism itself. A wide array of security products is fundamentally dependent on this log data to function. By disabling these logs, an attacker can effectively blind defensive systems, compromising the security integrity of the entire cloud environment.
In AWS, an attacker with cloudtrail:StopLogging permissions can invoke the stop-logging API call for a specific trail. Once this API is executed, no further logs for that trail are written to the S3 bucket, creating an immediate visibility gap for organizations that created their own trails.
In Google Cloud, the equivalent action is disabling the sink. An attacker with logging.sinks.update permissions can set the sink’s disabled field to true to stop logs from being written. The Google Cloud console message shown in Figure 1 reflects this change.
Figure 1. Message confirming suspension of logs.
Technique 2: Delete Log Storage Destination
Typically, logs are stored in a cloud storage resource. An attacker who obtains permission to this resource could delete the cloud storage, preventing logs from being written. The following scenarios demonstrate this ability.
In AWS, an attacker with s3:DeleteBucket permissions can use the delete-bucket API to delete the S3 bucket; this action also requires the s3:DeleteObject permission to empty the bucket. A few minutes after the action, the associated CloudTrail trail's configuration will indicate this deletion, as the notification in Figure 2 shows.
Figure 2. An indication for the bucket deletion in AWS CloudTrail.
In Google Cloud, an attacker with logging.buckets.delete permissions can delete the log bucket. In the case of a log bucket, the deletion is not immediate. Once the delete command is issued, the log bucket enters a DELETE_REQUESTED state, remaining in that state for seven days. After this period, the bucket is deleted.
Google Cloud offers a mechanism to protect against this deletion by providing the ability to lock the logging bucket. Once a bucket is locked, its retention policy becomes permanent and irreversible, meaning the bucket cannot be deleted by any user until every log entry within it has fulfilled the specified retention period.
Technique 3: Delete Log Router
Another defense evasion tactic involves deleting the log routing resource – for example, an AWS trail or a Google Cloud sink. Once deleted, new logs will cease to be written to the designated destination. An attacker can delete a log router by using the delete-trail AWS API or the google.logging.v2.ConfigServiceV2.DeleteSink Google Cloud method.
Technique 4: Impair Logging via Attacker-Controlled Encryption Key
An attacker could potentially render cloud logs unreadable by modifying their encryption key. An attack flow using AWS could unfold as follows:
When a trail is created in AWS, one of the configuration parameters is the key management service (KMS) key, which is used to encrypt the logs delivered by CloudTrail.
An attacker could prevent legitimate access to this key by updating the trail to use an attacker-controlled KMS key and then removing access to the key.
Consequently, logs will not be written to the bucket due to the inability to encrypt them with the unusable key.
To perform this attack, an attacker first creates an external KMS key with the policy shown in Figure 3 to ensure that the key is accessible to CloudTrail.
Figure 3. Policy to create a KMS key with external access.
The attacker uses the update-trail API to modify the KMS key used to encrypt the logs in the S3 bucket.
Next, the attacker removes CloudTrail's access to the key by either deleting the key or removing the Allow CloudTrail to access the key statement from the policy. Subsequently, CloudTrail will indicate that there is a configuration issue due to denied bucket access, even though the bucket is correctly configured.
From this point on, logs will not be written to the bucket because the KMS key will be inaccessible. Figure 4 shows the message that is displayed after access is disabled.
Figure 4. Disabling access to the KMS key results in a Bucket access denied error.
Figure 5 shows the attack flow using AWS.
Figure 5. Impair logging via attacker-controlled encryption key attack flow in AWS.
An attack flow using this technique in Google Cloud is as follows:
In Google Cloud, a similar attack scenario can be simulated where a log bucket is already pre-configured with customer-managed encryption keys (CMEK). An attacker can then exploit this existing configuration by modifying the CMEK to reference an external key using the following command (the external CMEK must have encrypt/decrypt access granted to the KMS service account): gcloud logging buckets update BUCKET_NAME --location=LOCATION --cmek-kms-key-name FULL_KMS_KEY_NAME
Subsequently, the attacker can remove the permissions granted to the external key. At this point, the victim will be unable to read the logs, as the Google Cloud panel in Figure 6 shows.
Figure 6. The outcome of an inaccessible encrypted key.
Any attempts to revert the key will result in the error message “rekeying requires that the CMEK service account has decrypt access to the current CMEK key,” as Figure 7 shows.
Figure 7. The outcome of an attempt to revert the key.
Technique 5: Log Poisoning
Another defense evasion technique is the direct modification of logs – known as log poisoning. This is an effective technique when logs are pre-configured to be written to a cloud storage resource. In this case, the logs are stored in JavaScript Object Notation (JSON) format and can be modified by an attacker. If stored logs are deleted, added or modified, there is a high likelihood that Security Operations Center (SOC) personnel or analysts would inadvertently use these poisoned logs to conduct log analysis.
In AWS, CloudTrail logs are delivered as objects to an S3 bucket. An attacker with s3:GetObject and s3:PutObject permissions on the bucket could download a log file, remove or alter specific events and then re-upload it, overwriting the original file. This breaks the chain of custody and invalidates the audit trail.
Figure 8 shows the response to a query from a scenario where an attacker alters a log to avoid detection, and then the victim inspects the log using Amazon Athena.
Figure 8. Athena query analysis shows the modified log.
In Google Cloud, sinks route the logs to cloud storage. An attacker with storage.objects.get and storage.objects.create permissions can perform the same download and overwrite technique.
To mitigate the risk of log poisoning, AWS provides CloudTrail log file integrity validation. This feature provides the ability to cryptographically verify whether log files were modified after they were delivered by CloudTrail. This ability is enabled by default when using the AWS Console to create Trails, but not when using the API or command line interface (CLI).
Continuous Visibility
Upon gaining an initial foothold in a victim environment, an attacker with advanced capabilities would aim to establish long-term, passive visibility into the victim's cloud infrastructure. Instead of running noisy discovery commands that might trigger alerts – or if they lack proper permissions – an attacker can target the log routing mechanism to route logs to their own environment, resulting in real-time visibility. This enables attackers to perform continuous discovery and passively monitor all activity, from new VM deployments and IAM policy changes to sensitive data access. In this way, attackers can map the environment, identify high-value targets, and escalate privileges while potentially remaining invisible to the victim's security monitoring. The following techniques achieve continuous visibility:
Configure new log routing resource
Log redirection
Technique 1: Configure New Log Routing Resource
A direct method for achieving continuous visibility involves creating a new log routing resource – for example, an AWS trail or a Google Cloud sink. The attacker configures the newly created resource to direct logs to an external, attacker-controlled destination.
In AWS, the attacker configures CloudTrail logging to their own S3 bucket by using the create-trail API and specifying their bucket in the --s3-bucket-name parameter.
In Google Cloud, the attacker utilizes the logging.sinks.create API to set the DESTINATION parameter to the attacker’s intended resource.
Both of the above steps result in all logs being directed to the attacker's chosen destination.
For certain AWS accounts, the CreateTrail operation shows up in CloudTrail. If EventBridge is configured upon AWS account set-up, defenders can use EventBridge to alert on creation events. In this setup, subsequent describe calls of CloudTrail configuration will show the attacker's destination bucket. However, for organizations that use third parties or have not applied these configurations, attackers can carry out adversarial activities without being detected.
Technique 2: Log Redirection
Using this technique, the attacker alters the log routing destination to one within their own environment. This redirects logs to an attacker-controlled resource, enabling the attacker to obtain continuous discovery.
In AWS, the attacker updates the --s3-bucket-name parameter when invoking the update-trail API. After modifying the destination bucket, all logs are directed to the attacker’s bucket, providing continuous discovery capabilities on the victim’s account.
In Google Cloud, the attacker uses logging.sinks.update permissions to update the destination parameter, achieving the same ability to redirect logs.
Small enterprises that manage their own alert telemetry may notice that Trails have stopped working in this situation, but larger organizations may not be using AWS-native services that would allow them to detect this behavior.
Risk and Impact Assessment
Table 1 summarizes the evasion and visibility techniques, the likelihood that the activity is malicious, and the impact on logging services.
Technique Name
Likeliness of Malicious Activity
Primary Impact
Stop Logging
High
Total inability to view logs; usually precedes a larger attack.
Delete Log Storage Destination
Medium
Destruction of forensic evidence and archived log data.
Delete Log Router
Low
Disruption of the security pipeline.
Impair Logging via Attacker-Controlled Encryption Key
Medium
Logs exist but are rendered unreadable.
Log Poisoning
Medium
Degradation of data integrity.
Configure New Log Routing Resource
Low
Log exfiltration and potential covert persistence.
Log Redirection
High
Log exfiltration and potential covert persistence.
Table 1. Risk and impact assessment of evasion and visibility techniques.
Prevention and Awareness
The attack scenarios discussed all stem from modifications to logging service resources. Given the high value of cloud logging service resources, access should be restricted to highly privileged users to help prevent these scenarios. This measure reduces the likelihood of an attacker altering the configuration of such resources.
Amazon Web Services
For every AWS account there is an immutable 90 day CloudTrail Event History of all management events. This fallback ensures that these records cannot be deleted or circumvented. However, data and network events do not appear in this history.
In AWS, limit the update-trail API invocation to highly privileged users. Configure the bucket policy of the associated S3 bucket to prevent non-admin users from making configuration modifications. It's also crucial to ensure that only the CloudTrail service can write objects to these buckets.
Google Cloud
Google Cloud provides a similar safety mechanism to AWS, through its built-in log buckets. The _Required log bucket serves as an immutable repository for essential logs – such as Admin Activity and System Event audit logs – that cannot be disabled, modified or deleted. Alongside this, the _Default log bucket automatically captures a broader range of log entries for a shorter period of time. When creating logging storage for external integration purposes, these built-in buckets will not be relevant. As a result, those manually configured buckets may remain exposed to the specific attack techniques described in this article.
In Google Cloud, restrict the permissions for logging.sinks.update, and protect the destination resource.
Conclusion
Cloud logging services are fundamental for maintaining security posture and operational awareness, providing the definitive record of all activities within a cloud environment. The integrity of the logging infrastructure itself is a critical control, and for this reason has become a primary target for threat actors aiming to operate undetected.
The misuse of cloud logging services can have serious negative outcomes, enabling adversaries to cause blind spots for security teams, exfiltrate sensitive data in real-time, or methodically cover their tracks to evade forensics. By understanding the specific TTPs that threat actors use against these services, defenders can build more resilient detection and prevention strategies.
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:
Cortex Cloud customers are better protected from the topics discussed within this article with cloud runtime security operations, through the collection, analysis, detection, alerting and prevention of malicious operations on cloud platform and SaaS application audit logs. Using behavioral and static alerting techniques on cloud logs during cloud operations runtime, the techniques discussed within the article can be identified and trigger alerts which provide early warning – and in some cases, prevention operations to prevent further compromise from these attacks.
The Unit 42 Cloud Security Assessment is an evaluation service that reviews cloud infrastructure to identify misconfigurations and security gaps.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Palo Alto Networks Unit 42 has observed active exploitation of PAN-OS vulnerability CVE-2026-0257 by an unidentified threat actor attempting to access GlobalProtect. This security flaw involves an authentication bypass in the portal and gateway components of vulnerable versions of PAN-OS® software, which could allow unauthorized attackers to circumvent security controls and initiate VPN connections. This CVE was added to the Known Exploited Vulnerability (KEV) catalog on May 29.
No post-access behavior or lateral movement has been identified as of this time. Only a small portion of the probed devices actually established VPN sessions, resulting in gateway-connected events.
We advise organizations to proactively hunt for the indicators of the activity specified in this report and activate incident response protocols for any successful gateway-connected events linked to these indicators. Additionally, we strongly recommend reviewing the security advisory for CVE-2026-0257, following the available workarounds and mitigations or upgrading to a version that includes a fix for this issue.
For pre-Proof of Concept release (May 29, 2026) activities, search for these IP addresses in GlobalProtect logs to look for successful login connection:
23.128.228[.]6
104.207.144[.]154
146.19.216[.]119
146.19.216[.]120
146.19.216[.]125
179.43.172[.]213
185.195.232[.]139
198.12.106[.]60
202.144.192[.]47
Search GlobalProtect logs for successful gateway-connected events from any IP address using suspicious host IDs or device names, including but not limited to:
aa:bb:cc:dd:ee:ff
00:11:22:33:44:55
WINDOWS-LAPTOP-001
DESKTOP-GP01
GP-CLIENT
As part of post-PoC release monitoring, search GlobalProtect logs for successful gateway-connected events matching the following hard-coded client configuration values from the PoC code.
endpoint_os_version : Microsoft Windows 10 Pro 64-bit
source_user_info.domain : empty
We encourage organizations to consult the official Palo Alto Networks Security Advisory for additional details about the vulnerability, impacted products and configuration guidance. We also recommend reading Rapid7’s technical analysis about the exploitation activity they observed in the wild.
Palo Alto Networks Cortex Xpanse is able to identify publicly exposed PAN-OS gateways and GlobalProtect portals.
Palo Alto Networks has shared our findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
We will update this threat brief as more relevant information becomes available.
The products listed below can help protect PANW customers against exploits targeting CVE-2026-0257.
Palo Alto Networks Product Protections for PAN-OS CVE-2026-0257
Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat.
If you think you might have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
South Korea: +82.080.467.8774
Cloud-Delivered Security Services for the Next-Generation Firewall
Advanced URL Filtering canidentify known IP addresses associated with this activity as malicious.
Cortex AgentiX
Security analysts can use natural language to prompt the Cortex AgentiX Threat Intel agent to extract file indicators from this threat brief. They can then enrich them, check for sightings in their Cortex tenant and related alerts, and provide a quick summary of the impact to the organization.
Cortex XDR and XSIAM
Cortex XDR and XSIAM provide comprehensive protections for endpoint attacks. It helps block post-exploit activity with its Behavioral Threat Protection, AI-driven local analysis, cloud-based malware analysis and other security engines across Windows, Linux, and Mac systems.
It's Friday afternoon. The week has been busy, and everyone is wrapping up before the weekend. One of your workers receives a message (Figure 1) through Microsoft Teams from what appears to be the IT Service Provider.
Figure 1. Simulated Microsoft Teams message request.
The message is marked as external. The worker previews the message and sees, "Hi, this is the IT Department. We see an issue with your account." The message looks routine and is in MS Teams, not email. The worker accepts the message. The conversation proceeds and the "IT technician" explains that a login anomaly was detected and asks the worker to approve a multi-factor authentication (MFA) prompt to confirm their identity. The conversation continues for a few minutes to maintain credibility, but behind the scenes the compromise is already underway.
This scenario shows how access to trusted internal communications channels allows threat actors to manipulate employees into taking actions that lead to compromise. Recent events utilizing this technique include:
Cloaked Ursa (aka APT29, Cozy Bear and Midnight Blizzard) has successfully operationalized this approach. We reported in late 2024 how the threat actor leveraged compromised accounts to send MS Teams messages containing malicious links that redirected victims to credential harvesting pages mimicking legitimate Microsoft login portals.
In December 2025, a threat group tracked by Mandiant as UNC6692 used MS Teams to impersonate IT helpdesk staff. The threat actors convinced targeted employees to accept a Microsoft Teams chat invitation from an account outside their organization.
The Rise of Chat-Based Social Engineering
Threat actors have increasingly moved away from traditional phishing techniques toward trusted collaboration tools. In the first four months of 2026, phishing alerts from collaboration tools represented 42% of all phishing alerts in Cortex, up from 30% of all phishing alerts in the preceding four months. Organizations continue to make progress in the effort to prevent email phishing. Email gateways are more intelligent. Awareness training and regular phishing simulations have conditioned users to be cautious with email, but far less so with collaboration tools. Using collaboration tools for malicious operations helps a threat actor blend in with legitimate operations. Threat actors know this and use collaboration tools for phishing, with Microsoft Teams being one of those tools.
Unit 42 has observed threat actors initiating chats with employees in victim organizations through Microsoft Teams using a range of techniques designed to mask their true identity and appear legitimate. Recent activity includes threat actors leveraging typosquatted domains that closely resemble trusted vendors or internal naming conventions. They also sometimes operate from Microsoft 365 tenants that have no previous affiliation with the target organization. In many cases, these tenants are deliberately named to mimic IT support functions, security teams or managed service providers.
In many organizations, Teams federation is enabled by default, allowing users to communicate with external tenants unless restricted by policy. In more advanced scenarios, threat actors bypass the need for deception altogether by compromising legitimate service provider or partner accounts, and leverage existing trust relationships to initiate chats from domains that are already recognized and allowed.
These chat messages can appear directly in an employee’s feed. Microsoft Teams has an impersonation protection feature that presents additional warnings to the chat recipient, but the onus is still on the user to decide whether to accept the message as legitimate. While Teams provides visual indicators that a sender is external, users may overlook these warnings when the sender appears to represent a known vendor, partner or internal support function. Threat actors count on this combination of visual and domain familiarity to impersonate trusted entities. This lowers user suspicion and increases the likelihood of successful social engineering.
As defenders, we must shift the burden away from the user and prevent as many of these malicious chat requests from reaching the user in the first place.
Hardening Microsoft Teams Against External Abuse
Threat actors like Cloaked Ursa succeed not because MS Teams is insecure, but because external communication settings are often too permissive and users tend to trust internal tools.
Effective defense combines user awareness along with strict configuration and identity-centric controls. We discuss these defenses briefly below. Please refer to Microsoft's Best Practices documentation for a more complete discussion of MS Teams security configuration.
User awareness is important and it needs to evolve beyond typical email phishing training. Workers should be explicitly taught that MS Teams messages can originate from outside the organization and are not inherently trustworthy. Training should involve real-world scenarios such as unsolicited “IT support” messages, requests to approve MFA prompts and instructions to reset credentials. These scenarios should teach users to recognize external indicators in MS Teams, to question unexpected outreach and to verify requests through a separate channel such as a help desk number or internal ticketing system.
Securing MS Teams communication involves configuring who users can interact with via chat. One set of configuration settings, shown in Figure 2 below, controls unmanaged or personal accounts. The setting "External users with MS Teams accounts not managed by an organization can contact users in my organization" controls communication initiated by unmanaged or personal accounts. When enabled, it permits users outside of an organization to initiate conversations. If business cases allow, this setting should be disabled to prevent external users from initiating MS Teams chats with internal users. The parent control for this setting is stricter and named "People in my organization can communicate with unmanaged MS Teams accounts." Toggling this setting to "off" completely disables communication with unmanaged or personal accounts, and should be considered if business cases allow.
Figure 2. Microsoft Teams controls for unmanaged or personal accounts. Source: Microsoft
A second and more impactful setting governs federation and is shown in Figure 3. This setting determines whether users from other Microsoft 365 tenants can communicate with your organization. In practice, many companies leave federation open, enabling communication with any external domain. This creates a large and potentially unmonitored attack surface. If business cases allow, a more secure configuration is to choose "Allow only specific external domains" and then add domains with which the organization typically communicates to an Allow list.
Figure 3. Microsoft Teams controls for federation. Source: Microsoft.
Attacks initiated through MS Teams chats ultimately target identity systems. Because of this, MS Teams hardening should include a review of broader identity protections. Conditional Access policies can ensure that even if a user is manipulated, high-risk actions require additional verification or compliant devices. Privileged roles should be governed through just-in-time access models such as Entra Privileged Identity Management, which reduces the impact of any single compromised account. For additional information on cross-tenant intrusions including Teams, please see Microsoft's mitigation and protection guidance on this topic.
Monitoring also plays a critical role here. External chat initiation should be treated as an event worth investigating, particularly when from previously unseen or typosquatted domains, or if followed by authentication anomalies or device registration events. If malicious chats should get through to one or more users, administrators can remove those chats from users' views to prevent future interaction. Organizations with appropriate Microsoft licensing can enable users to report suspicious Teams messages from chats and channels, similar to the "Report Phishing" function in email.
Final Thoughts
The takeaways are simple but important:
If external chat is open, attackers will use it. Tightening controls around external chat will reduce risk by constraining an entire attack vector. This reduces the chance of phishing chats reaching the user.
Users are conditioned to identify email phishing. Extending user phishing training to cover Microsoft Teams and other collaboration tools creates better awareness and lessens the likelihood of success of a phishing chat that gets through to a user.
We are tracking an increasingly widespread malvertising campaign targeting macOS. This campaign appears to be the next stage of a previous campaign known as JSCoreRunner, which was first identified in August 2025. In recent months, the financially-motivated attackers behind these campaigns transitioned from delivering standard adware, to delivering adware with full backdoor capabilities. We designate this campaign Operation FlutterBridge, and we call the payload that it delivers FlutterShell.
Built using the Flutter framework, FlutterShell infects targets with adware via malicious desktop applications. In addition to its adware functionality, the payload possesses backdoor capabilities, including shell command execution and file system manipulation. Some variants weaponize artificial intelligence (AI) summarization features for data exfiltration by routing documents through an attacker-controlled server before processing them. The FlutterShell malware strain appears to be under active development, with new improvements being rapidly integrated into the code.
Operation FlutterBridge targets a global audience through an extensive Google Ads campaign, with an emphasis on Anglophone and Western European markets, distributed via hundreds of Google-verified advertisements. Our research indicates that the attackers behind this cluster distributed the ads using a series of shell companies, to bypass ad-network vetting and orchestrate these attacks at scale.
We reported these advertisers to Google, which provided the following statement:
Malware has no place on our platforms, and we’ve suspended these advertiser accounts for violating our policies.
We track Operation FlutterBridge and the JSCoreRunner campaign under a cluster of activity that we refer to as CL-CRI-1089.
This article provides a technical overview of the FlutterShell macOS malware and the delivery network behind the malvertising campaigns.
Palo Alto Networks customers are better protected from the threats described in this article through the following products and services:
CL-CRI-1089 is a cybercrime cluster of activity that has been operational since at least 2023. The attackers behind this cluster are responsible for spreading malicious payloads via malvertising campaigns, targeting both Windows and macOS users through separate, ongoing operations.
The attackers’ modus operandi is consistent across these operations: They distributed malicious advertisements using a network of Google-verified shell companies. These ads were designed to trick targets into deploying malware that masquerades as legitimate desktop applications. While in-the-wild observations suggest the malware functions primarily as adware, it possesses capabilities for far more dangerous behavior, effectively functioning as a backdoor.
Operations attributed to this cluster include the RecipeLister and Calendaromatic Windows campaigns, as well as the JSCoreRunner macOS campaign. The Windows activity was previously tracked by other vendors under the broader “TamperedChef” designation, before Unit 42 researchers deconstructed the activity into distinct clusters. In late 2025, the attackers expanded their operations with Operation FlutterBridge, deploying a new macOS backdoor identified as FlutterShell.
Overview of the FlutterShell Malware
FlutterShell is a macOS backdoor developed using the Flutter framework and designed to masquerade as legitimate software. FlutterShell’s authors implemented a WebView-based architecture that utilizes a JavaScript-to-native bridge. This design allows the attackers to host malicious logic on an external website, rather than hardcoding it into the binary. This enables the attackers to dynamically alter FlutterShell's behavior in real time, without needing to recompile or redistribute the application.
FlutterShell has a set of built-in commands that provide attackers with the following capabilities:
Arbitrary command execution
File system interaction
Environment variables exfiltration
During our investigation, we observed FlutterShell being used as adware. Upon execution, the malware modifies Google Chrome configuration files to hijack the browser, forcing all traffic through an attacker-controlled, ad-filled intermediary site.
We identified several versions of FlutterShell that did not yet contain malicious code. Additionally, an examination of the JavaScript logic hosted on the attackers’ infrastructure revealed multiple unfinished functions. These findings, combined with the frequent appearance of new variants, indicate that the malware is likely under active development.
The use of the Flutter framework presents specific analytical hurdles. The Flutter engine compiles Dart code into a dynamic library and uses an Object Pool to store data. This separates the code from the strings and variables it uses, making it difficult for security analysts to see how the malware actually functions. This feature also makes tracing the execution flow of a Flutter application via static analysis particularly challenging. To overcome these challenges, we used a custom version of Worawit Wangwarunyoo's blutter tool to disassemble the Dart binary and reconstruct the application logic.
FlutterShell Deployment and Masquerading
We encountered three versions of FlutterShell in which the malware posed as a podcast player and two different PDF viewers. These desktop applications were fully functional, effectively concealing the malicious logic executing in the background. Figure 1 shows two of the applications on macOS hosts.
Figure 1. FlutterShell masquerading as a legitimate podcast player and PDF viewer application.
All observed samples were signed with valid Apple Developer IDs and successfully passed notarization, meaning Apple's automated security checks did not flag them as malicious at the time of submission. Figure 2 shows the legitimate signature of FlutterShell’s binaries and its successful notarization by Apple.
Figure 2. FlutterShell is signed with valid Apple Developer IDs and successfully passed notarization.
At the time of analysis, all three applications containing FlutterShell had zero detections on VirusTotal, as shown in Figure 3 for the PodcastsLounge application.
Figure 3. Malware analysis conducted on VirusTotal.
FlutterShell Technical Analysis
FlutterShell’s Malicious WebView Architecture
The FlutterShell backdoor logic is not hardcoded into the binary. Instead, FlutterShell employs a WebView-based architecture utilizing a JavaScript-to-native bridge.
In WebView-based architecture, a native application uses an embedded web browser component to display content. The JavaScript-to-native bridge acts as a communication channel between this web content and the host native application, allowing them to exchange data and cross-invoke functionality.
Consequently, the malicious logic of FlutterShell is stored on the attackers’ website and is only triggered when the application loads the specific web content. Figure 4 demonstrates how the application converts web content to native commands.
Figure 4. WebView architecture to native OS code execution graph.
Upon initial execution, FlutterShell waits for a specific duration received dynamically from the command and control (C2) server before contacting the attackers’ website — which contains the malicious JavaScript code — to avoid analysis and build user trust. More details about the backdoor’s delay routine are provided in Appendix A.
JavaScript Bridge Injection Technique
The primary payload of FlutterShell is embedded within the main webpage and a /update-thanks.html subdirectory of the attacker-controlled site. Figure 5 shows the website's landing page.
Figure 5. “Thank You for Updating!” landing page that hides the malicious logic of FlutterShell.
To facilitate communication between the remote attacker-controlled webpage and the infected local system, the malware injects a JavaScript bridge. This bridge uses a message channel named flutterInvoke to pass JSON-formatted commands from the WebView context into the native Dart environment.
The remote webpage acts as the execution environment for the JavaScript-to-native bridge. By loading the external content, the attackers can send JSON-formatted commands to the application, which are then translated into native system calls and operations on the infected machine.
The main webpage and the /update-thanks.html subdirectory retrieve the core malicious logic from external endpoints: /getConfig and /getUpdateThanksConfig, respectively. These scripts contain the JavaScript code that defines which commands should be executed and configures the supported functionality. This architecture allows the attackers to modify the code in /getConfig and /getUpdateThanksConfig at any moment, dynamically altering FlutterShell's behavior without requiring a software update. Figure 6 shows the HTML page presented to the targeted end-user, followed by the subsequent JavaScript code executed by the payload.
Figure 6. JavaScript code in /update-thanks.html responsible for retrieving the malicious logic.
At the time of investigation, the call to /getConfig was either commented out on the main page or the endpoint was unreachable. We also noticed that /getUpdateThanksConfig contained setup functions for commands that were not yet implemented in the FlutterShell binary. The observed inactivity and disabled functions strongly indicate that the malware was still under active development.
Variants and Evolution of FlutterShell
Our investigations up until February 2026 revealed three main variants of the FlutterShell backdoor, each advertised approximately one month apart. The first variant masqueraded as a podcast app named PodcastsLounge while the subsequent variants appeared as PDF viewers named PDF-Brain and PDF-Ninja.
While the three variants masqueraded as different applications, the malicious code and execution flow embedded within them have only minor differences. Notably, the internal package name of the PDF-Brain variant was still labeled podcasts_lounge, revealing its connection to the earlier version.
With each new variant released, we observed developments in the obfuscation used by the attackers behind the campaign. The second variant (PDF-Brain) had some of its strings obfuscated, and the third variant (PDF-Ninja) utilized Flutter’s native --obfuscate flag, which strips debug information and randomizes symbol names, making reverse engineering significantly more difficult. Furthermore, the attackers renamed the malicious commands to mimic legitimate PDF library operations, likely in an attempt to bypass static analysis and Apple's notarization process.
The main differences and overlaps between the three variants are listed in Table 1.
Feature
Variant: PodcastsLounge
Variant: PDF-Brain
Variant: PDF-Ninja
Execution Command
exec_sync
pdf_sync
renderPDF
Command Naming Scheme
Descriptive naming
(e.g: read_file, write_file)
Descriptive naming
(e.g: read_file, write_file)
Deceptive naming
(e.g: read_pdf, write_pdf)
String Storage (/bin/sh )
Plaintext
Base64-encoded
Plaintext (regression)
Binary Obfuscation
None
None
Flutter --obfuscate enabled
C2 Domain
atsheisdomestic[.]org
etoftheappyrince[.]org
healightejustb[.]org
Table 1. Feature comparison matrix of FlutterShell variants.
Another feature differentiating the PDF-Brain and PDF-Ninja variants is an AI summarization tool that doubles as a data exfiltration vector. Instead of sending the file content directly to an AI Agent, FlutterShell forwards the content to the attackers’ C2 server, at the https://[attacker_domain]/summarize-text endpoint. The server functions as an intermediary, forwarding the request to the AI agent. This means that while the user receives an AI summary, the attackers can simultaneously harvest and exfiltrate the entire content of every document processed.
Additionally, we observed that the download sites for PodcastsLounge and PDF-Brain malicious applications share a nearly identical design structure, indicating that the attackers reused the web assets for both campaigns. Figure 7 shows screenshots from both sites.
We also encountered versions of these macOS applications that did not contain any malicious code.
We also noted that the attackers behind CL-CRI-1089 offered Windows versions for all FlutterShell applications. However, up to early February 2026 the Windows versions did not appear to contain any embedded malicious logic. The absence of malicious code in both the macOS and Windows applications may suggest a phased deployment strategy, a technique designed to bypass automated detection.
FlutterShell’s Adware Payload
According to our telemetry, the attackers’ primary goal appeared to be browser hijacking. Upon installation, FlutterShell fingerprints the machine by collecting the hardware’s universally unique identifier (IOPlatformUUID) value using the following command:
Next, the malware targets the Google Chrome “Secure Preferences” file. This file functions as an anti-tamper mechanism by storing a validated copy of the user's settings.
FlutterShell modifies the default_search_provider_data block within this file, specifically changing the url and new_tab_url values to the attacker-controlled domain sinterfumesco[.]com. This modification ensures that every time a user with an infected machine performs a search or opens a new tab, the request is hijacked and sent to the attackers’ domain. Figure 8 shows the modified Secure Preferences file.
Figure 8. The modified Secure Preferences file.
To apply the URL and domain changes, FlutterShell terminates the Google Chrome process using killall "Google Chrome" and immediately relaunches the process with the following arguments:
Google Chrome "hxxps[:]//sinterfumesco[.]com/search?utn=[Tracking Data]=&q=starttt" --restore-last-session --hide-crash-restore-bubble --noerrdialogs --disable-session-crashed-bubble
These flags force Chrome to connect to sinterfumesco[.]com while suppressing the crash restoration warnings (“Chrome did not shut down correctly”) that would normally appear after a forced termination.
This sequence enables attackers to generate revenue by funneling targeted users through an ad-filled intermediary site or showing ads in the background, before finally redirecting the users to a legitimate search engine. Figure 9 shows the detection of suspicious FlutterShell activity, including executing fingerprinting commands and browser hijacking.
Figure 9. FlutterShell browser hijacking activity, as seen in Cortex XDR.
CL-CRI-1089: Campaign Infrastructure and Evolving Tradecraft
We examined the evolution of CL-CRI-1089’s tactics and tradecraft across multiple campaigns since early 2025.
CL-CRI-1089 Ads Delivery Network
Our investigation tracked the activity cluster CL-CRI-1089 through a far-reaching network of Google and YouTube advertisements, both of which are controlled by Google Ads. While Google apparently remediated several ads linked to previous campaigns, the advertiser remained active, and FlutterShell continued to be distributed via hundreds of active advertisements with new instances throughout February 2026.
Verified Shell Entities
Verified Google Ads accounts were the primary distribution vehicle for FlutterShell in this campaign, using verified shell companies AdsParkPro LTD and Advantage Web Marketing LLC. We also observed that this cluster used a different shell entity called SOFT WE ART LIMITED in past Windows campaigns. At first glance, these companies appeared to be legitimate Ukraine and UK-based enterprises, registered years before the malicious activity ever started. Figure 10 shows advertisements by Advantage Web Marketing LLC in the Google Ads Transparency Center.
Figure 10. Tracking Advantage Web Marketing LLC advertisements in Google Ads Transparency Center.
However, although the accounts were verified by Google Ads, a closer look into the three companies revealed the hallmarks of a shell corporation designed for ad-fraud and malware delivery:
All three companies have a minimal digital presence beyond their company websites. The websites themselves have minimal functionality and utilize templated structures, likely designed to create an impression of legitimacy.
Similar patterns in corporate filings revealed one Ukrainian-based and two UK-based companies led by Ukrainian nationals with no verifiable professional history or digital identity.
We identified an approximate one-year latency between the initial Google Ads registration and the first recorded ad spend. This suggests a maturation strategy, in which the attackers allow a legal entity to age, in order to bypass initial fraud-detection filters.
Given the apparent absence of legitimate commercial activity, we assess that these companies were created as a vehicle for this malicious advertising infrastructure.
During our research, we saw proof of the attackers' agility in real-time: AdsParkPro LTD's advertisements were entirely removed from the Google Ads Transparency Center on January 19, 2026. Simultaneously, online business records were modified to list the company as dormant. However, just two weeks later, the actor re-emerged with a new FlutterShell variant, promoted via another verified advertiser, Advantage Web Marketing LLC.
Advantage Web Marketing LLC has been observed not only spreading malicious advertisements but also acting as the signatory for Windows adware variants associated with the CL-CRI-1089 cluster. This suggests that the other identified shell entities (AdsParkPro LTD and SOFT WE ART LIMITED) could also be leveraged in the future to sign malicious binaries.
Adversary Tradecraft and OpSec Failures
Despite the scale and reach of the campaign, the attackers exhibited poor attention to detail in their creative assets. Many advertisements used nonsensical or poorly translated content and generic unpolished visuals. We also observed several instances of cross-contamination, where the actor inadvertently linked the logo of a previous malicious product with the current masqueraded application. Figure 11 shows that PodcastsLounge advertisements display graphics relating to a PDF viewer.
Figure 11. Cross-contamination between two different malicious ads.
The targeting strategy of the advertisements is broad, but deliberate. While most ads were accessible globally, we identified specific geographic clusters where the actor focused their budget. These included Western European markets (notably France and Germany) and English-speaking regions, including the U.S., Canada and Australia. We identified multiple infected hosts targeted by this threat from correlating regions.
Connecting the Dots Behind CL-CRI-1089 Campaigns
This section details the connection between FlutterShell and the two Windows malware strains operated by the attackers behind CL-CRI-1089, and the strong links between FlutterShell and its predecessor JSCoreRunner. This relationship is evident across their infrastructure, architecture and operational behavior.
The CL-CRI-1089 Connection
By pivoting on infrastructure related to the ad-filled intermediary site used in the FlutterShell campaign, we linked the current macOS campaign to two Windows malware strains: RecipeLister and Calendaromatic. Both of these strains were distributed via malvertising campaigns, and are tracked as part of the CL-CRI-1089 cluster of activity. High traffic rankings for these related domains indicate a wide distribution of the adware.
Calendaromatic and RecipeLister also share technical similarities with FlutterShell, including a WebView-based code architecture that allows dynamic payload changes. In the case of the RecipeLister and Calendaromatic malware strains, the actor encoded content within hidden characters or date synonyms. In FlutterShell, the attacker directly embedded the commands in the website’s content.
All of the malicious applications hijack the victim's browser, redirecting it to similarly structured websites, which present the user with icons linked to well-known brands.
When looking into RecipeLister, we found yet another shell entity responsible for spreading malicious adware — SOFT WE ART LIMITED. This company shares commonalities with other shell companies tied to Operation FlutterBridge: a UK-based entity with one Ukrainian member of personnel who could not be traced to any known real employees. The company’s current website remains active, and shares content and phrasing similarities with AdsParkPro LTD’s previous digital footprint, which has transitioned across three distinct domains since 2024.
The JSCoreRunner Connection
In addition to its connection with Windows-based campaigns, our analysis identified significant links between FlutterShell and the previously documented JSCoreRunner (also known as FileRipple).
As mentioned in a report by Moonlock Labs, JSCoreRunner was also distributed by the same verified publisher — AdsParkPro LTD. This shared distribution point is the first key indicator that the campaigns are connected. Furthermore, the technical characteristics of both strains confirm a shared origin; they both utilize a specialized JavaScript-to-native bridge and exhibit clear similarities in command structure and functionality. These similarities are discussed in further detail in Appendix B.
Figure 12 shows an example of a Cortex XDR alert that successfully flagged FlutterShell activity by identifying browser hijacking activity similar to its predecessor, JSCoreRunner.
Figure 12. Cortex XDR alert for FlutterShell activity flagged as similar to JSCoreRunner.
Conclusion
The evolution from JSCoreRunner to FlutterShell represents a significant increase in technical depth for the attackers behind CL-CRI-1089. By transitioning to the Flutter framework and adopting a dynamic, WebView-based architecture, the attackers have effectively separated their malicious logic from the binary. This shift not only complicates static analysis, but allows the attackers to modify the malware's behavior on the fly, turning what appears to be a nuisance adware strain into a fully functional backdoor.
Furthermore, the scale of the distribution network, coupled with the verified shell entities used to bypass ad-network vetting, highlights the persistent danger of malvertising. The coordination of multiple shell entities, and the rapid development and delivery of new FlutterShell variants, indicates that this campaign is far from over. Up until late March, we continued to witness the distribution of FlutterBridge malware variants. As the attackers behind CL-CRI-1089 continue to refine their JavaScript-to-native bridge techniques, we expect to see this architecture deployed in future campaigns targeting both macOS and Windows environments.
Palo Alto Networks Protection and Mitigation
Advanced WildFire
The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of indicators associated with this malware.
Cortex XDR and XSIAM help to prevent the threats described in this article, by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, to prevent both known and unknown malware from causing harm to endpoints. The mitigation methods implement malware protection based on the different operating systems – Windows, macOS and Linux.
How the Agentic Assistant Supported the Investigation
Cortex’s AgentiX Agentic Assistant streamlined the investigation by allowing the team to query the data using natural language, providing deeper context and insights, and suggesting clear recommendations on what should be done next. Figure 13 shows the AgentiX interface when finding processes that communicate with a malicious domain used in the FlutterBridge operation.
Figure 13. Finding processes that communicated with atsheisdomestic[.]org, using AgentiX.
Indicators of Compromise
SHA256 Hashes of Malicious Files From FlutterShell Activity (PodcastsLounge)
Appendix A: Analysis of Additional FlutterShell Features
Loading the WebView
FlutterShell initiates the WebView and loads the attackers’ website in the following cases:
Initial execution: Automatically, following a calculated delay received dynamically from the C2.
User Interaction: When the targeted user clicks the About or Update buttons in the application settings.
Upon initial execution, FlutterShell waits for a specific duration before contacting the attacker-controlled website. This delay is non-deterministic and is calculated during the application's startup routine:
Immediately after launch, FlutterShell sends an HTTP GET request to [attacker_domain]/api/update-delay to fetch the delay duration in seconds.
If this endpoint is unreachable, the malware defaults to a 600 second (10 minute) delay. If the server responds, but the delay field is null, it defaults to a 1200 second (20 minute) delay.
Once the timer expires, FlutterShell forces the application to the foreground and presents the webpage [attacker_domain]/update-thanks.html.
This calculated delay suggests a deliberate strategy to evade automated sandbox environments, which typically time out within a few minutes. Simultaneously, it builds user trust by maintaining a period of “normal” application behavior before the malicious window appears.
If the user clicks the About or Update buttons in the application settings, FlutterShell loads the attackers’ main website page or the update-thanks.html page, respectively. In both scenarios, the loaded webpages contain JavaScript code that executes immediately upon loading.
FlutterShell’s Update Mechanism via the Sparkle Framework
The FlutterShell backdoor uses the Sparkle software update framework for macOS applications in its update mechanism. However, it significantly deviates from the standard Sparkle protocol, to avoid detection.
In a legitimate implementation, once Sparkle finishes downloading an update to the cache, it triggers a user interface (UI) prompt, such as “A new version is available. Install and Relaunch?”. The update process halts here until the user manually clicks the button to approve the restart. To bypass this user interaction, FlutterShell interrupts the flow the moment the download completes.
Our analysis of this sequence reveals the following flow:
Callback reception: The malware listens for the update completion signal in the function SparkleUpdateService:_handleMethodCall() marked as the string onUpdateCycleFinished from the native macOS layer.
Installation verification: If the update completed without errors, the code checks for the existence of the Sparkle installation directory: $HOME/Library/Caches/com.app.[appname]/org.sparkle-project.Sparkle/Installation/.
Manual execution: Rather than waiting for the user to authorize the install, the malware programmatically executes the open command on the staged app bundle found in the cache.
Forced termination: It immediately executes dart:io exit(), killing the old running process instantly.
This sequence effectively “swaps”" the malware version in real time, without ever showing a dialog box. This ensures that the updated malware begins running without any UI interaction, allowing the attackers to upgrade the backdoor's capabilities silently.
Supported FlutterShell Commands Analysis
FlutterShell’s built-in commands provide full backdoor capabilities, allowing the attackers to execute shell commands and manipulate files on the system. Table 2 lists the commands and capabilities of FlutterShell found collectively within the three identified variants — PodcastsLounge, PDF-Brain and PDF-Ninja.
Category
Commands and Features
Description
Variant
PodcastsLounge
PDF-Brain
PDF-Ninja
Execution
exec_sync
pdf_sync
renderPDF
Executes arbitrary shell commands with current user permissions
Filesystem
read_file
write_file
read_dir
exists
get_home_dir
read_pdf
write_pdf
read_pdf_dir
pdf_exists
get_pdf_dir
Read files
Write files
Get directory structure
Harvesting
get_env
Extracts environment variables. These may contain high-value assets like plaintext API keys for secondary access.
UI Manipulation
close_webview, setSize
Resize the application’s windows, likely to reduce user suspicion.
Table 2. An example of FlutterShell’s backdoor capabilities.
We also saw that some variants of FlutterShell have the com.apple.security.files.downloads.read-write macOS entitlement, which gives the malware the capability to read and write to files in the user’s Downloads directory.
Appendix B: Technical Similarities Between JSCoreRunner and FlutterShell
The architectural fingerprints of both JSCoreRunner and FlutterShell malware families are nearly indistinguishable. Both rely on a specialized JavaScript-to-native bridge, using JavaScript as a high-level conductor to trigger low-level system operations.
The most compelling evidence of a shared lineage is the backdoor primitives. We found a set of six identical core commands embedded in both JSCoreRunner and FlutterShell, as Table 3 shows.
Capability
FlutterShell
JSCoreRunner
Check File/Dir Existence
exists/existsSync
_fsExistsSync
Execute Command
exec_sync/pdf_sync
_execSync
File Reading
read_file
_fsReadFileSync
File Writing
write_file
_fsWriteFileSync
Dir Enumeration
read_dir
_fsReaddirSync
Get Home Directory
get_home_dir
_osHomedir
Table 3. Function name comparison between JSCoreRunner and FlutterShell.
Operationally, the campaign objectives remain consistent. Both have been observed primarily as browser hijackers, with a specific focus on compromising Google Chrome installations to inject ads or scrape sensitive session data.
While the fundamental architecture is the same, FlutterShell represents a significant tactical evolution over JSCoreRunner. The primary shift lies in their different payload delivery methods — while JSCoreRunner’s logic is embedded statically in the binary, FlutterShell’s logic is received dynamically from the C2 server at runtime.
This shift has significant implications for detection and response. Dynamic delivery means attackers can decouple the binary from its logic by updating their logic without needing to recompile the application. In addition, dynamic content delivery allows the attacker to use geofencing and avoid certain regions and entities to download the malware’s payload, thus hindering analysis even more.
The 2026 FIFA World Cup will be the largest sporting event ever staged. Across 39 days, 16 host cities in three nations will host 104 matches, an expanded 48-team tournament and an estimated five-to-six million in-venue spectators alongside a global broadcast audience approaching half the planet.
The tournament opens at Estadio Azteca in Mexico City on June 11, 2026, and concludes at MetLife Stadium in East Rutherford, New Jersey, on July 19, 2026.
This is the first World Cup to be jointly hosted by three nations. Each match runs on a temporary, multi-ring tournament network grafted onto pre-existing NFL, MLS, CFL and Liga MX stadium environments. It depends on a network of municipal services, including public transit, signalized traffic, water and wastewater treatment, regional power, airport operations and emergency services. Each of those touchpoints is in scope for an adversary.
Based on a review of cyber operations against prior mega-events from 2016 through the Milano-Cortina 2026 Winter Games, this assessment finds that disruptive intrusions, criminal fraud at scale and politically motivated distributed denial-of-service (DDoS) and hack-and-leak operations are highly likely. The only meaningful questions are who, against which targets and at what severity.
There are three drivers in the 2026 World Cup risk picture:
Iran-nexus activity. The U.S.–Israel–Iran kinetic conflict that began on Feb. 28, 2026 has reordered the threat surface for any U.S.-hosted event. The Handala Hack Team, assessed by the U.S. Federal Bureau of Investigation (FBI) and multiple commercial threat intelligence firms to be a front for Iran's Ministry of Intelligence and Security (MOIS), executed significant wiper attacks in early 2026. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) published a joint advisory AA26-097A confirming an active, ongoing Iranian-affiliated campaign. The campaign targets internet-exposed Rockwell Automation and Allen-Bradley programmable logic controllers (PLCs) in U.S. critical infrastructure, as well as Islamic Revolutionary Guard Corps (IRGC) targeting of Israeli-made Unitronics Vision Series PLCs at U.S. water, energy and municipal targets. These are the same categories of infrastructure that World Cup host cities will be operating under tournament load.
Russia-nexus hacktivism. Since 2022, NoName057(16) has conducted over 3,700 verified DDoS attacks against governments and critical sectors in NATO member states. Documented surges keyed to politically symbolic events including the NATO Summit, the Ukraine Peace Summit and claims of intent at the Paris 2022 Olympics and the Milano Cortina 2026 Winter Olympics. Operation Eastwood (July 2025) disrupted but did not eliminate the group. The UK NCSC confirmed continued operations into 2026. The U.S., Canada and Mexico are NATO partners or allies and the World Cup is a politically symbolic event of the highest order.
Financially motivated cybercrime. Group-IB identified more than 16,000 fraudulent domains and 90 compromised Hayya fan-portal accounts during World Cup 2022 in Qatar. The 2023 Muddled Libra (operators of ALPHV aka BlackCat ransomware) campaign against entertainment organizations demonstrated that the hospitality stack is a target for ransomware operators. The stack includes reservations, digital keys, point-of-sale (PoS) machines and loyalty data. Ticket fraud, accommodation fraud, transportation QR-code fraud and FanID-equivalent account takeover are prime targets at scale across all three host nations.
The Paris 2024 Olympics is a strong example of a recent precedent. French authorities (ANSSI) confirmed at least 140 cyber events during the Games, including 22 confirmed unauthorized intrusions and a ransomware attack against the Grand Palais venue.
None succeeded in disrupting competition, but only because of preparation that began years earlier. Preparation included exercises against 500 Games-linked facilities, and support by sustained government-industry coordination. The 2026 tournament must clear the same bar across multiple jurisdictions, regulatory bodies and languages.
The Bottom Line
Defenders should plan against the possibility of all of the following:
Cybercriminals targeting fans and the hospitality supply chain
Iran-nexus disruptive operations against ancillary U.S. infrastructure during the tournament window
Pro-Russian and pro-Iran hacktivist DDoS and defacement targeting of host-city, federation and ticketing services
A wiper deployed against tournament IT during a high-visibility ceremony
Previous Attacks Against Major International Sporting Events
French Rugby Federation systems encrypted three months before kickoff; Personally identifiable information (PII) exfiltrated. No on-field disruption. Reputational and financial damage.
ANSSI: 140+ events, 119 low-impact, 22 successful intrusions. Ransomware on Grand Palais venue and approximately 40 other museums. DDoS peaks at 190,000 req/sec on official site. No competition was disrupted.
Milan-Cortina Winter Olympics
2026
Italian Foreign Minister Antonio Tajani said in a press conference that Italy thwarted attacks
No public confirmation of disruption to competition. Italian National Cybersecurity Agency operated a dedicated command centre throughout the Games.
Table 1. Previous attacks against major sporting events.
Cybercriminal Threats to Fans and the Tournament Supply Chain
Financially motivated cybercrime is the highest-volume, highest-likelihood threat category for the 2026 FIFA World Cup Games.
Ticket Fraud and FanID-equivalent Account Takeover
Credential-stuffing attacks against the official fan portal
Hospitality and Accommodation Fraud
Attacks against hospitality businesses and platforms, digital key infrastructure, point of sale (PoS) and identity providers and fake short-term rental properties are another potential area of risk.
QR-Code, Transportation and PoS Fraud
Tournament-specific QR-code fraud is the single fastest-growing variant. There have already been observed pre-tournament listing scams, and a high potential for fake shuttle passes, parking permits and official fan transport QR codes that fail when scanned. The geographic spread of the 2026 games in various cities multiplies opportunities for transit-themed fraud relative to single-host-city games.
Phishing, Malware and Lure Themes
Confirmed lure themes from prior tournaments include:
Lottery winnings
Ticket cancellations
FIFA dispute-resolution decisions
Accreditation problems
FanID issues
Free streaming
Counterfeit merchandise
Expect to see typosquatted FIFA domains, malicious mobile applications, infostealers sold on Telegram, and Telegram-based reseller channels moving money via peer-to-peer payment apps as seen in Table 2.
Cybercriminal Vector
Primary Targets
Phishing/lookalike domains/typosquatting
All fans, especially first-time international travelers
Fake/resold tickets; FanID account takeover
Fans buying outside the FIFA platform
Hospitality ransomware (High-profile operators)
Hotel chains, property management, casino-resort venues
DDoS against host-city, federation or ticketing services
Pro-Russian and pro-Iran hacktivist targets
Hack-and-leak/doxxing of officials, sponsors, athletes
Table 2. Cybercriminal techniques that are possible during the World Cup.
Geopolitical Threats: Iran-Nexus and Disruptive Hacktivism
The geopolitical context for the 2026 tournament is materially different from any prior World Cup. The U.S.-Israel-Iran conflict has produced a surge in Iran-nexus cyber operations against U.S. organizations. The Russia-Ukraine war and the resulting NATO alignment of all three host nations make pro-Russian hacktivism an additional, parallel risk.
Every World Cup host city in the United States operates municipal water, wastewater and energy infrastructure inside this advisory's threat envelope. A 2024 CISA assessment found over 70% non-compliance with existing safety requirements at U.S. water utilities.
Iran-Nexus: Other Personas and the Electronic Operations Room
Beyond Handala and CyberAv3ngers, multiple Iran-aligned personas — DieNet, APTIran, Cyber Toufan, Cyber Support Front, Iranian Avenger, Cyb3r Drag0nz — have been observed operating through a team named the Electronic Operations Room of Islamic Resistance Axis. This team formed in late February 2026. DieNet has specifically claimed DDoS attacks against Bahrain and Saudi airports and Jordanian banks — transportation and finance targets directly relevant to fan-facing infrastructure.
Russia-Nexus: NoName057(16) and Allied Hacktivists
NoName057(16) has been the most operationally consistent pro-Russian hacktivist group since March 2022, with an attributed 3,700-plus targeted hosts to the group between July 2024 and July 2025. The UK NCSC, Eurojust and Europol issued co-sealed advisories in December 2025 and January 2026 regarding the hacktivist group. Operation Eastwood produced two arrests and seven arrest warrants but did not stop the group, which resumed activity within days.
Three operational characteristics are directly relevant to 2026:
Volunteer-driven scale: DDoSia rewards volunteer participants with cryptocurrency and runs on Windows, Linux, Android and Docker.
OT expansion: A co-sealed advisory and subsequent UK NCSC alert specifically warns that pro-Russian hacktivists have moved beyond DDoS into operational technology (OT) targeting via exposed VNC and remote-access services.
The current conflict in Iran opens the door for potential Iran-based narrativeamplification, consistent with its observed hybrid offensive approach, specifically aimed at compounding the division of support for kinetic activity and targeting countries or athletes from Gulf states perceived as adversarial.
People’s Republic of China-aligned Dragonbridge has increasingly experimented with and deployed generative AI tools — such as synthetic audio, AI-generated news hosts, avatars, and images — to scale its political influence operations across social media, though these efforts have ultimately failed to garner significant organic engagement from authentic viewers.
Temporary Multi-City Tournament Infrastructure
FIFA's published tournament structure presents a unique and historically large attack surface. Sixteen host cities span three host nations, four time zones and multiple regulatory regimes. Each match operates a layered, ring-based tournament network grafted onto a permanent stadium environment, depends on a temporary commercial supplier ecosystem and pulls on host-city public services that FIFA does not own. Table 3 lists these rings and the primary cyber risk to each.
The 2026 supplier ecosystem will be vast. Each host city contracts independently for stadium operations, security, transit, hospitality, food service, signage, fan-zone production and last-mile network connectivity. The Pyeongchang 2018 Olympic Destroyer destructive case is a clear historical warning: Recorded Future identified that Olympic Destroyer samples targeting the IT service provider were timestamped five minutes ahead of samples targeting the host.
Impact on Municipal, State and Federal Infrastructure
Municipal Layer
CISA AA26-097A identifies “Government Services and Facilities (to include local municipalities)” as one of three named target sectors of the active Iran-nexus PLC campaign. Analysis of CyberAv3ngers' targeting found that small municipal authorities are deliberately selected because they manage OT with consumer remote-access tools or expose PLC interfaces directly to the internet. A January 2024 Russian cyberattack on a municipality in Texas resulted in successfully overflowing a water tank after unsuccessful attempts in neighboring water systems. Ransomware attacks on water systems have also occurred.
State and Provincial Layer
Pro-Russian hacktivist DDoS has already demonstrated the ability to take state and local government websites offline for hours. UK NCSC's January 2026 alert specifically called out persistent NoName057(16) targeting of UK local-government services. The U.S., Canadian and Mexican equivalents are inside the same threat envelope.
Federal Layer
Federal agencies have signaled awareness: CISA AA26-097A, the DOJ domain-seizure activity against Iranian cyber fronts and the U.S. State Department's $10 million reward offers indicate active coordination. Defenders should expect and request pre-tournament threat-sharing engagements with CISA, FBI, the Canadian Centre for Cyber Security and Mexico's CERT-MX, mirroring the model that ANSSI ran in advance of Paris 2024.
Cascading-Risk Scenarios
Two specific scenarios merit pre-tournament tabletop exercise.
OT Disruption at Host-City Utility During Match
Scenario: An Iran-nexus actor manipulates a wastewater PLC in a host city overnight before a knockout match, producing a service alert and a forced public-health advisory.
Mitigation
Pre-tournament audit of all internet-exposed PLCs per CISA AA26-097A
Mandated migration off TeamViewer/AnyDesk for OT
Default-credential audits
24/7 OT incident-response retainer
Hospitality Ransomware in Final Week
Scenario: A Muddled Libra-style social-engineering campaign against a major host-city hotel operator collapses room access, mobile check-in and PoS for 48-72 hours during the run-up to the July 19, 2026, final at MetLife Stadium.
Mitigation
Pre-tournament tabletop exercises with major hotel groups
Explicit verification protocols on IT help desks
Segregation of IdP trust from ESXi management
Offline runbooks for the property-management system
Prioritized Threat Matrix
The following matrix in Table 4 consolidates the assessed likelihood and severity of each evidence-backed threat vector for the tournament window of June 11-July 19, 2026. Severity is conditioned on the potential impact to fans, host cities and the integrity of the competition.
Disinformation/AI-generated content around matches
Medium
Multiple state and non-state actors
Insider compromise at a tournament supplier
High
Cybercriminal-for-hire; state-backed
Mobile malware via fake apps in official stores
Medium
Cybercriminal
Table 4. Prioritized threat matrix of likely cyberattacks.
Recommendations
These recommendations are derived from the threat picture above and from public after-action reporting on Paris 2024 and Milan-Cortina 2026. They are prioritized by impact rather than by category.
For the tournament organization and host-city committees
Stand up a single, multi-jurisdictional cyber operations center with U.S. CISA, the Canadian Centre for Cyber Security, Mexico's CERT-MX, the FBI, the RCMP and Mexican federal cyber liaison co-located or fully integrated, replicating the ANSSI/Paris 2024 model.
Inventory the full vendor and supplier graph for each host city and conduct credential-rotation, default-password and remote-access audits across that graph. Prioritize IT service providers and venue operations, which Recorded Future identified as Pyeongchang's primary breach vector.
Mandate that no tournament network, at any ring, permits consumer remote-access tools on production infrastructure for the duration of the tournament window.
Pre-position DDoS scrubbing capacity, content-delivery-network failover and rate-limiting on all fan-facing domains. NoName057(16) DDoS volumes during Paris 2024 peaked at 190,000 requests/second; defenders should plan for an order of magnitude above that.
Run a destructive-malware tabletop. Validate that backups are isolated, immutable and recoverable inside a four-hour window.
For host-city utilities and municipal operators
Audit every internet-exposed PLC, HMI and SCADA component in water, wastewater, energy and transit operations. Apply CISA AA26-097A and AA23-335A guidance specifically: Change all default credentials, place PLCs behind segmented firewalls and eliminate direct internet exposure on ports 44818, 2222, 102, 22 and 502.
Engage the FBI, CISA and EPA for sector-specific assessments before kickoff. Where budget is constrained, a single round of vulnerability scans focused on the AA26-097A indicator set is high value.
Establish 24/7 OT incident response coverage through the entire tournament window.
For hospitality and venue operators in host metros
Treat the IT help desk as the first line of defense and the most likely point of compromise. Implement out-of-band caller-verification protocols; ban credential resets initiated by phone alone; assume that publicly identifiable employees are reconnaissance targets.
Segregate identity-provider trust from VMware ESXi management. Previous compromises pivoted from Okta to ESXi to ransomware; that pivot path must be broken architecturally before the tournament, not during it.
Maintain offline runbooks for property-management, PoS, digital-key and reservation systems. Confirm pen-and-paper fallback works under load.
For sponsors, federations and broadcast partners
Assume executive personal accounts are in scope for state-aligned hack-and-leak operations.
Apply phishing-resistant MFA (FIDO2/WebAuthn) to all corporate, executive and high-visibility employee accounts before kickoff. SMS and TOTP MFA are insufficient against the demonstrated tradecraft of Scattered Spider and Handala.
Pre-build communications response templates for hack-and-leak scenarios; do not draft them under live attack.
For fans and the traveling public
Buy tickets only on the official FIFA platform or a FIFA-authorised resale partner. Do not buy through Telegram, WhatsApp, social media DMs or peer-to-peer payment apps. Use a credit card with chargeback protection.
Verify accommodation listings with major platforms; treat off-platform wire transfers and cryptocurrency requests as fraud. Cross-reference street view and listing photos.
Treat any QR code presented in transit, parking or fan-zone contexts with skepticism. Cross-check with the host city's official transportation app or website before scanning.
On public Wi-Fi, use a reputable VPN for any account-level activity; better still, use cellular data. Disable Wi-Fi auto-join; remove networks after use.
Patch mobile devices. Avoid sideloading apps. Verify every FIFA app against the FIFA-published list of official applications.
Final Thoughts
The window for shifting from preparation to live response is closing fast. The 2026 FIFA World Cup conditions are different than at any previous tournament: three host nations, sixteen host cities, a 48-team field, an active U.S.-Israel-Iran kinetic conflict, an ongoing Russia-NATO confrontation and a cybercriminal ecosystem that has industrialized against the hospitality sector since 2023.
The threat actors of greatest concern for 2026 — the Handala Hack Team, CyberAv3ngers, NoName057(16), Muddled Libra, ALPHV affiliates and the broader Iran- and Russia-aligned hacktivist ecosystem — have all demonstrated their capabilities within the last 24 months. This has been proven in public record by what these actors have already accomplished.
Plan for incidents across the full supplier and host-city graph, exercise the response against realistic scenarios and coordinate across jurisdictions before kickoff rather than during the tournament. Where that posture has been adopted, the historical record shows that competition has not been disrupted. Where it has been weaker, adversaries have succeeded. The single most important defender posture for 2026 is to assume the attacks will come.
Extortion Activity No Longer Requires Encryption for Payment
This blog dives into the growing trend of data theft and extortion activities which no longer require the use of ransomware to pressure victims into paying a demand. We examine the financially-motivated threat actors using both single and double extortion techniques and what this means for organizations going forward, especially with the arrival of frontier AI models.
Shifting Threat Landscape Observations
As detailed in our 2026 Global Incident Response Report, Unit 42 observed a notable decrease in the use of encryption for extortion-related cases last year. The total percentage in 2025 dropped to 78%, much lower than the near-or-above-90% levels observed between 2021-2024. Other security organizations have seen similar trends, with Google reporting a gradual rise in data theft and extortion incidents from approximately 2% in 2020 to 15% in 2025. Resilience also observed an increase in extortion-only incidents in 2025, rising from 49% in the first half to 65% in the second half.
In 2025, pure data-exfiltration campaigns heavily targeted Professional Services, Healthcare and Consumer Services firms with threat actors specifically focused on mid-sized organizations accounting for 64% of victims. Interestingly, while Manufacturing remains the single most disrupted sector overall, Construction has witnessed a 44% year-over-year increase as a data-only extortion hotspot. These firms are attractive targets due to lucrative financial blueprints and bidding data combined with data egress controls.
The current data-only extortion economy is directly fueled by a heavily-regulated compliance landscape, which threat actors have effectively weaponized. Strict mandates like the SEC's 4-day disclosure window and GDPR’s 72-hour reporting rule have created a regulatory countdown clock, allowing threat actors to force rapid negotiations before organizations can complete internal assessments. Because global privacy frameworks, state-level breach notification laws and post-leak class-action litigation have driven the average cost of data-theft extortion to $5.08 million (and over $10 million for broader U.S. breaches), data exposure alone carries disastrous financial liabilities. Threat actors recognize that regulatory penalties are so severe that the compliance framework itself compels corporate payouts.
As recently noted by our Chief Security Intelligence Officer, Wendi Whitmore, it only took 39 seconds for threat actors to move from initial access to data exfiltration in one case.
Differences in Extortion Operations
Unit 42 is actively monitoring several threat actors that are continuously conducting data theft and extortion operations. The notable differences between these attackers is their use of initial access techniques and the number of extortion techniques to pressure victims into payment.
Initial Access via Software Supply Chain Compromise
TGR-CRI-1135 (aka TeamPCP) has been active since at least late 2025. According to Wired, this group has conducted upwards of 20 distinct supply chain compromise attacks which have led to the injection of malicious code into over 500 pieces of software. We previously reported on the group’s activities earlier this year and how their malware was able to successfully exfiltrate sensitive secrets (cloud access tokens, SSH keys, Kubernetes secrets) from victims.
In recent months, TGR-CRI-1135 has been partnering with various ransomware-as-a-service (RaaS) and extortion-as-a-service (EaaS) operators to monetize their ongoing intrusion activities. On the EaaS front, they have been collaborating with the operators of LAPSUS$ Group to extort targeted organizations via their data leak site as shown below in Figure 1.
Figure 1. Screenshot of LAPSUS$ DLS post on May 21, 2026. Source: Dark Web Informer.
On the RaaS front, they have been working with the operators of Vect ransomware based on communications observed via the BreachForums cybercrime forum as shown in Figure 2. Unit 42 is also aware of claims by one of Vect’s affiliates, the Rostova Organization, that they are also partnering with TGR-CRI-1135.
Figure 2. Screenshot from HasanBroker’s BreachForums post on March 25, 2026. Source: Unit 42.
On May 13, 2026, TGR-CRI-1135 announced the release of an open source version of Shai-Hulud on BreachForums as shown in Figure 3. Going forward, as noted in our most recent threat research article, this will likely make attribution more difficult given that copycats may leverage the tool in similar supply chain compromise attacks.
Figure 3. Screenshot from BreachForums post on May 13, 2026. Source: Unit 42.
One notable development related to Vect was the announcement on BreachForums shown in Figure 4 which states that those operators have been removed from the forum. It is unclear if this will have a material effect on their collaboration with TGR-CRI-1135 going forward.
Figure 4. Screenshot from Resolute’s BreachForums post on May 21, 2026. Source: Unit 42.
At this time, Unit 42 is not aware of TGR-CRI-1135 using any additional extortion techniques to pressure victims into paying their ransom demands outside of purely data exfiltration.
Initial Access via Vishing
Bling Libra continues their rampage of infiltrating customer SaaS tenants for data theft and extortion operations, which Unit 42 reported on extensively in 2025. The operators have distanced themselves from the cybercriminal alliance known as Scattered LAPSUS$ Hunters based on a Telegram message shown in Figure 5.
Figure 5. Screenshot from scattered LAPSUS$ hunters part 7 chat on May 11, 2026. Source: Telegram.
However, their playbook has remained relatively unchanged based on Unit 42 observations. They continue to use vishing for initial access, directing unsuspecting victims to phishing sites designed to intercept user credentials and multifactor authentication (MFA) codes and ultimately registering their own devices to establish persistence within targeted environments. The operators still use the same Tox ID to communicate with victims and also maintain a Tor-based data leak site.
In comparison to TGR-CRI-1135, Bling Libra uses additional extortion techniques outside of pure data theft to pressure victims into paying a ransom. Unit 42 is aware of their adoption of both distributed denial-of-service (DDoS) attacks and information leaks to media outlets as added leverage points to extort victims.
On the flip side, an activity cluster tracked by Unit 42 as CL-CRI-1116, which overlaps with public reporting on BlackFile, has followed a similar pattern of activity in terms of a playbook-driven approach with some subtle and not so subtle nuances.
While the attackers behind CL-CRI-1116 also use their own Tor-based data leak site, they do not reuse the same Tox ID across victims and typically use a different registrar to set up their phishing sites in comparison to Bling Libra.
The major difference between CL-CRI-1116 and Bling Libra is the former’s use of swatting employees as a double extortion technique. This act is typically defined as placing a false emergency call to first responders, such as reporting a fake crime at a specific location to trigger a physical response. In many cases, this is expected to create chaos and can potentially even lead to acts of violence.
This convergence between cyber and physical security can lead to complications if these two teams aren’t in regular communications with each other on how to address such a situation, especially as it pertains to executive protection.
One recent development regarding the attackers behind CL-CRI-1116 is the closure of their former data leak site and the rebranding of their program under the name “Redact” with a new data leak site as shown in Figures 6 and 7.
Figure 6. Screenshot from BlackFile data leak site post on May 11, 2026. Source: Unit 42.Figure 7. Screenshot from BlackFile data leak site post on May 19, 2026. Source: Unit 42.
Looking Forward
In recent weeks, Palo Alto Networks has been at the forefront of providing guidance to organizations on how to secure their environments from the inevitable weaponization of frontier AI models like Mythos by threat actors. These models currently accelerate at finding and chaining vulnerabilities together to exploit flaws in applications and infrastructure alike. For example, Anthropic recently disclosed how Mythos was able to identify approximately 23,000 potential vulnerabilities across 1,000 open source software projects. We have also observed in AI-assisted scenarios that the time from initial access to data exfiltration has dropped to as little as 25 minutes. With this in mind, what do extortion activities, regardless of initial access vector or use of single vs double techniques, look like in the age of frontier AI models?
In terms of software supply chain compromise, TGR-CRI-1135 has already targeted AI environments as part of their ongoing campaigns, but what if they were able to weaponize a frontier AI model to further accelerate the speed and scale of their intrusion activities? This would compound the already complex problem of organizations trying to secure their application development and CI/CD pipelines from these types of attacks. The recent disclosure of the SymJack is a prime example of how AI agents could be leveraged in these types of attacks.
With regards to vishing, AI-powered call center platforms like ATHR can nearly fully automate these attacks for human operators by utilizing AI agents to manage calls and other aspects of the intrusion lifecycle. This service not only lowers the barriers to entry for less sophisticated cybercriminals but also further accelerates attacks for more sophisticated threat actors like Bling Libra. The incorporation of frontier AI models into a platform like this would only exacerbate the speed and scale of attacks leveraging this type of capability.
We believe there is an approximate window of 3-5 months before these frontier AI models are weaponized by threat actors. The time is now for organizations to capitalize on a moment where we as defenders can truly establish a “left of bang” posture against a volatile threat landscape.
Defensive Recommendations
Data Exfiltration Detection and Prevention
Deploy data loss prevention (DLP) controls at cloud, endpoint, and network egress points.
Baseline and alert on abnormal egress volume and velocity.
Monitor for staging behavior.
SaaS Security Posture Management
Audit OAuth token grants, third-party app integrations, and API permissions across SaaS platforms.
Enforce conditional access policies that restrict SaaS sessions by device compliance, location, and risk score.
Implement SaaS audit log aggregation and anomaly detection.
Identity and Vishing Resilience
Migrate from OTP-based MFA to phishing-resistant authentication (FIDO2/WebAuthn hardware keys).
Implement help desk identity verification procedures that cannot be socially engineered.
Conduct targeted vishing simulation exercises.
Software Supply Chain Integrity
Implement software composition analysis (SCA) and dependency pinning in CI/CD pipelines.
Rotate and vault all secrets exposed to CI/CD environments.
Monitor package registries for typosquatting and unauthorized updates to internal or frequently-used packages.
Enforce code signing and provenance verification for all artifacts entering production.
AI-Accelerated Threat Preparedness
Pressure-test detection and response capabilities against compressed attack timelines.
Prioritize vulnerability remediation for internet-facing and AI-discoverable attack surfaces.
Deploy voice authentication and call verification controls for inbound calls.
Unit 42 Deep and Dark Web is a service that assists with gaining visibility into unknown and emerging risks of content posted on the deep and dark web, informs organizations about the exposure of sensitive information, and helps reduce the time between detection and response.
Unit 42 Frontier AI Defense is an elite service that uses access to frontier models to identify your organization's likely attack paths before attackers can weaponize them.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
South Korea: +82.080.467.8774
Get updates from Unit 42
Peace of mind comes from staying ahead of threats. Subscribe today.
Get the latest news, invites to events, and threat alerts