Tracking Iranian APT Screening Serpens’ 2026 Espionage Campaigns

Posted on by Unit 42

Executive Summary

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:

Cortex AgentiX Agentic Assistant can assist teams in investigating incidents.

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics Advanced Persistent Threat (APT), Malware, Cyberespionage, RATs

Screening Serpens Overview

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.

A timeline illustration in the shape of a serpent, depicting a sequence of cyber campaign events from February 2023 to late 2025. Key events include the start of a Middle Eastern phishing campaign, indications of Iranian conflict, and the introduction of malware, MiniJunk V2. MiniUpdate samples were uploaded throughout March in the U.S. and Israel, and in April from the UAE. The campaign is projected to expand globally by late 2025.
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.

A screenshot of a file directory displaying five PDF files and one ZIP file, each related to job roles such as Data Analytics & Business Intelligence Specialist, IT Project & Applications Manager, and Senior Software Engineer. The files have modification dates in March 2023 and range in size from 116 KB to 248 KB.
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.

A screenshot of a job description for a Senior Software Engineer at a technology and innovation team. The role involves software solutions for businesses, collaboration with cross-functional teams, and process optimization. Key responsibilities include developing applications, maintaining software, supporting integration, resolving issues, and developing technology strategies. The position mentions collaboration, cloud-based systems, and database management.
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.

A screenshot of a file explorer window displaying the contents of "Hiring Portal.zip." It includes six files, with size, compressed size, and date modified listed.
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.

Error message from Hiring Portal: 'Couldn't connect to survey server' with an OK button.
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.

A screenshot of a file directory showing various files and a hidden file beginning with an underscore. File types include Application, Configuration Source, Microsoft Edge HTML, and Application extension, with dates from 2025 and 2026.
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.

MiniUpdate Loading Flow

Advanced AppDomainManager Hijacking: Native EDR Evasion

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.

A screenshot of a configuration file with XML code. Important sections are highlighted, including safemode set to true, the useLegacyV2RuntimeActivationPolicy set to "no," and bypassTrustedAppStrongNames set to true.
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.

A spinning blue loading icon on a white square background.
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.

A screenshot of the Task Scheduler interface displays a task running daily at 8:30 AM. The task is set to start a program. The interface includes tabs: General, Triggers, Actions, Conditions, Settings, and History (disabled).
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.

A flowchart illustrating the MiniUpdate malware process. It includes multiple steps, such as creating processes, dropping files, and executing tasks. Key components involve the initial host NET application, primary loader, and the execution of Appdomain Hijack. The diagram details the connection to C2 and commands, ending with the malware's silent termination.
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:

  • buisness-centeral.azurewebsites[.]net
  • buisness-centeral-transportation.azurewebsites[.]net
  • Buisness-centeral-transportation[.]com

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.

A screenshot showing file explorer windows with a "Portal.zip" folder. The folder contains files including "Setup.exe." Another window displays "Folder Options," highlighting the default Windows setting to hide certain files. A label points to hidden files loaded by "Setup.exe".
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.

A screenshot of a code snippet showing XML configuration settings.
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.

A flowchart depicting the process of the MiniJunk V2 malware. It includes stages such as displaying a decoy error message, saving payloads to a scheduled task location, dropping various files, and executing the final payload. Key files mentioned include malicious archive, legitimate setup.exe and various DLLs.
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.

A screenshot of Cortex XDR report interface. The summary details a DLL Hijacking issue identified, involving WildFire Malware detection and a suspicious DLL. Two issues are listed: "WildFire Malware" with one alert for a suspicious DLL detected, and "DLL Hijacking" also with one alert. The event details section provides specific information, such as time, status, and path. The report also features a graph and information to the right side.
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.

A screenshot of a Windows File Explorer window showing a folder named "Portable Platform." It contains three items with their respective modification dates.
Figure 15. Contents of Portable Platform.zip.

Figure 16 shows the file folder content.

Screenshot of a file explorer window displaying two files, with their names, modification date and time and sizes listed. Navigation and sorting options are visible at the top.
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.

A screenshot of a software window titled "Meeting Room." It contains a text box labeled "Meeting Room URL" and a "Send" button.
Figure 17. A meeting room decoy window.

When the Connection.dll RAT runs, it follows a strict execution sequence:

  1. 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.
  2. 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.
  • Advanced URL Filtering and Advanced DNS Security identify and block known domains and URLs associated with this activity in real time.
  • 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.
A screenshot of AngentiX report detailing an 'Endpoint Investigation' about DLL hijacking events. It includes sections on issue details, key findings and insights, a case overview, and a request for further action. The report mentions techniques like DLL Sideloading and TRAPS (Threat Response Automation Service).
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.

Indicators of Compromise

Domains:

  • licencemanagers.azurewebsites[.]net
  • LicenceSupporting.azurewebsites[.]net
  • PeerDistSvcManagers.azurewebsites[.]net
  • ThemesManagers.azurewebsites[.]net
  • ThemesProviderManagers.azurewebsites[.]net
  • docspace-y4cumb.onlyoffice[.]com
  • NanoMatrix.azurewebsites[.]net
  • QuantumWeave.azurewebsites[.]net
  • ElementShift.azurewebsites[.]net
  • business-startup[.]org
  • business-startup.azurewebsites[.]net
  • Businessstartup.azurewebsites[.]net
  • app[redacted][.]live
  • buisness-centeral.azurewebsites[.]net
  • buisness-centeral-transportation.azurewebsites[.]net
  • Buisness-centeral-transportation[.]com
  • docspace-twpf0e.onlyoffice[.]com
  • PremierHealthAdvisory[.]com
  • PremierHealthAdvisory.azurewebsites[.]net
  • Premier-HealthAdvisory.azurewebsites[.]net
  • Ramiltonsfinance[.]com
  • Ramiltonsfinance.azurewebsites[.]neti
  • Ramiltons-finance.azurewebsites[.]net

URLs:

  • hxxps[:]//docspace-y4cumb.onlyoffice[.]com/storage/files/root/folder_3602000/file_3601577/v1/content.zip[...]
  • hxxps[:]//app[redacted][.]live/meeting/edcdba624ddb43c2a1dcf334aa493068
  • hxxps[:]//docspace-twpf0e.onlyoffice[.]com/storage/files/root/folder_3765000/file_3764519/v1/content.zip?filename=remote.[REDACTED].zip
  • hxxps[:]//2117.filemail[.]com/api/file/get?filekey=T0EnWQ6NugHkW_kLfDxPBEw_um6NSkg9ZwNRQ_5lrKrLLUo35pV8m3TKv1LqF3zZzdUm

SHA256 Hashes:

MiniUpdate: US Campaign

  • 44f4f7aca7f1d9bfdaf7b3736934cbe19f851a707662f8f0b0c49b383e054250 - Initial archive file
  • 332ba2f0297dfb1599adecc3e9067893e7cf243aa23aedce4906a4c480574c17 - Hiring Portal.zip
  • 0db36a04d304ad96f9e6f97b531934594cd95a5cea9ff2c9af249201089dc864 - UpdateChecker.dll

MiniUpdate: Israel Campaign

  • 38bd137c672bd58d08c4f0502f993a6561e2c3411773d1ae57ee0151a0a9d11d - Initial archive file
  • d4a7e9f107fe40c1a5d0139c6c6e25bf6bf57f61feff090bee28f476bb3cc3c2 - UpdateChecker.dll

MiniUpdate: UAE Campaign

  • bc3b44154518c5794ce639108e7b9c5fecb0c189607a26de1aaed518d890c7ad - UpdateChecker.dll

MiniUpdate: Middle Eastern Campaign

  • 74882085db2088356ed7f72f01e0404a0a98cda88ef56fb15ce74c1f36b26d27
  • bc3b44154518c5794ce639108e7b9c5fecb0c189607a26de1aaed518d890c7ad - UpdateChecker.dll

MiniJunk V2: Middle Eastern Campaign

  • 9cf029daca89523d917dafed0568d11d00e45ec96b5b90b4a1f7fd4018c7da84 - uevmonitor.dll
  • B19e06da580cf91691eda066ac9ee4b09c6e5dc26c367af12660fe1f9306eec4 - unbcl.dll

MiniJunk V2: U.S. Campaign

  • 8808c794c24367438f183e4be941876f1d3ecd0c8d2eb43b10d2380841d2283b - Portable Platform.zip
  • 43dc62cef52ebdd69e79f10015b3e13890f26c058325c0ff139c70f8d8eadcfa - Connection.dll
  • 9e4a658e6d831c9e9bdfe11884a75b7c64812ed0a80e8495ddf6b316505acac1 - unbcl.dll

Additional References

Paved With Intent: ROADtools and Nation-State Tactics in the Cloud

Posted on by Sheida Azimi

Executive Summary

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:

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics Microsoft Azure, Cloud, MITRE

Tool Overview

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 roadrecon module 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.

A screenshot of the ROADrecon interface displays a menu on the left with options like Home, Users, and Administrative Units. The main area shows a list with headings: Name, Description, Group type, and Group source. The list includes groups such as "All Users" and others.
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:

  • Persistence: T1098.005 Account Manipulation – Device Registration
  • Defense Evasion: T1550 Use Alternate Authentication Material
  • Discovery: T1087 Account Discovery

Persistence

Technique: T1098.005 Account Manipulation – Device Registration (Figure 2).

Callout box showing a laptop with malware bug on the screen, accompanied by text stating, "By registering devices they control, attackers can create persistent access."
Figure 2. MITRE ATT&CK technique T1098.005.

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.

Terminal window displaying commands for obtaining and saving tokens for 'mydevice' using 'roadtx,' a private key, and device ID starting. The process includes requesting a token from enterprise registration on a Windows network and saving a device certificate.
Figure 3. An example of roadtx access token acquisition and device registration.

Defense Evasion

Technique: T1550 Use Alternate Authentication Material (Figure 4).

Callout box with an icon of a cloud with circuit lines and the biohazard symbol paired with text that reads, "roadtx turns stolen credentials into access that can bypass controls."
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).

Callout box with an icon of a face, followed by the text: "Once tokens are obtained, roadrecon can quickly translate them into actionable intelligence."
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.

A screenshot of the ROADReconf interface displaying a list of devices. Each entry includes columns for name, manufacturer, enabled status, model, operating system, and trust type. One entry is highlighted in red showing the OS version.
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.

Token Misuse

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.

Microsoft Graph API

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.

Indicators

User-Agent string in HTTP headers of network traffic:

  • roadtools
  • python-requests/<version>

Additional Resources

The npm Threat Landscape: Attack Surface and Mitigations (Updated May 21)

Posted on by Unit 42

Executive Summary

The security of the npm ecosystem reached a critical inflection point in September 2025. The Shai-Hulud worm, a self-replicating malware that automated the compromise and redistribution of malicious packages, marked the end of the “nuisance” era of npm attacks and the beginning of a high-consequence threat landscape.

Since that watershed moment, Unit 42 has tracked an aggressive acceleration in the frequency and technical depth of supply chain compromises. Attacks have evolved from a series of isolated typosquatting incidents into systematic campaigns by various threat actors to weaponize the trust that powers modern software development.

April 2026 Campaigns

We have seen two campaigns in April: the first started April 22, 2026 and included the string Shai-Hulud: The Third Coming. The second started April 29, 2026 and is known as Mini Shai-Hulud.

May 2026 Campaigns

In May 2026, the Mini Shai-Hulud campaign continued with two new waves attributed to TeamPCP. These campaigns introduced two unique elements. One campaign used a credential-free initial access technique. The other campaign generated the highest single-hour package count of any Shai-Hulud worm to date. Copycat activity has made future attribution to TeamPCP more difficult.

The New Baseline for npm Threats

The Shai-Hulud incident proved that the npm registry could be used as a force multiplier for malware distribution. In the months following, we have observed three core shifts in adversary TTPs:

  • Wormable propagation: Malicious payloads now prioritize the theft of npm tokens and GitHub Personal Access Tokens (PATs) to automatically infect and republish legitimate packages, as seen in the March 2026 Axios compromise.
  • Infrastructure-level persistence: Attackers are no longer just stealing data; they are embedding themselves into continuous integration/continuous delivery (CI/CD) pipelines to attain long-term, undetectable access to enterprise environments.
  • Multi-stage payloads: Following the September 2025 template, current attacks often deploy dormant “sleeper” dependencies that only activate under specific environmental conditions to evade automated scanners.

npm Attacks Seen As a Whole

npm compromises have common themes. In the post-Shai-Hulud era, we believe it is helpful to consider the attack surface as a whole.

This article will combine:

  1. Details of major incidents: Real-time analysis of significant package compromises (e.g., Shai-Hulud 2.0, Axios, Chalk/Debug)
  2. Cross-campaign correlation: Identifying common infrastructure or code snippets that link disparate attacks to the same threat actors
  3. Remediation playbooks: Actionable guidance for rotating credentials and purging malicious dependencies from local and cloud-based caches

Shai-Hulud: A New Wave

A malicious npm package published as @bitwarden/cli version 2026.4.0 was identified as part of a broader supply-chain campaign attributed to TeamPCP. The package impersonates the legitimate Bitwarden command-line interface (CLI) password manager. Upon installation, it executes a multi-stage payload that steals credentials from cloud providers, CI/CD systems and developer workstations. It then self-propagates by backdooring every npm package the victim can publish. It has been noted that inside public GitHub repositories that were published contained the string “Shai-Hulud: The Third Coming.”

Attackers deployed the same payload across multiple Checkmarx distribution channels, indicating a coordinated campaign to weaponize compromised developer tooling credentials to maximize the area of impact:

  • Docker Hub images
  • GitHub Actions
  • VS Code extensions

Palo Alto Networks customers are better protected from the threats described in this article through the following products and services:

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.

Related Unit 42 Topics Supply Chain, Credential Harvesting, Obfuscation, Backdoor

May 2026 - Mini Shai-Hulud Continues

Two further waves in May 2026 continued the Mini Shai-Hulud campaign:

  • The first introduced a fundamentally new initial-access technique that requires no stolen credential and produced the first malicious npm packages with valid supply chain levels for software artifacts (SLSA) provenance
  • The second demonstrated the largest single-hour package count of any Shai-Hulud wave

Both are attributed to TeamPCP, though the public release of the worm's source code on May 12 has already spawned separate copycat activity, complicating future attribution.

May 11, 2026: Mini Shai-Hulud Strikes Again

On May 11, TeamPCP launched a coordinated supply chain attack across the npm and PyPI ecosystems. The initial vector was TanStack's GitHub Actions CI pipeline. Within six minutes, 84 malicious package artifacts were published across 42 @tanstack/* packages.

The worm's self-propagation mechanism then expanded rapidly. By end of day, we had documented 373 malicious versions across 169 npm packages plus compromised PyPI packages.

The affected scope went well beyond TanStack. The worm's self-propagation spread the compromise to packages across multiple industries and ecosystems:

  • Enterprise infrastructure: @opensearch-project/opensearch (the official OpenSearch JavaScript client; versions 3.5.3–3.8.0) and 57 @uipath/* enterprise automation packages
  • AI tooling: @mistralai/mistralai and its Azure/GCP variants, which is the official Mistral AI TypeScript client
  • Specialized ecosystems: 19 @squawk/* aviation data packages, intercom-client@7.0.4 (customer messaging) and dozens of others across @tallyui, @draftlab, @beproduct, @mesadev and several unscoped packages

@tanstack/react-router alone receives over 12.7 million weekly downloads. We estimate 520 million cumulative downloads were in the affected window. Palo Alto Networks provides XDR and XQL queries to detect this activity.

A New Initial Access: No Stolen Credential Required

Every prior Shai-Hulud wave began with a stolen or phished credential. The TanStack attack needed neither. Instead, three GitHub Actions weaknesses were chained, none of which was sufficient alone.

Step 1: Pwn Request

On May 10, the attacker created a fork of TanStack/router under the account zblgg/configuration, deliberately named to avoid appearing in fork-list searches. A malicious commit was authored under the spoofed identity claude <claude@users.noreply.github.com>, impersonating the Anthropic Claude GitHub App, and prefixed [skip ci] to suppress automated CI on push.

A pull request (PR #7378) against TanStack/router#main then triggered bundle-size.yml — a workflow that used the pull_request_target trigger and checked out the fork's merge ref. This gave the fork's code execution in the base repository's runner context, with full access to its cache scope.

The threat actors used Bun, which is a lightweight JavaScript runtime and package manager alternative to Node.js and npm as shown in Figure 1. The attack used Bun to execute the malicious payload tanstack_runner.js. This in turn attempted to enumerate the system for sensitive credentials, including invoking the GitHub CLI to capture the GitHub authentication token (gh auth token).

Code snippet of execution chain with some information redacted.
Figure 1. Mini Shai-Hulud TanStack execution chain on Windows.
Kubernetes

In a Linux-hosted Kubernetes environment, Unit 42 observed legitimate runc create container activity associated with a build pipeline that subsequently retrieved and executed the compromised JavaScript package. The runc create invocation itself was legitimate Kubernetes runtime activity associated with the containerized build process.

During the build:

  • The project again dynamically retrieved and executed the Bun runtime through its pnpm dependency chain
  • It subsequently executed the malicious JavaScript payload tanstack_runner.js
  • Then proceeded as in the Windows environment

The process lineage is shown in Figure 2.

Code snippet of execution chain in the kubelet node.
Figure 2. Mini Shai-Hulud TanStack execution chain in Linux hosted Kubernetes.

Step 2: GitHub Actions Cache Poisoning

The fork's code wrote a 1.1 GB poisoned pnpm store under the exact cache key that release.yml would later look up. The key was pre-computed from the public pnpm-lock.yaml using the same hashFiles() formula the workflow uses. The poisoned cache entry then sat dormant for eight hours.

A critical detail: actions/cache@v5's post-job save uses a runner-internal token, not the workflow GITHUB_TOKEN, so setting permissions: contents: read on the workflow does not prevent the cache write.

Step 3: OpenID Connect (OIDC) Token Extraction From Runner Memory

When a legitimate maintainer pushed to main, release.yml triggered, restored the poisoned cache and executed attacker-controlled binaries during the build phase. Those binaries read /proc/<Runner.Worker>/mem and extracted the OIDC token — minted lazily in runner memory only when id-token: write is set — then POSTed it directly to registry.npmjs.org.

The workflow's own Publish Packages step was never reached; tests failed and that step was skipped. npm received 84 valid, signed, provenance-attested package publishes anyway.

This is the same /proc-memory extraction technique documented in the tj-actions/changed-files compromise of March 2025 and reused in the April 2026 SAP and Bitwarden waves.

The SLSA Provenance Problem

This is the first documented case of a worm publishing malicious npm packages with valid SLSA Build Level 3 provenance. Sigstore correctly attested that the packages were built by release.yml from refs/heads/main of TanStack/router — because they were. SLSA provenance confirms which pipeline built a package, not whether that pipeline's internal state was clean.

The root cause is the same OIDC trust-scope misconfiguration exploited in the April 29 @cap-js wave. The trusted-publisher binding trusted the entire repository rather than a specific workflow on a protected branch.

Provenance verification is necessary but no longer sufficient. This is why behavioral analysis at install time is essential.

Payload and Propagation

The malicious payload, router_init.js (2.3 MB obfuscated), was not delivered via a preinstall hook on the compromised packages themselves. Instead, each tarball received an injected optionalDependencies entry pointing to an orphaned commit in the attacker's fork.

This is a commit that GitHub surfaces under the legitimate TanStack/router URL due to shared fork-network commit object storage:

The dependency is designed to fail silently during installation. The malicious code executes in the background while the install process appears normal, leaving near-zero trace in logs. The payload uses multiple layers of obfuscation and encryption to resist automated analysis. It shares the same custom cipher documented in the April 22 Bitwarden and April 29 SAP sections, confirming shared authorship across all three waves.

For secondary victims infected via worm propagation (e.g., UiPath, Mistral AI and OpenSearch), the delivery mechanism reverted to the familiar preinstall hook from the April SAP wave.

The pattern is now well-established. Once the worm gains a foothold in one ecosystem, it uses stolen credentials to republish itself into every other package the victim maintains, rapidly expanding its reach across unrelated projects and organizations.

The Dead-Man's Switch: A Critical Remediation-Order Warning

The May 11 payload installs a persistent background service that polls api.github.com/user with the stolen GitHub token every 60 seconds. If the token is revoked (HTTP 40x), the service executes rm -rf ~/ — destroying the user's home directory. The daemon auto-exits after 24 hours.

May 12, 2026: Public Release of the Worm

On the evening of May 12, 2026, the fully weaponized Mini Shai-Hulud source code was published to public GitHub repositories before being taken down. The toolchain including the CI cache-poisoning scripts, OIDC token extractor and the credential stealer with its propagation logic is now publicly available.

Mini Shai-Hulud is no longer scoped to TeamPCP. Future incidents using this toolchain may not share TeamPCP's infrastructure or tradecraft and should not be attributed solely on the basis of worm lineage.

May 19, 2026: @antv Wave

On May 19, 2026, the npm maintainer account atool was compromised as part of a new Mini Shai-Hulud wave. In approximately one hour, 639 malicious package versions were published across 323 unique packages. This is the largest single-hour package count of any Shai-Hulud wave to date.

The affected scope spans the @antv data visualization ecosystem and related libraries:

  • @antv/g2, g6, x6, l7, s2, f2, g, g2plot, graphin, data-set and s2-vue
  • Packages outside the @antv namespace including echarts-for-react ( approximately 1.1 million weekly downloads), timeago.js, size-sensor and canvas-nest.js

The potential area of impact across data visualization, graphing, mapping, charting and React component ecosystems is significant.

Infection Mechanism

Unlike the TanStack wave's pipeline-hijack technique, this wave returns to a simpler model. This involves compromising a maintainer account and using it to republish packages directly. This is the same approach seen in the September and November 2025 campaigns.

The attacker modified each package's package.json in three ways:

  • Adding a preinstall hook ("preinstall": "bun run index.js") that executes the malicious payload via the Bun runtime
  • Bundling Bun as a dependency to ensure it's available on any machine
  • Inserting a git-based optional dependency pointing to an orphaned commit in the legitimate antvis/G2 repository as a backup execution path

To ensure the malicious versions reached as many targets as possible, the attacker also bumped version numbers beyond the latest legitimate release (e.g., @antv/s2-vue jumped from the real version 2.2.0 to 2.4.0). Any project using a permissive version range like ^2.x would automatically pull the malicious version on its next install.

Payload Capabilities

The 499 KB obfuscated payload runs six credential collectors in parallel, sweeping a broad range of targets:

  • Developer credentials: GitHub tokens, npm tokens, SSH keys, Git credentials and private keys
  • Cloud and infrastructure: AWS credentials and parameters, Kubernetes service-account tokens, HashiCorp Vault secrets and Docker authentication
  • CI/CD platforms: Tokens from 18-plus platforms including GitHub Actions, GitLab CI, CircleCI, Vercel and Netlify
  • Third-party services: Database connection strings, Stripe, Slack and Twilio API keys
  • Password managers (new to this wave): The payload directly queries 1Password, Bitwarden, pass and gopass via their local CLIs

All stolen data is encrypted and sent to a C2 endpoint disguised as OpenTelemetry trace ingestion (t.m-kosche[.]com), meaning network monitoring tools may classify the traffic as legitimate observability telemetry.

A fallback channel exfiltrates data to GitHub repositories created under the victim's account, using Dune-themed names and the reversed campaign marker Shai-Hulud: Here We Go Again as the description.

April 2026 - Shai Hulud: A New Wave

Late April Mini Shai-Hulud Wave

As of April 29, 2026, a new supply chain attack wave (dubbed Mini Shai-Hulud) is actively targeting the SAP developer ecosystem via four compromised npm packages.

The affected versions are:

  • @cap-js/sqlite@2.2.2
  • @cap-js/postgres@2.2.2
  • @cap-js/db-service@2.10.1 mbt
  • @1.2.48

Combined, these packages carry approximately 570,000 weekly downloads, with @cap-js/sqlite and @cap-js/db-service each pulling around 250,000 and 260,000 downloads, respectively.

All four packages are part of SAP's Cloud Application Programming (CAP) Model and multitarget application (MTA) build toolchain. This makes the targets of this attack enterprise developers and CI/CD pipelines with access to cloud credentials, GitHub tokens and deployment secrets.

The campaign is a close structural continuation of the @bitwarden/cli@2026.4.0 compromise earlier in April 2026. It uses the same toolchain, same obfuscation and same propagation logic, which is now turned against the SAP ecosystem.

Attack Mechanism

Each compromised package received two new files:

  • setup.mjs
  • execution.js

These files arrived along with a modified package.json that adds a preinstall lifecycle hook ("preinstall": "node setup.mjs"). This means the malicious code executes automatically during the npm install process, before the installation is complete. The setup.mjs bootstrapper detects the host OS and architecture, then performs the following activities:

  • Downloading the Bun JavaScript runtime (v1.3.13) from the official github[.]com/oven-sh/bun releases
  • Extracting the runtime to a temporary directory
  • Immediately using it to execute execution.js

Payload Capabilities

The 11.7 MB single-file, obfuscated credential stealer, execution.js, is a propagation framework. It performs the following activities:

  • Using a custom string scrambling layer labeled ctf-scramble-v2 to hide sensitive strings from static analysis
  • Including a Russian locale killswitch (exiting silently if the system locale is set as ru)
  • Daemonizing itself on non-CI machines to run in the background

It harvests the following information:

  • GitHub tokens (including gh auth token output)
  • npm tokens from .npmrc
  • Full environment variable blocks
  • GitHub Actions secrets
  • AWS STS identity
  • Secrets Manager and SSM parameters
  • Azure Key Vault secrets
  • GCP Secret Manager values
  • Kubernetes service account tokens
  • Claude and MCP configuration files
  • Electrum wallets
  • VPN configs

A particularly aggressive CI path uses an embedded Python helper that reads the /proc memory of the GitHub Actions Runner.Worker process to extract masked secret values.

All collected data is:

  • Compressed
  • AES-256-GCM encrypted with a key wrapped under an embedded RSA public key
  • Exfiltrated to freshly created public GitHub repositories with randomized Dune-themed names and the description A Mini Shai-Hulud has Appeared

Propagation and GitHub Dead Drop

The campaign uses GitHub's public commit search API as a covert command and control (C2) channel. The malware performs the following activities:

  • Searching for commits containing the keyword OhNoWhatsGoingOnWithGitHub
  • Decoding matching commit messages as a token dead-drop to recover stolen GitHub tokens
  • Using them to spread

Once a usable token is obtained, the payload:

  • Copies itself into execution[.]js
  • Writes setup.mjs
  • Sets "preinstall": "node setup.mjs" in package.json
  • Increments the patch version
  • Repacks the tarball for publishing

The malware also pushes the following files directly into victim repositories:

  • .vscode/setup.mjs
  • .claude/execution.js
  • .claude/settings.json

The malware pushes the above files using commits authored as claude <claude@users.noreply.github.com> with the message chore: update dependencies.

The three forensic links to @bitwarden/cli@2026.4.0 are precise enough to indicate shared authorship or a directly reused toolchain.

1. The setup.mjs preinstall bootstrapper. In the Bitwarden campaign, setup.mjs was the self-replication artifact the worm (bw1.js) injected into every npm package the victim could publish. The SAP packages use that same filename as their bootstrapper, and the two share clear common lineage: same Bun version (1.3.13), same Alpine/musl detection logic and the same redirect-following download approach.

2. The decodeScramble / ctf-scramble-v2 obfuscation method. The Bitwarden payload encodes all sensitive strings using a custom seeded ASCII shuffle cipher. This is a Fisher-Yates shuffle over a 128-character ASCII table driven by a linear congruential PRNG seeded with 0x3039 (12345). The SAP execution.js uses a layer explicitly labeled ctf-scramble-v2, which is the same deterministic substitution scheme. This is not a library, it is a bespoke implementation. It is reused across both payloads.

3. The GitHub commit dead-drop pattern. The Bitwarden malware used GitHub's public commit search API as a covert C2 channel. It embedded stolen tokens in commit messages matching LongLiveTheResistanceAgainstMachines:<base64> and used them to bootstrap new exfiltration channels without attacker-controlled infrastructure.

This wave applies the exact same pattern under a new keyword (OhNoWhatsGoingOnWithGitHub) with matching commit messages decoded as a token dead-drop. The mechanism is identical in implementation:

  • Search the GitHub API for commits containing the keyword
  • Parse the commit message body
  • Decode the embedded token
  • Validate it for repository access

Rotating the keyword while keeping the technique intact is a hallmark of the same operator updating a reused codebase.

Broader Shai-Hulud Campaign Context

According to Checkmarx's official security update, this npm package is one component of a broader supply-chain campaign that simultaneously compromised multiple Checkmarx distribution channels:

  • Docker Hub: Poisoned checkmarx/kics images (v2.1.20, v2.1.21, latest, alpine, debian)
  • GitHub Actions: Malicious checkmarx/ast-github-action v2.3.35
  • VS Code extensions: Backdoored checkmarx/ast-results (v2.63, v2.66) and checkmarx/cx-dev-assist (v1.17, v1.19)
  • npm: The @bitwarden/cli package analyzed in this report

Per Checkmarx's disclosure, all artifacts share the same C2 infrastructure (audit.checkmarx[.]cx), the same obfuscation techniques and the same credential harvesting and propagation logic. The VS Code extension variant delivered its payload (mcpAddon.js) from a backdated orphan commit in Checkmarx's own GitHub repository, making the download URL appear trustworthy.

TeamPCP (@pcpcats) publicly took credit for the compromise. Per Socket's analysis, the group had previously targeted Checkmarx infrastructure in March 2026, along with Trivy and LiteLLM, suggesting an ongoing campaign against security tooling vendors.

Attack Overview

Table 1 shows the attributes of the attack.

Attribute Detail
Package @bitwarden/cli@2026.4.0
Trigger preinstall lifecycle script
Runtime Bun v1.3.13 (downloaded during install)
C2 server audit.checkmarx[.]cx:443 (94.154.172[.]43)
C2 path /v1/telemetry
Fallback C2 Dynamic, fetched via GitHub Search API dead drop
Exfiltration HTTPS POST (encrypted) + GitHub public repos
Attribution TeamPCP (@pcpcats)

Table 1. Attributes of the attack.

The Bitwarden security team provided the following information. They identified and contained the malicious package described in Table 1, which was briefly distributed through the npm delivery path for @bitwarden/cli@2026.4.0 between 5:57 PM and 7:30 PM EST on April 22, 2026, in connection with the broader supply chain incident.

Their investigation found no evidence that end user vault data was accessed or at risk, or that production data or production systems were compromised. Once the issue was detected, they:

  • Revoked compromised access
  • Deprecated the malicious npm release
  • Immediately initiated remediation steps

The issue affected the npm distribution mechanism for the CLI during that limited window, not the integrity of the legitimate Bitwarden CLI codebase or stored vault data.

People who did not download the package from npm during that window were not affected. Bitwarden completed a review of internal environments, release paths and related systems. They found no additional impacted products or environments at this time.

A CVE for Bitwarden CLI version 2026.4.0 is being issued in connection with this incident.

Stage 1: Bootstrap - bw_setup.js

The package.json provides two execution paths for the malicious script, as shown in Figure 3.

Screenshot of a code snippet in JSON format. It includes a "scripts" section with a "preinstall" key running node and a "bin" section with "bw".
Figure 3. Execution paths for the malicious script in the package.json file.

The preinstall hook runs automatically during npm install. The bin field registers bw_setup.js as the bw command, symlinking it into the user's PATH.

Since the legitimate Bitwarden CLI also uses bw as its binary name, this serves as a secondary trigger. Even if preinstall is blocked (e.g., via --ignore-scripts), the malware executes the next time the user or any script invokes bw. The shebang line #!/usr/bin/env node at the top of bw_setup.js ensures it runs as a Node.js script when called directly.

The bootstrap script performs three actions:

  1. Platform detection: Identifies the OS and architecture (Linux, macOS, Windows; x64 or arm64), including musl versus glibc detection on Linux.
  2. Bun runtime download: Downloads the Bun JavaScript runtime (v1.3.13) from the official github[.]com/oven-sh/bun releases. This is needed because the main payload uses Bun-specific APIs (shell execution, file I/O, gzip) not available in Node.js.
  3. Payload execution: Runs bw1.js using the freshly downloaded Bun binary.

A custom ZIP extraction implementation is included to avoid any dependencies, making the bootstrap entirely self-contained.

Stage 2: The Payload - bw1.js

The payload is an approximately 10 MB single-line JavaScript file containing approximately 285,000 lines when formatted. It bundles legitimate software developer kits (SDKs) (e.g., AWS SDK, Google Cloud client libraries, Azure Identity, Octokit, jsonwebtoken, tar) alongside the malicious orchestration code.

Obfuscation Techniques

The code employs multiple layers of obfuscation:

  • String table rotation: A function _0x214e resolves hex indices to strings from a large rotated array (_0x1ee1), breaking simple static string analysis.
  • Seeded ASCII shuffle cipher: Sensitive strings (domains, file paths, shell commands) are encoded as arrays of numeric indices into a Fisher-Yates-shuffled ASCII table. The shuffle uses a linear congruential PRNG seeded with 0x3039 (12345), as shown below in Figure 4.
Screenshot of a snippet showing a class named PRNG with a constructor and next methods. The constructor sets a seed value, while the next method recalculates the seed using a specific formula and returns it after division by a large number.
Figure 4. Seeded ASCII shuffle cipher.

The 128-character ASCII set is shuffled deterministically, producing a substitution table where an index with the hex value 0x42 maps to the ASCII character a, 0x6e to u. For example, the C2 domain is stored as [0x42, 0x6e, 0x36, 0x4b, 0x2b, 0x5c, 0xd, 0x57, 0x0, 0xd, 0x7, 0x26, 0x42, 0x3, 0x2a, 0x5c, 0xd, 0x2a], which decodes to an ASCII string for the domain audit.checkmarx[.]cx.

  • Gzip and Base64 embedded payloads: Several blobs are stored as gzip-compressed Base64 strings, including an RSA public key, a GitHub Actions workflow YAML, the worm's setup.mjs loader and a manifesto string
  • Mangled identifiers: All variable and function names are replaced with hex patterns such as _0x3865d8

Credential Harvesting

The payload deploys multiple provider classes, each targeting a different credential source. Every provider scans its results with regex patterns to extract npm and GitHub tokens, as shown in Figure 5.

Screenshot of a code snippet showing two regular expressions for detecting tokens: one for 'ghtoken' and another for 'npmtoken', both following a specific pattern.
Figure 5. Regex patterns to extract npm and GitHub tokens.
File System Provider (Cn)

Reads sensitive files from the developer's workstation, with per-OS path lists decoded via the scrambler as shown below in Table 2.

Platform Targeted Files
Linux ~/.ssh/id_*, ~/.ssh/keys, .git/config, ~/.npmrc, .npmrc, .env, ~/.claude/mcp.json, ~/.claude.json, ~/.kiro/settings/mcp.json
macOS ~/.aws/credentials, .git/config, ~/.npmrc, .npmrc, .env, ~/.claude.json, .claude.json, ~/.kiro/settings/mcp.json, .kiro/settings/mcp.json
Windows Credential store paths, config.ini

Table 2. OS path lists from the malware.

Files larger than approximately 5 MB are skipped. All others are read in full and included in the exfiltration payload.

Shell Provider (un)

Runs gh auth token via execSync to capture the GitHub CLI's active token, and then harvests the full process.env environment block. Both are returned for token-regex scanning and exfiltration. Unlike the cloud providers below, the Shell Provider does not use any SDK — it relies solely on the single shell command and environment variables.

GitHub Actions Provider (Co)

Detects CI/CD environments via process.env.GITHUB_ACTIONS === "true" and extracts all configured secrets by parsing {"value":"...","isSecret":true} patterns from the Actions runner context.

AWS SSM Provider (ku)

Uses the bundled AWS SDK (SSMClient, DescribeParameters, GetParameter) to enumerate and read parameters from AWS Systems Manager Parameter Store.

Azure Key Vault Provider (Rn)

Uses Azure Identity and Key Vault SDK to call getSecretsFromVault, listing and reading secrets from all accessible vaults.

Google Cloud Secret Manager Provider (uo)

Uses the Google Cloud Secret Manager client to listSecrets and accessSecretVersion, reading all accessible secrets across projects.

Exfiltration

All harvested credentials are processed through a two-tier exfiltration system.

Primary: HTTPS to C2 (Cy Class)
  1. Results are serialized to JSON and compressed with gzip
  2. A random 32-byte AES-256-GCM symmetric key is generated
  3. The data is encrypted with AES-256-GCM
  4. The symmetric key is RSA-encrypted with a hard-coded 4096-bit public key (Fr)
  5. The encrypted envelope is sent via POST hxxps[:]//audit.checkmarx[.]cx:443/v1/telemetry.
Secondary: GitHub Public Repositories (ky Class)

Using stolen GitHub tokens, the malware:

  1. Creates a new public repository under the victim's account with the description "Checkmarx Configuration Storage" and a Dune-themed name (e.g., gesserit-melange-813)
  2. Commits encrypted result files to a results/ directory
  3. Embeds stolen tokens in commit messages using the format LongLiveTheResistanceAgainstMachines:<base64_token>

This dual exfiltration ensures data reaches the attacker even if the C2 domain is blocked.

GitHub Actions Workflow Injection (u_ Class)

When the malware obtains a GitHub token with repo and workflow scopes, class u_ validates the scopes and then:

  • Enumerates repositories the victim can push to, prioritizing recently active ones
  • Checks whether each repo has configured GitHub Actions secrets (skips repos without them)
  • Creates a new branch, commits .github/workflows/format-check.yml — a malicious workflow that dumps all secrets, as shown below in Figure 6.
Screenshot of a a YAML configuration script for a GitHub Actions workflow. The workflow name is "Formatter" it uses the "actions/checkout" and "upload-artifact" actions. The workflow is configured to output results to a specific file.
Figure 6. Content of the format-check.yml file.
  • Downloads the resulting artifact containing all serialized secrets
  • Deletes the branch and workflow run to cover its tracks

npm Worm Propagation

This is the self-replicating component. When the malware finds an npm token (npm_...):

Token Validation

Calls the npm tokens API with Authorization: Bearer <token>, verifies the token has publish (write) permission on the package scope and that it bypasses two-factor authentication (2FA).

Package Enumeration

Using the validated token:

  • Fetches the npm username
  • Iterates through the token's allowed resources (orgs, scopes, specific packages)
  • Queries /-/org/<user>/package for writable packages
  • Falls back to /-/v1/search?text=maintainer:<user> for public packages
Tarball Download and Backdooring

For each target package:

  • Downloads the latest tarball from the npm registry
  • Extracts it to a temporary directory
  • Copies the Bun binary into the package
  • Rewrites package.json:
    • Clears all scripts
    • Sets "preinstall": "node setup.mjs" (decoded from the scrambler)
    • Bumps the patch version (e.g., 1.2.3 → 1.2.4)
  • Writes setup.mjs with the full worm payload (K$, a gzip+Base64 encoded copy of the malware)
  • Re-packs the tarball
Publishing

Writes a .npmrc with the stolen token's auth line (//registry.npmjs[.]org/:_authToken=<token>) and runs bun publish <tarball>.

Every newly infected package will trigger the same preinstall chain on any developer who installs it, creating an exponential propagation vector.

C2 Resilience: The GitHub Dead Drop

The malware implements a fall back mechanism for C2 resilience using GitHub's public search API as a covert command channel.

If the primary C2 server (audit.checkmarx[.]cx) is unreachable, the malware:

  1. Searches GitHub commits for the keyword beautifulcastle via the public Search API
  2. Finds a matching commit in [helloworm00/hello-world](hxxps[:]//github[.]com/helloworm00/hello-world) (commit bc544f4, dated April 21 - one day before the main attack)
  3. Parses the commit message body with the regex /beautifulcastle ([A-Za-z0-9+/=]{1,30})\.([A-Za-z0-9+/=]{1,700})/
  4. Decodes the first capture group from Base64 to get a domain
  5. Verifies the second capture group as a digital signature (512-byte RSA-4096) against the hard-coded public key Er, ensuring only the attacker can direct the malware to a new C2 server

At the time of analysis, the dead drop contained a placeholder value (hxxps[:]//example[.]com), indicating it was pre-staged for future use. The attacker can rotate C2 infrastructure at any time by creating a new signed commit on any public GitHub repository.

A second fall back (Hr function) searches for commits matching LongLiveTheResistanceAgainstMachines:<base64> to recover previously stolen GitHub tokens from exfiltration repos, bootstrapping new GitHub-based exfiltration channels without any attacker-controlled infrastructure.

Anti-Detection Measures

  • Russian locale killswitch: The mz0 function checks Intl.DateTimeFormat().resolvedOptions().locale, LC_ALL, LC_MESSAGES, LANGUAGE and LANG for Russian (ru). If any match, the malware calls process.exit(0) immediately without executing
  • Daemonization: The Ml0 function re-spawns the process detached with __DAEMONIZED=1 in the environment, allowing the parent to exit cleanly while the payload runs in the background
  • PID-based lock file: $l0 writes process.pid to a temp file and checks whether a previous instance is still alive via process.kill(pid, 0), preventing multiple instances from running simultaneously
  • Signal handlers: Catch SIGINT/SIGTERM with no-op callbacks (() => {}) to prevent interruption
  • Temp directory cleanup: After tarball manipulation removes forensic artifacts
  • All sensitive strings: Encoded via the scrambler or gzip+Base64
  • Silent error handling: Failures are caught and suppressed
  • Innocuous naming: The C2 path v1/telemetry mimics legitimate analytics endpoints

Interim Guidance

  1. Block the C2 domains and IPs listed above at the network perimeter.
  2. Rotate all credentials that may have been exposed: npm tokens, GitHub PATs, AWS/Azure/Google Cloud keys, SSH keys and CI/CD secrets.
  3. Audit npm packages you maintain for unauthorized version bumps or new preinstall hooks.
  4. Review GitHub for unauthorized repository creation, unexpected workflow files and artifact downloads.
  5. Search for the format-results artifact in GitHub Actions logs across your organization.
  6. Hunt for unexpected Bun process execution and outbound connections to the IoC infrastructure.
  7. Pin dependencies to known-good versions using lockfiles and integrity hashes.

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.

The following XQL query has been used to successfully identify execution of a JavaScript file through Bun that subsequently calls the GitHub CLI in a likely attempt to collect locally stored authentication tokens. While Bun is legitimate in many developer environments, its use as a runtime for package install malware in this campaign makes this behavior worth investigating when observed with credential access commands such as gh auth token:

Conclusion

Unit 42 has witnessed a shift since the September 2025 Shai-Hulud incident, proving that it wasn’t a temporary spike but the new baseline for software supply chain risk. In an ecosystem where code is shared at the speed of thought, a single compromised dependency can trigger a global cascade.

Ultimately, npm compromises share commonalities and organizations can navigate this volatility by keeping particular best practices in mind. As we continue to monitor, analyze and update our findings related to npm packages, we encourage you to move beyond static defenses and embrace a culture of continuous verification. The supply chain may be the new primary target, but with collective intelligence and relentless visibility, it doesn’t have to be the primary vulnerability.

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.

Mitigations for Compromised npm Packages

Enforce Cooldown Periods

Implement a policy (via a private registry or proxy like Artifactory) that blocks any package version published within the last 24 to 72 hours. Most malicious packages are identified and removed from the public registry within this window.

Disable Lifecycle Scripts

Many compromises rely on preinstall or postinstall hooks to exfiltrate secrets. Use the following in your .npmrc: ignore-scripts=true.

Version Pinning and npm ci

Use package-lock.json and ensure your CI/CD pipelines use npm ci instead of npm install. This prevents the "hidden" update of dependencies during a build.

Private Registry Proxying

Never allow developer machines or CI runners to talk directly to registry.npmjs[.]org. Route all traffic through a private registry.

Namespace Shadowing (Prevention of Dependency Confusion)

Attackers often publish packages with the same name as your internal libraries to the public registry. Always use scoped packages (e.g., @myorg/internal-lib) and configure your private registry to only resolve that scope internally.

Provenance Verification

Verify the OpenID Connect Attestation. Many major packages provide "provenance," proving the code was built on a specific GitHub/GitLab runner. Use tools like slsa-verifier to check these during the build.

Egress Filtering in CI/CD

Most npm-based malware attempts to send ~/.npmrc tokens or ~/.ssh keys to a C2 server. Apply strict egress network policies to your CI runners. Only allow connections to your private registry and known deployment targets.

Software Bill of Materials (SBOM)

Automatically generate an SBOM for every production release. This allows your security team to perform instant impact analysis when a new zero-day is announced.

Palo Alto Networks Product Protections Related to Compromised npm Packages

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 npm compromises, including the malicious Bitwarden package.

Cloud-Delivered Security Services for the Next-Generation Firewall

Advanced URL Filtering and Advanced DNS Security identify known domains and IP addresses associated with this activity as malicious.

Cortex Cloud

Cortex Cloud’s Application Security Module (ASPM) supports the scanning of npm packages installed on cloud resources as well as monitoring audit logs from third party SaaS vendors, including GitHub as discussed within this article. Cortex Cloud prioritizes alerts, issues, policies and assets based on ingested applications as well as their usage. This allows security teams to maintain security awareness across their on-premises and cloud environment by identifying and remediating impacted cloud resources and actively responding to associated runtime operations from the threats discussed within this article through Cortex Cloud’s XDR Agent and serverless operations. For additional details about how to protect against this threat using Cortex Cloud, please see their blog.

Koi Agentic Endpoint Security

Koi Agentic Endpoint Security allows customers to delay automatic updates for all installed packages by a set time window, allowing newly pushed versions to establish reputation and undergo public scrutiny before being deployed in your environment.

Indicators of Compromise

Indicators From April 29, 2026 Activity

Affected Packages

  • @cap-js/sqlite@2.2.2
  • @cap-js/postgres@2.2.2
  • @cap-js/db-service@2.10.1 mbt@1.2.48

SHA256 Hashes

  • setup.mjs: 4066781fa830224c8bbcc3aa005a396657f9c8f9016f9a64ad44a9d7f5f45e34
  • execution.js: 6f933d00b7d05678eb43c90963a80b8947c4ae6830182f89df31da9f568fea95

URLs

  • hxxps[:]//github[.]com/oven-sh/bun/releases/download/bun-v1.3.13/ (Bun download)
  • hxxps[:]//api.github[.]com/search/commits?q=OhNoWhatsGoingOnWithGitHub (dead drop)

Indicators From April 22, 2026 Activity

Network Indicators

Table 3 lists the network indicators from this activity.

Indicator Type
audit.checkmarx[.]cx C2 domain
94.154.172[.]43 C2 IP address
checkmarx[.]cx Attacker-controlled domain
91.195.240[.]123 Attacker IP address

Table 3. Network indicators.

GitHub Indicators

Table 4 lists the GitHub indicators from this activity.

Indicator Type
helloworm00/hello-world Dead drop repository
bc544f455d7c06c8a1f3446160a6d9a4a8236b11 Dead drop commit SHA1 hash
helloworm00@proton[.]me Attacker email address
Commit messages matching LongLiveTheResistanceAgainstMachines:* Exfiltration staging
Public repositories named <dune-word>-<dune-word>-<3digits> with description "Checkmarx Configuration Storage" Exfiltration repositories

Table 4. GitHub indicators.

Files and Process Indicators

Table 5 lists the file and process indicators from this activity.

Indicator Type SHA256 hash
bw_setup.js Bootstrap script f35475829991b303c5efc2ee0f343dd38f8614e8b5e69db683923135f85cf60d
bw1.js Obfuscated payload 18f784b3bc9a0bcdcb1a8d7f51bc5f54323fc40cbd874119354ab609bef6e4cb
package.json Malicious manifest 167ce57ef59a32a6a0ef4137785828077879092d7f83ddbc1755d6e69116e0ad
setup.mjs in infected packages Worm payload
Unexpected bun process execution Runtime indicator
.github/workflows/format-check.yml on transient branches Workflow injection
format-results workflow artifact Secret exfiltration

Table 5. File and process indicators.

npm Indicators

Table 6 lists the npm indicators from this activity.

Indicator Type
@bitwarden/cli@2026.4.0 Malicious package
New preinstall: "node setup.mjs" in package.json Injected hook

Table 6. npm indicators.

Additional References

Updated April 27, 2026 at 2:15 p.m. PT to add information about Bitwarden and link to the Cortex Cloud article in the Additional References section.

Updated May 1, 2026 at 4:55 p.m. PT to add information on the Mini Shai-Hulud campaign.

Updated May 20, 2026 at 12:30 p.m. PT to update the Executive Summary with information on two new waves and add a new section on Mini-Shai Hulud May 2026 waves.

Updated May 21, 2026 at 8:45 a.m. PT to add managed threat hunting queries and additional product protection. 

Tracking TamperedChef Clusters via Certificate and Code Reuse

Posted on by Sheida Azimi

Executive Summary

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:

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics AI, Malware, Adware, RATs, Malvertising

The Rise of Malicious Productivity Applications

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
Screenshots of four website homepages in a collage advertising PDF software. The top left shows "Sonic PDF" offering premium PDF software for Windows with advanced features. The top right is "PDF SuperDrive," highlighting professional PDF software and its user base stats. The bottom left is "Crystal PDF," featuring a free download for PDF conversion and management. The bottom right is "ImageryX," promoting neural creativity with vibrant visuals.
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.exe binary 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.

A diagram shows two orange boxes labeled "CROWN SKY LLC" and "MARKET FUSION INNOVATIONS LLC" on the left with arrows pointing to three other boxes labeled "Calendomatic.exe," "ManualzPDF.exe," and "PDFPrime.exe.
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).

Screenshot of the OneZIP website homepage. It features a prominent "Download OneZIP" button, with text promoting the tool's features: instant file conversion to ZIP, security, and high user rating. The page highlights benefits like lightning-fast speed, no registration, and Windows compatibility.
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.

Screenshots of three adjacent banners promoting OneZip's file compression service in French, English, and German. Each banner has the OneZip logo and a download button featuring a zipped folder icon. The company name "Candy Tech Ltd" is displayed at the bottom of each banner.
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.

Screenshot of Candy Tech webpage with a minimalist design. Illustration of a person sitting on abstract shapes using a laptop. Text reads "Powerful Utility Tools Made Simple." A button labeled "Learn More" is displayed below. The navigation menu includes "Home," "About," and "Contact."
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.

Screenshot of a webpage from FireArc featuring five sections: Gaming, CTV, ECommerce, Content, and Utility Apps. Each section has a brief description and a "Learn More" link. The top menu includes About, Business Units, Company, Careers, and Contact.
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:

  • 248de1470771904462c91f146074e49b3d7416844ec143ade53f4ac0487fdb44
  • 2231bfa7c7bd4a8ff12568074f83de8e4ec95c226230cccc6616a1a4416de268

The Wide-Reaching Web of TamperedChef

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.

Buying Legitimacy: Purchasing Code-Signing Certificates

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.

Additional Resources

Gremlin Stealer's Evolved Tactics: Hiding in Plain Sight With Resource Files

Posted on by Mark Lim

Executive Summary

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:

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics Infostealer, Telegram, Cryptocurrency

New Gremlin Site for Publishing Data

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.

Screenshot of a computer screen displaying a login interface for "GREMLIN" on a dark background. It includes input fields for username and password, with a prominent green "Login" button.
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.

Screenshot of a VirusTotal webpage analyzing a URL. The analysis shows 0 out of 71 security vendors flagged the URL as malicious. Status is 200 with the content type listed. Tabs for details, relations, content, telemetry, and community are visible.
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.

Screenshot of a dashboard interface of the "Gremlin" application displaying statistics such as the number of online devices (11), data usage (0.83 MB), and uptime (12:40:52). The interface includes sections with buttons labeled in Russian for each device, showing options to "Online" and "Delete.
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.

Screenshot of a hex editor displaying hexadecimal code on the right pane and a directory tree on the left, including folders like "Version Info" and "Configuration Files." The displayed code includes both hexadecimal and ASCII representations.
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.

Screenshot of a text document showing a process for XOR decryption and URL extraction. The text notes successful URL findings with keys 20, 31, and 49. The process concludes with a message stating "Decryption and URL extraction complete".
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:

Comparison with Older Version

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.

Two side-by-side screenshots of code editors. The left screenshot displays an older version with a list of entities like "AesCrypto," "Armory," "Asset," and others under the namespace "SHAPP." The right screenshot shows the latest version, also under "SHAPP," with a longer list including additional entries or modified ones. Both have red outlines highlighting the lists.
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.

Screenshot of Exeinfo PE software window displaying file information. The header shows version 0.0.9.0 by A.S.L. The main section includes details about a file named '217.exe', such as entry point, file offset, and subsystem. A section below highlights "(PACKED mode)". Various buttons and icons are visible on the right
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.
  • Example: A line like this from the original code:

csharp

// This is what the obfuscated code looks like

string url = global::_003CModule_003E.c(18829, 2178, 23);

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.
  • Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious.
  • Advanced Threat Prevention has an inbuilt machine learning-based detection that can detect exploits in real time.
  • Cortex XDR and XSIAM are designed to:
    • Prevent the execution of known malicious malware, and also prevent the execution of unknown malware using Behavioral Threat Protection 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:

  • 2172dae9a5a695e00e0e4609e7db0207d8566d225f7e815fada246ae995c0f9b
  • 9aab30a3190301016c79f8a7f8edf45ec088ceecad39926cfcf3418145f3d614
  • 971198ff86aeb42739ba9381923d0bc6f847a91553ec57ea6bae5becf80f8759
  • ab0fa760bd037a95c4dee431e649e0db860f7cdad6428895b9a399b6991bf3cd
  • f76ba1a4650d8cafb6d3ff071688c5db6fd37e165050f03cece693826f51d346
  • a9f529a5cbc1f3ee80f785b22e0c472953e6cb226952218aecc7ab07ca328abd
  • 691896c7be87e47f3e9ae914d76caaf026aaad0a1034e9f396c2354245215dc3
  • 281b970f281dbea3c0e8cfc68b2e9939b253e5d3de52265b454d8f0f578768a2
  • 9fda1ddb1acf8dd3685ec31b0b07110855832e3bed28a0f3b81c57fe7fe3ac20
  • d11938f14499de03d6a02b5e158782afd903460576e9227e0a15d960a2e9c02c
  • 1bd0a200528c82c6488b4f48dd6dbc818d48782a2e25ccd22781c5718c3f62f5

URLs

  • hxxp[:]194.87.92[.]109/i.php

Additional Resources

Inside AD CS Escalation: Unpacking Advanced Misuse Techniques and Tools

Posted on by Sheida Azimi

Executive Summary

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.

Cortex XDR and XSIAM customers are protected from this activity with Cortex User Entity Behavior Analytics (UEBA) and Cortex Cloud Identity Security.

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics Active Directory, Fighting Ursa, Microsoft

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.

Diagram titled "Server Side AD CS Infrastructure" showing three sections. First section: "Certificate Authority" with an icon of servers, labeled "issues certificates." Second section: "Certificate Templates" with a document icon, labeled "define policies." Third section: "Issued Certificates" with a certificate icon, labeled "provide authorization and encryption." Below, a "Client Side" section shows icons of a person and a database labeled "User" and "SQL Server," with "consume certificates.
Figure 1. PKI architecture showing CA → Templates → Certificates → Users and Services.

For additional background on AD CS fundamentals, see Detecting AD CS Abuse.

Ongoing Exploitation and Blind Spots

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.

Cortex XDR alert with diagram showing a file named update6.exe. Text indicates a machine certificate was issued with a mismatch, indicating abuse related to CVE-2022-26923. Some identifying information is redacted.
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:

  1. Initial access: Compromising low-privileged accounts via phishing, credential theft or other vectors
  2. Discovery: Enumerating CA servers, certificate templates, enrollment permissions and account keys
  3. Exploitation: Misusing misconfigured templates to request certificates or register cryptographic keys for privileged accounts
  4. 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
  5. 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.

Flowchart of the Active Directory CS attack chain in five stages: Initial Access (Compromise user), Discovery (Enumerate templates), Exploitation (Request certificate), Privilege Escalation (Use certificate to Kerberos), and Persistence (Shadow credentials, renewals). Arrows indicate the sequence from Initial Access to Persistence.
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.

A screenshot titled "Vulnerable template Properties" displaying settings tabs. The "Subject Name" tab is open, showing options. A selection is highlighted by a red box around "Supply in the request.
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:

  • Low-privileged users have enrollment rights
  • Requesters can specify a subject alternative name (SAN) (ENROLLEE_SUPPLIES_SUBJECT)
  • Manager approval is disabled
  • No authorized signatures are required
  • 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.

A screenshot of a code snippet displaying JSON configuration related to a Vulnerable template with different sections highlighted in red.
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

  1. Key registration: The attacker adds key credentials to the target account’s msDS-KeyCredentialLink attribute, usually through AD manipulation or elevated access
  2. 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.

Tool Primary Use Case Notes
Certify Enumerates and exploits AD CS templates C# tool, supports multiple ESC-style attack paths
Certipy Certificate template exploitation and AD enumeration Python-based, covers ESC1-ESC16 attack paths
PKINIT tools Misuse PKINIT for Kerberos Ticket Granting Ticket (TGT) requests Supports certificate-based Kerberos authentication
Whisker Shadow credentials and Key Trust misuse C# tool, manipulates the msDS-KeyCredentialLink attribute
pyWhisker Shadow credentials and Key Trust misuse Python equivalent of the Whisker tool

Table 1. Common AD CS attack tools.

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.

The image shows a computer screen with a program called "Certify" in ASCII art text. Below, instructions are given to find certificate authorities using the search base "CN=Configuration,DC=env12,DC=local". It displays a list under "Root CAs" with details such as certificate thumbprints and serial numbers, along with date and time stamps.
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.

The image is a diagram displaying a cybersecurity alert in Cortex XDR. The alert involves "LDAP AD CS Enumeration via Attack Tool" with the command `certipy.exe`. The path shows a flow from "certipy.exe" to a triangle containing an exclamation mark, which indicates a warning or critical point. Descriptions and potential sources of the alert are on the left. Some identifying information is redacted.
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.

Command line interface displaying text related to managing certificates and keys. It involves generating and updating credentials.
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.

Additional Resources

Appendix A: Detection Strategies: Beyond Signatures

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.

The image shows a screenshot of an Event 1644 from Active Directory Domain Service. The event details include an internal client event.
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.

Cortex XDR alert for "Possible LDAP Enumeration Tool Usage." It includes sections labeled "Description," "Source," and "Module," with text partially masked. On the right, a diagram features a circular element connected to a red triangle with an exclamation mark, indicating an alert. "ADExplorer.exe" and "CGO" are displayed below the diagram. Some identifying information is redacted.
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.​

Screenshot of a Microsoft Windows security auditing event log for event ID 5136. The active directory domain service is "env12.local" with various distinguished names (DNs) and a GUID partially blurred.
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.

Threat Brief: Exploitation of PAN-OS Captive Portal Zero-Day for Unauthenticated Remote Code Execution

Posted on by Unit 42

Executive Summary

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).

EarthWorm has reportedly been used by the threat actor behind CL-STA-0046, Volt Typhoon, UAT-8337 and APT41.

ReverseSocks5

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

Advanced URL Filtering and Advanced DNS Security identify known URLs and domains associated with this activity as malicious.

Cortex AgentiX

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.

Indicators of Compromise

  • 67.206.213[.]86
  • 136.0.8[.]48
  • 146.70.100[.]69 (C2 Staging)
  • 149.104.66[.]84
  • hxxp[:]//146.70.100[.]69:8000/php_sess (EarthWorm Download)
  • hxxps[:]//github[.]com/Acebond/ReverseSocks5/releases/download/v2.2.0/ReverseSocks5-v2.2.0-linux-amd64.tar[.]gz (ReverseSocks5 Download)
  • e11f69b49b6f2e829454371c31ebf86893f82a042dae3f2faf63dcd84f97a584 (EarthWorm)
  • Safari/532.31 Mozilla/5.5 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36 Edg/138.0.0.0 (Attacker User Agent String)
  • /var/tmp/linuxap, /var/tmp/linuxda, /var/tmp/linuxupdate (Tunneling Tools)
  • /tmp/.c (Unidentified Python Script)
  • /tmp/R5, /var/R5 (ReverseSocks5)

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.

Copy Fail: What You Need to Know About the Most Severe Linux Threat in Years

Posted on by Sheida Azimi

Executive Summary

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:

  • echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
  • rmmod algif_aead

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.

Conclusion

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 Prevention security 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.

Essential Data Sources for Detection Beyond the Endpoint

Posted on by Ria Bhatia

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.

Additional Resources

That AI Extension Helping You Write Emails? It’s Reading Them First

Posted on by Oleksii Starov

Executive Summary

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:

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics GenAI, Infostealer, Remote Access Trojan

Examples of Extensions Disguised as AI Tools

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)
  • Cursor customization extensions delivering potentially unwanted programs (PUPs) (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.
DOM-based exfiltration 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.

Table titled "Six Malware Categories Observed in GenAI Browser Extensions." It lists categories, names, extension IDs, users, and versions. Categories include Remote Access Trojan, InfoStealer, Search Hijacker, Brand Impersonator, Spyware, and Adversary in the browser. Various extensions with significant user numbers are detailed.
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.

  • Extension ID: fpeabamapgecnidibdmjoepaiehokgda
  • SHA256 hash: 0cbf101e96f6d5c4146812f07105f8b89bd76dd994f540470cd1c4bc37df37d5

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.”

Screenshot of the Chrome Web Store featuring the "Chrome MCP Server - AI Browser Control" extension. The page shows details like user reviews and a section with screenshots, highlighting features of the extension.
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.

Code snippet from a file showing configuration settings for connecting to a remote server. The settings include host name, port number, and related URL paths for server configuration and HTTP. Reconnection intervals and maximum attempts are also specified.
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.

Two screenshots showing code snippets. The left side highlights an extension manifest with permissions that enable full browser control. The right side emphasizes a background process that initiates a persistent C2 connection via WebSocket. Below, an arrow points to a response from a C2 server containing a session ID.
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.

Code snippet showing a function named `handleExecuteScript` using asynchronous JavaScript. It includes a `try` block to query active Chrome tabs and executes a script. Results are processed and errors handled with a catch statement.
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.

  • Extension ID: eebihieclccoidddmjcencomodomdoei
  • SHA256 hash: ac0a312398b3bf6b3d7c5169687ca72f361838bc5a90f2c0dbce2dc8e2094a02

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.

Code snippet illustrating a fetch API call. The method is POST, with JSON stringified body parameters including subject, from, to, body, and threadId.
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.

Screenshot of a split screen. On the left is a Gmail inbox with an email highlighted, containing the number 756843. On the right is a browser's DevTools displaying a JSON response with the key "content" and the value mentioning a LinkedIn account verification code, also showing the number 756843.
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.

  • Extension ID: iefpkdilnfhogjbkhgnliaomoldgkdlj
  • SHA256 hash: 604c7aef72892b56ac23ad54744376574239c8f0651e95dd5b6cf540eb70f7c3

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.

Screenshot of a browser window displaying an AI job application assistant titled "Reverse Recruiting." The interface includes a dashboard overview with sections for applications, activity, and results analytics. There is an extension button on the right labeled "Install Extension," and options for sharing, accessing tools, and user information on the left.
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.

Screenshot snippet of JavaScript code is displayed, focusing on retrieving and handling API keys for OpenAI, Gemini, and Claude within a storage system. The code also includes a fetch request to an API endpoint.
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:

  • Extension ID: jhhjbaicgmecddbaobeobkikgmfffaeg
  • SHA256 hash: dfe307d957724ebe32331f92d53e366b7fa85968a9564c2285c5a0142ac9e1bb

The search hijacker changes and controls the default search engine as noted in Figure 10.

Screenshot of Google Chrome settings under "Search engine" section. It shows an option managed by "Chat AI for Chrome," with buttons to manage or disable it. Options to manage search engines and site search are visible on the sidebar.
Figure 10. Chat AI for Chrome extension controlling the search engine in Chrome.

Chat AI for Chrome generates a unique user identifier on installation and stores it in three persistence layers:

  • chrome.cookies
  • window.localStorage
  • chrome.storage.sync (syncs across all Chrome instances signed into the same Google account)

It then registers a listener on Chrome's cookie change events, as noted in the code snippet in Figure 11.

Screenshot of a code snippet for managing cookies in a web browser extension. It adds a listener to changes in cookies and sets a new cookie with the name "tracking_id" if a specific condition is met.
Figure 11. Snippet showing extension’s persistent tracking cookie behavior.

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.

Screenshot of a code snippet showing a JSON configuration for Chrome settings overrides. It specifies a search provider with a search URL pointing to chatgptforchrome.com and includes a key "is_default" set to true.
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.

  • Extension ID: hmkcidjcpomiegnklmplkimmbcbklglb
  • SHA256 hash: 4e38bee33237a8c8b17a2504013e506ca7cbf667a7f68a2d94d75db505c2149f

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.

Screenshot of a code snippet showing a script for a Chrome extension. It adds a listener to open "thanks.html" upon installation, with comments in English and Polish explaining the function.
Figure 13. Snippet showing onInstalled listener opening a forced tab for thanks.html.
Screenshot showing a webpage with two sections. The left side displays a blurred image with a 3.5-star rating and an overview text. The right side promotes Opera GX with features like tech and privacy tools, a seamless extension support, and quick setup steps.
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.

  • Extension ID: dgeiaiglmhdhajbpfbmajaajdlfdinpi
  • SHA256 hash: c9754454efede2dec2fcb856faa40424b8df378706b664a5ae4847fcd0336b53

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.

Screenshot of a code snippet listing permissions required for browser extensions. It includes permissions like storage, scripting, context menus, and web requests. Host permissions allow access to all URLs, and external connectivity matches a specific URL pattern.
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.

Screenshot of a code snippet showing JavaScript configuration for a proxy script. The script fetches a PAC file and sets it using Chrome proxy settings.
Figure 16. Snippet showing malicious proxy hijacking via dynamically fetched content.

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.

Screenshot of a code snippet showing a configuration for links in a JavaScript object with comments detailing different sections: Configuration, State, Functions, and Init.
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:

  • Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious.
  • 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.

Additional Resources

TGR-STA-1030: New Activity in Central and South America

Posted on by Unit 42

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.

We have observed the same tactics, techniques and procedures used previously by this group.

Additional Resources

Frontier AI and the Future of Defense: Your Top Questions Answered

Posted on by Samantha Stallings

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.

Additional Resources

Can AI Attack the Cloud? Lessons From Building an Autonomous Cloud Offensive Multi-Agent System

Posted on by Yahav Festinger

Executive Summary

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:

Organizations can gain help assessing cloud security posture through the Unit 42 Cloud Security Assessment.

The Unit 42 AI Security Assessment can help empower safe AI use and development.

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics Cloud, AI, Multi-Agent, LLM, Google

Background: LLM Agents and Security

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.

A GIF of a terminal window showing the Zealot Agent Client launching in a command line interface. It provides instructions to exfiltrate sensitive data from BigQuery using a GCP VM instance.
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.

A diagram illustrating a hierarchy of security agents. At the top, a "Supervisor" oversees three agents: "Infrastructure Security Agent," "Application Security Agent," and "Cloud Security Agent."
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:

  1. 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.
  2. 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.
  3. 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.

A diagram illustrating a cybersecurity system called "AttackState." It displays interconnected components. Supervising this system is the "Supervisor" with "full state read/write" capability. Arrows indicate processes between the main system and various agents: Infrastructure Security Agent, Application Security Agent, and Cloud Security Agent. A note at the bottom describes "Turn-based, exclusive access" for agents to update the shared state sequentially.
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.

A flowchart detailing a multi-phase cybersecurity attack. Phase 1 involves infrastructure agent reconnaissance with activities like port scanning and cloud platform enumeration. Phase 2 focuses on initial access via an application security agent, highlighting SSRF vulnerabilities and metadata service access. Phase 3, cloud enumeration by a cloud security agent, involves identifying IAM permissions and a sensitive database. Phase 4, escalation and exfiltration, outlines data exfiltration to an attacker-controlled bucket and mission completion.
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.

A screenshot of a terminal screen showing text from an Nmap scan. It lists network interaction details, packet loss, and two open ports.
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.

A screenshot of a code snippet related to Google Cloud services. It shows JSON configuration and shell commands for setting IAM roles and service accounts. A highlighted section includes a command using `curl` to set a policy with the `objectAdmin` role. A caption at the bottom states, "The CloudSec agent adds itself the objectAdmin role.
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.

Organizations can gain help assessing cloud security posture through the Unit 42 Cloud Security Assessment.

The Unit 42 AI Security Assessment can help empower safe AI use and development.

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)
GCP service account impersonation attempt XDR Analytics BIOC, Cloud Valid Accounts: Cloud Accounts (T1078.004), Abuse Elevation Control Mechanism: Temporary Elevated Cloud Access (T1548.005), Trusted Relationship (T1199)
Storage enumeration activity XDR Analytics, Cloud Cloud Storage Object Discovery (T1619), Cloud Infrastructure Discovery (T1580)
BigQuery table or query results exfiltrated to a foreign project XDR Analytics BIOC, Cloud Transfer Data to Cloud Account (T1537)
A cloud storage object was copied to a foreign cloud account XDR Analytics BIOC, Cloud Transfer Data to Cloud Account (T1537)

Additional Resources

When Wi-Fi Encryption Fails: Protecting Your Enterprise from AirSnitch Attacks

Posted on by Emmanuel Zhou

Executive Summary

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:

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Related Unit 42 Topics Network Security, MitM

The AirSnitch Threats: A New Security Paradigm

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 (⑤)
A diagram comparing two threat models. The "Traditional Threat Model" depicts a router connected to a masked figure icon labeled "Malicious Actor." The "AirSnitch Threat Model" shows various interconnected components, including a globe, router, and multiple masked figure icons labeled "Malicious Actor," each with numbered connections indicating different threat paths.
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.

A diagram of a Wi-Fi network showing a router labeled "SSID: Test" connected to three clients: a smartphone, a computer, and a tablet, each with a yellow key icon.
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.

A flow chart showing a network attack scenario. It includes an attacker device connected to AP1 (access point 1), which is connected to a router. The router connects to AP2 (access point 2) and then to a victim device. Arrows indicate the flow of network packets between the entities.
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.

A diagram showing two types of port stealing. On the left, the diagram shows data flow from a cloud to an AP, then to a hacker figure, bypassing a user. On the right, the diagram displays data flow reversed from a user to an AP, then diverting to the hacker figure before reaching the cloud.
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).

A diagram showing a network setup. An AP connects to two bands: 2.4G, with an icon blocking a suspicious individual, and 5G, linking to a smartphone, desktop, and monitor.
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.

A person in an office building is visibly frustrated while using a laptop connected to "Internal Wi-Fi Client." A diagram shows a connection between the laptop and a "WPA2/3-Enterprise WLAN," which links to a distant "Faraway AP (Guest SSID)" on a telecommunications tower. Nearby, a cloaked figure holds a device, suggesting they are accessing the network.
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:

  1. Does your enterprise strictly separate guest SSIDs from WPA2/3-Enterprise SSIDs on Wi-Fi APs?
  2. 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?
  3. Does your enterprise use weak RADIUS passphrases on Wi-Fi APs?
  4. Does your enterprise update endpoint operating systems to newer, patched versions?
  5. Does your enterprise use robust, secure virtual private network (VPN) solutions for even intranet access?
  6. 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

Additional Resources

Fracturing Software Security With Frontier AI Models

Posted on by Sheida Azimi

Introduction

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.

Unit 42 predicts an increase in large-scale supply chain compromises of OSS projects, similar to the recent TeamPCP supply chain attacks and North Korea’s attack on the Axios JavaScript library.

A New Frontier in AI-Enabled Attack Paths

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 only a few notable exceptions, such as Anthropic’s reporting on GTG-1002 AI-enabled attacks against approximately 30 organizations and Amazon’s reporting on threat actors targeting edge devices at scale, the world has yet to see massive adoption of AI in large-scale campaigns.

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.

A diagram illustrates an AI-enabled attack path, orchestrated by an MCP C2 Server. It details four stages: AI reconnaissance and initial access, autonomous lateral movement and discovery, AI-driven exploitation with custom exploits, and LLM-summarized data exfiltration. A central cloud icon represents the MCP C2 server.
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.

Additional Resources

Get the latest news, invites to events, and threat alerts

Default Heading

Read the article Right Arrow