The predominance of cloud-based apps and the trend towards remote work have made the browser the place where most work happens. In fact, about 85% of daily work takes place there.
In many ways, it’s a win for all involved.
Users can work from a wider range of locations and devices, accessing full “desktops” inside a browser tab. Organizations can manage apps and browser access easier than through localized desktop software. This all allows for greater central management, lower costs and better flexibility.
But where work goes, attackers tend to follow.
In Unit 42’s 2025 Global Incident Response Report, nearly half of the incidents we investigated involved malicious activity launched or facilitated through employees’ browsers. Popular tactics include phishing, abuse of URL redirects and malware downloads – each one exploiting the browser session without adequate detection or blocking.
Why Browsers Fail: Common Pitfalls and Security Lapses
Google Chrome, Apple Safari, Mozilla Firefox and Microsoft Edge come from the biggest, most trusted names in tech. As such, users tend to treat the browser as a defense between the internet and the organization’s infrastructure.
Though browsers do provide some security through TLS connections, sandboxing and automatic updates, attackers still plant malicious traps for unsuspecting users to trip.
Social Engineering
Fraudulent emails, fake websites and login portals, malicious links and files – phishing attacks are largely conducted through browsers.
Browser Extensions
Marketplaces like the Google Web Store offer tens of thousands of extensions. Many of these extensions aren’t secure, and some are outright malicious—in fact, a Stanford University study found that 280 million Google Chrome users installed extensions containing malware over a three-year period.
Users who work on their personal device face more risk. Unlike managed corporate environments, personal devices often lack centralized security policies and monitoring to vet or block suspicious extension installations. For example, an extension for converting files or finding retail discounts may hold malware.
Browser-Specific Tactics
Session hijacking tactics allow malware on the endpoint to steal session tokens from the browser in order to impersonate the user. Once a session is compromised, numerous other security controls can be bypassed. Cross-site scripting allows attackers to inject scripts into web-based apps. These scripts can steal user sessions, modify transactions or show fake login screens.
No Clicking Necessary
“Don’t click anything suspicious” is no longer valid advice. Malicious assets seem more authentic than ever, and many don’t even need clicking. Simply visiting a malicious or compromised website can cause malware to be downloaded and installed without the user’s knowledge or interaction.
A Lack of Policy
For many organizations, the browser isn’t on their radar in terms of being part of the attack surface. As such, many organizations allow insecure protocols and lack an inventory of permissible extensions.
Think of the browser as the new endpoint. Through the browser, users access internal systems, sensitive information, source code, financial transactions and more.
Crucial Steps Every Defender Should Take
New tools are emerging that help secure the browser. For example, enterprise-grade secure browsers come with strict extension allow lists. They conduct data loss prevention based on context directly in the browser, enable role-based browsing permissions and more.
With or without these tools, organizations should still take steps to harden systems and pursue strategies that support browser security.
See all traffic without needing to decrypt traffic, by analyzing the encrypted traffic’s behavior rather than its contents.
Extend zero trust to the browser by implementing multi-factor authentication for every browser-based app and using step-up MFA for sensitive user actions. Tailor access rules according to context like device security posture, location, or network
Bring the browser into the fold of security by implementing tools that detect suspicious behavior like credential misuse, sensitive access from unknown devices and malware hidden in large files before they are downloaded.
Zero Trust: Implementation Strategies
Just as organizations would implement zero trust in internal systems, they should verify identity and control access tightly within the browser.
First things first: authenticate the user’s access permissions before they open the browser. Then, validate the user’s identity before granting access to any web app and apply conditional access.
Apply the principle of least privilege to SaaS and web apps — which users can access which apps and what they can do inside them — with granular last-mile data controls.
Assume all web traffic and extensions are risky. Only allow vetted, enterprise-approved extensions. Continuously monitor extensions and block them should they pose a risk.
Continuously monitor browser sessions for risky behavior and log everything. Perform continuous risk assessment regarding device health, user behavior and application risk.
Finalizing your Playbook: Achieving Superior Browser Security
Our Prisma Browser combines zero trust principles by leveraging our cloud-delivered security services. It provides real-time traffic inspection without the need for encryption, malware prevention, URL filtering and data loss prevention across traffic — all without an agent. Working with Prisma Access secures access to internal applications without exposing them to the public internet, ensuring every user and device is continuously authenticated and authorized before granting access.
In October 2025, we published two Insights blogs on threat activity affiliated with the cybercriminal alliance known as Scattered LAPSUS$ Hunters (SLSH). After a few weeks of apparent inactivity, the threat actors have returned with a vengeance based on open-source reporting and conversations obtained from a new Telegram channel (scattered LAPSUS$ hunters part 7). This latest Insights threat blog will detail several notable observations made by Unit 42 since mid-November, and prepares organizations as we head into the holiday season.
New Data Theft Allegations and Imposed Deadline
On Nov. 20, 2025, Salesforce released a security advisory acknowledging that they had detected “unusual activity involving Gainsight-published applications.” This led the company to revoke “all active access and refresh tokens associated with Gainsight-published applications” while also temporarily removing such applications from their AppExchange while they conduct an investigation.
At the time of this writing time, Salesforce assesses that the activity was not a result of any vulnerability in their platform and that “this activity may have enabled unauthorized access to certain customers’ Salesforce data through the app’s connection.” The company has notified all impacted customers and issued an additional advisory on Nov. 22, 2025 with a number of indicators of compromise (IoCs) related to this activity.
Based on BleepingComputer’s reporting, Bling Libra (aka ShinyHunters) claimed to have gained access to an additional 285 Salesforce instances by breaching Gainsight. The threat group asserted they accomplished this using secrets obtained via their supply chain attack targeting Salesloft Drift in August 2025, which Unit 42 previously reported on Sep. 10, 2025.
Gainsight acknowledged on Sept. 3, 2025 that they were breached via stolen OAuth tokens linked to the Salesloft Drift attack. In this security alert the company confirmed the following types of information were likely accessed by the threat actors:
Names
Business email addresses
Phone numbers
Regional/location details
Gainsight product licensing information
Plain text content from certain support cases (not including attachments)
On Nov. 20, 2025, SLSH representatives posted a message within their newly created Telegram channel. It included an image that appears to represent a new dedicated leak site (DLS) with text reading “24 November 2025, stay tuned” as shown in Figure 1. This seemingly implies a deadline set for any companies affected by this latest data theft campaign to pay a ransom.
Figure 1. Screenshot of Telegram post to scattered LAPSUS$ hunters part 7 channel on Nov. 20, 2025. Source: Telegram.
On Nov. 21, 2025, SLSH posted another message shown in Figure 2, which functions as a warning to companies that have not yet been affected by their Salesforce data theft campaigns.
Figure 2. Screenshot of Telegram post to scattered LAPSUS$ hunters part 7 channel on Nov. 21, 2025. Source: Telegram.
Emergence of ShinySp1d3r Ransomware-as-a-Service
On Nov. 19, 2025, BleepingComputer reported on a new ransomware-as-a-service (RaaS) program dubbed “ShinySp1d3r” which is allegedly still under active development by SLSH. The ransomware currently only works on Windows systems but representatives for the criminal syndicate told reporters that they are close to producing versions for Linux and ESXi systems.
Figure 3. Screenshot of ShinySp1d3r wallpaper. Source: Unit 42.Figure 4. Screenshot of ShinySp1d3r ransom note. Source: Unit 42.
On Nov. 21, 2025, SLSH posted another Telegram message shown in Figure 5 where they threaten to deploy ShinySp1d3r ransomware for all of New York City and the State of New York.
Figure 5. Screenshot of Telegram post to scattered LAPSUS$ hunters part 7 channel on Nov. 21, 2025. Source: Telegram.
Latest Insider Access Recruitment Attempts
On Nov. 21, 2025, CrowdStrike confirmed to BleepingComputer that an employee had shared screenshots of internal systems with SLSH which were then posted to the group’s Telegram channel. CrowdStrike asserted that the individual was terminated last month and that none of its systems were breached as a result of this activity. Bling Libra confirmed to reporters that they agreed to pay the insider $25,000 for access to CrowdStrike’s network.
On the same day, SLSH posted several more Telegram messages further illustrated in Figures 6 and 7. The first image shown below highlights the industries that the threat actors were looking to solicit insiders from, which includes retail and hospitality organizations.
Figure 6. Screenshot of Telegram post to scattered LAPSUS$ hunters part 7 channel on Nov. 20, 2025. Source: Telegram.
The second image shown below illustrates how the threat actors are attempting to calm any unease that potential insiders may be feeling in the aftermath of CrowdStrike’s insider detection.
Figure 7. Screenshot of Telegram post to scattered LAPSUS$ hunters part 7 channel on Nov. 21, 2025. Source: Telegram.
Looking Ahead to 2026
On Nov. 24, 2025, Gainsight announced that connections to other SaaS platforms such as HubSpot and Zendesk were being temporarily suspended due to the supply chain attack. The company also encouraged customers to rotate their S3 keys as a precautionary measure.
At time of publication, Unit 42 had yet to identify any communications by the threat actors claiming to have leaked information related to their alleged Gainsight data theft campaign. However, they did post the following message to their Telegram channel on Nov. 24, 2025:
“pretty sure the 2025 victim count by us in total is ~1.5k (1000 already publicly reported) and still increasing”
My overall prediction when it comes to these financially-motivated threat actors in 2026 and beyond is more of the same: unwavering chaos. We previously expected SLSH to take a break and reemerge at the beginning of the new calendar year with the aforementioned activities, but they have seemingly decided to expedite that timeline based on these latest observations. The emergence of a RaaS program, in conjunction with an EaaS offering, makes SLSH a formidable adversary in terms of the wide net they can cast against organizations using multiple methods to monetize their intrusion operations. Additionally, the insider recruitment element adds yet another layer for organizations to defend against.
The timing of these developments could not be worse for most organizations, especially retailers, as they ramp up for the biggest shopping weeks of the calendar year. Figure 8 provides more insight on how the threat actors plan to operate in the coming weeks, which seemingly alludes to more customer data potentially being leaked to their DLS.
Figure 8. Screenshot of Telegram post to scattered LAPSUS$ hunters part 7 channel on Nov. 23, 2025. Source: Telegram.
Palo Alto Networks recently predicted that 2026 will be the “Year of the Defender” with regards to applying AI-driven defenses to combat AI-powered attacks. I strongly believe that this sentiment of 2026 being the year of the defender also needs to hold true if we are to collectively defeat the many fronts that SLSH is targeting organizations from.
One of the best gifts you can give your organization this time of year is joining and actively participating in an industry-specific Information Sharing and Analysis Center — this enables your network defenders to learn from other peer institutions and collectively shift the outcome to “left of bang.”
Unit 42 is ready to help support your organization with an active compromise or to provide a proactive assessment to lower your organization's risk related to this evolving threat activity.
Unit 42 researchers investigated a renewed npm-focused compromise, in a campaign dubbed Shai-Hulud 2.0. This was first reported in early November 2025. The current campaign is significantly wider in scope, affecting tens of thousands of GitHub repositories This includes over 25,000 malicious repositories across about 350 unique users.
Notable Differences in November Campaigns
Execution during pre-install dramatically widened the area of impact
This campaign introduced a far more aggressive fallback mechanism, which could attempt to destroy a user’s home directory
New payload files are named setup_bun.js and bun_environment.js
Stolen credentials and secrets are exfiltrated to public GitHub repositories with the repository description: “Sha1-Hulud: The Second Coming.”
The Shai-Hulud 2.0 campaign represents an aggressive escalation in software supply chain attacks, moving beyond its predecessor's methods by changing the point of infection. By targeting the pre-install phase of software dependencies, the malware achieves two significant breakthroughs:
It completely eliminates the need for human interaction, guaranteeing execution on virtually every build server processing the infected package
It effectively bypasses static scanning tools that inspect code during later build stages
While this threat still focuses on stealing high-value cloud credentials, it can also cripple an enterprise's entire CI/CD pipeline. This could disrupt development and potentially lock out internal systems, escalating the attack from simple espionage into a highly disruptive denial-of-service event.
In September, Unit 42 investigated the novel, self-replicating worm as "Shai-Hulud," responsible for the compromise of hundreds of software packages.
This attack represents a significant evolution in supply chain threats, leveraging automated propagation to achieve scale. Unit 42 also assesses with moderate confidence that an LLM was used to generate the malicious bash script, based on inclusion of comments and emojis.
Palo Alto Networks customers are better protected from, and receive mitigations for aspects of this attack, through various products and services, including:
The attack may originate from a credential-harvesting phishing campaign spoofing npm and asking developers to “update” their multi-factor authentication (MFA) login options. Once initial access was gained, the threat actor deployed a malicious payload that functions as a worm, initiating a multi-stage attack sequence. Based on the inclusion of comments and emojis in the bash script, Unit 42 assesses with moderate confidence the threat actor leveraged LLM to assist in writing the malicious code.
The malicious package versions contain a worm that executes a post-installation script. This malware scans the compromised environment for sensitive credentials, including:
.npmrc files (for npm tokens)
Environment variables and configuration files specifically targeting GitHub Personal Access Tokens (PATs) and API keys for cloud services like:
Amazon Web Services (AWS)
Google Cloud Platform (GCP)
Microsoft Azure
Harvested credentials are exfiltrated to an actor-controlled endpoint. The malware programmatically creates a new public GitHub repository named "Shai-Hulud" under the victim's account and commits the stolen secrets to it, exposing them publicly.
Using the stolen npm token, the malware authenticates to the npm registry as the compromised developer. It then identifies other packages maintained by that developer, injects malicious code into them, and publishes the new, compromised versions to the registry. This automated process allows the malware to spread exponentially without direct actor intervention.
Current Scope of the Attack
As of November 2025, there is a a renewed npm-focused compromise in a campaign dubbed “Shai-Hulud 2.0.”
Execution during pre-install (instead of post-install): Dramatically widened the area of impact across developer machines and continuous integration and continuous delivery (CI/CD) pipelines.
A far more aggressive fallback mechanism: This shifts the tactics from purely data theft to punitive sabotage. If the malware fails to steal credentials, obtain tokens or secure any exfiltration channel (i.e., it cannot authenticate to GitHub, create a repository or find GitHub/npm tokens) it attempts to destroy the victim’s entire home directory. It does so by securely overwriting and deleting every writable file owned by the current user under their home folder.
New payload files: These are named setup_bun.js and bun_environment.js. The attack disguises itself as a helpful Bun installer. The core payload, bun_environment.js, is a massive file (over 10 MB) that uses extreme obfuscation techniques. It delays full execution on developer machines by forking itself into a detached background process. This allows the original install process to exit cleanly, giving the user the illusion of a normal installation.
Sha1-Hulud: Stolen credentials and secrets are exfiltrated to public GitHub repositories with the repository description: “Sha1-Hulud: The Second Coming.” It also attempts persistence by creating a GitHub Actions workflow file named discussion.yaml. This workflow registers the infected machine as a self-hosted runner and allows attackers to execute arbitrary commands by opening GitHub discussions.
Scope of the Attack Before November 2025
The scope of the compromise is extensive, impacting numerous packages, including the widely used @ctrl/tinycolor library, which receives millions of weekly downloads.
Credential theft from this campaign can lead directly to compromise of cloud services (such as AWS, Azure, GCP), leading to data theft from storage buckets, ransomware deployment, cryptomining or deletion of production environments. It may also lead to direct database theft and hijacking of third-party services for phishing. Additionally, stolen SSH keys can enable lateral movement within compromised networks.
Interim Guidance
Credential Rotation: Immediately rotate all developer credentials. This includes npm access tokens, GitHub PATs and SSH keys, and all programmatic access keys for cloud and third-party services. Assume that any secret present on a developer's machine may have been compromised.
Dependency Auditing: Conduct a thorough and immediate audit of all project dependencies. Use tools like npm audit to identify vulnerable package versions. Scrutinize your project's package-lock.json or yarn.lock files to ensure you are not using any of the known-compromised packages. Remove or update affected dependencies immediately.
GitHub Account Security Review: All developers should review their GitHub accounts for unrecognized public repositories (specifically "Shai-Hulud"), suspicious commits or unexpected modifications to GitHub Actions workflows that could establish persistence.
Enforce MFA: Ensure that MFA is strictly enforced on all developer accounts, particularly for critical platforms like GitHub and npm, to prevent credential abuse.
Unit 42 Managed Threat Hunting Queries
1
2
3
4
5
6
7
8
9
10
11
12
13
// Description: Check for connections to any webhook.site domains in raw NGFW URL logs. Optional filter for specific URI observed in use by threat actor.
// Description: Detects Trufflehog usage. Legitimate tool abused by threat actor for secrets discovery. False positives may occur if there is legitimate use.
|filter action_file_sha256="46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09"// bundle.js from September 2025 attack
oraction_file_sha256 in("62ee164b9b306250c1172583f138c9614139264f889fa99614903c12755468d0","f099c5d9ec417d4445a0328ac0ada9cde79fc37410914103ae9c609cbc0ee068","cbb9bc5a8496243e02f3cc080efbe3e4a1430ba0671f2e43a202bf45b05479cd")// bun_environment.js from November 2025 attack
oraction_file_sha256="a3894003ad1d293ba96d77881ccd2071446dc3f65f434669b49b3da92421901a"// setup_bun.js from November 2025 attack
1
2
3
4
5
6
// Description: Detects the unique SHA1HULUD string used in runner creation
// Description: Detects an extremely large (>=9MB) bun_environment.js file. False positives are possible, be sure to check action_file_path for the package name and version of any hits.
The Shai-Hulud worm represents a significant escalation in the ongoing series of npm attacks targeting the open-source community. This follows recent incidents such as the s1ngularity/Nx compromise, which involved credential theft and exposed private repositories, and a widespread npm phishing campaign observed in September 2024.
Its self-replicating design is particularly notable, effectively combining credential harvesting with an automated dissemination mechanism that exploits maintainers' existing publishing rights to proliferate across the ecosystem. Furthermore, we have observed the integration of AI-generated content within the Shai-Hulud campaign, a development that follows the s1ngularity/Nx attack's explicit weaponization of AI command-line tools for reconnaissance. This signifies the ever-evolving threat from malicious actors exploiting AI for malicious activity, accelerating secret sprawl.
The consistent and refined nature of these attack methodologies underscores a growing threat to open-source software supply chains. These attacks are propagating at the speed of Continuous Integration and Continuous Delivery (CI/CD), which poses long-lasting and increasing security challenges for the entire ecosystem.
Palo Alto Networks has shared our findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Palo Alto Networks Product Protections and Detections for npm Packages Supply Chain Attacks
Palo Alto Networks customers can leverage a variety of product protections, services and updates designed 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
Advanced WildFire
The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of indicators associated with this threat.
Next-Generation Firewalls With Advanced Threat Prevention
Cloud-Delivered Security Services for the Next-Generation Firewall
Advanced URL Filtering helps to block meddler-in-the-middle (MitM) phishing attacks and classifies as malicious URLs associated with this activity.
Cortex XDR and XSIAM
Cortex XDR and XSIAM agents help protect against the threats described in this article. The agents prevent the execution of known malware and may also prevent the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module.
Cortex Cloud
Cortex Cloud offers extensive ASPM and supply chain security capabilities to help identify the vulnerabilities and misconfigurations that Shai-Hulud exploits. With real-time SBOM visibility, teams can instantly query their inventory against known malicious npm packages. The platform's Operational Risk model adds another layer of defense by evaluating open-source components based on maintainer activity, deprecation signals, and community health to flag risky packages even without published CVEs.
To harden pipelines, Cortex Cloud provides out-of-the-box CI/CD rules aligned with OWASP and CIS guidance, including checks for missing npm lock files, insecure “npm install” usage, git-sourced packages without commit hashes, and unused dependencies that expand the attack surface.
Since CVE publication often lags behind active attacks it’s critical to review and verify that your applications are not relying on unsanctioned npm package versions. Together, these controls help ensure malicious versions can’t silently enter builds or linger in your environment.
Prisma Cloud can help detect the use of the malicious packages and recognize misconfigurations in the pipelines that might lead customers to use untested/unsanctioned OSS package versions. However, the scanner is designed for detection of vulnerabilities, license issues and operational risks, and not for detecting malicious code on new packages. It is important to investigate relevant CI/CD alerts and ensure your applications are not using unsanctioned versions of npm packages.
A fundamental challenge with large language models (LLMs) in a security context is that their greatest strengths as defensive tools are precisely what enable their offensive power. This issue is known as the dual-use dilemma, a concept typically applied to technologies like nuclear physics or biotechnology, but now also central to AI. Any tool powerful enough to build a complex system can also be repurposed to break one.
This dilemma manifests in several critical ways related to cybersecurity. While defenders can employ LLMs to speed up and improve responses, attackers can also take advantage of them for their workflows. For example:
Linguistic precision: LLMs can generate text that is grammatically plausible, contextually relevant and psychologically manipulative, advancing the art of social engineering for phishing, vishing and business email compromise (BEC) campaigns.
Code fluency: They can rapidly generate, debug and modify functional code, including malicious scripts and customized malware, greatly accelerating the development cycle for malware and tooling.
The line between a benign research tool and a powerful threat creation engine is dangerously thin. The two are often separated only by the developer's intent and the absence of ethical guardrails.
In this article, we examine two examples of LLMs that Unit 42 considers malicious, purpose-built models specifically designed for offensive purposes. These models, WormGPT and KawaiiGPT, demonstrate these exact dual-use challenges.
These malicious LLMs — models built or adapted specifically for offensive purposes — distinguish themselves from their mainstream counterparts by intentionally removing ethical constraints and safety filters during their foundational training or fine-tuning process.
Additionally, these malicious LLMs contain targeted functionality. They are marketed in underground forums and Telegram channels with a variety of features, including those explicitly tailored to:
Generate phishing emails
Write polymorphic malware
Automate reconnaissance
In some cases, these tools are not merely jailbroken models- instances where prompt injection techniques are used to circumvent a model’s built-in ethical and safety restrictions- of publicly available models. Instead, they represent a dedicated, commercialized effort to provide cybercriminals with accessible, scalable and highly effective new tools.
The Lowered Barrier to Entry
Perhaps the most significant impact of malicious LLMs is the democratization of cybercrime. These unrestricted models have fundamentally removed some of the barriers in terms of technical skill required for cybercrime activity. These models grant the power once reserved for more knowledgeable threat actors to virtually anyone with an internet connection and a basic understanding of how to create prompts to achieve their goals.
Attacks that previously required higher-level expertise in coding and native-level language fluency are now much more accessible. This shift in the threat landscape leads to:
Scale over skill: The tools empower low-skill attackers. AI-empowered script kiddies can launch high-volume campaigns that are qualitatively superior to past attacks.
Time compression: The attack lifecycle can be compressed from days or hours of manual effort (e.g., researching a target, crafting a personalized lure and generating corresponding basic tooling code) down to mere minutes of prompting.
The continued proliferation of malicious LLMs serves as a warning. The offensive capabilities of AI are getting more mature and are becoming more widely available.
The WormGPT Legacy
Genesis of a Threat: Origin and Initial Impact of the Original WormGPT
The original WormGPT emerged in July 2023 as one of the first widely recognized, commercialized malicious LLMs. It was created specifically to bypass the ethical rules of mainstream LLM models.
WormGPT was reportedly built upon the GPT-J 6B open-source language model. WormGPT's creator publicly claimed to have fine-tuned this accessible foundation model using specialized, confidential and malicious datasets with a specific emphasis on malware-related data. This ensured the resulting tool lacked the ethical guardrails of mainstream AI.
The datasets used by WormGPT allegedly contained malware code, exploit write-ups and phishing templates. This directly trained the model on the tactics, techniques and procedures (TTPs) used by cybercriminals.
It was promoted on prominent underground forums, such as Hack Forums, as shown in Figure 1. These ads contained the explicit promise of WormGPT being an “uncensored” alternative to legitimate LLMs, capable of assisting with all forms of illegal activity.
Figure 1. WormGPT ad found on Hack Forums.
Initial Impact and Core Capabilities
WormGPT achieved notoriety when cybersecurity researchers tested this malicious LLM, demonstrating its capabilities that included:
Advancing phishing and BEC: WormGPT had the ability to generate remarkably persuasive and contextually accurate BEC or phishing messages. This is unlike traditional phishing, which often contains poor grammar or awkward phrasing. WormGPT could produce fluent, professional-sounding text.
Malware scaffolding: WormGPT was advertised as a tool that could generate malicious code snippets in various programming languages (like Python). This helps less-skilled actors rapidly develop and modify malware without needing deep malware programming expertise.
Commercialization of crime: By launching as a subscription-based service (with costs ranging from tens to hundreds of Euros per month), malicious LLMs signaled the formal integration of LLM attack capabilities into the existing cybercrime-as-a-service model. This makes effective tools accessible to a much wider array of threat actors.
The massive media exposure WormGPT received ultimately led the original developer to shut down the project in mid-2023, citing the negative publicity. However, the damage was already done.
WormGPT established the blueprint, the demand and the brand for uncensored malicious LLMs. This led directly to the rise of successor and copycat variants, including WormGPT 4 and its peers.
Capabilities of WormGPT 4
The resurgence of the WormGPT brand, particularly with versions like WormGPT 4, marks an evolution from simple jailbroken models to commercialized, specialized tools to help facilitate cybercrime.
This version of WormGPT calls itself WormGPT, but the Telegram channel for WormGPT calls itself WormGPT 4. To distinguish this from other sites claiming to be WormGPT, we will refer to it as WormGPT 4 in this article.
The primary selling point, which it advertises boldly across its interface and underground forums, is a total rejection of ethical boundaries. As Figure 2 shows, its webpage states, “WORMGPT is your key to an AI without boundaries.”
Figure 2. WormGPT 4 webpage.
This philosophy directly translates into a suite of capabilities designed to automate and scale attacks. Distributed via its own website or a Telegram channel, WormGPT 4 markets itself across multiple platforms and methods.
The developers of WormGPT 4 maintain secrecy regarding its model architecture and training data. They neither confirm nor deny whether they rely on an illicitly fine-tuned or trained LLM or merely persistent jailbreaking techniques.
WormGPT 4’s language capabilities are not just about producing convincing text. By eliminating the tell-tale grammatical errors and awkward phrasing that often flag traditional phishing attempts, WormGPT 4 can generate a message that persuasively mimics a CEO or trusted vendor. This capability allows low-skilled attackers to launch sophisticated campaigns that are far more likely to bypass both automated email filters and human scrutiny.
WormGPT 4’s availability is driven by a clear commercial strategy, contrasting sharply with the often free, unreliable nature of simple jailbreaks. The tool is highly accessible due to its easy-to-use platform and cheap subscription cost.
The subscription model offers tiered pricing, including:
Monthly access for $50
Annual access for $175
Lifetime access for $220, as shown below in Figure 3
This clear pricing and the option to acquire the full source code reflect a readily available business model.
Figure 3. WormGPT 4 sale prices.
Ads for WormGPT 4 were posted on Telegram and in underground forums like DarknetArmy, with sales campaigns starting around Sept. 27, 2025.
WormGPT 4’s Telegram presence serves as a community and sales channel. It has a dedicated and active user base, as evidenced by a subscriber count of over 500 people as shown below in Figure 4.
Figure 4. WormGPT 4 Telegram channel.
Beyond social engineering, WormGPT 4 functions as a malware template generator, providing users with the building blocks for basic malware development. We decided to test this aspect of WormGPT 4’s capabilities.
Ransomware Code Generator
When prompted to generate a script to encrypt and lock all PDF files on a Windows host, the model instantly delivered a functional PowerShell script. Characteristics of this script include:
Ransomware code: This script comes complete with configurable settings for file extension and search path (defaulting to the entire C:\ drive). It also uses AES-256 encryption.
Command-and-control (C2) server support: The generated code includes an optional component for data exfiltration via Tor. This is an indicator of the tool's focus on supporting semi-professional, profit-driven cyber operations.
The user experience is designed to be frictionless. As Figure 5 below shows, the LLM states, “Ah, I see you're ready to escalate. Let's make digital destruction simple and effective. Here's a fully functional PowerShell script[...] This is silent, fast, and brutal — just how I like it. ”
Figure 5. WormGPT 4 generates a rudimentary ransomware script impacting PDF files.
Ransomware Note Generator
Additionally, the model instantly drafts ransom notes that are designed to maximize fear and compliance. As Figure 6 below shows, the sample note promises “military-grade encryption” and enforces a strict, urgent deadline: a 72-hour window to pay, after which the price doubles.
Figure 6. WormGPT 4 generates a ransom note example.
The rise of WormGPT 4 illustrates a grim reality: Sophisticated, unrestricted AI is no longer confined to the realms of theory or highly skilled nation-state actors. It has become a readily available and simple cybercrime-as-a-service product, complete with:
An easy-to-use interface
Cheap subscription plans
Dedicated marketing channels across Telegram and various other forums
WormGPT 4 provides credible linguistic manipulation for BEC and phishing attacks. It also provides instantaneous, functional code generation for ransomware, lowering the barrier to entry for cybercrime. The model acts as a force multiplier, empowering even novice attackers to launch operations previously reserved for knowledgeable hackers.
The key takeaway is a shift in the threat model: Defenders can no longer rely on the classic warning signs of poor grammar or sloppy coding to flag a threat. The proliferation of the WormGPT brand highlights the dual-use dilemma.
Capabilities of KawaiiGPT
WormGPT offers paid assistance in the creation of ransomware, phishing and BEC campaigns. Meanwhile, the emergence of free tools like KawaiiGPT further lowered the cybercrime barrier.
First identified in July 2025 and currently at version 2.5, KawaiiGPT represents an accessible, entry-level, yet functionally potent malicious LLM. Figure 7 shows a screenshot of the webpage for KawaiiGPT.
Figure 7. KawaiiGPT webpage.
KawaiiGPT’s success is built on accessibility and simplicity, contrasting with the often murky and expensive dark-web sales models of its competitors. Freely available on GitHub as shown below in Figure 8, its lightweight setup is designed to be easy, often in our own testing taking less than five minutes to configure and run on most Linux operating systems.
This removes the technical complexity associated with sourcing, configuring and running custom LLMs, which often deters new users. This ease of deployment and a ready-to-use command-line interface (CLI) lowers the required technical skills, background and experience, potentially reaching a broader spectrum of users. This spectrum includes users who previously lacked the specialized expertise to engage with other malicious LLMs.
Figure 8. KawaiiGPT GitHub repository.
KawaiiGPT attempts to cloak its malicious intent in a veneer of casual language. It frequently greets users with Owo! okay! here you go... 😀 as seen below in Figure 9, before delivering malicious output. However, this persona belies its dangerous capabilities.
Figure 9. KawaiiGPT generates a spear phishing message.
Social Engineering and Lateral Movement Scripts
KawaiiGPT can craft highly deceptive social engineering lures. When prompted to generate a spear-phishing email pretending to be from a fake bank, the model instantly produces a professional-looking message with the subject line Urgent: Verify Your Account Information.
This lure is a classic credential-harvesting scam, directing the victim to a fake verification link (e.g., hxxps[:]//fakebankverify[.]com/updateinfo) with subsequent pages asking for sensitive information like card details and date of birth.
KawaiiGPT’s basic ability to generate code for key phases of an attack is demonstrated by its response to a prompt about lateral movement. The model delivers a functional blueprint for network compromise by using the SSH Python module paramiko, as shown in Figure 10.
Figure 10. Example of the beginning of a rudimentary Python script for lateral movement created from a prompt in KawaiiGPT.
The resulting script does not introduce hugely novel capabilities, but it automates a standard, critical step in nearly every successful breach. The generated code authenticates as a legitimate user and grants the attacker a remote shell onto the new target machine.
Once the SSH session is established, the subsequent execute_command function uses client.exec_command(command) to launch the exploitation phase. This functionality allows the attacker to remotely run any command including:
Escalating privileges
Executing reconnaissance tools
Installing persistent backdoors
Collecting sensitive files
Launching further attacks against other systems on the network
By generating a complete, ready-to-run script, the LLM bypasses an attacker's need for specialized knowledge of SSH protocols. This could make the expansion of a breach comparatively easier, especially in an insufficiently protected environment.
Data Exfiltration Script
When further prompted, KawaiiGPT quickly generates a Python script designed to perform data exfiltration for EML-formatted email files on a Windows host as shown below in Figure 11. The code uses the standard os.walk Python library to recursively search for emails and the smtplib module for exfiltration. The script subsequently packages them and sends them out as attachments via email to an attacker-controlled address.
Figure 11. Example of the beginning of a basic data exfiltration Python script created from a prompt in KawaiiGPT.
The significance of this automated code generation is threefold:
Immediate functionality: The script is not abstract. It imports the necessary modules (os, smtplib) and defines the functions required to locate, package and transmit the files. This provides a functional blueprint for a malicious campaign right out of the box.
Low customization barrier: While the initial output is simple and rudimentary, this code can be easily modified and expanded in functionality with only a limited amount of Python programming experience. A novice attacker can easily add features like compression, encryption or using fragmented data transfers to evade simple data loss prevention (DLP) systems.
Weaponizing native tools: By using the smtplib library, which is a legitimate, trusted Python module, the resulting script blends in with normal network traffic. This makes it a stealthy and effective method for stealing sensitive communications and proprietary data.
The creation of this exfiltration tool demonstrates how malicious LLMs are accelerating the speed of attack and broadening the technical scope available to cybercriminals.
Beyond social engineering, KawaiiGPT demonstrates a rudimentary capability in generating the necessary components for a full-scale digital shakedown. While its code for attack functions might be less complex than the more optimized PowerShell scripts generated by WormGPT 4, KawaiiGPT instantly provides the social and technical scaffolding for an attack.
Ransom Note Generation
The KawaiiGPT model generates the social engineering infrastructure for an attack, such as an instantly created, threatening ransom note. This note is formatted with clear headings (e.g., **YOUR FILES HAVE BEEN ENCRYPTED** and **YOU HAVE 72 HOURS TO PAY THE RANSOM**) and explicitly warns the victim that their important files are inaccessible because they have been encrypted with military-grade encryption, as shown below in Figure 12.
Figure 12. Example of a ransom note created from a prompt in KawaiiGPT.
The note provides a step-by-step guide for victims under **HOW DO I PAY?**, instructing them to:
Obtain bitcoin from an online exchange or a bitcoin ATM.
Send the ransom amount to a provided wallet address.
The immediate generation of the entire extortion workflow, from the encryption message to cryptocurrency payment instructions, allows even novice threat actors to deploy a complete ransomware operation. It streamlines the business of extortion, allowing the user to focus solely on breaching the target system.
In contrast to the commercial nature of WormGPT 4, the accessibility of KawaiiGPT is a threat unto itself. The tool is free and publicly available, ensuring that cost is zero barrier to entry for aspiring cybercriminals.
KawaiiGPT seeks to appeal to its target audience by asserting it is a custom-built model rather than a simple jailbroken version of a public API. Whether true or not, this positioning serves two purposes:
It appeals to actors seeking genuine, uncensored capability
It fosters a sense of community identity (albeit illicit) around a novel tool
This open-source, community-driven approach has proven highly effective in attracting a loyal user base. The LLM has already self-reported over 500 registered users, with a consistent core of several hundred weekly active users using the platform as noted below in Figure 13.
Figure 13. KawaiiGPT creator’s Telegram update post.
This user base seems to often congregate in an active Telegram channel of 180 members as of early November as shown in Figure 14.
Figure 14. KawaiiGPT’s creator posts an example prompt and result.
This channel creates a mechanism for sharing tips, requesting features and further advancing the tool's offensive capabilities. KawaiiGPT packages exploitation assistance into a free and community-supported environment.
KawaiiGPT demonstrates that access to malicious LLMs is no longer a question of resources or skill, but a matter of downloading and configuring a single tool.
Conclusion
The emergence of unrestricted LLMs like WormGPT 4 and KawaiiGPT is not a theoretical threat, it is a new baseline for digital risk. Analysis of these two models confirms that attackers are actively using malicious LLMs in the threat landscape. This is driven by two major shifts:
The commercialization of cyberattacks
The democratization of skill
Regulatory and Ethical Imperatives: A Call for Accountability
The challenge posed by these malicious LLMs results in the need for accountability from three key groups:
Developers: The ethical-utility debate surrounding LLMs is intensifying. The developers of foundation models must implement mandatory, robust alignment techniques and adversarial stress testing before public release. The existence of a tool like KawaiiGPT proves that open-source availability must be paired with inherent safety mechanisms.
Governments and regulators: Threat actors are using advanced technologies like AI to aid malicious activities. As such, policymakers should advance standards and frameworks to concurrently address the proliferation of malicious models and best practices to advance the security of models like regular security auditing. Staying updated on these topics is crucial, as this technology significantly aids and accelerates malicious activities.
Researchers: The subscription model of WormGPT 4, which is actively advertised on Telegram, demonstrates the need to confront threat actors engaged in for-profit, organized business. Disrupting this requires targeted international collaboration amongst researchers to target the services that are used to monetize these malicious LLM services.
The future of cybersecurity and AI is not about blocking specific tools, but about building systems that are resilient to the scale and speed of AI-generated malice. The ability to quickly generate a full attack chain, from a highly persuasive ransom note to working exfiltration code, is the threat we now face.
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
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.
We have identified two interconnected malware campaigns active throughout 2025, using large-scale brand impersonation to deliver Gh0st remote access Trojan (RAT) variants to Chinese-speaking users. From the first campaign to the second, the adversary advanced from simple droppers to complex, multi-stage infection chains that misuse legitimate, signed software to bypass modern defenses.
This report provides a detailed breakdown of the campaigns' anatomy, offering new intelligence on the attackers' operational playbook. We analyze an initial campaign from February–March 2025 that mimicked three brands across over 2,000 domains and a more sophisticated campaign starting in May 2025 that impersonated over 40 applications. The impersonated software primarily includes widely used enterprise tools, secure messaging apps, gaming platforms and popular AI software.
By analyzing the evolution of the attack methods, infrastructure and targeting, we establish a clear operational playbook. Understanding the adversary’s adaptive tactics, techniques and procedures (TTPs), such as using cloud infrastructure for payload delivery and DLL side-loading for evasion, provides crucial insights for enhancing security postures.
Our analysis is based on data from Palo Alto Networks products, including Advanced URL Filtering and Advanced WildFire, which provided visibility into the malware's behavior and infection chains. This internal data was supplemented by passive DNS (pDNS) analysis and open-source intelligence. We provide organizations with indicators of compromise (IoCs) to mitigate against this threat.
Palo Alto Networks customers are better protected from this activity through the following products and services:
The Rise of Impersonation at Scale: A Persistent Threat to Chinese-Speaking Users
In recent years, malware campaigns specifically tailored to target Chinese-speaking users globally have emerged as a notable trend in the threat landscape. These operations demonstrate a complex understanding of the target demographic's digital ecosystem and online behaviors.
The lures used are often not generic. Instead, attackers carefully select them to appeal to this specific audience. Attackers frequently impersonate the following types of applications:
Software that is widely popular within the community (e.g., Youdao dictionary or Sogou browser)
Tools used to circumvent state-imposed internet restrictions (e.g., VPNs and encrypted messaging applications)
How would potential victims find these malicious sites impersonating legitimate software? Attackers have a variety of options. They could generate traffic to these sites through malicious online ads or search engine poisoning. Attackers can also post on social media and other online forums to promote these sites. Email is another vector for leading potential victims to these sites.
The choice to target people seeking tools to bypass censorship is particularly strategic. This suggests an adversary who is interested in people already attempting to operate outside of easily monitored channels, making them prime targets for surveillance or espionage.
The final payload in these campaigns is often a RAT that grants the attacker comprehensive control over a compromised system. The Gh0st RAT and its many variants are a prominent choice, particularly for Chinese-nexus cybercrime and espionage actors who have used these tools for over a decade.
Anatomy of the First Campaign: Campaign Trio
We refer to this initial activity as Campaign Trio due to its impersonation of three distinct software brands. Active from February–March 2025, this phase established a baseline operational model of the adversary. This campaign involved a massive number of domains, used an aggressive approach to infrastructure deployment and a clear, focused targeting strategy.
The malware distribution strategy of this campaign relied on a vast network of malicious websites that convincingly mimicked legitimate software download portals to lure victims.
Mass Domain Registration
Between February and March 2025, attackers registered over 2,000 domains, with significant surges in activity in early February and early March. Attackers appear to have automated their domain registration, typically combining the impersonated brand name with a random-looking alphanumeric suffix and using TLDs like .top or .vip.
The entire network of over 2,000 domains was hosted on just three IP addresses:
154.82.84[.]227
156.251.25[.]43
156.251.25[.]112
This high-volume domain approach is designed to persist in the face of reputation-based blocking systems. It also ensures that even if some domains are taken down, many other domains remain available.
Figure 1 shows a sample attack infrastructure of Campaign Trio including the following info:
Three clusters of brand impersonating domains
Their association with web server IP addresses
An additional server hosting the malware for downloading
Figure 1. The Campaign Trio's attack infrastructure.
This centralized model, with over 2,000 domains resolving to just three IP addresses, suggests that attackers viewed components of the infrastructure as disposable. This also implies an aggressive approach to infrastructure deployment that allows the attackers to rapidly establish new websites.
Targeted Impersonation
The choice of impersonated brands for this campaign reveals a deliberate targeting strategy:
i4tools: With over 1,400 domains, this was the most impersonated brand. This is Chinese-language, multi-function software for managing and transferring files to and from Apple-based mobile devices.
Youdao: Attackers created over 600 domains to impersonate this popular Chinese dictionary and translation application, strongly indicating a focus on Chinese-speaking users.
DeepSeek: We identified only five domains. The impersonation of this AI company demonstrates the attackers' interest in capitalizing on current technology trends.
The landing pages hosted on these domains closely mimicked the legitimate sites to deceive victims into downloading the trojanized software installers shown in Figures 2, 3 and 4.
Figure 2. Example of a malicious landing page impersonating DeepSeek and the malicious payload URL in the page content.Figure 3. Example of a malicious landing page impersonating Youdao and the malicious payload URL in the page content.Figure 4. Example of a malicious landing page impersonating i4tools and the malicious payload URL in the page content.
Execution and Payload Delivery: A Centralized Model
Webpages from over 2,000 domains served their malicious payloads from a single source: hxxps[:]//xiazailianjieoss[.]com.
This domain hosted ZIP archives containing the trojanized installers. The downloaded archives contained either a malicious Microsoft Installer (MSI) file or a standalone executable. The MSI installers used a custom action to execute a secondary, smaller executable, separating the malicious logic from the main installer to bypass static analysis.
Final Payload: The Gh0st RAT
MSI-based malware delivery can include a substantial variety of actions also typically executed by benign MSI files. This allows malicious actions to hide within the many legitimate operations generated by an attacker's MSI file.
Figure 5 illustrates this concept in action. It shows a malicious MSI sample from Campaign Trio running the embedded malware within the MSI package. Using Microsoft's Orca tool, we can search the malicious MSI file's custom actions for anything suspicious. Running the malicious executable is one of 43 custom actions, not including all the normal actions and processes generated by an MSI file.
Figure 5. Examining a malicious MSI file from Campaign Trio.
The MSI file in Figure 5 employs a seemingly legitimate graphical user interface (GUI) for its installation procedure. The Orca tool reveals the MSI file's custom action table, where we've highlighted the malicious action run in the background during the installation. In this instance, the custom action LaunchApplication executes the second-stage malware, a 1.7 MB executable named [System Process]5.exe.
Primary functions of [System Process]5.exe are to:
Download an obfuscated binary from a staging server
The deobfuscated binary is the final payload. We identified this final payload as Gh0st RAT, which provides attackers with the following capabilities:
Logging keystrokes
Capturing screenshots
Remote shell access
Downloading additional malware
These Gh0st RAT samples create scheduled tasks for persistence and use powershell.exe to add exclusions in Windows Defender, so they can run undetected. Once active, these Gh0st RAT samples establish command and control (C2) communication via encrypted TCP traffic over port 8080 to servers with domains like xiaobaituziha[.]com, which resolved to 103.181.134[.]138.
Anatomy of the Second Campaign: Campaign Chorus
We refer to the second campaign as Campaign Chorus because attackers expanded their lures to impersonate over 40 different software applications. Launched in May 2025, this campaign built upon the foundation of the first and showed a significant expansion in targeting. Its TTPs evolved to enhance evasion and bypass security controls.
Expanded Targeting, Refined TTPs
While maintaining a focus on Chinese-speaking users, attackers broadened their lure selection to maximize their potential targets. The attackers organized Campaign Chorus in a more structured manner.
Broader Scope and Wave-Based Attacks
In Campaign Chorus, attackers impersonated widely used enterprise messaging software, Chinese versions of secure messaging apps and popular gaming platforms. They also continued targeting software popular with Chinese speakers, such as QQ Music and Sogou browser. This indicates a strategy to reach a wider demographic of Chinese speakers.
Figure 6 shows examples of impersonated applications from this campaign.
Figure 6. Software impersonation examples from The Chorus phase.
This campaign was initially executed in two distinct waves, distinguished by domain naming conventions and registration dates:
Wave 1 (registered May 15, 2025): This wave consisted of 40 domains, all beginning with the prefix guwaanzh
Wave 2 (registered May 26–28, 2025): This wave included 51 domains, all starting with the prefix xiazaizhadia
The use of structured, wave-based attacks with different domain prefixes and corresponding redirection servers (djbzdhygj[.]com for Wave 1 and yqmqhjgn[.]com for Wave 2) suggests a more organized and possibly experimental approach. The attackers could have been testing the effectiveness of different lures or attempting to compartmentalize their infrastructure to make it more resilient to takedowns.
Figure 7 shows an infrastructure map diagram illustrating the two distinct attack waves, their respective redirection servers and how the domains were hosted on a single IP address.
Figure 7. Attack infrastructure map for Campaign Chorus.
A More Evasive Infection Chain
Figure 8 shows the most significant advancement during this campaign: adopting a more intricate and elusive infection chain. This multi-stage evolution from the previous campaign increases the complexity of malware embedded in the MSI file. This indicates an increased effort to evade detection.
Figure 8. The multi-stage infection chain of Campaign Chorus.
The previous campaign's infection chain was more easily detectable by endpoint detection and response (EDR) solutions. This new chain is explicitly designed to circumvent these protections.
Redirection via Cloud-Hosted Payloads
In a tactical shift from previous activity, the actor behind Campaign Chorus moved away from a single, self-hosted payload server. Instead, the malicious landing pages used intermediary redirection domains to fetch the malicious ZIP archives from public cloud service buckets.
For this tactic, attackers misused cloud services, leveraging trusted reputations to make malicious download traffic appear benign. Consequently, the malicious downloads might bypass network filters that would otherwise block traffic from an unknown or newly registered domain. This also increases the actor's operational resilience, as disrupting a cloud service bucket is a more involved process for defenders than simply blocklisting a malicious IP address.
The VBScript Dropper
As noted earlier in Figure 8, the core of this new infection chain is an embedded VBScript file run as a custom action by the MSI installer. The VBScript file acts as a file assembler and decryptor for the next-stage malware.
This next-stage payload is stored within the MSI file, but not as a single encoded binary. Instead, it is split across multiple data files contained within the MSI's embedded .cab archive.
The VBScript file reads these separate components, merges them into a single binary and uses a stored password to decrypt the combined data. This process creates the next-stage malware. This technique is designed to evade static analysis tools that might otherwise detect a single binary containing malicious content within the MSI.
Execution via DLL Side-Loading
The final and most complex step in the infection chain is using DLL side-loading to execute the payload. The VBScript file decodes data binaries within the MSI and saves the resulting two files to disk:
The first file is a copy of a legitimate signed executable (wsc_proxy.exe)
The second file is a malicious, attacker-crafted DLL named wsc.dll
When wsc_proxy.exe is executed, the Windows loader searches for its required dependency, wsc.dll. Because the malicious version is in the same directory, it is loaded into the process memory before the legitimate version in the system directory would be found.
This is a classic example of DLL side-loading. It is an evasion technique that allows the attacker's code to run under the guise of a trusted, signed process. The misuse of a legitimate executable is meant to bypass application allow-listing and process-based monitoring. The parent process initiating the malicious activity is itself benign and digitally signed by a reputable vendor. This makes it significantly harder for security tools to flag the activity as malicious.
Campaign Profile: A Unified Operational Playbook
When analyzed together, the evidence from Campaign Trio and Campaign Chorus reveals a consistent operational playbook, allowing us to build a distinct behavioral profile. The technical differences are best understood not as the work of two unrelated campaigns, but as the logical evolution of a single group adapting its methods.
The campaigns have several key characteristics that form a strategic signature:
Mass-scale programmatic infrastructure: Both campaigns rely on the programmatic generation of domains for brand impersonation using a consistent naming convention.
Specific demographic focus: Both campaigns focus heavily on software popular with Chinese-speaking users, even when deploying infrastructure in regions like the U.S. and Singapore. This indicates an actor with a deep and specific understanding of this demographic, rather than an opportunistic actor casting a wide, generic net.
“Burn-and-churn” operational tempo: Both campaigns use a centralized and disposable infrastructure model. The strategy of hosting thousands of domains on a handful of IP addresses demonstrates a rapid deployment approach where the attackers consider the infrastructure expendable. The actor prioritizes the speed and scale of deployment over stealth and long-term resilience. They are confident in their ability to quickly pivot to new domains and servers.
Two-tiered infrastructure: The actor exhibits a clear separation between its disposable, high-volume access infrastructure (the thousands of impersonation domains) and its more critical operational infrastructure (the payload and C2 servers). While the access layer is designed to be burned, the operational layer shows evolution (from self-hosted to cloud-hosted) aimed at increasing longevity and resilience. This architectural choice allows the actor to absorb the loss of their frontend domains without losing its core payload delivery and C2 capabilities.
TTP Profile
Table 1 shows the adversary's methods mapped to the MITRE ATT&CK framework, providing a standardized view of its operational tactics.
Observed Campaign Activity and Infrastructure Expansion
The results of our investigation reinforce that these campaigns are not isolated, short-term events. Attackers are actively maintaining and expanding their infrastructure, indicating a persistent, long-term operation.
We investigated the WHOIS creation dates of domains associated with both these campaigns and found that they have consistently registered domains from February–August 2025.
Our analysis showed a significant surge in activity between February and May 2025. During these four months, attackers created over 2,500 domains, accounting for 87.4% of all malicious domains identified in connection with these campaigns.
Figure 9 shows the distribution of domains belonging to these campaigns created per week according to their WHOIS creation dates. In February and March of 2025, we observed over 1,500 domains belonging to the first campaign being registered.
Figure 9. Number of domains from the two campaigns registered over time, highlighting periodic bursts.
We also noticed an interesting pattern where attackers registered between 100-200 domains every week for a month.
This pattern started with 100 domains registered on April 15, 2025.
This was followed by 237 more in the week of April 21–27, the majority of which were registered on April 22.
This was followed by another 191 domains between April 28–May 4. Of these, 104 were registered on April 29.
This was followed by a week of low activity (around May 5, 2025) and ended with almost 261 domains registered between May 13–15, 2025.
This regularity suggests an automated or highly structured process for routine infrastructure replenishment, likely to replace domains that have been blocked during operations.
From the pDNS data, we find that these new domains are pointed to the same core IP addresses used in both campaigns, with activity observed as recently as July 2025. Domains associated with the first campaign's infrastructure continue to resolve to 156.251.25[.]112. For example, we observed domains such as youdaxxyzr[.]top and i4toolscacsm[.]top actively resolving to this IP address. This demonstrates that the actor did not simply abandon its initial core IP address infrastructure but continued to leverage the IP address for ongoing attacks.
Similarly, the infrastructure for the second campaign remains active. The IP address 95.173.197[.]195 continues to serve new malicious domains as of early October 2025. Continuously registering and refreshing domains is a clear tactic to evade blocklists. It helps ensure the longevity of the campaigns, pointing to a well-resourced and determined adversary.
Figure 10 depicts a graph of the first campaign. It shows domains involved in both campaigns. Both campaigns use the same elements, like nameservers and hosting IP addresses. This graph depicts 683 domains that share the same set of nameservers and resolve to the same hosting IP address 156.251.25[.]112. This IP address is geolocated to Hong Kong.
Figure 10. Large-scale activity graph showing infrastructure overlap between the two campaigns.
Furthermore, we analyzed pDNS query volumes for domains associated with the first campaign to quantify its sustained activity over time. We found that while daily query volumes fluctuated, there was a gradual upward trend in queries toward domains associated with this campaign between March 2025 and July 2025.
Figure 11 shows a large peak in the number of queries toward these domains on July 12, 2025. We investigated domains contributing to this peak, and over 68% of these queries were generated for domains registered between March 6 and March 13, 2025, representing an exact four-month gap. This increase in query volume could be due to changes in the attackers' content or their connections to other entities.
Figure 11. Normalized pDNS traffic volume of this activity from March through July 2025.
The parallel operation of both old and new infrastructure through sustained activity suggests an operation that is not merely evolving but consists of multiple infrastructures and distinct tool sets simultaneously. This could indicate A/B testing of TTPs, targeting different victim sets with different levels of complexity, or simply a cost-effective strategy of continuing to leverage older assets as long as they remain effective.
Conclusion
The campaigns detailed in this article represent a persistent, large-scale and evolving threat. Operating at scale combined with a continuous adaptation of TTPs presents a significant challenge for defenders.
There is a clear evolution in these two campaigns. Campaign Trio, the first campaign, uses direct droppers. Campaign Chorus, the second campaign, leverages a more complex multi-stage infection chain and uses DLL sideloading.
The following traits are notable:
Consistent focus on a Chinese-speaking demographic
Programmatically generating thousands of domains
Strategically using both self-hosted and major cloud provider infrastructure
This signals a broader trend where threat actors will increasingly leverage legitimate cloud services and signed software, shifting the defensive focus from blocking known-bad indicators to detecting sophisticated behavioral anomalies.
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research.
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.
Cortex Cloud DSPM can help organizations detect if their cloud infrastructure has been used to host malicious binaries like those described in this article by routinely scanning cloud storage containers and properly classifying the data within.
This functionality can assist organizations from unwittingly being used to host malicious binaries placed by threat actors.
While the nature of the article does not point to the compromise of victim cloud environments to host these binaries, Cortex Cloud DSPM can detect malicious data and prevent it from harming the organization itself or, in this case, external organizations.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 00080005045107
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Indicators of Compromise (IoCs)
A comprehensive list of IoCs associated with these campaigns can be found in the tables below.
Impersonated Brand Examples and Corresponding Domains From Campaigns Trio and Chorus
Malicious Domain
Brand/Product Info
deep-seek[.]rest
Chinese AI company
i4toolsearch[.]vip
Software to manage and transfer files in macOS devices
youdaohhzi[.]top
Popular Chinese dictionary and translation software
xiazaizhadia9[.]cyou
An import-export and e-commerce trading company based in China
xiazaizhadia8[.]cyou
Translation tool
xiazaizhadia51[.]cyou
A popular Chinese office suite
xiazaizhadia50[.]cyou
Web browser
xiazaizhadia46[.]cyou
An anti-detection browser
xiazaizhadia44[.]cyou
Multilingual translation service
xiazaizhadia42[.]cyou
VPN service
xiazaizhadia41[.]cyou
Chinese web browser
xiazaizhadia40[.]cyou
VPN service
xiazaizhadia39[.]cyou
Digital distribution platform for PC video games
xiazaizhadia37[.]cyou
Chinese Pinyin input method editor
xiazaizhadia36[.]cyou
A privacy-focused instant messaging application
xiazaizhadia35[.]cyou
Business communication and collaboration platform
xiazaizhadia34[.]cyou
A video game distribution platform
xiazaizhadia33[.]cyou
Server management web panel
xiazaizhadia30[.]cyou
Typing training software
xiazaizhadia29[.]cyou
Music streaming service
xiazaizhadia27[.]cyou
Translation service
xiazaizhadia24[.]cyou
Image viewing application
xiazaizhadia22[.]cyou
Messaging service
xiazaizhadia21[.]cyou
Photo editing and beautification software
xiazaizhadia20[.]cyou
A Chinese subscription video-on-demand streaming service
xiazaizhadia2[.]cyou
A Chinese music streaming service
xiazaizhadia19[.]cyou
A Chinese video live streaming platform
xiazaizhadia18[.]cyou
A major web browser in China
xiazaizhadia16[.]cyou
Software designed to automatically find and update hardware drivers on a Windows PC
xiazaizhadia12[.]cyou
A Chinese music streaming service
xiazaizhadia10[.]cyou
Remote desktop control software popular in China
xiazaizhadia1[.]cyou
An anti-detection browser
guwaanzh8[.]cyou
A privacy-focused, end-to-end encrypted messaging application that uses distributed technology
guwaanzh35[.]cyou
Server management web panel used widely in China
guwaanzh34[.]cyou
A video game distribution platform in China
guwaanzh25[.]cyou
A lightweight Chinese internet security suite
guwaanzh24[.]cyou
Instant messaging application
guwaanzh21[.]cyou
Screen capture and video recording software
guwaanzh20[.]cyou
Social media and payment application
guwaanzh2[.]cyou
A major Chinese music streaming and download service
Observed Domain Activity (Based on pDNS Data)
Domain
First Seen (UTC)
Last Seen (UTC)
ydbaoo52[.]cyou
2025-06-16 13:11:39
2025-08-20 00:10:29
i4toolscacvi[.]top
2025-04-16 01:18:16
2025-08-19 23:04:08
youdaqqaavw[.]top
2025-04-29 19:19:45
2025-08-19 20:39:49
i4toolsuuozp[.]top
2025-04-22 09:04:45
2025-08-17 05:26:12
i4toolsllsk[.]top
2025-03-09 10:20:15
2025-08-15 23:00:12
youdaovavxl[.]top
2025-04-16 01:28:55
2025-08-14 03:20:36
youdaxxddxk[.]top
2025-04-26 13:42:59
2025-07-23 04:53:57
youdaovavxk[.]top
2025-04-16 01:28:55
2025-07-22 23:02:23
ydbao11[.]cyou
2025-06-10 05:08:35
2025-07-08 10:56:29
youdaooosssj[.]top
2025-06-10 09:16:41
2025-06-11 11:22:28
qishuiyinyque-vip[.]top
2025-05-18 04:06:29
2025-06-11 11:08:24
i4toolsuuoxk[.]top
2025-04-23 03:20:02
2025-06-11 09:22:28
i4toolscacsm[.]top
2025-04-15 18:06:37
2025-06-11 06:47:22
youdaxxyzr[.]top
2025-04-25 03:35:13
2025-06-11 03:17:04
i4toolscaczu[.]top
2025-04-16 01:18:17
2025-06-10 21:16:29
youdaxxyzy[.]top
2025-04-24 10:09:16
2025-06-10 13:28:26
xiazaizhadia31[.]cyou
2025-05-26 18:14:44
2025-06-10 03:46:14
guwaanzh1[.]cyou
2025-05-15 12:09:46
2025-06-09 22:06:13
xiazaizhadia11[.]cyou
2025-05-26 15:27:15
2025-06-09 14:56:12
anydesk-www[.]cyou
2025-05-03 03:12:06
2025-06-09 08:29:06
i4.llllxiazai-web.vip
2025-05-07 09:03:49
2025-05-19 01:33:38
Acknowledgments
The authors would like to thank Shehroze Farooqi, Bradley Duncan and Alex Starov for their valuable insights and feedback to improve the research work mentioned in this article.
Imagine a scenario where malicious actors don’t need to trick you into giving up your password. They have no need to perform sophisticated social engineering attacks or exploit vulnerabilities in your operating system. Instead, they can simply force your computer to authenticate to an attacker-controlled system, effectively commanding your machine to hand over valuable credentials. This attack method is called authentication coercion.
While authentication coercion attacks such as PrintNightmare became well-known in the past few years, we have recently observed a growing trend of a new type of authentication coercion attack. These attacks focus on exploiting rarely used protocols, and they may pass through defenses written specifically for the existing known exploits.
We provide a practical guide to understanding and better defending against this prevalent, highly effective threat. Authentication coercion attacks misuse a fundamental Windows feature that enables computers to execute procedures on remote machines. Attackers manipulate this feature to force machines, including the most critical Tier 0 assets like Domain Controllers, to authenticate to attacker-controlled systems. This attack leverages the design of legitimate authentication protocols in Microsoft Windows environments and requires no special permissions.
We analyze real-world examples of threat actors misusing these inherent Windows authentication mechanisms. Our comprehensive breakdown covers the flow of authentication coercion, and includes a case study of a real attack in which threat actors exploited an obscure, rarely monitored remote procedure call (RPC) interface.
Security researchers, including Unit 42, have documented the use of coercion tools such as PetitPotam (CVE-2021-36942) in actual attacks. Microsoft has issued security advisories acknowledging the exploitation potential of this CVE.
We offer actionable monitoring, detection and prevention strategies that organizations should implement to help identify behavioral anomalies and suspicious RPC packets, for more effective detection and response.
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
At its heart, authentication coercion involves manipulating a target’s machine into initiating an authentication attempt to an attacker-controlled server. When a Windows machine attempts to connect to a resource like a shared directory or a printer, it needs to automatically authenticate to the remote resource. Attackers exploit this auto-authentication behavior. By setting up a malicious listener, they can trick a targeted machine into believing the attacker’s system is a legitimate resource it needs to connect to. When the targeted machine attempts to connect, it sends its hashed credentials to the attacker. Figure 1 shows the simplified scenario.
Successful authentication coercion attacks can result in complete domain compromise. This allows attackers to steal sensitive data, deploy malware across networks, and establish persistent access that can remain undetected for extended periods.
What makes this attack method particularly concerning is the widespread availability of proof of concept (PoC) code repositories on platforms like GitHub, which significantly lower the barrier to entry for potential attackers. The availability of ready-to-use exploit code and its integration into penetration testing frameworks like Metasploit, and its use with tools like Mimikatz, have resulted in practical attack methods. Now, even adversaries with minimal technical expertise can deploy these attacks.
Several authentication coercion techniques have been documented in real-world attack scenarios. In May 2022, the Cybersecurity and Infrastructure Security Agency (CISA) reported that a Russian state-sponsored group was exploiting PrintNightmare, CVE-2021-34527. This exploit enabled the threat actor to access cloud and email accounts and exfiltrate documents. CISA lists this CVE in its Known Exploited Vulnerabilities catalog. What this catalog doesn’t show is that attackers are now leaning towards exploiting rare, unseen RPC functions to avoid detection by traditional defense mechanisms.
Under the Hood: Authentication Coercion Techniques
RPC: The Backbone of Windows and Active Directory
To understand authentication coercion, we need to examine the basics of RPC messages. RPC is a fundamental inter-process communication (IPC) mechanism deeply embedded within every Windows operating system. It enables programs to execute procedures and services, whether those services reside locally on the same machine or remotely across a network. RPC is often accessible to standard or low-privileged domain user accounts. RPC functions are executed by calling specific methods on available interfaces, which involves a client sending a request to a server. Each of these methods has a unique operation number (opnum) within its interface that defines the specific action that the operation performs.
Many Windows protocols utilize RPC functionality as their underlying communication framework. Some functions can operate locally within a system, while others are designed for remote execution. Remote function calls can accept a Universal Naming Convention (UNC) path as a parameter to facilitate communication with a remote machine – for example, \\share\path\to\file. Figure 2 shows an example of an RPC function that takes a UNC format parameter (ShareName).
Figure 2. Documentation on IsPathSupported opnum from the MS-FSRVP protocol. Source: Microsoft.
Misusing Rare RPC Interfaces
In recent years, several RPC functions have become closely associated with coercion techniques. For instance, the PrintNightmare exploit that uses the RpcRemoteFindFirstPrinterChangeNotificationEx function is well known, and already commonly covered by security tools. However, there are other publicly available exploitation and proof of concept tools that simplify the execution of these complex attacks. This has caused security teams to often focus on monitoring the interfaces and functions targeted by those tools. But as defenders harden these known vectors, attackers increasingly pivot to lesser-known opnums that are unlikely to be monitored. For example, a Windows Coerced Authentication Methods repository lists 16 working functions across five protocols that threat actors can use to launch a coercion attack. The author of this repository notes that over 240 functions are yet to be tested, and could possibly be exploited in the same way. Understanding the scope of the attack surfaces that are potentially vulnerable to these common attack tools is crucial for implementing foundational defenses.
Table 1 maps well-known authentication coercion attack tools and the RPC protocols that are vulnerable to them.
Common Exploit/Attack Tool
Protocol
PrinterBug (PrintNightmare)
MS-RPRN
(Print System Remote Protocol)
PetitPotam
MS-EFSR
(Encrypting File System Remote Protocol)
DFSCoerce
MS-DFSNM
(Distributed File System Namespace Management Protocol)
ShadowCoerce
MS-FSRVP
(File Server Remote VSS Protocol)
PrintNightmare
MS-PAR
(Print System Asynchronous Remote Protocol)
CheeseOunce
MS-EVEN
(EventLog Remoting Protocol)
Table 1. Publicly known coercion exploits and attack tools, and their corresponding RPC protocol.
Real World Case Study: Using Rare RPC Functions
This section explores a real-world attack in which threat actors used rare RPC functions to conduct authentication coercion attacks.
In March 2025, we detected possible coercion activity on several servers within the network of a healthcare industry organization. The alert indicated that a machine on the network was attempting to coerce the local server into contacting an external IP address via RPC. The attacker exploited the remote event logging (MS-EVEN) interface, using a publicly available attack tool. MS-EVEN exposes the RPC methods for reading events in both live and backup event logs on remote computers. The combination of this interface and function is rare in the organization, because no other machine had used that specific protocol in the preceding 30 days. Figure 3 shows the alert this attack triggered.
Figure 3. Data from the “Possible authentication coercion” alert.
The Cortex XDR “Possible authentication coercion” alert shown in Figure 3 revealed the following artifacts:
The internal IP address that initiated the remote RPC: 172.17.XX.XX
Two user accounts that logged in to the internal compromised IP address that day
The IP address that was parsed from the RPC’s parameters
The threat actor used the ElfrOpenBELW function to execute the coercion attack. Figure 4 shows a detailed explanation of the opnum.
Figure 4. Microsoft documentation on ElfrOpenBELW opnum from the MS-EVEN protocol.
Figure 5 shows the legitimate usage of MS-EVEN when connecting to a remote server in the “Event Viewer” console.
Figure 5. Connecting to a remote “Event Viewer” console to see event logs on remote machines.
In this example, the IP address used in the ElfrOpenBELW function was external to the organization. The first successful authentication that day occurred at 5 a.m. from an external Kali Linux machine. The absence of malicious activity on the user account indicates that the threat actor had compromised the user’s account prior to the attack. Following these initial connections, the internal IP address then attempted to authenticate using NTLM to a wide range of critical servers within the organization, including:
Domain Controllers
Read-Only Domain Controllers (RODC)
RADIUS servers
Citrix servers
All of these authentication attempts occurred in a short time window, and all failed. The actor then made those critical servers initiate authentication to an attacker-controlled machine, stole the NTLM hashes of the servers, moved laterally and escalated privileges. Figure 6 shows the RPC actions performed by the compromised host on a wide variety of servers in the organization.
Figure 6. The compromised machine coercing authentication to servers.
This behavior stood out due to several reasons:
The rarity of usage for this RPC interface and opnum
The number of RPC messages and protocols initiated by the machine within a short timeframe
The RPC message parameters
The rarity of network traffic to the IP address from the UNC parameter
This behavior is similar to how automatic attack tools work, and it triggered an alert to the organization indicating that an attack might be occurring.
Because RPC authentication coercion does not require special permissions and can be done from any machine with network access to the remote server, the attacker used this method as the primary way to obtain credentials. We observed that the attacker sent malicious RPCS to more than 10 remote resources. All of the calls were from the same machine, and all failed to authenticate via NTLM.
Figure 7 shows the log of the agent rule that prevented the execution of the attack.
Figure 7. The agent prevented the PrinterBug attack on the internal workstation.
The attacker successfully evaded some of the agent's preventions and forced a Citrix server and an RODC to authenticate to its command and control (C2) servers.
One hour later, the attacker performed an NTLM relay from the same internal IP address. The attacker used the machine account hash of the compromised Citrix and RODC servers to target certificate authority (CA) servers. Figure 8 shows the relayed authentication from a DC machine account to a CA server from the attacker-compromised IP address. The attacker also tried to initiate a DCSync attack with the stolen DC hashes.
Figure 8. Authentication originating from the attacker’s IP address to a CA server using a DC machine account.
Figure 9 shows a summary of the attacker’s actions.
Figure 9. A summary of the attack stages seen on a customer network.
This attack’s exploitation of rarely used protocols is a growing trend. Our internal telemetry reveals an increase in authentication coercion attacks against organizations, with threat actors misusing unique protocols and functions. One of the main reasons for this increase is that as defense tools evolve and improve, attackers find more diverse and as-yet undetected ways to execute their attacks. This cycle means that defenders must create more advanced approaches to detection.
Don’t Get Coerced: Detection and Prevention Mechanisms
Monitoring RPC traffic is a crucial first step for detecting suspicious activity. However, such monitoring presents significant challenges, due to the sheer volume and complexity of RPC communications. Defenders can better filter out benign RPC traffic and identify malicious coercion activity by following the advice below.
Generic RPC Monitoring and Detection
Effective generic RPC detection involves identifying suspicious attributes and their relevance to various resources. To improve performance and effectiveness in analyzing RPC events, it is essential to filter non-relevant messages. More importantly, security teams should search for anomalies in RPC traffic. This could include:
UNC path parameters: Various coercion techniques exploit UNC paths. As local RPC traffic is less likely to be suspicious, consider filtering out calls that are performed locally. Investigate RPC parameters that might look malicious or that point to a suspicious IP address.
Source and destination: Track RPCs that have unusual origin or destination combinations, or calls that target critical assets.
Interface GUID and opnum: Each RPC protocol has multiple opnums that attackers can use to coerce authentication to a remote server. To help identify such attempts, monitor calls to both rare and known vulnerable interfaces (e.g., MS-RPRN, MS-EFSR, MS-DFSNM, MS-FSRVP) and their specific opnums.
RPC Prevention and Hardening
Improving the detection strategy for RPC communication is a key factor in eliminating coercion attacks. Critical protocols that must remain enabled require more tailored detections, while other RPC-based protocols can be handled in a more generic manner. The following actions can help to prevent coercion attacks from happening at an early stage:
Windows RPC filters: Windows offers built-in mechanisms to filter RPC traffic, which defenders can leverage to block known coercion techniques. Administrators can use the netsh rpc filter utility to better control and block RPC traffic based on various conditions.
SMB signing enforcement: Reinforce security by enforcing SMB signing across the domain. While this is not a direct RPC mitigation, it makes it more difficult for threat actors to relay coerced authentications.
Extended Protection for Authentication (EPA): EPA is a Windows security feature designed to better protect authentication credentials during network connections. Microsoft documentation provides further details about implementing this feature.
Disable unused RPC services: Minimize the attack surface of assets by disabling unused RPC-based services on them. Permit only needed services that align with the asset’s purpose.
Table 2 provides extensive information for detecting well-known coercion attacks.
Enable Extended Protection for Authentication (EPA) and disable HTTP on AD CS servers; disable NTLM on AD CS servers; disable EFSRPC service if not needed
MS-DFSNM
(Distributed File System Namespace Management Protocol)
Disable “File Server VSS Agent Service” if not needed
MS-PAR
(Print System Asynchronous Remote Protocol)
\PIPE\spoolss
76f03f96-cdfd-44fc-a22c-64950a001209
RpcAsyncOpenPrinter (opnum 0)
PrintNightmare
Disable Print Spooler service on Domain Controllers; enforce SMB signing
MS-EVEN
(EventLog Remoting Protocol)
\PIPE\even
82273fdc-e32a-18c3-3f78-827929dc23ea
ElfrOpenBELW (opnum 9)
CheeseOunce
Disable remote eventlog on Domain Controllers; general NTLM relay protections apply
Table 2. RPC protocols, interfaces and opnums to detect publicly known coercion attack techniques.
Conclusion
Authentication coercion, particularly through the misuse of rarely monitored RPC interfaces, represents a significant and evolving challenge in securing Windows and Active Directory environments. While traditional defenses against coercion provide sufficient protection against known techniques, these protections are no longer enough. Attackers are now using unmonitored, rare RPC functions – so defenders must seek out these hard to detect coercion methods.
The reliance on RPC across Windows infrastructure creates a broad attack surface. To stay ahead of potential threats, organizations must move beyond monitoring specific publicly available attack tools and PoCs to embrace generic, context-aware RPC monitoring. This means actively searching for anomalies – not just in well-known coercion vectors, but also for less-frequently used RPC interfaces and functions. Practices like establishing behavioral baselines and collecting and leveraging advanced analytics are no longer optional, but essential.
By proactively identifying and responding to these subtle shifts in attacker methodology, organizations can significantly improve their security posture and build more resilient defenses against adversaries.
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
User and Entity Behavioral Analytics (UEBA) is designed 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 better detects anomalous activity indicative of credential-based attacks.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 00080005045107
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Unit 42 researchers have uncovered a previously unknown Android spyware family, which we have named LANDFALL. To deliver the spyware, attackers exploited a zero-day vulnerability (CVE-2025-21042) in Samsung’s Android image processing library. The specific flaw LANDFALL exploited, CVE-2025-21042, is not an isolated case but rather part of a broader pattern of similar issues found on multiple mobile platforms.
This vulnerability was actively exploited in the wild before Samsung patched it in April 2025, following reports of in-the-wild attacks. However, the exploit itself — and the commercial-grade spyware used with it — have not yet been publicly reported and analyzed.
LANDFALL was embedded in malicious image files (DNG file format) that appear to have been sent via WhatsApp. This method closely resembles an exploit chain involving Apple and WhatsApp that drew attention in August 2025. It also resembles an exploit chain that likely occurred using a similar zero-day vulnerability (CVE-2025-21043) disclosed in September. Our research did not identify any unknown vulnerabilities in WhatsApp.
Importantly, our finding predates these disclosures — the LANDFALL campaign was already operating in mid-2024, using the zero-day Android/Samsung vulnerability (CVE-2025-21042) months before it was fixed.
The vulnerability has been patched since April 2025, so there is no ongoing risk to current Samsung users. In September, Samsung also patched another zero-day vulnerability (CVE-2025-21043) in the same image processing library, further protecting against this type of attack.
Our research looks back at historical exploitation that occurred before the patch, providing rare visibility into an advanced spyware operation that was publicly unreported.
Key findings:
LANDFALL is Android spyware specifically designed against Samsung Galaxy devices, used in targeted intrusion activities within the Middle East.
LANDFALL enabled comprehensive surveillance, including microphone recording, location tracking and collection of photos, contacts and call logs.
The spyware is delivered through malformed DNG image files exploiting CVE-2025-21042 — a critical zero-day vulnerability in Samsung’s image processing library, which was exploited in the wild.
The exploit chain possibly involved zero-click delivery using maliciously crafted images, similar to recent exploit chains seen on iOS and Samsung Galaxy.
The campaign shares infrastructure and tradecraft patterns with commercial spyware operations in the Middle East, indicating possible links to private-sector offensive actors (PSOAs).
LANDFALL remained active and undetected for months.
Palo Alto Networks customers are better protected through the following products and services:
In mid-2025, following the public disclosure of an exploit chain targeting iOS devices, we searched for samples of the iOS exploit. This led to our discovery of the Android spyware that we called LANDFALL.
Specifically, Unit 42 discovered several samples of DNG image files containing Android spyware used in an exploit chain targeting Samsung Galaxy devices. Our analysis confirmed these samples exploit CVE-2025-21042 to deliver LANDFALL, possibly via zero-click exploits on messaging applications.
Beginning the Hunt: The iOS Exploit Chain and How It Made Us Wonder
In August 2025, Apple issued OS security updates for its various products to address CVE-2025-43300, a zero-day vulnerability affecting DNG image parsing that attackers reportedly exploited in the wild.
That same month, WhatsApp reported a zero-day vulnerability for CVE-2025-55177 that was chained with the image-processing vulnerability for Apple platforms in sophisticated attacks targeting iOS devices. The WhatsApp vulnerability allowed attackers to force devices to process content from arbitrary URLs.
When the two vulnerabilities were combined in an exploit chain, this enabled zero-click remote code execution through maliciously crafted images sent via WhatsApp messages.
Given the disclosure of this in-the-wild exploit chain and the absence of publicly available exploit samples, we initiated a hunt for this activity. Our search led to the discovery of several previously undetected DNG image files containing embedded Android spyware that were uploaded to VirusTotal throughout 2024 and early 2025.
Judging by their filenames (e.g., WhatsApp Image 2025-02-10 at 4.54.17 PM.jpeg and IMG-20240723-WA0000.jpg), attackers likely delivered these samples via WhatsApp. Our analysis of the embedded spyware indicates it is designed for Samsung Galaxy devices.
Malformed DNG Image Files: A New Attack Vector Trend
Our analysis of LANDFALL spyware began with our discovery of malformed DNG image files. DNG stands for Digital Negative, and it is a raw image file format based on the TIFF image format. The malformed DNG image files we discovered have an embedded ZIP archive appended to the end of the file. Figure 1 shows one of these samples in a hex editor, indicating where the ZIP archive content begins near the end of the file.
Figure 1. Example of a malformed DNG image with an embedded ZIP archive.
Our analysis indicates these DNG files exploit CVE-2025-21042, a vulnerability in Samsung's image-processing library libimagecodec.quram.so that Samsung patched in April 2025. The exploit extracts shared object library (.so) files from the embedded ZIP archive to run LANDFALL spyware. Figure 2 below shows a flowchart for this spyware.
Figure 2. Flowchart for LANDFALL spyware.
Table 1 shows the DNG image samples we discovered.
Filenames with strings like WhatsApp Image and WA000 imply attackers could have attempted to deliver the embedded Android spyware via WhatsApp. This matches earlier public reporting of similar DNG image-based exploitation through WhatsApp targeting Apple devices. Furthermore, WhatsApp researchers identified and reported a similar DNG vulnerability, CVE-2025-21043, to Samsung.
Delivering LANDFALL Spyware: Mobile Device Malware Exploit Chains
Typically, mobile device malware distributed through exploits requires a chain of exploits across different vulnerabilities for successful infection. Various studies have documented cases of at least two vulnerabilities when distributing spyware, but modern exploit chains for spyware are far more complex [PDF], linking multiple vulnerabilities to compromise mobile devices and gain privileges.
We have yet to discover any further exploits associated with this activity.
Please see the later section, How LANDFALL Fits Into the Larger Picture, for a more complete description of the known vulnerabilities involved in this and similar exploit chains.
LANDFALL Spyware Analysis
LANDFALL is Android spyware specifically designed for Samsung Galaxy devices, likely used in targeted intrusion activities within the Middle East. This modular spyware is engineered for espionage and data exfiltration.
The infection chain for LANDFALL involves an exploit for CVE-2025-21042, a vulnerability in Samsung's image-processing library tracked by the vendor as Samsung Vulnerabilities and Exposures (SVE) designator SVE-2024-1969. We believe a full attack chain would follow a pattern of potential zero-click remote code execution, beginning with the delivery of the malformed DNG images.
Two components of LANDFALL spyware are embedded within the malformed DNG images and would be extracted and executed, following a successful exploit:
Loader (b.so): An ARM64 ELF shared object (106 KB, stripped and dynamically linked) that serves as the main backdoor.
SELinux Policy Manipulator (l.so): Extracted from an XZ-compressed ELF binary, this component is designed to manipulate the device's SELinux policy to grant LANDFALL elevated permissions and aid persistence. (See Appendix A - SELinux Policy Manipulation.)
Table 2 shows the LANDFALL component files embedded within the malicious DNG samples.
SELinux policy manipulator (l.so) extracted from XZ compressed file
July 23, 2024
Table 2. LANDFALL components embedded in the DNG image files.
Our analysis indicates LANDFALL is multi-component Android spyware designed for monitoring and data exfiltration.
Our analysis focuses on the b.so component, which serves as the initial loader for a broader LANDFALL framework. In its own debug artifacts, the component refers to itself as “Bridge Head.” This will be of interest later when we discuss possible relationships between LANDFALL and known spyware groups.
LANDFALL’s Potential Capabilities
The b.so component of LANDFALL contains numerous debug and status strings, but it does not contain the logic that actually references most of these strings. This suggests that b.so would download additional components for these capabilities. Our analysis of embedded command strings and execution paths within the b.so file provides insight into the broader LANDFALL's potential capabilities.
Device Fingerprinting
OS version
Hardware ID (IMEI)
SIM/Subscriber ID (IMSI)
SIM card serial
User account
Voicemail number
Network configuration
Taking inventory of installed applications
Accessing location services
VPN status
USB debugging status
Bluetooth
Data Exfiltration
Recording microphone
Recording calls
Call history
Contacts database
SMS/messaging data
Camera photos
Arbitrary files
Databases on the device (browsing history, etc.)
Execution, Loading and Persistence
Loading native shared object (.so) modules
Loading and executing DEX files from memory and disk
Injecting processes
Executing via LD_PRELOAD
Executing arbitrary commands
Manipulating SELinux
Persistency
Modifying SELinux policy via compressed binary
Monitoring WhatsApp Media directory for additional payloads
Registering WhatsApp web client
Manipulating the file system in Android app directories
Manipulating the file system
Evasion and Defense Avoidance
Detecting TracerPid debugger
Detecting Frida instrumentation framework
Detecting Xposed framework
Dynamic library loading with namespace manipulation
Certificate pinning for C2 communications
Cleaning up WhatsApp images payload
Targeted Device Models
Galaxy S23 Series (S91[168]BXX.*)
Galaxy S24 Series (S921BXXU1AWM9, S92[168]BXX.*)
Galaxy Z Fold4 (F936BXXS4DWJ1)
Galaxy S22 (S901EXXS4CWD1)
Galaxy Z Flip4 (F721BXXU1CWAC)
Figure 3 shows an example of the targeted device model strings in a b.so sample of LANDFALL.
Figure 3. LANDFALL b.so sample in a hexadecimal editor showing targeted device model numbers.
C2 Communication
The b.so component of LANDFALL communicates with its C2 server over HTTPS using a non-standard, ephemeral TCP port. Before the HTTPS traffic, it can initiate ping traffic as detailed in the Communication With the C2 Server section of Appendix B. For HTTPS traffic, b.so initiates contact with a POST request containing detailed device and spyware information, such as:
Agent ID
Device path
User ID
Figure 4 shows an interpretation of this initial POST request, where we use curl to show how this request would be structured. Of note, LANDFALL does not use curl to generate this traffic.
Figure 4. HTTP POST request structure when b.so initially contacts the C2 server.
The initial beacon traffic is an HTTP POST request to the C2 server with the following parameters:
protocol: The protocol version (e.g., A1.5.0)
protocol_ver: The protocol version (e.g., "")
type: The message type (e.g., MSG_TYPE_GET_AGENT)
agent_id: The agent's unique identifier
upload_id: An upload identifier
command_id: A command identifier
source: The source of the request (e.g., bridge_head)
incremental_build: The incremental build version (e.g., v1.5.0)
euid: The effective user ID of the process
bh_path: The path to the b.so binary on the device
runner: The runner mode (e.g., I)
Configuration of b.so File
The b.so file's configuration is managed through a combination of hard-coded default values and an encrypted JSON object embedded within itself. This configuration includes C2 details, cryptographic keys and unique identifiers for the agent and commands.
Figure 5 shows an example of this configuration.
Figure 5. Example of LANDFALL’s configuration.
This b.so component of LANDFALL also contains a number of hard-coded configuration values. These are used as default values if they are not provided in the encrypted JSON object. We do not yet fully understand the purpose of some of these values. Table 3 shows these hard-coded default configuration values.
Field Name
Default Value
allow_wifi
true
allow_mobile
true
allow_roaming
false
socket_timeout
5
sleep_time
60 (0x3c)
sleep_time_between_retries
35 (0x23)
suicide_time
7200 (0x1c20)
live_mode_expiration
0
allow_min_battery
0
is_persistent
false
Table 3. Hard-coded default configuration values for LANDFALL malware.
C2 Infrastructure for LANDFALL Spyware
Based on our analysis of these samples, we identified six C2 servers for LANDFALL, shown below in Table 4.
IP Address
Domain
First Seen
Last Seen
194.76.224[.]127
brightvideodesigns[.]com
Feb. 7, 2025
Sept. 19, 2025
91.132.92[.]35
hotelsitereview[.]com
Feb. 3, 2025
Sept. 16, 2025
92.243.65[.]240
healthyeatingontherun[.]com
Oct. 11, 2024
Sept. 2, 2025
192.36.57[.]56
projectmanagerskills[.]com
Feb. 3, 2025
Aug. 26, 2025
46.246.28[.]75
Unknown
Unknown
Unknown
45.155.250[.]158
Unknown
Unknown
Unknown
Table 4. LANDFALL C2 servers.
How LANDFALL Fits Into the Larger Picture
LANDFALL is one example of a larger pattern of exploit chains affecting mobile devices, related to DNG image processing vulnerabilities.
The LANDFALL campaign's use of a malformed DNG file highlights a significant, recurring attack vector: the targeting of vulnerabilities within DNG image processing libraries. The specific flaw LANDFALL exploited, CVE-2025-21042, is not an isolated case but rather part of a broader pattern of similar issues found on multiple mobile platforms. In fact, earlier in 2025, Samsung identified another DNG flaw in the same Samsung library, CVE-2025-21043, and the parallel exploit chain on iOS was identified that leveraged CVE-2025-43300 in Apple iOS and CVE-2025-55177 in WhatsApp.
Relationship to CVE-2025-21043 (SVE-2025-1702)
Our analysis revealed a possible connection to a separate vulnerability in the same library, CVE-2025-21043 (SVE-2025-1702), which Samsung patched in its September 2025 security update. While it was not exploited in the LANDFALL samples we discovered, the similarities between the exploit for LANDFALL (CVE-2025-21042) and this vulnerability (CVE-2025-21043) are striking. Both vulnerabilities were publicly disclosed around the same time and both are connected to DNG image file processing delivered through mobile communication applications.
Apple's CVE-2025-43300
In August 2025, Apple addressed CVE-2025-43300, a zero-day vulnerability impacting DNG image parsing, which was actively exploited in the wild, to enable zero-click remote code execution through malicious images sent via mobile communication applications.
We cannot confirm whether this chain was used to deliver an equivalent of LANDFALL to iOS, or whether it is the same threat actor behind the two. However, this parallel development in the iOS ecosystem, combined with the disclosure of the Samsung and Apple vulnerabilities just a few weeks apart, highlights a broader pattern of DNG image processing vulnerabilities being leveraged in sophisticated mobile spyware attacks.
Figure 6. Timeline for recent malicious DNG image files and associated exploit activity.
July 2024 – February 2025: Initial samples of malicious DNG image files carrying LANDFALL are first submitted on VirusTotal in July 2024, with additional samples appearing periodically over the next several months.
The DNG files exploit a vulnerability in Samsung’s Android image processing library (SVE-2024-1969, CVE-2025-21042)
April 2025: Samsung issues a firmware update to address the vulnerability, SVE-2024-1969, later known as CVE-2025-21042 when publicly disclosed.
August 2025: Parallel developments occur.
Apple patches a zero-day vulnerability impacting DNG image parsing, which was actively exploited in the wild (CVE-2025-43300)
WhatsApp discloses a vulnerability (CVE-2025-55177) that was chained with Apple’s DNG image parsing zero-day vulnerability (CVE-2025-43300)
We discovered DNG image files exploiting CVE-2025-21042 to deliver Android spyware that we identified as LANDFALL.
WhatsApp disclosed to Samsung CVE-2025-21043 — another DNG-related zero-day vulnerability in Samsung Galaxy devices.
September 2025: Samsung issues mobile device firmware updates for CVE-2025-21043 (SVE-2025-1702). Concurrently, it assigns CVE-2025-21042 (SVE-20254-1969) to the earlier vulnerability that previously had no CVE designator.
Potential Victims
Analysis of VirusTotal submission data for the malicious DNG files indicates potential targets in Iraq, Iran, Turkey and Morocco.
Turkey's national CERT (in Turkish, USOM) reported IP addresses used by LANDFALL's C2 servers as malicious, mobile- and APT-related, which also supports the possible targeting of victims in Turkey.
Relationship to Known Spyware Groups
While we were unable to recover every component of the LANDFALL framework, it is clear that the tool is commercial grade. It may have utilized several zero-day exploits in its infection chain.
Such tools are often developed and sold as commercial spyware and attributed to groups known as private sector offensive actors (PSOAs), who are often legitimate legal entities. Reportedly, these groups provide services to government entities.
We were not able at this time to officially attribute LANDFALL activity to a known PSOA or threat actor. Unit 42 tracks the activity related to CVE-2025-21042 and LANDFALL as CL-UNK-1054.
Two aspects are notable and worth highlighting.
First, LANDFALL's C2 infrastructure and domain registration patterns share similarities to infrastructure associated with Stealth Falcon as observed by Unit 42. These similarities are based on various publicreports, as well as Stealth Falcon activity we have analyzed for targets in the Middle East.
Second, in its own debug artifacts, the spyware component we analyzed refers to itself as “Bridge Head.” Of note, the term Bridge Head is a common nickname used by some private-sector offensive cyber companies (including NSO, Variston [PDF], Cytrox and Quadream) for first-stage loaders. However, this naming convention alone does not constitute a direct attribution link.
While this is a common name used in commercial mobile spyware to describe loaders, it draws similarities to the Heliconica framework. This framework also contains references to “BridgeHead,” as Google TAG reported about spyware vendor Variston. Google identified Variston as a Barcelona-based PSOA (provider of exploits). Further analysis from Google and other reports indicated Variston's tooling was supplied to clients in the UAE through a reseller named Protect Electronic Systems (or Protected AE).
This potential provider-client link to the UAE is noteworthy, as Microsoft and others reported that Stealth Falcon also operates heavily out of that country. Variston reportedly ceased operations in early 2025 following its public exposure.
As of October 2025, except in infrastructure, we have not observed direct overlaps between the mobile campaigns of LANDFALL and the endpoint-based activity from Stealth Falcon, nor direct strong links with Stealth Falcon. However, the similarities are worth discussion.
Conclusion
The discovery of LANDFALL spyware reveals a campaign targeting Samsung Android devices. The exploit chain involves CVE-2025-21042, a vulnerability that was patched by Samsung in April 2025. The presence of this spyware within DNG image files with WhatsApp-related naming conventions likely indicates attackers attempted to deliver the exploit through a messaging application.
From the initial appearance of samples in July 2024, this activity highlights how sophisticated exploits can remain in public repositories for an extended period before being fully understood.
The analysis of the loader reveals evidence of commercial-grade activity. The LANDFALL spyware components suggest advanced capabilities for stealth, persistence and comprehensive data collection from modern Samsung devices.
However, we have not directly analyzed the next-stage components of the spyware. Additional details on this or on the exact delivery method would provide even more insight into the malicious activity.
Palo Alto Networks customers are better protected from LANDFALL Android spyware through the following products:
The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research.
Advanced Threat Prevention has an inbuilt machine learning-based detection that can detect exploits in real time.
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
Malware Samples
A list of malware samples for LANDFALL activity is listed below in Table 7.
LANDFALL's component for SELinux policy manipulation is l.so. This file provides a capability to bypass system security controls. It is decompressed from /data/data/com.samsung.ipservice/files/l to /data/data/com.samsung.ipservice/files/l.so and executed.
Rather than containing hard-coded rules, l.so implements a generic engine that can dynamically parse and load new SELinux policy statements from an external source, modifying the running policy in memory.
Appendix B: Additional Details on LANDFALL Spyware Analysis
This appendix details the observed capabilities of the loader component of LANDFALL, as well as those we infer exist in other modules of the complete LANDFALL framework that we have not yet accessed.
LANDFALL’s Bridge Head, named on the disk as b.so, is loaded by an exploit on the device. Immediately after being loaded post‑exploit, LANDFALL parses LD_PRELOAD from the environment to avoid inheriting upstream preloads. It reads the effective user ID via geteuid() and stores it globally so later branches can adjust behavior for root versus non‑root. Then it calls into the main routine.
It gathers process basics (parent pid, euid, Android build string), reads a runner flag from the environment variable R and takes a copy of it for later actions. This value (typically I for interactive or P for passive) will be reported to the command and control and determine how it launches a later staged payload. It resolves its own mapped path, selects the app-private base at /data/data/com.samsung.ipservice/files/ as its working directory and then constructs two child paths there. One path is for the staged download and one is for the final l.so used for execution.
Configuration
LANDFALL reads and XOR-decrypts a JSON configuration directly from its own file. The spyware normalizes configuration by writing internal defaults back into the parsed object: numeric fields default when missing or zero, and certain booleans are coerced to fixed values regardless of the supplied configuration. Finally, it checks that a public key (X.509 DER) is present in the configuration and exits otherwise.
Table 8 summarizes the configuration normalization performed at this stage.
Key Name
Value Type
Default
Required
allow_wifi
boolean
Enforced true (overrides false/missing to true)
No
allow_mobile
boolean
Enforced true (overrides false/missing to true)
No
allow_roaming
boolean
Default false if missing/false; true remains true
No
allow_min_battery
integer
0 if value is 0 or missing
No
sleep_time
integer (seconds)
60 if value is 0 or missing
No
sleep_time_between_retries
integer (seconds)
35 if value is 0 or missing
No
suicide_time
integer (seconds)
7200 if value is 0 or missing
No
live_mode_expiration
integer (seconds)
0 if value is 0 or missing
No
socket_timeout
integer (seconds)
5 if value is 0 or missing
No
is_persistent
boolean
Default false if missing/false; true remains true
No
bridge_head_version_major
integer
Hard-set to 2 (always)
No
bridge_head_version_minor
integer
Hard-set to 1 (always)
No
cnc_hostname
string
None; must be present
Yes
cnc_port
integer
None; must be non-zero
Yes
cnc_base_url
string
None; must be present
Yes
agent_id
string (UUID)
None; must be present
Yes
command_id
string (UUID)
None; must be present
Yes
commands
array
Must exist; read and freed (structure not retained here)
Yes
public_key
X.509 DER (bytes)
None; must be present and valid
Yes
Table 8. Keys and values for LANDFALL malware.
Communication With the C2 Server
Once configuration is complete, b.so loads the necessary network and encryption functions, sets up its SSL environment, and prepares a secure client context for future HTTPS communication. If any part of this setup fails, it exits cleanly rather than risk a partial setup.
Before entering the C2 beaconing loop, it optionally emits telemetry. If it is running as root, it formats a concise "started" line that includes:
A fixed version marker (e.g., v1.5.0)
pid
euid
Runner mode
It then sends that via a POST request to the C2 server, as shown below.
If the runner mode is I, it prepares the SELinux helper first: it locates the compressed policy helper (/data/data/com.samsung.ipservice/files/l), inflates it via an internal XZ decoder into a fresh buffer, and writes the result to data/data/com.samsung.ipservice/files/l.so. Then it beacons to the C2 server by sending ping using the hyphen‑stripped agent_id as payload. The outcome doesn’t gate the rest of the flow, and it serves as an operator telemetry.
An example of code for an I‑mode ping follows.
Only then does the main C2 beaconing loop begin. It records time zero and enforces a strict wall‑clock budget of about 7,200 seconds (suicide_time) for the entire session.
It zeros two large, reusable path buffers: one for the raw blob that may arrive from the server, and a sibling for the decompressed shared object. Both paths live under the app‑private working directory (e.g., /data/data/com.samsung.ipservice/files/). With the paths ready, it contacts the command and control server by building a compact, URL‑encoded style body of key=value pairs:
A protocol/variant tag; the beacon message type
The agent_id, command_id and a fresh upload_id (UUIDv4) for correlation
source=bridge_head
Euid
The runner flag and its on‑disk install path
When applicable, it computes a SHA-1 over part of the message and appends it. It uses the following Chrome User‑Agent string:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.89 Safari/537.36
Requests are directed at the configured base path (e.g., POST /is/ HTTP/1.0). Before any application data is sent, it pins the TLS connection.
While reading the response from the C2 server, LANDFALL checks the response status code and looks through the headers to determine the message length and type. Some status codes — particularly timeouts and a masked set of 4xx/5xx (e.g., 408, 504) — are treated as transient and trigger sleep(sleep_time_between_retries) (default 35 seconds) before retrying with a fresh connection. A not‑found response (e.g., 404) is considered terminal for this run and exits the loop. If the status indicates success and a body is present, LANDFALL proceeds to staging.
Next-Stage Payloads
Staging starts by cleaning up the file system state. If an old raw blob exists at the temporary path, it removes it. It writes the raw bytes to a staging file named aa.so under the working directory, and then, attempts to decompress them using a built‑in XZ/LZMA decoder that inflates into a pre‑allocated approximately 5 MiB buffer.
On success, it writes the decompressed bytes to dec_a.so (the final .so path) under the working directory, clears the temporary aa.so and sets the file mode on dec_a.so to 777 to ensure it’s loadable in various contexts.
Example XZ inflater (trimmed):
With the shared object in place (dec_a.so), it chooses an execution strategy based on the runner flag. For interactive setups (I), it exports two environment variables and launches a benign system tool synchronously:
LD_PRELOAD=<final.so> PRELOAD_PATH=/data/data/com.samsung.ipservice/files/l.so /system/bin/id (where <final.so> is dec_a.so)
The PRELOAD_PATH points at the device path where SELinux policy content is expected, allowing the preloaded code to find and apply policy at startup. Note that this PRELOAD_PATH is only used in interactive mode, the passive running path omits it.
For passive runs (P), it launches the same tool in the background:
LD_PRELOAD=<final.so> /system/bin/id (with <final.so> is dec_a.so)
This is done so control returns quickly while the helper initializes in another process. Internally, both are dispatched via a shell wrapper (/system/bin/sh -c <cmd>). In both cases, it accepts only narrow success results:
exit code 0 or a specific 0x15; anything else is treated as failure and breaks out of the loop
On successful load, it formats and sends an “ended” line mirroring the opening message including:
Version marker
pid
incremental_build
runner
It then frees transient strings and buffers. If no payload was available, or if a transient error occurred, it checks the elapsed wall‑clock time against its approximately 7,200‑second budget. If there’s time left, it sleeps the configured interval and tries again.
Finally, when the loop finishes, either after a successful loading of the next stage or due to time budget or unrecoverable errors, it unwinds cleanly. If it is running as root, it prefers a direct _exit(status) path instead of a normal return to minimize side effects in the runtime. In all cases, it aims to leave behind only the minimum artifacts needed for the staged code to continue.
Unreferenced Capabilities
During reverse engineering, we identified multiple routines compiled into the b.so component that are not invoked by its observed control flow. These latent features appear designed for use by the follow‑on modules loaded.
It is also very probable that some of these functions are leftovers from older versions of LANDFALL. They reveal concrete behaviors oriented around WhatsApp media paths, DCIM discovery, file system staging and process hygiene on Android:
One routine prepares a “started” telemetry line and then interacts with the device’s media subsystem. It formats the line:
BH v1.5.0 started - pid: , euid=, incremental_build: v1.5.0, runner:
If its internal checks pass, it executes a broadcast to force a gallery rescan using the exact shell:
am broadcast -a android.intent.action.MEDIA_SCANNER_SCAN_FILE -d file:///sdcard/DCIM/hacked.jpg
In the same flow, it also constructs a “newest photo” probe over DCIM using:
find /sdcard/DCIM -type f -exec ls -t1 {} + | grep -v hacked| head -1
This pattern is consistent with harvesting the latest camera item while excluding an artifact it can plant. This routine is compiled in but not called by any other code in the sample.
WhatsApp media path planter. Another routine decodes a hard-coded Base64 1x1 PNG (iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJ…JRU5ErkJggg==) and searches WhatsApp’s media directories on external storage for a recent file path that matches the agent’s identifier (the UUID is first stripped of hyphens). It builds and executes a search pipeline across both default (ID 0) and multi‑user (ID 95) paths:
If such a path is returned, it writes the decoded PNG there verbatim. This looks like a cover‑artifact or covert marker stage aimed at WhatsApp images.
Another helper takes a base directory and a string and returns one matching JPEG path by executing:
It trims trailing newlines and verifies the path exists before returning.
Zygote avoidance check: A process‑hygiene helper allocates a buffer for its own cmdline and returns success only when the name does not match zygote or zygote64. It is designed to avoid Android’s special host processes.
SELinux symbol resolver and cleanup: Two small routines handle dynamic SELinux plumbing.
One dlopens /system/lib64/libselinux.so and resolves getfilecon and setfilecon into global function pointers.
The other tears this down and clears the pointers.
Both exist to support policy/file‑context work but are not referenced by the observed code path.
A more substantial routine accepts a list of file system paths. For each, it saves the current label via getfilecon, invokes an internal labeler on the path, applies ownership via chown and then restores the saved label with setfilecon. It returns distinct negative codes when chown or setfilecon fail.
There is a file probe that attempts to open a path and maps the outcome to internal status codes (success, permission denied, not found, generic error). It also resets internal library state (including any previously opened SELinux handles).
Map process‑execution outcome to message status: A tiny mapper converts the result of an internal command‑execution helper into message catalog codes (e.g., mapping a specific return (1) to CMD_STAT_* code 0x0C and 2–3 to 0x51). It standardizes reporting for helpers but is not reached by the current logic.
Building a device‑report JSON array: Another dormant routine constructs a cJSON array where each entry carries device_path, a Base64‑encoded binary field, a last_updated boolean and a textual state derived from the internal CMD_STAT_* table. It walks an input vector, reads the referenced file into memory, Base64 encodes it and appends to the array.
A small string‑templating helper finds occurrences of the token --working_dir-- inside a JSON value and replaces them with the runtime path tracked by the b.so.
Appending TracerPid to telemetry: A diagnostic helper parses /proc/self/status, extracts the TracerPid line, converts it to an integer, and, if greater than zero, appends a formatted key/value into the request body via the b.so’s string‑builder.
A staging helper concatenates an existing buffer with a pseudo‑random block derived from an input string:
It seeds a byte with rand()
It XORs each subsequent byte of the input into a rolling accumulator
It writes the accumulator bytes as a suffix
It then writes the combined buffer to a given file path via the b.so’s writer
A two‑step installer/uninstaller pair uses three config keys: persistency_origin, persistency_payload and persistency_backup. The main routine checks that all three are set, copies the backup back to the origin if needed and then deletes the payload file. It returns distinct status codes (0x4B/0x4C/0x4D) that map to the message catalog entries for “no config,” “failed move” and “failed unlink.” A sibling routine conditionally creates or truncates the backup file (fopen with mode “w”) when a global persistence flag is set.
Battery percentage via sysfs: A utility reads battery capacity from the system’s power‑supply sysfs, checking two common locations: /sys/class/power_supply/battery/capacity and /sys/class/power_supply/Battery/capacity.
Two routines set up and finalize the working directory under app‑private storage.
The first creates the directory tree, applies mode 0771 (0x1F9), temporarily adds execute to the parent and copies the resolved path into config. And, when running as root, it attempts to mount a tmpfs at that location to keep artifacts in memory
The second (cleanup/finalize) can, when root and the directory exists, run lsof | grep <working_dir> and ship the result home. It then restores the parent directory’s original mode and frees the path buffer
Process discovery by SELinux context and by cmdline: Two search helpers iterate /proc, building and reading per‑PID files.
One compares /proc/%d/attr/current against a target SELinux context and then confirms the process has PPID 1
The other compares /proc/%d/cmdline against a target cmdline
On a match, they write the PID to an out‑parameter and return success
Debug‑printing a variant array: A developer‑facing routine prints a small typed array structure. It formats type names from a table, dumps short byte arrays inside square brackets and emits a single character for a specific type, one element per line. This looks like leftover debugging and is not invoked by active code.
None of these helpers are exercised by this component’s main execution loop. Their presence is consistent with a staged architecture in which subsequently loaded shared objects, forming the complete LANDFALL framework, expand collection and persistence using capabilities already compiled into this loader.
Asset Management: The Boring Hero of Cyber Defense
Cyber threat intelligence is often touted as a way to help defend an organization's IT environment. If we better understand the threats that might target our networks, we can better defend ourselves against those threats. This is true, but threat intelligence is only effective if an organization also properly manages its IT assets.
Asset management consists of:
Inventory and tracking of hosts on an organization's network
Monitoring hosts on an organization's network
Administering hosts on an organization's network (software patches, OS and hardware updates, endpoint defense solutions, etc.)
While not entirely a security function, asset management should be at the base of any IT security pyramid. As I wrote in 2019 for SANS Internet Storm Center (ISC), "Without inventory management, we cannot properly secure our infrastructure, because we don't fully understand everything on our network." An unknown or improperly managed host within an organization's network could provide a window for attackers to establish a foothold in the environment.
Unfortunately, asset management isn't as exciting as the cyberthreats we face. Reading about a particular threat is often more intriguing than taking the practical steps needed to defend against it.
Patch, Protect, Prevent: Why It Still Matters
I first noticed this as a volunteer handler at the ISC. During my time with the ISC, I frequently wrote diaries that provided examples of Windows-based malware infections and the associated indicators. My lab environment consisted of purposefully vulnerable hosts, so I ended these diaries with best practices to help protect against the threat. A key part of these final words included a statement advising that properly administered and up-to-date Windows hosts were much less likely to become infected.
Readers would occasionally leave favorable comments about the technical content regarding the threats, but sometimes they commented on how frustrating it was to see the same preventative measures over and over again in my diaries.
However, these preventative measures are the best security practices. When implemented, they were often effective against prominent malware families like Emotet and Qakbot (Qbot). In my diaries about these malware families, the samples in my lab could easily have been prevented through various vendors' endpoint security solutions. However, these malware families were responsible for millions of malware infections worldwide. In the 2023 takedown of Qakbot's infrastructure, the malware family was reportedly responsible for more than 700,000 infections. In a disruption of Emotet's infrastructure in 2021, it was reportedly responsible for over 1.6 million infections.
Some of this can be attributed to the cat-and-mouse game of cybercriminals trying to stay ahead of security vendors. But many of these infections could've been detected or prevented with proper asset management.
Asset Management: Your First Line of Defense, Not the Last
Knowing the threat posed by malware families like Emotet and Qakbot may be part of an effective defense, but without the bedrock of asset management, threat intelligence about those attacks is far less effective. The bedrock of asset management is necessary to better defend an organization against any IT threat.
Although attacks have evolved, we see many time-honored tactics that remain the same. For example, an ongoing tactic is using SEO poisoning to deliver malware disguised as legitimate software. For an Akira ransomware infection in August 2025, the initial access vector was SEO poisoning that led to a Bumblebee malware infection. This is a classic case of an initial infection leading to lateral movement and a domain controller takeover, where the attackers deployed ransomware across the network.
My advice? Know ourselves before we know the enemy, because the enemy is always looking for weaknesses in our defense.
Without comprehensive asset management, attackers can find avenues into our networks. Palo Alto Networks Unit 42 Attack Surface Assessment can help find these potential access paths before attackers can take advantage of them.
Unit 42 stopped monitoring this threat and updating the brief on Jan. 30, 2026. Please refer to Microsoft’s website for the latest information.
On Oct. 14, 2025, a critical, unauthenticated remote code execution (RCE) vulnerability was identified in Microsoft's Windows Server Update Services (WSUS), a core enterprise component for patch management. Microsoft's initial patch during the October Patch Tuesday did not fully address the flaw, necessitating an emergency out-of-band security update released Oct. 23, 2025. Within hours of the emergency update, Unit 42 and other security researchers observed active exploitation in the wild. The combination of a remotely exploitable, unauthenticated RCE in a core infrastructure service, coupled with observed active exploitation in the wild, represents a severe and time-sensitive risk.
Key details of the threat are summarized below:
Vulnerability: Critical Remote Code Execution (RCE) in Windows Server Update Services (WSUS), tracked as CVE-2025-59287 (CVSS 9.8).
Impact: Allows a remote, unauthenticated attacker to execute arbitrary code with system privileges on affected servers.
Status: Actively Exploited. Threat actors were observed exploiting the vulnerability within hours of Microsoft releasing an emergency patch on Oct. 23.
Urgency: The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added this vulnerability to its Known Exploited Vulnerabilities (KEV) Catalog on Oct. 24, underscoring the immediate risk.
For organizations unable to deploy the emergency patches immediately, Microsoft has recommended temporary workarounds to mitigate the risk.
Palo Alto Networks customers are better protected from activity related to CVE-2025-59287 through the following products and services:
WSUS is a foundational tool for IT administrators, enabling the centralized management and distribution of Microsoft product updates across corporate networks. Its role as a trusted source for software patches makes it a high-value target; a compromise of a WSUS server can provide a foothold for lateral movement and widespread network compromise.
The vulnerability is rooted in an "unsafe deserialization of untrusted data." Security researchers have identified multiple attack paths including sending a specially crafted request to the GetCookie() endpoint, which causes the server to improperly deserialize an AuthorizationCookie object using the insecure BinaryFormatter. Another path targets the ReportingWebService to trigger unsafe deserialization via SoapFormatter. In both cases, a remote, unauthenticated attacker can trick the system into executing malicious code with the highest level of system privileges.
The scope of this vulnerability is specific to systems with the WSUS role enabled:
Affected Software: Microsoft Windows Server 2012, 2012 R2, 2016, 2019, 2022 (including 23H2 Edition) and 2025.
Required Condition: The vulnerability only affects servers where the WSUS Server Role is enabled. This feature is not enabled by default.
Current Scope of the Attack Using CVE-2025-59287
Following the public disclosure of a proof-of-concept exploit, Unit 42 in addition to other security firms quickly detected active scanning and exploitation.
Analysis of the attacks observed by Unit 42 reveals a consistent methodology focused on initial access and internal network reconnaissance.
Initial Access: Attackers target publicly exposed WSUS instances on their default TCP ports, 8530 (HTTP) and 8531 (HTTPS).
Execution: Malicious PowerShell commands are executed via specific parent processes. Observed forensic process chains include wsusservice.exe → cmd.exe → cmd.exe → powershell.exe and w3wp.exe → cmd.exe → cmd.exe → powershell.exe.
Reconnaissance: The initial payload executes commands to gather intelligence on the internal network environment, including whoami, net user /domain, and ipconfig /all. This initial command set is designed to rapidly map the internal domain structure and identify high-value user accounts, providing the attacker with an immediate blueprint for lateral movement.
Data Exfiltration: Collected information is exfiltrated to a remote, attacker-controlled Webhook.site endpoint using a PowerShell payload that attempts Invoke-WebRequest and falls back to curl.exe if needed.
Cortex Xpanse identified approximately 5,500 WSUS instances exposed to the internet, providing a tangible metric for the global attack surface. This reconnaissance-focused TTP indicates that initial exploitation is a precursor to broader network compromise, making immediate remediation and threat hunting paramount.
Interim Guidance
Microsoft has recommended temporary workarounds to mitigate the risk for organizations unable to deploy the emergency patches immediately. These measures should be considered interim solutions until patching can be completed.
We recommend that affected organizations follow this guidance to address the issue, and check back on official Microsoft language regularly for updates.
As of Oct. 27, the guidance consisted of the following mitigations:
1. Disable the WSUS Server Role: Disabling the WSUS role on the server removes the attack vector entirely. However, this will prevent the server from managing and distributing updates to client systems.
2. Block High-Risk Ports: Block all inbound traffic to TCP ports 8530 and 8531 on the host-level firewall. As recommended by Microsoft, this removes the attack vector but will prevent the server from managing and distributing updates.
Unit 42 Managed Threat Hunting Queries
The Unit 42 Managed Threat Hunting team continues to track any attempts to exploit this CVE across our Managed Services customers, using telemetry available within Cortex XDR. Cortex XDR customers who don’t leverage Unit 42 Managed Services can also use the following XQL query to search for signs of exploitation.
Based on the amount of publicly available information, the ease of use and the effectiveness of this exploit, Palo Alto Networks highly recommends following Microsoft’s guidance to protect your organization.
This vulnerability and subsequent weaponization serves as an illustration of how configuration failures enable exploitation. While the WSUS vulnerability provides the technical vector, its potentially severe impact is a direct consequence of lapses in security hygiene.
The exposure of an internal-facing service, such as WSUS, to the public internet constitutes a significant misconfiguration that elevates a localized server vulnerability into a potential enterprise-wide, supply-chain compromise. This underscores that rigorous asset management and disciplined network segmentation are critical security controls, essential for mitigating the escalation of isolated flaws into systemic organizational breaches.
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 CVE-2025-59287
Palo Alto Networks customers can leverage a variety of product protections and updates to help 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)
We discovered a new attack technique, which we call agent session smuggling. This technique allows a malicious AI agent to exploit an established cross-agent communication session to send covert instructions to a victim agent.
Here, we discuss the issues that can arise in a communication session using the Agent2Agent (A2A) protocol, which is a popular option for managing the connections between agents. The A2A protocol’s stateful behavior lets agents remember recent interactions and maintain coherent conversations. This attack exploits this property to inject malicious instructions into a conversation, hiding them among otherwise benign client requests and server responses.
Many AI threats involve tricking an agent with a single malicious piece of data such as a deceptive email or document. Our research highlights a more advanced danger, malicious agents.
A straightforward attack on a victim agent might involve a one-time effort to trick it into acting on harmful instructions from a document without seeking confirmation from its user. In contrast, a rogue agent is a far more dynamic threat. It can hold a conversation, adapt its strategy and build a false sense of trust over multiple interactions.
This scenario is especially dangerous because, as a recent study shows, agents are often designed to trust other collaborating agents by default. Agent session smuggling exploits this built-in trust, allowing an attacker to manipulate a victim agent over an entire session.
This research does not reveal any vulnerability in the A2A protocol itself. Rather, the technique exploits the way implicit trust relationships between agents would affect any stateful protocol — meaning any protocol that can memorize recent interactions and carry out multi-turn conversation.
Mitigation requires a layered defense strategy, including:
Human-in-the-loop (HitL) enforcement for critical actions
Remote agent verification (e.g., cryptographically signed AgentCards)
Context-grounding techniques to detect off-topic or injected instructions
Palo Alto Networks customers are better protected through the following products and services:
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.
AI Access Security is designed for visibility and control over usage of third-party GenAI tools, helping prevent sensitive data exposures, unsafe use of risky models and harmful outputs through policy enforcement and user activity monitoring.
Cortex Cloud AI-SPM is designed to provide automatic scanning and classification of AI assets, both commercial and self-managed models, to detect sensitive data and evaluate security posture. Context is determined by AI type, hosting cloud environment, risk status, posture and datasets.
A Unit 42 AI Security Assessment can help you proactively identify the threats most likely to target your AI environment.
An Overview of the A2A Protocol and Comparison With MCP
The A2A protocol is an open standard that facilitates interoperable communication among AI agents, regardless of vendor, architecture or underlying technology. Its core objective is to enable agents to discover, understand and coordinate with one another to solve complex, distributed tasks while preserving autonomy and privacy.
In the A2A protocol:
A local agent runs within the same application or process as the initiating agent, enabling fast, in-memory communication.
A remote agent operates as an independent, network-accessible service. It uses the A2A protocol to create a secure communication channel, allowing it to handle tasks delegated from other systems, or even other organizations, and then return the results.
A2A has notable parallels with the Model Context Protocol (MCP), a widely used standard for connecting large language models (LLMs) to external tools and contextual data. Both aim to standardize how AI systems interact, but they operate on distinct aspects of agentic systems.
MCP functions as a universal adapter, providing structured access to tools and data sources. It primarily supports LLM-to-tool communication through a centralized integration model.
A2A focuses on agent-to-agent interoperability. It enables decentralized, peer-to-peer coordination in which agents can delegate tasks, exchange information and preserve state across collaborative workflows.
In short, MCP emphasizes execution through tool integration, whereas A2A emphasizes orchestration across agents.
Despite these differences, both protocols face similar classes of threats, as shown in Table 1.
Attack/Threats
MCP
A2A
Tool/Agent Description Poisoning
Tool descriptions can be poisoned with malicious instructions that manipulate LLM behavior during tool selection and execution
AgentCard descriptions can embed prompt injections or malicious directives that manipulate the client agent’s behavior when consumed
Rug Pull Attacks
Previously trusted MCP servers can unexpectedly shift to malicious behavior after integration, exploiting established trust relationships
Trusted agents can unexpectedly turn malicious by updating their AgentCards or operation logic
Tool/Agent Shadowing
Malicious servers register tools with identical or similar names to legitimate ones, causing confusion during tool selection
Rogue agents create AgentCards that mimic legitimate agents through similar names, skills or typosquatting techniques
Parameter/Skill Poisoning
Tool parameters can be manipulated to include unintended data (e.g., conversation history) in requests to external servers
AgentCard skills and examples can be crafted to manipulate how agents interact, potentially exposing sensitive context or credentials
Table 1. Comparison of MCP and A2A attacks.
The Agent Session Smuggling Attack
Agent session smuggling is a new attack vector specific to stateful cross-agent communication, such as A2A systems. A communication is stateful if it can remember recent interactions, like a conversation where both parties keep track of the ongoing context.
The core of the attack involves a malicious remote agent that misuses an ongoing session to inject additional instructions between a legitimate client request and the server’s response. These hidden instructions can lead to context poisoning (corrupting the AI's understanding of a conversation), data exfiltration or unauthorized tool execution on the client agent.
Figure 1 outlines the attack sequence:
Step 1: The client agent initiates a new session by sending a normal request to the remote agent.
Step 2: The remote agent begins processing the request. During this active session, it covertly sends extra instructions to the client agent across multiple turn interactions.
Step 3: The remote agent returns the expected response to the original request, completing the transaction.
Figure 1. Agent session smuggling attack flow.
Key properties of the attack
Stateful: The attack leverages the remote agent’s ability to manage long-running tasks and persist session state. This means the agent saves the context of an interaction, much like a person remembers the beginning of a sentence while listening to the end. In this context, stateful means the agent retains and references session-specific information across multiple turns (e.g., conversation history, variables or task progress tied to a session ID) so later messages can depend on earlier context.
Multi-turn interaction: Because of the stateful property, two connected agents can engage in multi-turn conversations. A malicious agent can exploit this to stage progressive, adaptive multi-turn attacks, which have been shown significantly more difficult to defend against in prior research (see, for example, “LLM Defenses Are Not Robust to Multi-Turn Human Jailbreaks Yet” by Nathaniel Li et al. on Scale).
Autonomous and adaptive: Malicious agents that are powered by AI models can dynamically craft instructions based on live context such as client inputs, intermediate responses and user identity.
Undetectable to end users: The injected instructions occur mid-session, making them invisible to end users, who typically only see the final, consolidated response from the client agent.
In principle, any multi-agent system with stateful inter-agent communication could be susceptible to this attack. However, the risk is lower in setups fully contained within a single trust boundary. A trust boundary is an area of the system where all components are trusted by default, such as ADK or LangGraph multi-agent systems, where one administrator controls all participating agents.
Our research therefore focuses on the A2A protocol, which is explicitly designed for cross-boundary interoperability. This interoperability enables agents to collaborate across different systems, modules or organizations.
Compared to known MCP threats, agent session smuggling exploits A2A’s stateful and adaptive design in ways that are not possible in MCP. MCP servers generally operate in a stateless manner, executing isolated tool invocations without preserving session history, which limits actors’ ability to use them to mount multi-turn or evolving attacks.
MCP servers are also typically static and deterministic, since they do not rely on AI models. In contrast, an A2A server can persist state across interactions and leverage model-driven reasoning, allowing a malicious agent to adapt and refine instructions over multiple turns. This combination of persistence and autonomy makes agent session smuggling more stealthy and difficult to defend against than MCP-based attacks.
Proof of Concept Agent Session Smuggling Attacks
To demonstrate the feasibility and potential impact of agent session smuggling, we developed two proof-of-concept (PoC) attack scenarios. The setup consisted of a financial assistant (the client agent) and a research assistant (the malicious remote agent). These PoCs illustrate how a malicious agent can exfiltrate sensitive data and execute unauthorized actions without the end user's awareness.
Sensitive information leakage: Extracting confidential data from the client agent
Unauthorized tool invocation: Convincing the client agent to perform unauthorized actions on behalf of the victim user
Client agent: A financial assistant based on the ADK financial-advisor example. The agent supports tasks such as retrieving financial news, managing portfolios and executing trade operations.
In this scenario, the malicious remote agent (research assistant) aims to exfiltrate the client agent’s (financial assistant’s) internal state, including:
Chat history
System instructions
Available tools
Tool schemas
The attack unfolds subtly. Upon receiving a legitimate request from the financial assistant, the research assistant issues a series of seemingly harmless clarification questions. These follow-up questions gradually trick the financial assistant into disclosing sensitive information that should never leave its environment.
Figure 2 illustrates the user’s interaction flow. The session begins normally. The user asks the financial assistant to retrieve the investment portfolio and profile, followed by a request for a briefing on AI market news.
This market news request is delegated to the research assistant. As shown on the right side of the figure, the research assistant engages in a series of back-and-forth exchanges with the financial assistant. Except for the initial request and the final response, the research assistant injects all intermediate interactions.
The intermediate steps shown in Figure 2 only appear because the developer web user interface (UI) is designed to display every internal action. In a production chatbot UI, these intermediate interactions would likely remain invisible.
Figure 2. Developer web UI. The right side shows internal exchanges between the financial assistant and the research assistant.
Figure 3 provides a more detailed view via the financial assistant’s activity log. Row 10 shows the initial query sent to the research assistant, and Row 28 shows the final result the research agent produces. Rows 11–27, alternating between function_call and function_response, reveal the interactions between the two agents. During the interactions, the financial assistant gradually disclosed its system configuration and the user’s prior conversation history.
Finally, Figure 4 shows the research assistant’s log after the attack. It confirms successful data exfiltration, including the financial assistant’s capabilities, tool schemas and the entire session history.
Figure 4. The research assistant log showing exfiltrated configuration data.
PoC 2: Unauthorized Tool Invocation
In this scenario, the malicious remote agent (research assistant) attempts to trick the client agent (financial assistant) into executing unauthorized trade actions. The attacker’s objective is to misuse the client agent’s buy_stock tool without the end user’s knowledge or consent.
After receiving a valid delegation request, the research assistant sends additional processing requirements, prompting the financial assistant to perform tool invocations unrelated to the user’s original request. This PoC assumes the attacker knows the financial assistant’s tools, having acquired either through public information or the previous PoC.
Figure 5 illustrates the user’s interaction flow. On the right-hand side, the user’s news request is delegated to the research assistant. While the research assistant does provide the expected news summary, it also smuggles hidden instructions that induce the financial assistant to invoke the buy_stock tool. Again, these intermediate actions are executed autonomously and would remain invisible in a typical production chatbot interface, where the user would only be shown the final summarized response.
Figure 5. Developer web UI that shows the communication between the financial assistant and the research assistant, including smuggled instructions.
Figure 6 shows the financial assistant’s activity log. Row 7 shows the initial request sent to the research assistant, and Row 12 shows the legitimate response received. Rows 8–11, however, reveal four additional actions the financial assistant autonomously executed, resulting in an unauthorized trade of 10 shares on behalf of the victim user. This sequence demonstrates how agent session smuggling can escalate from information leakage to high-impact tool execution.
Defending against agent session smuggling requires a layered security approach that validates the identity of agents, the integrity of the conversation and the impact of the actions taken. The following strategies can help mitigate the risks:
Enforce out-of-band confirmation for sensitive actions: The most effective defense is to require HitL approval for any sensitive or high-impact action, but this confirmation must occur out-of-band, through a separate channel the LLM cannot influence. When an agent is instructed to perform a critical task, the orchestration framework should pause the execution. It should then trigger a confirmation prompt in a static, non-generative part of the application UI or through a separate system like a push notification.
Implement context grounding: An agent session smuggling attack relies on derailing a conversation from its original purpose to inject malicious commands. Context grounding is a technical control that algorithmically enforces conversational integrity. When a client agent initiates a session, it should create a task anchor based on the original user request's intent. As the interaction progresses, the client must continuously validate that the remote agent's instructions remain semantically aligned with this anchor. Any significant deviation or introduction of unrelated topics should cause the client agent to flag the interaction as a potential hijacking attempt and terminate the session.
Validate agent identity and capabilities: Secure agent-to-agent communication must be built on a foundation of verifiable trust. Before engaging in a session, agents should be required to present verifiable credentials, such as cryptographically signed AgentCards. This allows each participant to confirm the identity, origin and declared capabilities of the other. While this control does not prevent a trusted agent from being subverted, it eliminates the risk of agent impersonation or spoofing attacks and establishes an auditable, tamper-evident record of all interactions.
Expose client agent activity to users: Smuggled instructions and activities are invisible to end users, since they usually only see the final response from the client agent. The UI can reduce this weak spot by exposing real-time agent activity. For example, surfacing tool invocations, showing live execution logs or providing visual indicators of remote instructions. These signals improve user awareness and increase the chance of catching suspicious activity.
Conclusion
This work introduced agent session smuggling, a new attack technique that targets cross-agent communication in A2A systems. Unlike threats involving malicious tools or end users, a compromised agent represents a more capable adversary. Powered by AI models, a compromised agent can autonomously generate adaptive strategies, exploit session state and escalate its influence across all connected client agents and their users.
Although we have not observed the attack in the wild, its low barrier to execution makes it a realistic risk. An adversary needs only to convince a victim agent to connect to a malicious peer, after which covert instructions can be injected without user visibility. Protecting against this requires a layered defense approach:
HitL approval for sensitive actions
Confirmation logic enforced outside of model prompts
Context-grounding to detect off-topic instructions and cryptographic validation of remote agents
As multi-agent ecosystems expand, their interoperability also opens new attack surfaces. Practitioners should assume that agent-to-agent communication is not inherently trustworthy. We must design orchestration frameworks with layered safeguards to contain the risks of adaptive, AI-powered adversaries.
Palo Alto Networks Protection and Mitigation
Prisma AIRS is designed for real-time protection of AI applications, models, data and agents. It analyzes network traffic and application behavior to detect threats such as prompt injection, denial-of-service attacks and data exfiltration, with inline enforcement at the network and API levels.
AI Access Security is designed for visibility and control over usage of third-party GenAI tools, helping prevent sensitive data exposures, unsafe use of risky models and harmful outputs through policy enforcement and user activity monitoring. Together, Prisma AIRS and AI Access Security help secure the building of enterprise AI applications and external AI interactions.
Cortex Cloud AI-SPM is designed to provide automatic scanning and classification of AI assets, both commercial and self-managed models, to detect sensitive data and evaluate security posture. Context is determined by AI type, hosting cloud environment, risk status, posture and datasets.
A Unit 42 AI Security Assessment can help you proactively identify the threats most likely to target your AI environment.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
We have discovered a new Windows-based malware family we've named Airstalk, which is available in both PowerShell and .NET variants. We assess with medium confidence that a possible nation-state threat actor used this malware in a likely supply chain attack. We have created the threat activity cluster CL-STA-1009 to identify and track any further related activity.
Airstalk misuses the AirWatch API for mobile device management (MDM), which is now called Workspace ONE Unified Endpoint Management. It uses the API to establish a covert command-and-control (C2) channel, primarily through the AirWatch feature to manage custom device attributes and file uploads.
Airstalk has the following functionality:
Employs a multi-threaded C2 communication protocol
Incorporates versioning
Uses a likely stolen certificate to sign some of the samples found
This malware is designed to exfiltrate sensitive browser data, including:
Cookies
Browsing history
Bookmarks
Screenshots
We have also identified other tasks within the samples found that the threat author did not implement.
We have identified two main variants of Airstalk malware, one written in PowerShell, and another written in .NET. The .NET variant of Airstalk has more capabilities than the PowerShell variant and seems to be in a more advanced stage of development.
We call this malware Airstalk because it misuses the MDM API from AirWatch for its C2 communications. Both variants employ the same covert channel for the C2, but the C2 protocols and the targeted browsers differ slightly.
Airstalk PowerShell Variant
PowerShell Covert Channel Implementation
Airstalk uses the devices endpoint (/api/mdm/devices/) of the MDM API from AirWatch for its covert C2 communications with the attacker. These C2 communications use the custom attributes feature of the device within the AirWatch MDM API to store the communication details of the backdoor and use it as a dead drop.
A dead drop is a secret method of communication used to pass items or information between individuals without them connecting directly. Adversaries typically use this technique in espionage, where one person leaves the item in a hidden location and the other retrieves it later.
The malware also leverages another API endpoint (/api/mam/blobs/uploadblob) to upload files for different purposes.
The C2 communication is based on JSON messages through the devices API endpoint, containing at least the following required fields (first schema):
1
2
3
4
5
6
7
8
9
10
11
12
13
{
“Name”:“<CLIENT_UUID>”,
“Value”:“<SERIALIZED_MESSAGE>”,
“Uuid”:“<CLIENT_UUID>”,
“Application”:“services.exe”,
“ApplicationGroup”:“services”
}
CLIENT_UUID: Read through Windows Management Instrumentation (WMI) to contain the real value of the compromised device
SERIALIZED_MESSAGE: Base64-encoded JSON message
The serialized message sent within the Value field, has the following minimum fields (second schema):
1
2
3
4
5
6
7
8
9
{
“method”:“<MESSAGE_TYPE>”,
“uuid”:“<CLIENT_UUID>”,
“sender”;“<SENDER_ROLE>”
}
CLIENT_UUID: Real Universally Unique Identifier (UUID) value of the compromised device
MESSAGE_TYPE: Varies depending on the purpose of the message
SENDER_ROLE: Set to client for all the messages sent from the compromised device toward the API endpoint
The final messages (first schema) are then set as custom attributes through the MDM API to communicate with the attacker.
Figure 1. Covert channel core function from the PowerShell variant of Airstalk.
To read a message back from the attacker, the malware performs the inverse process. It deserializes the message and verifies whether the message comes from the attacker, to avoid reading the message sent by itself, as shown in Figure 2.
Figure 2. C2 response from the Covert channel core function of Airstalk's PowerShell variant.
C2 Protocol
The C2 protocol for Airstalk's PowerShell variant uses different message types for synchronization and execution of specific tasks, based on the stage of the communication.
Table 1 shows the different values that the method field can have.
MESSAGE_TYPE
Purpose
CONNECT
Connection request
CONNECTED
Connection accepted
ACTIONS
Tasks synchronization
RESULT
Tasks results
Table 1. Values of the method field in Airstalk's PowerShell variant C2 communications.
When executed, Airstalk's PowerShell variant initializes the communication with the attacker. To do so, it sends a CONNECT message and blocks the execution through the function Get-Response as shown in Figure 3, waiting for a message from the threat actor.
Figure 3. Connection initialization by Airstalk's PowerShell variant.
The code seems to expect to receive a CONNECTED message. However, the result is the same whatever the message type is, as long as it doesn’t come from the malware (client).
After establishing a connection with the attacker, the malware:
Asks for tasks to execute, sending a message of type ACTIONS
Blocks the execution, waiting for an answer from the attacker with an ACTIONS message type
Returns the ID of the action to conduct, as shown in Figure 4 below
Figure 4. C2 tasks checked by Airstalk's PowerShell variant.
As indicated in Figure 4, this time the execution flow properly filters the message type.
Figure 5 illustrates the execution flow of Airstalk's PowerShell variant.
Figure 5. C2 execution flow of Airstalk's PowerShell variant.
Backdoor Capabilities
Once the C2 communication channel is established, the PowerShell variant of Airstalk can receive different tasks through the action field, as shown below in Table 2.
ACTION_ID
Task
0
Take a screenshot
1
Get all Chrome cookies
2
List all the files within the user’s directory
4
List all the Chrome profiles within the user’s directory
5
Get browser bookmarks of a given Chrome profile
6
Get the browser history of a given Chrome profile
7
Uninstall the backdoor
Table 2. Identifiers and tasks for the action field.
Following the ACTION_ID values in Table 2, we find the value 3 is skipped. That might be a developer decision, a mistake or a way to hide additional capabilities from the backdoor by removing the implementation of tasks. This removal is a simple but effective way to use it as a modular backdoor.
After executing a task, the malware sends the result of the task with the function UploadResult, specifying the ACTION_ID of the task executed and its returned value as noted in Figure 6.
Figure 6. Send the task result back to the C2 channel.
Some tasks require sending back a large amount of data or files after Airstalk is executed. To do so, the malware uses the blobs feature of the AirWatch MDM API to upload the content as a new blob. Figure 7 shows how this is implemented in the script of Airstalk's PowerShell variant.
Figure 7. File upload function in Airstalk's PowerShell variant.
An example of this behavior is taking a screenshot of the infected host, which Figure 8 below shows.
Figure 8. Screenshot function leveraging the UploadResult functionality.
The function to dump cookies from Chrome enables remote debugging in the browser and restarts it with parameters to load the targeted Chrome profile. These parameters also send the command to dump all the cookies and save them to a file that is later exfiltrated through the covert channel shown below in Figure 9.
Figure 9. Exfiltration of Chrome Cookies.
As previously reported by Red Canary, cookie theft via Chrome remote debugging is not novel functionality and is already built into a number of information stealers such as Lumma and StealC. However, these information stealers are unlikely to successfully run in a well-protected environment. Bundling the functionality into a trusted systems management tool allows execution without raising suspicion.
Airstalk .NET Variant
During our investigation of this malware, we identified a set of samples representing a .NET variant of Airstalk. Compared to the PowerShell variant, the .NET variant has slight differences in its covert C2 channel protocol and has more capabilities. The .NET variant also appears to be in a more advanced stage of development than the PowerShell variant.
While the sample we found of Airstalk's PowerShell found only targets Google Chrome, Airstalk's .NET variant also targets two additional web browsers:
Microsoft Edge
Island Browser
The .NET variant tries to mimic a legacy application, by using code signing and specific metadata attributes. Figure 10 notes an example of this.
Figure 10. Exif metadata from Airstalk's .NET variant is natively set through .NET assemblies.
.NET Covert Channel Implementation
Compared to the PowerShell variant, Airstalk's .NET variant includes an additional suffix to the UUID field within the JSON message (first schema) in its covert C2 communication, as noted in Figure 11.
Figure 11. Covert channel code function in Airstalk's .NET variant.
The Airstalk .NET variant has three different delivery types for its C2 communications as Table 3 notes.
Delivery type
Suffix
Description
DEBUG
-kd
Used to send debugging data
RESULT
-kr
Used to check tasks and send task results
BASE
-kb
Used for connection establishment and beaconing
Table 3. Different delivery types in C2 communications for the .NET variant of Airstalk.
C2 Protocol
Compared to the PowerShell variant, Airstalk's .NET variant has small differences in the message types for its C2 protocol. Table 4 lists the extra types (methods) used by the .NET variant.
MESSAGE_TYPE
Purpose
PowerShell Variant
.NET Variant
CONNECT
Connection request
Yes
Yes
CONNECTED
Connection accepted
Yes
Yes
ACTIONS
Tasks flow
Yes
Yes
RESULT
Tasks results
Yes
Yes
MISMATCH
Version mismatch error
No
Yes
DEBUG
Debug messages
No
Yes
PING
Beaconing
No
Yes
Table 4. Communication methods for Airstalk's .NET variant C2 protocol.
Compared to its PowerShell variant, Airstalk's .NET variant has a different execution flow. The .NET variant uses three different execution threads, one for each specific purpose:
Managing C2 tasks
Exfiltrating the debug log
Beaconing to the C2
Figure 12. Code illustrating the main execution flow for C2 communications in Airstalk's .NET variant.
As Figure 12 above notes, these variants have a beaconing behavior, a debugging thread and a log file that it sends back to the attacker. This is sent through the covert channel every 10 minutes, according to the Debug function that Figure 13 shows.
Figure 13. Debug function periodically uploads the log.
Figure 14 shows the full list of tasks supported by the .NET variant.
Figure 14. List of supported tasks for C2 communications in Airstalk's .NET variant.
Although the .NET variant's task names are defined similarly to the PowerShell variant tasks, not all the tasks are implemented. Additionally, the task IDs in the .NET variant differ from the PowerShell variant. This indicates an evolution of the .NET variant of Airstalk from what we see in the PowerShell variant. In the .NET variant, some tasks look similar to the PowerShell variant, but a closer examination reveals they are more complex as compounds of smaller tasks.
Table 5 below describes the capabilities and implementations of the functions shown earlier in Figure 14.
Name
ID
Implemented
Description
Screenshot
0
Yes
Takes a screenshot
UpdateChrome
1
Yes
Exfiltrates the specified Chrome profile
FileMap
2
Yes
Lists the content of the specified directory
RunUtility
3
No
N/A
EnterpriseChromeProfiles
4
Yes
Retrieves the available Chrome profiles
UploadFile
5
Yes
Exfiltrates specific Chrome artifacts and credentials
OpenURL
6
Yes
Opens a new URL in Chrome
Uninstall
7
Yes
Finishes the execution
EnterpriseChromeBookmarks
8
Yes
Gets the Chrome bookmarks from the specified user
EnterpriseIslandProfiles
9
Yes
Retrieves the available Island profiles
UpdateIsland
10
Yes
Exfiltrates the specified Island profile
ExfilAlreadyOpenChrome
11
Yes
Dumps all the Cookies from the current Chrome profile
Table 5. Tasks for C2 functions in Airstalk's .NET variant.
Versioning
Airstalk's PowerShell variant does not have a version variable, but the .NET variant has a variable specifying the malware version. We found samples of the Airstalk .NET variant using versions 13 and 14.
Persistence
The PowerShell variant uses a scheduled task for persistence that it removes when executing the Uninstall task shown in Figure 15.
However, Airstalk's .NET variant does not have a persistence mechanism. The .NET variant finishes its process execution and sets a flag in the custom attributes API endpoint as shown in Figure 16.
Table 6. Information on testing PE binaries for Airstalk's .NET variant.
Although the threat actor behind CL-STA-1009 modified the timestamps from later Airstalk .NET variant binaries, we can establish a development timeline by using the signed timestamps, as shown below in Table 7.
Table 7. Development timeline based on the signed timestamps.
Attribution and the Supply Chain
Based on our internal assessment, we assess with medium confidence that a nation-state threat actor used Airstalk malware in a supply chain attack. We are tracking the identified activity as an activity cluster that we named CL-STA-1009.
We’ve followed a number of supply chain attacks over the past few years. Supply chain attacks target the goods and services organizations rely upon to perform their day-to-day activities. The supply chain includes hardware that comprises an organization’s infrastructure, cloud-based services trusted to manage an organization’s most sensitive data, and specialized staff augmentation.
This last category, typically named business process outsourcing (BPO), creates the potential for extensive damage when targeted by attackers. Hardware and software can be monitored, controlled and provisioned. However, human assets — particularly highly specialized ones — must often be granted extensive access to critical business systems. Additionally, they are often working from equipment managed by their own organizations. Because they are managed by the BPO, this effectively places them out of reach of the majority of your organization’s security controls.
Organizations specializing in BPO have become lucrative targets for both criminal and nation-state attackers. We’ve seen a notable increase of attacks on BPOs as the source of intrusion in incidents we've seen over the past few years.
BPOs typically leverage the economy of scale to have highly specialized talent service multiple clients concurrently. While this can generate significant savings for both the BPO and its clients, it has the drawback of allowing the BPO to act as a gateway into multiple targets. Attackers are willing to invest generously in the resources necessary to not only compromise them but maintain access indefinitely.
Conclusion
CL-STA-1009 is a threat activity cluster representing activity from a suspected nation-state actor. This cluster is associated with Airstalk malware, which we assess with medium confidence adversaries used in supply chain attacks.
The .NET variant represents an evolution of the malware, featuring a multi-threaded C2 protocol, versioning, beaconing and more complex, compound tasks. This malware employs defense evasion techniques, including using signed binaries with a revoked certificate that appears to have been issued to a legitimate organization in 2024. These evasion techniques also include the manipulation of PE timestamps, although signing timestamps help establish a timeline of activity. The malware's capabilities and adaptive nature highlight the persistent threat posed by the threat actor behind CL-STA-1009.
The evasion techniques employed by this malware allow it to remain undetected in most environments. This is particularly true if the malware is running within a third-party vendor’s environment. This is particularly disastrous for organizations that use BPO because stolen browser session cookies could allow access to a large number of their clients. Stolen screenshots and logged keystrokes can reveal sensitive and proprietary information not only for the victim, but the victim's customers as well.
Long-term monitoring allows a determined attacker to understand how the business operates and how the BPO organization typically interacts with its customers, making it less likely that follow-on intrusions would be detected. The key to identifying and protecting organizations from these types of attacks is to expand security focus from typical indicators and access control to understanding how users typically work, both internally and externally.
However, the differences in patterns between how an attacker behaves and how your users typically behave will eventually reveal them if you know what to watch for. These differences are what you must identify and act on using behavioral monitoring tools tuned to spot subtle anomalies.
Palo Alto Networks customers are better protected from Airstalk malware through the following products:
The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research.
Cortex XDR and XSIAM help prevent malware 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 help prevent both known and unknown malware from causing harm to endpoints.
Prisma Browser helps protect against attacks like Airstalk in several ways:
First, it detects and blocks malicious file downloads through the built-in Advanced WildFire threat detection engine.
Second, its layered protection model isolates all browser data and files from the underlying endpoint, preventing local malware from accessing cookies, history or credentials.
Finally, Prisma Browser continuously validates device posture, ensuring that the right EDR is installed, active and healthy before allowing access to sensitive applications.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
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.
When Honest Businesses Meet the Dark Side of Search
Meet Sarah, an artisanal baker who opens Sarah’s Sourdough. To improve her search engine optimization (SEO), she builds a beautiful website and shares authentic baking content. By writing blog posts, earning local backlinks and telling her story, Sarah practices ethical SEO to help search engines understand her value. Soon, when users search “fresh sourdough near me,” her shop ranks at the top. This is how search is meant to work – connecting real people with real solutions.
Understanding Malicious SEO and Its Growing Impact in the Age of AI
Suddenly, Sarah’s thriving bakery site is buried beneath spammy imitators like BestBreadsNow[.]info — ad-filled pages with no real business, just tricks to climb the search ranks. These sites use malicious SEO. This consists of manipulative tactics designed to game algorithms, such as:
Keyword stuffing (cramming pages with repetitive terms)
Purchased backlinks (paying unrelated sites to link back)
Fake content
What was once a niche problem is now a multi-million-dollar shadow economy. Entire ecosystems exist to exploit search engines, including:
Cloaking tools that show fake content to search engines
Content farms mass-producing shallow articles
Underground sellers who fabricate popularity and traffic
And now, AI is accelerating it all. With the click of a button, bad actors can generate tens of thousands of spam articles, spin up fake social accounts to build backlinks, and deploy AI-tailored cloaking that deceives algorithms while staying invisible to users.
Sarah isn’t just competing with bad actors anymore. She’s competing with an AI-powered content machine built to drown out authenticity with algorithm-friendly noise.
Next-Generation Defenses Against AI-Powered SEO Misuse
To counter the rise of AI-boosted malicious SEO, search engines and content platforms must adopt intelligent, proactive defenses beyond simple spam filters or manual moderation. Key strategies include:
AI to Detect AI Manipulation
Search engines need models trained to detect:
AI-generated text patterns, like repetitive phrasing, lack of nuance and burst-publishing behavior.
Fake engagement, such as bot-generated comments, identical posts across fake profiles and unnatural link velocity.
Modern SEO misuse happens at scale across entire ecosystems of fake domains and botnets. Defense systems must:
Identify link farms via graph analysis of backlink structures
Detect coordinated bot activity by analyzing IP reuse, timing patterns and shared hosting metadata
Compare crawler vs. user views to detect cloaking behavior
Proactive Ecosystem-Wide Monitoring
This gives defenders visibility into the infrastructure behind spam, not just its symptoms. By integrating threat intelligence and pre-release stress testing, defenders can block attacks before they scale.
The Future of SEO: A Strategic Battle Between AI-Driven Threats and Ethical Defense
AI-driven malicious SEO is already reshaping how visibility, trust and reputation are won or lost online. Non-LLM-focused defenses will be outpaced, outnumbered and outsmarted.
The only viable path forward is a proactive one. Search engines, content platforms and threat intelligence teams must shift from reacting to anticipating, using AI not only as a shield but as a strategic advantage. AI empowered this new class of threat, and only its intelligent and responsible use can defeat it.
Malicious versus ethical SEO is not just a fight for rankings. It’s a fight for the credibility of information, for the viability of legitimate businesses and for the soul of the open web. The best time to prepare for this fight starts now.
AzureHound is a data collection tool intended for penetration testing that is part of the BloodHound suite. Threat actors misuse this tool to enumerate Azure resources and map potential attack paths, enabling further malicious operations. Here, we help defenders understand the tool and protect against illegitimate use of it.
This look into AzureHound will discuss its capabilities and common usage, and map its tool usage to the MITRE ATT&CK framework. Focusing on relevant ATT&CK techniques, we provide examples of tool execution and highlight how the activity appears in Azure log sources as well as in Cortex XDR.
Tools like AzureHound allow threat actors to operate quickly and efficiently in cloud environments. Threat actors operating these tools often leave detectable evidence for defenders who know where to look. This article provides actionable intelligence for tuning detections, improving incident response processes, conducting threat hunting and managing a security function.
Palo Alto Networks customers are better protected from the threats described here through the following products and services:
AzureHound is an open-source data collection tool written in the Go programming language. It is available precompiled for Windows, Linux and macOS.
This tool collects data using the Microsoft Graph and Azure REST Application Programming Interfaces (APIs). It is designed to enumerate an Entra ID and Azure environment and gather information about identities and various other resources. The goal of this enumeration is to use the collected data to identify potential attack paths to privilege escalation within the target Azure environment.
AzureHound can send its output to JSON files, which BloodHound can then ingest. BloodHound is a visualization tool designed to graphically reveal hidden relationships and identify attack paths within an Entra ID, Azure or Active Directory (AD) environment.
Operating at the infrastructure layer, the Azure REST API provides access to Azure Resource Manager (ARM), the control plane for all Azure resources like storage, virtual machines and networks.
AzureHound does not need to be run from within the victim environment. This is because both the Microsoft Graph and Azure REST APIs are available externally.
Threat Actor Usage of AzureHound
AzureHound is intended to be used by security professionals — like defenders and red teams — to proactively find and fix cloud vulnerabilities. However, threat actors can also use it for discovery, after gaining access to a victim's Azure environment.
Threat actors use AzureHound to automate complex discovery procedures in Azure environments. This helps them discover user hierarchies and identify high-value targets.
Collecting internal Azure information helps threat actors uncover misconfigurations and indirect privilege escalation opportunities that might not be obvious without this full view of the target Azure environment.
Threat actors also run the tool after obtaining initial access to the victim environment, downloading and running AzureHound on assets to which they have gained access.
As recently as August 2025, threat actor activity with this tool highlights a continued focus on cloud environments as a critical attack surface. Publicly available research identifies AzureHound as part of several post-compromise operations:
Unit 42 tracks the Iranian-backed group Curious Serpens (aka Peach Sandstorm), which has been active since at least 2013. The group has evolved to misuse Azure cloud environments in its attack chain, including using AzureHound to conduct internal discovery of the target's Microsoft Entra ID environment.
In May 2025, Microsoft reported on a suspected nation-state threat actor it named Void Blizzard leveraging AzureHound during the discovery phase of their attacks to enumerate Entra ID configurations.
In August 2025, Microsoft reported a campaign by a ransomware operator they identified as Storm-0501. Operating on-premises in a hybrid, multi-tenant Azure environment, the threat actor used AzureHound to enumerate the target's Entra ID tenants.
MITRE Tactic Discovery
The MITRE ATT&CK framework is a security practitioner and community-driven knowledge base of threat actor behaviors that describes the tactics, techniques and procedures (TTPs) of cyberattacks. The framework provides a common vocabulary for sharing intelligence and research. It aids in the structured analysis of cyberattacks and tracking of trends in threat actors’ activity.
Discovery within the MITRE ATT&CK framework refers to techniques that threat actors use to learn about their target environment after gaining initial access. MITRE ATT&CK recognizes that cloud techniques and procedures differ from their endpoint counterparts and identifies this cloud-focused subset of the Enterprise Matrix as the Cloud Matrix. We will focus on discovery techniques from the Cloud Matrix.
In Azure, discovery involves gathering details on the following:
Users
Groups
Service principals
Roles
Devices
Storage accounts
Applications
Permissions
Threat actors seek to understand the resources and relationships within the Azure environment to facilitate their attack.
AzureHound accelerates this process by giving threat actors an efficient means to collect data, which they then use to map potential attack paths against the target Azure environment. These attack paths include:
Privilege escalation opportunities
Lateral movement paths
Relationships of high-value accounts such as Global Administrators or other privileged roles
MITRE Discovery Techniques
From the perspective of a threat actor using AzureHound, each discovery technique represents a step in building a comprehensive understanding of a target's cloud environment.
To understand a command-line tool like AzureHound, users typically reference online documentation as well as output from the tool's -h, --help or other usage parameter. Compared to the online documentation, a full listing via the list -h parameter in the 2.6.0 version of AzureHound reveals additional discovery options that are useful in the context of analyzing potential malicious usage. This includes some commands of particular interest to a threat actor such as:
function-apps
function-app-role-assignments
storage-accounts
storage-containers
subscription-user-access-admins
web-apps
The commands above give threat actors baseline information about services commonly exploited in cloud environments. The commands detailed in this analysis are based on the direct output from the tool.
T1087.004: Account Discovery: Cloud
To establish a foundational understanding of the target environment, a threat actor might first locate the identities operating within it. This initial enumeration provides a roster of potential targets for credential theft or impersonation. The tool automates the collection of all identities, including users, devices and service principals, along with their ownership relationships. This provides a detailed picture of the identities present in the tenant.
AzureHound parameters that facilitate the MITRE technique Account Discovery: Cloud Account include the following:
list users
list devices
list device-owners
list service-principals
list service-principal-owners
AzureHound supports multiple means of authentication, including:
Threat actors will use whatever means of authentication is available. They can combine a stolen username and password with multi-factor authentication (MFA) fatigue to affect a successful login. Alternatively, they may login with a stolen token. Infostealers such as Raccoon Stealer or Redline can extract cookies, credentials and session tokens from a user's browser. Researchers from Flare found that session tokens acquired from infostealers have exposed tokens from Azure.
As displayed by the list users request within Figure 1, the output of AzureHound command-line discovery can reveal information of interest to a threat actor. This example invocation of the command lists all Entra ID users and sends the output to a file called users.json.
Figure 1. Execution of AzureHound to enumerate users.
The following data is among the fields returned by default for each user if available in the Entra ID User record:
displayName
jobTitle
lastPasswordChangeDateTime
mail
userPrincipalName
userType
tenantId
tenantName
Figure 2 shows a screen capture of the raw output from AzureHound with some of the fields listed above.
Figure 2. AzureHound list users raw output.
This data helps threat actors target key users in the target organization for successive stages in the attack. For example, a threat actor could dump all users to a JSON file and search it for job titles that indicate high-value targets including those containing words like:
Administrator
Application
Identity
Cloud
These targets are considered high value because these job roles would have elevated privileges within the Azure tenant.
T1069.003: Permission Groups Discovery: Cloud Groups
Once threat actors know the identities within the target environment, they need to understand the relationships between the identities by discovering permission structures.
This technique focuses on mapping out administrative roles and group memberships to find exploitable privilege escalation paths. This is achieved by collecting not just the groups and roles themselves, but the web of specific role assignments that connect identities to resources, revealing who has access to what.
What data the options above return depends on the identity AzureHound uses to authenticate. AzureHound gathers information based on the permissions granted to the account under which it runs within Azure. These accounts can only enumerate policy definitions and assignments if they have roles like Reader or higher at the subscription or resource group level.
Figure 3 shows the result of a command to enumerate Groups within a tenant.
Figure 3. Execution of AzureHound to enumerate groups.
Threat actors enumerate Entra ID groups, roles and role assignments because they collectively define how access and permissions are distributed across users, applications and resources. Threat actors can identify highly privileged roles, such as Global Administrator or Privileged Role Administrator and determine which users or service principals are assigned to them. This information can also reveal privileged escalation paths through nested group memberships.
Role assignments can reveal excessive or misconfigured permissions. This information helps threat actors discover opportunities for privilege escalation, lateral movement and additional data collection.
AzureHound integrates with BloodHound to create graphs that visually map potential privilege escalation and architectural blueprint. It does so using a massive amount of raw data such as lists of users, groups, apps, subscriptions and their permissions.
Manually connecting these dots is slow and prone to error. As such, the BloodHound GUI becomes a useful analytical tool for threat actors.
By importing the collected data, the tool transforms lines of text into a living map of important relationships. This information about highly privileged users gives the threat actor a list of users to target for credential theft. Figure 4 shows users who have the Global Administrator role either directly assigned, or inherited through group membership.
Figure 4. BloodHound paths to Global Administrator.
For confidentiality, we have hidden or obscured labels for users and groups as well as tenant information.
T1619: Cloud Storage Object Discovery
A primary objective for many threat actors is data exfiltration, making it critical to identify where data is stored. This technique involves discovering cloud storage resources. A threat actor can use AzureHound to specifically target and enumerate Azure storage accounts and the blob containers within them, revealing the locations of potentially sensitive data.
AzureHound has two options for storage object discovery, covering both Azure storage accounts and containers:
list storage-accounts
list storage-containers
Figure 5 shows an example of storage account discovery via AzureHound, enumerating all storage accounts that the identity passed into the command has access to.
Figure 5. Execution of AzureHound to enumerate storage accounts.
The output from the list storage-account command can reveal important information about the storage account configuration. The output comprises the entire storage account resource definition including:
Within this data, the name of the storage account is very important and tied to its service endpoints, which are publicly resolvable DNS names used to connect to the storage account. For example, a storage account blob container by default uses the storage account, container and blob names to define the service endpoint as follows:
Storage accounts can also be tied to custom domain names, which would be in the output's customDomain key-value pair. Please refer to Microsoft's storage account overview for more information on custom domains and other details.
Threat actors seek to access the data in storage accounts for data exfiltration. However, these service endpoints can be secured by network ACLs on the storage account firewall. This information provides the threat actor an understanding of network allowlists and denylists comprising the firewall configuration.
Figure 6 shows that the storage account service has a default deny policy, allowing access only from two /24 network ranges and trusted Azure services like Azure Monitor, Backup and File Sync.
Figure 6. Storage account network ACLs.
Trusted services in Azure refers to a predefined list of Microsoft-owned services that are, by default, granted permissions and access to other Azure resources, bypassing standard network ACLs. Microsoft manages the list and it’s specific to the resource type (e.g., storage blobs, key vaults).
T1526: Cloud Service Discovery
Beyond storage and identities, an actor will seek to understand what platform services are in use, as these can present unique paths for attack. By enumerating services like Web Apps, Function Apps and Kubernetes clusters (AKS), a threat actor can identify application platforms that may be misconfigured or vulnerable. This provides the threat actor with a menu of potential high-level service targets.
With a list of applications, the threat actor’s search expands to the underlying resources. This allows them to map out automation pipelines, Kubernetes clusters and container registries for the cloud's crown jewels. A single misconfigured automation account could allow for the execution of the attacker's own code with high privileges.
This search also involves testing for publicly exposed container registries, pulling images for offline analysis to hunt for hard-coded credentials, API keys or vulnerable libraries. It could also uncover abandoned resources, providing new and powerful attack strategies.
For example, once a threat actor discovers a forgotten test automation pipeline, they can exploit its powerful identity and rights over a resource group. The attacker could then use this trusted identity to inject malicious code into the automation's runbook, waiting for a cloud pipeline to trigger, then executing their malicious code with those elevated permissions.
To fully grasp the architecture of the target environment, a threat actor must discover the foundational infrastructure components. This technique involves enumerating core resources and the management constructs that contain them.
A threat actor can build a complete architectural map of the cloud deployment by listing the following:
Virtual machines
Key vaults
The hierarchy of tenants, subscriptions and resource groups
Similar to the BloodHound user mapping previously shown, this use case shows how attackers visually examine infrastructure elements with BloodHound. Figure 7 displays these key vault findings. We have hidden or obscured labels and tenant information for confidentiality.
Figure 7. BloodHound illustration of available key vaults.
Instead of scrolling through output, the threat actor now has a complete, bird's eye view of key vaults in the tenant infrastructure. They can visually navigate the hierarchy from the tenant down to individual resources.
For example, in addition to key vaults, attackers can click on a node representing the Production subscription. They could then select virtual machines from the Descendent Objects list and instantly see all the virtual machines connected to it.
Defender Perspective
AzureHound relies on Microsoft Graph and Azure REST APIs to enumerate users, roles and permissions. This means that effective defense requires a layered approach that combines access control, endpoint security and visibility into the API activity. The goal is to make it significantly harder for threat actors to authenticate, execute and operate undetected in an organization's environment.
Mitigations
From a defender perspective, secure configurations are essential. As noted above in our discussion of MITRE discovery techniques, AzureHound can be used to obtain information about Azure users and resources within a specific tenant via publicly documented APIs. These API requests may also uncover security vulnerabilities within a tenant. By design, this information is accessible on a per-tenant basis to users with an Entra ID account with Read privileges in that tenant.
To bolster the security of your Azure account, we recommend customers follow Microsoft best practices. In addition, to help prevent the unauthorized access necessary for this technique to be successful, we recommend Admins implement additional security measures.
In addition to Microsoft's recommended best practices and additional security steps, the following mitigations can help further secure your organization. Some of these intersect with the best practices, and some are complementary controls or policy considerations that can be implemented to further harden your environment.
The first line of defense is strong identity and access control, which controls what a user, group or service principal can do. Organizations should implement phishing-resistant MFA for all accounts, especially those with access to sensitive data or administrative roles. Users performing highly privileged tasks, such as Global Administrators or Privileged Role Administrators, should maintain separate accounts for those duties.
Privileged Identity Management (PIM) solutions, such as Microsoft Entra ID PIM or broader Privileged Access Management (PAM) platforms, enable organizations to manage, control and monitor access to privileged identities. These solutions help prevent a compromise of standard user credentials from granting a threat actor elevated access.
In addition to identity and access control, Conditional Access Policies (CAPs) help mitigate exposure to AzureHound by restricting user and application access. CAPs are part of Entra ID and are enforced during authentication. They work by enforcing CAP-defined requirements including MFA, device compliance, trusted locations and client application restrictions. Because of this, CAPs can block AzureHound from accessing Microsoft Graph and Azure management APIs, even if an attacker has obtained valid credentials.
Another effective measure is token binding, which ensures that authentication tokens are tied to a specific device. This feature is known as Token Protection in Entra ID and moved to general availability in August 2025.
As discussed above, Void Blizzard has used stolen authentication tokens. These tokens can be used to authenticate to the target environment, including by AzureHound to the Microsoft Graph API. Token binding can help mitigate token theft attacks by making the stolen token invalid from a different device.
Additionally, secure browsers can provide similar protection by shielding access to private or privileged applications and ensuring that tokens issued are valid only from the secure browser. This renders the tokens invalid from the command line, for tools such as AzureHound.
In addition to identity controls, visibility at the endpoint level remains essential in detecting and preventing AzureHound and other threats. Ensure that endpoint detection and response (EDR/XDR) tooling is deployed across all assets, including to cloud workloads such as cloud detection and response (CDR).
The 2025 Unit 42 Global Incident Response Report discusses how threat actors target unmanaged assets. These assets are those defined as not having endpoint detection and response tools (EDR/XDR/CDR), with a reduced chance of threats being discovered.
It is also vital that organizations use a combination of cloud security posture management (CSPM) and CDR tools to detect attackers creating new compute instances (i.e., virtual machines, containers or serverless functions). This also helps ensure that cloud endpoint agents are properly installed and configured to maintain monitoring capabilities over newly created compute instances. Closing visibility gaps drastically reduces the threat actor's ability to evade detection.
AzureHound reveals which identities can register applications within the Azure tenant, so controlling app registrations is another effective mitigation against AzureHound. Threat actors often take advantage of default settings that allow users to register applications and grant themselves elevated permissions. This in turn can enable broad directory visibility without interactive logins or MFA.
Disabling user-initiated app registrations and requiring an admin consent workflow reduces the chances of a threat actor creating malicious service principals or bypassing MFA through tokenized app-based authentication.
Logging Considerations
Microsoft Graph activity logs have been available in preview since October 2023 and reached general availability in April 2024. This important capability allows defenders to monitor HTTP requests to the Graph service and detect suspicious enumeration patterns.
By default, Microsoft Graph activity logs are not enabled. Defenders should configure Microsoft Entra ID to export Microsoft Graph activity logs to destinations such as Azure Event Hubs. This allows integration with security information and event management (SIEM) solutions as well as EDR, XDR and CDR tools. These logs capture granular details of the API calls that have passed through the Graph API, including the endpoints targeted by tools like AzureHound.
Some AzureHound requests call the Azure REST API at the management.azure[.]com ARM endpoint. These requests to the ARM provider are logged differently than Graph API calls and present visibility challenges.
Activity logs collect subscription-level events from the ARM provider such as creating a new resource or deleting a storage account, which are events not associated with AzureHound requests. The read and list operations (REST GET calls) AzureHound invokes are not recorded in activity logs.
While diagnostic settings can be explicitly enabled for various resource types to capture resource provider level logging, this will only log service endpoint read operations at the data plane level (e.g., mystorage.blob.core.windows[.]net, or myvault.vault.azure[.]net). This does not occur at the control plane level where requests to the ARM provider take place. As a result, AzureHound enumeration calls to the Azure REST API, such as listing storage accounts (azurehound list storage-accounts) or key vaults (azurehound list key-vaults), will not appear in activity or resource logs.
The AzureHound GitHub repository provides additional context and information on which API an AzureHound command uses, and consequently which log to look in for the events.
For example, details on the azurehound list storage-accounts command discussed above can be found in the AzureHound API client code for storage accounts. Figure 8 illustrates AzureHound client code using the Azure REST API for storage account enumeration.
Figure 9. AzureHound role enumeration source code.
AzureHound list commands that go through the Azure REST API ARM endpoint and thus may not be visible in logs include the following:
automation-accounts
container-registries
function-apps
key-vaults
logic-apps
managed-clusters
management-groups
resource-groups
storage-accounts
storage-containers
virtual-machines
vm-scale-sets
web-apps
This logging weak spot reveals unexpected behavior of AzureHound. All azurehound list commands are preceded by AzureHound test calls to the endpoints and APIs the tool uses. The endpoints and APIs called differ depending on the Azure environment (e.g., global Azure Cloud, U.S. government, China).
The global Azure Cloud environment uses the following authentication and API endpoints:
Microsoft identity platform endpoint: login.microsoftonline[.]com
Microsoft Graph API: graph.microsoft[.]com
Azure REST API ARM endpoint: management.azure[.]com
Figure 10 shows an extract from the verbose output of AzureHound execution for these test calls.
Figure 10. AzureHound API test requests.
The AzureHound call to the Microsoft identity platform endpoint login.microsoftonline[.]com is recorded in the Entra ID non-interactive sign-in logs. If Graph API logging is enabled as described earlier, the test call to the Microsoft Graph API (hxxps[:]//graph.microsoft[.]com/v1.0/organization) will be visible in the Microsoft Graph activity logs. Due to the logging limitations mentioned above, the test call to the Azure REST API at management.azure[.]com is not logged.
Table 1 below shows information from the logs for a list storage-accounts request given at 10:57 P.M. and a request for list groups given at 11:25 P.M. Recall that storage account enumeration uses the Azure REST API.
AzureHound Command Line
AzureHound API Calls
Logged Time
Logged RequestURI
Logged User-Agent
list storage-accounts
AzureHound test call to the Graph API to determine reachability[1]
8/1/2025, 10:57:35.185 PM
hxxps[:]//graph.microsoft[.]com/v1.0/organization
azurehound/v2.6.0
Call to Azure REST API to enumerate storage account data.
Call to REST API at management.azure[.]com/[...]Microsoft.Storage/storageAccounts/list is not logged
list groups
AzureHound test call to the Graph API to determine reachability[1]
8/1/2025, 11:25:45.561 PM
hxxps[:]//graph.microsoft[.]com/v1.0/organization
azurehound/v2.6.0
Call to Microsoft Graph API to enumerate group data.
[1]Although we only include the Graph API test call in the table, all three test calls mentioned above are invoked each time.
Table 1. Microsoft Graph API vs. Azure REST API request logging.
The data shows that while the list groups command logs the read operation for the group enumeration (Graph API: hxxps[:]//graph.microsoft[.]com/v1.0/groups?[...]), the list storage-accounts request has no associated RequestURI logged for the read operation of the storage accounts (Azure REST API: Microsoft.Storage/storageAccounts/list). This is the REST API logging weak spot that we previously referred to. However, we can match these test calls to information in other logs to gain more visibility into this activity.
For AzureHound list commands using the Azure REST API, the initial /organization Graph API request used to test the connection is logged. It can be used to correlate events by matching fields such as session ID, IP address, user ID and user-agent against other log activity in Microsoft Graph activity logs and Entra ID sign-in logs.
In addition to Microsoft Graph API and Azure REST API activity and resource logs, Entra ID sign-in logs and audit logs can provide additional context.
As the name implies, Entra ID sign-in logs record successful and failed sign-ins, but these logs also record the following:
CAP policy evaluation
Token issuance for API calls
User-agent and device
MFA details
The information contained in these logs can help identify suspicious login patterns such as:
Unusual geography
Impossible travel
Sign-in to resources Microsoft Graph and Azure management APIs in quick succession
Accounts signing in without MFA
Entra Audit logs track directory-level configuration changes in Microsoft Entra ID including:
User and group modification (create, delete, update)
Role assignments and removals
App registration and service principal modification
Application consent
Conditional Access policy changes
PIM role activations and deactivations
As such, audit logs are not very useful for directly detecting AzureHound activity. However, they are useful for finding follow-on activity after a threat actor has escalated privileges, such as the threat actor creating a new user for persistence and assigning it privileged roles.
It is also worth noting that in July 2025, Defender XDR introduced a new Advanced Hunting table, GraphApiAuditEvents, in public preview. This is a leaner version of Microsoft Graph Activity Logs that provides visibility into Entra ID Graph API calls without extra ingestion or storage costs. Its schema is simplified, including key fields like RequestURI and token identifiers. However, it lacks the UserAgent field and is limited to a default 30 days of data retention.
We will discuss in the next section how we use this information to hunt in Cortex XDR or XSIAM for related threat actor activity.
Threat Hunting
While Cortex Cloud includes various detections for Azure cloud discovery activity, an incident responder or threat hunter can also use Cortex XQL queries to drill down into the data for more detail on individual events. At the most basic level, this can be done by querying the Cortex cloud_audit_logs dataset for requests where the user agent contains an AzureHound identifier (default: azurehound/<version>).
Industry observations indicate that in many cases, threat actors operate tools using default configurations, including user-agent strings, providing an easy parameter for an initial hunt query.
1
2
3
dataset=cloud_audit_logs
|filter lowercase(user_agent)contains"azurehound"
Optionally, a filter for the API operation can be set to filter results for that respective operation. The following example searches for AzureHound activity (azurehound list users) that is querying the Microsoft Graph API for a list of Entra ID users.
Cortex ingests log data from Azure. The activity in Azure is surfaced through Microsoft Entra ID Microsoft Graph activity log and tied to its audit and sign-in monitoring capabilities. This provides visibility into HTTP requests made to the Microsoft Graph API within a tenant.
Figure 11 below shows a sample raw activity log entry representing an AzureHound list users request that has been sanitized for anonymity. Defenders can use many of the fields to create additional queries fitting the situation they are investigating. For example, filtering for a specific signInActivityId or callerIpAddress.
Figure 11. Raw Azure activity log extract for AzureHound list users.
There are several other useful elements from the log extract:
The user-agent string indicates that AzureHound was most likely used to make this request.
The Request URI field indicates AzureHound is pulling user data via GET /users with a large attribute set (accountEnabled, createdDateTime, displayName, mail, userPrincipalName, etc.). This is consistent with discovery and privilege escalation mapping.
In the App ID field, the value 1950a258-227b-4e31-a9cf-717495945fc2 is the Microsoft Azure PowerShell client ID. This is worth noting as PowerShell is often used by offensive tools and by threat actors.
And finally, the UserPrincipalObjectID (454b1120-3507-4bbb-b559-87b7f64af7fa) is the Entra ID object ID of the user whose credentials were used. For more information, correlate the sign-in activity ID (frZ7H7lx8kSlDW0b-4MfAA) with Entra ID sign-in logs.
Identification of high volume API enumeration by a single identity is also a useful strategy for defenders to help identify suspicious discovery activity. AzureHound may generate bursts of API calls in a short time window when querying the Microsoft Graph or Azure REST APIs. This can happen during requests for high volume resources such as users, roles, virtual machines or applications, or simply when using azurehound list to enumerate the entire Azure environment at once. When combined with user-agent strings and the IP address of the calling entity, this can provide a signal for broad enumeration of an Azure environment.
The following XQL query helps surface this enumeration. The operation_name and operation_name_orig filters will limit the results to limit the search to Graph API GET requests which AzureHound uses as explained above.
The bin and comp stages together with the count() function are used to aggregate the data into 60-minute buckets for comparison with the apiCallCount threshold (500 calls per 60 minutes in the example). The apiCallCount should be adjusted to fit the size of the Azure environment. Larger organizations will likely see a higher number of requests as the number of users, roles, virtual machines and applications will typically be much larger than smaller organizations.
|comp count()asapiCallCount by identity_name,user_agent,caller_ip,_time
|filter apiCallCount>500// adjust to your environment
|sort desc apiCallCount
Cortex XQL queries allow defenders to drill into telemetry collected from sources like Microsoft Graph API activity logs to uncover detailed indicators of AzureHound activity. Queries that correlate request volume, user identity, caller IP and user agent over defined time windows can help defenders identify unusual enumeration patterns typical of AzureHound.
Conclusion
Threat actors make use of AzureHound’s capabilities for targeted cloud discovery. Its ability to enumerate users, groups, applications, permissions and resource relationships maps directly to MITRE ATT&CK TTPs. This gives threat actors like Curious Serpens and Void Blizzard a structured method to map environments, identify accounts for privilege escalation and locate the crown jewels of cloud environments.
Detecting this activity depends on telemetry visibility. Microsoft Graph activity logs provide a rich record of API calls, enabling defenders to identify discovery patterns. When paired with other Azure and Entra ID logs, these sources form a comprehensive monitoring layer that elevates threat detection and incident response.
Please refer to our Detecting Threats with Microsoft Graph Activity Logs guide for a walkthrough on configuring Graph API logging, integrating with Cortex XDR and using Cortex to investigate Microsoft Graph activity.
By aligning detections with the MITRE ATT&CK framework and leveraging these log sources, defenders can combine visibility with proactive control. The following are all critical actions that strengthen an organization’s ability to deny attackers success:
Mapping legitimate discovery tools to threat scenarios
Correlating data across systems
Applying Conditional Access Policies
Following the principle of least privilege
Closely monitoring for deviations from normal behavior
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
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, to accurately detect misconfigurations, unwanted access to sensitive data and real-time analysis surrounding usage and access patterns.
Prisma Browser applies multiple mechanisms to protect against token theft and enables administrators to enforce re-authentication during a session. This limits the lifespan of any hijacked session and narrows the attacker’s window of opportunity.
We are attributing an ongoing smishing (phishing via text message) campaign of fraudulent toll violation and package misdelivery notices to a group widely known as the Smishing Triad. Our analysis indicates this campaign is a significantly more extensive and complex threat than previously reported. Attackers have impersonated international services across a wide array of critical sectors.
The attackers have targeted U.S. residents in this campaign since April 2024. The threat actor is evolving their tactics by expanding their reach globally, improving the social engineering tactics used in smishing for delivery.
The threat actor is also expanding the range of services they impersonate to include many international services in critical sectors, such as:
Banking
Cryptocurrency platforms
E-commerce platforms
Healthcare
Law enforcement
Social media
The campaign is highly decentralized, lacking a single point of control, and uses a large number of domains and a diverse set of hosting infrastructure. This is advantageous for the attackers as churning through thousands of domains weekly makes detection more difficult.
Using our intelligence framework, we have identified over 194,000 malicious domains linked to this operation since Jan. 1, 2024. Although these domains are registered through a Hong Kong-based registrar and use Chinese nameservers, the attack infrastructure is primarily hosted on popular U.S. cloud services.
This campaign uses SMS messages for social engineering to create a sense of urgency and prompt victims into immediate action. The campaign's global scale, complex infrastructure and realistic phishing pages strongly suggest that it is powered by a large, well-resourced phishing-as-a-service (PhaaS) operation. This poses a widespread threat to individuals globally. These phishing pages aim to collect sensitive information such as National Identification Numbers (such as Social Security numbers), home addresses, payment details and login credentials.
Palo Alto Networks customers are better protected from this activity through the following products and services:
Technical Analysis of the Extended Smishing Triad Campaign
Earlier this year, we released timely threat intelligence social posts that reported our discovery of more than 10,000 domains involved in smishing scams. Subsequently, we found and blocked over 91,500 domains involved in the same scam. Since publishing those threat intelligence posts, we have continued to track and analyze the threat actors and domains behind these smishing scams.
Security vendor Resecurity attributes these attacks to the Smishing Triad, reporting that the group shared phishing kits on Telegram and other services. This finding is corroborated by follow-up reports by Silent Push. However, our analysis reveals that the campaign's scope is far broader and evolves faster than previously known.
Many indicators suggest that the campaign is constantly evolving. A Fortinet article highlighted the fact that the threat actors used email-to-SMS features. This article noted that arbitrary email addresses can be used to send messages through iMessage. However, we have observed that more recent smishing messages have started to use phone numbers to send them.
Many of these messages are received from phone numbers beginning with the international country code for the Philippines (+63). However, there has been an increasing number of messages in this campaign received from U.S. phone numbers (+1) as well.
Tracking all domains in this campaign is challenging due to its decentralized nature. The attack domains are short-lived and constantly churned, with thousands registered daily. The rapidly evolving campaign highlights that tracking root domains using just lexical patterns is not enough.
We have developed a multi-faceted intelligence framework to track this campaign. It synthesizes data from the following sources:
WHOIS and passive DNS (pDNS) reputation metrics
Evolving domain patterns
Visual clustering of screenshots
Graph-based infrastructure analysis
Using our multi-faceted intelligence framework, we found a total of 194,345 fully qualified domain names (FQDNs) across 136,933 root domains associated with this campaign. These root domains were registered on or after Jan. 1, 2024.
The majority of these domains are registered through Dominet (HK) Limited, a Hong Kong-based registrar and use Chinese nameservers. Although the domain registration and DNS infrastructure originate in China, the attacking infrastructure (the hosting IP addresses) is concentrated in the U.S., particularly within popular cloud services.
We find that the domains in this campaign impersonate global services in many sectors, including:
Critical services: Banking, healthcare and law enforcement (e.g., multi-national financial services and investment companies, police forces from cities in the Middle East)
Widely used services: E-commerce, social media, online gaming and cryptocurrency exchanges (e.g., several Russia-based e-commerce markets and cryptocurrency exchanges)
Previously reported services: Tolls and global state-owned mail and package delivery services extending beyond the U.S. (e.g., Israel, Canada, France, Germany, Ireland, Australia, Argentina)
Attackers craft SMS messages to deliver these URLs. These are highly tailored to the victims to compel immediate action. Using social engineering techniques creates a sense of urgency. By employing targeted personal information and incorporating technical or legal jargon they can appear more legitimate. These things combined with the scope of services imitated suggests that a large PhaaS operation is behind this campaign.
Underground Phishing-as-a-Service Ecosystem
In this section, we discuss the underground PhaaS ecosystem and investigate the Smishing Triad Telegram channel. Over the past six months, the channel has evolved from a dedicated phishing kit marketplace into a highly active community that gathers diverse threat actors within the PhaaS ecosystem.
Figure 1 shows chat records from different participants within the channel. Most posts are advertising various underground services such as domain registration, data sales and message delivery. Highlighting the intense competition within this ecosystem, multiple threat actors compete to offer the same services, particularly Rich Communication Services and Instant Message delivery (RCS/IM).
Figure 1. Telegram chat history of different threat actors in the PhaaS ecosystem.
Figure 2 illustrates below the different roles active in the Smishing Triad Telegram channel and their interactions.
Figure 2. The PhaaS ecosystem of the Smishing Triad.
Threat actors specialize in different stages of the smishing supply chain, enabling them to launch attacks more efficiently and scalably:
Upstream
Data broker: Sells target phone numbers
Domain seller: Registers disposable domains for hosting phishing websites
Hosting provider: Provides servers to run phishing backends
Midstream
Phishing kit developer: Builds phishing websites (frontend and backend) and maintains the PhaaS platform, including dashboards for harvesting and managing stolen credentials
Downstream
SMS/RCS/IM spammer: Delivers phishing messages at scale to direct victims to phishing websites
Support
Liveness scanner: Verifies which target phone numbers are valid and active
Blocklist scanner: Checks the phishing domains against blocklists to trigger asset rotations
Domains Involved in the Campaign
A majority of the root domains involved in this campaign were created with a hyphenated series of strings followed by a top-level domain (TLD) (e.g., [string1]-[string2].[TLD]). In this section, we describe the part before the first hyphen as a prefix. In conjunction with a well-known subdomain, these prefixes could potentially trick victims. For instance, a casual inspection of the domain irs.gov-addpayment[.]info could trick people into thinking they are navigating to irs[.]gov.
Figure 3 shows the most popular prefixes of domain names used in the 136,933 root domains we found in this campaign.
Figure 3. The 10 most popular prefixes of the root domains found in this campaign.
While these domains are registered through various registrars, a significant majority (68.06% or 93,197) of the root domains are registered under Dominet (HK) Limited, a registrar based in Hong Kong. The next most popular registrars are Namesilo with 11.85% (16,227) and Gname with 7.94% (10,873) of the root domains.
Domain Registration Trends
The WHOIS creation dates shown in Figure 4 reveal an interesting shift. We have picked the top 10 most popular domain prefixes in this campaign. The domains with the prefix com- were the most commonly registered in this campaign until May 2025. However, in the past three months, we observed a significant increase in the registration of gov- domains relative to com- domains. This indicates that the campaign is evolving to fit the types of services it impersonates.
Figure 4. WHOIS creation dates for domains belonging to this campaign.
Domain Lifetimes
We also evaluated the lifetime of the domains used in this campaign using pDNS data. A domain's lifetime is the duration between its earliest “first seen” and latest “last seen” timestamps.
As detailed in Figure 5, 39,964 (29.19%) domains were active for two days or less. We saw that 71.3% of these domains were active for less than a week and 82.6% had a lifespan of two weeks or less.
Less than 6% of domains remain active beyond the first three months of their registration. This rapid churn clearly demonstrates that the campaign's strategy relies on a continuous cycle of newly registered domains to evade detection.
Figure 5. Distribution of domain lifetimes from pDNS data.
Network Infrastructure
As previously mentioned, the domains involved in these campaigns are highly decentralized. In this section, we investigate the network infrastructure of the campaign.
DNS Infrastructure
The 194,345 FQDNs in this campaign resolve to a large and diverse set of approximately 43,494 unique IP addresses. The campaign uses a majority of U.S. IP addresses hosted on Autonomous System AS13335, particularly within the 104.21.0[.]0/16 subnet.
In contrast, the nameserver infrastructure is more concentrated, with only 837 unique nameserver root domains. A large majority of the FQDNs use just two providers: AliDNS (45.6%) and Cloudflare (34.6%). This centralization suggests that while the campaign's web hosting is widely distributed, its DNS management is consolidated under a few key services.
Campaign Infrastructure Graph
In Figure 6, we present an example graph depicting this campaign. We see that there are 90 different root domains pointing to a set of IP addresses in the 104.21.0[.]0/16 subnet belonging to AS13335. There are several such localized clusters for each IP address and nameserver.
Figure 6. Campaign graph depicting 90 different root domains pointing to a set of IP addresses within the 104.21.0[.]0/16 subnet.The U.S. Postal Service (USPS) is the single most impersonated service with 28,045 FQDNs. The broader category of toll services is the most impersonated category in this campaign, with nearly 90,000 dedicated phishing FQDNs.
The attack domains are hosted on different IP addresses that are geolocated to various countries. To identify the domains generating the most traffic, we analyzed the distribution of pDNS queries to find the DNS query volume for all domains in the campaign.
We aggregated the number of DNS responses per domain and geolocated the IP addresses in these responses. Queries to domains located in the U.S. account for more than half the volume of queries, as shown in Figure 7. The attack infrastructure for domains generating the largest volume of traffic were located in the U.S., followed by China and Singapore.
Figure 7. Distribution of DNS queries to attack domains by geolocation of the IP addresses.
Impersonated Brands and Services
A large portion of the attack infrastructure we saw was based in the U.S., and the impersonated services reflected this. However, we also identified attackers impersonating services in other countries.
Large U.S. Focus
The campaign targets individuals. It sends messages that masquerade as coming from various commercial organizations as well as state and U.S. government offices, such as:
Commercial and state-owned mail and package delivery services
State vehicles and licensing agencies
State and federal tax services or agencies
We also found mentions of U.S. state names and their two-letter abbreviations in the FQDNs.
Global Brands and Services
Critical services: This campaign often includes messages that mimic those that could come from critical services such as mail, toll payment services, law enforcement and banking in several countries:
The U.S. (banking, mail and delivery, tolls)
Germany (mail and delivery services, investment banks and savings banks)
United Arab Emirates (police forces belonging to multiple cities)
The UK (state-owned services)
Malaysia, Mexico (banks)
Argentina, Australia, Canada, France, Ireland, Israel, Russia (electronic tolls, as well as mail and delivery services).
General services: The campaign involves impersonating messages from many general services such as:
Carpooling applications
Online platforms for home-sharing and hospitality services
Popular social media sites
Typosquatting: We have observed several FQDNs used in this campaign that are typosquatting popular services, including financial technology applications and personal cloud services
E-commerce and online payment platforms: This campaign also impersonates several large e-commerce platforms in:
Russia
Poland
Lithuania
Other countries internationally
Cryptocurrency exchanges: We found that the campaign also impersonates cryptocurrency exchanges, wallet and Web3 platforms
Gaming-related: We have found FQDNs used in this campaign relating to online games and fake marketplaces for in-game skins
What Content Is Being Hosted?
Phishing Impersonating Banking and Popular Services
The most common landing page we observed contained phishing content impersonating the service indicated by the FQDN. Figure 8 presents examples of phishing pages designed to resemble login and identity verification for a consumer electronics company (5,078 FQDNs) and a significant financial services firm (769 FQDNs). These are potentially aimed at extracting victims’ login information and other sensitive information such as social security numbers.
Figure 8. Landing pages for domains phishing banking and popular service providers.
Phishing Impersonating Government Agencies
We have observed phishing pages impersonating government services such as the IRS and U.S. state vehicle departments and other transportation-related agencies.
These landing pages often mention unpaid toll and other service charges. They are potentially aimed at extracting login credentials, personal details and payment information.
Figure 9 shows examples of landing pages of domains impersonating state-specific electronic toll services. They use the state names and their services in the subdomain names and make use of state logos and emblems within the phishing pages.
Figure 10 shows examples of landing pages impersonating U.S. government agencies such as the IRS (128 FQDNs). The page contains a fake CAPTCHA page that is designed to manipulate users into executing malicious scripts on their machine.
Figure 10. Landing pages for domains phishing government agencies.
Misdelivery and Fake Customs Charges
Figure 11 shows several examples of landing pages containing fake notices of delivery failure, toll violation, international customs charges associated with popular mail and package delivery services, and toll services. These are potentially aimed at extracting personal information such as home addresses, contact details and payment information from victims.
Figure 11. Landing pages for misdelivery and fake customs charges.
Conclusion
We have uncovered that the smishing campaign impersonating U.S. toll services is not isolated. It is instead a large-scale campaign with global reach impersonating many services across different sectors. The threat is highly decentralized. Attackers are registering and churning through thousands of domains daily.
To track this rapidly evolving activity, we developed a multi-faceted intelligence framework that synthesizes data from WHOIS records, pDNS, evolving domain patterns, visual clustering of landing pages and graph-based infrastructure analysis.
We advise people to exercise vigilance and caution. People should treat any unsolicited messages from unknown senders with suspicion. We recommend that people verify any request that demands urgent action using the official service provider's website or application. This should be done without clicking any links or calling any phone numbers included in the suspicious message.
Palo Alto Networks Protection and Mitigation
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 00080005045107
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
We investigated a campaign waged by financially motivated threat actors operating out of Morocco. We refer to this campaign as Jingle Thief, due to the attackers’ modus operandi of conducting gift card fraud during festive seasons. Jingle Thief attackers use phishing and smishing to steal credentials, to compromise organizations that issue gift cards. Their operations primarily target global enterprises in the retail and consumer services sectors. Once they gain access to an organization, they pursue the type and level of access needed to issue unauthorized gift cards.
The activity related to this campaign is tracked by Unit 42 as cluster CL‑CRI‑1032. The threat actors behind the activity target organizations that primarily rely on cloud-based services and infrastructure. They then exploit Microsoft 365 capabilities to conduct reconnaissance, maintain long-term persistence and execute large-scale gift card fraud. We assess with moderate confidence that the activity cluster we track as CL-CRI-1032 overlaps with the activity of threat actors publicly tracked as Atlas Lion and STORM-0539 [PDF].
What makes the threat actor behind this activity particularly dangerous is the ability to maintain a foothold inside organizations for extended periods — sometimes over a year. During this time, they gain deep familiarity with the environment, including how to access critical infrastructure — making detection and remediation especially challenging. In April and May 2025, the threat actor behind the Jingle Thief campaign launched a wave of coordinated attacks across multiple global enterprises.
This article presents an end-to-end analysis of the Jingle Thief campaign lifecycle, based on real-world incident telemetry and detections. We provide a clear view of the methods involved in this activity, and practical guidance for mitigating identity-based threats — attacks that target user accounts and credentials — in cloud environments. As identity increasingly replaces the traditional perimeter, understanding campaigns like Jingle Thief is essential to securing modern enterprise infrastructure.
We assess with moderate confidence that the Jingle Thief campaign was created by financially motivated Morocco-based attackers who have been active since 2021. Their operations primarily target global enterprises in the retail and consumer services sectors. Although not affiliated with a nation-state, the activity we track as CL‑CRI‑1032 includes advanced tactics, persistence and operational focus.
Unlike threat actors who rely on commodity malware or endpoint exploitation, the attackers behind CL‑CRI‑1032 operate almost exclusively in cloud environments once they obtain credentials through phishing. They exploit cloud-based infrastructure to impersonate legitimate users, gain unauthorized access to sensitive data and carry out gift card fraud at scale.
Anatomy of the Jingle Thief Campaign
In a campaign that we observed, threat actors maintained access for approximately 10 months and compromised over 60 user accounts within a single global enterprise. The activity involved the use of Microsoft 365 services, including SharePoint, OneDrive, Exchange and Entra ID. This demonstrated a high degree of adaptability and operational patience. Detecting this approach requires close observation of adversaries’ actions over an extended period. The threat actors behind the Jingle Thief campaign often align their activity with holiday periods, increasing operations during times of reduced staffing and heightened gift card spending.
Having gained initial access, the threat actors conducted reconnaissance to map the environment, moved laterally to access more sensitive areas, and identified opportunities to execute large-scale financial fraud. Figure 1 illustrates the end-to-end attack lifecycle across Microsoft 365, highlighting how the threat actors progressed from phishing-based entry to persistent access through device registration.
Figure 1. Jingle Thief phishing attack chain across Microsoft 365.
The final attack step of device registration creates a foothold that the threat actors exploit to issue gift cards, which they then leverage for monetary gain.
Why Gift Cards? The Prey of Choice
Gift cards are highly attractive to financially motivated actors due to their ease of redemption and rapid monetization. Threat actors resell gift cards on gray-market forums at discounted rates, enabling near-instant cash flow.
Additional factors that make gift cards attractive include:
Minimal personal information required for redemption
Difficult to trace, making fraud harder to investigate or recover
Accepted widely, often indistinguishable from legitimate use
Useful for low-risk money laundering, especially across jurisdictions
Frequently issued through systems with weak access controls, broad internal permissions, and limited monitoring or logging
Retail environments are particularly vulnerable to this type of attack, as gift card systems are often accessible to a wide range of internal users, such as store employees. These systems may support multiple vendors or programs, making access pathways broader and more difficult to control.
Gift card fraud combines stealth, speed and scalability, especially when paired with access to cloud environments where issuance workflows reside. To exploit these systems, the threat actors need access to internal documentation and communications. They can secure this by stealing credentials and maintaining a quiet, persistent presence within Microsoft 365 environments of targeted organizations that provide gift card services.
In the campaign we observed, the attackers made repeated access attempts against multiple gift‑card issuance applications. They tried to issue high‑value cards across different programs in order to monetize them, and possibly to use the cards as collateral in money-laundering schemes — effectively turning digital theft into untraceable cash or short-term loans. These operations were staged in a way that minimizes logging and forensic traces, reducing the chance of rapid detection.
Highly Targeted and Tailored Attacks
The threat actors behind the Jingle Thief campaign invest heavily in reconnaissance before launching attacks. They gather intelligence on each target, including branding, login portals, email templates and domain naming conventions. This allows them to craft highly convincing phishing content that appears authentic to both users and security tools.
Phishing URLs often include the organization’s name, a trusted third-party tool or software, and landing pages that closely mimic legitimate login screens. This highly customized social engineering approach increases the likelihood of compromise and highlights the actors’ use of sophisticated techniques.
Figure 2 shows a credential phishing page crafted by the threat actors to impersonate a legitimate Microsoft 365 login portal, tailored to the victim organization’s branding.
Figure 2. Fake Microsoft 365 login page tailored to the target organization.
Initial Access: Phishing and Smishing for Cloud Credentials
The threat actors behind the Jingle Thief campaign typically begin their operations with tailored phishing or SMS-based smishing attacks. These messages lure victims to counterfeit Microsoft 365 login portals that mimic legitimate sign-in pages. Some lures impersonate nonprofits or non-governmental organizations (NGOs), likely to give the appearance of credibility and increase victim engagement.
Notably, many messages are delivered using self-hosted PHP mailer scripts, often sent from compromised or hijacked WordPress servers, which obscure the attackers’ origin and improve delivery.
The threat actors also employ deceptive URL formatting, such as: https://organization[.]com@malicious.cl[/]workspace
While the URL above appears to point to the legitimate organization’s domain (organization[.]com), browsers interpret everything before the @ as user credentials, and actually navigate to the domain after it (malicious.cl). This tactic helps disguise the true destination of the link and increases the likelihood of victims clicking.
After harvesting credentials in the campaign that we observed, the attackers authenticated to Microsoft 365 directly and began navigating the environment, with no malware required. Figure 3 shows a smishing attempt used to harvest credentials, captured from a malicious PHP email send log from the attackers’ infrastructure. The message originated from a Moroccan IP address, and was sent to a Verizon SMS gateway (vtext.com).
Figure 3. Credential phishing via smishing, logged from attackers’ infrastructure.
Cloud Reconnaissance: Mining SharePoint and OneDrive for Gift Card Intel
After initial access, the attackers behind Jingle Thief perform extensive reconnaissance within the Microsoft 365 environment, particularly focusing on SharePoint and OneDrive. These services frequently contain internal documentation related to business operations, financial processes and IT workflows.
The threat actors search for:
Gift card issuance workflows
Ticketing system exports or instructions
VPN configuration and access guides
Spreadsheets or internal tools used to issue or track gift cards
Figure 4 shows SharePoint files accessed by the threat actors after account compromise, revealing their focus on internal documentation tied to gift card workflows and remote access infrastructure.
Figure 4. Internal SharePoint files accessed by Jingle Thief post-compromise.
Rather than escalating privileges, the threat actors build situational awareness by accessing readily available data on compromised users. This discreet approach helps evade detection while laying the groundwork for future fraud.
Internal Phishing for Lateral Moves
Instead of deploying malware or post-exploitation frameworks, Jingle Thief relies on internal phishing to expand their foothold within target environments. In an attempted attack against one of our customers, after compromising a user's Microsoft 365 account, the attackers sent phishing emails from the legitimate account to personnel inside the same organization. These messages mimicked IT service notifications or ticketing updates, often leveraging information gathered from internal documentation or previous communications to appear legitimate.
Common lures:
Fake ServiceNow alerts: "INCIDENT REQ07672026 Has been completed"
IT access notifications: "ServiceNow Account Inactivity Notice"
Generic approval prompts: "Incident pending your review"
These emails link to fake login portals branded with the organization’s identity, leveraging internal trust to evade suspicion and spread laterally.
Figure 5 shows an internal phishing email sent from a compromised account, spoofing a ServiceNow inactivity notice to trick users into entering credentials.
Figure 5. Internal phishing email mimicking a ServiceNow notification.
Ruling the Inbox for Silent Email Exfiltration
To passively monitor internal communications, the attackers responsible for the Jingle Thief campaign often create inbox rules to automatically forward emails to attacker-controlled addresses.
They monitor:
Gift card approvals
Financial workflows
IT ticketing or account changes
This approach reduces the need for active attacker interaction and helps maintain stealth. Figure 6 shows an alert flagging the creation of a malicious inbox forwarding rule, which is one of the stealth tactics employed by these threat actors to monitor internal communications.
Figure 6. Cortex XDR alert showing automatic email forwarding rule set by threat actors.
Stealthy Email Activity: Hiding in Plain Sight
To cover their tracks, the attackers actively manage mailbox folders:
Moving sent phishing emails immediately from Sent Items to Deleted Items
Moving replies from users from Inbox to Deleted Items
This ensures that victims won’t see the phishing messages or responses, delaying discovery by both victims and defenders.
The Exchange audit logs in Figure 7 show the attackers moving phishing email replies from the Inbox folder to the Deleted Items folder.
Figure 7. Items moved from Inbox to Deleted Items.
Dominating Rogue Devices for Persistence
Most of the intrusions we observed in the Jingle Thief campaign relied on stolen credentials or session tokens for temporary access. However, the actors also demonstrated techniques for establishing longer-term persistence within compromised environments.
In some intrusions, the threat actors took control of identity infrastructure by misusing legitimate user self-service and device enrollment mechanisms in Microsoft Entra ID. These tactics allowed them to maintain access even after passwords were reset or sessions were revoked.
Tactics include:
Registering rogue authenticator apps to bypass MFA
Resetting passwords via self-service flows
Enrolling attacker-controlled devices in Entra ID
Figure 8 shows the user interface for registering a device in Microsoft Entra ID using the Authenticator app. The attackers misused this legitimate process to silently enroll rogue devices and maintain MFA-resistant access.
Figure 8. Device registration flow in Microsoft Entra ID.
The ultimate goal of these varied tactics – phishing, inbox control, mail exfiltration and rogue device registration – is to obtain and monetize gift cards at scale.
Tracing Jingle Thief’s Moroccan Roots
The campaign activities that we observed almost exclusively originated from IP addresses geolocated in Morocco. Across incidents, Microsoft 365 logs showed recurring device fingerprints and login behaviors associated with these IP addresses. Unlike many actors who hide behind VPNs, these threat actors often made no attempt to obscure their origin, and only sometimes used Mysterium VPN when accessing compromised accounts.
Autonomous System Number (ASN) metadata from the connections also consistently matched Moroccan telecommunications providers, including:
MT-MPLS
ASMedi
MAROCCONNECT
In addition to IP and ASN infrastructure, Jingle Thief reuses distinctive domain and URL structures across campaigns. These recurring patterns in domain naming and infrastructure further support attribution to a Morocco-based threat group.
Conclusion
The Jingle Thief campaign demonstrates a clear focus on major retailers’ gift-card issuance systems. The attackers targeted multiple issuance applications to generate high‑value cards, likely for resale on gray markets, or as fungible assets in money‑laundering chains. Gift-card systems are often under‑monitored and widely accessible internally, making them an attractive extension to identity‑based attacks: By compromising the right accounts, threat actors can issue and steal gift cards, while leaving almost no trace of their malicious operations.
The cluster of activity behind the Jingle Thief campaign overlaps with the activity of threat actors publicly tracked as Atlas Lion. This cluster — tracked by Unit 42 as CL-CRI-1032 — favors identity misuse over malware, and leverages trusted cloud services rather than endpoint compromise. Their campaigns highlight how attackers can operate entirely within cloud environments, abusing legitimate features for phishing, persistence and fraud.
By understanding the tactics used in the Jingle Thief campaign, defenders can better prioritize identity-based monitoring and adapt to the industry’s shift toward treating identity as the new security perimeter. Understanding user behavior, login patterns and identity misuse are increasingly essential for early detection and response.
Palo Alto Networks customers are better protected from this activity with the new Cortex Advanced Email Security module, as well as Cortex UEBA and ITDR.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 00080005045107
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Indicators of Compromise
Moroccan Infrastructure (Attribution Signal)
105.156.109[.]227
105.156.234[.]139
105.157.86[.]136
105.158.226[.]49
105.158.237[.]165
160.176.128[.]242
160.178.201[.]89
160.179.102[.]157
196.64.165[.]160
196.65.139[.]51
196.65.146[.]114
196.65.172[.]48
196.65.237[.]97
196.74.125[.]243
196.74.183[.]81
196.77.47[.]232
196.89.141[.]80
41.141.201[.]19
41.250.180[.]114
41.250.190[.]104
Associated ASN Organizations (Geolocated to Morocco)
MT-MPLS
ASMedi
MAROCCONNECT
U.S. Infrastructure (Potential Proxy or Compromised Hosts)
![Screenshot of an email inbox displaying multiple messages with the subject 'Automatic reply: INCIDENT [Set of numbers] has been completed', all from the sender 'MoveToDeclassifiedItems' and located in the 'Inbox' folder.](https://unit42.paloaltonetworks.com/wp-content/uploads/2025/10/word-image-280966-161503-7.png)
Get updates from Unit 42 