Threat actors have systematically upgraded their command-and-control (C2) infrastructure to use Web3, also known as Web 3.0 or decentralized blockchain web architectures. This advancement goes from using static C2 endpoints hard coded in malware binaries to using Web3-powered smart contracts. Threat actors are then enabled to dynamically update entire botnets and worm network infrastructures with a single smart contract transaction.
According to the 2026 Unit 42 Global Incident Response Report, software supply chain compromises have become a leading initial access vector targeting enterprise cloud environments. By poisoning open-source dependencies, threat actors bypass traditional authentication perimeters to harvest the following from developer endpoints and continuous integration/continuous deployment (CI/CD) pipelines:
Elevated cloud identity tokens
Service account keys
Deployment secrets
Recent supply chain campaigns, most notably the ChainDrop npm worm and the PolinRider campaign, demonstrate how open-source packages are engineered specifically to extract ephemeral cloud access keys and establish persistence within developer workflows. This operational shift has been seen in North Korea-affiliated state-sponsored actors, such as Alluring Pisces (aka Sapphire Sleet or Midnight Neptune), that operationalize these techniques across their recent attributed supply chain campaigns, including those targeting Axios, Mastra AI and Rust's arrayref.
So what can be done about this? There are active defensive measures organizations can employ to combat this technique. See the section Considerations for Security Teams for additional information.
First, evaluate your organization's business domain to determine whether Web3 or blockchain network activity is ever expected. If your organization should never connect to a Web3 or blockchain network, this is an easy win.
Next, ensure you have endpoint protection and network security controls in place to properly monitor and block processes and their network traffic if they become compromised.
Finally, automate your policy controls across all CI/CD runners and version control systems in your environment.
Open-Source Supply Chains: The Cloud Initial Access Vector
Developer workstations and automated CI/CD runners represent a highly privileged attack surface holding sensitive or administrative Identity Access Management (IAM) keys or tokens. Current supply chain malware prioritizes extracting these credentials whenever software dependencies are resolved.
Two recent, high-impact campaigns illustrate these cloud-focused initial access vectors with decentralized blockchain C2 methodology.
ChainDrop npm Worm
Traced to the Shai-Hulud family, ChainDrop infected over 400 npm packages (including keyv and cacheable-request). The worm executes a preinstall script hook that downloads a custom Bun runtime to launch an obfuscated credential harvester.
In addition to searching static disk files, ChainDrop searches memory inside running build processes. It captures ephemeral cloud provider identity and access management (IAM) keys, CI/CD pipeline worker tokens and short-lived OIDC federation keys. Then, the runner terminates.
Figure 1. Attack flow of the ChainDrop npm worm.
To maintain long-term communication without relying on static domains, ChainDrop uses EtherHiding to query smart contract transactions. The smart contract transactions contain dynamically encrypted information for exfiltration IP or domain endpoints. ChainDrop then injects persistent task hooks. This triggers automatic execution whenever a developer opens a project or starts an AI coding session, as shown below in Figure 1.
PolinRider Campaign
Expanding across developer ecosystems, the PolinRider campaign spans multiple package registries, including npm, Go modules and Packagist. Rather than relying strictly on standard package installation scripts, PolinRider conceals malicious loaders within repository configuration files, web resources and developer IDE workspace automation.
When a developer loads the workspace, the payload silently triggers in the background to exfiltrate developer credentials, cloud session tokens and environment secrets while establishing long-term persistence within enterprise build pipelines.
Across different variants within the campaign, loaders dynamically resolve C2 endpoints using Web3 mechanisms. Mechanisms range from multi-chain transaction queries across networks like TRON, Aptos and Binance Smart Chain (BSC) to zero-data address resolution techniques like NullReceiver.
Figure 2. PolinRider multi-registry attack flow and Web3 C2 resolution.
To maximize the reliability of C2 infrastructure, threat actors deploy multiple of these mechanisms in a hybrid architecture. This allows them to use zero-data transfers as a backup channel if primary remote procedure call (RPC) gateways or multi-chain lookups are blocked, as shown below in Figure 2.
Once extracted, these credentials may provide direct access to cloud management consoles and management APIs, bypassing multi-factor authentication (MFA) if other controls are not in place.
The Architectural Evolution of Web3 Command and Control
Supply chain compromises face a distinct operational hurdle. Once a backdoored package is published to a public registry, automated security scanners, registry auditors and static analysis tools immediately inspect the code for hard-coded C2 domains or IP addresses. Hard coding infrastructure leads to swift domain takedown, IP blocklisting and package removal.
Threat actors can use the Web3 mechanics discussed above to maintain their initial access footholds across developer endpoints and enterprise build pipelines. They can do so by pointing their C2 infrastructure to blockchain networks and, more specifically, to smart contract enabled transactions.
By routing C2 resolution through Web3 networks, campaigns like ChainDrop and DPRK-affiliated PolinRider operations ensure their infrastructure survives Web 2.0-style network monitoring. These techniques have evolved through three distinct architectural phases, moving from observable smart contract storage to completely zero-data transaction decoding.
Phase 1: EtherHiding
Popularized under the EtherHiding taxonomy and reported in late 2024 supply chain campaigns targeting npm packages, early Web3 C2 implementations relied on deploying a hardcoded smart contract address on public blockchains. Malware loaders such as those deployed by the ChainDrop npm worm issued read-only JSON-RPC calls (eth_call) to retrieve C2 domains stored within smart contract state variables. Although this bypassed traditional Web 2.0 DNS sinkholing, embedding a fixed contract address introduced a static single point of failure. Outbound JSON-RPC request payloads explicitly expose the target contract address ("to": "0x..."). Security controls could flag and block all RPC queries directed to that specific contract.
Phase 2: Cross-Chain Transaction Data Hiding (TxDataHiding)
To overcome the single-point-of-failure inherent to hard-coded state contracts, threat actors shifted from contract state storage to the transaction input data layer (calldata). Popularized under the TxDataHiding taxonomy and deployed across campaigns like PolinRider, this phase decouples C2 resolution from permanent smart contract getters.
Instead of invoking state variables, operators embed encrypted C2 payloads directly into the raw input data fields (0x...) of standard blockchain transactions. The payloads are often sent to dynamic router contracts or designated burn addresses.
The malware loader reads transaction history logs (eth_getTransactionByHash, or calldata parsing) to extract and decrypt the active payload in memory. In PolinRider, variants implement multi-tier fallback routes across networks like TRON, Aptos and Binance Smart Chain (BSC).
If one chain or router is flagged, the actor broadcasts a fresh transaction on another network, updating global C2 endpoints instantly without modifying a single line of state code.
Identified in supply chain compromises targeting front-end dependencies (bianira-ui, fluid-type-ui), NullReceiver achieves total data minimization by eliminating smart contracts, input data fields and executable payloads. The loader queries an actor-controlled wallet for its latest zero-value transaction. It mathematically extracts the active C2 IPv4 address directly from the 20-byte recipient address structure itself. Figure 3 demonstrates this below.
Because the transaction carries zero value and zero data, no code structure or domain string exists for security filters to inspect.
DPRK State-Sponsored Operational Expansion
Cybercriminal groups deploy supply chain worms for opportunistic theft. On the other hand, North Korean state-sponsored threat actors use open-source software registries as a primary initial access vector targeting corporate environments.
This strategic shift is reflected across the cloud sector. Recent findings from Amazon Threat Intelligence highlight how North Korean threat groups systematically target open-source dependencies to penetrate enterprise infrastructure.
Threat actors demonstrate how compromising a single maintainer account or registry scope converts open-source dependencies, resulting in widespread affected cloud environments.
Telemetry across these intrusions indicates that an affiliated DPRK threat actor maintained a shared infrastructure footprint.
Axios Compromise: The threat actor compromised the lead maintainer of axios, injecting a backdoored dependency (plain-crypto-js) into the package manifest. The payload executed inside enterprise build pipelines to exfiltrate cloud tokens and target macOS code-signing certificates.
Mastra AI Campaign: Targeting AI development workflows, the threat actor published poisoned npm packages that used build execution hooks to scrape developer environment variables and cloud keys.
Rust arrayref: Expanding into Rust, the actor poisoned the arrayref crate on crates.io, using Rust's native compilation hook to execute a second-stage payload upon project builds.
Matching C2 beacon behaviors, SSL configurations, and clustered virtual private server (VPS) hosting ranges link all three operations, demonstrating how the actor leverages supply chain poisoning as a scalable initial access mechanism designed to yield long-lived cloud administrative access.
Considerations for Security Teams
As threat actors adapt to security controls and evolve beyond zero-data transfers, decentralized C2 techniques will increasingly leverage emergent primitives that blend malicious lookups directly into routine enterprise traffic. When attackers can silently infiltrate developer workstations and build runners to gain their initial foothold, static Indicator of Compromise (IoC) blocklists and traditional perimeter defenses are no longer sufficient to protect cloud infrastructure.
Defending against this threat landscape requires moving from reactive IoC matching to proactive behavioral visibility. Organizations can effectively neutralize these techniques by deploying three core defense capabilities:
Context-Aware and AI-Driven Behavioral Analytics
First, evaluate your organization's business domain to determine whether Web3 or blockchain network activity is ever expected within your environment. For typical enterprise organizations without Web3 operations, any outbound blockchain interaction represents an immediate, high-confidence anomaly. Integrating AI-driven behavioral analytics enables security teams to correlate network telemetry, baseline normal developer traffic and determine whether subtle on-chain evasion techniques are actively being witnessed in the environment.
Process-Contextual Endpoint and Network Inspection
Configure endpoint protection and network security controls to perform deep process-level inspection across developer workstations and CI/CD runners. Security policies should monitor standard enterprise runtimes, scripting engines and compiler binaries. This raises immediate alerts when non-crypto development tools initiate unexpected outbound queries toward public blockchain gateways.
Build Pipeline Integrity
Because modern supply chain payloads conceal loaders within build tools and workspace automation settings, security teams must expand code auditing beyond standard application binaries. Implement automated policy controls across CI/CD runners and version control systems to flag unauthorized modifications to repository configuration files, hidden script injections in package manifests, and unverified package lifecycle hooks before code is executed in build pipelines.
We discovered that an Iranian state-aligned threat actor has been masquerading as the Dubai Airports IT department to deliver trojanized coding challenges to high-value targets. Unit 42 tracks the activity as CL-STA-1178. This activity includes a campaign we call “Blinder Tunnel,” that targeted Iraqi critical infrastructure in March 2026, following infrastructure staging that was observed as early as November 2025. We named the campaign Blinder Tunnel after infrastructure terms the attackers used, as well as the malware’s tunneling capabilities.
While other security vendors have discussed individual attacks linked to this activity, this is the first report that not only ties together these disparate attacks as related activity, but tracks the evolving 2026 activity and the Blinder Tunnel campaign as a whole. We assess with high confidence that this activity aligns with an Iranian-nexus threat.
This campaign expands on previous operations and incorporates a “Peaky Blinders” theme by naming infrastructure components after the British crime drama’s branding — even embedding its theme song into the malware.
During our research, we discovered that the attackers established an initial foothold using a three-step attack chain:
Exploited legitimate Windows developer .csproj files
Performed AppDomainManager hijacking
Executed binaries through DLL sideloading
These steps enabled the attackers to deploy custom malware that we refer to as ShelbyLoader V2. To blend in with legitimate cloud traffic, the campaign misused GitHub’s API infrastructure for command-and-control (C2) communication. It did so by leveraging repositories to:
Fetch decryption keys
Download payloads
Use GitHub issues as a resilient C2 fallback mechanism
GitHub has taken down the malicious infrastructure that we identified as being associated with this campaign.
Our investigation benefited from various operational security (OpSec) and cryptographic missteps by the attackers, including:
Exposing tools on public repositories
Combining phishing and tunneling infrastructure
Embedding metadata within the show’s theme song
These tactical errors linked Blinder Tunnel infrastructure to a separate campaign in which the same actor leveraged conflict-themed Google Drive lures for credential harvesting against an Israeli entity in May-June 2026.
Palo Alto Networks customers are better protected from the Blinder Tunnel campaign through the following products and services:
CL-STA-1178 represents activity from an Iranian state-aligned threat actor linked to a series of targeted cyber operations across the Middle East. Previously associated with campaigns tracked by Elastic Security Labs as The Shelby Strategy, the threat actor behind this cluster of activity frequently employs thematic branding in their malware and infrastructure, drawing inspiration from the popular television show “Peaky Blinders.”
The attackers behind this cluster target high-value infrastructure, including telecommunications, aviation and other critical entities across Iraq, Israel and the United Arab Emirates (UAE).
Since the launch of Blinder Tunnel in March 2026, Unit 42 researchers have identified an evolution in the operational capabilities associated with the activity. The attackers used tailored social engineering tactics, weaponizing recruitment lures aimed at Iraqi software developers and engineers.
We observed the threat actor staging and testing attack infrastructure as early as November 2025. This infrastructure remained dormant but operational until March 2026, when the attackers activated the campaign to target an individual in Iraq's critical infrastructure sector.
The infection chain relies on three initial execution techniques to establish covert access. The attacks introduced a new layer of evasion by weaponizing a native .csproj file, a Microsoft developer file used to build software projects. This initial stage subsequently triggered AppDomainManager hijacking, followed by DLL sideloading, leveraging their previously established execution techniques.
AppDomainManager hijacking is an emerging evasion technique that attackers are increasingly adopting, according to our recent research. Iranian threat groups like Screening Serpens and others are using this technique to force trusted Windows applications to covertly execute malicious payloads.
For C2 communication, the attackers behind Blinder Tunnel misuses legitimate GitHub API infrastructure, a strategy known as living off the cloud, to blend their malicious network activity with standard enterprise traffic. Before its removal, the GitHub repository also hosted an in-memory wrapper that executed the open-source Chisel tunneling utility. The attackers used Chisel as a bridge between their external infrastructure and compromised networks.
Figure 1 provides a high-level view of the entire campaign.
Figure 1. Overview of the Blinder Tunnel campaign.
Initial Access and Delivery
Dubai Airports Careers Portal
Starting in late March 2026, the threat actor launched a social engineering campaign disguised as a professional recruitment process to compromise a specific individual, likely a software engineer. We identified this campaign through VirusTotal, following multiple file submissions from a submitter based in Iraq.
Impersonating the Dubai Airports IT department, the attackers approached a target with a job offer for a development role. Threat actors often abuse, take advantage of or subvert legitimate products for malicious purposes. This does not imply that the legitimate product is flawed or malicious. Unit 42 is not aware of any breach, compromise, or vulnerability within Dubai Airports infrastructure or systems.
As a mandatory first stage in the recruitment process, attackers instructed the target to download and install a file named Dubai Airport Careers.
This file was an Inno Setup installer that deployed a self-contained, offline site masquerading as a career portal. To access the assessment, the target had to log in using credentials provided by the “recruiters,” simulating a realistic portal experience.
Figure 2 shows the initial login screen.
Figure 2. Impersonated Dubai Airports career portal login page.
After the target logged in, the application presented a tailored, 10-question HR questionnaire. Figure 2 shows part of this questionnaire.
Figure 3. Impersonated question and answer page mimicking an application for potential job candidates.
Submitting the questionnaire does not trigger data exfiltration, remote communication or malicious execution. This lack of network or backend activity indicates that the application is a harmless decoy. This lack of suspicious activity is designed to build credibility and lower the victim's guard before delivering a malicious payload in the next phase of the phishing operation.
Recruitment Coding Challenge
In April 2026, the same source that reported the career portal to VirusTotal made another submission, revealing the next stage of the recruitment lure. Unlike the usual malicious links or documents seen in a report by ClearSky Cyber Security about Iranian Dream Job campaigns, the threat actor sent the target a weaponized Microsoft Visual Studio project archive disguised as a coding assessment.
The project, named DubaiAirport_Carrers_IT_Test.zip (misspelled Carrers instead of Careers), contained a Readme.md file with personalized instructions. The message addressed the target directly:
“Dear <redacted full name>.”
The sender claimed to be a senior manager of a Dubai Airports IT department, instructing the recipient to open the C# Flight Management System project in their integrated development environment (IDE).
Figure 4 shows the first section of the Readme.md file, including the message tailored to the target and instructions for an at-home assessment.
Figure 4. The opening section of the Readme.md file.
Under the pretense of evaluating the target's technical abilities, the project included an intentional bug in a backend C# method: a for loop that skips the last element. Attackers instructed the target to build and run the project to find and fix the bug, a task that an experienced software engineer could accomplish without difficulty.
Three-Step Infection Chain
The initial infection is triggered by a malicious .csproj file. Once executed, the attack chain progressed to AppDomainManager hijacking followed by DLL sideloading.
Stage One: Malicious .csproj File
The attackers weaponized the C# project's .csproj configuration file by misusing Visual Studio's built-in evaluation process. This method caused the payload to execute the moment the project was loaded into the IDE, even before the developer attempted to compile the code.
Figure 5 shows the project files within the DubaiAirport_Carrers_IT_Test.zip archive, including the weaponized .csproj file.
Figure 5. The project's structure and files within the malicious archive.
When a developer opens a project, Visual Studio performs a design-time build in the background. This process resolves dependencies and enables various features. During this initialization phase, Visual Studio runs a specific command called GetFrameworkPaths. Building on this command, the attackers defined a custom XML target with this exact name in their malicious .csproj file, overriding the safe Microsoft default behavior.
When the target opened the project, Visual Studio attempted its routine background check and executed the attacker's custom instructions without user intervention. The script created a deceptive folder in the user's local app data: %LOCALAPPDATA%\Microsoft\RuntimeBrokers. It then copied the hidden malware binaries from the project's Resources folder to this directory and launched the payload, RuntimeBroker.exe.
Figure 6 demonstrates the exact configuration of the .csproj file, highlighting the hijacked target and the sequence that copied the malicious files to their target destination.
Figure 6. The .csproj file configuration, showing the malicious configuration used by the threat actor.
The malware deployed, copied itself and launched in the background while the developer was still reading the deceptive Readme.md file. This technique is classified as Trusted Developer Utilities Proxy Execution. It can be effective because the malicious background execution is triggered by the legitimate, expected behavior of msbuild.exe, a trusted developer tool.
Stage Two: AppDomainManager Hijacking
The MSBuild binary launched a legitimate, signed Microsoft Visual Studio hosting process (vshost.exe). This file was then renamed to RuntimeBroker.exe. Upon execution, the AppDomainManager hijacking began by manipulating the application's RuntimeBroker.exe.config file. The attackers used this configuration file to replace the application's default startup manager with their own malicious version. This forced the system to pass full execution control to the malware before the host application launched, allowing their custom RAT, ShelbyLoader V2, to run in a hidden, trusted process.
Using this hijack technique allowed the attackers to manipulate the system and security configurations. By adding just a few lines of XML, the attacker instructed the system to disable one of its security-tracking mechanisms using the <etwEnable enabled="false"/> directive.
Because Event Tracing for Windows (ETW) is critical for monitoring execution and detecting in-memory threats, this flag could impair detection capabilities.
Figure 7 shows the RuntimeBroker.exe.config configuration file content, with the embedded malicious lines.
Figure 7. RuntimeBroker.exe.config content.
Figure 8 displays the malicious files from the Resources folder, which served as the actor's main tool set throughout this campaign.
Figure 8. List of malicious files from the project's Resources folder.
Stage Three: DLL Sideloading
Following the execution of RuntimeBroker.exe and the subsequent AppDomainManager hijack, the attack sequence concluded with DLL sideloading as its final stage.
RuntimeBroker.exe, a renamed benign Microsoft binary, is susceptible to DLL search-order hijacking. The actor exploited this flaw to perform DLL sideloading, executing the malicious payload by loading RuntimeBroker.dll into memory.
Organizations can defend against these attacks by monitoring binaries that load unknown or non-standard DLLs outside of system directories. In this particular case, Cortex XDR flagged the root .slnx file that triggered the DLL sideloading attempt as a high-severity threat, preventing execution before any user interaction could occur, as Figure 9 shows.
Figure 9. The infection chain originating in malicious DLL sideloading (categorized as DLL Hijacking), as shown, detected and prevented by Cortex XDR.
Security teams can detect this masquerading activity by monitoring abnormal process behavior. Cortex XDR flagged this execution chain as high risk and blocked the threat, as Figure 10 shows.
Figure 10. The infection chain as seen, detected and prevented by Cortex XDR.
The Attackers’ Evolving Tool Set
The attacker’s tool set relied on a modular, multi-stage architecture. This architecture was designed for persistence, remote command execution and lateral movement across compromised environments. The following analysis examines the core components of the attacker’s custom tool set:
ShelbyLoader V2: Primary loader that uses GitHub issues as a C2 fallback
All the .NET binaries recovered in this campaign were obscured with the open-source obfuscator Obfuscar. This tool hinders reverse engineering and automated static analysis, using runtime string decryption and non-printable Unicode characters for class and method identifiers.
The malware was a C# DLL that performed the following activities:
Operated as a loader
Created persistence
Fingerprinted the infected host
Established communication with the C2
The malware served as the initial entry point for launching the campaign. It executed a structured routine to perform initial host anti-analysis checks and establish communication before downloading and decrypting a second-stage payload.
The malware utilized two timed mechanisms to manage its operations:
Persistence (120-second interval): The malware achieved persistence through the registry, by creating a MicrosoftRuntime value under the current user startup registry key, pointing to the binary located at %LOCALAPPDATA%\Microsoft\RuntimeBrokers\RuntimeBroker.exe. The loader logged this persistence status across four operational states and returned the results to the attackers' C2:
Already persisted
Newly persisted
Registry key not found
Executable not found
Beacon (63-second interval): This timer drove the primary C2 loop. The beacon routine attempted to authenticate to the GitHub API using a hard-coded GitHub Personal Access Token (PAT): github_pat_11B2HDA2Q0KDdo…(redacted)
The beacon cycle began by communicating with the peakyblinders-tm/myLic GitHub repository and uploading a Base64-encoded machine fingerprint to /{machineId}/Lic.txt. The machineId is derived by taking the first 16 lowercase hex characters of a SHA-256 hash of the string Peaky Blinders 2.1 concatenated with the machine fingerprint.
After successful registration, the malware continuously polled for tasking by downloading the content of /{machineId}/Inf.txt. The malware parsed the response for a Base64-encoded command, which it decoded and executed. Once processed, the beacon uploaded an acknowledgment containing the SHA-256 file to update and clear the repository file. If the GitHub API returned an HTTP 403 (Forbidden) error due to rate limits, the malware enforced a one-hour sleep loop.
To hinder analysis, the malware checked for virtualization markers in the following locations:
Windows Management Instrumentation (WMI)
Running processes
Registry keys
File artifacts
It also verified host hardware (CPU, RAM, disk space) and ensured it was spawned by explorer.exe before running.
GitHub Issues as a C2 Fallback Mechanism
If the hard-coded token was revoked or the primary C2 channel returned an HTTP 401 Unauthorized error, the malware activated a fallback mechanism: a dead-drop resolver that leveraged the GitHub Issues Search API.
The malware constructed an automated search query using the current date formatted as yyyymmdd, combined with the repository identifier and an issue type filter. For every matching issue found, it fetched the comments URL and parsed the response body. It then extracted specific content that was hidden inside standard HTML comment markers: <!-- and -->.
This extracted ciphertext was decrypted using AES-256-CBC. The decryption key was derived by running an MD5 hash of the current date string, concatenated with the unique machineId and an initialization vector (IV) derived from the MD5 of that key, iterated five times. Once decrypted, the malware applied regular expressions to update the C2 owner, repository path and authentication token:
Owner=(\w.+)
LicRepo=(\w.+)
LicToken=(\w.+)
This fallback structure was built to allow for continuous operations in the event that GitHub took down the primary C2 repository or security tools blocked it.
The operators also planted encrypted fallback C2 data within the comments of benign GitHub issues. The underlying text cannot be decrypted without a target's unique machineId. However, the campaign's overall timeline suggests that an issue comment posted on April 16, 2026, served as a potential additional C2 of this implant, as Figure 11 shows.
Figure 11. A comment left by the attacker on April 16, 2026.
PsProxy.dll: The PowerShell Proxy Module
To execute local commands, the attackers used a dedicated in-memory module, PsProxy.dll, which served as a stateless execution engine with no standalone network or persistence capabilities.
The malware leveraged a technique described by MITRE as executing PowerShell commands without invoking the PowerShell.exe binary. Security tools generally hunt for malicious activity by monitoring the PowerShell.exe process. To evade this detection, PsProxy.dll bypassed the standard console and hooked into the core PowerShell engine (System.Management.Automation.dll).
The malware then initialized a customized runspace — an invisible, self-contained execution context — within the hijacked host process. This allowed the attacker's script to execute without spawning PowerShell.exe.
The malware authors designed this architecture for both stealth and stability. The PowerShell module ran without dropping malicious scripts to the disk or spawning suspicious processes. It also operated in a separate memory compartment, preventing a crashed script from disrupting the primary C2 connection. When a command arrived from the server, the main payload passed the raw script over to this proxy for execution.
Figure 12 illustrates the role of PsProxy.dll within the attack chain as a secondary execution module for the ShelbyC2 V2 RAT.
Figure 12. PowerShell module functionality.
ShelbyC2 V2 RuntimeBrokerApi.dll: Loading the Final Payload
Once the malware established stable communication with the GitHub-hosted C2, the RuntimeBroker.dll loader read an AES-CBC-encrypted file named RuntimeBrokerApi.dll from its base directory. We named this main RAT ShelbyC2 V2, based on the name of its last reported iteration, ShelbyC2.
The decryption key was generated using the full SHA-256 hash of a license content string fetched at runtime from the GitHub C2:
The IV was set to the first 16 bytes of that same hash. The decrypted bytes were then loaded into memory as a raw .NET assembly.
ShelbyC2 V2 (RuntimeBrokerApi.dll) operated as the primary RAT. It managed command execution via the previously analyzed PsProxy.dll PowerShell module and served as the staging mechanism for deploying the Blackwood tunneling tool into the network, which we analyze in detail in the following section.
Blackwood: A Custom, Zero-Disk Chisel Tunneling Tool
On May 1, 2026, the attackers expanded their GitHub-centric infrastructure by creating a new public repository named pubs under the peakyblinders-tm account. This repository hosted a single archive file: Client.zip. Our analysis of this payload revealed a malicious executable internally named Blackwood, which was previously covered by CPX and submitted to VirusTotal in May 2025.
Figure 13 shows the GitHub repository pubs, containing the Client.zip file.
Figure 13. GitHub pubs repository containing the Client.zip file.
Figure 14 shows the extracted archive content, where the malicious file is named Blackwood.dll.
Figure 14. Extracted Client.zip archive content.
To deploy Blackwood, the attackers relied on the same execution playbook observed with the primary loader, ShelbyLoader V2: AppDomainManager hijacking and DLL sideloading. Inside the extracted archive, the attackers stored:
The malicious payload
A legitimate Microsoft-signed binary, vshost32.exe
A configuration file named vshost32.exe.config
When the trusted vshost32.exe executable was launched, the .NET runtime parsed the configuration file and sideloaded Blackwood.dll into the application's memory.
Blackwood.dll acted as a loader for the open-source Chisel tunneling tool. Once deployed, it enabled the attackers to establish encrypted TCP tunnels over HTTP with SOCKS5 proxy support to bypass perimeter defenses and enable lateral pivoting across compromised networks. To hide the tunneling payload from analysis, the core binary was embedded within the .NET loader as an 8.4 MB manifest resource named Blackwood.Cheese.xml. This payload was also encrypted with AES-256-CBC.
During execution, the malware derived the decryption key by computing the SHA-256 hash of a hard-coded ASCII passphrase (y0Da+QH#pwSg38E?=8R;71-jQu8Tqq). After Blackwood.dll decrypted the embedded XML resource, it revealed the actual Chisel payload — a Go-compiled DLL. The Blackwood.dll loader then reflectively loaded this Chisel DLL into memory and executed it.
The Chisel tool read its operational settings from the external configuration file Blackwood.dll.conf, which was dropped alongside the executable. The loader employed a conditional evasion scheme:
If the loader binary had a DLL extension, the loader treated the configuration file as Base64-encoded text and decrypted the file via the RC4 algorithm using the hard-coded key “My name is Blackwood !”
If the extension had been changed, the loader would have read the file in plaintext, resulting in a decryption failure.
Figure 15 displays the successful decryption using the hard-coded key, yielding a Chisel configuration.
Figure 15. A successful decryption of the Blackwood configuration using the hard-coded key.
The discovered IP address, 91.107.156[.]29, functioned as a dedicated tunneling endpoint. The configuration instructed the infected machine to connect to this server and establish a reverse SOCKS proxy (R:0.0.0.0:10999:socks), creating a bridge that could allow attackers to route traffic to the target's internal network.
Initial Tool Set Testing
Throughout the campaign, the attackers performed operational testing to validate and improve their infrastructure and malware functions. The attackers confirmed dead-drop C2 resolution through GitHub comments in November 2025 and simulated Iraqi connections on a mock GitHub issue dashboard in April 2026. We also observed that the attackers tested additional infrastructure on a staging server for a phishing campaign targeting an Israeli entity in May 2026.
A comprehensive analysis of these operational testing phases is provided in Appendix A.
Additional Credential Harvesting Campaign
Analysis of Blackwood tunneling configurations submitted to VirusTotal revealed additional attacker infrastructure active between May and June 2026. One of the servers showed that the attackers reused the same infrastructure for both internal network access and credential harvesting. Our research linked this server to a phishing campaign in May–June 2026 targeting an Israeli entity, using conflict-themed lures.
A detailed breakdown of this additional campaign is available in Appendix B.
Attribution to the Iranian Nexus
Despite utilizing cloud infrastructure and code obfuscation to hide their operations, the actors behind the Blinder Tunnel campaign left behind several forensic artifacts. Based on infrastructure ownership, embedded metadata, targeted victimology and overlaps in tradecraft, we assess that an Iranian state-aligned threat actor conducted this campaign.
The key findings that led us to this attribution include:
Iranian-hosted infrastructure: The initial Blackwood C2 IP address belongs to an Iranian ISP: TOSE'EH ERTEBATAT NOVIN ARIA. A secondary Hetzner tunneling server resolves to Persian-language domains that the attackers likely acquired via an Iranian reseller.
MP3 file metadata: An .mp3 file hosted in the attackers' public GitHub repository retained metadata pointing to MusicDel[.]ir, a popular Iranian music platform.
Regional geopolitical victimology: The campaign's targeting profile aligns with previously documented regional espionage activity and historical targeting patterns associated with this activity cluster.
Convergence with Iranian espionage playbooks: The campaign employed established Iranian tactics, techniques and procedures (TTPs), which shows low confidence overlaps between CL-STA-1178 and established Iranian groups. Among the TTPs are:
Using aviation-targeted lures
AppDomainManager hijacking to disable ETW (resembling Screening Serpens)
Using GitHub dead-drop resolvers
Using in-memory .NET PowerShell wrappers (resembling Agent Serpens)
A detailed technical breakdown of the attribution artifacts is available in Appendix C.
Conclusion
The activity tracked as CL-STA-1178 represents targeted operations against Middle Eastern enterprise networks in the newly uncovered campaign Blinder Tunnel.
The attackers behind the activity used tailored social engineering techniques to masquerade as Dubai Airports recruiters, using a trojanized Visual Studio coding challenge to target a high-value job seeker based in Iraq.
The campaign is characterized by misuse of built-in developer tools and DLL sideloading. Attackers also used AppDomainManager hijacking to bypass security monitors like ETW. These evasion techniques enabled the attackers to deploy:
The primary loader, ShelbyLoader V2
The custom RAT payload, ShelbyC2 V2
The custom Blackwood tunneling tool
The Blinder Tunnel campaign relied on living-off-the-cloud techniques. By misusing GitHub APIs and reading encrypted comments within GitHub issues to rotate C2 servers, the attackers disguised the malware’s command traffic as legitimate enterprise platform activity.
We assess with high confidence that this activity cluster aligns with the work of an Iranian-nexus threat actor. The attacker using infrastructure themed around the TV show “Peaky Blinders” links this activity to the campaign previously documented in Elastic Security’s “The Shelby Strategy” report. Furthermore, OpSec failures and flawed cryptography uncovered a parallel campaign targeting an Israeli entity, revealing a broader operational footprint. The campaign's tool set and geographical targeting align with established regional threat activity and historical tradecraft.
This operation underscores the need for organizations to secure developer environments, monitor anomalous cloud platform traffic and maintain vigilance against industry-specific social engineering lures.
Palo Alto Networks Protection and Mitigation
Cortex AgentiX Agentic Assistant streamlined this investigation by allowing the team to query the data using natural language, providing deeper context and insights, and suggesting clear recommendations on what researchers should do next. Figures 16 and 17 show examples of this.
Figure 16. Breakdown of attack chain and actions taken, as shown in Cortex AgentiX.Figure 17. Immediate and short-term remediation steps, suggested by Cortex AgentiX.
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 to identify and automatically block the recruitment lures, malicious build steps, and payloads associated with this campaign.
Advanced URL Filtering and Advanced DNS Security identify and block known malicious domains and URLs associated with this activity, specifically stopping the GitHub C2 traffic, Chisel tunneling attempts, and credential-harvesting phishing infrastructure associated with this threat cluster.
Cortex XDR and XSIAM are designed to prevent the execution of known malicious malware and prevent the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module.
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.
Appendix A: The Attackers’ Initial Testing of Their Tool Set
According to our observations, the attackers conducted multiple operational tests throughout the campaign to validate and refine their own tools.
First Observed GitHub Comment
On Nov. 18, 2025, it appears that the threat actor performed operational tests to validate their C2 mechanisms, using a public GitHub repository to test their dead-drop resolution capabilities. By embedding an encrypted payload block inside a comment, the malware developers could verify that their malware located and retrieved fallback C2 instructions.
This early activity suggests a prolonged preparation period, indicating that this campaign could have started in November 2025. Figure 17 shows the comment left by the threat actor.
Figure 18. A GitHub comment indicating campaign preparation began by November 2025.
Analysis of the “asasas” GitHub Thread
On April 24, 2026, the operators used a GitHub issue in their peakyblinders-tm repository as an operational logging dashboard. The issue's asasas title and an initial hisasas comment suggest that the attackers created this thread as a preliminary trial run. These strings indicate adjacent QWERTY key smashing, typical of a quick confidence check to verify permissions before logging real telemetry.
The thread contained a series of additional comments that appeared to be automated alerts posted by the repository owner. These alerts flagged events such as New device Found and Login detected. The thread also contained system attributes such as #microsoft to denote the host operating system.
One of the log entries records a connection from the IP address 138.256.21[.]23 alongside the country code for Iraq, IQ. Since .256 exceeds the maximum IPv4 octet value of 255, we assess that attackers used a fabricated, non-routable IP address during an operational test to avoid triggering real network traffic. Despite the invalid IP address, the explicit inclusion of the IQ country code suggests a connection to the campaign's geographic targeting focus in the Middle East.
Figure 18 shows the GitHub issue thread, displaying a sequence of comments from the repository owner that combine what appear to be test strings, mock connection data and automated alerts.
Figure 19. GitHub issue “asasas” and comments thread.
The server 65.109.214[.]145 was identified through a Blackwood malware sample submitted to VirusTotal on May 24, 2026. Analysis indicates that this IP address was central to a credential-harvesting campaign between May and June 2026, hosting phishing domains as well as the backend Blackwood.dll component, configured on port 8080.
The server hosted a targeted infrastructure consisting of several Google-themed typosquatted domains. These included:
cloud.g-drive[.]cam
googeldrive[.]cam, drivegoogel[.]cam
googelmeet[.]online
meetonline[.]cam
On May 16, 2026, a VirusTotal submitter from Israel submitted a phishing URL hosted on this IP address: hxxps[:]//cloud.g-drive[.]cam/drive/file/d/[generated id]/view
The underlying landing page was designed to look like a Google Drive error page displaying a prompt to download an archive file named WarUnPublishedDocuments.zip.
Clicking the download button shown in Figure 19 directed the target to a site impersonating a Google login portal to collect user credentials at hxxps[:]//cloud.g-drive[.]cam/signin/v2/identifier?from=landing.
Figure 20. A window impersonating Google Drive to lure the target to download a ZIP file named WarUnPublishedDocuments.zip.
We reported this information to Google, who investigated the activity outlined in this report. They confirmed that Google Drive systems and infrastructure were not compromised or involved in any way in the attacks.
The threat actors utilized external lookalike domains designed to impersonate Google Drive and Google Workspace interfaces for credential harvesting. Google Safe Browsing and Chrome protections actively block access to these identified malicious domains.
Google noted that they encourage organizations to enforce phishing-resistant multi-factor authentication (such as passkeys) and advise users to verify destination URLs before entering account credentials.
Further infrastructure tracking revealed the threat actor’s earlier staging environment. By pivoting on domains hosted on the primary 65.109.214[.]145 server, we discovered the domain asdfafadafg[.]online. This domain resolved to a secondary IP address, 38.180.136[.]127.
Timeline analysis indicates that the operators used this server to test their phishing infrastructure during early May 2026, before migrating their operations to the primary 65.109.214[.]145 server.
Appendix C: Attribution to the Iranian Nexus
Despite the attackers’ use of code obfuscation to hide their tracks, we discovered infrastructure overlaps and operational mistakes that revealed key attribution artifacts. An Iranian IP address, embedded music metadata and the targeted activity against critical infrastructure in the Middle East point to an Iranian state-sponsored espionage operation. We summarize each forensic artifact and share how it aligns with our attribution process.
Infrastructure
Our investigation into the Blackwood malware samples revealed four IP addresses used in the activity cluster. Two of the identified IP addresses provided clues to the operator’s country of origin.
87.248.129[.]239
This server was identified through an initial Blackwood malware sample submitted to VirusTotal on May 25, 2025, prior to the current campaign. This is an Iranian IP address, hosted by the internet service provider TOSE'EH ERTEBATAT NOVIN ARIA CO PJS. Active between April and June 2025, this server was the first to be linked to the Blackwood malware.
91.107.156[.]29
Extracted from the embedded configuration file inside the Blackwood malware sample, the IP address 91.107.156[.]29 functions as a tunneling relay. Although this server is hosted on Hetzner's infrastructure in Germany, passive DNS telemetry links it to an external domain layout. Historical DNS records reveal subdomains pointing to ns1.soroshpasargad[.]com and to the 3ff7dfc547e8697c registrar. In Persian, Sorosh means messenger or angel. Pasargad refers to the ancient capital of the first Persian Empire. Based on the aforementioned Persian domain and other Persian domains under the same registrar, we suspect that the current server listed under Hetzner could have been acquired from an Iranian reseller.
Tool Set
An OpSec oversight on the attackers' public GitHub profile provided an indicator of the operators' regional origin. The threat actor maintained a public repository under the organization profile peakyblinders-tm. The repository's README file included an embedded audio file titled Peaky Blinders Team.mp3, featuring the television show's theme song, “Red Right Hand.”
Figure 20 shows the Readme.md file from the attacker's public GitHub repository.
Figure 21. The Readme.md file from the attacker's public GitHub repository features the “Peaky Blinders” theme song.
An analysis of the audio file's embedded metadata revealed that the operators did not strip the file's original attributes before uploading it to their public project page. As shown in the metadata breakdown in Figure 21, the COMMENT field explicitly retains the value MusicDel[.]ir.
Figure 22. Metadata of the audio file.
MusicDel[.]ir is an active, public Iranian music distribution website used primarily for downloading tracks in Iran. The presence of this specific metadata string indicates that the operators downloaded the audio file from a domestic Iranian platform before uploading it to their GitHub infrastructure.
Victimology
The targeting profile corresponds with victimology previously observed across other Iranian APT campaigns. The targets were all in the Middle East, specifically within the telecommunications and aviation sectors:
Iraq: In their research on “The Shelby Strategy,” Elastic Security Labs documented that the threat actor executed spear phishing campaigns from within a compromised Iraqi telecommunications infrastructure. According to their findings, this activity targeted two separate Iraqi communications companies. The activity’s geographic focus was the same in the campaign we investigated. This is corroborated by recent technical artifacts, as multiple campaign-related payloads — including the job assignment archive — were submitted to VirusTotal from Iraq. Additionally, the operators used the country code IQ (Iraq) in their mock connection logs during their GitHub operational testing. Based on the established operational profile and technical evidence linking this activity to the region, we assess that the individual targeted in Blinder Tunnel matches the profile of a software engineer based in Iraq.
United Arab Emirates (UAE): The initial lure mimicked the Dubai Airports IT Department. In another aviation-themed operation, Elastic Security Labs identified related infrastructure targeting the UAE aviation sector, including the malicious subdomain portal.sharjahairport[.]cloud.
Israel: The activity also targeted an Israeli entity using conflict-themed social engineering lures. A suspicious URL was submitted to VirusTotal via the web interface from an IP address in Israel. The URL redirected to a phishing page that served an archive named WarUnPublishedDocuments.zip, which in turn led to a site impersonating a Google login portal.
The “Peaky Blinders” Theme
Throughout past and present campaigns (2025-2026), the threat actor behind this activity consistently used a “Peaky Blinders” theme in naming their malware architecture and GitHub-based C2 repositories. This is evident in the following:
GitHub accounts named after the show’s name and main characters:
peakyblinders-tm
ArthurShelby
JohnShelllby
A repository referencing the gang's clothing: GreenBeret0
The presence of the show’s theme song in the repo's README file
These indicators served as a unique fingerprint that aided in attribution.
Similarities to Other Known APTs
Public threat intelligence tracks the Blinder Tunnel campaign as disparate activities independent of any known group. Unit 42 tracks this activity as a cluster, specifically using the CL-STA-1178 moniker. The tradecraft used in the Blinder Tunnel campaign shows low-confidence overlaps with established Iranian groups, none of which are strong enough to attribute CL-STA-1178 to any of these groups specifically. However, we do attribute the activity with high confidence to Iranian state-aligned attackers.
Screening Serpens
As detailed in a recent Unit 42 report, the Screening Serpens (aka UNC1549, Smoke Sandstorm, Iranian Dream Job) group targets technology, aerospace and defense professionals in the Middle East using highly tailored social engineering lures. The group has used personalized recruitment offers designed to trick targets into initiating the infection chain.
Another evolution highlighted in our research is the use of .NET AppDomainManager hijacking, manipulating legitimate configuration files to disable endpoint security mechanisms before the malware executes.
The Blinder Tunnel campaign employs both tactics. The Dubai Airport Coding Challenge deployment aligns with Screening Serpens' pattern of fraudulent hiring lures targeting the aviation sector.
Manipulation of the RuntimeBroker.exe.config file to execute AppDomainManager hijacking, to disable ETW (<etwEnable enabled="false"/>), was used by Screening Serpens throughout 2026.
Agent Serpens
When analyzing the Iranian state-sponsored activity tracked as Agent Serpens (aka APT35, Charming Kitten, Phosphorus), we noticed additional similarities in its operational playbook.
An overlap between this Blinder Tunnel campaign and Agent Serpens activity is the misuse of trusted developer platforms to maintain resilient C2 infrastructure. If communication channels fail, both campaigns rely on GitHub as a fallback dead-drop resolver.
As described in this research, the ShelbyLoader V2 backdoor queries the GitHub Issues Search API to extract AES-encrypted routing data hidden within HTML comments. Similarly, Drokbk malware uses the GitHub API to parse a specific repository file to locate and re-establish its C2 connection.
Furthermore, Cybereason's analysis of the Iranian threat group highlights a similar PowerShell execution technique. Just as Blinder Tunnel operations rely on memory-only wrappers, Agent Serpens deploys the PowerLess Trojan to execute PowerShell commands within a native .NET context. In both cases, the techniques used prevented the creation of a suspicious PowerShell.exe process that could trigger event detection alerts.
Unit 42 is aware of possible zero-day activity against NetScaler devices. In a Citrix report that details several CVEs, they noted that CVE-2026-88771 and CVE-2026-88772 have been exploited in the wild. The threat actors exploited these vulnerabilities to deliver web shells and establish their initial access and persistence into organizations. Analysis is ongoing to determine any post-compromise activity.
As of Sept. 27, 2026, Palo Alto Networks Cortex Xpanse has identified 50,277 exposed instances that could potentially be vulnerable to these CVEs based on our telemetry.
It is important to note that activity after Sept. 27, 2026 might not match the same indicators of compromise (IoCs) or tactics, techniques and procedures (TTPs) from the original zero-day activity. We group pre-disclosure and post-disclosure activities to differentiate what we believe the original actors were doing with the exploit from what additional actors, security researchers and internet scanning tools are doing now that the vulnerabilities are public.
The vulnerabilities are:
CVE-2026-88771: A remote code execution (RCE) vulnerability that fails to properly validate input and allows an unauthenticated actor to run commands against NetScaler Application Delivery Controller (ADC) and NetScaler Gateway systems
CVE-2026-88772: A memory overflow vulnerability that can lead to a remote code execution (RCE) or denial of service (DoS) on the Datagram Transport Layer Security (DTLS) configuration on NetScaler ADC and NetScaler Gateway systems
Both vulnerabilities have a CVSS v4.0 base score of 9.5.
Palo Alto Networks customers are better protected from this activity through our products and services, such as:
This section is our analysis of threat activity that occurred prior to the public disclosure of these zero-day vulnerabilities. We saw two groups of web shell activity:
Datagram Transport Layer Security (DTLS) exploitation dropping .deb web shell files
A three-stage command injection exploit chain that drops PHP web shells
The earliest activity we identified occurred on Aug. 21, 2026, from two hosts, one at 104.248.244[.]66 and one at 77.83.199[.]39. First, 104.248.244[.]66 requested /admin_ui/common/css/ns/ui.css from a NetScaler Gateway appliance at a US-based organization.
Approximately two hours later, the host at 77.83.199[.]39 requested the same file, /admin_ui/common/css/ns/ui.css. Nearly two hours after that second request, 77.83.199[.]39 requested /vpn/js/rdx/core/lang/rdx_en.json.gz. These requests are consistent with version fingerprinting.
On August 21 and 22, these two hosts and 78.47.24[.]217 sent the same requests to more than 100 other systems.
CVE-2026-88772: DTLS Exploitation To .deb Webshell Activity
In this exploit chain, the attacker sends crafted DTLS traffic to a vulnerable NetScaler device, which processes the malicious packet. This malicious packet causes memory corruption or a crash that can lead to either code execution or denial of service.
Between September 4 and 24, the threat actor repeatedly requested files from the appliance's /vpn/scripts/linux/ folder. This folder normally hosts Citrix client installation packages. The threat actor also used this folder to host their web shells.
The threat actor rotated its infrastructure over this period:
September 4–8: Four virtual private servers (VPSs), one per day, requested nsgclient18.deb and nsgser18.deb. These hosts were 66.135.19[.]18, 167.99.111[.]203, 142.93.85[.]227 and 104.248.74[.]206.
September 7: 137.184.91[.]207 requested the same files.
September 9–11: Three Cloudflare WARP VPN addresses requested nsgclient18.deb, nsgsupport.deb and nsgpackage64.deb. These addresses were 104.28.247[.]136, 104.28.215[.]136 and 104.28.215[.]137.
September 14:162.33.178[.]9 requested nsgbuild.deb and nsgsupport.deb.
September 15–24:193.149.176[.]207 requested nsgbuild.deb every day. This server accounts for most of the requests we observed
From September 10–27, the WARP addresses (plus two additional IP addresses, 104.28.247[.]137 and 193.149.176[.]207) sent a continuous stream of requests to the appliance's /logon/LogonPoint/Authentication/GetUserName page. We believe any activity to this URL path is anomalous and worth investigating.
The requests continued around the clock, including on days without web shell activity. They also continued for two and a half days after the last web shell request on September 24.
The last request arrived at 01:54 UTC on September 27, hours before Citrix published its security bulletin.
.deb Web Shell Analysis
We recovered and analyzed .deb files used in this activity. We analyzed nsg64.deb (ae22ef2517b5c0fb47f78745b9cb5260acee0e751b89bcd354640ff8bc8d29ec), which is a web shell written in PHP targeting Citrix NetScaler appliances. This file provides remote command execution, file exfiltration and file upload capabilities.
All command-and-control communication is RC4-encrypted using the 16-byte key 7489a0f93c67fa5cdaeb4b921d90594d, which is the MD5 hash of the hard-coded passphrase Rhfajaf1H992. The shell authenticates operators by verifying the k parameter against the passphrase and leverages the NetScaler SUID binary at /var/netscaler/.ns_suidcmd for privilege escalation.
Actor commands arrive through a custom HTTP headers. These headers are retrieved by checking the HTTP_xxx server variable, xxx parameters in cookies, GET and POST request parameters, as well as Apache request headers. The command handler in this web shell supports five different commands:
cmd command executes an arbitrary shell command using shell_exec, exec, passthru, system, and popen. It returns RC4-encrypted output.
size command returns the size of a specified file determined by running wc -c < {filename} 2>/dev/null
dl command exfiltrates files from the target system with chunked transfers via offset and length parameters, enforcing a hard cap of 1,048,576 bytes per request
up command writes data to a specified file path with optional append mode
info command returns the PHP version in the format php=PHP_VERSION\nns=4
CVE-2026-88771: Three Stage Command Injection Exploit to Web Shell Execution
On September 21, an actor from 77.83.199[.]39, 78.47.24[.]217 and 139.180.152[.]138 dropped a PHP web shell in a three-stage process against a U.S.-based target’s NetScaler devices.
Stage 1
The attacker sends an HTTP request to the NetScaler device with a dropper command encoded as Base64 text in the User-Agent string. The NetScaler device sends back a 404 error as expected, but this User-Agent string is added to the /var/log/httpaccess-vpn.log.
Stage 2
The attacker submits a login request that includes additional text that is logged as a failure message to /var/log/ns.log as:
pitboss PPE missed too many heartbeatsNSPPE;<additional text>
Eventually this ns.log file will be processed by the vulnerable Perl script at /netscaler/ns_monuploadd_err.pl.
Stage 3
When the Perl script at /netscaler/ns_monuploadd_err.pl -WR runs, it:
Picks up the poisoned log entries from the previous stage
Extracts the additional text inserted after NSPPE
Runs that text as part of a shell command
The <additional text> in this activity uses the grep command to retrieve the staged Base64 contained in the access log entry from Stage 1. It then decodes the Base64-encoded text and pipes it to sh or php, where this decoded text is run as a command.
Payload Analysis
Figure 1 shows an example of the PHP web shell we observed being dropped and executed as a Base64 payload in the three-stage process above. We have observed multiple values in place of C2 (e.g., 3P, 4B) at the beginning of this text and a variable character length.
Figure 1. Example of PHP web shell dropped and executed as a Base64 payload.
Figure 2 shows the decoded text from the Base64 payload.
Figure 2. Decoded text from the Base64 payload.
What the Commands Do
Privilege Escalation Bootstrap
chmod 6555 /bin/sh sets the SUID + SGID bits on /bin/sh. Any unprivileged process that subsequently calls /bin/sh inherits root UID. This step ensures future commands run as root regardless of the web server's runtime user.
Establish the Drop Path
mkdir -p /var/netscaler/logon/LogonPoint/custom
The directory at /var/netscaler/logon/LogonPoint/ is the NetScaler Gateway web UI root, served directly by the appliance's Apache (httpd). The custom/ subdirectory is the intended path for customer UI customizations — it is web-accessible by design and often not monitored.
CsrfToken cookie must equal the hard-coded value e826d7ddf3c85920. This is the per-implant password — different intrusions might use different tokens.
Command Channel
The NSC_TASS cookie carries the URL-encoded command to execute. Passthru() runs it with shell privileges and streams output directly to the HTTP response.
Stealth Headers
No-store/no-cache directives prevent proxy and browser caching, reducing the chance of detection via cached response analysis.
Naming Camouflage
NSC_TASS mimics legitimate NetScaler cookie names (NSC_* is the namespace used by NetScaler for load-balancer session cookies), making it blend into normal appliance traffic.
Register Web Shell With Apache via httpd.conf Patching
The perl -ni -e one-liner surgically edits /etc/httpd.conf to add two things:
A <Files ".ctxs.receiver"> block that enables PHP execution for the hidden file and sets anti-caching headers.
Two Alias/AliasMatch directives that serve the web shell under a legitimate-looking path:
Fixed alias: /logon/LogonPoint/custom/receiver.min.css → web shell
Regex alias: /logon/LogonPoint/custom/receiver.min.<hex>.css → web shell (any hex suffix)
The CSS filename disguise is deliberate. Browser developer tools, web application firewall logs and blue team analysts watching HTTP traffic will see what looks like a versioned CSS asset load, which is completely normal for a web application. The grep -q guard prevents duplicate injection if the persistence mechanism is run again.
Enable PHP Engine
The perl -pi -e 's/php_flag engine off/php_flag engine on /' /etc/httpd.conf one-liner substitutes php_flag engine off with php_flag engine on in httpd.conf to enable PHP, which is required for the web shell to execute. NetScaler's Apache config ships with php_flag engine off to disable PHP execution globally as a security hardening measure.
Reload Apache Using Updated Configuration
The line kill -HUP `cat /var/run/httpd.pid` sends SIGHUP to the Apache process, triggering a graceful config reload without dropping active connections. The injected config and PHP engine activation take effect immediately, with no restart log entry and no interruption to legitimate traffic.
Post-Disclosure Activity
We saw wide scale scanning and testing for these vulnerabilities once they were publicly disclosed on Sept. 27, 2026. Our analysis is ongoing and we will update this section if we identify novel activity.
Interim Guidance
We recommend that customers update their Citrix software to the latest versions as soon as possible, as well as following the recommendations:
Confirm exposure following the “Steps to determine if an appliance meets the CVE preconditions” section of the Citrix Security Advisory for these vulnerabilities
Isolate the vulnerable systems from the network
Preserve evidence by capturing the following:
A NetScaler VPX instance snapshot
Logs on remote syslog servers and NetScaler Console
A technical support bundle
A packet engine core dump
Hunt for the following:
Signs of suspicious administrative sessions
Unexpected outbound connections
Unexplained gaps in logging
Note: These are not TTPs we have observed specifically related to these vulnerabilities. They should be seen as general hunting guidance until more is known about the exploitation activity identified by Citrix in their advisory.
Update and patch to the latest versions
Note: Updating and patching will not remove access for attackers that have already established persistence within a compromise the network.
As of Sept. 27, 2026, Palo Alto Networks Cortex Xpanse has identified the presence of 50,277 exposed instances potentially vulnerable to these CVEs based on our telemetry.
Unit 42 Managed Threat Hunting Queries
This query looks for CVE-2026-88771 log poisoning. It does not indicate successful exploitation on patched devices. Unpatched devices will lead to execution if this log poisoning is present on a system.
command_attempted=if(_raw_log contains"PPE unexpectedly died",arrayindex(regextract(_raw_log,"pitboss PPE unexpectedly died NSPPE(?:\-00|)\;(.+)\>, factor"),0),arrayindex(regextract(_raw_log,"pitboss PPE missed too many heartbeats\s?NSPPE(?:\-00|)\;(.+)\>, factor"),0))
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
Next-Generation Firewalls With Advanced Threat Prevention
Next-Generation Firewall with the Advanced Threat Prevention security subscription can help via the following Threat Prevention signature: 97562. This signature is designed to block the exploitation of the CVE-2026-88771 Citrix NetScaler command injection vulnerability
Cloud-Delivered Security Services for the Next-Generation Firewall
Cortex XDR and XSIAM are designed to detect post-exploit activity, including credential-based attacks, with behavioral analytics.
Cortex Xpanse
Cortex Xpanse has the ability to identify exposed Citrix NetScaler ADC and Gateway devices on the public internet and escalate these findings to defenders. Customers can enable alerting on this risk by ensuring that the InsecureCitrixApplicationDeliveryController Attack Surface Rule is enabled. Identified findings can either be viewed in the Threat Response Center or in the incident view of Expander. These findings are also available for Cortex XSIAM customers who have purchased the ASM module.
Device Security
Device Security is designed to proactively protect the specialized device attack surface of operational environments, providing deep visibility into industrial protocols, actionable risk insights, and adaptive security enforcement across all OT and IoT assets.
Updated Sept. 27, 2026 at 4:15 p.m. PT to add information about Cortex Xpanse telemetry.
Updated Sept. 30, 2026, at 3:00 p.m. PT to add information on pre- and post-disclosure activity and threat hunting queries. Additional product protection information was added.
Updated Oct. 1, 2026 at 1:00 p.m. PT to update MTH queries and add Cortex Xpanse and Device Security product protection information.
Updated Oct. 8, 2026 at 7:00 a.m. PT to add Advanced IP Defense and DNS Security to the product protection.
Kubernetes operators are coded to drastically reduce operational toil by acting as automated site reliability engineers. However, their reliance on highly privileged service accounts introduces a severe, often overlooked security weak spot.
To quantify and combat threats aiming to take advantage of this weak spot, we have released OperTraitor, an open-source, large language model (LLM)-powered analysis engine. OperTraitor ingests raw role-based access control (RBAC) configurations directly from locally installed operators and the OperatorHub catalog. Upon doing so, it calculates the difference between an operator's documented functionality and its actual granted privileges.
In using this tool, we discovered problems lingering in default registries like OperatorHub (e.g., abandoned, overly permissive software components). To ensure smooth deployments, developers frequently grant these Kubernetes operators broad, wildcard RBAC permissions, unintentionally transforming trusted components into silent backdoors.
OperTraitor empowers defenders by generating a normalized risk score to help visualize the potential impact of third-party operators. Defenders can then effectively downscope the operators’ underlying service accounts before they can be exploited.
This article analyzes the shifting threat landscape as the industry transitions toward AI-driven agentic operators, a development that will turn these passive RBAC misconfigurations into active threat vectors.
We detail the real-world impact of these excessive permissions through two case studies:
Using our tool, we identified a High-severity vulnerability (CVE-2026-6389, CVSS 8.8) in IBM's Turbonomic platform
OperTraitor also flagged an overly privileged configuration that included cluster-wide access to secrets and various actions on RBAC resources
We examine the complex trade-offs vendors face between operational flexibility and strict security
We demonstrate how to hunt for and mitigate similar risks in your own environment using OperTraitor
Palo Alto Networks customers are better protected from the threats discussed in this article through the following products:
Before we can secure Kubernetes infrastructure, we must understand its foundational automation mechanisms. When we discuss Kubernetes operators, we refer to two core components working in tandem, a custom resource definition (CRD) and a controller:
CRD: A user-defined extension of the Kubernetes API that allows engineers to treat specific business logic (like a database cluster or a firewall policy) as a native Kubernetes object.
Controller: A non-terminating control loop that continuously monitors the actual state of these custom resources and reconciles them against the desired state defined in the configuration files. To execute this reconciliation loop, the controller requires a Kubernetes service account bound to specific Roles or ClusterRoles.
If a threat actor compromises an operator, the scope of the compromise is entirely defined by its RBAC permissions. An overly privileged operator functions as a silent backdoor ripe for exploitation, regardless of whether the compromise stems from a container image supply chain attack, a dependency vulnerability or the hijacking of its underlying node.
The Amplification of Risk: AI and the Agentic Era
While the fundamental issue is RBAC, the stakes are rising. The industry is currently shifting toward agentic operators, which are autonomous systems that manage clusters using LLMs and AI reasoning.
When we introduce AI into this ecosystem, excessive permissions become a much more serious weakness. We can observe this compounding risk in three emerging operational patterns:
LLM-enhanced logic: Operators that enhance standard remediation with LLM calls (e.g., K8sGPT)
If these inherit broad RBAC, they effectively become autonomous entities capable of reading sensitive data across unintended namespaces. These autonomous entities fall under two categories:
External agent bridges
Full agent runtimes
External agent bridges: Operators serving as conduits for external agents (e.g., via Model Context Protocol)
An overly privileged operator can grant an external AI unchecked control over cluster resources
Full agent runtimes: Operators designed to manage AI agent lifecycles natively within the cluster
The agents' unpredictable capabilities can impact the approach to infrastructure management
Regardless of whether an operator uses an LLM or traditional deterministic logic, the defensive mandate remains the same: Secure the service account.
Auditing the Ecosystem: The Operator Lifecycle Weak Spot
To understand the true scale of these RBAC misconfigurations across the ecosystem and empower the community to audit them, we built OperTraitor. We designed this automated pipeline to perform the following:
Collect data based on OperatorHub and locally installed operators
Feed their RBAC configurations into an LLM configured for threat analysis
The engine compares the permissions an operator actually possesses against its stated documentation. It then assigns a risk score from 1–10 based on the difference between required and granted privileges.
Figure 1. OperTraitor architecture. Source: OperTraitor repository on GitHub.
Figure 2 displays a screenshot of the OperTraitor user interface, showing the total number of high-risk operators alongside the post-analysis scores of two specific operators.
Figure 2. OperTraitor main analysis dashboard showing high-risk operators.
During this process, we uncovered a significant supply chain weakness. OperatorHub is filled with abandoned, overly permissive software components. Many vendors publish new, secure versions of their operators exclusively through Helm charts, their GitHub repositories or ArtifactHub. However, their older, vulnerable versions remain easily accessible through the Operator Lifecycle Manager (OLM).
OLM has historically been the gold standard of the open-source community and the default in OpenShift environments. As a result, users routinely deploy outdated operators in a few simple clicks, often without realizing it. Vendors are largely not prioritizing the maintenance or deprecation of their legacy components on OperatorHub, presenting a significant attack vector.
The Tip of the Iceberg
The RBAC misconfigurations we discovered are not isolated incidents. During our research, we identified multiple other operators (slightly over 5%) that request excessive privileges, including implicit paths to cluster admin access.
Unfortunately, many of the operator owners we contacted did not respond to our responsible disclosure attempts. In many cases, this lack of engagement simply indicates that the operator is no longer actively maintained.
While we will not cover those specific cases in this article, the reality highlights a critical takeaway that security teams must be vigilant. We strongly encourage treating every component sourced from OperatorHub with caution, independently verifying both its RBAC requirements and its active maintenance status before deployment.
To illustrate the real-world impact of these excessive permissions, we detail two specific case studies below.
Case Study 1: Excessive Secret Access (Prometurbo Operator - IBM)
When initially scanning OperatorHub, OperTraitor flagged the Prometurbo operator for using wildcards. Recognizing that the version on OperatorHub was severely outdated (v8.6.0, from 2022), we analyzed the recent version available via IBM’s GitHub repository (v8.17.6) to see if the posture had changed.
OperTraitor identified a critical RBAC violation. Instead of restricting access to its own namespace, the operator's service account was bound to a ClusterRole. This ClusterRole contained an explicit rule granting get, list and watch verbs on the secrets resource within the core API group (represented by apiGroups: [""])
Unless an operator functions explicitly as a centralized secrets manager, it rarely requires cluster-wide read access to Secret resources. Typically, an operator only needs access to specific secrets within its localized namespace.
Possessing explicit, cluster-wide read access to all secrets, the Prometurbo operator effectively became a single point of failure. If compromised, an attacker could immediately dump administrative service account tokens, database credentials, API keys and TLS certificates from completely unrelated namespaces. This could turn a localized breach into a total environment compromise.
Upon identifying this setting, we initiated a responsible disclosure process with IBM. The vendor responded promptly and collaboratively, quickly identifying the root cause and issuing a patch in a subsequent release that properly scoped the operator's RBAC permissions to align with the principle of least privilege (PoLP).
Due to the importance and impact of the vulnerability, IBM published a formal security bulletin and assigned a CVE (CVE-2026-6389) with a High CVSS score (8.8/10).
Disclosure Timeline:
Nov. 5, 2025: Vulnerability reported to IBM via the Vulnerability Disclosure Program
Feb. 3, 2026: IBM confirmed the issue is resolved
April 24, 2026: IBM published a security bulletin with CVE-2026-6389
Case Study 2: The Trade-Off Between Security and User Experience (UX) (Datadog Operator)
In the case of the Datadog operator, OperTraitor flagged an overly privileged configuration that included cluster-wide access to secrets and various actions (verbs) on RBAC resources (ClusterRoles and ClusterRoleBindings).
Upon our disclosure, Datadog representatives shared a detailed explanation of the reasoning behind granting these broad permissions. They noted that the names of the secrets the operator needs to access are based on user-defined values, making them impossible to predict or explicitly define before deployment. Given Datadog’s architecture, this is a valid point that highlights the complex trade-off vendors face between delivering strict security and a seamless user experience.
Securing the operator ecosystem requires a shift in how security teams evaluate and monitor Kubernetes infrastructure. We recommend implementing the following defensive strategies:
Verify the source and avoid default registries: Do not implicitly trust versions available on OLM or OperatorHub. Always verify the vendor's official documentation and deploy operators via their maintained Helm charts, ArtifactHub or official GitHub repositories to ensure you are installing the most recent, patched version.
Enforce namespace-scoped operators: Whenever architecturally possible, restrict operators to the specific namespaces they manage. Avoid deploying cluster-scoped operators (ClusterRoles and ClusterRoleBindings) unless absolutely necessary, strictly limiting the area of impact in a potential compromise.
Continuously audit and downscope RBAC: Always validate vendor-provided YAML manifests. Assess the RBAC posture for critical production environments. There are useful open-source tools to support this task, including OperTraitor.
Monitor service account behavior: Enable and actively monitor Kubernetes Audit Logs. Baseline the normal behavior of your operator service accounts and alert on anomalous activity. An example of anomalous activity could be an operator suddenly attempting to list secrets in an unrelated namespace or querying the API server from an unexpected IP address.
Establish guardrails for AI agents: If you are experimenting with LLM enhanced operators or agentic frameworks, enforce strict network policies:
Ensure these pods cannot reach the public internet or unauthorized internal endpoints
Strictly limit the context and permissions passed to the underlying LLMs
Conclusion
The convenience of Kubernetes operators comes with a hidden cost: the rapid proliferation of highly privileged, non-human identities within our clusters. Our research indicates a widespread violation of the PoLP across the Kubernetes ecosystem.
Whether driven by the difficulty of scoping permissions for dynamic environments or simply by a developer’s misconfiguration, operators are frequently granted access that far exceeds their operational requirements. This problem is exacerbated by the prevalence of outdated, abandoned components in registries like OperatorHub, creating a massive attack surface.
The shift to agentic operators will worsen the risks this presents. An overly privileged operator today is the autonomous, uncontrolled agent of tomorrow.
As we stand on the threshold of the agentic era, the way we manage Kubernetes is undergoing a fundamental change. AI-driven automation holds incredible promise for reducing operational overhead, but it requires a rock-solid foundation of identity and access management to ensure a secure environment.
We can not afford to treat non-human identities as an afterthought. Security teams must scrutinize operator permissions with the same rigor they apply to human administrators. By improving the RBAC hygiene of our clusters today, we can safely embrace the autonomous operations of the future without betraying our security posture.
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
Cortex Cloud can help protect cloud posture and runtime operations against identity-driven threats by pairing static permission baselines with deep behavioral context. By embedding the functional identity baselines discussed in this research into our detection engine for both cloud VM compute and serverless agents, Cortex Cloud adds a vital layer of operational context, enabling security teams to filter out noisy false positives and decisively catch threat actors attempting to masquerade, alter configurations, or execute anomalous operations in the environment.
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 interviewed three Unit 42 consultants to examine the most critical cybersecurity misconceptions observed in their casework across customer environments, and the strategic shifts needed to correct them.
Myth 1: The More Security Tools, The Better
A widespread assumption is that purchasing a new, specialized security tool for every emerging threat always results in stronger protection. In reality, continuously adding tools without a unified security strategy can lead to tool overload and create critical operational vulnerabilities.
Some of the key challenges created by this approach include:
Alert fatigue and high false positive rates: Improperly tuned security tools can overwhelm security operations center (SOC) analysts with alerts, making it difficult to distinguish real threats from false positives. AI-powered telemetry can help reduce this burden, but if it’s treated as a black box, it can complicate analysts’ efforts to understand the reasoning behind an alert.
Feature underutilization: Organizations frequently fail to take advantage of the capabilities already available within their existing security platforms. Rather than leveraging features present in the tools they already have, some organizations purchase new products to address needs their current tools can already satisfy.
Increased operational friction and overhead: Managing multiple, disparate platforms consumes valuable time and increases operational costs. It can also create visibility gaps at the integration points between different tools and technology suites.
Our consultants recommend three main strategies:
Thoroughly Audit Your Tools
Conduct an in-depth audit of the security tools your organization already deploys. Review vendor documentation, technical manuals and product resources to identify the full range of capabilities available within each platform, not solely the most well-known or popular. Understanding a product’s full capabilities can reveal opportunities to address existing security requirements without introducing additional products.
Conduct a Comprehensive Security Architecture Review
Organize your security tools according to their primary function and domain. For instance, network tools should be classified under network protection while identity tools fall under identity and access management. Evaluate each security domain systematically to understand which tools are truly required and where existing platforms may already provide adequate coverage.
Consolidate and Fine-Tune
Align your security portfolio to your organization’s unique environment. Where possible, consolidate overlapping solutions and configure existing platforms to maximize their capabilities. The goal is not simply to reduce tools but to build a security portfolio that is streamlined, integrated and capable of providing effective coverage.
Myth 2: Smaller or Medium Sized Organizations Are Safe From Attackers
Unit 42 consultants have observed small and mid-sized organizations operating under the assumption that they are too insignificant to be targeted by major threat actors.
The reality is that attackers frequently target smaller entities to provide a pathway into larger, more heavily protected organizations. This risk is particularly relevant in the public sector, where smaller agencies may maintain connections or access to larger entities and critical infrastructure.
This assumption is compounded by overconfidence and poor implementation posture. In a majority of the cases observed, organizations failed to properly implement, leverage and enforce the tools they actually possessed. These issues can increase the odds of being compromised.
Our consultants emphasize two main approaches for reducing this risk:
Maintain a Zero-Trust Mindset
An organization’s size, industry or current security practices do not make it immune from being compromised. Modern security teams should operate under an Assume Breach mindset, prioritizing proactive readiness.
Invest in Your Security Strategy
Gone are the days when an organization’s cybersecurity can be successfully managed by one IT administrator. Cyber risk encompasses every vector that could lead to system compromise, from unpatched software to social engineering to supply chain vulnerabilities. A thorough security strategy is essential for the long-term success of an organization, and must be prioritized as such.
Myth 3: Security Controls and GRC Are Strictly For "Checking Boxes"
Our consultants frequently observe organizations treating security controls and governance, risk and compliance (GRC) controls as routine checkpoints rather than essential components of active defense. Associating controls strictly with the compliance space fundamentally misinterprets their purpose. When security teams view controls as audit paperwork, they undermine their strategic value and leave severe risks unaddressed across the enterprise.
Consider a periodic privileged access review, a control that’s designed to regulate identity and access management. If neglected, unmonitored accounts in an organization can obtain excessive permissions. If a threat actor compromises one of these accounts, they obtain increased privileges that enable rapid lateral movement and privilege escalation across the enterprise. Had the security control been administered as intended, the excessive privileges would have been revoked, therefore removing the attacker’s primary attack path.
Our consultants offers three main key takeaways:
Adopt a Security-First GRC Mindset
Shift the perspective of GRC from external audit compliance to active threat mitigation. This approach enables organizations to identify risks earlier, refine controls processes and respond to emerging threats more effectively.
Establish an Authoritative Security Framework
Organizations should establish a recognized security framework, such as NIST SP 800-53, CIS Controls v8, or ISO 27001, as the foundation for their GRC program. Pairing a high-level control framework with technical specifications provides clear guidance on the controls that need to be implemented and monitored.
Adopt a Risk Controls Matrix (RCM)
Allocate the necessary time and resources to build and manage a dynamic RCM. This includes:
Clearly designating RCM owners
Maintaining clean data mapping across enterprise applications
Establishing clear testing schedules
Verifying whether controls perform as intended
An effective RCM verifies control efficacy, eliminates ambiguity and accelerates incident response.
Final Thoughts
These perspectives from our consultants reinforce a key takeaway: Effective organizational security is built on foundational discipline, not on chasing industry trends and continually shifting to the next solution. Routine architecture reviews, ongoing assessment of weak points and an understanding of your true security posture delivers a stronger, more sustainable foundation for managing risk.
The connections between these myths further demonstrate how they can reinforce one another. An increasingly complex tool stack can directly create a false sense of security, leading organizations to overestimate their defenses and underestimate their exposure. While these technologies can provide significant value and strengthen an organization’s defense, they are not a substitute for security fundamentals. Challenging these underlying assumptions and addressing the underlying gaps can fundamentally transform an organization’s security posture from passive compliance into true resilience.
This article explores how AWS mitigates the security risks associated with publicly exposed Identity and Access Management (IAM) access keys through its AWSCompromisedKeyQuarantine managed policy. We discuss the evolution of the different versions of this AWS managed policy. We also show how the managed policy AWSCompromisedKeyQuarantine evolved over time to protect organizations by relating it directly to new cloud attacks against AWS environments.
Additionally, this article provides background to the partner integration between GitHub's secret scanning program and AWS. Our research details how the managed policy automatically gets attached with a step-by-step timeline of a real-world exposure test.
Finally, the article highlights practical monitoring strategies for security teams to detect quarantine events within their own logging environments to ensure rapid incident response.
Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:
When organizations face attacks against their AWS environments, misuse of AWS IAM user access keys continue to account for a large majority of initial attack vectors. These long-term access keys pose security risks to organizations if the permissions associated with the IAM users do not follow the principle of least privilege.
Access keys and their associated secrets become exposed in many different ways, commonly through publication in public code repositories or exposure in environment variable files. If AWS receives notifications about access keys and secrets exposed in public GitHub repositories or through other notices, it promptly secures those credentials and notifies the owners.
AWS secures the exposed credentials using automated processes, which allows it to quickly support victim organizations and limit their exposure. This automated process has been around for many years and was documented by cloud security researcher Pawel Rzepa in the AWS Access Keys Leak in GitHub Repository and the Some Improvements in Amazon Reaction posts.
Before delving into the importance of the AWSCompromisedKeyQuarantine managed policy and its purpose, we will first discuss how managed policies work within AWS environments.
The AWS IAM service offers various features for configuring identities within an AWS account. In particular, AWS provides a policy feature that aggregates permissions into an object for attachment to a principal.
Policies encompass a wide range of types, but this article focuses on identity-based policies. Identity-based policies specifically attach to an identity, while other policy types attach to resources or define permission limitations, such as a permission boundary.
These policies consist of managed (AWS-managed and customer-managed) and inline policies. Managed policies include three sub-types:
Figure 1. Breakdown of IAM features in relation to main IAM service.
AWS-managed policies exist to assist organizations with IAM permission management. They also enable organizations to configure permissions to stand up resources within an AWS account swiftly and securely. Of the AWS-managed policies, AWSCompromisedKeyQuarantine specifically helps protect an IAM user in case of an exposed AWS IAM access key and secret. Access keys grant long-term command line interface (CLI) access to an IAM user.
AWS created the AWSCompromisedKeyQuarantine managed policy on Aug. 11, 2020, later releasing V2 on April 21, 2021, and V3 on Aug. 21, 2024. According to the V3 managed policy description, this policy:
“Denies access to certain actions, applied by AWS in the event that an IAM user's credentials have been compromised or exposed publicly. The policy aims to limit the potential damage that may be caused by fraud-related activity leading to unauthorized charges, while not impacting the existing resources. Do NOT remove this policy. Instead, please follow the instructions specified in the support case created for you regarding this event.”
We will cover the evolution of the policy permissions and the implication of those changes in the Managed Policy Permission Evolution section of this article.
Analyzing this policy in detail matters because AWS automatically attaches it upon locating exposed credentials in public code repositories or external exposure notifications. The AWSCompromisedKeyQuarantine managed policy proactively assists customers during access key exposures to minimize potential damage from attackers. Once attached, the managed policy limits the scope of permissions associated with the IAM user by denying various permissions commonly misused by threat actors.
GitHub Secret Scanning Partner Program
Long-term access keys can be exposed in many different ways. For example, it could be due to them being included in publicly accessible environment variable files and or public code repositories.
The GitHub secret scanning partner program allows it to scan public surfaces across GitHub, including repositories and public npm packages for specific sequences to identify exposed credentials. These scans occur by default within public repositories. Administrators and owners can also enable scanning on private repositories. Service partners can work with GitHub to create specific sequences for scanning and then provide an HTTP endpoint for GitHub to alert the service provider to exposed credentials in public repositories.
This alert allows the service provider to then proactively notify their customers about exposed credentials, and in some cases, the service providers take steps to secure the secret by revoking or quarantining the exposed secret. GitHub documentation lists more than 500 detectors across over 200 service partners, such as AWS. The checkbox in GitHub’s documentation notes when GitHub has an agreement to share compromised secret leaks with the respective issuer.
Managed Policy Attachment and Notification Process
When AWS first released the AWSCompromisedKeyQuarantine managed policy, the notification process differed from the current iteration. The original process entailed emailing the AWS account owner of the exposure. The process evolved to also attach the managed policy to the IAM user associated with the exposed access key and secret. The process has evolved again to include a support ticket generated within the AWS account containing the exposed access key.
We performed a test exposing an access key with a public GitHub repository in the main branch to track the response time and notification process. During the test scenario, AWS attached the AWSCompromisedKeyQuarantineV3 managed policy within 10 seconds of the access key exposure. A second later, GitHub generated a notification. This was followed shortly by AWS generating various Health and Support tickets.
The timeline below details each step of the testing process with commentary about what actions appear in the default AWS CloudTrail logs. The CloudTrail service, enabled by default for 90 days, records all management events occurring within an AWS account. During the test, we did not enable any additional CloudTrail data events so all the events in the timeline appear in the default CloudTrail logs. All times listed below are in Coordinated Universal Time (UTC).
Dec. 19, 2025 17:28:39 - CreateUser - CloudTrail logs showed the creation of the initial IAM user with the arbitrary username TestUser
Dec. 19, 2025 17:29:44 - CreateAccessKey - CloudTrail logs showed the creation of the new access key associated with the newly created IAM user
Dec. 19, 2025 17:34:23 - GetCallerIdentity - CloudTrail logs showed the initial test of the access key with aws sts get-caller-identity
Dec. 19, 2025 18:46:57 - When trying to push a new text file into the GitHub repository, GitHub push protection noted that it identified an access key and secret, as noted below in Figure 2. Both the access key and the secret each generated a pop-up asking whether the push with the credentials was purposeful.
Figure 2. GitHub notification of an AWS access key.
Dec. 19, 2025 18:50:05 - Access key and secret successfully pushed to public GitHub Repository
Dec. 19, 2025 18:50:15 - CloudTrail logs show the attachment of the AWSCompromisedKeyQuarantineV3 managed policy with the AttachUserPolicy event as noted in Figure 3. The CloudTrail log did not indicate this was an AWS automated action. Instead, the userIdentity JSON field, which identifies the action's performer, listed the IAM user's name (TestUser as shown in Figure 4) even though TestUser did not perform this action.
Figure 3. AWSCompromisedKeyQuarantineV3 managed policy attached.Figure 4. JSON entry from the CloudTrail log.
Dec. 19, 2025 18:50:16 - GitHub also sent out an email notification stating that it identified the sensitive access key and secret. Figure 5 shows the body of this email notification.
Figure 5. Content from the GitHub email notification.
Dec. 19, 2025 18:50:17 - In the AWS console, a notification appeared noting that an AWS Health alert was created with the name Risk IAM quarantine, as noted below in Figure 6. This action did not generate an event in the CloudTrail logs.
Figure 6. AWS console showing the Health alert.
Dec. 19, 2025 18:50:26 - AWS also sent out an email notification, shown below in Figure 7. This contained the same information as a Support ticket created seconds later in the AWS console.
Figure 7. Content from the AWS email notification.
Dec. 19, 2025 18:50:59 - In the AWS console, a Support case was also created with details of the exposed access key and IAM user. Figure 8 shows the details of this case. Creating a Support case also did not generate an event in the CloudTrail logs.
Figure 8. Details of the Support case in the AWS console.Figure 9 shows the high-level chain of events from the timeline illustrated in Figures 2–8.
Figure 9. Access key and secret exposure test scenario high-level timeline.
Within some organizations, the cloud engineering teams monitor emails regarding an AWS account and the security team is unaware of these emails. To prevent these communication gaps, security professionals can leverage AWS Systems Manager Explorer which helps aggregate AWS Support cases. The security team can also proactively enable alerting in the tool of their choice, based on the attachment event in the CloudTrail logs.
Within the CloudTrail logs, when any version of the AWSCompromisedKeyQuarantine managed policy gets attached to an IAM user, the event name AttachUserPolicy with the event source of IAM will be generated. The name of the managed policy will be present within the requestparameters subfield PolicyArn. This helps security teams proactively stay on top of exposed credentials and quickly begin investigating the access key in question.
Managed Policy Permission Evolution
After the initial release of the AWSCompromisedKeyQuarantine managed policy on Aug. 11, 2020, AWS has continued to update the policy to keep protecting their customers from new threats. AWS performs two types of version updates for managed policies. In minor updates, AWS makes changes to the permissions in the policy and updates the policy version without changing the managed policy name. In major updates, AWS creates a new managed policy and appends vX with the new version number to the end of the policy name.
Originally, the permissions of AWSCompromisedKeyQuarantine v1 focused on limiting 28 actions for the following five services:
However, with each new version of the managed policy, those permissions have evolved and expanded.
The code snippet below from the AWSCompromisedKeyQuarantine v1 managed policy JSON permissions details the full JSON permissions associated with the first version of this managed policy. Unlike traditional managed policies, this specific policy contains a Deny effect on permissions. After identifying an exposed access key, AWS does not need to modify the existing permissions associated with the IAM user to protect the identity from exploitation.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Deny",
"Action":[
"iam:AttachGroupPolicy",
"iam:AttachRolePolicy",
"iam:AttachUserPolicy",
"iam:ChangePassword",
"iam:CreateAccessKey",
"iam:CreateInstanceProfile",
"iam:CreateLoginProfile",
"iam:CreateRole",
"iam:CreateUser",
"iam:DetachUserPolicy",
"iam:PutUserPermissionsBoundary",
"iam:PutUserPolicy",
"iam:UpdateAccessKey",
"iam:UpdateAccountPasswordPolicy",
"iam:UpdateUser",
"ec2:RequestSpotInstances",
"ec2:RunInstances",
"ec2:StartInstances",
"organizations:CreateAccount",
"organizations:CreateOrganization",
"organizations:InviteAccountToOrganization",
"lambda:CreateFunction",
"lightsail:Create*",
"lightsail:Start*",
"lightsail:Delete*",
"lightsail:Update*",
"lightsail:GetInstanceAccessDetails",
"lightsail:DownloadDefaultKeyPair"
],
"Resource":[
"*"
]
}
]
}
Simply attaching these AWSCompromisedKeyQuarantine policies with the Deny component helps limit unauthorized usage of the key. When interpreting IAM user permissions, AWS dictates that explicit Deny overrides explicit Allow. So even if the IAM user permissions contained iam:CreateUser with an Allow for the effect, the AWSCompromisedKeyQuarantine managed policy containing iam:CreateUser with a Deny for the effect will override the Allow.
If the IAM user had completely different permissions than those listed below, then the purpose of the identity would not be impacted by these permission limits. Since the attachment of this specific managed policy occurs automatically, AWS wants to balance operational impact with securing the exposed credentials.
Another policy exists, AWSDenyAll, which denies all actions. However, this has a significant impact on any processes using the access key and secret. The AWSCompromisedKeyQuarantine policy limits the majority of risky threat actor activity while also allowing normal business operations.
AWS purposefully denies specific actions rather than completely disabling the compromised access key or user password. However, this decision allows advanced threat actors to use the exposed credentials for any actions the policy does not explicitly deny.
With AWSCompromisedKeyQuarantineV2, released on April 21, 2021, the permissions evolved to include the Amazon Simple Storage Service (S3) service with 11 permissions and 16 additional permissions to the original five services. Throughout the five versions of AWSCompromisedKeyQuarantineV2, AWS ultimately added a total of 61 permissions to the Deny list across 17 services.
When reviewing the different JSON permissions within v1 and v2 of AWSCompromisedKeyQuarantineV3, we identified that it replicated the additions to AWSCompromisedKeyQuarantineV2 v4 and v5 and added no additional permissions. Tables 1–3 detail the modifications made throughout each version of the managed policy.
Managed Policy Version
Version Release Date
Permissions changed
v1
2020-08-11 18:04:13
N/A
Table 1. AWSCompromisedKeyQuarantine permission changes per version.
Table 2. AWSCompromisedKeyQuarantineV2 permission changes per version.
Managed Policy Version
Version Release Date
Permissions changed
v1
2024-08-21 17:36:49
Same as AWSCompromisedKeyQuarantineV2 v4
v2
2024-10-02 16:52:27
Same as AWSCompromisedKeyQuarantineV2 v5 AWSCompromisedKeyQuarantineV3 v2 created 11 minutes after AWSCompromisedKeyQuarantineV2 v5
Table 3. AWSCompromisedKeyQuarantineV3 permission changes per version.
After releasing a new version, AWS stops attaching older policies to the exposed IAM users. Starting with AWSCompromisedKeyQuarantineV2, the Support service contains the support ticket with the attachment details as outlined in Table 1.
Cloud Attack Transition Based on Policy Updates
The evolution of the AWSCompromisedKeyQuarantine managed policy reflects how threat actors have changed their attacks against AWS environments. This section discusses an example permission added to the various versions of the managed policy and illustrates how various attacks might have caused that addition.
Let’s start with iam:CreateRole and lambda:CreateFunction in the AWSCompromisedKeyQuarantine v1 managed policy. This AWS Security Blog discusses how AWS uncovered a cryptomining campaign. Part of the attack involved creating a new IAM role to attach to the threat actor-created Lambda function. Once attached, the AWSCompromisedKeyQuarantine managed policy would have prevented this threat actor from creating a Lambda function and role.
The AWSCompromisedKeyQuarantineV2 v1 managed policy contains the s3:DeleteObject action. As discussed in an InfoRisk Today article, threat actors delete data from S3 buckets after exfiltration to maximize impact and encourage payment of extortion fees. Once again, if attached, the managed policy would have prevented the threat actor from successfully deleting all the data from the S3 bucket.
To counter malicious activity targeting the Amazon Bedrock service, AWS expanded v5 of the AWSCompromisedKeyQuarantineV2 managed policy to restrict five Bedrock permissions. This update was directly influenced by research from Permiso, which exposed how attackers exploit Bedrock to run unauthorized API calls like InvokeModel. Due to these policy enhancements, the attack methods uncovered by Permiso can now also be blocked.
GitHub Validity Checks for Detecting Secrets Exposure
GitHub has also created validity checks as part of its GitHub Secret Protection program (a subprogram of the GitHub Advanced Security program, or GHAS). When enabled, these checks periodically verify the validity of a detected credential by testing it against API endpoints provided by that service provider.
A list of supported secret scanning patterns can be found within the GitHub support secret scanning patterns documentation. Once GitHub identifies a secret, the platform proactively checks with various service providers to determine whether the exposed secret remains active or inactive, or whether it cannot be confirmed. GitHub also performs GET requests with the exposed credentials to confirm the credential’s validity and filters out dummy data.
After exposure of long-term AWS access keys in GitHub repositories, these GET requests take the form of performing the AWS Security Token Service (STS) API call GetCallerIdentity. This API event subsequently appears in the CloudTrail logs for the specific AWS account containing the exposed access key. Our testing triggered the newer push protection features that assist with catching secrets before they’re pushed to repositories.
A note of caution: There are some scenarios where push protection may will not scan a code push or alert on all identified secrets:
In one scenario, push protection does not detect secrets in the event of an overly large code push (e.g., pushing thousands of files or a public repository exceeding 50 MB)
In another scenario, if a single code push contains more than five exposed secrets, only five will generate alerts
These scenarios could result in an identification gap. Security teams should monitor for these potential cases to ensure additional scanning occurs on those code pushes, preventing any missed secrets.
Our testing generated CloudTrail logs that contain IP addresses, which resolve to the GitHub Autonomous System Number (ASN). The user agent present within the logs identifies the API event as originating from an automated testing process.
In early October of 2025, GitHub updated the user agent associated with AWS credential checks from:
Note: The above user agent strings use an asterisk (*) as a wildcard value for the version numbers.
Organizations need strong internal relationships between teams managing the organization’s GitHub repositories and cloud environments to promptly address exposed credentials. To circumvent organizational inefficiencies and issues between teams, security teams can also monitor for these exposed access keys by creating alerts specifically around GitHub ASN IP addresses with the above user agents performing GetCallerIdentity. This helps security teams proactively monitor exposed credentials and quickly begin investigating the access key before a potential attacker can misuse it.
Conclusion
The creation of the AWSCompromisedKeyQuarantine managed policy has proactively secured many organizations against unknowingly exposed IAM access keys and secrets. As the managed policy evolves, it reflects how attackers change their tactics when targeting cloud environments. Using the attachment of the managed policy and the presence of the GitHub validity check user agent, organizations can quickly address an exposure and investigate potential unwanted activity.
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
Cortex Cloud can help protect cloud posture and runtime operations against identity-driven threats by pairing static permission baselines with deep behavioral context. By embedding the functional identity baselines discussed in this research into our detection engine for both cloud VM compute and serverless agents, Cortex Cloud adds a vital layer of operational context, enabling security teams to filter out noisy false positives and decisively catch threat actors attempting to masquerade, alter configurations, or execute anomalous operations in the environment.
Idira Privilege Access Management (PAM) can help unify privileged access across human, machine, and agentic identities to secure cloud access across multi-cloud environments. Building on proven PAM, it delivers centralized secrets management alongside modern controls like Just-in-Time access and Zero Standing Privileges. This enforces consistent least-privilege security across on-premises, cloud, and SaaS targets.
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: 00080005045107
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.
Unit 42 researchers have identified an issue where using default configurations in Amazon Web Services (AWS) AgentCore Harness could allow attackers to steer an agent's actions through prompt injection to exfiltrate plaintext credentials managed by AgentCore Identity.
To reach that finding, we examined two of the harness's many integrations:
AWS AgentCore Identity, the platform's recommended way to manage agent identities and store credentials (i.e. an identity vault)
A downstream Model Context Protocol (MCP) server, which the harness authenticates against using a credential from that identity vault
AWS AgentCore Identity provides encryption at rest, encryption in transit, key management service (KMS) keys and identity and access management (IAM)-gated access. We wanted to know what happens at runtime, when a credential has to leave the vault to be used. What we found was that the harness's own built-in shell tool, which is enabled by default, reaches into the same memory space where credentials are resolved to plaintext.
We disclosed this finding to AWS. AWS reviewed and closed the report as informative under the AgentCore shared responsibility model, citing allowedTools scoping and egress filtering as customer-side controls.
For operators building on AgentCore today, defense takes a layered approach:
Scope the allowedTools the harness can use to what it needs
Scope Identity vault service accounts to least privilege for the downstream integration
Watch outbound traffic from your harness containers
Palo Alto Networks customers are better protected from the threats discussed in this article through the following products and services:
The research that follows is built entirely on AWS AgentCore Harness, a managed runtime for AI agents. As AWS describes it, you declare what your agent does (model, tools, skills, instructions) and AgentCore handles the rest. This includes the environment, compute, memory, identity, networking and observability that turn the configuration into a running agent.
What you declare is only part of the picture. On top of it, the harness ships two built-in tools turned on by default. As AWS's documentation put it in late August 2026:
"Default tools shell and file_operations are available in every session unless you restrict them with allowedTools. shell executes bash commands; file_operations supports viewing, creating, and editing files."
The built-in tools are a big part of what makes the harness so autonomous and productive. The agent can write files and run code to get real work done. But the same reach that makes the built-in tools useful makes them dangerous when people leave them on unintentionally.
We've found that the shell tool runs as root inside the harness, so the moment an attacker gets the agent to run a command, that command inherits the same root access. Nothing has to be misconfigured for this to happen. It is the out-of-the-box state.
Unless you scope the allowedTools parameter to what each session actually needs, every session can run arbitrary shell commands and read or write files, whether you asked for those tools or not.
The Agent Harness Bridges the Gap Between Reasoning and Action
Not long ago, an AI model could answer a question but not act on it. Now, AI agents are reasoning across boundaries that used to be out of reach, taking on tasks that are more complex, longer-running and more autonomous.
But reasoning alone does not get an agent very far. To be useful, an agent needs infrastructure that turns decisions into actions.
That is the gap an agent harness fills. It is the managed runtime around the model, built to keep the agent on track and give it what it needs to operate on its own. A harness provides a variety of different capabilities, including the following:
Tools to call
A sandboxed shell to execute code
Memory that survives across sessions
MCP integrations for external services
An identity to act under
The harness orchestrates these capabilities in a resilient loop that lets the agent plan, act, observe and continue.
Figure 1 below shows the anatomy of an agent harness.
Figure 1. Anatomy of an agent harness.
As Figure 1 illustrates, the user's reach stops at “invoke.” The harness's reach extends to every tool and downstream service under the operator's credentials.
Among all the capabilities a harness can give an agent, the shell tool can be both a significant productivity enhancement and a primary attack surface.
But to understand how the shell tool came to be, we first need a quick recap of how an LLM works in the context of this sort of tool.
The Shell Tool: Benefits and Risks
On its own, a language model can only produce text. To make it more useful, its ability to use tools relies on a mechanism called function calling.
The Benefit: Programmatic Tool Use Increases Functionality and Efficiency
This section outlines how function calling grew into programmatic tool use, a leap in efficiency that eventually put a shell tool in the agent’s hands.
Given a user request and a set of available functions, the model can determine that a function should be called and return a structured tool_call response:
The chosen function name
The arguments to pass and their values
All the information the runtime needs to execute it
The runtime then invokes the function, captures the result and sends that result back into the model's context, where the model can decide whether to call another function or produce the final answer. If you run that runtime in a loop and rename “functions” to “tools,” it is now a fully autonomous agent.
As agents matured, tool catalogs became part of agent frameworks. MCP pushed the idea further by standardizing how agents discover and connect to external tools, services, resources and prompts.
However, the core pattern stayed the same. The model still needed to have the tool definitions in its context before it could use them, and each tool's response before it could reason about what to do next. Both required context.
People saw how capable agents could be and began loading them with more tools. Very quickly, the bottleneck shifted from whether agents could use tools to how many tools the agent’s context can handle.
Programmatic tool use breaks out of the one-tool-at-a-time loop, leveraging the fact that models are trained on far more code and shell interactions than they are on tool definitions. With programmatic tool use, the model no longer works through tool definitions one call at a time, with every result piling back into its context. Instead, programmatic tools let the model orchestrate the entire workflow by writing scripts the way it sees fit in a sandboxed command line interface (CLI), such as Python, shell, or whatever the model needs. It executes commands as it goes and handles the results directly. The model only sees the final output.
That is what opened the door to longer and more complex agentic tasks. Instead of reasoning through every small step in natural language, the agent can delegate the messy middle to code and come back with the part that matters.
The efficiency gains from this are substantial. Fewer tokens are spent on tool definitions and intermediate results, and there is less latency from repeated model round trips. There’s also better accuracy because the agent can use code for the parts code is good at (loops, filters, transformations, retries and glue logic).
The context saving alone is dramatic. Compare the same 200,000 token budget under both approaches, as Figure 2 below shows. What we show in the image is a scenario in which every MCP tool definition is loaded upfront (top) versus a single shell tool discovering what it needs on demand (bottom).
Figure 2. Same 200,000 token budget.
Figure 2 shows that a single shell tool with on-demand discovery reclaims what dozens of upfront tool definitions cost. However, this approach introduces security trade-offs.
The Risk: Programmatic Tool Use Weaponizes Prompt Injection
The same property that makes programmatic tool use powerful also makes it an amplifier for prompt injection.
Before programmatic tool use handed the agent a shell, a successful injection could influence what the agent said, which typed tool it chose or what data it tried to leak back through its response. While text-based injection poses significant problems, its impact is still mostly bounded by text output and by the specific tools the developer exposed.
With a shell, we still worry about what the model can be convinced to say, but we’re also concerned about what code can do at the agent runtime's privilege level.
If the model can be convinced to run a command, influenced reasoning is no longer bounded by a typed schema. It is bounded by the privilege level of the managed runtime it runs in, including:
The file system
The process space
The network
The sandbox and whatever credentials are reachable from that execution environment
With that in mind, we can illustrate this with a fictional company called SupportCo.
Testing the Harness
To illustrate this scenario, we created a fictional operator SupportCo, which runs its customer-support agent on AgentCore Harness. The harness reads inbound support tickets, looks up account records through a downstream MCP server and hands the answer back to whoever wrote in. This is a default-configuration deployment including a managed harness, the built-in shell tool and an authenticated downstream MCP integration. Everything here is standard, and nothing is misconfigured.
Where can its built-in shell tool take us?
In Search of Our Primitive
Using nothing but prompts, we started with the approach of asking the model to use the shell tool and run our recon commands. It refused, and it did so again on the next attempt.
Those refusals suggested we should take a different approach. Luckily for the testing attempt, the harness's configuration knobs let us pick the model per invocation.
We don't need a capable, well-aligned model here, just one that supports tool calling. So we picked a more permissive model, and it did exactly what we asked. It saw a tool it was allowed to call and called it.
However, probing was still harder than we hoped. The connection between our prompts and what actually ran was loose. A next-token predictor is poorly suited to reproducing shell syntax exactly. If an escape vanishes or a dash gets rewritten, the quoting drifts just far enough to break.
So we stopped directly prompting the model to carry the payload, and instead landed the instruction via indirect prompt injection. We gave the model one line it could not get wrong: curl our recon script and pipe it into python3.
That is the version that stuck. The agent read the ticket, fired the shell tool and our recon ran inside the harness.
Figure 3 below shows the primitive (the reusable building block the rest of the attack is built on), where a hidden HTML comment tells the agent to curl our recon script and pipe it into python3.
Figure 3. The injected support ticket.
Who Am I?
The first thing our recon did was perform runtime environment discovery.
Figure 4 below shows the output of the whoami and id commands that were executed inside the harness.
Figure 4. The shell tool runs as root inside the harness.
To our surprise, the shell tool — the subprocess that runs whatever code the model decides to execute — was running as root. It was not a restricted service account or a sandboxed user.
Root access provides full visibility into the operating system environment, so we went looking to see what else was running. After realizing the harness doesn't ship ps, we read the process list straight from /proc. Figure 5 shows the results of the process tree.
Figure 5. The process tree.
The environment was not very busy, but one thing triggered our curiosity: process identifier (PID) 1, python3.10 -m loopy.server. Could this be the harness runtime? Our recon script, PID 40, was a direct descendant of it. PID 1 spawned bash (PID 38, the shell tool), which in turn ran our code. The same user identifier (UID) runs the entire chain, and every process is root.
If PID 1 was the harness runtime, its memory was where the interesting things live. So we checked its status and whether we could read it. Figure 6 below shows the results.
Figure 6. PID 1's status and access check.
We saw the same UID on both sides, and /proc/1/mem was readable. Everything in loopy's address space was open to the shell tool.
Reading it in practice takes a little more than a cat. The /proc file system (procfs) is a kernel-managed window into each process's runtime state, exposed through many small interfaces such as :
/proc/1/mem for raw memory
/proc/1/maps for the memory layout
*/proc/1/status for identity and privileges
The memory-region layout is sparse, so walking /proc/1/mem straight through hits unmapped gaps that throw I/O errors. So we scanned it in two steps:
Read /proc/1/maps for the layout of the address space:
Start address
End address
Permissions (read/write/execute)
What's mapped there (heap, stack, shared libraries, anonymous allocations)
This layout is our map of where to search.
For each readable region, read the bytes from /proc/1/mem:
seek() to the region's start address
read(size) bytes
Search the chunk for anything of interest in loopy's memory such as byte patterns, strings, structured data
Whatever we’re after, if it’s in loopy's memory, this approach pulls it out.
Where Am I?
The process tree left us a breadcrumb. The --library-path pointed the whole runtime at /opt/amazon, so we went into the file system where the harness's Python packages live, under /opt/amazon/lib/python3.10/. Figure 7 below shows the results.
Figure 7. The harness's Python packages.
PID 1 ran the loopy/ subdirectory shown above in Figure 7. The presence of server.py inside this directory confirmed our harness runtime. Within the same directory as loopy/ we found bedrock_agentcore/, with identity/, memory/, services/ and a handful of other AgentCore sub-modules that were available for exploration.
With read access to /proc/1/mem and the bedrock_agentcore packages within reach, one module in particular stood out: identity.
With root, a readable heap, our code running inside and network egress, all we lacked was a target. The identity module was it. To see why, let’s look in more depth at the AgentCore Identity vault.
AgentCore Identity Vault
Every credential in the Identity vault is encrypted at rest and in transit, sealed behind KMS keys and access controls. Instead of placing a Bearer token in the Authorization header, it’s stored in the Identity vault and referenced by the Amazon Resource Name (ARN), as Figure 8 below shows.
Figure 8. The vault reference for the Bearer token.
On paper, this is the right place to store credentials. But what happens at runtime?
For the harness to authenticate with a credential stored in that vault, the ARN first needs to be resolved into the real plaintext secret. That resolution must happen at runtime, inside its process. In this case that’s PID 1, whose memory we can already read.
With that in mind, we set out to see if and where an AgentCore Identity ARN gets resolved into a real JSON Web Token (JWT) inside the harness.
Exfiltrating an AgentCore Identity JWT
Setting the Stage
To see how AgentCore Identity works in practice, we set up a simple scenario. Our test rig simulated an MCP server that required an Amazon Cognito Bearer token and had access to personally identifiable information (PII) such as names, phone numbers or the last four digits of Social Security numbers (SSNs). The token was stored in the vault, and the harness was configured to reference it by ${arn:...} in its Authorization header, exactly as AgentCore documents.
Figure 9 shows the actual create_harness call, with the Identity vault reference in the Authorization header.
Figure 9. The create_harness call.
The built-in shell tool in that configuration is easy to miss because it comes on by default. AgentCore Harness ships the built-in shell and file_operations tools to every session unless the allowedTools parameter says otherwise, and both run at the same UID as PID 1.
This means the credential-theft chain we're about to walk through is reachable in the default configuration. Even if the operator finds allowedTools, the parameter only scopes tool selection at InvokeHarness time, not at CreateHarness. It is flexible if you know it, easy to miss if you don't.
The Exfiltration
With the harness live, we wrote a small script, pid1_identity_recon_exfil.py. It scans the heap for two patterns:
The credential itself in JWT form
The MCP server URL we'd need to replay it against
Figure 10 shows the patterns within this script.
Figure 10. The two heap-scan patterns in pid1_identity_recon_exfil.py.
To get the script running inside the harness, we reuse the primitive from earlier. as Figure 11 below shows. It uses the same support ticket as before, but this time the payload is our pid1_identity_recon_exfil.py file.
Figure 11. Support ticket with the hidden HTML comment.
Figure 12 shows the results of this action.
Figure 12. The exfil script's output from inside the harness.
One JWT (1,034 bytes) and the MCP server URL (the replay target) are both sent to our simulated attacker's webhook in a single HTTP POST request.
Figure 13 shows what landed on the attacker's side. This image shows the HTTP POST request and response captured at webhook[.]site, carrying the Bearer JWT and the MCP replay URL. This arrived at our simulated attacker's endpoint, moments after the agent summarized the support ticket shown previously in Figure 11.
Figure 13. The webhook[.]site page showing the JWT and MCP URL arriving at the attacker's endpoint.
Replay: From Webhook to PII
With the JWT and URL in hand, we fetched them from the webhook and connected to the MCP server. We were able to do so from our laptop with no AWS credentials required. Figure 14 below shows a screenshot of the replay session.
Figure 14. The replay from our laptop.
Our simulated attacker listed the MCP tools, called the lookup_customer tool that returned customer PII and created a ticket. All of this came from a credential stored in the AgentCore Identity vault, referenced only by ARN and never held locally by any user. It was now in the attacker's hands and fully replayable from anywhere on the internet.
Whose JWT Have We Exfiltrated?
We decoded the exfiltrated token by pasting it into the JWT Debugger, and its payload claims reveal the account behind it. Figure 15 shows the decoded token data, which includes the username for the account: mcp-service.
Figure 15. The exfiltrated JWT decoded.
Why the Operator's Service Account?
For the harness to use a JWT from the vault, that JWT has to be in the vault to begin with.
End-user session tokens don't qualify. They're generated fresh on login, expire quickly, and belong to whichever user is currently signed in. You can't pre-enroll them, and you can't provision a new harness per user just to embed their token.
There's a scope argument too. The user's session JWT authorizes them to bedrock-agentcore:InvokeHarness, alongside other permissions. The credential stored in the AgentCore Identity vault is something else entirely. It's meant to be used by the harness's execution role to authenticate against downstream services, in our case the customer’s MCP server. That's authority the user never had and was never supposed to have. It's the harness acting on the operator's behalf, not the caller's.
Figure 16 shows the two sides of the privilege boundary:
The caller is allowed only to InvokeHarness
The harness's execution role is allowed to reach every downstream service the operator wired in
The caller can only ask the harness for help. However, once invoked, the harness can reach every downstream service the operator wired in, including credentials.
Figure 16. Authorized to invoke is not authorized to reach.
The vault is for the credentials that are stable, including the operator's service accounts, wired in once at create_harness time. This is the one we set up at the top of the previous section in this article, Let's exfiltrate an AgentCore Identity JWT. It is then reused across every user session, which is the credential that lands in PID 1's heap and gets exfiltrated. The exfiltrated credential is not the end-user's JWT. It is mcp-service, the operator's service account.
Disclosure Timeline
May 19, 2026: Reported to the AWS Security team via HackerOne (report #3747844)
June 8, 2026: AWS Security team responded with reproduction requests and clarifications on scope
June 10, 2026: Confirmed this finding shares its root cause with an earlier report (#3737800) and the two reports were merged
June 10, 2026: AWS closed the report as informative under the AgentCore shared responsibility model, citing allowedTools scoping and egress filtering as customer-side controls
Conclusion
As AI agent reasoning gets sharper, longer-running and more autonomous, the attack surface the harness has to keep contained widens with every capability it hands the agent. Our research walked through one form of that widening surface end to end. This included a shell tool running inside the same memory space where the harness resolves its credentials and every credential the vault ever hands over sitting in plaintext in the heap by the time the shell tool could access it.
The vault successfully secured credentials at rest and in transit, but the shell tool's memory access bypassed these protections.
Our findings highlight a broader challenge for managed agent runtimes:
The shell tool could be the new perimeter if not scoped correctly.
A general-purpose shell is powerful because it can reach anything the runtime can. Scoping it down to prevent exfiltration also strips it of the flexibility that made programmatic tool use worth adopting. And the model's reasoning can't reliably distinguish a legitimate instruction from an injected one, so it's the shell tool's reach that bounds what an attacker can do, not the model's judgment. Whatever the shell tool can touch (file system, network, process memory, downstream services) is what an injection can touch.
Vaults protect at rest and in transit, not in use.
Any credential the harness resolves at runtime has to become plaintext to be useful. In-use protection is a separate problem, and the vault doesn't solve it.
Consider which credentials your harness acts on behalf of.
Harnesses might require long-term, high-privilege credentials to do their downstream work and stay autonomous. Whatever they resolve becomes reachable via any injection that lands, regardless of the invoking user's own scope.
We recommend those organizations operating on AgentCore Harness make sure to cover the following:
Scope the allowedTools parameter at InvokeHarness time (not CreateHarness) to what each session needs. The built-in shell and file_operations tools are shipped enabled by default. Sessions that don't call for them shouldn't get them.
Scope every Identity vault service account to least privilege for its downstream integration. A leaked credential is worth what its scope buys.
Watch outbound traffic from your harness containers. Any endpoint that isn't in your downstream integration list is evidence of an active injection, not configuration drift.
If you're building a managed agent runtime, treat every capability the harness gives the model as an attack-surface primitive, not a productivity feature bolted onto it. Any credential the runtime resolves has to live somewhere the shell tool cannot read, or the shell tool has to run in a sandbox isolated from the process that resolves it. Without these isolation boundaries, runtime credentials remain exposed to the shell tool.
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
Cortex Cloud can help protect cloud posture and runtime operations against identity-driven threats by pairing static permission baselines with deep behavioral context. By embedding the functional identity baselines discussed in this research into our detection engine for both cloud VM compute and serverless agents, Cortex Cloud adds a vital layer of operational context, enabling security teams to filter out noisy false positives and decisively catch threat actors attempting to masquerade, alter configurations, or execute anomalous operations in the environment.
Unit 42 Cloud Security Assessment is an evaluation service that reviews cloud infrastructure to identify misconfigurations and security gap.
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.
Our series, Inside the Modern SOC: Trends and Insights from Unit 42 Managed Services, shares the operational patterns that Unit 42 experts observe, with today's challenge beginning after the initial foothold.
Across Unit 42 investigations, we continue to see adversaries move well beyond where an attack begins. They pivot across the enterprise, avoiding detection by exploiting the visibility gaps created by disconnected security tools.
According to the 2026 Unit 42 Global Incident Response Report, 43% of attacks involved activity across four or more attack surfaces, with some cases spanning as many as eight. As attacks move across cloud, endpoint, network, identity and software-as-a-service (SaaS) environments, analysts must connect activity across security domains before the complete attack path becomes clear.
Following the Attack Across Environments
The First Signal
An investigation may begin with what appears to be an isolated event. An endpoint generates an alert. A cloud administrator provisions a resource outside of normal activity. An unfamiliar application requests elevated permissions. On its own, none of these events necessarily signals a broader attack.
The Cross-Environment Pivot
As the attack progresses, related activity begins appearing elsewhere. Permissions may change within a SaaS application. Cloud resources may be provisioned or reconfigured. Sensitive data may be staged for exfiltration. New network connections may emerge between systems that rarely communicate.
When these signals are investigated separately, security teams can miss the connection between them and the larger attack taking shape across the environment.
Reconstructing the Attack Path
The complete picture often becomes clear only when activity across security domains is connected. AI-driven correlation connects signals that initially appear unrelated, helping analysts reconstruct how an adversary gained access, where they moved, what they accessed and what they were attempting to accomplish.
Because attackers don't operate within the boundaries monitored by individual security tools, security operations can't either. Defenders need to follow attacker activity across the enterprise and investigate the intrusion as one connected attack. Doing this consistently requires continuous monitoring and response, along with ongoing optimization of detections, correlation rules and workflows as threats and environments evolve.
How SOC Leaders Can Defend Across Attack Surfaces
Use AI to Investigate the Attack, Not the Alert
As attackers move across security domains, security leaders should evaluate whether their operations can reconstruct a complete attack path rather than respond to isolated alerts. The goal is to use AI-driven correlation to reveal how seemingly unrelated activity connects before an adversary reaches their objective.
Connect Evidence Across the Attack Path
To track adversarial behavior from the first signal across every stage of the attack lifecycle, organizations must connect evidence across their security environment through lateral movement, persistence and impact. True visibility requires cross-domain correlation, while threat hunting should test for attacker behaviors that may not yet have generated an alert. SOC leaders should ensure their platforms automatically correlate activity into unified incident storylines, giving analysts the context to investigate and respond without manually pivoting between tools or teams.
Continuously Test and Evolve Security Operations
Treat every investigation as an opportunity to improve the next one. Review where analysts lost context, where detections or correlation rules could be improved and which response steps created delays. Use those findings to refine detection logic, correlation rules, automation and response playbooks as attacker techniques and the environment evolve.
How Unit 42 Managed Services Applies These Principles
As attacks increasingly span multiple environments, AI-driven correlation and behavioral analytics in the Cortex SecOps platform bring related signals together into a unified investigation. Unit 42 analysts apply frontline expertise and threat intelligence to validate the attack path, investigate coordinated activity and accelerate response.
Our Managed Detection and Response (MDR) analysts continuously investigate suspicious activity while our threat hunters combine AI-powered insights with Unit 42 expertise to proactively search for attacker behaviors that may not yet have generated an alert. Insights from investigations and hunts help strengthen detections, refine correlation rules and improve response workflows across customer environments.
Organizations using Managed XSIAM extend this approach through continuous SOC engineering delivered by Unit 42 experts. Our teams continuously optimize:
Data integrations
Detection logic
Custom correlation rules
Automated response playbooks
Investigation workflows
Continuous SOC engineering helps reduce investigation and response time by optimizing the detections, correlation rules, automation and workflows that power AI-driven security operations.
The Unit 42 Managed Services Edge
Unit 42 combines expert-led MDR, Managed Threat Hunting and Managed XSIAM to help organizations investigate attacks as one connected incident. Powered by AI-driven capabilities in the Cortex SecOps platform, our experts apply insights from thousands of investigations, threat hunts and incident response engagements to accelerate response and continuously improve security operations.
This article reviews an Atomic macOS (AMOS) stealer malware infection generated in a lab environment. While several sources have published articles analyzing AMOS stealer, the associated indicators constantly change. This article presents a snapshot of indicators seen in early August 2026 and is designed to help readers better understand AMOS stealer.
Malware that we've assessed as AMOS stealer has been distributed through ClickFix campaigns as well as through malicious ads. We've also seen AMOS stealer distributed through campaigns that claim to offer cracked versions of popular copyright-protected software. These sites offer instructions to install software such as a macOS toolkit but then actually install malware like AMOS stealer.
This article examines an AMOS stealer infection generated on Aug. 5, 2026, from an instructional page claiming to install a “macOS toolkit.”
Characteristics of the Infection
The domain hosting the malicious page claiming to have installation instructions for a macOS toolkit is getmacouscloud[.]com. An example of one of the pages is shown below in Figure 1.
Figure 1. A malicious website advertising a quick setup for “macOS toolkit.”
While the “quick setup” instructions from this page in Figure 1 are sometimes described as a ClickFix technique, this is not really ClickFix. The ClickFix technique generally uses a fake CAPTCHA or other type of verification page offering instructions to continue to the website a viewer intends to visit. ClickFix campaigns inject a script into a viewer's clipboard to paste into a Run window for Windows systems or a Terminal window for macOS systems.
Regardless of what we call this copy/paste technique, we followed the instructions in our lab environment. We copied text from the page and pasted it into a Terminal window on our macOS system as shown in Figure 2.
Figure 2. Malicious text pasted into a Terminal window.
The command in Figure 2 retrieved a Z-shell (Zsh) script from hxxps[:]//ferncore13[.]com/curl/608e70d1338612686917ee5cd300ff7ed8e318dfd787a50257f92142e99bd688. That Zsh script contains Base64-encoded text for a GZIP-compressed payload as shown in Figure 3.
Figure 3. Base64-encoded GZIP-compressed payload in the initial Zsh script.
That GZIP-compressed payload contains a follow-up Zsh script designed to retrieve and run a Mach-O binary to install AMOS stealer. That Mach-O binary for the AMOS stealer installer was saved as /tmp/helper, as shown below in Figure 4. The same directory also contained a plist file named starter, also shown in Figure 4.
Figure 4. Mach-O binary for AMOS stealer installer and plist file.
The plist file at /tmp/starter contains text that hints at a newly created file in the user's /Library/Application Support/.com.apple.accountsd/ directory named .service. This file is a shell script that runs a Mach-O file for AMOS stealer in the same directory named AccountsHelper, as shown in Figure 5.
Figure 5. Files in the /Library/Application Support/.com.apple.accountsd/ directory.
We found an additional directory and similar files in the user's /Library/Application Support/.com.apple.metadata.mds/ directory named .mdworker and mdworker_shared., as shown below in Figure 6. The .mdworker file is a shell script that runs another AMOS stealer Mach-O file named mdworker_shared.
Figure 6. Files in the /Library/Application Support/.com.apple.metadata.mds/ directory.
Of note, before the infection would proceed, the macOS host presented a prompt to enter the user's password as shown below in Figure 7. Since the user account on this macOS host was an administrative account, it proceeded when we entered the user's password.
Figure 7. Prompt for the user's password.
After entering the user's password, the host's Terminal process presented prompts requesting various permissions during the infection, as noted below in Figure 8.
Figure 8. Prompts by the Terminal process during the infection.
After running the initial malicious text in the Terminal window, the Terminal process requested the following permissions:
Access to control the macOS Finder application
Access to files in the user's Desktop folder
Access to files in the user's Documents folder
Access to control the macOS Notes application
AMOS stealer collected and temporarily saved information under the host's /tmp directory, and compressed the data into a file named out.zip. The file and directory structure of the out.zip file follows:
Directory: deskwallets/Binance/
Directory: deskwallets/TonKeeper/
Directory: FileGrabber/aws/
Directory: FileGrabber/docker/
Directory: FileGrabber/filezilla/
Directory: FileGrabber/gcloud/
File: FileGrabber/zsh_history
File: info
Directory: Telegram Data/
File: username
The infected macOS host was a clean installation with no additional added applications. However, the file and directory content of out.zip hints at the applications that AMOS stealer searched for during this infection.
Infection Traffic
Post-infection traffic consisted mainly of HTTP POST requests to a command and control (C2) server at 161.35.146[.]120. Figure 9 shows traffic from the infection filtered in Wireshark.
Figure 9. Traffic from the infection filtered in Wireshark.
As shown above in Figure 9, URLs for the initial HTTP POST requests hint at the types of data collected by AMOS stealer. These initial URLs end with the following strings:
stage=boot
stage=init_session
stage=messengers
stage=credentials
stage=browsers
stage=wallets
stage=resolve_auth
stage=local_data
Comparing this AMOS stealer infection on Aug. 5, 2026, with a previous infection on July 31, 2026, reveals similar post-infection URL patterns. However, that AMOS stealer infection generated traffic to a different C2 server at 188.166.78[.]138.
This comparison underscores a notable characteristic of AMOS stealer and its supporting infrastructure. The associated domains, URLs and IP addresses frequently change for AMOS stealer activity. The same frequent changes apply to filenames, file hashes and directory paths seen in our post-infection forensic analysis.
These different AMOS stealer characteristics over a relatively brief period indicate this is a malware family in active development, which is continually evolving.
Conclusion
This article reviewed an Atomic stealer malware infection from early August 2026. The resulting analysis includes behavior from the infected macOS host, malware samples, post-infection artifacts and traffic patterns that indicate the types of information collected by this malware.
The key to understanding AMOS stealer is realizing this malware is continually evolving. The indicators frequently change, and the ones we present in this research are no longer the most current. However, the overall patterns of activity remain consistent. While this review is a snapshot, analysts and other security professionals can better understand AMOS stealer by keeping track of its changes in the coming weeks and months.
Palo Alto Networks Product Protections
Palo Alto Networks customers are better protected from AMOS stealer and related threats through the following products and services:
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
We discovered the following five files during this AMOS stealer infection:
Initial Zsh script downloaded from a command run from the macOS Terminal window
As cloud environments expand to include human, machine and autonomous agent identities, mapping the functional roles of these identities has become a significant security challenge. To address this challenge, we designed a behavioral clustering model that extracts activity patterns from cloud audit logs. By adopting a clustering-based approach to identity mapping, organizations can gain greater visibility into cloud activity and integrate these behavioral patterns into automated threat detection mechanisms.
To create our behavioral clustering model, we examined the behavior of over 40,000 identities from 125 cloud environments over a two-month period, mapping these identities to functional roles. These roles include administrators, backup services, security tooling and development and operations (DevOps).
Identifying these functional roles is rarely straightforward because resource naming conventions or assigned identity and access management (IAM) policies do not always reveal an identity’s true behavior. Attackers routinely use masquerading techniques like pre-existing permission profiles and benign labels to make malicious activity harder to detect.
To illustrate the practical application of our model, we provide an in-depth analysis of the dataset's largest cluster: administrator console users in Amazon Web Services (AWS). We also show how an identity’s behavioral patterns provide richer context for cloud threat detection.
Additionally, we demonstrate how lightweight heuristic logic can be extracted directly from the clustering map, which can be implemented in standard SQL. This allows organizations to classify functional identity roles at scale, delivering continuous operational visibility without the need to continuously run a resource-intensive machine learning pipeline.
The methodology applied in our behavioral clustering model uses unsupervised machine learning algorithms, specifically Uniform Manifold Approximation and Projection (UMAP) and Hierarchical Density-Based Spatial Clustering of Applications with Noise (HDBSCAN), to construct a reliable behavioral map. This approach automatically categorizes a vast collection of cloud identities into distinct, clustered groups.
While our research specifically focuses on AWS CloudTrail data, the methodology can be easily extended to audit logs from other cloud providers, software as a service (SaaS), Kubernetes and other environments.
Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:
When it comes to accurately detecting malicious activity within cloud environments, context is key. Consider a scenario where a cloud identity enumerates all resources within your environment. Is this a security tool that frequently scans resources as part of its normal routine? Or is it a service identity that usually serves a limited purpose, such as a backup service that only interacts with a single cloud storage bucket? One of these scenarios represents normal operational activity, the other indicates a potential security breach.
This reality forces us to draw a distinction between capabilities and active behavior:
What an identity can do: Identity permissions dictate the operations that a role is permitted to perform. Although the industry-standard recommendation is to enforce the principle of least privilege, the reality is that many identities remain heavily over-privileged. This typically happens due to misconfigurations, a lack of visibility or simply a desire to reduce technical friction during rapid development. Attackers can exploit over-privileged identities to execute malicious operations that should have been blocked by tighter access controls. At the same time, many over-privileged identities exist in production for years without ever causing an issue. Security teams use cloud security posture management (CSPM) to audit assigned cloud permissions – but this is only part of the identity puzzle.
What an identity actually does: This lies within the domain of cloud detection and response (CDR). Analyzing the practical evidence of operations invoked by different identities is the main focus of this article. To do this we inspect observed API activity such as authentication (ConsoleLogin, GetSigninToken) and discovery (ListBuckets, ListRoles). To interact with the 240 services offered by AWS, there are more than 15,000 possible operations an identity can invoke.
Given that thousands of identities are operating across complex cloud environments, we are left with the following questions:
Are there common behavioral patterns that identities naturally follow?
How can we reliably differentiate between the footprints of various functional roles such as administrators, DevOps, backup services and security tools?
Mapping the Landscape: Functional Identity Roles
Analyzing the specific cloud operations an identity invokes, as captured in AWS CloudTrail, provides a clear picture of its day-to-day behavior and role. When observing a large enough collection of identities across multiple organizations, a macro-level picture begins to emerge.
A behavioral map visualizes each identity as a distinct data point, where its invoked operations dictate its coordinates. The scatter plot in Video 1 projects a vast array of AWS identities into a two-dimensional space based on their executed operations.
Video 1. AWS identity behavioral map.
In this simplified visualization, each dot represents a unique cloud identity, projected into a two-dimensional space where proximity reflects behavioral similarity and colors reflect behavioral clusters.
This map features the 30 largest clusters found in the dataset, representing approximately 20,000 identities. Due to a limited color palette, some colors are reused across the visualization; however, each spatially separated dense region represents its own isolated cluster.
The visual datapoint clustering, along with additional quantitative metrics, indicate that cloud identities have a strong tendency to share similar behavioral traits, often mapping to the same functional roles across different organizations.
Analytical Methods
To decode the functional role associated with each behavioral cluster, we combined four analytical methods:
Operation frequency: Analyzing the most frequent operations invoked within each cluster
Class-based scoring (c-TF-IDF): Using c-TF-IDF scoring to identify operations that distinguish one cluster from the rest
Attribute-based mapping: Highlighting various portions of the map based on specific operations, services and/or string matching
Identity naming patterns: Mining common substrings and naming conventions within each cluster
To illustrate these methods, we narrow our analysis to a well-isolated cluster shown in Video 2. Consisting of roughly 5,000 identities spanning over 100 cloud projects, it represents one of the largest, most dense clusters in our dataset: administrative user identities.
Video 2. Detailed view of the administrative identity cluster.
The clustering algorithm we use is hierarchical, allowing us to partition large clusters into distinct sub-behaviors. However, for the purposes of this research, we analyze the cluster at a macro level, focusing on identities operating through the AWS Management Console.
Operation Frequency
An analysis of the most frequent operations within this cluster revealed a defining characteristic: roughly 94% of the identities invoked ConsoleLogin, an AWS Management Console sign-in event, as Figure 1 shows. For comparison, fewer than 1% of identities in any other cluster performed this operation.
Figure 1. The most frequent cloud operations executed within the selected cluster.
We can also see that around 60% of the identities in the cluster invoke additional operations associated with the default AWS Console behavior, such as GetCostAndUsage and GetCostForecast.
Class-Based Scoring
To look beyond raw frequency and uncover the most distinguishing operations for this group, we examined the cluster using c-TF-IDF scoring, as illustrated in Figure 2. The APIs with the highest op_score serve as behavioral markers, occurring frequently within the selected cluster while remaining relatively rare across the rest of the global dataset.
Figure 2. Distinguishing operations of the selected cluster based on c-TF-IDF scores.
The scoring results show that operations that are automatically triggered when logging into the AWS console – such as ListNotificationHubs– receive higher scores than those based on raw frequency analysis.
Attribute-Based Mapping
To further validate the hypothesis that this is a cluster of administrative user identities, we also examined textual metadata. We looked at the entire clustering map and highlighted only the identities whose resource names contain the substring admin. In Video 3, the admin string shows a strong concentration within our selected target group.
Video 3. Global behavioral map, with identities containing the admin substring highlighted in orange.
In addition to highlighting portions of the map based on names, it is also possible to highlight them based on attributes such as specific invoked operations, usage of selected services such as S3, EC2 Lambda or any other measurable attribute.
Identity Naming Patterns
Mining common substrings from identity names provides additional context for cluster analysis. While relying on naming conventions of a single identity alone can generate inaccurate results, recurring patterns within a cluster help explain its underlying behavior. Using a Generalized Suffix Tree, we algorithmically discovered the cluster's most frequent substrings rather than searching for specific arbitrary keywords like “admin.” Among the top results was AWSReservedSSO_AdministratorAccess_ – the default prefix generated when assigning AdministratorAccess via AWS IAM Identity Center.
Landscape Mapping Summary
Combining these quantitative methods with visual mapping allows us to confidently conclude that this cluster indeed represents administrative users operating primarily through the AWS Management Console.
Repeating this profiling process across our dataset reveals clear, reproducible clusters for both human and machine identities, some of which shown in Figure 3. We were able to identify clusters based on behavioral patterns, including:
DevOps
Infrastructure as Code (IaaC) runners
Continuous integration and continuous delivery (CI/CD) systems
Security products
Backup agents
Networking components
FinOps platforms
Figure 3. Global behavioral map with identified clusters labeled.
Methodology: The Clustering Pipeline
To build this behavioral map, we constructed a multi-stage data pipeline, as illustrated in Figure 4. The pipeline consists of the following stages:
Cloud audit log ingestion
Pre-processing and vectorization
Dimensionality reduction
Clustering
Figure 4. The complete pipeline with its multiple stages.
The process begins by converting raw cloud audit logs into identity vectors that capture each identity's behavior and allow us to measure the distance between them. In this format, each identity is represented as a vector containing information about the specific operations it invoked.
By treating the set of possible operations as a “vocabulary,” we can represent each identity as a boolean vector where positions are marked true if the operation was invoked within the given timeframe. Because this vocabulary spans at least 15,000 possible operations — most of which are rarely invoked — the resulting vectors are both large (high-dimensionality) and sparse (mostly filled with zeros), making them challenging to process. Figure 5 shows the data format after this vectorization process, using test identities and data.
Figure 5. Sparse matrix representation of cloud identity behavior using boolean vectors.
We applied the Uniform Manifold Approximation and Projection (UMAP) algorithm to reduce high-dimensional data into a lower-dimensional space while preserving its essential structure. Considering our vector representation, we found that cosine similarity works well as the distance metric for UMAP, as it focuses on the angle between the vectors rather than their magnitude.
We ran this dimensionality reduction on the vectorized data, processing it in two parallel passes:
The first pass creates dense embeddings, which are lower-dimensional vectors for the clustering algorithm. This significantly reduces dimensions while preserving enough detail to maintain behavioral information.
The second pass compresses the original sparse vectors into a two-dimensional plot specifically for visualization, as shown in Figures 1, 2 and 5.
Figure 6 shows how the format and dimensionality of the data change after applying UMAP in the first pass. The initial large vectors consisting of over 10,000 boolean values are transformed into much smaller, dense vectors with 32 continuous values.
Figure 6. Illustration of the dimensionality reduction process.
Once every identity is assigned to a cluster, or labeled as an outlier, we can begin investigating the groups to understand their shared behaviors. This analysis focuses on their common traits and how to distinguish them from identities in other clusters. The resulting groups align closely with standard functional roles in cloud environments, such as Administration, DevOps, Security and CI/CD.
Automated Detection Mechanics
After discovering the behavioral groups using the above pipeline, we can scale this detection capability to ingest new identities and automatically determine whether they belong to a known cluster.
Instead of running the full pipeline, we train a classifier to evaluate cluster membership for groups of interest. For example, a dedicated classifier can be built to detect DevOps users, while a different classifier can detect security tools.
We found that a simple logistic regression model trained directly on the original sparse boolean vectors can accurately identify our clusters of choice. Unlike more complex machine learning models that often require additional tools to interpret outputs and decisions, the trained logistic regression model is highly interpretable. This enables us to observe the cloud operations required to infer cluster membership, along with their respective mathematical weights.
In practice, the model's inference logic calculates a weighted sum of the present operations. This means that we can determine how each cloud operation increases or decreases the likelihood that an identity belongs to a target cluster, and which operations are most important for prediction.
Because the vocabulary of possible operations is vast, assigning weights to thousands of mostly irrelevant operations would be unnecessary. To address this challenge, we used L1 regularization, also known as Lasso. This is a penalty that forces the model to reduce the coefficients of irrelevant features to absolute zero, compressing the model to focus exclusively on a small subset of critical, defining operations.
These steps result in a local approximation of our more complex clustering model. By training the classifier on specific groups, the model is essentially distilled into an indicative set of a few dozen operations paired with corresponding coefficients. This concise logic can be used to quickly infer whether an identity belongs to a DevOps, administrative or security product cluster.
Beyond being transparent and explainable, this lightweight logic is simple and efficient enough to be implemented directly within standard SQL queries. By adopting this lightweight approach, organizations can perform accurate role inference at scale, without relying on resource-intensive pipelines.
Conclusion
While posture management establishes the essential baseline of what an identity is permitted to do, analyzing its behavior reveals what it actually executes in production. Knowing the true functional baseline of an identity allows security teams to quickly spot deviations, flag defense evasion attempts and accelerate incident response.
By utilizing unsupervised machine learning algorithms like UMAP and HDBSCAN, we demonstrated that cloud identities naturally form distinct behavioral clusters. Rather than relying on static assigned permissions, these clusters accurately reflect an identity's true functional role within an environment — such as administrative access, CI/CD pipelines or security scanning services.
After establishing these behavioral clusters, we can efficiently map identities to their functional roles using lightweight logic distilled from our model. This logic can be implemented directly in standard SQL queries, enabling highly scalable identity classification across enterprise environments. This methodology can also be applied to audit logs from other sources of operational data, including different cloud providers, Kubernetes and SaaS.
Enriching standard telemetry with behavioral metadata adds an important layer of context, exposing high-risk anomalies that static analysis could miss, such as a compromised backup service suddenly executing administrative actions.
As cloud environments continue to grow in complexity, a context-aware approach serves as a robust blueprint for future detection strategies, offering a clear path toward more precise, efficient and proactive security operations.
Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:
Cortex Cloud can help protect cloud posture and runtime operations against identity-driven threats by pairing static permission baselines with deep behavioral context. By embedding the functional identity baselines discussed in this research into our detection engine, Cortex Cloud adds a vital layer of operational context, enabling security teams to filter out noisy false positives and decisively catch threat actors attempting to masquerade, alter configurations, or execute anomalous operations in the environment.
Cortex XDR and XSIAM are designed to prevent the execution of known malicious malware and prevent the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module.
Idira Privilege Access Management (PAM) can help unify privileged access across human, machine, and agentic identities to secure cloud access across multi-cloud environments. Building on proven PAM, it delivers centralized secrets management alongside modern controls like Just-in-Time access and Zero Standing Privileges. This enforces consistent least-privilege security across on-premises, cloud, and SaaS targets.
Idira Identity Governance and Administration (IGA) can help automate user access reviews and access provisioning, using AI Profiles to continuously define job-appropriate access rather than relying on static, hard-to-maintain roles. By analyzing entitlements at a granular level, Idira surfaces excessive privilege with less effort, enforces least privilege at scale, and provides the integrated governance foundation for Zero Standing Privilege across all identities.
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
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 research demonstrates post-exploitation techniques that could allow an attacker with root access on a compromised Kubernetes node to misuse an open standard and reference implementation for machine identity known as SPIFFE/SPIRE to impersonate co-located workloads and harvest SPIFFE Verifiable Identity Documents (SVIDs). We show how the trust assumption at the core of every machine-identity system — that the node is trusted — collapses once an attacker obtains root on that node. Unit 42 has not observed this technique exploited in the wild.
The Secure Production Identity Framework for Everyone (SPIFFE)/the SPIFFE Runtime Environment (SPIRE) is widely deployed in Kubernetes and cloud-native environments to replace long-lived secrets with short-lived, cryptographically verifiable workload identities.
Our research shows how an attacker with root can spoof the Linux control group (cgroup) information the SPIRE agent uses during workload attestation. This tricks the agent into issuing a co-located workload's SVID to an attacker-controlled process.
As part of this research, we developed Spooffe, an open-source tool that defenders can use to test whether an attacker with administrative access could manipulate cgroup metadata to retrieve co-located workload identities and assess the resulting identity area of impact.
When designing threat models for SPIFFE/SPIRE, organizations should assume that root-level access to a node grants access to all cryptographic identities scoped to it. We recommend performing the following activities to reduce exposure:
Harden nodes
Restrict root access
Prohibit privileged containers, host access
Minimize reliance on weak selectors
Palo Alto Networks customers are better protected from the threats described here through the following products and services:
SPIFFE is an open standard for machine identity designed to solve the “Secret Zero” problem — the challenge of securely introducing the initial secret required to bootstrap trust — by replacing long-lived secrets with short-lived workload identities. When deployed correctly, SPIFFE enforces strong identity boundaries between workloads.
However, these guarantees rely on a core assumption shared by all identity systems that the underlying node is trusted. If an attacker gains root access to a node, they can interact with identity mechanisms to retrieve all identities authorized to that compromised node.
Our research explores how attackers can exploit root access to harvest workload identities from a compromised node. In this post, we lay the groundwork by explaining machine identity and how SPIFFE establishes and verifies trust in cloud-native environments. We then demonstrate workload impersonation through selector spoofing. Finally, we introduce Spooffe, a tool we built to automate the extraction of these workload identities (SVIDs).
Consider a scenario where two applications, a frontend and a backend, must communicate securely.
We could generate key pairs and exchange public keys to communicate through Mutual Transport Layer Security (mTLS), but this option raises a few key questions:
Who rotates those keys?
Who revokes them if the app is compromised?
Can we verify who/what is presenting the keys?
SPIFFE addresses these issues by standardizing how machines are named and how short-lived credentials are issued.
The term machines refers to two broad categories:
Workloads: Containers, processes and services running application logic
Devices: Endpoints such as desktops, mobile devices and internet of things (IoT) or operational technology (OT) systems
(Note: Device identity is not part of the core SPIFFE specification)
SPIFFE Identity Components
Each workload is assigned three identity components:
SPIFFE ID: Who you are (your name)
SPIFFE Verifiable Identity (SVID): Proof that you are who you are claiming to be (your credentials)
Trust Bundle: How others verify that a trusted authority issued your credential
Let’s go into a little more detail about each of these.
SPIFFE ID is a canonical name for a workload identity that follows a URI-style format like spiffe://<trust-domain>/<path> (Figure 1).
Figure 1. SPIFFE ID.
The middle part (example[.]com) in Figure 1 is the trust domain, the issuer of identity that acts as a security boundary.
In this way, workloads can have an identity and know who to communicate with.
However, identity alone does not guarantee trust or security, so we add the SPIFFE Verifiable Identity Document (SVID). This is a short-lived credential that a workload presents to prove its identity. It is cryptographically signed by the certificate authority (CA) server and always includes the workload's SPIFFE ID.
SVIDs support two primary formats:
X.509 SVID: A certificate with an embedded public key, typically used for mTLS
JSON Web Token (JWT) SVID: A signed JWT token used as a bearer token for application-level authorization
Finally, we have the trust bundle, which is a set of trust anchors — root CA certificates or JSON Web Key Sets (JWKS). These are used to verify that a trusted authority issued an SVID within a trust domain.
To understand how these identity components are issued and verified in practice, we first need to look at the SPIRE architecture and its core runtime components.
SPIRE Architecture
SPIRE is a production-ready implementation of the SPIFFE specification. While several implementations exist, we chose SPIRE for this research because it is widely deployed in Kubernetes environments and fully implements the SPIFFE standard. Furthermore, because SPIRE is open source, we can inspect its internals to understand how the specification works in practice.
SPIRE is composed of a few simple pieces (as shown in Figure 2 below):
Figure 2. SPIFFE/SPIRE architecture.
Workload: A single piece of software deployed to do a specific job (e.g., a process, container, pod)
SPIRE Server (control plane): This is the CA that stores registration entries. It also issues and cryptographically signs SVIDs. Additionally, it publishes the trust bundle for the trust domain.
SPIRE Agent: This runs on every compute node (e.g., a Kubernetes node, VM or bare-metal host). It performs the following activities:
Accepts requests from workloads locally over the Workload API (UNIX socket)
Communicates with the server via the Node API
Performs attestation
Caches SVIDs
Handles rotation
Registration entries and selectors: These are server-side policy objects that define which workloads are allowed to receive which SPIFFE IDs. When a workload requests an identity, the SPIRE agent collects runtime attributes (selectors) about the workload and the server compares them against registration entries to determine which identity, if any, should be issued.
With the SPIRE architecture in mind, we can now walk through how workload-to-workload identity verification works end to end.
Workload-to-Workload Identity Verification Flow
When workload A needs to communicate with workload B over mTLS, it requests a short-lived credential from the local SPIRE agent. The agent attests the workload and forwards the attestation data to the SPIFFE server. Based on predefined registration policies, the server selects the appropriate SPIFFE ID for the workload and issues a short-lived X.509 SVID.
The server also publishes the corresponding public keys as part of the trust bundle.
When workload A initiates a connection, it presents its SVID during the mTLS handshake. Workload B verifies the SVID by validating the signature against the trust bundle, checking the certificate’s expiration, and confirming that the SPIFFE ID matches an expected identity.
If these checks succeed, workload B can cryptographically authenticate workload A and establish a secure connection. This enables workload-to-workload communication based on identity rather than long-lived secrets (Figure 3).
Figure 3. Workload communication.
The identity flow described above depends on attestation, the process by which SPIRE determines whether a workload is allowed to receive an identity. SPIRE performs attestation at two levels:
Node attestation establishes trust in the agent running on a node
Workload attestation determines the identity of individual workloads
In this post, we focus on workload attestation, as it is the mechanism directly involved in selector evaluation and the attacks discussed later.
Workload Attestation
Before the agent attests the workloads, the SPIRE server’s administrator must register the workload selectors in the SPIRE server so it can later compare them to the selectors in the agent.
In this Kubernetes example, the registration entry authorizes any pod running in the default namespace and using the default service account to receive the specified SPIFFE identity (spiffeID).
The resulting record is stored on the SPIRE server as follows:
Shell
1
2
3
4
5
6
7
8
9
10
$kubectl exec-nspire spire-server-0--/opt/spire/bin/spire-server entry show
The SPIRE agent periodically synchronizes and caches these registration entries from the server, using them locally during workload attestation to determine which identity applies. The agent generates key pairs for each registration entry, sends certificate signing requests (CSRs) to the server and caches the resulting SVIDs.
When a workload wants to authenticate, it requests an identity from the agent over the Workload API (Figure 4, step 1). The agent performs workload attestation (Figure 4, step 2) by gathering selectors from the workload process and matching them against cached registration entries.
Upon a successful match (Figure 4, step 3), the agent returns:
X.509 SVID
Private key
Trust bundle
Note: This example is based on an X.509 SVID request. For JWT SVID requests, the agent returns only a signed JWT token.
Figure 4. Workload attestation.
With the high-level flow in mind, we can now examine how attestation works in practice.
How the Agent Attests the Workload
When a workload requests an SVID (via FetchJWTSVID or FetchX509SVID), it connects to the agent Workload API, typically via a Unix domain socket (such as /run/spire/sockets/agent.sock). The agent then extracts the PID for the calling process.
Once the agent receives the PID, it passes it to the configured workload attestor plugins, which collect selectors based on process and container metadata. SPIRE agents support several workload-attestor plugins. Common plugins include docker, k8s, systemd, Unix and Windows. In our cluster, the agent uses the k8s and Unix plugins.
Kubernetes Plugin (k8s)
The k8s plugin uses the workload PID to access /proc/<pid>/mountinfo or /proc/<pid>/cgroups. It calls GetPodUIDAndContainerID to extract the pod UID and the container ID. In our environment, this process looks like the following:
After extracting the container ID and pod UID, the k8s plugin queries the kubelet to retrieve pod metadata. To do this, it uses the SPIRE agent’s service account token, stored at /var/run/secrets/kubernetes.io/serviceaccount/token.
The agent's service account has the following permissions, which allow it to list pods and access node information:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
kind:ClusterRole
metadata:
...
name:spire-agent-cluster-role
...
rules:
-apiGroups:
-""
resources:
-pods
-nodes
-nodes/proxy
verbs:
-get
Using this token, the plugin calls getPodList to retrieve all pods on the node. It then identifies the pod whose UID and container ID match the values extracted from the /proc directory. Once matched, it collects selectors from the pod's metadata:
The Unix plugin gathers information from /proc to produce selectors such as user identifier (UID) and group identifier (GID). These selectors are used during workload attestation to bind a workload’s identity to operating system level properties of the calling process, helping SPIRE distinguish between different workloads running on the same node.
The agent combines these selectors from both the k8s and Unix plugins. It then matches this selector set against the locally cached registration entries. If an entry's selectors are a subset of the workload's selectors, the agent returns the corresponding cached SVID to the workload.
Workload Impersonation: Selector Spoofing via Cgroup
This attack requires root-level access to the node. Our analysis revealed that workload attestation relies heavily on the workload’s cgroup path. An attacker with root access on the node can manipulate this cgroup path, potentially tricking the agent into believing the attestation claims belong to a different workload and obtain that workload’s identity. This could allow the attacker to impersonate the victim workload and access any services or resources trusted under that identity.
As a first step, we created a registration entry for a pod named workload-a in the server and we verified that we could fetch its identity from the pod:
Notably, writing the PID directly into the original cgroup path would have also worked. We used a separate cgroup only to avoid modifying the original workload’s runtime state.
Running the fetch command again successfully retrieved the identity associated with PID 9072:
We can also see the workload-a SPIFFE ID inside the JWT token:
Shell
1
"sub":"spiffe://example.org/ns/a/sa/a"
The manual spoofing demonstration highlights that the security model relies entirely on a single, vulnerable assumption of node integrity. When we have root access, we can get the identity of any workload on the node.
This manual spoofing demonstration highlights a critical trust assumption in workload attestation. When an attacker has root-level access to a node, they can manipulate cgroup information to cause the SPIRE agent to misattribute workload identities. Under these conditions, the attacker can impersonate other workloads running on the same node and obtain their identities.
Spooffe
These findings motivated us to develop Spooffe, a tool that allows defenders to automate selector spoofing to retrieve all the workload identities from the node.
Spooffe scans the node for running workloads, discovers their cgroup paths, and replicates them as a mock cgroup for its own process. It then queries the local SPIRE agent for the resulting identities (SVIDs), allowing us to collect all workload identities present on the host (Figure 5).
Figure 5: Dumping all workloads' identities (SVIDs).
Besides selector spoofing, Spooffe includes additional capabilities. However, in this post we focus only on the features relevant to this research.
One such capability is agent impersonation, which examines whether an attacker can impersonate the SPIRE agent and communicate directly with the server to extract workload identities.
Conclusion
In this article, we demonstrated how an attacker with root access on a compromised node can misuse SPIFFE/SPIRE workload attestation to impersonate co-located workloads and retrieve their identities. By manipulating cgroup metadata, we showed how attackers could mislead the SPIRE agent into issuing valid SVIDs to an attacker-controlled process. We also introduced Spooffe, a tool that automates this technique to enumerate and extract workload identities from a node.
These findings highlight a fundamental assumption in workload identity systems: trust in the underlying node. While SPIFFE/SPIRE enforces strong cryptographic identity guarantees between workloads, those guarantees rely on the integrity of the environment where attestation occurs. Once that trust boundary is broken, identity isolation between workloads collapses, allowing attackers to move laterally using legitimate credentials rather than stolen secrets.
Organizations adopting workload identity should treat node-level compromise as equivalent to compromise of all identities scoped to that node. To reduce risk, restrict privileged containers, limit direct host access and minimize reliance on weak or easily spoofable selectors.
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.
Palo Alto Networks Product Protections
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
Cortex XDR and XSIAM can help protect against post-exploitation activities using the multi-layer protection approach. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection, and Endpoint Protection Modules (EPM).
Cortex Cloud Identity Threat Detection can help deliver end-to-end visibility across cloud providers and IdPs by baselining real-time access patterns. By continuously monitoring these behaviors, ITDR detects identity abuse and compromised credentials targeting critical cloud resources and Kubernetes workloads, automatically triggering containment actions to keep attackers out.
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)
A recent Unit 42 investigation into seemingly low-priority enterprise infections demonstrates how the most effective camouflage in cybercrime is not necessarily in the use of sophisticated techniques, but in how unremarkable the threat appears. The activities that we investigated would typically not require escalation or further inquiry. But upon closer inspection, we discovered a massive cybercrime campaign largely targeting young gamers. Tracked as CL-CRI-1171, in accordance with Unit 42’s attribution framework, the group behind this cluster has operated under the radar for at least two years, distributing an indeterminate number of payloads.
The group behind CL-CRI-1171 provides an infection service for other threat actors who want to spread their malware indiscriminately. This pay-per-install (PPI) marketplace drove hundreds of infections through YouTube channels and a parallel search engine optimization (SEO)-poisoning funnel, all using the same custom loader.
We observed at least eleven YouTube channels that had hundreds of thousands of followers. We notified YouTube of these channels, which it promptly terminated.
These channels were actively interacting with viewers to promote gaming content laced with links to download malware. Content in the channels included advice on improving frame rates, fixing game crashes and adjusting settings on game platforms. Although the videos provided real content for gamers, they also served as the delivery vehicle for infection, prompting viewers to download malicious tools.
The SEO funnel targeted a more professional audience, promoting trojanized software that resulted in malware deployment on corporate endpoints, including critical infrastructure and even government entities. We identified three independent payloads delivered by the same loader between July 2025 and April 2026: two never publicly reported, Docro Hijacker and ARKTunnel, and a new variant of a previously unnamed backdoor, which we dubbed Insomnia remote access Trojan (RAT).
These infections represent only a small sample of a much larger deployment campaign. We have identified more than 10,000 distinct loader samples, each capable of delivering unique payload combinations.
We provide an overview of the cybercrime cluster and its loader infrastructure, and a technical analysis of three recently delivered malware strains.
Palo Alto Networks customers are better protected from the threats discussed in this article through the following:
Our discovery of two separate infections delivering three entirely distinct malware families revealed one common denominator: a shared loader. By tracing this infrastructure, we mapped the broader activity of CL-CRI-1171, ultimately tying the cluster to a PPI marketplace responsible for delivering countless payloads over the last two years.
This operation uses at least two funneling mechanisms to route traffic to the malware landing pages: a network of YouTube channels and SEO poisoning. The shared infrastructure between the YouTube and SEO funnels, consistent use of the same loader and a rotational domain pattern observed over an eight-month window all pointed to a single sustained operation, which we track as CL-CRI-1171.
The PPI Ecosystem: An Infection Marketplace
PPI networks operate as underground marketplaces. An operator compromises machines and auctions access to multiple buyers, each buyer deploying their own independent payloads through the same dropper. The result is a single infection that conceals multiple payloads from unrelated threat actors on the same endpoint, each with its own C2 infrastructure and objectives. Because the loader is designed to be disposable and generic, it rarely attracts the scrutiny needed to uncover its subsequent payloads.
Tracking CL-CRI-1171: The PPI Operation Behind the Payloads
The investigation began with two identical and seemingly routine infections at separate organizations. Both events involved trojanized software downloads — one a Bluetooth driver, the other WinDirStat — and both affected machines executed an identical post-exploitation chain. The loader was unnamed, untracked and generic enough to be dismissed as commodity adware.
But our discovery of a shared payload chain raised a question. How were two unrelated organizations infected by the same unnamed loader delivering the same set of payloads, just one week apart?
Pivoting on the loader's C2 infrastructure revealed a sprawling network of rotational domains — over 200 unique hostnames following a distinctive two-word compound naming pattern (including bubbleslip, churchpail, dinosaursjam), rotating across .xyz, .cfd, .space and .info top-level domains (TLDs).
Unpacking the Delivery Infrastructure
The payloads delivered through CL-CRI-1171's infrastructure are not fixed, enabling the simultaneous delivery of unrelated malware families. In April 2026, two incidents initiated this investigation. They shared a single loader that delivered three separate malware families: Insomnia RAT, ARKTunnel and Docro Hijacker. A subsequent infection, observed in June 2026, delivered two entirely different payloads: GCleaner and Socks5Systemz.
Figure 1 illustrates the structure of the operational architecture and the observed rotational malware bundles.
Figure 1. Illustration of CL-CRI-1171 infrastructure.
Our in-depth analysis explores three operations that were spotted in two intrusion sets during April 2026. By examining the campaign’s trackers, we found that these operation payloads were in rotation from July 2025 to April 2026. This discovery provides a valuable snapshot of the group’s deployment capabilities and the variety of payloads they have been entrusted to deliver.
Although the observed rotation appears to be highly structured, the discovery of over 10,000 unique OfferLoader samples points to a much larger distribution pipeline. It is very likely that the loader has delivered numerous other malware families.
The SEO poisoning path was the first delivery channel we identified. Unsuspecting users searching for legitimate software landed on file-hosting lure pages that displayed a fake virus-scan animation before delivering the trojanized archive via a chain of redirectors into the PPI gate.
A reconstructed example download page from the SEO poisoning funnel is shown in Figure 2.
Figure 2. Reconstruction of the trojanized WinDirStat download page.
Analysis of the gate's tracker URLs revealed a critical detail. Each URL contained a click_id parameter: a Base64-encoded fingerprint containing the victim's operating system (OS), browser, the referring domain, the exact search keyword that led them to the lure and their public IP address, as Table 1 shows.
Operating System
Browser
Referring SEO Domain
Search Keyword
Victim IP
Windows_10
Chrome
atthelake[.]info
hwidspoofer
5.xxx.xx.xxx
Windows_10
Chrome
atthelake[.]info
combatwarriorsGit
2.xx.xxx.xx
Table 1. Example of a deobfuscated click_id.
The gate uses this fingerprint to decide who receives the payload: a valid, fresh click_id forwards the visitor to the malware/loader download. This is an evasion tactic used to ensure that only real targets are infected, and to protect the actor’s infrastructure: scanners, crawlers or analysts receive a decoy clone of the legitimate WinRAR download page or broken links. This is why the campaign has almost no public footprint despite being highly active: automated URL scanners rarely pass the gate.
Decoding hundreds of these fingerprints, with the assistance of AI, exposed the full names of YouTube video titles and their associated channels. Alongside search keywords for cracked software and game cheats, the q= field – which tracks which search query led to the infection – contained strings like "CS2 Potato Graphics Settings - Maximum FPS Boost for Low-End PC (2026 Guide) - Velvox."
The YouTube Funnel
Searching for titles derived from the fingerprints led us to uncover a chain of gaming optimization YouTube channels. Their content included tips on boosting frames per second (FPS), fixing game crashes and tweaking settings on popular game platforms. While the videos provided authentic, engaging content for young gamers, they ultimately served as an infection delivery vehicle, prompting viewers to download a malicious “tool” or “optimization pack” via links in the description, as Figure 3 shows.
Figure 3. A YouTube video from the ADEX channel directing viewers to a download link.
Those links pass through intermediary sites, such as Blogspot, which contain social-engineering instructions that lead the victim to the same PPI gate infrastructure serving the SEO path. An example blog page is shown in Figure 4.
Figure 4. The download link leads to a Blogspot page.
We identified 11 channels connected to CL-CRI-1171, which collectively had hundreds of thousands of subscribers and millions of views.
Technical Analysis
Our investigation revealed three malware strains delivered by the group behind CL-CRI-1171 between June 2025 and April 2026. The following sections explain the technical aspects of the loader used by this cybercrime group and the deployed malware payloads:
OfferLoader – The delivery mechanism behind all recorded intrusions, an Inno Setup trojanized installer that sets up the other payloads.
Operation A: Insomnia RAT – A dual-payload, cross-platform backdoor that brings its own environment to ensure survival. Targeting both Windows and macOS using Node.js, paired with a twin Python agent.
Operation B: ARKTunnel – A previously unreported WebSocket tunneling RAT unpacks itself from a bitmap image using steganography. We found 50 samples spanning over a year of development, operating across four fictitious corporate-identity rotations.
Operation C: Docro Hijacker – A Chrome backdoor that revives a browser-hijacking technique first seen in 2015, re-engineered to bypass modern integrity protections. This campaign represents the first observation of this modern variant in the wild.
Initial Access Vector in Intrusions
We discovered two intrusion sets that began in the same way: a user searched for a legitimate utility, clicked a top search result that led to a malicious domain, and downloaded what appeared to be a legitimate application. Both infections delivered the same three payloads.
First intrusion set: Downloaded Bluetooth Driver for Windows 10.exe from a file-sharing archive. The installer was a trojanized Inno Setup package carrying the PPI loader with affiliate ID CID=2855.
Second intrusion set: Browsed to noiseship[.]cfd, a domain registered just 39 days earlier, and downloaded a trojanized windirstat.exe installer. This package carried the PPI loader with affiliate ID CID=3075.
The OfferLoader Execution Chain
The operator's code and C2 communication designate each payload slot as an "offer," tracking variables as offer_execution, offer_execution_fail and offer_exists. Based on the naming convention, we track this loader as OfferLoader. OfferLoader uses chained Inno Setup (a legitimate installation packager) packages to deliver multiple payloads. Figure 5 shows the infection chain.
Figure 5. Cortex XSIAM view of the infection chain. In this case, Advanced WildFire blocked the payloads.
OfferLoader is delivered in a ZIP file, with the source download site providing the social engineering instructions required to guide users through downloading and executing an extraction tool. Based on our analysis of the collected samples, we observed the loader being delivered alongside a legitimate version of WinRAR, renamed to .store. The installer contains no embedded application files; all malicious logic is contained in the compiled Pascal [Code] section, which triggers when the installation page is displayed.
In two separate intrusion sets we discovered that the ZIP file contained OfferLoader masquerading as a windirstat.exe installer that initiates the compromise by unpacking windirstat.tmp. This temporary file transmits an initial tracking beacon to voyagemist[.]space. This is another gating mechanism: depending on the structure of the beacon, one of two text files will be retrieved. They either contain “no” to signal that the loader should not unpack further stages, or “ok” to signal all offers will be deployed. Following this check-in, the process spawns three child processes: eld0.exe, eld1.exe and eld2.exe. Each child process corresponds to a different malware campaign. The loader passes specific affiliate-tracking parameters to each process via a command line.
Figure 6 illustrates the entire OfferLoader infection chain at the time of the intrusion.
Figure 6. Example of an OfferLoader infection chain.
OfferLoader's role ends once the three offers are spawned. From this point forward, each child process operates as an independent malware campaign with its own infrastructure, C2 protocol and objectives. The following sections analyze what each offer delivers.
Operation A: Insomnia RAT – A Cross-Platform Backdoor
Insomnia RAT simultaneously distributes two payloads:
An upgraded variant of a Node.js backdoor (reported by Walmart Global Tech in 2025)
A complementary Python backdoor
We have dubbed these twin payloads Insomnia RAT, due to the user-agent string used for C2 communications: insomnia/2023.4.0 Windows.
Figure 7 shows the full infection chain that delivers Insomnia RAT’s twin payloads.
Figure 7. The new Insomnia RAT variant infection chain.
Eld0.exe drops the a.dll payload and spawns a hidden PowerShell process to download and execute t.ps1. This double-stage installer script disables Windows Defender protections, adds the entire C:\ drive as an exclusion, suppresses security notifications and deploys the two Insomnia RAT backdoors. t.ps1 also downloads and sets up the environment needed to execute both backdoors by installing Python and Node.js on the victim’s machine. Node.js is hidden from the system's Add/Remove Programs list by setting SystemComponent=1 in the registry.
The first part of Insomnia RAT is a Node.js agent downloaded from stryper[.]info/aa.js. While the prior variant targeted Windows, Linux and FreeBSD with a single payload, this iteration targets Windows and macOS using platform-specific C2 server lists. It also deploys a companion Python agent as a redundant fallback, ensuring persistent access if one runtime environment is detected or removed.
The backdoor collects the victim's MachineGuid, universally unique identifier (UUID), hostname and operating system details. It then contacts its C2 servers via an HTTPS POST request to /d using a User-Agent string, insomnia/2023.4.0 Windows to disguise itself. The C2 server responds with a JSON array containing commands. These specify a payload type (node, cmd, ps1, sh, or ow for a self-update) and a download URL. Results are reported back to the /e endpoint.
To establish persistence, the installer registers a scheduled task named Maps Performance Task under \Microsoft\Windows\Maps\. This mimics a legitimate Windows task, executing the backdoor hourly and at system startup under the SYSTEM account.
The same t.ps1 script installs a second, redundant agent. This Python script is downloaded from aa.amazingshield[.]xyz. The installer downloads a legitimate Python distribution and registers a second scheduled task, OOBETaskScheduler, under \Microsoft\Windows\Servicing\.
The Python agent is simpler than its Node.js sibling, but follows the same C2 protocol pattern: POST requests to /d for tasks and POST requests to /e for error reporting. The agent collects the MachineGuid, OS product name, hostname and processor architecture.
The Python agent used crowdstri[.]com as its C2 domain. This appears to be a deliberate typosquat of crowdstrike[.]com, designed to blend into logs and evade quick security reviews.
Operation B: ARKTunnel – A WebSocket RAT Hidden in a Bitmap
The eld1.exe chain terminates in a previously undocumented tunnel payload. The chain uses least-significant-bit (LSB) steganography to deploy the final payload. Figure 8 shows the full infection chain of Operation B.
Figure 8. The ARKTunnel infection chain.
Rather than dropping an executable directly to disk, eld1.exe extracts a ZIP archive from a BMP image resource using LSB steganography. The result is the payload archive, ProcorTrex.zip, which contains wscl.exe, a previously unreported WebSocket-based tunneling RAT. We named this RAT ARKTunnel, based on the attacker's fabricated company name rotation of EarthKark and TamarkLark.
ARKTunnel installs itself as a Windows service named wscl-13 or msvcsrvc with a delayed autostart configuration. The RAT supports TCP and UDP tunneling, as well as file execution.
The C2 server address, reg.pcsdkflyer[.]ca, is decoded from a 39-byte configuration blob using Base64-decoding followed by an XOR decryption routine. The portable executable (PE) metadata of wscl.exe contains a fabricated company name, TamarkLark Corporation, and a fictitious product name, TamarkLark Manager, which led us to suspect that other ARKTunnel samples might use additional fabricated company names.
The investigation revealed at least 50 samples deployed over the course of a year. The developer rotated through at least two fake company identities while maintaining an identical icon, binary structure and deployment pattern:
EarthLink in May 2025: EarthLink is the name of a legitimate internet provider, however the attackers used this name coincidentally in the file version information. The attackers did not use or impersonate EarthLink resources or identity.
EarthChain from May 2025–April 2026: EarthChain is also real company name that the attackers used coincidentally. Likewise, also they did not use or impersonate the company’s resources or identity.
EarthKark: A fake identity, used from February 2026–June 2026
TamarkLark: A fake identity, used from March 2026–June 2026
All of the samples share the same wscl.exe filename pattern and GUID-based temp directory extraction pattern, indicating that they are variants of the same family.
Despite 50 samples spanning a full year of development and four identity rotations, ARKTunnel has attracted no public reporting or dedicated tracking, with each sample individually flagged as a generic Trojan rather than recognized as a tunneling implant.
Operation C: Docro Hijacker – Reviving Old Techniques
The eld2.exe payload installs a Chrome browser hijacker that we have named Docro Hijacker. The hijacker revives a browser-hijacking technique that has resurfaced periodically since 2015, now re-engineered to bypass updates to Chrome's integrity protections. While this iteration closely mirrors a proof-of-concept detailed by Synacktiv in 2025, this campaign marks the updated technique’s first documented instance of in-the-wild deployment.
Figure 9 shows the Docro Hijacker installation chain.
Figure 9. The Docro Hijacker infection chain.
eld2.exe is an Inno Setup package, and much like its loader, it extracts and runs eld2.tmp which contacts the affiliate’s extentrack[.]com install tracker.
eld2.tmp drops and loads Adblock.dll, which bypasses Chrome's Secure Preferences HMAC-SHA256 integrity check. The DLL extracts Chrome's HMAC key from resources.pak, computes valid HMAC signatures for the modified preference values and writes them directly to the Secure Preferences file. This file functions as an anti-tamper mechanism for browsers by storing a validated copy of the user's settings.
This manipulation allows the malware to execute two primary actions:
Search hijacking: Changes the default search provider to mqsearch[.]com, a domain that masquerades as a search engine
Extension installation: Installs the docro extension, a Chrome Manifest V3 extension located at C:\ProgramData\DocsHelper\docro\
The docro extension uses Chrome's declarativeNetRequest API to dynamically rewrite network requests. Upon installation, it contacts vendralo[.]info to retrieve a unique per-victim UUID and fetch a set of network rewriting rules that are refreshed hourly.
These rules are used to hijack and monetize search results in the victim's browser. When the victim performs an internet search, across any of more than 190 Google country-code domains, the extension loads a script from drelto[.]info/farlix into the search results page. Because the script runs within the search engine's own origin context, it has full access to the page content. This enables the operator to inject advertisements into organic search results, rewrite affiliate links to capture referral revenue and/or redirect clicks to attacker-controlled destinations. These actions are functionally transparent to the user and visually indistinguishable from the legitimate search page.
The extension also checks vendralo[.]info for updates via /extensionInstaller/updateChromeExtension, allowing the operator to silently rotate to a new extension version at any time. Install telemetry is reported to finersto[.]com and extentrack[.]com.
With more than 50 unique samples contacting mqsearch[.]com according to VirusTotal, Docro Hijacker appears to be a mature, independent monetization module.
Conclusion
The actors behind CL-CRI-1171 did not use sophisticated evasion techniques, but focused their efforts on building a loader that is exceptionally difficult to track due to its clever gating mechanisms.
Our investigation highlights how the authors of OfferLoader, by being intentional about its simplicity and by hiding all of its functions as bytecode within a package, designed the malware to evade scrutiny while quietly building a massive, mature infection funnel.
Although OfferLoader was easy for defenders and security products to miss, its gating mechanisms were not, and the sheer number of them was our first clue that more widespread activity was occurring.
While a loader that just drops a payload is seemingly routine, this mechanism allowed possibly thousands of rotational malware bundles, including entirely new and undocumented malware families, to remain hidden from standard security attention. Ultimately, this case serves as a critical reminder for defenders: Treating commodity loader infections as minor, routine events overlooks the dangerous payloads and campaigns that might be tied to them.
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected against the threats described in this report through the following products and services:
The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research. Through continuous cloud-based analysis, Advanced WildFire is designed to proactively identify and block OfferLoader samples as well as downstream payloads, including Insomnia RAT, ARKTunnel, and Docro Hijacker.
Cortex XDR and XSIAM can help detect and prevent the OfferLoader chain and all three payload branches described in this article. Cortex customers benefit from multiple layers of protection against this threat, including:
YARA-based signatures targeting the OfferLoader family and its staged payloads
Behavioral detection rules that help prevent:
Malicious Chrome extension setup
Untrusted service installations used for persistence
Trojanized installer execution patterns
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.
SHA256 hash: 9b0d9cbc0fd4a7bae8b78a15dfbe63052779414ad725845732c4a0083008da69
File name: a.dll
File type: PE32 DLL
File description: Executes the PowerShell downloader for the Node.js and Python second stages
SHA256 hash: cf184d04ca31fb2b6b7efd85399c29c1136b539153e137ceb3877b1b905791de
File name: <guid>.py
File type: Python script
File description: the Python-based component of the Insomnia RAT dual payload.
SHA256 hash: 62d49d0c78207ec2452cc8a30501db771c9edbae89889e41a7dd227551243e8e
File name: aa.js
File type: JavaScript
File description: the Node.js-based component of the Insomnia RAT dual payload.
URL: hxxps[:]//stryper[.]info/t.ps1
Description: Stage-2 PowerShell installer for the Node.js and Python agents
Domain: crowdstri[.]com
Description: CrowdStrike-typosquat C2 for the Python agent
Operation B: ARKTunnel
SHA256 hash: aaebc8c07de485be6d1bfa956668c5e18aa1ff5588dfe84672e20ae90b4560f1
File name: eld1.exe
File type: PE32 executable
File description: LSB-steganography dropper. The attacker forged the PE version-info resource to mimic a popular test proctoring application.
SHA256 hash: e05bc22afbc5ddd50b49c85ee169dd13318000d38286de2b8bcff98217256a8d File size: 92,657 bytes
File name: procorTrex.zip
File location: C:\Users\Public\procorTrex.zip
File type: ZIP archive
File description: ZIP carved from the eld1.exe BMP steganography payload
Domain: mqsearch[.]com
Description: Hijacked the default search provider endpoint
Domain: extentrack[.]com
Description: Docs Helper install-success and install-failure callback
CL-CRI-1171 Rotational Infrastructure
Initial-Access Lure and SEO File-Locker Hosts
Domain
Role
noiseship[.]cfd
SEO-poison domain
atthelake[.]info
Top referring SEO-poison domain
uy.basesfiles[.]com
Fake file host
basesfile[.]com
Sibling fake file host
igk.filexspace[.]com ikx.filexspace[.]com
SEO file-locker lure hosts
filexstorage[.]site
SEO file-locker lure host
filescloud[.]pro
SEO file-locker lure host
zippyfiles[.]net
SEO file-locker lure host
mifilesx[.]site
SEO file-locker lure host
dw.xrsdownload[.]com
SEO file-locker lure host
storage.ggclicker[.]com
SEO file-locker / referrer host
watchadvance[.]com
SEO-poisoning domain
Domains Used to Confirm OfferLoader Installations
Domain:
animalview[.]xyz
trickflag[.]info
suitstraw[.]info
connect.fuelleg[.]info
vesselsystem[.]xyz
minewave[.]info
collartitle[.]info
boardmagic[.]info
placespoon[.]xyz
needcherries[.]online
Payload-Handoff and Second-Stage Hosts
Install-Tracker Beacons (Operator Panel)
Domain
Role
voyagemist[.]space
PPI affiliate install tracker
statementtouch[.]xyz
PPI affiliate install tracker
chawton[.]info
PPI affiliate install tracker
YouTube Funnel – Burner Blogs and Custom-Domain Sites
Domain Name
Persona
Type
velfps.blogspot[.]com
Velvox
Blogspot burner
velvoxlab.blogspot[.]com
Velvox
Blogspot burner
venrx.blogspot[.]com
Venrx
Blogspot burner
venrxhub.blogspot[.]com
Venrx
Blogspot burner
venrx[.]xyz
Venrx
Custom-domain burner
ravexoffical.blogspot[.]com
Ravex
Blogspot burner
adex-blog.blogspot[.]com
Adex
Blogspot burner
Please note: While Velvox is a real company, the attackers used its name coincidentally. They did not use or impersonate the company’s resources or identity.
We have analyzed two ongoing, multi-stage network intrusion and data-exfiltration campaigns targeting organizations in Latin America. Corroborating recent findings from the broader threat intelligence community, we observed attackers leveraging artificial intelligence (AI) to enhance their capabilities.
Our investigation categorizes this activity as follows:
Mexican transportation campaign: This campaign impacted a transportation organization, alongside federal government ministries and municipal water utilities in Mexico and Ecuador. Operators relied on living-off-the-land (LotL) techniques. They executed iterative batch scripts to manipulate and exfiltrate sensitive data, and self-hosted NextChat instances on operational infrastructure. We track the activity in this cluster as CL-CRI-1131.
Brazilian financial campaign: Attackers targeted the Brazilian financial sector. We observed an expansion of previously reported targeting of vulnerable web servers in a job-themed phishing campaign. The attackers employed custom remote access Trojans (RATs) and tunneling tools, including a Go-based SOCKS5 proxy with iterative filenames that suggest AI-enablement. We track the activity in this cluster as CL-CRI-1163.
We track them as two separate activity clusters with distinct geographic focuses. However, the technical and behavioral overlaps between CL-CRI-1131 and CL-CRI-1163 highlight shifting trends in Latin American targeting and threat actor tooling.
Both clusters have overlapping SOCKS5 relay infrastructure and they both rely on AI to orchestrate operations via commercial large language models (LLMs). This signals a broader evolution in the regional threat landscape. Rather than isolated incidents, these clusters demonstrate how diverse threat groups in Latin America are independently adopting advanced proxy networks and AI integration to streamline their execution.
Palo Alto Networks customers are better protected from the threats discussed here through the following products and services:
During an April 2026 compromise, the attacker’s host-based operations reflected the trial and error of LLM usage. Infrastructure associated with the campaign persisted into June 2026 and exposed targeting profiles of the attacker.
During an intrusion as part of CL-CRI-1131 activity in April 2026, we observed the attacker struggling to gather sensitive data. After repeated attempts to dump the Security Account Manager (SAM) registry hive and the domain controller NTDS.dit file, the attacker created shadow copies across multiple drives before copying files, as shown in Figure 1.
Figure 1. Volume shadow copy manipulation.
This occurred while the attacker used a series of numbered batch scripts to collect sensitive data from the compromised host, as shown in Figure 2.
Figure 2. Commands used for a series of batch scripts to collect sensitive data.
The attackers inserted a permissions check to ensure successful file writing to the collection directory. These trial-and-error actions and successive script fixes are consistent with LLM usage.
After struggling to collect these files, we observed attackers troubleshooting connectivity with infrastructure at 62.171.185[.]97.
Infrastructure Analysis: Tracing Exfiltration Commands to Exposed Certificates
Pivoting on 62.171.185[.]97, the IP address used in CL-CRI-1131 activity for data exfiltration, we discovered an active Let's Encrypt TLS certificate using the domain m-doxa-apodo.duckdns[.]org and following a unique dynamic DNS naming standard.
Shared Infrastructure: What the SSL Certificates Revealed
Searching for the m-doxa prefix revealed that attackers established the infrastructure for the campaign in February 2026 using a single, consolidated multi-Subject Alternative Name (SAN) certificate. This single certificate reveals five active subdomains. These subdomain names indicate their operational functions and intended Mexican federal government targets, as Table 1 shows.
Subdomain
Interpretation
m-doxa-apodo.duckdns[.]org
apodo = alias/nickname (Spanish)
m-doxa-geo.duckdns[.]org
geo for geolocation
m-doxa-intel.duckdns[.]org
intel for intelligence
m-doxa-vacunas.duckdns[.]org
vacunas = vaccines (Spanish)
Table 1. Subdomains and their likely operational capabilities and targets.
In February 2026, following the initial window of activity reported by CloudSEK, attackers deployed a single-SAN certificate during this campaign. The certificate was configured to secure only one specific domain: m-doxa-apodo. However, as the operation evolved, so did the infrastructure.
By April 2026, and again in June 2026, attackers rotated their infrastructure and generated new multi-SAN certificates.
Table 2 shows, by date, the certificates and hosts used for CL-CRI-1131 activity, demonstrating a timeline for the associated infrastructure.
These reports describe attackers using multiple LLMs, including Claude and GPT-4.1 to troubleshoot issues faced by the attackers across their campaigns. We discuss the attackers using NextChat as part of their broader LLM process.
The IP address 178.128.87[.]160 was used in CL-CRI-1131 activity during the associated April and June 2026 compromises. This address hosted an instance of the open-source tool NextChat on TCP port 3000. Figure 3 shows an example of the associated NextChat user interface, as it would look from a web browser window.
Figure 3. Example of a locally hosted NextChat window.
NextChat is an open-source web interface where users can load and interact with multiple models. NextChat allows operators to compare across models and ensure prompts are hosted on attacker-controlled infrastructure.
Beyond revealing new targets, tracking this infrastructure provided a critical window into the activity cluster's backend operations. Given the initial failures to extract data from the host combined with the NextChat interface on this backend, we assess that the attackers relied on LLMs to generate the required workaround scripts.
Integrating AI into the operational infrastructure is not unique to this incident. We observe an identical technical setup when pivoting to a secondary campaign targeting the Brazilian financial sector.
CL-CRI-1163: Brazilian Financial Service Campaign
Unlike the Mexican transportation campaign, the Brazilian financial campaign we track as CL-CRI-1163 involved homebrewed malware. We observed that the attackers behind CL-CRI-1163 likely gained initial access through a job-themed phishing compromise.
Despite trading built-in Windows utilities for custom-built implants, the underlying operational shift remains consistent in both campaigns. Exposed staging infrastructure revealed operational scripts with filenames that suggest an LLM dynamically generated them rather than a human developer.
The apparent presence of this AI setup, deployed alongside advanced proxy networks, reinforces the conclusion of a broader regional trend. Even for attackers capable of deploying custom malware, an AI-driven backend serves as a force multiplier to populate directories with exploit scripts, streamline execution and lower the barrier to entry for managing complex post-exploitation workflows.
Initial Access and Execution: Phishing and Automated Actions on Objectives
In February 2026, we observed that attackers associated with CL-CRI-1163 achieved initial access through a resume-themed phishing email attachment.
After attackers dropped multiple RATs, we observed a similar iterative naming structure, likely due to the attackers' failure to install their tool set. We observed attempts to install versions 1–8 of a Go-based reverse SOCKS5 tunneling tool named SockTz from a compromised WordPress site.
Figure 4 shows the attempt to execute version 8, named socktz_v8.exe.
Figure 4. Attempt to retrieve SockTz version 8 from a compromised WordPress site.
Likely due to failure to install the SockTz malware and open a successful proxy connection, attackers behind CL-CRI-1163 pivoted to attacker-controlled infrastructure to retrieve version 9, named socktz_v9, as Figure 5 shows.
Figure 5. Pivot to attacker-controlled infrastructure to retrieve SockTz version.
Infrastructure Inspection: Analyzing AI-Generated Naming Conventions in the Open Directory
Researchers previously identified this SockTz proxy tool and 167.148.195[.]53 tied to persistent targeting of vulnerable JBoss servers. Where previous reports identified different versions of this tool across campaigns, we observed installation attempts of versions 1–9 in a two-hour window.
SockTz installers were hosted along with hundreds of campaign scripts on an open directory at 167.148.195[.]53. Similar to the SockTz version numbers and the CL-CRI-1131 operations, the open directory associated with this CL-CRI-1163 activity exposed iterative scripts with appended identifier _output, indicating the attackers employed LLMs throughout the campaign. A partial list of the files is shown in Figure 6.
Figure 6. Partial list of the campaign scripts hosted on an open directory at 167.148.195[.]53.In addition to exposing scripts across multiple phases of the attack chain, attackers appended exploit filenames with descriptive adjectives. This suggests that the attackers employed iterative, language model-driven development: exploit_creative.py, exploit_careful.py and rce_focused.py.
The threat actors behind the CL-CRI-1131 and CL-CRI-1163 campaigns have enhanced their technical capabilities by incorporating commercial LLMs into their workflows. This integration enables them to author advanced proxy configurations and dynamically address complex execution failures. However, the infrastructure they deployed to leverage this AI became their Achilles' heel.
Exposing an open NextChat directory to the public internet reveals a fundamental lack of operational maturity. The AI provided the necessary tactical workaround to extract the Active Directory database, but the human operators failed to secure the staging server. This left their entire playbook, prompt history and staging scripts visible to threat researchers.
This highlights a critical vulnerability for defenders to exploit. As less skilled and experienced actors adopt AI to accelerate their attacks, their foundational operational security (OpSec) failures remain the most reliable way to track and dismantle their operations.
Conclusion
The CL-CRI-1131 and CL-CRI-1163 operations orchestrated in the Mexican transportation and Brazilian financial sector campaigns highlight a notable evolution in the regional threat landscape. Through these campaigns, we observe attackers leveraging AI to enhance their capabilities.
Whether manipulating built-in Windows utilities or deploying custom-built proxy networks, these operators rely on commercial LLMs to overcome tactical hurdles and streamline their execution. However, this rapid technical acceleration is offset by fundamental operational security failures. Exposed staging directories, unsecured NextChat interfaces and structured multi-SAN certificates provide defenders with a clear roadmap of the attacker's infrastructure.
By pivoting on these OpSec oversights, defenders can proactively track the activity and disrupt the attackers' campaigns.
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
Cortex XDR and XSIAM are designed to help 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, intended to prevent both known and unknown malware from causing harm to endpoints.
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
Mexican Transportation Campaign
Domains:
m-doxa-apodo.duckdns[.]org
m-doxa-geo.duckdns[.]org
m-doxa-intel.duckdns[.]org
m-doxa-repuve.duckdns[.]org
m-doxa-sre.duckdns[.]org
m-doxa-vacunas.duckdns[.]org
Certificate SHA-256 Hashes for Fingerprints and Corresponding Hosts:
Unit 42 responded to an incident where a human attacker used frontier AI to breach an enterprise network autonomously as part of a ransom attack. The agents breached the company's security layers in a methodical manner, each targeting a different layer of defense to achieve a shared goal. The impact was at the scale of a coordinated effort from multiple red teams, which would normally take human operators around two weeks.
The threat actor told us in negotiations that they leveraged frontier AI models and attack-specific agentic AI frameworks. By shifting execution to an automated loop, the attacker compressed weeks of methodical intrusion tradecraft (using more than 50 MITRE ATT&CK techniques) into less than 10 hours.
After they gained initial access, the attacker used agents to map the internal architecture, raid source repositories and seize root credentials. The agents also triggered unauthorized continuous integration/continuous delivery (CI/CD) builds and claimed master keys to the victim's cloud AI infrastructure.
What made the attack stand out was AI-assisted operational efficiency, without the need for a novel zero-day or super elite tradecraft. The attacker left tactical execution to AI agents that monitored, evaluated, acted and re-planned in real time, increasing speed throughout the attack chain.
The attacker also directed the agent to leave behind a “report” on the organization’s security posture: an 80-page, technical audit detailing dozens of exploited findings.
Inside the Machine-Speed Attack Chain
The adversary ran their operation using current AI-enabled software development processes. We observed multiple indicators consistent with AI usage:
LLM calls to multiple frontier AI agents in parallel
Structured Markdown files passing information between agents and sessions
Custom scripts (assessed with high confidence to be AI-generated due to UI elements) managing dynamic operations
The 10-hour operational timeline included the following:
Infiltration and mapping: The actor breached a publicly accessible web service to tunnel into the network, deploying an automated recon agent to map internal microservices.
Secrets harvesting: Sub-agents combed enterprise code repositories, extracting hard-coded tokens and service passwords.
Privilege takeover: Using exposed tokens, the actor infiltrated the secrets management system, harvesting master administrative credentials to seize control of root system access.
Pipeline exploitation: The actor hijacked an enterprise code application via custom workflows to exfiltrate cloud access keys. They attempted to plant backdoors in Terraform configurations, but hard branch-protection controls stopped this.
AI infrastructure hijacking: Using stolen cloud keys, the actor turned the victim’s AI endpoints into post-compromise infrastructure — using the company’s compute power to perpetrate future moves.
Figure 1 maps the AI-orchestrated workflow.
Figure 1. AI-orchestrated intrusion workflow. The actor sets objectives and makes consequential decisions. Specialized agents execute, share results and adapt in real time.
Unified Threat Framework Mapping
For illustration, Table 1 below maps some of the techniques used against the MITRE ATT&CK and ATLAS frameworks:
Intrusion Stage
Threat Actor Action
MITRE ATT&CK® Mapping
MITRE ATLAS™ (AI-Specific) Mapping
Initial Access and Recon
Publicly accessible web service breach; automated service mapping via service discovery tool
T1190: Exploit Public-Facing Application
T1046: Network Service Discovery
AML.T0000: Initial Access
AML.T0002: AI-Automated Reconnaissance
Credential Access
Code scraping for secrets across code repos
T1552.001: Credentials In Files
AML.T0014: Credentials Harvesting
Privilege Escalation
Infiltrating secrets manager to harvest admin system secrets
T1555: Credentials from Password Stores
AML.T0016: Privilege Escalation via Automated Pivot
Table 1. Major MITRE ATT&CK and MITRE ATLAS techniques used by the attacker.
Key Lessons: Addressing Agentic Attacks
This incident exposes how an attacker who understands how to deploy frontier AI agents effectively can dramatically speed up the pace of their attack. We assess that attackers will increasingly add AI agents to their tool sets. Organizations should take note of the following to address agentic attacks:
AI agents reduce the time between steps in the attack flow: AI agents in this attack were designed to parse raw tool output and quickly take next steps, speeding up the overall attack flow.
AI agents leave recognizable indicators: Defenders can identify agentic attacks by watching for indicators such as the use of structured Markdown, Python caches and paired asset folders.
Attackers can use AI to establish redundant persistence across the environment: In this incident, the attacker used AI agents to efficiently establish overlapping persistence across SSH keys, serverless functions, container restart policies, cloud identities and CI/CD pipelines. Using AI agents can make it easier for an attacker to maintain and test this entire portfolio in parallel.
Attackers can use an organization’s AI tools as post-compromise infrastructure: Attackers can hijack enterprise AI services to assist in their attacks. This allows threat actors to hide orchestration traffic among expected traffic, and offload the financial cost onto the victim.
Defending Against Machine-Speed Attacks
Defending against automated agent loops requires matching the speed and adaptability of AI-driven attacks:
Execute synchronized containment: Deploy automated playbooks that simultaneously revoke credentials, terminate OAuth sessions, freeze CI/CD pipelines and isolate cloud accounts across all operational planes.
Govern AI as core infrastructure: Inventory every model endpoint, API key, Model Context Protocol (MCP) gateway and AI tool integration. Apply strict rate limits, least-privilege policies and diagnostic logging.
Detect behavioral loops: Hunt for operational loops including bursty API requests, rapid 401/200 HTTP state shifts, parallel authentications and sudden model usage from unexpected identities.
Lock down DevOps pipelines: Enforce mandatory, multi-party code reviews and immutable branch protection on all infrastructure-as-code repos to block automated backdoor injection.
Between January and April 2026, we uncovered a coordinated social engineering operation that leveraged external Microsoft Teams accounts to masquerade as IT help desk personnel. Our telemetry reveals that this operation targeted more than 150 employees across at least 10 companies in various industries. We call this activity Spring Ring.
What seems like a benign chat is in fact a voice phishing (vishing) call, during which adversaries try to coerce victims into executing remote monitoring and management (RMM) tools or custom malware. In a more advanced variant, attackers transitioned from a vishing call to a full-blown Microsoft NT LAN Manager (NTLM) relay attack aimed at an organization's domain controller (DC).
We provide a technical breakdown of this operation’s attack lifecycle across two observed campaigns, both illustrating vishing manipulation that resulted in the attempted payload delivery via two distinct attack vectors.
These two campaigns demonstrate the weaponization of communication platforms as identity becomes a primary attack vector.
Palo Alto Networks customers are better protected from the threats described here through the following products and services:
Spring Ring’s activity mirrors a broader trend in the threat landscape toward social engineering campaigns. According to our recently published Insights blog, 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. In addition, according to KnowBe4’s Phishing Threat Trends Report, Teams-based attacks rose by 41% [PDF] between October 2025 and March 2026. They note that this surge is driven by attackers exploiting the platform's default “Chat with Anyone” feature to initiate direct chats with users outside their organization.
Previous Teams-based attacks, such as those by Cloaked Ursa (aka APT29), focused on credential harvesting and group chat-based social engineering. They often relied on malicious links or fake Entra ID tenants to appear legitimate.
Spring Ring’s approach relies on active human voice interaction. In this way, attackers can evade detection without a software exploit. Instead, they rely on exploiting the trust that employees place in software as a service (SaaS) collaboration platforms.
SaaS Applications: The New High-Value Target
SaaS applications are essential for business operations, storing an organization’s most critical and sensitive data. Unlike email, where users are trained to look for external sender banners or suspicious links, communications platforms provide a closed loop that attackers exploit by:
Leveraging platform trust: People are more likely to engage with a message from a help desk identity than a random email from an external domain
Exploiting human interaction: A professional voice on an audio call creates a level of trust that is difficult to manufacture in text, making the victim more susceptible to manipulation
Bypassing the monitoring gap: Voice calls are often less monitored, recorded or documented than employees’ digital file operations or email histories, providing attackers with a secluded environment to execute their lures
The Evolution of Collaboration Attacks
The Spring Ring operation represents an evolution from previous campaigns by merging vishing into the Teams workflow. This shift moves the attack from a passive click-and-harvest model to a real-time engagement.
Attackers can then pivot based on the victim's responses. Once the trust gap is crossed, the path to domain-level privileges via open-source tools like PetitPotam is short.
Figure 1 shows an example of the warning that Teams users get when an external identity creates a chat with them.
Anatomy of Spring Ring: How Attackers Masquerade as Internal Support
The Spring Ring campaigns are a coordinated operation that relies on impersonating corporate IT structures. Attackers can drop their lures into a victim's primary communication channel using external Microsoft Teams accounts.
The Discovery: Spotting the Pattern
Our investigation into this activity began after the release of a new detection suite for Microsoft Teams. By monitoring these alerts, we identified a suspicious pattern of chat creation across multiple tenants. Further investigation into these alerts led to the initial discovery of 26 distinct identities approaching targets across different organizations.
The Initial Hook: Crafted Personas and Domains
The attack begins with creating a Microsoft Teams chat using identities designed to mirror legitimate internal support units. The attackers opt for professional, urgency-focused display names such as help desk, IT assistance or support staff.
To strengthen the impression of legitimacy, the attackers operate from external .onmicrosoft[.]com tenants. These are meant to resemble legitimate corporate infrastructure. They are used by attackers to provision Microsoft 365 tenants. The subdomains are controlled by the adversaries.
Threat actors frequently abuse or subvert legitimate products for malicious purposes. This does not indicate that the product itself is flawed or compromised. Unit 42 has no evidence of any compromise or vulnerability within Microsoft's product related to this campaign.
In some instances, the actors went beyond generic role names and used specific names to increase the perceived authenticity of the technician on the other end of the line:
Names have been partially redacted because the attackers used specific names of legitimate industry personnel. The use of these names does not indicate a compromise of their accounts.
After the chat is created, the attacker initiates a voice call (the vishing element) to coerce the victim. After establishing a connection with what the victim believes is their own IT department, the attacker guides targeted employees through the steps to grant them remote control or execute malicious payloads.
The Scale of Spring Ring
Our telemetry reveals that these attackers often make several attempts — including leaving voicemails — before establishing a connection. We observed the attackers engaging victims in calls that varied in duration:
Many calls last only a few seconds or they are missed by the victim as the attacker cycles through targets
Successful calls often last between 10 and 15 minutes
Figure 2 shows several vishing attempts made by the same attacker identity on six different targets, with different conversation durations.
Figure 2. Examples of an attacker initiating calls with different targets, and different time durations.
The reach of these campaigns is significant:
More than 10 tenants were attacked: We observed the campaigns targeting many organizations across different industries
More than 150 targets were approached: The attackers contacted more than 150 individual employees
Persistent activity: We tracked the campaigns since January 2026 over a period of several weeks. According to our telemetry, these campaigns were active up until April 2026.
Technical Deep Dive: The RMM and Custom Dropper Combination
Once the attacker establishes trust through the initial vishing call, the Spring Ring campaigns transitioned into a technical execution phase designed to gain a permanent foothold. We provide a detailed analysis of two campaigns (Campaign A and Campaign B) that both began with a Microsoft Teams lure. They then diverged in their payload delivery, tool complexity and post-compromise activities.
Figure 3 shows the full attack flow of the two campaigns' attack methods.
Figure 3. Full attack flow of the two Spring Ring campaigns.
Campaign A: From Support Tools to Obfuscated Payloads
In Campaign A, the attacker used a bring-your-own-tool approach, luring the victim to execute legitimate RMM software. The attacker posing as a technician walked the employee through launching built-in Windows tools like Quick Assist or downloading third-party RMM software. Once the RMM tool ran, the attacker could request remote control of the victim’s machine.
After gaining remote control, the attacker performed a series of basic enumeration commands to gain information on the host and domain. We observed them executing:
1
2
whoami/groups
net group/dom
After confirming the environment's value, the attacker pivots to payload delivery. The attacker used a PowerShell command line to download an obfuscated PowerShell-based remote access Trojan (RAT) from the attacker-controlled domain, san-sid[.]com. This malware used variable manipulations and arithmetic obfuscation designed to evade automated security analysis and sandbox detection.
By leveraging advanced AI and pattern-matching algorithms, we were able to de-obfuscate the RAT. We started by stripping away anti-analysis bloat from the code that was used to cause a time-out for deobfuscation tools.
The actual payload is a tiny, nine-line command and control (C2) stager. The script disables Antimalware Scan Interface (AMSI) via the amsiInitFailed flag and executes a test scan to verify the bypass. Upon verification, the script encrypts host data and beacons out to san-sid[.]com to download and execute further payloads.
Figure 4 shows a snippet of the obfuscated PowerShell-based RAT.
Figure 4. A snippet from the obfuscated PowerShell-based RAT.
This campaign was blocked by automated Cortex XDR Agent protections during the malware's execution phase.
Campaign B: The Tailored Cloud Execution Chain
The second campaign used a more customized delivery method. During the vishing call, the attacker directed the victim to a cloud endpoint. The attackers tailored the cloud infrastructure and filenames to match the targeted organization and the specific user, for example:
When the victim clicked a link containing their own company's name and downloaded <company_name>-org-filters-update-<victim_name>[.]exe, it triggered an execution chain:
Staging and persistence: The executable moved itself to the \Temp\ directory and spawned copies (e.g., vhlp-*.exe and scnr-*.exe) as a persistence mechanism
Browser hijacking: The malware launched a hidden, headless instance of Microsoft Edge, and the attackers wrote to the disk and sideloaded an Edge extension
Lateral movement and authentication coercion: The attackers used Python (C:\ProgramData\IntegrityData\python.exe) to initiate a lateral movement sequence:
SMB scanning: Initiated port 445 traffic targeting internal servers
NTLM authentication: Generated NTLM traffic targeting the organization's DC
PetitPotam exploitation: The attacker attempted a PetitPotam attack to coerce the DC into authenticating back to an attacker-controlled machine. This NTLM relay attack was designed to grant the attacker domain-level privileges
By comparing the two campaign paths, we can better understand the diversity of threats targeting collaboration platforms. Table 1 compares the campaigns' specific methods of attack.
Feature
Campaign A
Campaign B
Initial Lure
Microsoft Teams vishing
Microsoft Teams vishing
Primary Delivery
RMM tools
Tailored hosting infrastructure executables
Stealth Mechanism
Obfuscated PowerShell
Headless Microsoft Edge and sideloaded extension
Lateral Movement
Basic enumeration only
PetitPotam NTLM relay
Table 1. Comparing the two campaigns’ methods.
This comparison highlights an important point for defenders. A simple vishing hook can lead to either a standard malware infection, or to a serious domain-level breach if the attacker pivots to payload delivery.
Identifying Teams Impersonation and Identity-Based Anomalies
Recognizing campaigns like Spring Ring requires a strategy of profiling external and internal entity behaviors. The attackers behind these campaigns operate within a legitimate ecosystem, so detection hinges on identifying small anomalies in how external identities interact with your organization.
Profiling the Identity
The first line of defense is recognizing the markers of the external actor. Our research into these campaigns highlights several consistent patterns:
Spoofed domain naming: Attackers mostly use external .onmicrosoft[.]com tenants that include keywords like internal, certified, network or infrastructure to project authority
Persona mimicry: They use professional display names, like IT help desk or admin, to increase the perceived authenticity of the technician during vishing calls
Infrastructure red flag: The source IP addresses for these connections often originate from commercial VPN services to mask the attacker's true location
Behavioral Metrics of the Interaction
Our researchers were able to identify key markers of Spring Ring activity by analyzing the metadata of these interactions, despite the deceptive nature of the attacker’s initial lures:
The chat-to-call ratio: A primary indicator is the rapid transition from a 1:1 chat request to an unsolicited audio call
Call curation profiling: Attackers cycle through targets quickly. We observed call patterns ranging from 30-second initial attempts to 15-minute sessions.
Multiple approaches: These actors demonstrate high operational volume, often approaching 5-6 identities within a matter of minutes using one of their spoofed identities
Recognizing Post-Compromise Behavior
Upon a successful compromise, we observed endpoint activity characterized by:
Atypical execution of RMM tools by users who do not require remote support
Access to unknown links, including cloud storage URLs or other file hosting servers that victims might be lured to access
Organizations can identify the Spring Ring lifecycle before the attacker transitions from a chat to a domain-level attack, by profiling these signals, the origin of the tenant and the subsequent attack flow.
Figure 5 shows one example of a Cortex alert on a new suspicious conversation created in Microsoft Teams. This alert is based on behavioral and metadata analysis of a newly created chat.
Figure 5. Example of a Cortex alert on the creation of a suspicious chat in Microsoft Teams.
Conclusion
The Spring Ring campaigns demonstrate a strategic pivot in social engineering, where attackers move beyond email phishing to enterprise collaboration tools. Attackers turn an important productivity tool into a conduit for domain-level exploitation, masquerading as internal help desk personnel through vishing calls.
This activity highlights an important shift in the security landscape. Identity is now a primary perimeter, and the platforms we rely on for daily communication are being weaponized.
Looking forward, attackers might further refine their ability to operate within SaaS ecosystems. These platforms are not just an initial access vector, they contain sensitive documentation, workflows and communication logs that could allow an adversary to advance their attack chain.
Our analysis of the Spring Ring operation reinforces several key lessons:
Trusted SaaS applications are not inherently safe: Attackers exploit the confidence that employees place in communications platforms
Attack vectors are simple and scalable: By using seemingly legitimate external tenants and professional vishing lures, attackers can target hundreds of employees across many industries with minimal friction
Adaptability is key: Attackers are evolving their methods, shifting from basic credential harvesting to human-led lateral movement
As these threats evolve, organizations must prioritize user education regarding unsolicited external communication across collaboration platforms. Robust behavioral monitoring can help identify identity-based anomalies before they escalate to lateral movement.
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 can help prevent the execution of both known and unknown malware through Behavioral Threat Protection and machine learning powered by the Local Analysis module. Beyond stopping initial execution via malicious droppers, Cortex XDR actively halts post-exploitation activities, such as PetitPotam NTLM relay attacks, before adversaries can achieve lateral movement.
Cortex Cloud Identity Threat Detection can help deliver real-time protection against identity-based threats across cloud providers, IdPs, and SaaS applications. Using advanced behavioral analytics on real-time telemetry, ITDR baselines access patterns to detect anomalies, track complex attack chains—such as the Spring Ring lifecycle and trigger automated responses to contain compromised credentials.
The Cortex Advanced Email Security module can help extend the power of the Cortex platform into cloud-hosted email environments, providing a scalable, AI-driven layer for detection, investigation, and response. By automatically stopping email threats and malicious communications across enterprise environments, it provides seamless protection across one of your most vulnerable attack vectors.
Idira Threat Detection and Response can help enable security teams to counter identity-based attacks targeting Idira Next Generation Identity (NGI) Platform and the identities it secures. Using near real-time detection, powered by CORA AI, and leveraging Idira’s visibility across multiple contexts (like PAM, authentication, SSO, cloud, endpoints, browsers, and more), Idira ITP can apply automated, tailored non-disruptive in-session response to contain and minimize potential identity-based threats.
Idira Endpoint Privilege Manager can help enable enterprises to reduce risk, satisfy compliance, and streamline operations. It helps implement least privilege via policy-driven elevation and removal of standing admin rights, and blocks risky actions, such as execution of unvetted applications and access to memory of other processes, while providing audit-ready evidence and unified identity governance. Automation and consolidation improve efficiency and support Zero Trust strategies, strengthening security without slowing the business.
Idira Privileged Access Management can help unify privileged access across human, machine, and agentic identities to secure cloud access across multi-cloud environments. Building on proven PAM, it delivers centralized secrets management alongside modern controls like Just-in-Time access and Zero Standing Privileges. This enforces consistent least-privilege security across on-premises, cloud, and SaaS targets.
Idira Secure Infrastructure Access can help enforce Zero Standing Privileges (ZSP) through Just-in-Time (JIT) provisioning which grants temporary, tightly scoped access only as needed. Backed by continuous session recording and real-time command monitoring, SIA can detect high risk actions before an attacker compromises critical systems.
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
Attacker Identities Used in Vishing Attempts – Generic
![A screenshot of an email alert from AWS Support. The subject is "[Action Required] Your AWS Access Key is Exposed for AWS Account." It includes a table with customer and account details, and a detailed message advising actions to secure the exposed AWS access key. The message outlines steps for rotating the access key and includes links for additional resources.](https://unit42.paloaltonetworks.com/wp-content/uploads/2026/09/word-image-286681-186917-8.png)
Get updates from Unit 42 