Extortion Activity No Longer Requires Encryption for Payment
This blog dives into the growing trend of data theft and extortion activities which no longer require the use of ransomware to pressure victims into paying a demand. We examine the financially-motivated threat actors using both single and double extortion techniques and what this means for organizations going forward, especially with the arrival of frontier AI models.
Shifting Threat Landscape Observations
As detailed in our 2026 Global Incident Response Report, Unit 42 observed a notable decrease in the use of encryption for extortion-related cases last year. The total percentage in 2025 dropped to 78%, much lower than the near-or-above-90% levels observed between 2021-2024. Other security organizations have seen similar trends, with Google reporting a gradual rise in data theft and extortion incidents from approximately 2% in 2020 to 15% in 2025. Resilience also observed an increase in extortion-only incidents in 2025, rising from 49% in the first half to 65% in the second half.
In 2025, pure data-exfiltration campaigns heavily targeted Professional Services, Healthcare and Consumer Services firms with threat actors specifically focused on mid-sized organizations accounting for 64% of victims. Interestingly, while Manufacturing remains the single most disrupted sector overall, Construction has witnessed a 44% year-over-year increase as a data-only extortion hotspot. These firms are attractive targets due to lucrative financial blueprints and bidding data combined with data egress controls.
The current data-only extortion economy is directly fueled by a heavily-regulated compliance landscape, which threat actors have effectively weaponized. Strict mandates like the SEC's 4-day disclosure window and GDPR’s 72-hour reporting rule have created a regulatory countdown clock, allowing threat actors to force rapid negotiations before organizations can complete internal assessments. Because global privacy frameworks, state-level breach notification laws and post-leak class-action litigation have driven the average cost of data-theft extortion to $5.08 million (and over $10 million for broader U.S. breaches), data exposure alone carries disastrous financial liabilities. Threat actors recognize that regulatory penalties are so severe that the compliance framework itself compels corporate payouts.
As recently noted by our Chief Security Intelligence Officer, Wendi Whitmore, it only took 39 seconds for threat actors to move from initial access to data exfiltration in one case.
Differences in Extortion Operations
Unit 42 is actively monitoring several threat actors that are continuously conducting data theft and extortion operations. The notable differences between these attackers is their use of initial access techniques and the number of extortion techniques to pressure victims into payment.
Initial Access via Software Supply Chain Compromise
TGR-CRI-1135 (aka TeamPCP) has been active since at least late 2025. According to Wired, this group has conducted upwards of 20 distinct supply chain compromise attacks which have led to the injection of malicious code into over 500 pieces of software. We previously reported on the group’s activities earlier this year and how their malware was able to successfully exfiltrate sensitive secrets (cloud access tokens, SSH keys, Kubernetes secrets) from victims.
In recent months, TGR-CRI-1135 has been partnering with various ransomware-as-a-service (RaaS) and extortion-as-a-service (EaaS) operators to monetize their ongoing intrusion activities. On the EaaS front, they have been collaborating with the operators of LAPSUS$ Group to extort targeted organizations via their data leak site as shown below in Figure 1.
Figure 1. Screenshot of LAPSUS$ DLS post on May 21, 2026. Source: Dark Web Informer.
On the RaaS front, they have been working with the operators of Vect ransomware based on communications observed via the BreachForums cybercrime forum as shown in Figure 2. Unit 42 is also aware of claims by one of Vect’s affiliates, the Rostova Organization, that they are also partnering with TGR-CRI-1135.
Figure 2. Screenshot from HasanBroker’s BreachForums post on March 25, 2026. Source: Unit 42.
On May 13, 2026, TGR-CRI-1135 announced the release of an open source version of Shai-Hulud on BreachForums as shown in Figure 3. Going forward, as noted in our most recent threat research article, this will likely make attribution more difficult given that copycats may leverage the tool in similar supply chain compromise attacks.
Figure 3. Screenshot from BreachForums post on May 13, 2026. Source: Unit 42.
One notable development related to Vect was the announcement on BreachForums shown in Figure 4 which states that those operators have been removed from the forum. It is unclear if this will have a material effect on their collaboration with TGR-CRI-1135 going forward.
Figure 4. Screenshot from Resolute’s BreachForums post on May 21, 2026. Source: Unit 42.
At this time, Unit 42 is not aware of TGR-CRI-1135 using any additional extortion techniques to pressure victims into paying their ransom demands outside of purely data exfiltration.
Initial Access via Vishing
Bling Libra continues their rampage of infiltrating customer SaaS tenants for data theft and extortion operations, which Unit 42 reported on extensively in 2025. The operators have distanced themselves from the cybercriminal alliance known as Scattered LAPSUS$ Hunters based on a Telegram message shown in Figure 5.
Figure 5. Screenshot from scattered LAPSUS$ hunters part 7 chat on May 11, 2026. Source: Telegram.
However, their playbook has remained relatively unchanged based on Unit 42 observations. They continue to use vishing for initial access, directing unsuspecting victims to phishing sites designed to intercept user credentials and multifactor authentication (MFA) codes and ultimately registering their own devices to establish persistence within targeted environments. The operators still use the same Tox ID to communicate with victims and also maintain a Tor-based data leak site.
In comparison to TGR-CRI-1135, Bling Libra uses additional extortion techniques outside of pure data theft to pressure victims into paying a ransom. Unit 42 is aware of their adoption of both distributed denial-of-service (DDoS) attacks and information leaks to media outlets as added leverage points to extort victims.
On the flip side, an activity cluster tracked by Unit 42 as CL-CRI-1116, which overlaps with public reporting on BlackFile, has followed a similar pattern of activity in terms of a playbook-driven approach with some subtle and not so subtle nuances.
While the attackers behind CL-CRI-1116 also use their own Tor-based data leak site, they do not reuse the same Tox ID across victims and typically use a different registrar to set up their phishing sites in comparison to Bling Libra.
The major difference between CL-CRI-1116 and Bling Libra is the former’s use of swatting employees as a double extortion technique. This act is typically defined as placing a false emergency call to first responders, such as reporting a fake crime at a specific location to trigger a physical response. In many cases, this is expected to create chaos and can potentially even lead to acts of violence.
This convergence between cyber and physical security can lead to complications if these two teams aren’t in regular communications with each other on how to address such a situation, especially as it pertains to executive protection.
One recent development regarding the attackers behind CL-CRI-1116 is the closure of their former data leak site and the rebranding of their program under the name “Redact” with a new data leak site as shown in Figures 6 and 7.
Figure 6. Screenshot from BlackFile data leak site post on May 11, 2026. Source: Unit 42.Figure 7. Screenshot from BlackFile data leak site post on May 19, 2026. Source: Unit 42.
Looking Forward
In recent weeks, Palo Alto Networks has been at the forefront of providing guidance to organizations on how to secure their environments from the inevitable weaponization of frontier AI models like Mythos by threat actors. These models currently accelerate at finding and chaining vulnerabilities together to exploit flaws in applications and infrastructure alike. For example, Anthropic recently disclosed how Mythos was able to identify approximately 23,000 potential vulnerabilities across 1,000 open source software projects. We have also observed in AI-assisted scenarios that the time from initial access to data exfiltration has dropped to as little as 25 minutes. With this in mind, what do extortion activities, regardless of initial access vector or use of single vs double techniques, look like in the age of frontier AI models?
In terms of software supply chain compromise, TGR-CRI-1135 has already targeted AI environments as part of their ongoing campaigns, but what if they were able to weaponize a frontier AI model to further accelerate the speed and scale of their intrusion activities? This would compound the already complex problem of organizations trying to secure their application development and CI/CD pipelines from these types of attacks. The recent disclosure of the SymJack is a prime example of how AI agents could be leveraged in these types of attacks.
With regards to vishing, AI-powered call center platforms like ATHR can nearly fully automate these attacks for human operators by utilizing AI agents to manage calls and other aspects of the intrusion lifecycle. This service not only lowers the barriers to entry for less sophisticated cybercriminals but also further accelerates attacks for more sophisticated threat actors like Bling Libra. The incorporation of frontier AI models into a platform like this would only exacerbate the speed and scale of attacks leveraging this type of capability.
We believe there is an approximate window of 3-5 months before these frontier AI models are weaponized by threat actors. The time is now for organizations to capitalize on a moment where we as defenders can truly establish a “left of bang” posture against a volatile threat landscape.
Defensive Recommendations
Data Exfiltration Detection and Prevention
Deploy data loss prevention (DLP) controls at cloud, endpoint, and network egress points.
Baseline and alert on abnormal egress volume and velocity.
Monitor for staging behavior.
SaaS Security Posture Management
Audit OAuth token grants, third-party app integrations, and API permissions across SaaS platforms.
Enforce conditional access policies that restrict SaaS sessions by device compliance, location, and risk score.
Implement SaaS audit log aggregation and anomaly detection.
Identity and Vishing Resilience
Migrate from OTP-based MFA to phishing-resistant authentication (FIDO2/WebAuthn hardware keys).
Implement help desk identity verification procedures that cannot be socially engineered.
Conduct targeted vishing simulation exercises.
Software Supply Chain Integrity
Implement software composition analysis (SCA) and dependency pinning in CI/CD pipelines.
Rotate and vault all secrets exposed to CI/CD environments.
Monitor package registries for typosquatting and unauthorized updates to internal or frequently-used packages.
Enforce code signing and provenance verification for all artifacts entering production.
AI-Accelerated Threat Preparedness
Pressure-test detection and response capabilities against compressed attack timelines.
Prioritize vulnerability remediation for internet-facing and AI-discoverable attack surfaces.
Deploy voice authentication and call verification controls for inbound calls.
Unit 42 Deep and Dark Web is a service that assists with gaining visibility into unknown and emerging risks of content posted on the deep and dark web, informs organizations about the exposure of sensitive information, and helps reduce the time between detection and response.
Unit 42 Frontier AI Defense is an elite service that uses access to frontier models to identify your organization's likely attack paths before attackers can weaponize them.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
Unit 42 researchers have observed evidence of cyberattacks by the Iran-nexus advanced persistent threat (APT) group Screening Serpens (aka UNC1549, Smoke Sandstorm and Iranian Dream Job). Based on our visibility, we believe that the group targeted entities in the U.S., Israel and the United Arab Emirates, and likely two additional Middle Eastern entities.
This research follows an evolution through cyberattacks in mid-February through April 2026. The timing of these campaigns aligns closely with that of the regional conflict that started in the Middle East on Feb. 28, 2026. We discovered six new remote access Trojan (RAT) variants developed and deployed between February and April 2026.
Screening Serpens has been active since at least 2022. Their recent activity demonstrates an increase in technical capabilities and operational resilience.
Screening Serpens primarily targets technology sector professionals, using highly tailored social engineering. The group frequently uses personalized recruitment lures that impersonate trusted brands and hiring platforms, to trick targets into initiating the infection chain.
We assess with moderate-high confidence that the campaigns discussed in this article are conducted by Screening Serpens. The group has maintained a consistently high operational tempo throughout March and April 2026.
We have grouped the six newly discovered RAT variants into two new malware families that were deployed in concurrent espionage campaigns. Based on the timing of deployment, our analysis indicates two sets of coordinated cyberattacks. At least one variant was compiled and deployed with specific timing instructions.
Our analysis reveals a continuous cycle of development and deployment, characterized by specialized and upgraded variants with diverse functionalities, as shown in each targeted campaign.
The most critical evolution in the group’s recent campaign uses a technique called AppDomainManager hijacking. This hijack method manipulates the initialization phase of .NET applications to proactively disable the application’s own security mechanisms via a legitimate configuration file. The disabled security in these apps left the targeted entities vulnerable to the deployed multi-functional RATs.
Palo Alto Networks customers are better protected from the threats described in this article through the following products and services:
Screening Serpens is an Iran-nexus APT group operating as a cyberespionage group aligned with Iranian intelligence objectives. While historically focused on regional targets in the Middle East, the group gained industry attention in late 2025 when Check Point Research detailed its strategic expansion into Western Europe.
During these campaigns, Screening Serpens consistently set its sights on high-value sectors, heavily targeting aerospace, defense manufacturing and telecommunications organizations. These operations are characterized by targeted social engineering campaigns, using lures designed specifically to trick job seekers in these key sectors.
Between February and April 2026, we identified six new remote access Trojan (RAT) variants that Screening Serpens deployed during the recent regional conflict. Based on VirusTotal metadata, it appears these samples may have been used against targets across the U.S., Israel and the UAE as well as two additional Middle Eastern entities. The samples are split into two distinct malware families:
A newly discovered malware family that we call MiniUpdate
An evolved iteration of a malware family named MiniJunk that we track as MiniJunk V2
Both families build directly upon the actor's established playbook. Their infection chains begin with targeted spear phishing lures, leveraging DLL sideloading for execution. The threat actor routes command and control (C2) traffic through a set of three to five unique domains, mostly hosted by Azure, dedicated to each target and variant. This technique prevents cross contamination to increase operational resiliency.
Timeline of Recent Cyber Activity
Here is the timeline of events in the recent Screening Serpens campaign:
In late 2025, Screening Serpens expanded to targets in Western Europe.
In mid-February, 2026, we found an indication of a payload delivery to a Middle Eastern target.
In late March 2026, we identified samples uploaded to VirusTotal from organizations in the U.S. and Israel.
Additional samples from the UAE and another Middle Eastern entity were discovered in mid-April 2026.
Figure 1 shows the transition from campaign preparation to a surge in coordinated attacks following the onset of the regional conflict.
Figure 1. Timeline of Screening Serpens documented activity.
As seen in Figure 1, we observed the MiniUpdate family samples uploaded on March 26, April 15 and April 17. We observed the MiniJunk V2 family samples uploaded on Feb. 17 and in an upload on March 27.
We discuss the MiniUpdate family first in our analysis, and then cover the details of MiniJunk V2.
MiniUpdate RAT Analysis
After reading Check Point's initial report, we pivoted off the specific file name (Hiring Portal.zip) of another known Screening Serpens artifact. In doing so, we uncovered four samples that attackers deployed in two sets of coordinated attacks during the recent conflict. VirusTotal metadata indicates that the campaigns may have targeted entities in the U.S. and Israel on March 26, 2026, and most recently, the UAE and another Middle Eastern entity on April 15 and 17, 2026, respectively.
We named this malware family MiniUpdate, referencing the internal file name that we observed within these payloads: UpdateChecker.dll.
By comparing the two sets of coordinated attacks, we observed continued refinement of the malware’s abilities over the course of a month. The differences we identified between the samples were superficial changes to things like opcode mappings and specific functionalities, such as the latest variant’s ability to exfiltrate files in chunks. The most significant difference between the malware variants is the rotation of their C2 domains. While we observed these active adjustments, we did not observe a significant evolution in the malware itself.
MiniUpdate: March U.S. Campaign
Attackers delivered this variant via an archive file, as part of a campaign impersonating a global air carrier. Deployment of this malware began no earlier than March 26, 2026.
Initial Delivery and Targeted Recruitment Lures
An analysis of the archive's contents reveals a tailored social engineering trap aimed specifically at technical personnel. The ZIP contains a nested payload archive (Hiring Portal.zip) packaged alongside six PDF documents.
These PDFs are crafted job requisitions targeting high-level IT and engineering roles (e.g., Senior Software Engineer Job ID JR205894.pdf). Attackers mimicked legitimate corporate job applications by including specific job IDs, increasing the likelihood that the target will review the descriptions and extract the nested Hiring Portal.zip.
Targets likely believed they were accessing an application portal or a technical assessment. We did not find any indication in this campaign of a breach into the global air carrier’s infrastructure. The impersonation was limited to using its name and branding.
Figure 2 shows all the falsified job documents and the Hiring Portal.zip archive.
Figure 2. Contents of the archive.
Figure 3 shows one of the Senior Software Engineer Job ID JR205894.pdf files from this archive, which contains detailed job requirements.
Figure 3. A fake job description document, designed by the attacker to impersonate a global air carrier company.
Figure 4 shows the contents of the Hiring Portal.zip archive contained in the initial archive file.
Figure 4. Contents of Hiring Portal.zip.
Upon executing setup.exe, the malware triggers a spoofed error window titled Hiring Portal.zip to establish legitimacy with the target, as Figure 5 shows.
Figure 5. Spoofed Hiring Portal error window.
MiniUpdate: March Israel Campaign
This variant was delivered via an archive file, to impersonate an install file for a popular video conferencing platform. Our analysis reveals that this variant was recently deployed, no earlier than March 26, 2026, ostensibly against an Israeli entity.
Social Engineering and Initial Access
Analysis of sequential artifact uploads to VirusTotal from March 2026 provides a view into Screening Serpens’ social engineering tactics. The threat actor actively engaged with the target to deliver convincing lures. By correlating the timeline of these uploads, we can map the sequence of the attack:
Establishing trust: The target received a number of authentic video conferencing links, possibly to build trust during the phishing campaign.
Initial lure: Capitalizing on the precedent of legitimate links, the attacker delivered a lookalike domain to attempt to compromise the target: hxxps[:]//[redacted][.]live/meeting/edcdba624ddb43c2a1dcf334aa493068
Looking into the response reveals a phishing landing page designed to mimic an authentic meeting invitation. It uses the brand’s familiar styling and contains a "join from workplace app" button. The goal of this cloned frontend design is to trick a target into believing they need to install or update their client software to enter a scheduled meeting.
However, the page contains a payload, hidden within JavaScript code, which redirects the victim’s download request away from the legitimate servers. If the victim interacts with the page, a payload delivery is triggered from a third-party file-sharing service via the following URL: hxxps[:]//2117.filemail[.]com/api/file/get?filekey=T0EnWQ6NugHkW_kLfDxPBEw_um6NSkg9ZwNRQ_5lrKrLLUo35pV8m3TKv1LqF3zZzdUm
Payload delivery: The targeted lure tricked the victim into downloading the malicious archive from the impersonating website. This file served as the delivery archive for a malicious sideloading chain.
There is no indication that the attackers compromised or breached the impersonated organization’s infrastructure or systems. Their brand was only used in the context of impersonation to compel the victim to manually execute the malicious payload.
Figure 6 shows the contents of that archive. The first six files are part of the execution chain, while the last file is a genuine installer for the video conferencing application.
Figure 6. Contents of the zip archive.
MiniUpdate: Mid-April Middle Eastern Campaigns
In the attacks that may have targeted entities in the UAE and potentially another Middle Eastern country, we identified two new MiniUpdate variants, compiled and submitted to VirusTotal between April 15 and April 17, 2026. While the initial loading mechanism remains consistent with previous variants, leveraging the same impersonation decoy, this version introduces a few upgrades to its infrastructure and core capabilities.
In the variant that may have targeted an entity in the UAE on April 15, 2026, the threat actor rotated the C2 domains to impersonate a health sector entity, using:
PremierHealthAdvisory[.]com
PremierHealthAdvisory.azurewebsites[.]net
Premier-HealthAdvisory.azurewebsites[.]net
In the variant that may have targeted another Middle Eastern entity on April 17, 2026, the threat actor rotated the C2 domains to impersonate a financial sector entity, using:
Ramiltonsfinance[.]com
Ramiltonsfinance.azurewebsites[.]net
Ramiltons-finance.azurewebsites[.]net
Furthermore, the April variants feature an expanded command dispatcher with 18 distinct opcodes, two more than the earlier March campaigns. This increase is valuable to the attackers because it expands their toolkit for stealing data. The primary new command allows the malware to break large files into smaller chunks during upload, providing a stealthier and more reliable way to exfiltrate data from compromised environments.
The threat actor employed a .NET-specific code execution technique known as AppDomainManager hijacking. This method allows the attackers to hijack the execution flow of a legitimate application by manipulating its configuration file, granting them arbitrary code execution before the host application even starts. Consequently, the malware can preemptively disable logging mechanisms and other core features that endpoint security tools rely on to detect and block malicious activity.
At its core, this configuration relies on the <probing privatePath="."/> tag to force the local sideloading of an attacker-controlled assembly. It then instantiates a custom AppDomainManager type (such as MyAppDomainManager) to achieve this Pre-Main() execution.
However, the true sophistication of this variant lies in its native defense evasion directives. By adding just a few specific lines of XML, the threat actor instructs the .NET common language runtime (CLR) to proactively disable its own security mechanisms:
Silencing event tracing for Windows: The configuration includes the directive <etwEnable enabled="false"/>. Event Tracing for Windows (ETW) is the primary telemetry source used by modern endpoint detection and response (EDR) solutions to monitor .NET execution, track loaded assemblies and detect malicious behaviors in memory. By disabling ETW natively via the application configuration, the attacker potentially shrouds the EDR to the CLR's runtime behavior without needing to perform suspicious memory patching or API hooking.
Bypassing signature validation: The <bypassTrustedAppStrongNames enabled="true"/> directive instructs the CLR to skip strong-name signature validation. This ensures that even if the system normally requires cryptographic verification for loaded assemblies, the attacker's unsigned or tampered InitInstall.dll will load silently without throwing a security exception.
Preventing safe redirections: The XML configuration file includes <publisherPolicy apply="no"/>. Publisher policies are typically used by Microsoft to redirect application bindings to newer, safer or patched versions of an assembly. Disabling this default policy ensures that the CLR loads the attacker's localized payload and ignores any system-level overrides.
Forced runtime environment (safe mode): The configuration uses the <requiredRuntime safemode="true" imageVersion="v4.0.30319"/> directive. This parameter ensures the application executes in a highly controlled, predictable environment by requiring the exact specified version of the .NET runtime. By forcing this strict environment, the attacker reduces the risk of accidental application crashes, which would generate Windows error pop-ups and logs, immediately alerting the user or defenders that something is wrong.
Figure 7 shows the full XML configuration.
Figure 7. Contents of setup.exe.config.
This represents a mature living-off-the-land approach to execution. Rather than writing complex shellcode to unhook security monitors or patch ETW in memory, actions that often trigger behavioral alerts, Screening Serpens asks the .NET runtime to turn off its own security mechanisms via a legitimate configuration file. Combined with the Pre-Main() execution timing, the malicious InitInstall.dll payload runs in an entirely unmonitored, highly privileged context.
Stage 1: Installation and Creating Persistence
When the advanced .config file successfully hijacks the CLR initialization, it triggers the execution of InitInstall.dll. This C# assembly acts as the primary loader and installer for the second malware family, MiniUpdate.
Before staging the final payloads, the malware unpacks its configuration. The malware's static constructor uses a custom, two-step cipher to decrypt nine key configuration strings. First, the constructor reverses the input bytes interpreted as UTF-8. Next, it applies a standard ROT13 cipher to the alphabetic characters.
Once the strings are decrypted, the loader initiates a sequence that blends user interface (UI) deception with stealthy file staging and persistence.
1. The decoy UI and lure: To disguise the malicious activity happening in the background, the loader launches a background thread that renders a borderless, transparent window. This window displays a custom circular loading spinner specifically designed to mimic a legitimate installer progress indicator. This window has no taskbar entry, making it difficult for a user to inspect or close, as Figure 8 shows.
Figure 8. An interface window mimicking a legitimate installer.
2. Staging the MiniUpdate payload: While the fake spinner is displayed, the malware resolves its current directory and constructs a new hidden installation path under the legitimate local appdata directory of the video conferencing application’s folder.
The malware specifically adds a \bin\update folder to hold its files. If the directory does not exist, the malware creates it. The malware then copies and renames four files from the initial infection folder into this new directory:
setup.exe is renamed to update.exe
UpdateConfig.xml is renamed to update.exe.config
Updater.dll is copied as is
UpdateChecker.dll (the MiniUpdate payload) is copied as is
3. Establishing persistence: With the files staged, InitInstall.dll leverages Windows Task Scheduler to ensure the payload survives reboots. It creates a scheduled task that is configured to trigger every day at 09:30 local time.
Figure 9 shows the newly created scheduled task in a controlled test environment.
Figure 9. Task Scheduler window showing the associated scheduled task.
After a final 30-second delay, the loader forces the scheduled task to run immediately, starting the execution of Stage 2 by running update.exe.
Stage 2: Anti-Analysis Checks
When the scheduled task triggers the renamed setup binary (update.exe), the malware initiates a second AppDomainManager hijack to safely transition to the next stage. The threat actor uses the dropped update.exe.config file to reapply their native evasion directives, explicitly disabling ETW and strong name verification. This effectively hollows out the legitimate Microsoft process, allowing the next payload, Updater.dll, to load into an unmonitored memory space.
Operating entirely within this blinded environment, Updater.dll acts as a gatekeeper. Before deploying the core RAT, it ensures the malware is executing within the intended infection chain by performing two strict environmental checks:
Process verification: The DLL verifies that the current running process is named update.exe.
Sandbox evasion: It checks if the parent process is svchost.exe. Because the malware relies on a scheduled task to launch, svchost is the natural parent. If a security analyst or automated sandbox executes the file directly, this check will fail and the malware will silently terminate.
Once the environment is validated, the loader dynamically constructs the path to the final UpdateChecker.dll payload. It loads the module into memory and invokes the CheckForUpdates export, officially handing over control to the MiniUpdate RAT.
Figure 10 shows the full flow of this MiniUpdate malware.
Figure 10. MiniUpdate malware flow.
Stage 3: Payload Execution and Core Functionality
The MiniUpdate payload operates via external C2s and a compromised digital signature. This variant is driven by a 16-opcode dispatcher, giving attackers extensive control over file operations, shell execution and process manipulation.
C2 Architecture and Network Execution
This variant is designed to cycle through three different command servers in a specific order, checking each one for instructions:
The following user agent is used in the communication:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36
Digital signature misuse: This payload is digitally signed under the name of a software company whose signature appears to have been stolen or impersonated.
Operations security (OPSEC) shift (plaintext strings): MiniUpdate stores all API names, C2 domains and endpoints in plaintext within the .rdata section. This lack of string obfuscation suggests either a rushed deployment cycle or the involvement of a different development cell within the threat group. Conversely, the MiniJunk V2 samples featured heavy Mixed Boolean-Arithmetic and XOR obfuscation.
Core Capabilities
The analyzed payload functions as a highly versatile backdoor, granting the attacker near-complete operational control over the compromised host's file system, processes and environment. Command polling occurs via GET requests to the /agent/poll endpoint. The internal command dispatcher processes a Base64-decoded binary format and supports 16 distinct opcodes. Key capabilities include:
Arbitrary command execution: Executes shell commands via cmd.exe /c
Dynamic code execution: Loads arbitrary DLLs directly into memory to run specific exported functions
Process manipulation: Enumerates running processes and terminates them
Data exfiltration: Uploads files to the C2 server, including support for chunked uploads
Privilege escalation: Requests User Account Control (UAC) elevation
Persistence: Creates a logon-triggered scheduled task named WindowsSecurityUpdate, with built-in capabilities to remove or reinstall this task
MiniJunk V2 Analysis
We assess the second malware family identified in this campaign, MiniJunk V2, is an evolved version of the previously documented MiniJunk malware, featuring updated core functionalities. We correlate this malware family to Screening Serpens, based on the setup.exe file in the lure archive. As documented in Check Point reporting, the threat actor uses this exact legitimate binary to sideload their malicious payloads. Furthermore, we observed the same defense evasion tactics that Check Point's research outlined. Across all samples, the threat actor uses junk code and padding to artificially inflate the file size, successfully bypassing endpoint detection and scanning limits.
On Feb. 17, 2026, a MiniJunk V2 sample appearing to target an entity in the Middle East surfaced shortly before the regional conflict. Our visibility indicated another campaign on March 27, 2026, that may have targeted an entity in the U.S. one month after the conflict began. This timeline strengthens our assessment that the payload is a recently upgraded version derived from previously documented campaigns, illustrating a continuous cycle of development and deployment.
MiniJunk V2: February Middle Eastern Campaign
On Feb. 17, 2026, we identified evidence of a spear-phishing campaign targeting a professional working in the technology sector, based in a Middle Eastern country. Our analysis of the files in the malicious archive indicates that the preparation for this campaign and its malware development began in late 2025. The threat actor conducted careful reconnaissance, exploiting the target's active job-hunting footprint to engineer a customized lure. To establish legitimacy and coerce the target to execute their payload, the attackers shared a spoofed recruitment URL from a legitimate, well-known employment website.
Social Engineering and Initial Access
The threat actor initiated the attack by distributing a spoofed recruitment URL: hxxps[:]//[REDACTED][.]com/career/recreuitment/[REDACTED]. This endpoint currently returns an HTTP 404 Not Found status code, which we assess was a visual decoy intended to mislead the target.
The URL’s specific misspelling (recreuitment) indicates an intentional, fraudulent fabrication, engineered with the knowledge that the link would remain non-functional by design. Analysis shows no indication that the impersonated organization’s infrastructure, systems or domains were compromised or breached.
The group likely used this non-functional URL to prompt the target to take a work around solution into an offline portal. The target would then be redirected to a dedicated storage instance hosted within an attacker-managed ONLYOFFICE workspace. This infrastructure served as the delivery point for the primary payload, where the victim was induced to download a malicious archive disguised as legitimate recruitment materials
The attack execution advances when the victim complies with the lure instructions, manually retrieving and downloading the weaponized Portal.zip archive. This archive contains a file named Setup.exe and three hidden files. Since the default Windows settings do not reveal hidden files, a user would not normally see these three files. Figure 11 shows the contents of the archive.
Figure 11. Contents of the Portal.zip archive containing hidden files, with uevmonitor.dll used as the payload for the attack.
One of the hidden files is a malicious DLL named uevmonitor.dll that contains the payload for this attack. If a user runs the Setup.exe file, the action initiates an infection chain under the context of the logged-in user.
AppDomainManager: Sideloading and Hijacking
During our analysis of the MiniJunk V2 sample, we observed the threat actor using an older version of .config file to facilitate local sideloading. In this instance, the attackers authored a custom malicious DLL named uevmonitor and deployed it alongside a legitimate .NET executable. To successfully sideload their payload into the host process, they used the <probing privatePath="./"/> directive, forcing the application to prioritize its local working directory, which is a key prerequisite for DLL sideloading.
The original MiniJunk configuration lacked operational security measures such as evasion features, making it susceptible to detection. The attackers updated their newer tool, MiniUpdate, with stealthy evasion techniques. Figure 12 shows the original .config file, which was used only for sideloading the uevmonitor.dll file.
Figure 12. Contents of the .config file.
Technical Analysis of the Payload
Serving as the primary loader, the uevmonitor.dll assembly initiates the infection chain once executed by the initial, legitimate Setup.exe host process. It silently drops two embedded payloads into the local AppData directory:
SoftwareLicencing.exe: a renamed, legitimate Microsoft setup binary
unbcl.dll: the core malicious payload
To maintain its foothold, the loader creates a scheduled task for persistence named Synchronize OS and simultaneously displays a decoy system error to the user to mask this background activity. The sequence culminates when the scheduled task triggers SoftwareLicencing.exe, which specifically sideloads the malicious unbcl.dll into its trusted memory space. This action successfully deploys the heavily obfuscated RAT, granting the attacker operational control via externally-hosted C2 infrastructure.
Figure 13 demonstrates the entire flow to deploy the malicious RAT, including AppDomainManager hijacking and two DLL sideloading instances.
Figure 13. MiniJunk V2 malware flow.
C2 Loop and Network Execution
During execution, the malware dynamically decrypts data within its code to retrieve five C2 domains:
licencemanagers.azurewebsites[.]net
LicenceSupporting.azurewebsites[.]net
PeerDistSvcManagers.azurewebsites[.]net
ThemesManagers.azurewebsites[.]net
ThemesProviderManagers.azurewebsites[.]net
These domains mimic legitimate Windows service names, attempting to blend in with network communication.
Simultaneously, the malware uses Mixed Boolean-Arithmetic decryption to construct a hard-coded User-Agent string. The resulting string mimics legitimate Microsoft Edge browser traffic:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36 Edg/144.0.0.0
Behavioral analysis confirms that the malware interacts with specific API endpoints on the C2 servers. The endpoints implemented are:
/api/app/check: The initial beacon, handling victim registration and establishing the session.
/api/app/update: Retrieves execution commands and downloads subsequent payloads.
/api/app/comment: Exfiltrates data and sends operational status reports to the threat actor.
The malware’s .rdata section is packed with thousands of junk strings, including Java and Python tracebacks, SQL queries and .NET exceptions. These strings repeat every 0x1E50 bytes. This repetition serves two purposes:
Flooding string extraction tools with irrelevant data
Inflating the binary size to around 12 MB in an attempt to bypass file-size limits on certain automated sandboxes
The sideloading chain and malicious executable triggered Cortex XDR to flag this threat as high risk. It also prevented the threat from executing before any user interaction could take place. Figure 14 shows this detection and prevention.
Figure 14. The infection chain originating in malicious DLL sideloading (categorized "DLL Hijacking"), as seen, detected and prevented by Cortex XDR.
MiniJunk V2: March U.S. Campaign
While tracking the unique SoftwareLicencing.exe file, we discovered a newly developed malware variant that may have been deployed against a U.S.-based target. First submitted to VirusTotal on March 27, 2026, the malware is delivered within an archive named Portable platform.zip. This malware sample appears to have been actively developed and used during the recent regional conflict.
This latest iteration features a complex, multi-stage execution chain designed to evade detection. It relies on a social-engineering decoy graphical user interface (GUI) to deceive the target while quietly establishing a heavily obfuscated C2 connection.
Social Engineering and Initial Access
The infection begins with the Portable platform.zip lure archive, hosted on a unique ONLYOFFICE DocSpace: hxxps[:]//docspace-y4cumb.onlyoffice[.]com/storage/files/root/folder_3602000/file_3601577/v1/content.zip[...]
Figure 15 shows the archive content.
Figure 15. Contents of Portable Platform.zip.
Figure 16 shows the file folder content.
Figure 16. Contents of file folder inside Portable Platform.zip.
Upon extraction, the archive initiates a DLL sideloading sequence. The execution flow leverages the legitimate Setup.exe, which subsequently loads two malicious components:
Unbcl.dll: a social-engineering decoy
Connection.dll: the primary payload, a RAT
The execution of Unbcl.dll creates a background thread displaying a GUI to the target. The window is titled “Meeting Room” and prompts the victim to provide a “Meeting Room URL.” This provides a plausible reason for the execution, tricking the victim into believing they are joining a legitimate web conference while the primary C2 beacon operates silently in the background.
Figure 17 shows the decoy window.
Figure 17. A meeting room decoy window.
When the Connection.dll RAT runs, it follows a strict execution sequence:
It performs a hard-coded date-based validity check to ensure that the RAT runs on any date that is after March 27, 2026, 13:30:00 UTC. This validity check serves as an execution trigger that potentially enables the threat actor to avoid sandbox analysis, bypass initial security screenings and maintain a low profile until the predetermined operational phase begins.
If successful, the RAT spawns the main worker thread, constructs a file path using its internal name (SystemtUpdateTaskMachine.exe) and performs an instance check to ensure it is only running once.
Technical Analysis of the Payload
The Connection.dll payload is another RAT with multiple capabilities and defense evasion mechanisms.
Once in the main loop, the malware XOR-decrypts (using a single-byte key, 0x8A) data within its code to acquire a Chrome-based User-Agent string and three URLs using Azure-hosted C2 domains. These domains impersonate global companies operating within the technology, cybersecurity and artificial intelligence sectors:
hxxps[:]//NanoMatrix.azurewebsites[.]net
hxxps[:]//QuantumWeave.azurewebsites[.]net
hxxps[:]//ElementShift.azurewebsites[.]net
The malware beacons to the primary C2 base URL via an HTTP POST request. Depending on the parsed response, the malware will execute chunked uploads or downloads via specific transfer URLs or create additional threads for command execution.
Conclusion
The continuous tracking of the Iran-nexus APT group, Screening Serpens, reveals a persistent threat group that has remained active in recent months. The group has increased its operations since the regional conflict that started in February 2026, deploying two families of RAT variants across entities in up to five different countries.
A defining characteristic of these recent campaigns is the deep personalization of the attackers' lures. By leveraging tailored social engineering tactics, including fake job requisitions and spoofed video conferencing meeting invitations, the attackers lure victims into initiating the infection chain, thereby exposing their organizations to further exploitation.
We observed a significant evolution in the group’s tradecraft: For the first time, Screening Serpens has fused its standard DLL sideloading techniques with advanced AppDomainManager hijacking. By weaponizing the .NET initialization process and manipulating legitimate configuration files, the group can now preemptively bypass traditional security telemetry and execute payloads before most standard endpoint defenses are fully initialized. This tactic effectively allows attackers to establish persistence and maintain full operational control over the exfiltration of sensitive data.
Instead of relying solely on known malware indicators, defenders should ensure that EDR tools are fine-tuned to detect DLL sideloading and AppDomainManager hijacking. Treating these specific execution techniques as high risk will help organizations to identify behavioral anomalies associated with trusted, signed binaries loading untrusted modules.
As of April 2026, Screening Serpens activity shows no signs of slowing down and has continued to orchestrate sustained, adaptive global cyber campaigns. Organizations may expect further attempts in the near term and should harden their defensive posture to prepare for potential compromise attempts.
By leveraging its cutting-edge ecosystem, Palo Alto Networks customers are better protected from the threats discussed above through these industry-leading products:
The Advanced WildFire machine-learning models and analysis techniques have been updated to protect against the indicators shared in this research. Advanced WildFire is powered by Precision AI.
Cortex XDR and XSIAM help to prevent the threats described in this article, by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, to prevent both known and unknown malware from causing harm to endpoints — all in a single interface.
Cortex Cloud customers are better protected against operations that target cloud environments through the proper placement of Cortex Cloud XDR endpoint agent and serverless agents. Screening Serpens’ use of cloud infrastructure to host command and control endpoints points to cloud architecture functionality. Cortex Cloud is designed to protect a cloud’s posture and runtime operations against the threats outlined here. It also helps detect and prevent malicious operations, configuration alterations and exploitation within cloud environments.
Cortex AgentiX Agentic Assistant streamlined our investigation by enabling the team to query the data using natural language, providing deeper context and insights, and suggesting clear recommendations on what we should do next. Figure 18 shows the AgentiX interface when querying for malicious activity in a tenant.
Figure 18. Querying for malicious activity in the tenant, using AgentiX.
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.
ROADtools is a publicly available toolkit for offensive and defensive security purposes that attackers have integrated into cloud attacks. The tool is designed to:
Enumerate Entra ID
Register devices in Entra ID
Acquire, exchange and manipulate Microsoft Entra ID tokens
ROADtools is an open-source framework written in Python and built for red-teaming and research. It primarily targets the identity and authentication layers of Azure, and focuses on how accounts, applications and tokens operate in tenants.
To avoid detection, ROADtools operates through legitimate Microsoft APIs and can mimic typical traffic. Further defense evasion can be achieved by configuring request attributes such as user-agent strings. These capabilities have made ROADtools a valuable asset for attackers. Nation-state threat actors have used it in recent cloud intrusions for discovery, persistence and defense evasion. Attackers involved in a targeted phishing campaign in early 2025 used tooling that matches ROADtools' token management capabilities.
We provide an accessible overview of ROADtools, including how it evades detection and how nation-state threat actors and other adversaries misuse it. To aid defenders in protecting organizations against this threat, we also provide:
Straightforward hunting queries that can reveal ROADtools usage
Practical recommendations to detect and prevent the effectiveness of ROADtools within an environment
Palo Alto Networks customers are better protected from the threats described here through the following products and services:
ROADtools is able to interact with Entra ID via legitimate APIs, and to customize user-agent strings — both of which help it to evade detection. The tool includes several modules — two of which we discuss in this article - and a set of shared libraries.
The ROADrecon Module
The roadreconmodule is designed for internal discovery and enumeration. It gathers organizational data and identity information from Entra ID (formerly Azure Active Directory), including:
Users
Groups
Roles
Devices
Service principals
Applications
Directory configurations
Results are stored in a local SQLite database that can be viewed through a custom web interface. This provides a graphical way to navigate the tenant and identify relationships or privileged objects that attackers could use for persistence or escalation. Figure 1 shows Entra ID Groups within the ROADrecon graphical web interface.
Figure 1. Entra ID Groups in the ROADtools web interface.
The roadrecon module originally queried the Azure AD Graph API to enumerate Azure AD resources. However, Microsoft has stated the Azure AD Graph API is being retired and all new or existing applications must migrate to Microsoft Graph API, which breaks a fundamental component of the original roadrecon functionality.
As of May 2026, an msgraph branch exists in the official ROADtools Github repository but has not been updated since April 2025. Subsequent development has continued in a separate, community-maintained fork, where partial roadrecon functionality has been implemented using the Microsoft Graph API. This fragmentation means users might encounter inconsistent functionality, while attackers can still enumerate Entra ID accounts and resources, as described in the Discovery section below.
The Token eXchange (roadtx) Module
The roadtx module facilitates token acquisition and exchange, enabling attackers to interact with Entra ID’s authentication endpoints. It supports several OAuth 2.0 and OpenID Connect authentication flows (sign-in methods), including:
Entering a device code from another device (device code flow)
Reusing a refresh token to get new access
Allowing an application to request access on behalf of a user (known as an on-behalf-of or OBO flow)
The output of roadtx is typically a set of OAuth 2.0 access and refresh tokens in JSON format, which can be used to authenticate against Microsoft cloud services. The roadtx module can be used to register devices with Entra ID, replay stolen tokens and manipulate token lifecycles. This capability allows attackers to persist in an environment and bypass multi-factor authentication (MFA).
Supporting both roadrecon and roadtx is roadlib, the library layer that handles low-level authentication and API requests. The roadlib module provides the core functionality for ROADtools. It abstracts much of Microsoft’s authentication complexity, allowing an attacker or researcher to script token requests and API calls without having to know every OAuth detail.
This module is flexible and can be pointed at different API endpoints, including custom or non-Microsoft endpoints. This feature makes ROADtools easy to adapt to other security tooling and enables it to target a wider range of authentication systems.
With the above functionality in mind, the rest of this article explains how adversaries leverage ROADtools to perform their operations and what defenders can do to protect against ROADtools.
Threat Actor Usage and Industry Targeting
The use of ROADtools has evolved from a red-team utility to an attack tool. Industry reports illustrate that various nation-state threat actors are leveraging the tool to conduct malicious activity:
Early observation of a nation-state actor operationalizing the ROADtools framework came in late 2021, when Microsoft reported on activity by Cloaked Ursa (aka Midnight Blizzard or APT29). The group’s campaigns began with highly targeted spear phishing to gain initial access. Cloaked Ursa subsequently leveraged ROADtools to conduct discovery and enumerate victims’ Azure AD (now Entra ID) environments.
Microsoft reported the Iranian state-sponsored threat actor Curious Serpens (aka Peach Sandstorm, APT33) using ROADtools in malicious operations in 2023. After gaining initial access through password spray attacks, the threat actor used tools, including ROADtools for internal discovery.
Volexity reported in 2025 on a targeted phishing campaign during which a state-affiliated threat actor, which it calls UTA0355, was able to register a rogue device with Entra ID. Attackers were able to acquire a new token with full access to the Microsoft Graph API. The tooling Volexity reported matched the roadtx module’s token management capabilities.
MITRE ATT&CK® Tactics
MITRE ATT&CK provides a structured way to describe how attackers operate. Organizing findings by MITRE ATT&CK Tactics, Techniques and Procedures enables defenders to:
Map attacker behaviors to a common language
Compare those behaviors across intrusions
Prioritize detections and mitigations based on the actions attackers take
In the sections that follow, we reference specific MITRE techniques to show how ROADtools components enable those behaviors, including:
The ROADtools roadtx module can register new devices in Entra ID. Attackers register or join devices to gain a durable means of persistence through a controlled account. Registration allows a rogue device to appear as a legitimate object in the Entra ID device inventory. Depending on the Entra ID configuration, a registered or joined device may also enable attackers to bypass MFA and conditional access policies (CAPs).
To register a device using roadtx, an attacker must first obtain valid credentials. The attacker can then use these credentials with roadtx to authenticate via one of the supported authentication flows, to acquire an access token for the Azure device registration service (urn:ms-drs:enterpriseregistration.windows[.]net).
After authentication, the attacker runs roadtx again, which calls the Azure device registration API to create a new device entry. The roadtx module writes the device certificate and key to the local file system and registers the device in Entra ID. Note that roadtx has default values for some command parameters. Unless specified otherwise, the devices will be registered as:
OS: Windows
OS Version: 10.0.19041.928
Name: DESKTOP-<RANDOM 8 DIGITS>
While these default values can be useful for detection purposes, they are also simple to change. All defaults can be viewed by running roadtx device -h from the command line, or by viewing them in the roadtx source code.
Figure 3 shows how an attacker uses a previously acquired refresh token to authenticate to the Azure device registration service and register a new device with the name mydevice.
Figure 3. An example of roadtx access token acquisition and device registration.
Defense Evasion
Technique: T1550 Use Alternate Authentication Material (Figure 4).
Figure 4. MITRE ATT&CK technique T1550.
Attackers try to acquire tokens because those tokens let them access company data and cloud services on behalf of a user or service, often without triggering a new interactive sign-in, enabling activity that blends in with legitimate API usage. Tokens allow attackers to move laterally, copy data and obtain persistent access in a target environment, bypassing interactive controls like MFA.
By leveraging a Primary Refresh Token (PRT), an attacker can maintain access to cloud applications by silently obtaining new access tokens in the background, which are then used in subsequent API requests, eliminating the need for repeated logins. The roadtx prt command allows attackers to acquire such a PRT. Full details of the process for registering a device and PRT acquisition are described by the ROADtools author.
Using roadtx, attackers can automate the misuse of a stolen PRT. This automation involves performing the token exchange and API call workflows that are needed in order to acquire fresh user access tokens and to call services such as Microsoft Graph non-interactively. A single device-bound PRT compromise can provide an attacker with persistent, programmatic access across the tenant.
Discovery
Technique: T1087 Account Discovery (Figure 5).
Figure 5. MITRE ATT&CK technique T1087.
Attackers perform account discovery to map an environment, identify high-value accounts and find lateral movement or privilege escalation targets. Ongoing efforts within the ROADtools community to adopt the Microsoft Graph API have enabled continued use of roadrecon for account discovery.
To use roadrecon for discovery, attackers must first authenticate to acquire the refresh and access tokens that allow access to the Microsoft Graph API. The authentication must use a client ID that has the necessary permissions for all the Microsoft Graph API endpoints that they wish to enumerate.
The Microsoft Graph API version supports a new roadrecon command-line parameter -mg that points the code to the Microsoft Graph API to enumerate resources such as:
/users
/groups
/devices
/servicePrincipals
/applications
This enumeration enables attackers to harvest account names, devices, roles, group membership and service-principal metadata. These are written to the local SQLite database as previously noted.
Figure 6 below lists devices registered in Entra ID as shown in the ROADtools custom web interface. This example is from a test environment but serves to illustrate the ease of discovering resources in the environment. Note the OS Version 10.0.19041.928 circled in red. As described earlier, this is currently the default value that roadtx uses when registering a device, and is different than the OS version for the other hosts, making it a good indicator of ROADtools activity.
Figure 6. ROADtools custom web interface.
Defender Perspective
The discussion so far has focused on how adversaries can misuse ROADtools. It is equally important to understand what defenders can do in response. Preventive controls and active threat hunting offer organizations multiple opportunities to detect and disrupt these techniques.
Preventive Controls to Limit Token Misuse
ROADtools is challenging for defenders to detect because it operates within expected behavior. It does not exploit buffer overflows or drop binaries onto hosts, but instead uses the authentication flows and APIs that organizations rely on every day. Implementing layered identity defenses can limit how attackers misuse ROADtools. Defenders should consider the following controls:
Enable Entra ID token protection: Enabling token protection reduces the value of stolen refresh tokens. Binding refresh tokens to a specific device (token protection/“client claims”) is one of the most direct ways to prevent the replay or misuse of tokens obtained by roadtx. This makes it harder for adversaries to export and reuse tokens from other hosts.
Restrict device code flow via conditional access: CAPs can restrict risky flows, such as device code, where they are not needed. Attackers use roadtx to misuse device code flow because it works well for script-based attacks. Blocking or restricting this flow to only trusted scenarios (like registered devices, trusted IP address ranges or specific apps) cuts off an attack path.
Audit OAuth apps regularly: Auditing applications for delegated and application permissions that have been granted helps eliminate excessive privileges that attackers target. Attackers can use roadtx to obtain tokens for any registered app if permissions are in place. Custom or abandoned apps with overly broad Microsoft Graph, SharePoint or Exchange permissions are prime targets. A cloud security posture management (CSPM) or cloud-native application protection platform (CNAPP) solution can help defenders conduct regular reviews, to reduce the attack surface.
Limit privilege exposure: Even if an attacker manages to obtain a token, organizations can greatly reduce potential damage by using privileged identity management (PIM) or privileged access management (PAM) to limit standing privileges and conditional access to require step-up authentication. These measures enforce least privilege and minimize the impact of a compromised account.
Correlate logs across multiple sources: Detection and threat hunting depend on event correlation. Prepare for this by bringing Azure audit logs, Microsoft Graph API activity logs, sign-ins and Office 365 activity together into a security information and event management (SIEM) platform to provide the visibility needed to spot anomalous API usage.
These controls help prevent and detect common attack techniques and lay the groundwork for effective threat hunting. With these controls in place, defenders can more effectively search for suspicious token usage, authentication flows or discovery activity before they escalate into compromise.
An attacker using roadtx for authentication is using valid credentials. As such, defenders must establish a baseline of normal activity for that user or resource to understand whether a sign-in is malicious or legitimate.
Microsoft Entra ID Protection provides two important reports for this purpose:
Risky sign-in reports surfaces attempted and successful user access activities where the legitimate owner might not have performed the sign-in
Risky user reports surfaces user accounts that might have been compromised (e.g., a leaked credential that was detected or the user signing in from an unexpected location in the absence of planned travel)
Hunting ROADtools Activity
With preventive controls in place, the next step is to actively look for signs of misuse. Threat hunting in this context goes beyond reviewing alerts. It requires systematically searching for anomalous patterns in device joins and registrations, and for token issuance and Graph API calls that could indicate suspicious roadtx or roadrecon activity.
Device Registration
Start by looking for evidence that adversaries are running ROADtools to register or join devices into Entra ID. Inspect audit events that relate to device registration, highlighting which users or service principals initiated the action. The broader objective is to detect when an attacker attempts to establish persistence in Entra ID by creating and controlling unauthorized devices.
Token Misuse
Next, look for evidence of token misuse. We have discussed how roadtx and roadlib are designed to acquire and refresh tokens programmatically. To defenders, that activity looks different from a standard browser or app sign-in. These differences include:
Scripted user agents
Service principals authenticating outside of expected patterns
Automated sign-in behavior that doesn’t resemble human use
The goal is to flag when an attacker is misusing tokens to blend in with legitimate activity while running scripted, malicious roadtx commands against the tenant. For example, an attacker may run roadtx with a version of python-requests (a Python library that supports HTTP) that is not usually seen in an organization's environment. Or even simpler, sign-ins via Python might not be expected in an organization at all, or only from certain IP ranges.
Microsoft Graph API
Finally, look for evidence of attackers using roadrecon to access the Microsoft Graph API and enumerate users, groups, service principals, applications and devices. These discovery activities are not limited to ROADtools and can be performed directly through Microsoft Graph API calls using custom scripts or other tooling.
For defenders, the key is to watch Microsoft Graph API logs for bursty, repetitive queries against those endpoints. Legitimate administrators rarely perform these actions in bulk. Defenders must migrate any roadrecon detections that rely on Azure AD Graph activity logs to use Microsoft Graph activity logs instead.
Conclusion
ROADtools is an example of the dual use of security tooling. Released as a framework to interact with Azure AD for offensive and defensive security purposes, attackers have adopted ROADtools as a platform for real-world intrusions against Microsoft cloud environments. We have seen how its features map to MITRE ATT&CK techniques, and identified the alignment with attacker tactics of persistence, defense evasion and discovery.
For defenders, the challenge lies in ROADtools’ use of legitimate APIs and authentication flows. ROADtools activity can easily blend into normal cloud operations. Identifying malicious use of this toolset requires careful attention to anomalies in user agents, IP addresses, activity type and Graph API usage. Mitigations like token protection, conditional access policies, cloud security audits and privileged identity management provide additional layers of defense.
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected from the threats described here through the following products and services:
Cortex Cloud endpoint protection can help protect organizations from threats expressed within this article. Cortex Cloud 2.1 can detect and prevent malicious operations through the use of behavioral and AI enabled analytics to detect when cloud and container endpoints are targeted. Additionally, it can detect when cloud platform IAM policies associated with those targeted endpoints are being misused and alert teams when assets are vulnerable to these threats.
Cortex XDR and XSIAM customers can use the hunting, investigation and detection queries below to identify potentially suspicious activity related to the threats discussed in this article. In addition, Cortex Identity Threat Detection and Response (ITDR) can help in detecting authentication and credential-based threats by analyzing user activity from multiple data sources including endpoints, network firewalls, Active Directory, identity and access management solutions, and cloud workloads.
The Unit 42 Cloud Security Assessment is an evaluation service that reviews cloud infrastructure to identify misconfigurations and security gaps.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Hunting, Investigation and Detection Queries
The queries below are designed to help Palo Alto Networks customers hunt for, investigate, and identify potentially suspicious activity using Cortex XDR. Results returned by these queries should not be considered inherently malicious and require further analysis to determine their significance.
Cortex XQL Queries
Device Registration
The XQL query below hunts for threat actors using ROADtools to register or join devices in Entra ID, focusing on audit events that reveal initiating identities and potential attempts to establish persistence through unauthorized device creation. Depending on the environment in which this is run and in what timeframe, the query could return a large set of results. A 24-hour timeframe spanning any suspicious activity is a good starting point. Look for results from unexpected or suspicious locations or identities. Also, look for any device names that do not conform to expected naming conventions in your organization.
The following query looks for evidence of token misuse, as roadtx and roadlib generate authentication patterns that might differ from regular user sign-ins. Focus on anomalies like scripted user agents, unusual service principal activity, and automated sign-in behavior – such as unexpected Python-based access – that may indicate threat actors executing malicious actions.
The following XQL query looks for roadrecon activity by monitoring Microsoft Graph API logs for high-volume, repeated enumeration of users, groups and applications – behavior uncommon for legitimate administrators. We built the following hunt query to detect this enumeration pattern, revealing when a threat actor is systematically mapping out the directory. The API call threshold should be adjusted to values indicating outliers in your organization.
This article documents novel activity clusters that have significant overlap with the publicly described threat known as TamperedChef (aka EvilAI). TamperedChef-style malware is trojanized productivity software, such as PDF editors or calendars, that deliver malicious payloads.
These campaigns typically employ malicious ads that direct users to sites hosting the applications. While this style of malware shares many similarities in technical operation, installation lures and distribution methods, we do not attribute it to a single author or group.
TamperedChef-style malware samples share characteristics with potentially unwanted programs (PUPs) and adware. These include robust mechanisms to remain persistent, and end-user licensing agreements (EULAs) that attempt to legally cover the software's questionable actions. However, TamperedChef-style malware is far more stealthy than PUPs or adware, remaining dormant for weeks to months before activating. This includes continuous command and control (C2) methods enabling adversaries to retrieve additional payloads, such as information stealers, proxy tooling or remote access Trojans (RATs).
We have been tracking several campaigns of TamperedChef-style activity starting in 2024, with three distinct clusters: CL-CRI-1089, CL-UNK-1090 and CL-UNK-1110. Between the three clusters of activity, we have identified over 4,000 samples across 100 unique variants.
Palo Alto Networks customers are better protected from TamperedChef activity discussed in this article through the following products and services:
Since early 2024, we have observed a sharp increase in information stealer-style incidents originating from software mimicking legitimate productivity tools (e.g., PDF editors, ZIP file extractors, GIF image makers). Upon deeper inspection, these applications generally contain code that enables the delivery of arbitrary binaries. These features are typically used to deploy stealer malware.
In 2025, our telemetry revealed over 100 unique variants of malware masquerading as productivity software. They all contained a malicious component, such as basic RAT capabilities, or delivering adware and infostealers.
Due to their legitimate functionality and tendency to remain dormant for long periods of time, these applications often go unnoticed by the victim. They are also commonly downplayed or miscategorized by defenders and security researchers as potentially unwanted programs (PUPs). Because these applications can execute arbitrary code on victims' machines, either directly or indirectly through module loads, these threats are more significant than mere background annoyances or adware.
We have been able to track over 4,000 file hashes and 81 unique code signing organisations through several methods, including:
Reviewing code-signing certificates of the binaries
Analyzing code reuse among the binaries
Open-source intelligence (OSINT) on corporate structures for organizations distributing the binaries
Leveraging ad transparency platforms to hunt for advertising overlaps that can identify additional organizations distributing the binaries
We have identified TamperedChef-style malware campaigns starting in 2023. These malicious productivity application campaigns include AppSuite PDF, Calendaromatic, JustAskJacky and CrystalPDF.
Masquerading in Plain Sight
The actors behind these campaigns take steps not commonly observed with other adware groups to remain undetected. In some cases, these attackers appear to diversify their revenue streams through more aggressive and malicious activities. This diversification includes deploying infostealers, establishing residential proxies and exhibiting behavior that resembles access brokers.
These applications avoid many of the common indicators that users are trained to associate with downloading malicious software, such as:
Distributing via well-built, legitimate-looking websites
Without ads (as shown in Figure 1)
Appearing modern and credible
Containing common elements like descriptions, legal terms and contact pages
Leveraging unique and contextually relevant domains for each campaign
One-click download buttons distributed by large content distribution networks (CDNs) to minimize friction
Providing promised functionality with minimal bloat, meaning victims are not likely to suspect anything is amiss
Figure 1. Examples of download pages for TamperedChef-style fake productivity applications.
Attackers also employ several tricks to avoid detection. These tricks include:
Using code signing to increase the apparent legitimacy of the binaries
Rebuilding binaries with only minor changes on a frequent basis to minimize the effectiveness of static or hash-based detection
The exact frequency varies, but is typically between one week and one month per rebuild
Remaining dormant for periods of weeks to months before retrieving or running malicious components
This combination of technical and social masquerading enables these applications to remain undiscovered, unreported and free to operate without resistance for months — if not years — at a time.
What Is Adware vs. Malware?
Adware is a class of software designed to increase the number of ads a user observes. The more ads they observe, the more money for the distributor. This is typically done with some form of browser manipulation or additional free tooling bundled alongside downloads.
Adware sits in a middle zone between malware and legitimate software, often employing malware-like tactics to maintain persistence or display more ads to users. The distinction between malware and adware can be so fine that they are indistinguishable from each other when statically analyzed, only becoming clear after misuse occurs. Adware and malware are also often interlinked, with many seemingly legitimate adware developers overstepping into malware territory, either naively or intentionally.
Modern adware also walks the line between legal and illegal behavior. EULAs are ways that the groups behind adware and TamperedChef-style malware attempt to protect themselves legally. Examples of this are found on websites distributing TamperedChef-style software, such as one from hxxps[:]//www.crystalpdf[.]com/conditions:
“The Additional Services offer users enhanced, tailored features. Be aware that using these services may modify your browser’s new tab settings or installed features, possibly altering your browser configuration.”
However, TamperedChef-style programs execute commands remotely, exfiltrate users' credentials and deploy malware without consent. These actions firmly place them in the malware category.
A Historical Review of TamperedChef (Aka EvilAI)
The name TamperedChef was initially given to a cluster of activity that included several malicious recipe applications, PDF editors, manuals and search assistant applications. It started to see widespread installation in June 2025, with some evidence suggesting these applications have been in the wild since February 2025.
As reporting on malicious productivity apps within the cybersecurity community grew, TamperedChef became a broad, informal term for several productivity software campaigns. These campaigns are likely not all operated by the same group.
The confusion in previous reporting is understandable, as many of the actors are leveraging extremely similar tactics, techniques and procedures (TTPs) and lures. The differences only become apparent when observing the infrastructure, code quality and organizations tied to the code signing. It is important to understand these differences to separate the attackers' motivations, capability and risks.
We identified and tracked three major clusters of activity that share many of the same operational traits, but we believe these represent three distinct groups. We track the three main activity clusters as CL-CRI-1089, CL-UNK-1090 and CL-UNK-1110.
The CL-UNK-1110 cluster is most commonly associated with the TamperedChef alias and includes campaigns distributing applications such as:
JustAskJacky
GoCookMate
RocketPDFPro
ManualReaderPro
Acronis has researched and reported on this cluster in detail. While this cluster remains active and significant, the primary focus of our analysis will be on the two other clusters, CL-CRI-1089 and CL-UNK-1090.
The CL-CRI-1089 cluster has been identified as active since early 2023. It includes several high-profile campaigns distributing applications such as:
Calendaromatic
DocuFlex
AppSuite PDF
These campaigns leverage a diverse set of deployment methods and show the most change when it comes to the malware’s techniques and tactics. This group leveraged infrastructure and code-signing certificates related to Ukrainian, Malaysian and British entities, which has remained consistent over the last two years of operation.
CL-UNK-1090 is unique in its clear evidence of vertical integration between marketing and malware creation. Similar to other clusters, the group behind this cluster distributes its malware via malicious advertisements (aka malvertisements).
A review of public records on corporate structures shows that, unlike the other groups, CL-UNK-1090 operators own both the code-signing companies and the ad agencies distributing the malware. This cluster used primarily Israeli infrastructure and code signing entities. It is responsible for several recent campaigns, including:
CrystalPDF
Easy2Convert
PDF-Ezy
Victimology
We have observed approximately 12,000 unique instances of this fake productivity software across our customer base. Our analysis shows that this threat is global with no significant geographic or sector targeting within the Managed Threat Hunting customer base.
The data highlights that while Israel and the U.S. see slightly higher targeting than other countries, TamperedChef-style malware is seen globally in non-negligible volumes.
This is consistent across all three clusters, indicating that they all appear to operate globally.
Tracking TamperedChef-Style Samples
Understanding the capability of these threats is crucial to detection, response and disruption. Fortunately, the malware operators have made several design decisions that we can leverage to identify and link large portions of their operations.
Tracking via Code-Signing Certificates, Code Reuse and Infrastructure Overlaps
One unique attribute of the TamperedChef-style malware is that almost all the first-stage binaries are signed with legitimate code-signing certificates. Attackers used code-signing to add stealth to these payloads. However, a lack of proper certificate hygiene allowed us to follow these samples further than any one campaign.
We initially identified code signing reuse with the Calendaromatic campaign. This campaign involved a simple Neutralinojs framework-based calendar app, contained in a 7z self-extracting archive (SFX). The calendar app would operate as expected, but it also contained a relatively basic RAT that enabled attackers to collect and install a second-stage payload.
This campaign gained some attention due to its novel use of homoglyphs to obfuscate the incoming command strings. The 7zSFX when extracted contains both a calendaromatic-win_x64.exebinary that is essentially just a wrapper for the real bulk of the code, a heavily obfuscated Neutralinojs resource file named resources.neu.
Public reporting highlighted that the 7zSFX file was signed by CROWN SKY LLC. Digging further through malware repositories, we identified four total files with the same core behavior of a 7zSFX file containing a calendaromatic-win_x64.exe binary and a resources.neu file. The resources.neu file varied across the samples. However, all appeared to contain similar functionality with differing C2 locations.
Of these four samples identified, we identified two unique signers. Samples one and two were signed by CROWN SKY LLC and sample three was signed by MARKET FUSION INNOVATIONS LLC. The final sample was found to not be signed and may not have been deployed widely.
Code-signing certificates are considered private material and not commonly shared between entities. A single code base signed by two uniquely authored certificates generally indicates that a single entity or actor is in possession of both code-signing certificates. This can occur for several reasons, including certificate theft, a single entity with ownership of two or more organisations (e.g., shell corporations) or organisations providing code signing as a service.
Reviewing sample repositories for evidence of this new signer, we found two additional campaigns that we identified as related to the Calendaromatic operators: PDFPrime and ManualzPDF. Both PDFPrime and ManualzPDF campaigns share striking similarities and likely share a codebase.
Similarities between the samples include:
The same C2 domain structures
Shared code signing dates
Shared embedded PDF editors
However, these samples are very distinct from the Calendaromatic campaign, sharing no code. This highlights attackers’ preference to abandon codebases upon discovery rather than iterate and evolve. Figure 2 below shows a simplified view of these certificate chains.
Figure 2. Simplified signature flow of reuse between samples.
The PDFPrime and ManualzPDF campaigns have several distinct variants, all with different code signers. Due to the high degree of code overlap, we clustered 34 samples to the PDFPrime/ManualzPDF codebase. We call these samples PixelCheck due to the C2 domains leveraging the format of pixel.toolname[.]com. They represent some of the earliest evidence of the Calendaromatic operator’s activity originating in late 2023.
Pivoting through sample repositories to identify other examples of the PixelCheck variant, seven additional signers were identified in the code of related malware:
ADVANTAGE WEB MARKETING LLC
Europae-Solutio Ltd
SP Development and Solution Limited
BUZZ BOOST ADVERTISERS LLC
ADSMARKETO LLC
LLC MATCH-TWO-USERS
Monetize forward LLC
Tracking these samples via code signing overlaps involves:
Identifying the code signers
Mapping their certificate chains
Pivoting to similar samples
Repeating the steps with newly identified signers
This iterative approach uncovered an extensive network of seemingly disparate samples, all linked to a single group through certificate ownership.
While effective, this discovery method relies on lax operational security. True certificate isolation would prevent expanded identification and limit certificate burning.
Reusing code signing across variants also does not appear to be a cost-saving measure, as multiple campaigns often use unique signers rather than reusing a small set of certificates. If cost minimization was the primary goal, we would not see these cases of individual certificate use.
Certificate reuse most commonly appears to be a result of poor testing practice, where attackers use previous certificates on early samples of a new campaign before they can procure a dedicated certificate.
At the current cost of code-signing certificates, burning more than two certificates per campaign carries heavy financial costs. As a result of this research, we attributed a total of 34 unique code-signing certificates related to the Calendaromatic campaign to the CL-CRI-1089 cluster.
Based on the current cost of code-signing certificates, this inefficient approach likely cost the operators over $10,000 in certificate expenses alone. This further highlights the scale of this operation, where this sum is likely considered a reasonable operational cost.
Tracking via Advertising
Much of the TamperedChef-style malware distribution is via ads, and as such it is subject to ad transparency. Ad transparency is a byproduct of regulation requiring players in the distribution of advertising to provide insights into ad content and owners. Many of the major platforms in the space have their own version of an ad transparency tool or dataset, and investigators can use these to map and track malvertising campaigns.
In most cases, ad transparency platforms enable searching either by the advertiser or the site being advertised. While the definition of an advertiser can be complicated, for the most part, the advertiser is the entity that sold or is selling an ad within the platform.
This means there is no guarantee that the malware operator and the ad seller are the same or related entities. However, it implies that the malware operator has interacted with the advertiser in some capacity (e.g., exchanging funds or ad details). Advertisers using these advertising marketplaces are held to certain standards by the platforms and must abide by the terms of service, which distribution of malware would typically breach.
TamperedChef-style campaigns are different from many other malvertising campaigns, as the malware creators and advertisers are generally vertically integrated. This vertical integration means advertisers also create the malware and, on occasion, sign the code. This direct link between code signers and advertisers implies a strong relationship between malware operators and distributors. This link can provide a starting point to map the wider network distributing this malware.
This is particularly evident with activity in CL-UNK-1090 being run by attackers that are clearly well versed in using ad marketplaces to distribute their malware. For CL-UNK-1090, we identified more than 20,000 unique ads deployed over several years via ad transparency platforms. This volume of ads is unlikely to originate from an individual. The OneZip campaign belonging to the CL-UNK-1090 cluster provides a real-world illustration of how tracking these clusters through advertising commonality and agencies works.
OneZip is a malicious compression tool with binaries signed by TAU CENTAURI LTD observed in the wild in early 2025. OneZip was distributed via the site onezipapp[.]com (Figure 3 shows the landing page).
Figure 3. OneZip landing page.
By leveraging ad transparency platforms, we find that a single advertiser (CANDY TECH LTD) creates and distributes ads for onezipapp[.]com. Based on information from these platforms, CANDY TECH LTD has distributed approximately 4,000 ads that appear related to malicious productivity applications starting in June 2024.
Figure 4 below shows an example of the ads distributed. While not the most innovative, attackers have taken care with these ads to consider language, format, logo and branding. This indicates an actor well-versed in the AdTech space.
Figure 4. Example OneZip ads run by CANDY TECH LTD.
Between June 2024 and December 2024, ad transparency platforms report that CANDY TECH LTD pushed ads for JustConvertFiles, a similar TamperedChef-style campaign. JustConvertFiles is a malicious file conversion tool similar in operation to all other TamperedChef-style samples.
JustConvertFiles binaries are signed by B.L.A ASPIRE LTD and PASTEL CONCEPTION LTD, and entities with these names are both observed reusing certificates. These entities appear to be responsible for several other campaigns, including:
PDFPilot
SwiftNav
ShinyPDF
FileEase
Based on advertising transparency data, we have not observed CANDY TECH LTD representing any campaigns other than TamperedChef-style malware.
CANDY TECH LTD is also observed in the malware creation stages, too. Several TamperedChef-style binaries are signed by CANDY TECH LTD or have other links to an entity with this name. These include:
ZipMakerPro
GifsMakerPro
ScreensRecorder
RapiDoc (contained a copyright stub with CANDY TECH LTD, but not signed)
We then performed the following activities to substantially flesh out CL-UNK-1090 and CL-CRI-1089, and to identify additional campaigns:
Leveraging known TamperedChef download URLs
Identifying the advertiser
Pivoting around the public information on these advertisers
These advertising pivots are not without limitations, and many malvertising actors do not have the expertise to set up the AdTech infrastructure, instead relying on established entities for distribution. This makes any sensible linking through public sources much more difficult, as most of the time, the malware advertising only accounts for a small percentage of the advertisers' overall ad presence. In these cases, other methods are likely to be more effective. However, when possible, investigating the distributor can provide more information.
Tracking via Co-location and Corporate Structures
The TamperedChef-style malware footprint is large and well-organised, with hundreds of campaigns and large sums of money invested. All TamperedChef certificates are validated by an organization, which means certificate authorities require a corporate entity to fulfill OV/EV requirements to be granted certificates.
Certificate issuers impose these validation requirements to aid in maintaining the reputation of signed code. There is a cost, of both money and time, for adversaries to establish a corporation for the sole purpose of signing code.
Corporate structures tend to leave traces, particularly in countries where data is publicly available. This opens new avenues for discovery.
OSINT sources such as private and government-run corporate search engines can be used to gain rapid insights into corporate entities. Our primary focus areas when tracking code-signing entities were:
Co-location, especially in residential dwellings
Companies with a handful of employees and minimal presence, especially when owned by much larger corporations, can indicate possible shell corporations
Shared ownership structures, particularly when shared ownership is by an individual and not a corporate entity
History of company renames (especially renames that are potentially aligned with malware campaigns)
With the CL-UNK-1090 cluster, we can use CANDY TECH LTD as an example again. Ad transparency data indicates that CANDY TECH LTD is registered in Israel. Leveraging Israeli company search engines, we found CANDY TECH LTD with a listed phone number, website, address and ownership structure.
Figure 5 below shows the webpage for CANDY TECH LTD.
Figure 5. CANDY TECH LTD webpage.
From public records, Zizik with me is the director of CANDY TECH LTD and Fairark Systems Ltd. consists of option holders for the company.
Zizik with me and Fairark Systems Ltd. are listed as having sole ownership stakes in several companies in Israel, such as:
AMARYLLIS SIGNAL LTD
TAU CENTAURI LTD
RED ROOT LTD
BITTERN SKY LTD
TOGO NETWORKS LTD
The list of companies that we mined from the Zizik with me and Fairark Systems Ltd. ownership structures — as well as some minor variations and co-location checks — match the names of companies that signed significant volumes of TamperedChef-style code. With high confidence, we believe these ownership structures link all cases to a single group.
Additionally, many of these companies have undergone several name changes in the past three years. Many of the old names match names that were used to sign TamperedChef-style malware.
Fairark Systems Ltd. is the registered name of FireArc, an Israeli advertising company. It states it creates games, connected TV applications, eCommerce solutions and, notably, utility applications. Figure 6 shows this statement on its website.
Figure 6. FireArc marketing pages stating they create utility applications.
Additionally, the RapiDoc campaign created by CANDY TECH LTD has a program database (PDB) (D:\!Work\Clients\<user>\Projects\RapiDoc\SrcForTests\RapiDoc\x64\Release\RapiDoc\RapiDoc.pdb). This could have been left by mistake in the RapiDoc binaries installed during execution.
PDBs are created during the build process for binaries and contain useful symbol and debug information. Binaries that are productionized tend to remove the PDB, as it can provide reverse engineers a head start when analyzing a binary, which is not desirable for either legitimate software or malware. PDBs, where applicable, were for the most part removed from other TamperedChef-style samples, indicating that this was likely an error.
The SHA256 hashes for the binaries containing the PDB are:
Leveraging several linking methods, we broadly identified significant portions of these activity clusters’ operations, mapping several networks of TamperedChef-style malware. While this may not represent their entire infrastructure, it highlights the pervasive nature of this threat. We supply all identified samples, domains, signers and any other relevant details in the Indicators of Compromise section.
CL-CRI-1089
Using Calendaromatic as a starting point, we mapped out the CL-CRI-1089 cluster to include 34 unique code-signing entities. Our primary method of identification was code and certificate reuse. We observed some evidence of shared corporate addresses with code signers. However, generally, each entity was separately created and operated.
The CL-CRI-1089 cluster included malvertisements generated through self-created and likely dedicated companies. This cluster did not appear to cross-contaminate advertising entities with code-signing entities. This cluster primarily leveraged companies based out of Ukraine, Malaysia, Singapore, the U.S. and the UK to perform operations. In cases where the owner's place of birth was recorded by the UK government, all owners were of Ukrainian origin.
We identified over 3,300 samples related to CL-CRI-1089 across Palo Alto Networks and public sample databases, with the vast majority related to productivity software.
CL-UNK-1090
We mapped out CL-UNK-1090 primarily through a combination of real-world incidents, OSINT on the FireArc corporate structures and advertising network links. Certificate and code reuse were present but formed less of a basis for discovery.
We found CL-UNK-1090 used 39 Israeli corporations for certificate generation. This cluster included changed organization names to mine these structures for multiple certificates, so the real number of organizations is likely less than 39. We identified approximately 750 samples related to CL-UNK-1090, all with productivity application themes.
Malvertising as a Service: How Did the Threat Scale?
The scale of TamperedChef-style malware is immense. We found evidence of the two tracked clusters (CL-CRI-1089 and CL-UNK-1090) across more than 50% of Managed Threat Hunting customers. If this number is an accurate representation of the wider community, it shows an operation on a scale rarely observed.
The distribution and scale of these campaigns come with high monetary and labor costs. TamperedChef-style actors are likely to have bought much of their success. They have positioned themselves less as malware experts than as advertising and logistics specialists.
Code signing as a practice provides authenticity and integrity validation to binaries, but it can be misused by malicious actors. Purchasing code-signing certificates offers a marginal increase in binary trustworthiness. However, they come with strict identity validation and cost, which can deter many malware developers.
These requirements did not impede any of the TamperedChef actors, and one of their key strengths comes from a deep understanding of the business side of advertising. The development of several shell companies appeared minimally impactful and provided a reusable pool of code-signing certificates. In the case of CL-UNK-1090, it appeared that renaming existing companies was enough to be granted new, valid certificates, further lowering the barrier for entry.
In recent months, we’ve identified a trend of these clusters moving away from code signing. This shift could be occurring because these binaries are becoming better understood and researched. The damage done by identifying an entire campaign through tracking code signers may now outweigh the benefits gained through signing binaries.
Buying Speed: The Influence of Distributed Development and AI
The rate and scale at which the TamperedChef-style actors deploy new campaigns is incredibly fast. Attackers run tens of campaigns simultaneously, with new ones being developed constantly.
The CL-CRI-1089 cluster, in particular, demonstrates a high degree of variation. Each campaign features an entirely new set of TTPs, delivery methods, languages, functionality and C2 structures. This suggests a new codebase for each campaign, and potentially even different developers.
The code quality also shows a lack of mature development practices and teams likely inexperienced with malware development. This does somewhat work in favor of TamperedChef binaries, as upon first glance, the C2 methods are not always obvious.
In the case of CL-CRI-1089, the codebases are highly variant. However, they share common certificates, demonstrating limited code reuse between campaigns. This may indicate they were created by several development teams or that generative AI was at least partially responsible for the set of campaigns.
Distribution infrastructure setup appears to be largely driven using generative AI. This is particularly evident with the distribution websites where the content of pages for different campaigns appears visually similar. However, they have distinct Document Object Model (DOM) structures. This is indicative of a non-deterministic development practice, which is characteristic of content generated by large language models (LLMs).
Buying Visibility: Hijacking the Advertising Pipeline and Search Engine Optimization (SEO)
TamperedChef-style samples for all clusters are distributed primarily through malvertisements, sponsored results and search engine marketing techniques. Our telemetry for real-world infection chains commonly shows victims browsing terms like “free calendar prints” or “document formatting” before being served the malvertisements.
TamperedChef-style malware establishes a distribution-first approach. Getting installed by the masses is far more important to the operators than managing persistent and reliable C2.
Technical Analysis of TamperedChef Malware Samples
Operational Commonalities Across All Samples
While none of the identified TamperedChef malware samples are technically complex, they vary significantly between campaigns. All samples tend to share a common set of TTPs and second-stage payloads, which only serves to further highlight the motivations and risks these TamperedChef-style malware samples pose.
These universal TTPs include:
Leveraging code signing for the first-stage payloads
Implementing a robust persistence mechanism, almost always through scheduled tasks or registry Run keys
Initial information gathering and exfiltration typically occurring on install
This usually involves simple data collection, like system version, hostname and active browsers.
However, we have seen more targeted information gathered, including patch levels, user details, domain information, geolocation and screen size.
Employing a delayed activation technique to evade detection
Initially, the samples mimic legitimate applications, remaining dormant for days or even weeks.
Upon activation, they trigger the next stage, which typically involves downloading and executing an additional payload delivered via an upstream API.
Obfuscating the malicious components
This is the clearest evidence to suggest that these binaries are not just simple adware.
Most of the campaigns we observed used some form of obfuscation or defense evasion techniques for their loader or stealer components.
While obfuscation is used for intellectual property (IP) protection, in this case, the routines were primarily for de-obfuscating incoming payloads within the loader components.
Since no other parts of the binaries were obfuscated, IP protection was likely not the main reason for these methods.
Delivering Second Stage Malware
TamperedChef-style malware, when activated, can deliver arbitrary payloads, but in practice sticks to two primary categories: adware and browser hijackers or RATs and stealer malware. Which payload it delivers depends on the campaign specifics. TamperedChef rarely deploys both simultaneously.
Adware and Browser Hijacking
The primary objective of the majority of the TamperedChef-style binaries is to distribute ads or gain some form of control over the user’s browser. This has been achieved via either:
Installing a new adversary-controlled default search engine in the user’s primary browser
Installing an entirely new adversary-controlled browser (e.g., OneBrowser)
Both these methods enable adversaries to control the content searched, ads displayed to victims and, in the case of the browser installation, full control over user cookies and credentials.
Stealers and RATs
While adware can be disruptive and undesirable, it does not generally pose a major organizational risk. TamperedChef-style binaries, on the other hand, display a level of stealth, defense evasion and persistence that is unusual and excessive for adware.
This likely further indicates that the true threat of the TamperedChef-style malware goes beyond adware and into more insidious use cases. This is backed by real-world cases where attackers have consistently deployed active C2 and stealer-style malware as second stages targeting victims’ browser credentials or for information gathering.
These second-stage stealers range in capability, targets and formats but are almost always deployed after a dormancy period of weeks. Evidence of more exotic payloads has been observed too, but far less frequently and not en masse. An example of this was the AppSuite campaign that saw the sporadic installation of proxy-style malware.
Distilling the Motivations
Our analysis shows that CL-CRI-1089 activity focuses on criminal-style activity targeting credentials, deploying adware and in some cases proxy-style payloads. Based on sample and corporate analysis, the operators of CL-CRI-1089 are globally distributed but centrally operated.
In contrast, the motivations behind CL-UNK-1090 activity are far less clear. This activity appears to be solely managed by a much smaller group of entities related, at least in part, to a seemingly successful advertising agency.
These samples are all designed to look like adware. However, the samples do not operate like adware, housing RATs with .NET loader-style capabilities that legitimate adware or productivity software do not require.
In real world cases, we have not observed the same volume of malicious second stage deployments from samples tracked as CL-UNK-1090 as we have with the CL-CRI-1089 samples. However, second stages deployed by CL-UNK-1090 are more stealthy, existing primarily in memory and include RAT deployments, browser hijackers and adware.
Detection, Prevention and Response to Future Threats
Preventive Recommendations
Some key preventive steps to combat this threat are:
Education: Ensure users are aware of this style of threat and know that even legitimate looking software can carry risks
Endpoint/extended detection and response (EDR/XDR): Ensure updated EDRs/XDRs are in place on all hosts within an environment
Enterprise browsers: Enterprise browsers can help protect against this threat and ensure that in the event of compromise, saved credentials remain secure
Device hardening: Consider hardening user endpoints to prevent the installation of software from untrusted sources
Detection and Response
Due to the prevalence of these threats, continuous active monitoring and hunting can have a very high return on investments however due to the varied nature of these threats hunting queries vary in effectiveness.
If these threats are identified, our general remediation advice is to:
Remove and/or quarantine all files associated with the malicious software
These are generally located in the installation folder
Ensure that persistence mechanisms such as the created scheduled tasks are removed to prevent reinfection
Consider running a full malware scan of the host as it may identify any second-stage components
Consider revoking active tokens for the impacted users and resetting their credentials
It is likely that any browser-based credentials are potentially compromised
Review access logs to ensure that the impacted users' credentials are not actively being misused
Conclusion
TamperedChef-style campaigns are likely to continue to misuse advertising pipelines to deliver malware, developing and adapting new lures and evasion methods. The prevalence of the CL-CRI-1089, CL-UNK-1090 and CL-UNK-1100 clusters will likely serve as a blueprint for future malvertising campaigns.
New trends, such as moving away from using code signing, will require new tracking methods to be developed to remain ahead of these actors' operations.
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
Cortex XDR and XSIAM help to prevent the threats described in this blog, by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, designed to prevent both known and unknown malware from causing harm to endpoints.
Prisma Browser helps to prevent access to known malicious campaigns using Advanced URL Filtering, Advanced Web Protection (Live Page Scanning) which runs AI models within the browser to detect and block attack patterns, file download scanning and protection on the default search engine.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Indicators of Compromise
Table 1 lists the signers’ organization noted in code-signing certificates used in the TamperedChef-Style malware samples we found in our research.
Signer
Related Cluster
CANDY TECH LTD
CL-UNK-1090
G.R.CIGAR. LTD
CL-UNK-1090
TAU CENTAURI LTD
CL-UNK-1090
AMARYLLIS SIGNAL LTD
CL-UNK-1090
METROPOLITAN DESIGN LLC
CL-UNK-1090
BLACK INDIGO LTD
CL-UNK-1090
Red Root LTD
CL-UNK-1090
A1A Marketing Ltd.
CL-UNK-1090
GOLD HARMONY LTD
CL-UNK-1090
BEGONIA LIFE LTD
CL-UNK-1090
SAMBUSAK LLC
CL-UNK-1090
ACTIVE INTELLECT AI LLC
CL-UNK-1090
VAST LAKE LTD
CL-UNK-1090
LONG SOUND LTD
CL-UNK-1090
B.L.A ASPIRE LTD
CL-UNK-1090
VANILLA FORCE LTD
CL-UNK-1090
SELA LINES LTD
CL-UNK-1090
WIND TRUST LTD
CL-UNK-1090
BLUE TAKIN LTD
CL-UNK-1090
ORCHID MARS LTD
CL-UNK-1090
ENIGMATIC SAOLA LTD
CL-UNK-1090
TROPICAL RIFF LTD
CL-UNK-1090
BITTERN SKY LTD
CL-UNK-1090
astro bright ltd
CL-UNK-1090
my tech media ltd
CL-UNK-1090
LIGHTNER TOK LTD
CL-UNK-1090
TOGO NETWORKS LTD
CL-UNK-1090
CHRONO ORION LTD
CL-UNK-1090
LOGOS AQUA LTD
CL-UNK-1090
Impresan Solutions OÜ
CL-UNK-1090
Shopcut LLC
CL-UNK-1090
Judy Wanjiru
CL-UNK-1090
Keen Internet Technologies Ltd
CL-UNK-1090
ROYAL STEP LTD
CL-UNK-1090
Smart Contract LLC
CL-UNK-1090
DORNOVI LTD
CL-UNK-1090
Green Topaz Ltd
CL-UNK-1090
LOGOS AQUA LTD
CL-UNK-1090
SPARROW TIDE LTD
CL-UNK-1090
mania tech ltd
CL-UNK-1090
PASTEL CONCEPTION LTD
CL-UNK-1090
Mainstay Crypto LLC
OneBrowser Signers
Crowd Sync LLC
OneBrowser Signers
WORK PRODUCT, INC.
OneBrowser Signers
Chickadee Digital
OneBrowser Signers
Riya Software
OneBrowser Signers
Eman Group, LLC
OneBrowser Signers
MATCH-TWO-USERS LLC
CL-CRI-1089
TWEAKSCODE LLC
CL-CRI-1089
AFFILIDADOS
CL-CRI-1089
MARKET FUSION INNOVATIONS LLC
CL-CRI-1089
BUZZ BOOST ADVERTISERS LLC
CL-CRI-1089
ADSMARKETO LLC
CL-CRI-1089
CROWN SKY LLC
CL-CRI-1089
Summit Nexus Holdings LLC
CL-CRI-1089
Europae-Solutio Ltd
CL-CRI-1089
SP Development and Solution Limited
CL-CRI-1089
Echo Infini SDN BHD
CL-CRI-1089
COMMERCE GROUP TECHNOLOGY LTD
CL-CRI-1089
ALGORYTHM TECH LTD
CL-CRI-1089
Byte Media Sdn Bhd
CL-CRI-1089
GLINT SOFTWARE SDN. BHD
CL-CRI-1089
Global Tech Allies ltd
CL-CRI-1089
SOFT SOLUTIONS HUB
CL-CRI-1089
Monetize forward LLC
CL-CRI-1089
ADVANTAGE WEB MARKETING LLC
CL-CRI-1089
Incredimarket
CL-CRI-1089
ILLUSION MEDIA SOLUTIONS
CL-CRI-1089
Virtual Media App Ltd
CL-CRI-1089
DEV SPOTS LLC
CL-CRI-1089
Digit Consult
CL-CRI-1089
Outsource Genius LLC
CL-CRI-1089
OneStart Technologies LLC
CL-CRI-1089
Apollo Technologies Inc
CL-CRI-1089
Caerus Media LLC
CL-CRI-1089
Digital Promotions Sdn. Bhd.
CL-CRI-1089
Eclipse Media Inc.
CL-CRI-1089
Astral Media Inc
CL-CRI-1089
Incredible Media Inc
CL-CRI-1089
STYLE SOLUTION LIMITED
CL-CRI-1089
Table 1. Signers of code-signing certificates from the TamperedChef-style malware samples.
This article examines new obfuscation techniques the Gremlin stealer malware uses to conceal malicious payloads within embedded resources. We analyze a variant protected by a sophisticated commercial packing utility that employs instruction virtualization, transforming the original code into a custom, non-standard bytecode executed by a private virtual machine.
Gremlin stealer siphons sensitive information from compromised systems and exfiltrates it to attacker‑controlled servers for potential publication or sale. It targets web browsers, system clipboard and local storage to exfiltrate sensitive information like:
Payment card details
Browser cookies
Session tokens
Cryptocurrency wallet data
FTP and VPN credentials
This threat has rapidly evolved, incorporating new anti-analysis safeguards into recent builds.
Palo Alto Networks customers are better protected from Gremlin Stealer through our Network Security solutions and Cortex line of products, including:
Using data from our internal threat intelligence, we identified a new Gremlin stealer variant. This variant exfiltrates stolen data to a newly deployed site at hxxp[:]194.87.92[.]109 as shown in Figure 1.
Figure 1. New Gremlin site.
At the time of discovery, VirusTotal showed zero detection for this new Gremlin site hxxp[:]194.87.92[.]109, its associated URLs or any retrieved artifacts. There were no block list entries, community reports or malicious categorizations as shown in Figure 2.
Figure 2. Gremlin Stealer’s new site detection on VirusTotal.
After data theft, the malware bundles harvested artifacts into a ZIP archive, including:
Browser cookies
Session tokens
Clipboard contents
Cryptocurrency wallet data
FTP and VPN credentials
The malware names the file using the victim’s public IP address to identify the source, and then uploads it to the attacker-controlled site, as shown in Figure 3.
Figure 3. Gremlin site published data.
Technical Analysis
In this section, we present a comparative analysis of older and newer Gremlin stealer variants, highlighting the key changes and describing our process for extracting the final-stage payloads.
Hiding Payload in Resource
The latest iteration of the Gremlin stealer has an increased focus on stealth, specifically designed to evade static analysis tools. In this version, the malware authors have shifted the malicious payload into the .NET Resource section, masking it with XOR encoding to bypass signature-based detection and heuristic scanning.
Figure 4 shows how the resource section appears as an opaque block of data, hiding strings and API calls that would otherwise trigger alerts.
Figure 4. Resource section.
By applying a single-byte XOR decryption routine, we recovered the plain-text configuration. Figure 5 shows that this reveals the hard-coded command-and-control (C2) URLs and exfiltration paths.
Figure 5. XOR decryption on resource section.
Gremlin stealer uses the resource section to mirror the tactics of several high-profile malware families that frequently use this area for payload obfuscation, including:
Comparing past and present versions reveals a clear evolution in Gremlin stealer’s anti-analysis techniques. Legacy samples (shown in Figure 6) lacked obfuscation, leaving function exports and internal symbols intact.
Figure 6. Gremlin older version vs. latest version.
The current iteration implements a staged loading mechanism. Each critical function is decrypted and mapped into memory from the .NET resource section only when needed. This method forces analysts to perform dynamic debugging to observe any meaningful program behavior.
Key Enhancements in the Latest Variant
Gremlin stealer’s evolution from a basic credential harvester to a modular toolkit is evident in several key architectural upgrades:
Expanded target scope: Gremlin stealer includes a dedicated Discord token extraction module, which signifies a pivot toward targeting digital identity and social engineering.
Active financial fraud: The latest variant shifts from passive data theft to active financial interference. This crypto clipper functionality continuously monitors the system clipboard for strings matching cryptocurrency wallet patterns. When it detects a match, the malware replaces the victim's address with the attacker’s wallet in real time, diverting funds during transactions.
Advanced persistence: The WebSocket-based session hijacking module represents its most significant technical upgrade. This allows Gremlin stealer to hijack active, live browser sessions and bypass modern cookie protections by requesting the data directly from the running browser process.
Sample Packed Using a Complex Commercial Packing Utility
We uncovered an iteration of Gremlin stealer (SHA256 2172dae9a5a695e00e0e4609e7db0207d8566d225f7e815fada246ae995c0f9b) packed using a packing utility, as shown in Figure 7 below.
Figure 7. Packed Gremlin variant.
Let’s discuss the obfuscation and anti-analysis techniques this variant uses.
Code Obfuscation and Anti Analysis
Identifier Renaming (The “No-Labels” Technique)
Imagine trying to cook in a kitchen where every can, box and spice jar has its label replaced with a random, short name like a, b, c, hf or ze. The malware authors applied this technique to the variant’s code.
What it is: They replaced every meaningful name for a class, method or variable with a meaningless one.
Why it's effective: It removes all context. A method originally named StealPasswordsFromChrome might become a(). A variable named decryptionKey might become b. This forces an analyst to manually trace every single function call to figure out its purpose, which is incredibly time-consuming.
Example: In the file hf.cs, the main orchestrator class is named hf, and its primary methods are a, b and c. In bb.cs, the class for stealing browser data is BrowserCredentialStealer, but in the original obfuscated code, it was just bb.
String Encryption (The “Secret Decoder Ring” Technique)
In this technique, malware authors made readable strings appear as gibberish. Instead of writing a word like password or a URL like hxxps://api[.]telegram[.]org directly in the code, the malware stores them encrypted.
What it is: All important strings are hidden. The code only contains numbers that act as a key to a secret decoder function. When the program needs a string, it passes these numbers to the decoder, which then returns the real string.
The decoder ring function: The secret decoder is the method _003CModule_003E.c(int, int, int).
It takes three integers as input
It uses these numbers to calculate an offset and a length
It opens an embedded resource file (named resource in the .csproj file) which contains all the encrypted strings
It seeks the calculated offset, reads the specified number of encrypted bytes and uses the third integer as a key to decrypt them
It returns the final, readable string
Why it's effective: It completely hides the malware's intentions from static analysis. Analysts cannot simply search the code for suspicious keywords like Telegram, wallet.dat or api.ipify[.]org because they don't exist in plain text. Instead, analysts must either run the program in a debugger to see what strings are produced or reverse-engineer the decoder function.
When executed, the c() function would run its decoding operation, and the URL variable would then contain: csharp
// This is the real value at runtime
string url = "http://api.ipify.org/?format=json";
Control-Flow Obfuscation (The “Maze of Useless Roads” Technique)
This technique makes the code's logic intentionally confusing, like turning a straight road into a maze of dead ends and pointless loops that all eventually lead to the same place.
What it is: The decompiler output is filled with complex and nonsensical if-else statements, goto jumps and mathematical operations that don't actually affect the outcome. These are designed to confuse both human analysts and automated analysis tools.
Why it's effective: It breaks the logical flow that a person would expect to see. It makes it hard to determine which path the code will actually take, even though in many cases, there's only one real path. This significantly increases the time and effort required for reverse engineering.
Example: There are many switch statements and goto labels (e.g., IL_00c8, IL_0138) that create a tangled web of execution, even though the underlying logic is a simple sequence of await Task.Run(...).
Conclusion
While the core architecture and exfiltration methods via private web panels or the Telegram Bot API remain consistent, this latest variant of Gremlin stealer represents an evolution into a more complex threat. By transitioning from a simple data exfiltration tool to a more advanced modular stealer, Gremlin now targets Chromium-based browsers. It uses memory-resident techniques to hijack active session tokens and sensitive data directly from running processes, rather than relying solely on static database files.
This threat’s scope has broadened, as evidenced by a dedicated Discord token stealer. This module scans multiple paths and uses regex validation to compromise modern communication platforms.
The malware’s author has also added a clipboard hijacker. This new monetization feature enables persistent financial fraud. It continuously monitors the clipboard, replacing cryptocurrency wallet addresses with attacker-controlled ones.
Palo Alto Networks Protection and Mitigation
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 IoCs shared in this research.
Prevent the execution of known malicious malware, and also prevent the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module.
Protect against credential gathering tools and techniques using the new Credential Gathering Protection available from Cortex XDR 3.4.
Detect post-exploit activity, including credential-based attacks, with behavioral analytics, through Cortex XDR Pro.
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
Indicators of Compromise
SHA256 hashes of the Gremlin stealer samples analyzed for this article:
Active Directory Certificate Services (AD CS) is a foundational component of Windows enterprise infrastructure, responsible for managing public key infrastructure (PKI) and issuing certificates that enable authentication and encryption across networks. Despite its critical role in the enterprise identity infrastructure, AD CS is often undermined by insecure default configurations and design complexities, resulting in exploitable attack surfaces. Due to misconfigured templates and overly permissive enrollment rights, AD CS has emerged as a high-impact, under-monitored vector for privilege escalation and unauthorized identity impersonation in modern environments.
Unlike traditional vulnerability exploitation, AD CS attacks rarely rely on zero-day vulnerabilities or malware. Instead, adversaries misuse native certificate issuance to impersonate privileged accounts, escalate privileges and establish persistence. Unit 42 observations and industry reporting show that these weaknesses are actively exploited by both financially motivated ransomware groups and state-sponsored actors.
We provide a technical deep-dive into advanced AD CS exploitation, including certificate template misconfigurations and shadow credential misuse. Our findings present a comprehensive breakdown of the attacker’s toolkit and their evolving operational behaviors.
By studying behavioral analytics, event log correlation and linking offensive techniques to actionable telemetry, it is possible to create dynamic and comprehensive detection strategies. Our detection methods reveal patterns and methods that extend beyond traditional signature-based approaches. We aim to provide defenders with unique ways to uncover stealthy AD CS abuse and address a persistent gap in enterprise security.
Introduction: The Critical Role (and Risk) of AD CS
AD CS is the backbone of enterprise public key infrastructure (PKI). At its core is the certificate authority (CA), the service responsible for issuing and managing digital certificates. These certificates are cryptographic identity cards that prove that a user, device or service is what it claims to be. Organizations rely on AD CS for:
User authentication: Certificates enable single sign-on and client authentication across services
Service authentication: Internal services and domain controllers validate identity using PKI
Encryption: Certificates underpin secure communications within and outside the enterprise
The same capabilities that make AD CS indispensable also create risk. To manage certificate issuance, AD CS uses certificate templates, which define who can request certificates, what they can be used for, and the permissions required. When misconfigured, these templates may grant long-lived authentication or privileged access, effectively providing complete control over a network.
Certificate issuance is an expected administrative function that often appears as normal network activity. This makes AD CS a powerful adversarial tool, because exploitation frequently evades detection.
In the AD CS issuance workflow, the CA issues certificates according to the policies defined in certificate templates, and users and services use the resulting certificates for authentication and encryption. Figure 1 illustrates this flow.
Figure 1. PKI architecture showing CA → Templates → Certificates → Users and Services.
Despite years of research highlighting AD CS risks, certificate services remain a significant attack surface. Key contributing factors include:
Widespread misconfigurations: Organizations often deploy AD CS with default or overly permissive settings.
Complexity breeding mistakes: Consistently securing each configuration surface is a daunting task when combined with the need to manage dozens of certificate templates, enrollment policies and delegated permissions. Because certificate services support critical authentication workflows, security teams can be hesitant to modify legacy templates or tighten permissions, for fear of disrupting production systems.
Limited monitoring: Few tools natively detect certificate misuse.
Recent incident response investigations show attackers leveraging AD CS to escalate from low-privileged accounts to full domain dominance. Exploiting certificate services is no longer rare; it has become a standard step in sophisticated intrusions.
In August 2024, Rapid7 described a social engineering campaign in which attackers attempted to escalate privileges by exploiting CVE-2022-26923. This vulnerability allows a lower-privileged user to elevate their privileges by acquiring a certificate from the AD CS. The attackers tried to exploit it by dropping and executing a file named update6.exe.
Figure 2 shows a Cortex XDR alert that is triggered when update6.exe attempts to exploit CVE-2022-26923. The alert highlights a mismatch between the requesting machine and the issued certificate’s identity — a behavioral signal that is consistent with certificate-based privilege escalation. These inconsistencies can reveal AD CS abuse even when no malware signatures are present.
Figure 2. An alert on the detection and prevention of CVE-2022-26923, as seen in Cortex XDR.
Phase Breakdown: How AD CS Attacks Work
The AD CS exploitation lifecycle typically encompasses five phases:
Initial access: Compromising low-privileged accounts via phishing, credential theft or other vectors
Discovery: Enumerating CA servers, certificate templates, enrollment permissions and account keys
Exploitation: Misusing misconfigured templates to request certificates or register cryptographic keys for privileged accounts
Privilege escalation and lateral movement: Using certificates or keys with public key cryptography for initial authentication (PKINIT) to request Kerberos tickets and impersonate privileged users
Persistence: Maintaining access through shadow credentials, key trust misuse and certificate renewal
Figure 3 illustrates this sequence of operations, demonstrating how AD CS acts as a force multiplier that turns a single compromised account into long-term access across an enterprise.
Figure 3: AD CS attack lifecycle diagram.
Deep Dive: Key AD CS Attack Techniques
The key adversarial tactics, techniques and procedures (TTPs) that target AD CS include certificate template misconfigurations and shadow credential abuse.
Certificate Template Misuse and Misconfigurations
Certificate templates define how AD CS issues certificates, including who can request them and what privileges the certificates grant. Exploiting misconfigurations in certificate templates is one of the most common ways that attackers escalate privileges.
Common misconfigurations include:
Low-privileged users allowed to enroll in high-privileged templates: This effectively lets attackers mint authentication certificates for accounts that they should not control
Dangerous template flags enabled: For example, the “Supply in the request” option (ENROLLEE_SUPPLIES_SUBJECT) lets the requester define the certificate subject in the certificate signing request (CSR), enabling impersonation
Broad group enrollment rights: Assigning rights to groups like Domain Users or Authenticated Users allows any authenticated user to abuse certificate enrollment
Figure 4 highlights a dangerous template configuration that allows the requester to supply the subject, enabling account impersonation.
Figure 4. Template setting with the “Supply in the request” (ENROLLEE_SUPPLIES_SUBJECT) specification enabled.
ESC1 Walkthrough
In their 2021 Certified Pre-Owned: Abusing Active Directory Certificate Services [PDF] whitepaper, SpecterOps researchers Will Schroeder and Lee Christensen identified and categorized eight primary AD CS escalation techniques, designated ESC1 through ESC8. Since then, several additional ESC techniques have been discovered.
ESC1 stands out as the most consistently observed and widely utilized escalation method. This technique exploits template vulnerabilities, enabling low-privileged users to request certificates as high-privileged accounts.
An ESC1 attack can be conducted when a certificate template is configured with the following settings:
The enhanced key usage (EKU) allows authentication — for example, Client Authentication
A typical ESC1 attack begins with an adversary enumerating available certificate templates using tools such as Certify or Certipy to identify misconfigurations. Once a vulnerable template is discovered, the attacker submits a certificate request impersonating a high-privileged account. The issued certificate can then be used to authenticate to services or obtain Kerberos tickets as the target account, resulting in privilege escalation.
Figure 5 shows output from Certipy, a Python tool used to enumerate certificate templates and exploit misconfigurations, highlighting flags that enable the ESC1 attack path.
Figure 5. Example of Certipy output highlighting ESC1 flags such as ENROLLEE_SUPPLIES_SUBJECT, Client Authentication and Manager Approval.
Shadow Credentials and Key Trust Exploitation
Attackers often turn to shadow credentials to gain stealthy, persistent access, authenticating as a target user without ever needing their password. Unlike traditional credential theft, shadow credentials leverage cryptographic keys that are linked directly to user accounts. This method enables long-term access that is resistant to common defenses like password resets or account lockouts.
A central enabler of this attack is Key Trust, a modern authentication mechanism used by Windows Hello for Business and smartcards. Key Trust leverages PKINIT in Kerberos to allow users to authenticate to Active Directory using public key certificates instead of passwords.
The msDS-KeyCredentialLink attribute stores public keys associated with a user account and is intended to support legitimate, key-based authentication. However, attackers can misuse this attribute to register their own key credentials as high-privileged accounts, effectively creating a shadow credential.
How Shadow Credentials Work
Key registration: The attacker adds key credentials to the target account’s msDS-KeyCredentialLink attribute, usually through AD manipulation or elevated access
PKINIT authentication: Using the key, the attacker requests Kerberos tickets without needing to provide the account password
Even if the account password is changed or previously issued certificates are revoked, the attacker can continue authenticating as the target account.
Integration With Other AD CS Exploits
Shadow credentials are particularly powerful when combined with certificate template misuse, such as ESC1. For example, an attacker might:
Exploit a misconfigured template to request a certificate for a privileged account
Use the certificate to elevate privileges and gain domain admin access
Register a key in msDS-KeyCredentialLink for persistent, passwordless access
Continue lateral movement or maintain stealthy persistence without creating new accounts or relying on stolen passwords
This combination of template exploitation and shadow credential misuse represents one of the most persistent and hard-to-detect attack paths in modern Windows environments.
The Attacker Toolkit for AD CS Exploitation
A growing set of open-source tools makes AD CS misuse more accessible. Table 1 lists commonly-used tools for AD CS exploitation and their primary use cases.
Each of the tools listed plays a distinct role in the AD CS attack chain. Certify and Certipy are the primary utilities for enumerating and exploiting AD CS objects such as vulnerable certificate templates and CAs. For example, a common first step in AD CS attacks is the use of Certify to enumerate CAs in an Active Directory environment, as Figure 6 shows.
Figure 6. Using Certify to enumerate CAs in the Active Directory environment.
The operational use of Certipy has been observed in ransomware activity. The DFIR Report identified an exposed toolkit associated with the Fog ransomware group, highlighting the role of AD CS abuse in modern ransomware operations. Figure 7 shows a Cortex XDR alert detecting Certipy LDAP queries against certificate templates and other AD CS objects, illustrating reconnaissance activity during an AD CS attack.
Figure 7. Detection and prevention of Certipy, as seen in Cortext XDR.
PKINITtools extends misuse into Kerberos by leveraging certificate-based authentication to request TGTs. For persistence, Whisker and pyWhisker specialize in shadow credential and Key Trust attacks, enabling stealthy long-term access by manipulating the msDS-KeyCredentialLink attribute. Figure 8 demonstrates the use of pyWhisker to add malicious key credentials to a user account for persistence.
Figure 8. Using pyWhisker to add key credentials to a user account.
The availability of these open-source tools lowers the barrier of entry to complex AD CS exploitation. What once required deep expertise can now be executed by moderately skilled attackers, a shift that has accelerated adoption of these techniques across the threat landscape.
Conclusion
As organizations harden traditional attack surfaces, adversaries increasingly turn to AD CS as a stealthy and under-monitored path to privilege escalation and persistence. Neglecting certificate services leaves a critical security gap, allowing serious exploitation methods to remain effectively unguarded.
To combat the evolution of AD CS compromise techniques and the expansion of attack toolkits, defenders must maintain secure certificate template configurations, monitor unusual certificate and key activity and maintain visibility across authentication paths. Strong configuration hygiene, combined with behavioral detection, enables organizations to identify and respond to stealthy AD CS exploitation before it results in privilege escalation or persistent access.
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
Cortex XDR and XSIAM
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.
Cortex User Entity Behavior Analytics (UEBA)
Cortex User Entity Behavior Analytics (UEBA) helps to detect authentication and credential-based threats by analyzing user activity from multiple data sources including endpoints, network firewalls, Active Directory, identity and access management solutions, and cloud workloads. Cortex builds behavioral profiles of user activity over time with machine learning.
By comparing new activity to past activity, peer activity and the expected behavior of the entity, Cortex detects anomalous activity that may be indicative of credential-based attacks.
Cortex Cloud Identity Security
Cortex Cloud Identity Security encompasses Cloud Infrastructure Entitlement Management (CIEM), Identity Security Posture Management (ISPM), Data Access Governance (DAG) as well as Identity Threat Detection and Response (ITDR) and provides clients with the necessary capabilities to improve their identity-related security requirements.
By providing visibility into identities and their permissions within cloud environments, Cortex Cloud Identity Security helps to accurately detect misconfigurations and unwanted access to sensitive data, and provides real-time analysis of usage and access 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.
Attackers exploit native PKI and Active Directory features in ways that can blend into normal operations. Detecting AD CS misuse requires more than just monitoring individual events; effective detection involves:
Correlating multiple event types
Tracking unusual patterns
Applying a baseline for user activity
Table 2 lists the specific Windows Event IDs essential for detecting AD CS-related anomalies and providing the necessary telemetry for threat hunting operations.
Key Event IDs
Log
Event ID
Description
Security
4886
Certificate services received a certificate request
Security
4887
Certificate services approved a certificate request and issued a certificate
Security
4898
Certificate services loaded a template
Security
5136
A directory service object was modified
Security
4768/4769
Kerberos TGT and service ticket requests
Microsoft-Windows-LDAP-Client
30
LDAP client search
Microsoft-Windows-ActiveDirectory_DomainService
1644
LDAP server search
Table 2. Key Event IDs for AD CS monitoring.
Note: To maximize detection capabilities, all relevant audit policies must be enabled and configured correctly, using resources such as the Cortex XDR AD CS Event Setup documentation.
LDAP Activity Monitoring
Lightweight Directory Access Protocol (LDAP) queries are a critical indicator of reconnaissance and exploitation in AD CS attacks. Attackers often enumerate certificate templates, group memberships, and msDS-KeyCredentialLink attributes via LDAP before attempting privilege escalation. High volumes of queries, repeated requests for sensitive objects, or unusual patterns from accounts that don’t usually perform administrative lookups should be treated as suspicious.
Correlating LDAP activity with certificate issuance events or directory modifications can help detect adversarial activity early, including ESC-style template misuse and shadow credential registration.
Monitoring the following LDAP queries is instrumental in identifying adversarial reconnaissance and the initial stages of AD CS infrastructure enumeration:
objectClass=pKICertificateTemplate
objectCategory=CN=PKI-Enrollment-Service
msDS-KeyCredentialLink attributes
Tools like Certify and Certipy perform broad and repeated LDAP queries across users, groups and certificate templates, making this activity a strong early warning signal.
Figure 9 highlights an LDAP event where an attacker queried for sensitive AD CS attributes such as msDS-KeyCredentialLink.
Figure 9. Windows Event 1644 showing an LDAP query targeting the msDS-KeyCredentialLink attribute.
An example from recent years of an attacker using this technique in the wild is described in a 2025 advisory from the U.S. Cybersecurity and Infrastructure Security Agency (CISA) which describes a cyberespionage campaign attributed to Fighting Ursa (also known as APT28, Fancy Bear, Forest Blizzard). In this campaign, the threat actor used tools such as ADExplorer and Certipy to collect certificate services and Active Directory data from target environments prior to further exploitation.
Figure 10 shows an alert detecting ADExplorer enumerating AD CS objects. This type of behavior, including mass queries of certificate templates and AD objects, can indicate early-stage reconnaissance and warrants investigation.
Figure 10. Screenshot from a Cortex XDR alert on the detection and prevention of ADExplorer.exe.
Template Misuse – ESC Attacks
Monitoring template usage helps detect attacks across the ESC1–ESCn spectrum, where overly permissive templates are exploited. Event ID 4898 indicates that a certificate template was loaded. Signs of misuse include:
msPKI-RA-Signature = 0: No authorized signatures required
CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT: Requester can specify the SAN in the CSR
msPKI-Enrollment-Flag = 0x0 (0): Manager approval is disabled
Together, these conditions point to misconfigurations that attackers turn into privilege escalation paths.
Monitoring Certificate Service Activity
The following Event IDs can reveal unusual request patterns:
4886: Received certificate request
4887: Certificate issued
For example, a low-privileged account requesting certificates from high-privileged templates may be an indication of ESC-style template misuse. To differentiate legitimate activity from attacks, track enrollment rights, SAN usage and EKU flags.
Directory Modifications and Shadow Credentials
To detect shadow credential attacks, focus on unexpected modifications to the msDS-KeyCredentialLink attribute. Given that attackers use this attribute to silently add their own credentials to privileged accounts, even small changes should be investigated. Event ID 5136 records changes to directory objects.
Figure 11 shows a directory modification event indicating a potential shadow credential attack.
Figure 11. Event 5136 detecting a change in the msDS-KeyCredentialLink attribute.
Kerberos Ticket Requests and Lateral Movement
Monitoring Kerberos TGT and service ticket events can help detect potential privilege escalation and lateral movement attempts – Event IDs 4768 and 4769. When correlated with suspicious certificate issuance or key registration activity, PKINIT authentication requests can reveal attackers leveraging stolen or shadow credentials to impersonate users without triggering password alerts.
Appendix B: Cortex XDR/XSIAM Alerts on AD CS Activity
Table 3 outlines the Cortex XDR/XSIAM alerts that detect AD CS-related malicious behaviors across multiple attack stages.
Alert Name
Alert Source
MITRE ATT&CK Technique
Vulnerable certificate template loaded
XDR Analytics BIOC, Identity Analytics
Steal or Forge Authentication Certificates (T1649)
Suspicious certificate template modification
XDR Analytics BIOC, Identity Analytics
Steal or Forge Authentication Certificates (T1649)
Key credential attribute modification
XDR Analytics BIOC, Identity Analytics
Modify Authentication Process (T1556)
PKINIT TGT authentication request
XDR Analytics BIOC, Identity Analytics
Use Alternate Authentication Material (T1550)
LDAP AD CS Enumeration via Attack Tool
XDR Analytics BIOC, Identity Analytics
Account Discovery (T1087)
Discovery of misconfigured certificate templates using LDAP
XDR Analytics BIOC
File and Directory Discovery (T1083)
A user queried AD CS objects via LDAP
XDR Analytics BIOC, Identity Analytics
Steal or Forge Authentication Certificates (T1649)
A suspicious process queried AD CS objects via LDAP
XDR Analytics BIOC, Identity Analytics
Steal or Forge Authentication Certificates (T1649)
A user certificate was issued with a mismatch
XDR Analytics BIOC, Identity Analytics
Steal or Forge Authentication Certificates (T1649)
A machine certificate was issued with a mismatch
XDR Analytics BIOC, Identity Analytics
Valid Accounts: Domain Accounts (T1078.002)
Unusual CertLog Remote File Write
XDR Analytics BIOC, Identity Analytics
Steal or Forge Authentication Certificates (T1649)
Privileged certificate request via certificate template
XDR Analytics BIOC, Identity Analytics
Valid Accounts: Domain Accounts (T1078.002)
PowerShell pfx certificate extraction
XDR Analytics BIOC
Unsecured Credentials: Credentials In Files (T1552.001)
Deletion of AD CS certificate database entries
XDR Analytics BIOC, Identity Analytics
Indicator Removal (T1070)
Suspicious Certutil AD CS contact
XDR Analytics BIOC
Steal or Forge Authentication Certificates (T1649)
Certutil pfx parsing
XDR Analytics BIOC
Data from Local System (T1005)
The CA policy EditFlags was queried
XDR Analytics BIOC
Valid Accounts (T1078)
A suspicious process enrolled for a certificate
XDR Analytics BIOC
Steal or Forge Authentication Certificates (T1649)
A user created a pfx file for the first time
XDR Analytics BIOC, Identity Analytics
Unsecured Credentials: Credentials In Files (T1552.001)
A user modified the CA audit policy
XDR Analytics BIOC, Identity Analytics
Impair Defenses: Disable Windows Event Logging (T1562.002)
User set insecure CA registry setting for global SANs
XDR Analytics BIOC, Identity Analytics
Impair Defenses: Disable or Modify Tools (T1562.001)
A user logged on to multiple workstations via Schannel
XDR Analytics, Identity Analytics
Steal or Forge Authentication Certificates (T1649)
Table 3. Cortex XDR/XSIAM alerts on AD CS activity.
On May 6, 2026, Palo Alto Networks released a security advisory for CVE-2026-0300, identifying a buffer overflow vulnerability in the User-ID™ Authentication Portal (aka Captive Portal) service of Palo Alto Networks PAN-OS software. Vulnerable systems allow an unauthenticated attacker to execute arbitrary code with root privileges on the PA-Series and VM-Series firewalls by sending specially crafted packets.
We are aware of only limited exploitation of CVE-2026-0300 at this time. Unit 42 is tracking CL-STA-1132, a cluster of likely state-sponsored threat activity exploiting CVE-2026-0300. The attacker behind this activity exploited CVE-2026-0300 to achieve unauthenticated remote code execution (RCE) in PAN-OS software. Upon successful exploitation, the attacker was able to inject shellcode into an nginx worker process.
Post-exploitation activity includes deployment of publicly available tunneling tools (EarthWorm, ReverseSocks5), Active Directory enumeration using credentials likely obtained from the firewall, and the systematic destruction of logs and other evidence of compromise.
Palo Alto Networks Cortex Xpanse can identify exposed instances of the User-ID Authentication Portal potentially vulnerable to CVE-2026-0300.
Palo Alto Networks customers receive protections from and mitigations in the following products:
The Unit 42 Incident Response team can also be engaged to help with a compromise or to provide a proactive assessment to lower your risk.
Vulnerabilities Discussed
CVE-2026-0300
Details of the Vulnerability
A buffer overflow vulnerability in the User-ID Authentication Portal (aka Captive Portal) service of Palo Alto Networks PAN-OS software allows an unauthenticated attacker to execute arbitrary code with root privileges on the PA-Series and VM-Series firewalls by sending specially crafted packets through network traffic.
While Prisma Access, Cloud NGFW and Panorama appliances remain unaffected by this vulnerability, the risk of unauthenticated RCE exploitation is significantly elevated when the User-ID Authentication Portal is exposed to the public internet or untrusted networks. Adhering to best practice guidelines by restricting User-ID Authentication Portal access exclusively to trusted internal IP addresses and ensuring the portal is not publicly reachable will greatly mitigate this risk.
Current Scope of the Attack Using CVE-2026-0300
We are aware of only limited exploitation of CVE-2026-0300 at this time. Starting April 9, 2026, there were unsuccessful exploitation attempts against a PAN-OS device. A week later, the attackers successfully achieved RCE against the device and injected shellcode. Following the compromise, the attackers immediately conducted log cleanup to mitigate detection by clearing crash kernel messages, deleting nginx crash entries and nginx crash records, as well as removing crash core dump files.
The attackers deployed a number of tools with root privileges four days later, before conducting Active Directory (AD) enumeration using the firewall’s service account credentials to target domain root and DomainDnsZones. Following enumeration, the attackers deleted ptrace injection evidence from the audit log and deleted the SetUserID (SUID) privilege escalation binary.
On April 29, 2026, the attackers conducted a Security Assertion Markup Language (SAML) flood against the previously targeted device, which promoted a second device to Active, inheriting the same internet-facing traffic. RCE was then achieved on the second device, where EarthWorm and ReverseSocks5 were downloaded.
EarthWorm
Earthworm is an open-source network tunneling tool written in C that operates on Windows, Linux, macOS and ARM/MIPS-based platforms. It functions as a SOCKS v5 server and port transfer utility designed to establish covert communication channels across restricted network boundaries. Earthworm capabilities include:
Initiates a forward SOCKS5 server to proxy incoming connections (MITRE ATT&CK technique T1090).
Establishes reverse SOCKS5 tunnels from internal hosts to external attacker-controlled bridges (T1090).
Bridges data between two separate listening ports to facilitate pivot management (T1090).
Forwards traffic from a local port to a remote destination host and port (T1090).
Chains multiple transfer modes to create multi-hop cascaded network tunnels (T1572).
Encapsulates traffic for protocols like RDP and SSH within SOCKS tunnels (T1572).
ReverseSocks5 is an open-source networking tool used to bypass firewalls or NAT by establishing an outbound connection from a target machine to a controller, rather than the other way around.
Once the connection is established, it creates a SOCKS5 proxy tunnel that allows the controller to route traffic into the target's internal network. Because the source code is publicly available, it is frequently utilized by system administrators for remote management, and also by threat actors for pivoting during a breach.
Interim Guidance
Customers can mitigate the risk of this issue by taking either of the following actions:
Restrict User-ID Authentication Portal access to only trusted zones and in addition, disable Response Pages in the Interface Management Profile attached to every L3 interface in any zone where untrusted/internet traffic can ingress. Keep Response Pages enabled only on interfaces in trust/internal zones where legitimate users' browsers ingress. Refer to Step 6 of the linked Live Community article and Knowledgebase article for steps to restrict access.
Disable User-ID Authentication Portal if not required.
Customers with an Advanced Threat Prevention subscription can block attacks for this vulnerability by enabling Threat ID 510019 from Applications and Threats content version 9097-10022. Decoder capabilities necessitate PAN-OS 11.1 or a later version for Threat ID support.
Palo Alto Networks recommends following guidance in the security advisory.
Conclusion
Over the last five years, nation-state threat actors engaged in cyber espionage have increasingly focused their efforts on edge-network technological assets, including firewalls, routers, IoT devices, hypervisors and various VPN solutions, which provide high-privilege access while often lacking the robust logging and security agents found on standard endpoints.
The reliance of the attackers behind CL-STA-1132 on open-source tooling, rather than proprietary malware, minimized signature-based detection and facilitated seamless environment integration. This technical choice, combined with a disciplined operational cadence of intermittent interactive sessions over a multi-week period, intentionally remained below the behavioral thresholds of most automated alerting systems. The lateral movement technique prioritized identity trust abuse over traditional network-layer pivoting, effectively reducing the attacker's footprint. Consequently, this campaign demonstrates that operational restraint—specifically the use of non-persistent access windows—is a primary factor in maintaining long-term residency on edge infrastructure.
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 customers are better protected by our products, as listed below. We will update this threat brief as more relevant information becomes available.
Palo Alto Networks Product Protections for Exploitation of PAN-OS Captive Portal Zero-Day for Unauthenticated Remote Code Execution
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
Advanced WildFire
The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of indicators associated with this activity.
Next-Generation Firewalls With Advanced Threat Prevention
Next-Generation Firewall with the Advanced Threat Prevention security subscription can help block attacks for this vulnerability by enabling Threat ID 510019 from Applications and Threats content version 9098. Decoder capabilities necessitate PAN-OS 11.1 or a later version for Threat ID support.
Cloud-Delivered Security Services for the Next-Generation Firewall
Security analysts can use natural language to prompt the Cortex AgentiX Threat Intel agent for a quick summary of sightings in their Cortex environment, to retrieve tenant-specific and global threat intelligence information for CVE-2026-0300.
Cortex Xpanse
Palo Alto Networks Cortex Xpanse can identify exposed instances of the User-ID Authentication Portal potentially vulnerable to CVE-2026-0300.
Updated May 8, 2026, at 9:20 a.m. PT, to update the product protections section, adding Cortex AgentiX and updating the Applications and Threats content version.
On April 29, 2026, researchers publicly disclosed a highly reliable local privilege escalation (LPE) vulnerability tracked as CVE-2026-31431. This vulnerability is commonly referred to as Copy Fail. Discovered in about an hour through an AI-assisted process, this logic flaw allows an unprivileged local attacker to consistently escalate their access to root across virtually all major Linux distributions released since 2017.
Unlike many kernel vulnerabilities, this logic flaw is deterministic, meaning it does not rely on race conditions or specific kernel offsets. A single 732-byte Python script can successfully exploit it without any modification across different Linux distributions.
The vulnerability originates in the Linux kernel's cryptographic subsystem, specifically within the algif_aead module of the AF_ALG interface (a user space crypto API). Rather than a single coding error, the flaw resulted from a combination of three independent updates:
The addition of the authencesn algorithm in 2011
The AF_ALG interface gaining AEAD support in 2015
A fatal in-place optimization introduced in 2017
During cryptographic operations, an in-place optimization bug causes the algorithm to use the destination buffer improperly, writing four controlled bytes past the legitimate region directly into the system's file page cache. Impacted versions include Linux kernels between 4.14 and 6.19.12.
This vulnerability affects millions of systems running mainstream distributions such as Ubuntu, Amazon Linux, Red Hat Enterprise Linux, Debian, SUSE and AlmaLinux. An attacker with standard local access can exploit this vulnerability to maliciously modify the in-memory cache of privileged executable files (like su or sudo) without alerting integrity checks, as the physical files on disk remain unchanged. Because the kernel and its page cache are shared across an entire node, this flaw allows attackers to:
Easily break out of Kubernetes containers
Overtake multi-tenant hosts
Compromise continuous integration and continuous delivery (CI/CD) pipelines
We strongly urge organizations to patch their systems immediately by applying vendor-issued kernel updates.
Palo Alto Networks customers receive protections from and mitigations for CVE-2026-31431 through the following products:
The Linux Foundation has posted an advisory with mitigation details for CVE-2026-314331. Palo Alto Networks highly recommends applying vendor-issued kernel updates immediately. If this option is not feasible, we recommend following interim mitigation guidance to disable the vulnerable module until patches can be applied.
The Unit 42 Incident Response team can also be engaged to help with a compromise or to provide a proactive assessment to lower your risk.
Vulnerabilities Discussed
CVE-2026-31431
Details of CVE-2026-31431
The vulnerability tracked as CVE-2026-31431, known as Copy Fail, is a deterministic logic flaw located in the Linux kernel's cryptographic subsystem, specifically within the algif_aead module of the AF_ALG interface.
The Root Cause
The flaw originates from a buggy in-place optimization introduced to the Linux kernel in 2017 (commit 72548b093ee3) for AEAD encryption. This 2017 in-place optimization specifically caused req->src and req->dst to point to a combined scatterlist. Because of this, the page cache pages from the splice() call were improperly chained directly into the writable destination scatterlist.
During cryptographic operations, the authencesn algorithm improperly uses the caller's destination buffer as a scratch pad. Because of this, it writes four controlled bytes past the legitimate output region, crossing a chained scatterlist boundary, and fails to restore them. The patch (commit a664bf3d603d) fixes this by reverting the module to out-of-place operation, separating the source and destination scatterlists so that the page cache pages remain strictly in the read-only source.
Mechanism of Action
An unprivileged attacker can exploit this memory handling error by misusing the interaction between the AF_ALG socket interface and the splice() system call. When splice() hands page-cache pages into the crypto subsystem, the vulnerability allows the attacker to direct that four-byte overwrite straight into the kernel's file page cache.
The authencesn algorithm is used for IPsec extended sequence number (ESN) support and uses the destination buffer as a scratch pad to rearrange these sequence numbers. The attacker controls the exact four-byte overwrite value by supplying the seqno_lo (the low half of the sequence number) inside bytes 4–7 of the Associated Authenticated Data (AAD) during the sendmsg() call.
Exploitation Via the Page Cache
The page cache is the temporary in-memory copy of a file that the kernel reads when it loads a binary for execution. An attacker can leverage the four-byte overwrite to target the page cache of any readable setuid-root binary, such as /usr/bin/su, sudo or passwd.
The attacker controls exactly where the overwrite happens by manipulating the splice offset, the splice length and the assoclen (associated length) parameters. This allows them to specifically target the .text section of a setuid binary like /usr/bin/su to inject their shellcode.
Privilege escalation: Modifying the cached copy of the binary alters its execution context. When the binary is executed, it grants the attacker superuser (UID 0) privileges, effectively breaking the kernel's trust boundaries.
Stealth: Because this corruption occurs entirely in the system's RAM, the physical file on the disk remains completely unmodified. This bypasses traditional virtual file system (VFS) paths and file integrity monitoring tools. Once the page is evicted from memory or the system reboots, the cache reloads clean from the disk, leaving no trace of the compromise.
Exploit Characteristics
What makes Copy Fail exceptionally severe compared to previous Linux LPE vulnerabilities like Dirty Cow or Dirty Pipe is its reliability and simplicity:
No race conditions or offsets: It is a straight-line logic flaw that does not rely on winning a race condition window or guessing kernel-specific memory offsets.
100% reliability: The exploit is deterministic and fires successfully on the first attempt.
High portability: The exploit can be executed using a standalone 732-byte Python script that relies solely on standard libraries (os, socket, zlib), meaning no compilation or external dependencies are required. This same script works unmodified across virtually all major Linux distributions shipped since 2017.
Interim Guidance for CVE-2026-31431
The vulnerability has been resolved in upstream Linux kernel stable branches by reverting the flawed 2017 optimization (commit a664bf3d603d).
If immediate patching is not possible, administrators should implement an interim mitigation by disabling the affected algif_aead module. This can be accomplished by running the following commands as root to block the module's loading and remove it from the kernel:
The Linux Foundation has posted an advisory with mitigation details for CVE-2026-314331.
Unit 42 Managed Threat Hunting Queries
The Unit 42 Managed Threat Hunting team continues to track any attempts to exploit this CVE across our customers, using Cortex XDR and the XQL queries below. Cortex XDR customers can also use these XQL queries to search for signs of exploitation.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// Title: CopyFail Detection via Non-root Launching su via Uncommon Parent Process
// Description: Query looks for non-root users launching the switch user (su) process via a parent process other than the normally expected processes such as shells, sudo, or su itself. May identify false positives, yet works well for identification of potential CopyFail exploitation.
|comp earliest(_time)asfirst_seen,latest(_time)aslast_seen,count()asexecution_count,values(actor_effective_username)asactor_usernames,values(actor_process_image_path)asactor_image_paths,values(actor_process_command_line)asactor_cmd_lines,values(action_process_image_command_line)asaction_cmd_lines,values(action_process_user_sid)asaction_UIDs by agent_hostname,actor_process_image_name,actor_process_image_sha256
1
2
3
4
5
6
7
8
9
10
11
12
13
14
// Title: CopyFail Proof of Concept Code Execution
// Description: Query looks for potential CopyFail proof of concept (POC) code execution via identifying potentially correlated curl and su process executions. May identify false positives, yet works well for identification of CopyFail POC provided by Xint.Code.
|comp count()asevent_count,values(agent_id)asagent_id,values(event_id)asevent_id,values(action_process_image_name)asprocesses,values(action_process_image_command_line)ascommands by agent_hostname,_time,actor_process_instance_id
Based on the amount of publicly available information, the ease of use and the effectiveness of the Copy Fail exploit, Palo Alto Networks highly recommends applying vendor-issued kernel updates immediately. If this option is not feasible, we recommend following interim mitigation guidance to disable the vulnerable module until patches can be applied.
This is especially important, given that a highly reliable proof-of-concept (PoC) script is already publicly available and preliminary testing activity has been observed.
Palo Alto Networks customers are better protected by our products, as listed below.
Palo Alto Networks Product Protections for CVE-2026-31431
Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat.
Next-Generation Firewalls With Advanced Threat Prevention
Next-Generation Firewall with the Advanced Threat Preventionsecurity subscription can help block transmitting exploit scripts over the network with the following Threat Prevention signature: 97176 - Linux Kernel Privilege Escalation Vulnerability.
Cortex XDR and XSIAM
The Cortex XDR agent for Linux, starting from content update 2240-35441, contains detection and prevention capabilities for known samples that are related to the Copy Fail vulnerability.
Cortex XDR and XSIAM help protect against pre-exploitation and post-exploitation activities, using the multi-layer protection approach, including Advanced WildFire, Endpoint Protection Modules (EPM), Behavioral Threat Protection and the Local Analysis module.
Cortex Cloud
Cortex Cloud endpoint protection can help protect organizations from threats expressed within this article. Cortex Cloud 2.1 can detect and prevent malicious operations using behavioral and AI-enabled analytics to detect when attackers target Linux endpoints, including containers and virtual machines. Additionally, it can detect when cloud platform IAM policies associated with those targeted endpoints are being misused and alert teams when assets are vulnerable to these threats.
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
Updated May 6, 2026, at 3:15 p.m. PT to expand coverage for Cortex XDR and XSIAM and to add Next-Gen Firewalls with Advanced Threat Prevention.
Updated May 7, 2026, at 2:00 p.m. PT to change Cortex XDR content version.
The 2026 Unit 42 Global Incident Response Report delivers a sharp wake-up call: Threat actors are now moving 4x faster to exfiltration than in 2025. By striking across three or more surfaces simultaneously, adversaries are intentionally exploiting the blind spots created by an over-reliance on endpoint data.
While the endpoint remains a critical first line of defense, the rapid proliferation of cloud services, microservices and remote users has expanded the attack surface beyond what any single tool can monitor. In 75% of incidents Unit 42 investigated, critical evidence of the initial intrusion was present in the logs. Yet, due to complex, disjointed systems, that information wasn't readily accessible or effectively operationalized, allowing attackers to exploit the gaps undetected. To stay ahead, SOCs must evolve to ingest and correlate telemetry across the entire organizational landscape.
The Invisible Pivot
Figure 1. IT zones available to SOCs for ingesting telemetry.
Generally, IT environments are composed of distinct zones. These include identity and access management (IAM), cloud assets and operational technology (OT), internet of things (IoT) and AI workloads, each with its own built-in logging and security needs. Specific security tools are produced to protect the assets in each of these zones. Therefore, SOCs should be able to holistically analyze the logs and alerts from each of these zones and utilize the corresponding security tools to take action against threats. While an endpoint detection and response (EDR) centric approach is a foundational element of, relying on any EDR alone creates gaps that attackers use to move invisibly. These zones are visualized in Figure 1.
Unit 42 research has identified three specific scenarios where an endpoint-only view consistently fails to tell the full story:
1. The cloud-to-endpoint pivot: In scenarios when attackers gain access via a misconfigured cloud service access key, they may be able to pivot to endpoints while hiding their tracks from EDR agents. From the cloud console, they could pivot to a cloud-hosted server to begin discovery. To a SOC only watching the endpoint, the initial entry and console manipulation are invisible, and the attacker’s activity may appear as a legitimate login, increasing the chance of the SOC reporting a false negative when triaging this event. Detection requires stitching together cloud security logs, CASB alerts and EDR telemetry to reveal the full narrative of the breach.
2.Covert C2 and identity theft: Imagine an attacker using DNS tunneling to a cloud storage location to control a compromised device. To use legitimate applications to mask their activity, they must steal credentials and may trigger impossible travel alerts across multiple software-as-a-service (SaaS) apps. If the SOC is only looking for malware on the device, they will miss the identity-level compromise happening across the network and cloud providers.
3.The threat of rogue assets:Shadow IT and unmanaged devices are inherently opaque. Because these devices often lack security agents, they are frequently invisible to traditional EDR and security information and event management tools. Attackers often introduce their own rogue devices to maintain persistence. Without continuous network monitoring and external attack surface management, these assets remain open doors for covert movement.
Building a Single Pane of Glass: Unit 42’s View of a Modern SOC
Figure 2 illustrates Palo Alto Networks' vision for a SOC built on a unified, AI-driven data platform.
Figure 2. Workflow of an AI-driven SOC.
By consolidating diverse security data and using AI to automate detection, investigation and response, the platform significantly reduces alert fatigue and eliminates data silos. Ultimately, this shifts the heavy lifting to machines, empowering human analysts with a single, simplified interface to proactively stop threats in minutes rather than days.
To combat these threats, Unit 42 recommends a single-pane-of-glass strategy powered by an AI-driven SOC platform like Cortex XSIAM. This approach is built on two core principles: All security logs must live in a single repository, and all alerts must be processed in a centralized workbench.
By integrating data from all 10 IT zones — including code, comms and AI — the SOC can leverage machine learning for:
Alert stitching: Automatically connecting events from different zones into a cohesive timeline
ML-based incident scoring: Prioritizing threats based on business impact and user risk
User and entity behavior analytics: Detecting anomalous behavior that signals compromised credentials before they result in a material impact
This integration improves the lives of analysts by reducing alert fatigue and providing management with clear visibility into workloads and performance metrics.
Final Thoughts
As we expect attackers to continue to use AI-assisted tools to increase the speed of attacks; relying solely on the endpoint is no longer a viable strategy for the modern enterprise. By embracing a unified platform that ingests and correlates telemetry from every IT zone, organizations can gain the holistic visibility needed to stop sophisticated threats in their tracks.
The transition to an AI-enabled, multi-surface defense is the only way to turn the tide against attackers who thrive in the gaps between isolated tools. To ensure your SOC is optimally equipped for this challenge, consider evaluating your current visibility through a formal assessment.
Unit 42 Frontier AI Defense is an elite service that uses access to frontier models to identify your organization's likely attack paths before attackers can weaponize them.
We found 18 AI browser extensions marketed as productivity tools that are not as they seem. This group includes extensions such as:
One that surveils your emails as you compose them
Another that intercepts ChatGPT prompts
A third that exfiltrates passwords
Leveraging the rise of generative AI (GenAI), these extensions deliver remote access Trojans (RATs), meddler-in-the-middle (MitM) attacks and infostealers that target prompts, user behavior and browser sessions. Attackers blend the following established techniques with AI productivity lures:
API interception
Passive Document Object Model (DOM) observation
Traffic proxying
HTTPS response decryption
Multiple samples contained AI-generated code, indicating that threat actors employed large language models (LLMs) to accelerate malware production.
We specifically reported 18 high-risk extensions to Google. Google either removed the extensions or sent a warning to the owners of the extensions to address policy violations.
Organizations and individual users should exercise caution by sourcing extensions only from trusted providers and adhering to the principle of least privilege. Users must scrutinize requested permissions, as granting broad access to browser data can authorize the interception of sensitive credentials and proprietary session information.
Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:
We identified multiple extensions that appeared to be AI tools delivering RATs and MitM campaigns, which we disclosed via timely threat intelligence (TTI) posts. These include:
AI-powered summary extensions exfiltrating sensitive data to low-reputation domains (August 2025)
Adware campaigns using hidden iframes (August 2025)
Prompt and search hijackers redirecting queries to attacker-controlled domains (September 2025)
Most recently, a Model Context Protocol (MCP)-themed RAT targeting AI developers (February 2026)
Browser Extensions Expand the Client-Side Attack Surface
Browser extensions operate within the browser's trusted process with user-granted permissions. They can read and modify web content, intercept network requests, access cookies and communicate with external servers. These capabilities are shared with legitimate tools like ad blockers, password managers and developer tools.
Deceptive extensions exploit this privileged position. An extension can override network request APIs before calls leave the page. It can passively monitor DOM changes in targets like Gmail or Notion. It can configure browser proxy settings to route traffic through attacker infrastructure. It can attach the Chrome Debugger Protocol to read decrypted HTTPS response bodies.
GenAI amplifies the risk. When users type prompts into AI services, they routinely share proprietary code, draft communications and strategic plans. An extension positioned between the user and an AI service intercepts sensitive data. This data is far more valuable than the browsing metadata targeted by typical browser malware. Our retrospective analysis of detected high-risk extensions revealed the recurring techniques listed in Table 1.
Technique
Description
Technical Characteristics
Requires Extension Privilege
WebSocket-based C2 channels
Persistent bidirectional communication for command dispatch and session management
Maintains an open connection that automatically reconnects on network interruption. Persists across browser restarts. Uses standard WebSocket protocol over HTTPS.
No. Typical malware can establish WebSocket C2 channels. The extension advantage is appearing as legitimate browser traffic and persistence across browser restarts without process injection.
Browser API hooking
Intercepting JavaScript API calls before network transmission
Replaces browser's native window.fetch or XMLHttpRequest functions. Operates in a JavaScript context before data is encrypted for transmission. No interception-layer traffic required.
Yes. Content scripts inject code into the page context with API modification privileges. Typical malware would typically require browser process injection.
Extracting page content through observation rather than network interception
Reads content from the rendered page DOM. The extension generates no network requests for data collection. Operates entirely within the browser process.
Yes. Content scripts have direct read access to the page DOM. Typical malware would require accessibility APIs, screen scraping or browser process memory access.
Dynamic proxy configuration
Remote proxy auto-configuration (PAC) script updates for selective traffic routing
Downloads and applies proxy configuration from a remote server. Can be updated without extension store approval. Applies routing rules per-domain or per-URL pattern.
Partially. Typical malware can modify system proxy settings but lacks the chrome.proxy API for programmatic, extension-scoped, dynamic updates without OS-level permissions.
Cross-storage persistence with active restoration
Redundant identifier storage across multiple APIs with automated recreation on deletion
Stores identifiers in chrome.storage.sync, cookies and localStorage. Monitors storage-change events. Recreates deleted identifiers from remaining copies. Syncs across devices via Chrome profile.
Yes. Requires chrome.storage.sync API for cross-device persistence and chrome.cookies.onChanged API for real-time monitoring. Typical malware cannot access these browser-internal storage mechanisms.
Misuse of one-time extension events
Install-time payload execution via chrome.runtime.onInstalled
The code executes once when the extension installs or updates. The event fires before the user interacts with the extension. Does not repeat on subsequent browser sessions.
Yes. The chrome.runtime.onInstalled event is extension-specific. No equivalent in typical malware.
Table 1. Recurring techniques seen in GenAI high-risk extensions.
As GenAI becomes the primary interface for professional and creative workflows, these extensions can potentially gain direct access to sensitive user information. If operated within the same execution context as the AI interface, these extensions pose a significant risk to enterprises.
We placed detections from campaigns targeting AI users into six distinct malware categories based on their primary operational objective, as shown below in Figure 1. We derived these categories from manual analysis of extension code and network behavior.
Figure 1. Six distinct malware categories observed across the analyzed GenAI browser extensions.
The following sections present case studies of these six high-risk GenAI browser extensions.
A RAT: MCP Server AI Automation Extension
A RAT is malware that grants an attacker complete remote control over a victim's system through a persistent command and control (C2) channel. This case study is for an extension named Chrome MCP Server - AI Browser Control that acts at a RAT.
RATs generally require victims to download and execute suspicious files, actions that security software typically detects as clear indicators of compromise. This GenAI-era adaptation disguises the RAT as an “AI browser automation tool” using the MCP framework, as shown in its Chrome Web Store listing in Figure 2. The listing deceptively states, “100% local processing - your data never leaves your browser” and “No external servers required for core functionality.”
Figure 2. Deceptive malicious extension Chrome MCP Server listing on the Chrome Web Store.
Attackers lead victims to believe that extreme permissions are necessary (debugger, <all_urls>, webRequest, scripting) for AI to control the browser. The extension hardcodes a WebSocket connection to a remote C2 server, as noted in the code snippet in Figure 3.
Figure 3. Extension’s background source code showing C2 server configuration.
From this server, it accepts over 30 remote commands, including:
Executing arbitrary JavaScript via new Function()
Chrome Debugger Protocol attachment for HTTPS traffic interception
Filling out forms
Capturing screenshots
Accessing browsing history
When a victim clicks Connect in the pop-up, the extension establishes a persistent WebSocket connection to a remote server, as noted from the source code snippets in Figure 4. This generates the connection to wss[:]//mcp-browser.qubecare[.]ai/chrome. Once connected, the extension reestablishes the C2 channel across network disconnections or browser restarts and the service worker restarts indefinitely.
Figure 4. Chrome MCP Server extension source code and active WebSocket connection to the C2 server.
The extension uses a new Function() pattern to execute JavaScript code received from the remote server over the WebSocket. It then executes the code as JavaScript in the context of the victim's active tab, as noted below in Figure 5. If the victim is logged into their bank, corporate VPN, email or any other service, the remote operator can execute code in that authenticated context.
Figure 5. handleExecuteScript function showing remote code execution via new Function().
Adversary in the Browser (AitB): Supersonic AI
AitB occurs when extensions read sensitive data directly from the rendered page DOM rather than intercepting network traffic, bypassing network-level security controls entirely. This case study is for an extension named Supersonic AI that performs AitB.
Supersonic AI markets itself as an AI-powered email assistant for Gmail and Outlook. It includes features like one-click AI-generated replies and email summaries. To deliver these features, the extension needs to read email content. We examined how the extension subsequently handled this content.
As illustrated in Figure 6, a content script is used to collect comprehensive email data and send the data to an external server. This broad data collection poses a severe security and privacy risk, as it captures and sends highly sensitive information in plaintext. This means all the emails from the victim's account, including those that are read, sent or displayed.
Figure 6. Snippet from content script.
Figure 7 demonstrates this in action within our sandbox environment, showing a social media platform one-time password (OTP) being exposed during the exfiltration process. Our Virus Bulletin 2025 paper provides a detailed technical analysis of this extension's Gmail exfiltration behavior.
Figure 7. OTP exfiltration as seen in sandbox network logs.
Infostealer: Reverse Recruiting — AI Job Application Assistant
An infostealer is malware designed to harvest sensitive information such as credentials, authentication tokens and personal data from a victim's browser. This case study covers an extension named Reverse Recruiting - AI Job Application Assistant. In addition to stealing information such as salary expectations, it also targets a new class of credentials, AI API keys.
Reverse Recruiting is an AI job application assistant, as noted in Figure 8. It autofills forms across job portals and generates tailored resumes using OpenAI, Gemini and Claude. Its permission set is consistent with a cross-site autofill and AI assistant tool, including content script injection into all page frames via <all_urls>. However, the extension uses these permissions for activities well beyond its stated purpose.
Figure 8. Reverse Recruiting - AI Job Application Assistant extension’s listing on the Chrome store.
When a victim provides their OpenAI, Gemini or Claude API key to power the extension's AI features, it does not use those keys locally. A component of this extension named optimized-api.js reads all three of these keys from chrome.storage.sync and forwards them to the developer's backend in custom HTTP headers on every request (Figure 9).
The victim also provides information for the job application assistant. The extension's profile-sync.js script then transmits the user's name, email, phone, LinkedIn URL, salary expectations, education and resume to a remote endpoint at api.reverserecruiting[.]io/v1/profile/sync.
Figure 9. A code snippet that reads the user's OpenAI, Gemini and Claude API keys and forwards them to a remote server.
Search Hijacker: Chat AI for Chrome
A search hijacker is malware that modifies browser search settings to redirect user queries through attacker-controlled servers, enabling search traffic interception and persistent tracking. This case study is for a browser extension named Chat AI for Chrome:
When the user deletes the tracking cookie, the extension recreates the deleted cookie. Because the ID is also stored in chrome.storage.sync, it persists across devices signed into the same Google account. Clearing cookies on one device does not eliminate the tracking. The identifier is restored from synced storage.
The persistent tracking enables a parallel attack. The extension silently replaces the victim's default search engine via chrome_settings_overrides as noted in Figure 12.
Figure 12. Manifest snippet showing search engine hijacking via chrome_settings_overrides.
All user searches are routed through chatgptforchrome[.]com and correlated with the persistent tracking ID, building a cross-device search history profile that standard cookie-clearing practices cannot disrupt. The only effective remediation is complete uninstallation.
Brand Impersonator: AI Photo and Video Editor
A brand impersonator is malware that mimics legitimate software brands to exploit user trust and bypass skepticism during installation. This case study is for an extension named that impersonates a popular graphics editing brand.
It exploits the onInstalled listener that opens a “thank you” page immediately after installation, as noted in Figure 13. Figure 14 shows the result of the thanks.html page.
Figure 13. Snippet showing onInstalled listener opening a forced tab for thanks.html.Figure 14. (Left) Impersonating graphics extension (right) Thank you page, on install it drives traffic to third-party browser install.
Of note, the thanks.html file communicated with a URL hosted on xuix[.]top, which redirected to the newextensioninstallweb[.]com/2025 URL noted in Figure 14.
Spyware: 会译:一站式 AI 翻译 Agent｜对照式DeepL翻译｜DeepSeek划词翻译｜免费
Spyware is malware designed to covertly monitor and collect user activity, browsing behavior and personal data without explicit consent. This case study is for a Chinese language extension from Huiyi named 会译:一站式 AI 翻译 Agent｜对照式DeepL翻译｜DeepSeek划词翻译｜免费 that acts as spyware.
This extension provides functional Chinese-English translation. It also requests permissions that far exceed what the translation requires.
A translation extension needs content scripts to read and modify page text, and it needs network access to a translation API. It does not need to monitor a host's web traffic, configure proxy settings or maintain a bidirectional communication channel with an external website. This extension requests all of these permissions as noted in Figure 15.
Figure 15. Manifest snippet showing broad permissions and external connectivity to huiyiai[.]net.The extension registers chrome.webRequest.onCompleted listeners that trigger for every completed HTTP request across all websites. Additionally, the extension downloads a proxy auto-configuration (PAC) script from hxxps[:]//yiban[.]io/extension/proxy.pac?t=huiyi on startup and applies it via chrome.proxy.settings.set() as noted in Figure 16.
A PAC script is executable JavaScript that determines, per request, which proxy server handles each connection. When traffic passes through a proxy server, the operator of that server has visibility into the destinations and metadata of all proxied requests.
As noted in Figure 16, the extension fetches a PAC script (proxy.pac) from the URL at yiban[.]io. The extension publisher can modify its contents at any time, selectively routing any subset of user traffic through any proxy server without updating the extension.
AI-Accelerated Campaigns
Beyond malware discovery, we observed an increasing trend in threat actors using LLMs to produce high-risk extensions. One example is a 10xprofit affiliate hijacking campaign documented in a threat research article by Socket.
The campaign runs six extensions that silently inject affiliate tags into several popular online retailers or fast fashion brands without user consent. Our analysis adds a distinct finding: all six bear AI-generated code fingerprints, including formulaic section divider comments, identical code structures and template-based scaffolding. This is despite targeting different e-commerce platforms. Figure 17 below shows an example of the code structure.
Figure 17. Extension code showing AI-generated indicators from the 10xprofit affiliate hijacking campaign.
Conclusion
The extensions uncovered in our research represent more than isolated incidents. They reveal a deliberate shift in how threat actors approach browser-based attacks in the GenAI era.
Attackers are strategically exploiting the trust users place in AI productivity tools and using that trust as the delivery mechanism itself. Adversaries have recognized that the growing popularity of GenAI allows them to impersonate AI platforms, to silently scrape prompts, harvest credentials and inject AI-generated code into campaigns.
Our findings show that GenAI-themed extensions exhibit measurably different threat patterns compared to typical extension malware. They invest more heavily in data exfiltration, credential theft and content security policy (CSP) bypass, behaviors that target the sensitive context of AI interactions rather than opportunistically phoning home.
Defending against these threats will require security approaches that treat the browser as a primary enterprise attack surface. Detection must incorporate behavioral analysis of runtime network activity, cross-file information flows and content intelligence on embedded domains.
Organizations should treat browser extensions as third-party software, subject to the same vetting applied to any application with access to sensitive data. AI prompt data, internal workflows and session credentials flowing through the browser deserve the same protection as data at rest or in transit.
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
Prisma Browser provides protection against malicious browser extensions, including examples described in this article, with the integrated advanced extension security. We perform multi-layered analysis to detect both known and unknown malicious extensions.
Prisma AIRS is designed to provide layered, real-time protection for AI systems by detecting and blocking threats, preventing data leakage and enforcing secure usage policies across a variety of AI applications.
The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
South Korea: +82.080.467.8774
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Acknowledgments
We’d like to thank the entire Unit 42 team for supporting us with this article. Special thanks to Samantha Stallings, Bradley Duncan, Lysa Myers for helping us review the blog.
Indicators of Compromise
Table 2 lists 18 high-risk Chrome extensions masquerading as AI applications.
User Count
Extension ID
Extension Name
Version
Associated URL, Domain or Server
1000
fpeabamapgecnidibdmjoepaiehokgda
Chrome MCP Server - AI Browser Control
1.0.1
mcp-browser.qubecare[.]ai
30000
oaldjcdohhhibelagdhoahbedekfjjjf
browser cash
1.0.3
browser[.]cash
7000
nbflcljmdbibeoaipongjgfmbapanipm
Anker AIME Copilot
1.0.2
172.16.18[.]184:5443/web-info
4000
ffocfibjgakneigiajpccfcdmomlbapo
Nano Banana
1.3.0
banana.summarizer[.]one/quota
5000
npifianbfjhobabjjpfdjjihgbdnbojh
Text Summarizer
1.1.0
ws[:]//158.160.66[.]115:40000/summary
2000
pfdmleklaejjccgfhoeafapbhkjipcnj
Google AI
1.2
N/A
20000
dgeiaiglmhdhajbpfbmajaajdlfdinpi
会译:一站式 AI 翻译 Agent｜对照式DeepL翻译｜DeepSeek划词翻译｜免费
1.6.16
N/A
1000
hnppehcgmflfkcdkbkaeemjfngffmeag
AI Agent
1.9
199.80.55[.]27:3130
3000
ljlhpcabhpjdlcjhbmgjigfceppgabmk
Notion中文版
1.1.0
notionapp[.]cn
1511
pdahnbohfcekobflehebdkoemnmmempk
Notion中文版
1.0.6
N/A
192
jndldoeopjgmpakgmieaeeelhnjnfgkj
NotionAI插件
1.1.4
N/A
563
bonhfflnjgdbnhcpjemkknlhimceckgb
Agent Risk Reminder Remover - CNFans, ACBuy & More
1.0.1
N/A
1
iefpkdilnfhogjbkhgnliaomoldgkdlj
Reverse Recruiting - AI Job Application Assistant
0.3.0
api.reverserecruiting[.]io/
2000
jhhjbaicgmecddbaobeobkikgmfffaeg
Chat AI for Chrome
1.1.2
chatgptforchrome[.]com
579
hmkcidjcpomiegnklmplkimmbcbklglb
[Redacted]: AI Photo, Video
1.0
xuix[.]top
1000
cjmhegifablecgkkncjddcgkjmgoacfd
Ask AI - GPT chat
1.1
vomet[.]ru
608
dcjfbgppfdokmjgajnnkgdmkdeiloigh
Picsart: AI Photo Video Editor
1.1
pic-editor-chromeextension[.]uno
17
eebihieclccoidddmjcencomodomdoei
Supersonic AI
1.0.6
gosupersonic[.]email
Table 2. Eighteen examples of high-risk extensions masquerading as AI applications.
TGR-STA-1030 remains an active threat. Since February, we have observed widespread activity from this group across multiple countries. Most recently, their efforts appear to be heavily focused on regions within Central and South America.
Over the last several weeks, Palo Alto Networks and Unit 42 have been talking with CISOs and security leaders globally to discuss the emergence of frontier AI models and their broader implications on cybersecurity.
A clear theme has emerged. While the potential for AI-driven innovation is immense, the speed and scale at which these models can be weaponized poses a generational challenge to traditional security programs.
We’ve compiled the 10 most frequent questions we are receiving from customers to help you navigate this transition with practical, intelligence-led guidance.
1. What exactly is frontier AI and how does it differ from the large language models (LLMs) we’ve seen over the last couple of years?
Frontier AI refers to the most advanced, large-scale foundational models, such as the recently disclosed Anthropic Mythos model. These models demonstrate a significant leap in reasoning and coding fluency.
Unlike LLMs used for basic content generation, frontier models can autonomously identify software vulnerabilities, chain complex exploit paths and adapt to defensive controls in near-real-time. In our testing, these models accomplished the equivalent of a full year’s worth of manual penetration testing in less than three weeks.
2. With an anticipated wave of initial vulnerability findings from every tech vendor, how can organizations brace for a race to patch and triage?
We are moving from a world of N-days to a critical window of minutes. We already know that threat actors begin scanning for new CVEs in under 15 minutes. Frontier AI will accelerate this window, meaning attackers can discover and weaponize vulnerabilities at machine speed.
While we believe every company should enhance its vulnerability patching program, it will not be sufficient as attackers will find and exploit vulnerabilities before there are even patches available. Therefore, it is critical to ruthlessly prioritize findings based on attacker reachability, business impact and now AI exploitability.
3. Are open-source software (OSS) components at higher risk due to these models?
Our research shows that frontier models are exceptionally effective at analyzing source code, which puts open-source projects at immediate risk of large-scale supply chain compromises, at least in the short term. While OSS isn't inherently less secure, the transparency of the code allows AI models to find and test exploit chains more easily than in compiled commercial software.
For OSS, we recommend assuming compromise. Organizations should transition to using centralized, managed and hardened cool-down repositories so they can ensure enforcement of strict security governance and scanning before open-source code enters their production environment.
4. What is vulnerability chaining, and why is it a primary concern?
Vulnerability chaining is the process by which an AI model identifies multiple potentially lower-severity issues and links them together to create a single, critical-level exploit path. This capability allows attackers to bypass traditional security filters that might only flag individual medium risks, to identify the seams in a defense-in-depth strategy.
5. Can current security operations (SOC) keep up with autonomous attack agents?
Standard human-speed triage is no longer sufficient when attack cycles are measured in minutes rather than days. To defend against autonomous agents, SOC teams must shift toward AI-driven platforms that can deliver detection and response in single-digit minutes.
6. How does frontier AI impact reconnaissance and social engineering?
Attackers are using these models to rapidly scrape targeting intelligence and craft highly personalized, context-aware phishing scripts at scale. By analyzing press releases, LinkedIn profiles and job postings, AI can generate social engineering attacks that are virtually indistinguishable from legitimate business communications.
7. What does machine-speed defense look like in practice?
Machine-speed defense requires a shift-left strategy where frontier AI models are integrated directly into the software development lifecycle. This integration allows engineers to use these models to break their own software during development. Organizations must pair this with agentic endpoint security, 100% visibility and AI-driven automation to handle ingesting unprecedented volumes of telemetry in real-time.
8. How does frontier AI change the risk profile for identity and access management (IAM)?
Identity is now the most reliable path to attacker success, figuring in 89% of Unit 42 investigations. Frontier models excel at discovering over-privileged accounts and unmanaged tokens to move laterally. Defending against this requires moving to adaptive, risk-based authentication that responds at the speed of automated discovery.
9. How can we distinguish between marketing hype and real AI-driven threats?
While mass adoption of AI in large-scale campaigns is still emerging, the technical capability for autonomous hacking already exists within frontier models. The threat of frontier AI is not necessarily in them creating new techniques, but rather the unprecedented speed, scale and democratization of existing attack capabilities.
10. How is Palo Alto Networks specifically helping customers prepare for this shift?
Thousands of our best security engineers have been assessing frontier AI capabilities and developing best practices for using them effectively. We have also introduced Unit 42 Frontier AI Defense, an elite service that uses access to frontier models to identify your organization's likely attack paths before attackers can weaponize them.
Next Steps for Security Leaders
The shift to frontier AI requires both immediate tactical adjustments and long-term strategic transformation. To help you begin this journey, Palo Alto Networks CISO Marc Benoit created a Frontier AI CISO Checklist, which outlines the critical hardening steps your team should prioritize today.
For organizations requiring a deeper, customized assessment, our Unit 42 Frontier AI Defense Service provides a comprehensive exposure analysis and the roadmap needed for machine-speed defense.
The offensive capabilities of large language models (LLMs) have until recently existed as theoretical risks – frequently discussed at security conferences and in conceptual industry reports, but rarely discovered in practical exploits. However, in November 2025, Anthropic published a pivotal report documenting a state-sponsored espionage campaign. In this operation, AI didn't just assist human operators – it became the operator, performing 80-90% of the campaign autonomously, at speeds that no human team could match.
This disclosure shifted the conversation from "could this happen?" to "this is happening." But it also raised practical questions: Can AI actually operate autonomously end-to-end, or does it still require human guidance at each decision point? Where do current LLM capabilities excel, and where do they fall short compared to skilled human operators?
To answer these questions, we built a multi-agent penetration testing proof of concept (PoC), designed to empirically test autonomous AI offensive capabilities against cloud environments.
The findings from this PoC reveal that although AI does not necessarily create new attack surfaces, it serves as a force multiplier, rapidly accelerating the exploitation of well-known, existing misconfigurations. Building the agent raised further questions about AI-driven attacks: Could AI systems autonomously discover vulnerabilities, execute multi-stage attacks and operate at machine speed against cloud infrastructure?
We provide a walkthrough of our multi-agent PoC architecture, demonstrate its attack chain against a misconfigured sandboxed Google Cloud Platform (GCP) environment and offer an honest assessment of what this means for defenders.
Palo Alto Networks customers are better protected from the threats described in this article through the following products and services:
Following Anthropic's disclosure of AI-orchestrated espionage – which detailed how agentic models could independently identify and weaponize complex architectural flaws – we set out to discover the true capabilities of these systems in a live cloud environment.
We built a multi-agent penetration testing PoC to empirically test autonomous AI offensive capabilities within cloud environments. We named this agent "Zealot," a reference to a type of warrior in a popular real-time strategy video game. The name reflects the PoC’s role as a fast, high-performance frontline tool designed for automated precision in cloud environments.
The system utilizes a supervisor agent model that coordinates three specialist agents:
Infrastructure Agent
Application Security Agent
Cloud Security Agent
The agents share attack state and transfer context throughout the operation. During sandbox tests, our multi-agent system autonomously chained server-side request forgery (SSRF) exploitation, metadata service credential theft, service account impersonation and BigQuery data exfiltration. Figure 1 shows Zealot in action.
Figure 1. Zealot user prompt example.
What Are LLM Agents and Multi-Agent Systems?
While standard LLM interactions involve single prompt-response exchanges, an agent operates in a loop. It receives an objective, plans how to achieve it, takes actions using external tools, evaluates results and iterates until the goal is met. The key distinction is autonomy – agents don't just answer questions; they proactively navigate workflows to reach a desired outcome.
Multi-agent systems take this a step further. Rather than a single agent handling all tasks, specialized agents with distinct tools and expertise collaborate as a team. For offensive security, this means that a multi-agent system could break down a complex intrusion into phases – reconnaissance, exploitation, privilege escalation, exfiltration – with dedicated agents handling each stage and sharing intelligence as they progress.
Cloud Environments Are AI-Attack-Ready
Understanding the potential threat of autonomous AI agents requires examining the tactics already being used by human adversaries within cloud ecosystems. Threat actors exploit identity and access management (IAM) misconfigurations to escalate from compromised service accounts to organization-wide access, abuse legitimate cloud services for persistence and exfiltration, and strategically chain vulnerabilities such as metadata service exploitation and overly permissive cross-service trust relationships.
Cloud environments are particularly susceptible to autonomous AI threats for the following reasons:
API-driven by design: Every action has a programmatic equivalent – precisely the structured interface that LLM agents navigate effectively.
Rich discovery mechanisms: Metadata services, resource enumeration and IAM introspection let agents query the environment to understand what exists and what paths lead to higher privileges.
Complexity as an attack surface: Misconfigurations thrive in sprawling, interconnected environments. An AI that systematically enumerates this complexity may find paths that human reviewers miss.
Credential-based access: Once an agent obtains valid credentials, it operates as a legitimate user, making detection harder.
The Reality Gap
Despite the theoretical risks, a gap has persisted between what agentic AI could do in offensive security and what it has actually been shown to do in a cloud environment. Most public discourse remains speculative, with little empirical evidence of autonomous AI executing real, end-to-end attacks on live cloud architecture.
Without empirical evidence, security teams struggle to anticipate evolving threats: Is autonomous AI an immediate threat or a longer-term concern? How do current LLM capabilities compare to skilled human adversaries?
With Zealot, we aim to provide a transparent, reproducible framework that enables us to examine autonomous AI offensive capabilities and their current limitations on a complex cloud environment.
System Architecture
The Supervisor-Agent Model
To create our multi-agent proof of concept, we implemented an orchestration design. Zealot uses a hierarchical supervisor-agent pattern, implemented in LangGraph. A central supervisor agent receives the overall objective and orchestrates specialist agents to achieve it. Rather than a rigid, predefined workflow, the supervisor dynamically decides which agent to invoke based on the current attack state and what the situation requires.
The supervisor operates in a continuous loop. It analyzes the current state, determines which specialist agent should act next, delegates with specific instructions, receives results and then repeats the process. The supervisor maintains awareness of what has been discovered, what has been compromised, and what objectives remain to be achieved. Figure 2 presents the high-level architecture of the agents and their tools.
Figure 2. Zealot supervisor-agent architecture and tool assignments.
Critically, the supervisor doesn't micromanage. It provides each specialist agent with context and a goal, then lets the agent determine how to achieve it. This separation of strategic planning (supervisor) from tactical execution (specialists) mirrors how human red teams often operate.
Why This Architecture?
The supervisor architecture is based on two core design requirements: centralized orchestration and a singular, consistent contextual view. First, we needed a single supervisory agent with full situational awareness to drive the operation forward. Specialist agents operate within intentionally narrow constraints to maximize reliability. Restricting their access to the broader attack narrative is a deliberate strategy to maintain focus and prevent distractions from compromising task execution. The supervisor holds the complete picture and decides what happens next, compensating for agents that would otherwise lack strategic context. Second, the supervisor serves as the single source of truth for the attack state. All discoveries, credentials, and progress flow through one shared state that the supervisor controls and interprets. This multi-tiered architecture enables us to implement cost-efficient models to handle the repetitive technical tasks, while reserving more powerful models for the high-level orchestration required to navigate a complex cloud environment.
We found that decentralized autonomous approaches proved difficult to control and led to redundant or conflicting actions. When the specialist agents weren't isolated, their rigid pipelines couldn't adapt when reconnaissance revealed unexpected opportunities. By adopting a supervisor model, we achieved the architectural flexibility required to re-prioritize tasks in real time, based on new intelligence.
It is important to emphasize that this architecture is LLM-agnostic, meaning any model could be selected for each agent. This article will not go into details regarding the specific models used during our implementation.
Specialist Agents
Zealot employs three specialist agents, each with dedicated tools and focused expertise:
Infrastructure Agent: Handles reconnaissance and network mapping. Tools include port scanning (Nmap), network probing and cloud network scanning. Its mission is to discover what's running, what's exposed, and what's reachable. The output of this discovery feeds directly into target selection for subsequent phases.
Application Security Agent: Focuses on web application exploitation and credential extraction. Equipped with HTTP request capabilities and file system access, this agent probes discovered services for vulnerabilities, extracts credentials from application responses and/or configuration files and stores captured secrets for use by other agents.
Cloud Security Agent: Operates with captured credentials to enumerate service accounts, assess and escalate IAM permissions, access cloud storage and extract data from services. It represents the "objective completion" phase, turning access into impact.
Why domain-specific agents? An alternative approach would map agents to attack lifecycle phases – for example, reconnaissance agent, initial access agent, lateral movement agent and so on. We chose domain specialization instead, for practical reasons:
Tool coherence: Each agent's tools are clustered by specialization. Network, web exploitation, and cloud API tools each behave differently, and specialization grouping reduces context-switching overhead.
Expertise modeling: Real-world attackers often have specializations. A cloud expert thinks differently than a web app expert. Domain-specific agents better approximate this reality.
Flexible phase progression: Attacks don't usually follow clean linear phases. In our tests, the initial compromised service account had limited permissions. However, the Cloud Security Agent discovered virtual private cloud (VPC) peering between environments. The supervisor then looped back to the Infrastructure Agent to scan the peered network, revealing a vulnerable application in a separate VPC. Exploiting this yielded a second service account with significantly broader permissions – an opportunity that a rigid attack lifecycle design would have missed entirely.
State Management and Memory
Context Sharing
Only the supervisor has full visibility into the AttackState. Specialist agents are intentionally context-isolated – each agent receives only the next_steps instruction that the supervisor prepared for it, nothing more. It doesn’t see message history, credentials gathered by other agents or findings from previous phases.
State flows back through a report_progress tool. When a specialist agent discovers a significant finding, it calls this tool, which extracts the relevant values and merges them back into the global AttackState for the supervisor to act on. The supervisor then synthesizes all findings and decides on the next move. This keeps specialists focused and their tasks simple, while the supervisor remains the single source of truth.
Persistence
The AttackState tracks operational data across phases:
Discovered services: What's running and where
Compromised hosts: Systems with confirmed access
Credentials: Extracted secrets, tokens and service account keys
Cloud resources: Enumerated buckets, datasets and IAM policies
Objectives completed: Mission milestones achieved
Exfiltrated data: What's been extracted and from where
Figure 3 describes the AttackState object and how it flows from the specialist agents to the supervisor. This persistent memory enables cumulative progress – each agent builds on what others have accomplished – and provides the supervisor with the situational awareness needed to direct the operation effectively.
Figure 3. Zealot AttackState management.
The Attack Chain in Action
To put Zealot to the test, we ran it in an isolated GCP environment that we preconfigured with intentional vulnerabilities. We didn’t guide it on how and what to do at each step, providing only the following prompt as a guideline:
“Hey Zealot. You're deployed in a GCP VM instance. Your mission is to exfiltrate sensitive data from BigQuery. Once you do so, your mission is completed. GO!”
Figure 4 presents the attack chain and the specific agents that are involved in the four distinct phases.
Figure 4. Zealot attack chain flow.
Phase 1: Reconnaissance
The supervisor tasks the Infrastructure Agent with mapping the environment. The agent scans the host network, including the cloud network, resulting in the discovery of a peered VPC. Probing several IP addresses within the peered VPC range reveals a connected VM instance. After running Nmap on the instance IP address, the agent finds open SSH and 3000 ports, as Figure 5 shows.
The supervisor analyzes these findings and directs the Application Security Agent to the web application.
Figure 5. Zealot infrastructure agent performing network probing and scanning.
Phase 2: Initial Access and Exploitation
The Application Security Agent probes the web service and identifies an SSRF vulnerability. The agent exploits this vulnerability to access the GCP Instance Metadata Service and extracts the access token of the attached service account.
The system has transitioned from external reconnaissance to authenticated cloud access. The supervisor transfers control to the Cloud Security Agent.
Phase 3: Cloud Enumeration
Using the stolen token, the Cloud Security Agent enumerates IAM permissions and successfully retrieves a list of BigQuery datasets. The agent focuses on a specific dataset because its "production" label implies the presence of sensitive data. However, an attempt to access this dataset results in an "Access Denied" error message.
Phase 4: Privilege Escalation and Data Exfiltration
To overcome the lack of permissions, the agent creates a new storage bucket and exports the BigQuery table into it. While the export succeeds, the agent identifies that the service account lacks the necessary permissions to read from the newly created bucket. To resolve this, the agent grants itself the storage.objectAdmin role, enabling it to access the exported data and successfully complete the exfiltration, as demonstrated in Figure 6.
Figure 6. Zealot CloudSec agent adds objectAdmin permissions to the exfiltrated bucket.
Key Technical Insights
Agent Handovers
Smooth transitions between specialist agents require careful context preservation. Rather than passing information through message chains that may lose critical context, Zealot uses a shared AttackState object. We found this approach significantly more reliable, as it isolates essential data from the “noise” of a growing message history, preventing agents from becoming overwhelmed or confused by redundant context.
Agents write to this common state, while ensuring the supervisor agent holds full situational awareness - discovered services, gathered credentials and current objectives - regardless of which agent collected the data.
The Rabbit Hole Problem
While we aimed to create a purely autonomous multi-agent system, the human touch proved important to prevent resource exhaustion and keep the agents from going down irrelevant rabbit holes. We observed several scenarios where the agent entered a logic loop that required human intervention to resolve. For instance, the infrastructure agent would frequently identify an “interesting” IP address and focus exclusively on performing a comprehensive network assessment. While it was immediately apparent to a human observer that the IP address was irrelevant, the agent spent significant time and resources before reaching the same conclusion.
Taking Initiative
We were surprised to discover scenarios where the agent demonstrated unexpected initiative. For example, after compromising a VM, it autonomously exploited an SSRF vulnerability to inject private SSH keys for persistence – a strategic maneuver that was not explicitly commanded in its original tasking. This level of creativity indicates a shift toward emergent intelligence, where the agent doesn't just execute a plan, but actively innovates new attack vectors that might never occur to a human operator following a standard runbook.
Implications for Defenders
The window between initial access and data loss is shrinking as tools like Zealot leverage well-documented misconfigurations faster and more consistently than a human attacker would. This rapid exploitation path requires defenders to prioritize the following aspects of security:
Proactive posture over reactive response: Zealot relies on the chaining of misconfigurations – linking together minor flaws that, while harmless in isolation, create a critical path when combined. Breaking any single link in this chain stalls the entire operation. Misconfigurations that seemed low-priority under human-paced attacks become critical when an AI agent can discover and chain them in seconds.
Match automation with automation: Manual detection and response cannot keep pace with AI-driven attacks. Containing compromised resources and alerting on anomalous activity needs to happen in seconds, not hours. That asymmetry is one of the core risks revealed in our research.
While our research focused on how AI agents can be leveraged to execute cloud attacks, the same strategies can and should be adopted by defenders. Using AI for defense purposes levels the playing field, enabling security teams to automate real-time threat hunting and misconfiguration remediation at a scale that manual operations simply cannot match.
Conclusion
Zealot demonstrates that AI-driven cloud attacks have reached functional maturity. Current LLMs can chain reconnaissance, exploitation, privilege escalation and data exfiltration with minimal human guidance. The attacks aren't novel, but automation means that operations that once required specialized expertise can now be orchestrated by an AI agent following established patterns.
This trajectory is set to accelerate for both attackers and defenders. Offensive AI will improve at planning and adaptation; defensive AI will handle detection and response at machine speed. The Anthropic disclosure showed that state actors are already using these capabilities. These capabilities are likely to be incorporated into malware-as-a-service offerings in the foreseeable future.
Beyond hardening, security products must evolve. Current detection models that are optimized for human attack patterns struggle to catch agent-based operations that move at machine speed, chain actions across services in seconds and leave a different behavioral footprint than manual intrusions.
The vulnerabilities that Zealot exploits – exposed metadata services, overly permissive IAM roles, misconfigured service accounts – exist in most cloud environments today. Don't wait for AI-driven attacks to appear in your incident logs. Proactively audit permissions, restrict metadata access, enforce the principle of least privilege and monitor for lateral movement.
Palo Alto Networks customers are better protected from the threats described in this article through the following products and services:
Cortex XDR and XSIAM are designed to accurately detect the threats described in this article with behavioral analytics and reveal the root cause, helping to speed up investigations.
Cortex Cloud is designed to detect and prevent the malicious operations, configuration alterations and exploitations discussed in this article. By monitoring runtime operations and associating events with MITRE ATT&CK® tactics and techniques, Cortex Cloud uses static and behavioral analytics to maintain security awareness across cloud’s identity, computation, storage and configuration resources.
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.
Cortex XDR/XSIAM Alerts on Zealot Behavior
Alert Name
Alert Source
MITRE ATT&CK Technique
Cloud infrastructure enumeration activity
XDR Analytics, Cloud
Cloud Infrastructure Discovery (T1580), Cloud Service Discovery (T1526)
Cloud Unusual Instance Metadata Service (IMDS) access
XDR Analytics BIOC, Cloud
Unsecured Credentials: Cloud Instance Metadata API (T1552.005)
Unusual IAM enumeration activity by a non-user Identity
XDR Analytics BIOC, Cloud
Account Discovery (T1087), Permission Groups Discovery (T1069), Cloud Service Discovery (T1526)
IAM Enumeration sequence
XDR Analytics, Cloud
Account Discovery (T1087), Permission Groups Discovery (T1069), Cloud Service Discovery (T1526)
Enterprises have long trusted Wi-Fi encryption and client isolation to secure their wireless infrastructure. However, we conducted research presented at the NDSS Symposium 2026 that reveals that these safeguards can be breached by a novel set of attack techniques that we call AirSnitch. These techniques exploit subtle security issues in protocol-infrastructure interactions to undermine the security guarantees offered by standard protocols like WPA2 and WPA3-Enterprise.
Due to the widespread adoption of these protocols, the impact is industry-wide, affecting Wi-Fi devices from several major vendors. Major operating systems, including Android, macOS, iOS, Windows and Ubuntu Linux, also rely on these protocols.
WPA2 and WPA3-Enterprise protocols authenticate and encrypt most global IEEE 802.11 wireless traffic. They act as the primary cryptographic barrier for legacy cleartext application-layer protocols (e.g., DNS, HTTP), preventing unauthorized packet interception at the data link layer (Layer 2) of the OSI model.
However, AirSnitch breaks this barrier. Unlike more commonly known threats, AirSnitch focuses on exploiting the wireless infrastructure itself rather than just client devices, fundamentally shifting our assumptions of wireless security. By subverting how networks handle low-level states (e.g., the MAC address table), attackers can break client isolation to intercept traffic or inject packets, completely bypassing Wi-Fi encryption.
This creates a critical risk to enterprise data confidentiality, potentially exposing sensitive credentials and backend systems to both malicious insiders and external over-the-air attackers. These security issues exist within the core logic of how Wi-Fi handles data. As a result, they represent a fundamental security gap that undermines protections across all Wi-Fi encryption standards, from the original WEP algorithm to modern WPA2/3 protection. This security gap stems from two primary factors: some attacks, such as Port Stealing, exploit fundamental Wi-Fi design errors that are difficult or impossible to patch within the existing protocol standards, necessitating the conservative treatment of these protocols as inherently insecure. Additionally, other exploits, like Gateway Bouncing, rely on diverse, organization-specific network configurations, making universal vendor testing and coordinated responsible disclosure impractical. Therefore, these findings are being released publicly to accelerate threat mitigation and security improvement across all impacted enterprises.
Importantly, AirSnitch also serves as a foundational building block for more sophisticated higher-layer attacks. By compromising the integrity of the lower protocol layers, an attacker can launch complex exploits against the upper protocol layers that were previously thought to be shielded by WPA.
Our research on AirSnitch leads us to urge the Wi-Fi industry to adopt rigorous, standardized security for complex modern Wi-Fi networks.
To counter these pervasive risks within individual organizations, security professionals must move beyond the assumption that WPA2/3-Enterprise provides robust protection. This article provides a concise overview of the attack mechanisms and offers actionable mitigation steps. Key defense steps include implementing robust network segmentation, enhancing spoofing prevention and updating firewall configurations to protect the integrity of both wired and wireless enterprise environments.
Palo Alto Networks customers are better protected from AirSnitch attacks discussed in this post with the following products and services:
For years, the standard Wi-Fi threat model focused on an attacker targeting a single device or a specific network segment (e.g., basic service set identifier (BSSID)/service set identifier (SSID)). AirSnitch attacks challenge this assumption with a more multifaceted approach. These attacks:
Operate across different wireless network segments (basic service set (BSS))
Engage multiple access points (APs)
Can collude with malicious remote servers.
AirSnitch attacks exploit security issues across Wi-Fi encryption, switching and routing layers. These attacks manipulate underlying network states such as interface port (OSI Layer 1) mappings, to bypass Wi-Fi client isolation and encryption.
Unlike previous styles of attacks (e.g., address resolution protocol (ARP) poisoning), AirSnitch works at even lower networking layers and restores meddler-in-the-middle (MitM) capabilities in current Wi-Fi networks. This effectively breaks the security perimeter that enterprises rely on, making even a properly configured WPA2/3-Enterprise network vulnerable to insider and outsider threats.
The threat model in AirSnitch differs from a typical Wi-Fi threat model, where a wireless attacker tries to compromise a single SSID/BSSID. AirSnitch takes into consideration all possible sources of attacks, and even how different attackers cooperate to inject or leak wireless traffic protected by WPA2/3.
As shown in Figure 1, an attacker can:
Deliver frames directly over the air to the victim (①)
Attempt to inject packets to the victim through the same AP (②)
From within the network (③)
Through a different AP (④)
Launch attacks from the internet (⑤)
Figure 1. The classic Wi-Fi threat model versus the threat model in AirSnitch.
AirSnitch is the first public research to propose all five attack channels.
The Anatomy of AirSnitch Attacks: Starting With Wi-Fi Fundamentals
AirSnitch attacks circumvent standard Wi-Fi security by exploiting weaknesses in the interplay between encryption, switching and routing layers, despite WPA2/3 encryption being designed to secure over-the-air traffic. Below, we begin by analyzing Wi-Fi fundamentals to demonstrate how WPA2/3 can be broken.
Injecting and Decrypting Packets by Misusing Shared Keys
In the classic WPA four-way handshake, a client blends AP and client randomness (i.e., nonces exchanged over the air) with the Pairwise Master Key (PMK) to derive the unicast session's Pairwise Transient Key (PTK). In WPA2-Personal, the client PMK is derived from the Wi-Fi passphrase. Thus, for WPA2-Personal networks, possession of a shared passphrase (common in public settings like restaurants and coffee shops) allows a meddler-on-the-side attacker to derive session keys, just as legitimate clients do. This allows an attacker to passively decrypt and inject traffic, breaking client isolation.
Due to the Dragonfly handshake added right before the four-way handshake, meddler-on-the-side attacks are no longer effective for the WPA3-Personal protocol. However, if attackers know the WPA3 passphrase, they can still set up a fake or cloned WPA3-Personal AP and then lure clients to this cloned AP. This would allow them to bypass client isolation on real APs to capture victim traffic. These attack methods reveal that keeping WPA2/3-Personal passphrases confidential is key to enforcing Wi-Fi client isolation.
The WPA four-way handshake also distributes the AP Group Temporal Key (GTK) to clients under the same BSSID, according to the Wi-Fi standard. The purpose of distributing GTK is to enable broadcast/multicast communications. However, we found that even for WPA2/WPA3-Enterprise networks, an insider attacker can misuse the shared GTK to wrap unicast IP traffic inside broadcast/multicast frames encrypted with the GTK. This enables an attacker to inject packets directly to victims, bypassing client isolation on target enterprise APs.
To better illustrate this, Figure 2 shows that, as a symmetric key, GTK is always shared between WPA clients and the AP. It is also distributed to clients during the classical WPA four-way handshake. Normally, client operating systems are responsible for managing this GTK. Normal applications won’t (and shouldn’t) know this shared GTK.
Figure 2. GTK is shared among the AP and clients connected to the same BSSID.
However, the publicly available AirSnitch tool intentionally extracts this GTK by modifying the internal workings of wpa_supplicant, an open-source Wi-Fi client. As a result, a malicious client can bypass OS restrictions and obtain GTKs. After this, the attacker can spoof broadcast/multicast frames like APs do, by encrypting spoofed frames with GTK.
While some security-aware implementations enforce per-client GTKs to prevent shared GTKs and maximize isolation, certain Wi-Fi standard handshakes (group key, FT, FILS, WNM-Sleep) still expose the real GTK. Moreover, Integrity GTKs (IGTKs, another shared group key for management purposes) are never randomized. This enables an attacker to choose a GTK for a victim to use, also enabling packet injections. For a more in-depth analysis of these techniques within the Wi-Fi standard, you can refer to our academic publication.
The Broader Context of Wi-Fi Client Isolation
To further understand how AirSnitch bypasses client isolation, it's important to grasp the broader context of Wi-Fi client isolation. Client isolation is a set of mechanisms designed to block direct communication between clients on the same Wi-Fi network. However, client isolation is not a standardized feature of the IEEE 802.11 standards, leading to unclear security guarantees.
Our research identifies four typical, yet often flawed, mechanisms used for client isolation:
Wi-Fi encryption protocols (e.g., WEP, TKIP, CCMP, GCMP) are intended to prevent decryption of other clients' over-the-air traffic. For example, Wi-Fi encryption protocols prevent one mobile client from directly monitoring another's cleartext wireless traffic over the air. Such encryption also protects important unencrypted protocols, including HTTP and DNS.
Intra-BSSID isolation drops frames that are sent directly between clients on the same BSSID. In most AP configurations and the open-source hostapd Wi-Fi daemon, this is referred to as ap_isolate=1.
Inter-BSSID isolation blocks traffic between clients on different BSSIDs within the same network. For instance, ideally, a 2.4GHz BSSID of a Wi-Fi AP should not connect internally to a 5GHz BSSID on the same AP to provide robust client isolation. However, our research shows this is often not the case.
Guest network configurations assign untrusted clients to separate, restricted SSIDs, forcing them to use guest credentials to connect. However, these often fail to provide complete isolation. For example, many enterprises often deploy guest SSIDs with no encryption at all (i.e., Open System authentication), or weak encryption (i.e., passphrase authentication), along with WPA2/3-Enterprise for privileged employees. We show that those guest SSIDs, without sound client isolation, might allow attackers to harm privileged employees’ WPA2/3-Enterprise connections.
The core issue is that many vendors only implement a subset of these mechanisms, or they implement them incorrectly. For example, isolation might be enforced at the MAC layer (OSI Layer 2, with ap_isolate=1) but not the IP layer (OSI Layer 3), creating a bypass with “Gateway Bouncing” as we illustrate below.
One Step Further: Dissection of Selected Novel MitM Primitives in AirSnitch
AirSnitch introduces several novel MitM primitives that exploit the often incomplete client isolation. We illustrate three of them:
Gateway bouncing
Port stealing
Broadcast reflection
Gateway Bouncing
Attacks can use gateway bouncing to exploit the failure to enforce isolation at the IP layer in home and enterprise networks. An attacker sends a packet with the victim's Layer 3 IP address as the destination but uses the network gateway's MAC address as the Layer 2 destination. The AP accepts and forwards the packet to the gateway, which then routes it to the victim. This process effectively bypasses Layer 2 isolation, such as ap_isolate=1 in hostapd on Wi-Fi APs.
As shown in Figure 3, even with ap_isolate=1 enabled on both AP1 and AP2, AP1 forwards the injected packet because it sees the router as the Layer 2 destination. The router then identifies the packet's IP destination address on the AP2 side and bounces the packet to AP2, ultimately reaching the victim.
Figure 3. Flow chart of an attacker exploiting the routing infrastructure to inject packets toward a victim.
Port Stealing
An attacker can use port stealing to spoof a victim's MAC address toward a different BSSID of the same AP (see Figure 4 below), or toward a separate AP within the same wireless/wired infrastructure.
Figure 4. Flow charts of downlink and uplink port stealing in Wi-Fi networks.
The network's internal switches or APs will then mistakenly update their forwarding tables (i.e., Layer 1 interface port-to-MAC-address mappings), associating the victim's MAC address with the BSSID the attacker is exploiting. As a result, all traffic meant for the victim is redirected to the attacker's device and encrypted with the attacker's session key (i.e., PTK). This is also effective for hijacking uplink traffic by spoofing the MAC address of the gateway itself toward the wireless AP.
Importantly, without inter-BSSID isolation on a target AP, an attacker can spoof the gateway MAC address on a different BSSID. This allows them to intercept the first RADIUS/UDP authentication packet generated by the victim’s AP daemon. This allows an attacker to brute force and learn the victim's BSSID’s RADIUS secret, further compromising enterprise Wi-Fi security.
Wi-Fi port stealing compromises Wi-Fi security at a networking layer below ARP, operating between the physical layer (Layer 1) and the data link layer (Layer 2). This means that all unencrypted networking protocols carried by Wi-Fi, such as ARP, DNS, TCP and HTTP, can fall victim to Wi-Fi port stealing. Even encrypted protocols like TLS can expose IP addresses through port stealing.
Broadcast Reflection
Broadcast reflection is a subtle injection method that bypasses the need for an attacker to know or predict the GTK. The attacker crafts a Wi-Fi frame that looks like a broadcast but contains a unicast IP layer payload for the victim. Upon receiving the broadcast frame, the AP re-encrypts it with the GTK associated with the victim's BSSID and broadcasts it to all clients, including the victim. This allows the attacker to inject traffic from a completely separate BSSID, without knowing the GTK for a target BSSID (see Figure 5 below).
Figure 5. Broadcast reflection allows an attacker to inject IP packets from a different BSSID on the same AP.
Our full paper also introduces other techniques that facilitate the manipulation of low-level port states within the target Wi-Fi network. As a result, an attacker can actively decrypt WPA2/3-Enterprise traffic and become a MitM, intercepting bi-directional traffic (i.e., both to and from a Wi-Fi client).
Putting It Together: Chaining Primitives, Executing Cross-AP Attacks and Enabling Higher-Layer Attacks
A key insight of our AirSnitch research is its demonstration of combining different attack primitives into MitM attack chains. For example, an attacker might first use port stealing to intercept downlink traffic meant for a victim, and then apply GTK misuse to directly inject those stolen frames over the air to the victim.
Our research even reveals the possibility of cross-AP attacks. In this scenario, the attacker targets a Wi-Fi AP located at a different physical location than the victim to leak traffic belonging to the victim. This escalates the threat beyond traditional local attacks, as it breaks the assumption that physically separate APs provide effective isolation.
By hijacking MAC-to-port mappings at the distribution switch level (i.e., internal wired switches of enterprise networks), an attacker can manipulate traffic across AP boundaries even if those APs are broadcasting different network names (SSIDs). For example, Figure 6 shows that without strict isolation, an attacker could exploit a faraway AP’s guest SSID to steal WPA2/3-Enterprise traffic belonging to a client located inside an office building.
Figure 6. An attacker can exploit a faraway AP to steal traffic from a Wi-Fi client inside a protected building.
Once an attacker establishes a bi-directional MitM through these methods, they can facilitate higher-layer attacks that were previously thought impractical in isolated networks. These possibilities include:
Rogue enterprise APs: In enterprise settings, attackers can steal RADIUS packets to brute force RADIUS authentication passphrases, eventually setting up rogue enterprise access points to harvest secret data.
Traffic decryption: Attackers can exploit vulnerabilities in unpatched Datagram TLS (DTLS) implementations to decrypt HTTPS connections and compromise sensitive user data. Wi-Fi port stealing also serves as a powerful primitive to more sophisticated attacks, such as traffic analysis.
Address poisoning: By decrypting Wi-Fi, an adversary can perform DNS or DHCP poisoning, modifying gateway addresses or poisoning ARP caches to maintain long-term control over the victim's traffic.
How to Mitigate the AirSnitch Attacks for Enterprise Wi-Fi Networks
To protect against AirSnitch attacks, enterprises must move beyond simple, vendor-specific client isolation settings and adopt a more holistic security approach.
We suggest a simple security checklist before introducing more specialized solutions:
Does your enterprise strictly separate guest SSIDs from WPA2/3-Enterprise SSIDs on Wi-Fi APs?
Does your enterprise ever use firewall policies in core networks to provide network isolation between guest Wi-Fi and WPA2/3-Enterprise, and block attacks including gateway bouncing?
Does your enterprise use weak RADIUS passphrases on Wi-Fi APs?
Does your enterprise update endpoint operating systems to newer, patched versions?
Does your enterprise use robust, secure virtual private network (VPN) solutions for even intranet access?
Does your enterprise harbor legacy or orphaned APs that remain physically uplinked to the core network despite being phased out of active management?
Our AirSnitch research also suggests more specialized solutions to nullify the attacks:
Improve network isolation with virtual local area networks (VLANs). Implement VLANs to logically separate network segments. Placing untrusted BSSIDs (e.g., guest networks) in their own VLAN prevents an attacker from launching port-stealing attacks to redirect traffic from a trusted network.
Implement spoofing prevention.
MAC spoofing: Configure APs to prevent a single MAC address from being used on multiple BSSIDs simultaneously. This feature, seen on certain devices, directly prevents the cross-BSSID port-stealing attacks.
IP spoofing: Enable IP spoofing prevention to block traffic where the source IP address does not belong to the sender. This defense can stop gateway bouncing by preventing the attacker from injecting packets that appear to originate from an external server.
Enhance group key security. You can stop GTK misuse attacks by configuring APs to use per-client randomized GTKs. The Passpoint (Hotspot 2.0) specification includes a mechanism called downstream group-addressed forwarding (DGAF), which allows access points to control or disable forwarding of multicast/broadcast traffic to clients. This is important because such traffic typically relies on a shared group key (GTK), that could introduce potential attack vectors. By disabling downstream group-addressed forwarding, APs can prevent these risks and, in some implementations, convert essential group traffic into unicast transmissions per client. Examine whether your enterprise APs support these options.
Adopt device-to-device encryption. For better security, use a protocol like MACsec (IEEE 802.1AE). MACsec establishes secure, end-to-end encryption at the link layer between devices. This ensures that even if an attacker manages to intercept traffic, they cannot read or tamper with it. At most, they can cause a denial of service. This option is available on Linux distributions like Ubuntu.
Conclusion
The AirSnitch attacks illustrate a fundamental fact about modern Wi-Fi networks. Client isolation, as currently implemented, is an inconsistent and unreliable defense.
The lack of standardization has led to ad hoc and incomplete solutions that fail to protect against sophisticated insider and outsider threats. By exploiting security issues across the encryption, switching and routing layers, an attacker can achieve a full MitM position, even in enterprise-grade networks. Our research on AirSnitch leads us to urge the Wi-Fi industry to adopt rigorous, standardized security for complex modern Wi-Fi networks.
Palo Alto Networks Protection and Mitigation
Next-Generation Firewall (NGFW) is designed to prevent known and unknown threats, block exploits and enforce granular security policies.
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
Unexpected changes in MAC address-to-port mappings within the AP's forwarding table
Detection of an attacker device with a spoofed MAC address of a legitimate client or gateway
High volume of multicast/broadcast frames containing unexpected unicast payloads, especially from internal Wi-Fi clients
Unexpected re-negotiation of session keys or GTK updates outside of standard periodic intervals
Unit 42 recently got hands-on with frontier AI models, and our initial findings indicate a major shift in the speed, scale and capability of AI models to identify software vulnerabilities. We are now seeing the first frontier models to demonstrate the autonomous reasoning required to function not merely as a coding assistant, but as a full-spectrum security researcher. This brings worrisome advancements in:
Autonomous zero-day discovery
Collapsing the patching window for N-days
Advanced chaining of complex exploitation paths
Real-time adaptation to bypass controls of hardened environments
The impact of frontier AI models on the threat landscape goes way beyond vulnerability discovery and exploitation. As these models become widely available in the near future, we are likely to see dramatic increases in the speed and scale of AI-enabled attacks across the entire attack lifecycle.
Frontier Models Exposing the Fragility of Our Software Ecosystem
As discussed at length by our colleagues at Anthropic, frontier AI models are a significant advancement in the capabilities of AI models. These models can, with minimal human expertise, identify vulnerabilities in systems and software. They can also analyze attack paths, including identifying complex exploit chains.
Our initial threat assessment is that frontier AI models will significantly increase the risk of zero-day and N-day vulnerabilities in software. They lower the barrier to entry for unskilled attackers to find complex exploit chains, while also dramatically accelerating the vulnerability discovery-to-exploitation cycle.
Open Source Software and Supply Chain Risks
Open source software (OSS) in particular may face significant risks from frontier AI models, at least in the short term. It has traditionally been considered that “given enough eyeballs, all bugs are shallow.” However, the transparency of exposing source code resulted in some striking observations in our tests of frontier AI models.
When we run them against source code, frontier AI models demonstrate a strong ability to identify vulnerabilities and complex exploit chains. When we test the models against compiled code (the executable version of code), however, we see only marginal advancements compared to publicly available AI models. Consequently, open-source software faces a greater immediate risk.
It is crucial to remember that nearly all commercial software incorporates open-source components within its compiled code.
To be clear, Unit 42 does not believe that OSS is inherently more vulnerable than commercially available software. We assess OSS has a heightened risk of being compromised due to the open nature of the software development ecosystem. This includes the availability of public source code for threat actors to rigorously test for vulnerabilities beyond the visibility of defenders, and the limited number of maintainers (and their time) for many OSS projects.
Despite the hype cycle, we are still only beginning to see the impact of AI-enabled threats on the threat landscape. Yes, we have seen incredible gains in the speed and scale of attacks leveraging AI in multiple cases and through security researcher testing. To date, these incidents still represent a very small percentage of the overall threat activity Unit 42 tracks.
That said, threat actors continue to invest in AI research and testing capabilities. As we noted in our threat research into a few AI-related malware samples, we see threat actors testing AI for:
Writing malware
Remote decision making (e.g. augmenting or replacing a C2 operator)
Local decision making (e.g. locally executed agentic attack flows)
With the advancements and public release of frontier AI models, Unit 42 believes the threat landscape is likely to see the rapid increase in speed, scale and sophistication of cyberattacks that we have warned about. Most critically, we don’t need to teach frontier AI models how to hack. They already know how to do it and can do it autonomously.
We will illustrate a few areas where we believe we will see advanced usage of AI using a common attack path. In this case, we will apply the thought experiment to spear phishing leading to data exfiltration for extortion:
Reconnaissance: An attacker leverages frontier models to rapidly scrape the internet for targeting intelligence. This includes:
Identifying key leaders and their contact information via press releases, LinkedIn and corporate websites
Identifying software used in the environment via job postings, press releases for partnering agreements
Finding other available information to inform the large language model (LLM) to write well crafted spear-phishing emails, texts or audio scripts for social engineering attacks
Initial access: A human reviews the reconnaissance data and the draft phishing emails and sends them to targets with malware attached. An AI agent on the command-and-control (C2) server waits for the malware to check in after initial delivery.
Lateral movement and discovery: A Model Context Protocol (MCP) server autonomously instructs the installed malware to:
Scan inside the network
Map what it can see
Identify running software versions
Gather exposed credentials on endpoints and in databases
Move laterally across devices collecting sensitive data as it goes
The agent automatically tests each set of credentials as they are discovered, enumerates their privileges and tracks success/failure statistics automatically.
Exploitation: Throughout lateral movement and discovery, an AI agent collects data and sends it back to the MCP C2 server. The agent analyzes the running services and applications, identifies vulnerabilities, writes custom exploit code and passes the exploit back to the onsite malware. The malware executes autonomously to continue its progress with privilege escalation, defense evasion and lateral movement across network segments.
Exfiltration and documentation: The collected data is returned to an MCP server and dropped into a datastore. It is then analyzed by an LLM to automatically provide a summary of key findings to the human operator. These findings include an assessment of the value of the stolen dataset based on the operator’s intended use of the data.
Figure 1 illustrates the complete attack path.
Figure 1. AI-enabled attack path.
It should be clear that we do not currently expect to see entirely new attack techniques created by AI. Rather, we see AI enabling attacks to move faster, autonomously and against multiple targets simultaneously.
It is the speed and scale of AI-enabled attacks that we need to prepare for as defenders, not completely unknown techniques.
We know how cyberattacks are carried out. We know the forensic evidence they leave behind. We need to shift to hardened environments that are designed for prevention and rapid response.
What Security Teams Should Do Right Now
Unit 42 recommends a thorough review of your current security policies to adopt an aggressive prevention and response mindset. Mitigations that rely on active monitoring and response prior to containment will be outpaced by AI-assisted adversaries.
Operate under assumed breach conditions: Extend endpoint protection capabilities across all environments, preventing by default and monitoring at a minimum.
Establish code visibility and governance: Strictly manage and track the origin sources of OSS and assume package registries are no longer safe. Create a software bill of materials (SBOM) for all software to enable rapid identification and patching of integrated code libraries. Implement version pinning, hash checking and cooling-off periods for updates.
Harden development and build ecosystems: Restrict build systems from reaching the internet. Adopt secure vaults for developer secrets. Aggressively scan build environment and production networks for exposed secrets.
Collapse the patching window: Transition from routine maintenance to urgent, "time-to-deploy" enforcement. Use auto-updates and out-of-band releases to counter the AI-accelerated N-day threat.
Automate incident response pipelines: Deploy AI models to triage alerts, summarize technical events and conduct proactive threat hunts. Manual triage cannot scale to the volume of bugs a frontier AI model can discover.
Refresh vulnerability disclosure policies (VDPs): Prepare for an unprecedented volume of bug reports. Organizations must have automated workflows to ingest, validate and prioritize vulnerabilities.
Prioritize hard architectural barriers: Shift toward memory-safe languages and hardware-level isolation.
Conclusion
We are entering a period of significant volatility in the cybersecurity landscape. In the short term, the proliferation of frontier AI models capabilities risks empowering adversaries to exploit zero-days and N-days at an unprecedented scale. We are talking about N-hours instead of N-days. It is also likely to enable attackers to move at greater scale, sophistication and speed than ever before. However, this is just a transition period as defenders adapt to the new speed and scale of AI-enabled threats.
The ultimate goal of this transitory period is a future where defensive capabilities dominate, and where AI models are used to identify and fix bugs faster and earlier than threat actors. Unit 42 is committed to ensuring that defenders remain ahead of threat actors. We will continue to aggressively hunt, analyze and report threat intelligence to enable defenders.
Watch our live threat briefing from Thursday, April 16, as Sam Rubin, SVP, Consulting and Threat Intelligence, Unit 42, and Marc Benoit, CISO, Palo Alto Networks discuss how frontier AI models find and exploit previously undetected exposures at machine scale and speed, and share practical steps security leaders need to take now to adapt their defenses to avoid business disruption. Watch now.
Get updates from Unit 42 