The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration

Posted on by Yahav Festinger

Executive Summary

We recently identified a bucket hijacking technique impacting multiple services across major cloud service providers (CSPs). The attack technique exploits a fundamental architectural flaw that is common across cloud providers and could potentially affect other cloud providers as well.

Our research reveals that an attacker can silently compromise an organization's active data streams by rerouting data into an external storage bucket. Because a storage bucket name is globally unique, an attacker can simply delete the bucket and then recreate it under the attacker's own account using the same name. This therefore creates a global namespace risk. This bucket hijacking reroutes critical logs and sensitive data directly to the attacker’s environment.

We have shared these findings with Google Cloud, Amazon Web Services (AWS), and Microsoft Azure.

We have not yet identified a real-world threat actor using this attack technique. However, we recommend organizations take steps now to head off the potential impact, particularly since we anticipate that real-world attempts to use this attack technique would be difficult to detect.

Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:

Unit 42 Cloud Security Assessment can help turn cloud complexity into actionable security insights.

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

Related Unit 42 Topics Cloud Logging, Google Cloud, AWS, Microsoft Azure

Key Architectural Elements Enabling the Attack

Before detailing the attack methodology, it’s important to understand several architectural elements that, when combined, make bucket hijacking possible.

Data Stream Overview

A data stream is an automated, continuous pipeline designed for high-volume data movement between services. Once configured, these streams operate autonomously in the background to push telemetry, audit logs or objects from a source environment to a designated storage destination for processing and long-term retention.

Major CSPs facilitate automated data streams. These streams serve as critical nodes for routing, processing and backing up data within an organization's infrastructure, such as:

  • A cloud logging sink in Google Cloud acts as a router for log entries, directing them to a chosen destination. While primarily used to route and store logs in centralized log buckets for purposes like analysis and retention, a sink can also export logs to a Google Cloud Storage (GCS) bucket.
  • Bucket replication in AWS is a feature that automatically duplicates data from a source S3 bucket to a designated destination S3 bucket.

Global Uniqueness of Bucket Names

Cloud environments often stream data into buckets such as an S3 bucket in AWS or a GCS bucket in Google Cloud. Because bucket names are typically unique across the entire cloud provider, no two users can have the same bucket name. This design simplifies data stream establishment by providing a single, predictable target. However, it also creates a shared namespace where a destination's identity is tied solely to its name, rather than to a specific, immutable account owner. This characteristic is the foundational logic behind our discovery.

Permissions to Modify Data Stream Destinations

The data stream is frequently defined by a routing resource that is configured with a specific destination. To legitimately modify this destination, the user must possess specific, granular identity and access management (IAM) update permissions for that resource.

For example, modifying the destination for a cloud logging sink requires the logging.sinks.update permission. This routes logs to a bucket. Our research found that certain permissions outside of this traditional update purview could be leveraged to reroute data streams.

The Bucket Hijacking Attack

We now turn to discussing the attack flow before any mitigations were provided by the affected CSPs. After compromising a cloud environment and securing the permissions required to delete a target bucket, an attacker was effectively positioned to intercept and redirect a cloud data stream. By deleting the original bucket and immediately recreating a new bucket with the same name within their own account, the attacker could have redirected the data stream. This could have led to the exfiltration of the target's data to the attacker's account.

Figure 1 shows the attack flow diagram.

A three-part digram showing the bucket hijacking attack flow. The first step shows a cloud platform with a target project. It includes a resource labeled "Router" and a bucket labeled "target-storage." The middle step illustrates a cloud platform with the "target-storage" bucket removed. In the final step, the diagram shows two projects: a target project with the "Router" resource and an attacker project with a new "target-storage" bucket.
Figure 1. The bucket hijacking attack flow.

Simulating Bucket Hijacking in Google Cloud Logging

We simulated the bucket hijacking technique in Google Cloud Logging. In the simulation, we used a sink that routes logs to a cloud storage resource, as shown in Figure 2.

A screenshot of Google Cloud's "Sink details" page showing configurations for a Cloud Storage bucket. The screen includes fields like Name, Resource name, Description, Service, Destination, and Writer identity, with some text redacted. There are also options for "Inclusion filter" and "Exclusion filter(s)." Buttons labeled "Cancel" and "Edit sink" are at the bottom.
Figure 2. An existing sink referencing a GCS bucket.

After routing the logs, the original cloud storage bucket was deleted, as Figure 3 shows.

A screenshot of a confirmation dialog for deleting a Google Cloud storage bucket/ A warning indicates that this action will permanently delete the bucket and its contents. There is a text box for typing "DELETE" to confirm the action, with "DELETE" already entered. Options for "Cancel" and "Delete" are at the bottom.
Figure 3. Deleting the targeted bucket used by the sink.

We then created a new bucket with the same name in an attacker-controlled environment, as shown in Figure 4.

A screenshot of creating a storage bucket in Google Cloud Platform. The interface shows options for naming the bucket, selecting a data region, and configuring access and protection settings. On the right, pricing information and configuration tips are displayed.
Figure 4. Recreating the bucket in an external project.

Subsequently, logs were routed to this external cloud storage bucket, allowing the attacker to obtain extensive information about the compromised environment, as shown in Figure 5. The required permissions the attacker needed to have are storage.objects.delete (to empty the bucket) and storage.bucket.delete (to delete the bucket).

A screenshot of a Google Cloud Storage browser interface displaying a bucket. The list view includes multiple folders named after popular websites and companies, such as "en.wikipedia.org" and "linkedin.com." The interface shows columns for "Type," "Created," "Storage class," "Last modified," and more. Some folders have public access settings.
Figure 5. Logs written into the attacker’s controller bucket.

The Expansion to Multiple Services Within Google Cloud

Data streaming into a GCS bucket is not unique to cloud logging. There are many other Google Cloud services in which data can be streamed into cloud storage. We identified and tested a representative subset of potentially vulnerable services, specifically Pub/Sub and Storage Transfer Service, to confirm the systemic prevalence of this security risk.

Pub/Sub

Pub/Sub is an asynchronous messaging service that decouples upstream event producers from downstream processing services. It allows applications to broadcast messages to a topic, which are then distributed to one or more subscriptions for consumption by downstream systems.

This architecture enables scalable, event-driven communication. This allows disparate components such as log aggregators, data pipelines and real-time analytics engines to exchange information reliably without needing direct, synchronous connections.

The Pub/Sub architecture has three core components:

  1. Publishers (producers) send messages to a named logical channel called a topic, without needing to know who or what will receive them.
  2. Topics act as a buffer or distribution hub, holding the messages until they can be delivered.
  3. Subscribers (consumers) listen to specific topics via a subscription. When a message arrives in the topic, the Pub/Sub service pushes it to the subscribers (push model) or the subscribers actively request it (pull model).

To simulate a bucket hijacking attack on Pub/Sub, we took the following steps:

  1. We created a new Pub/Sub topic and a subscription linked to a GCS bucket
  2. We configured the GCS bucket with the necessary permissions to grant access to the service agent:
    1. Storage object creator (roles/storage.objectCreator)
    2. Storage legacy bucket reader (roles/storage.legacyBucketReader)
  3. We published a message to the topic, which was successfully delivered to the initial bucket
  4. We deleted the original bucket and created a new bucket with the same name in a different project (the attacker's project)
  5. When a message was published manually again, we found that the service exfiltrated the message to the attacker's environment

The successful redirection of the message stream proved that the bucket hijacking attack technique was directly applicable to the Pub/Sub service, allowing an attacker to exfiltrate data by deleting and recreating the destination bucket.

Storage Transfer Service

Storage Transfer Service is a managed data migration tool designed to automate the movement of large volumes of data into, out of or between cloud storage environments. It allows organizations to schedule and manage massive data transfers from external sources (like AWS S3 or on-premises systems) to GCS buckets, or to synchronize data between different cloud storage projects.

The service handles the underlying infrastructure, retries and checksum validation. It provides a way to populate data lakes or perform large-scale disaster recovery backups.

The Storage Transfer Service architecture operates as a centralized orchestration engine that manages the movement of data between a designated source and sink. When a user defines a transfer job, they specify the source, the destination and the scheduling parameters. The source can be an S3 bucket, a URL list or another GCS bucket.

To simulate a bucket hijacking attack on Storage Transfer Service, we took the following steps:

  1. We configured a new transfer job with a GCS bucket as the source and another GCS bucket as the destination
  2. We assigned the necessary permissions to the buckets to grant access to the service agent:
    1. Source bucket: Storage Object Viewer (roles/storage.objectViewer) and Storage Legacy Bucket Reader (roles/storage.legacyBucketReader)
    2. Destination bucket: Storage Object Admin (roles/storage.objectAdmin)
  3. The user then initiated the transfer job
  4. We deleted the destination bucket and then immediately re-created it in a different project (the attacker's environment)
  5. We wrote a new object into the source bucket
  6. After a period determined by the job's scheduling parameter, the object appeared in the newly hijacked destination bucket, which was under the attacker's control

The impact of this risk was significantly magnified by its broad applicability across numerous services. The permissions storage.buckets.delete and storage.objects.delete could be used to bypass the granular update permissions required for specific resources to redirect sensitive data streams such as logging.sinks.update, pubsub.subscriptions.update and storagetransfer.jobs.update.

The Expansion to Another Cloud Provider: AWS

The architectural flaw of global bucket name uniqueness is not exclusive to Google Cloud. AWS S3 buckets operate under the same design logic. Given this commonality, we investigated whether we could apply the same hijacking technique within the AWS ecosystem.

We successfully simulated the bucket hijacking attack using the S3 bucket replication feature. This feature enables the configuration of a source and destination bucket, where all objects written to the source bucket are automatically replicated to the destination bucket. The simulation followed these steps:

  1. We created a bucket in our environment with a replication rule targeting a second bucket within the same account
  2. We deleted the bucket and immediately recreated a new one using the same name within an external account
  3. We uploaded a file to the source bucket
  4. We observed the file appearing in the destination bucket located in the external account

Like in Google Cloud, we identified that this was not a localized issue, but applied to a number of AWS data stream services. We simulated the same technique using Amazon Data Firehose (where the destination is an S3 bucket) and observed the same behavior.

Cross-Subscription Data Exfiltration in Azure

Finally, we tested Azure’s environment for the same attack technique. Azure platform limitations prevent the immediate reuse of storage account names across different tenants for several days after deletion. However, we were able to simulate a cross-subscription attack technique.

This scenario was particularly relevant if an attacker gained permission to delete a storage account in one subscription and intended to reroute data to another. This allowed them to move data to a subscription where they maintained higher privileges and persistence, or perhaps where they previously lacked data access permissions. Ultimately, this technique relied on the fact that a storage account must be created with soft-delete disabled to ensure the name was released and could be promptly reclaimed.

We used Azure Monitor to demonstrate this attack. Diagnostic settings in Azure Monitor can be configured to export resource logs (e.g., metrics and audit events) to an Azure storage account. While the configuration stores the destination via its Azure Resource Manager (ARM) Resource ID, the internal pipeline resolves the storage account at runtime using its DNS name ({accountname}.blob.core.windows.net).

This architectural behavior facilitated the execution of the attack. If an attacker deleted a destination storage account and recreated it with an identical globally unique name in a different subscription within the same tenant, the diagnostic pipeline would continue to write logs to the attacker-controlled storage account.

The attack was less severe in Azure than in AWS or Google Cloud because it was limited to a cross-subscription scope rather than a cross-tenant one.

Exploitation Scenarios and Excessive Permissions Risks

The practical execution of bucket hijacking relies on specific exploitation vectors that are often facilitated by the widespread use of over-privileged administrative roles.

Exploitation Scenarios and Detection Challenges

We identified two distinct scenarios that could enable an attacker to execute a bucket hijacking operation:

  1. Privilege escalation: As demonstrated in our simulations, a compromised identity with the permission to delete a bucket could misuse this access to redirect data streams to the attacker's own bucket. The widespread application of storage administrator roles significantly increased the risk of this attack technique and overcame the need for the more granular logging.sinks.update permission (as shown later).
  2. Dangling router resources: In a similar exploit not demonstrated in this article, if someone deleted a bucket and failed to remove the associated router resource, an attacker could create a new bucket using the same name in their own environment. This action effectively redirects the data to the attacker's bucket, granting the attacker access to the victim's ongoing data.

Detecting these attack scenarios is particularly challenging. In scenarios where destination resources are used primarily for long-term retention or backup, the target may not detect the initial deletion of the original storage bucket. Because the data stream continues to operate autonomously, the sink configuration in Google Cloud appears valid upon inspection as shown in Figure 6. This allows the hijacking and subsequent data exfiltration to remain largely undetected.

A screenshot showing Google Cloud Storage with a checkbox selected for a bucket, with a URL.
Figure 6. The sink configuration remains intact and operational after recreating the bucket.

How Over-Privileged Roles Increase the Risk

Cloud providers frequently offer broad storage administration roles that grant wide-reaching deletion privileges by default, which significantly increases the practical risk of this attack technique.

For example, in Google Cloud the common storage admin role provides the storage.buckets.delete permission. However, as Figure 7 shows, it does not include granular permissions to modify data stream configurations like:

  • logging.sinks.update
  • pubsub.subscriptions.update
  • storagetransfer.jobs.update
A screenshot of a Google Cloud documentation page describing the "Storage Admin" role. Includes details about granted permissions, emphasizing full control over objects and buckets, with items like "storage.buckets.*" highlighted. The list contains various operations related to storage and administrative actions.
Figure 7. The predefined Google Cloud storage admin role includes bucket deletion permission (highlighted in red) but lacks granular update permissions for data stream resources.

Mitigation Strategies

Google has adjusted how router resources interact with target storage resources since the time of our initial research.

Microsoft recommended that Azure users review documentation and tooling on addressing dangling DNS for subdomain takeovers (see Additional Resources).

Users can also employ additional defense strategies.

Mitigating the bucket hijacking technique requires a two-pronged approach focusing on preventative guardrails and proactive monitoring. Prevention starts with the principle of least privilege. Organizations must strictly limit the IAM permissions for deletion actions, specifically:

  • Storage.buckets.delete in Google Cloud
  • DeleteBucket in AWS
  • Microsoft.Storage/storageAccounts/delete in Azure

These permissions should be restricted to a minimal set of administrative roles and should never be assigned to service accounts or applications without rigorous justification.

In addition, the following mechanisms help to prevent the bucket hijacking technique:

  • Organizations can prevent bucket hijacking for data exfiltration by enforcing data perimeter controls that restrict resource access to stay within a trusted organizational boundary.
    • In AWS, data perimeter policies — implemented through service control policies (SCPs) and virtual private cloud (VPC) endpoint policies — can ensure that workloads within the organization are unable to write data to S3 buckets that belong to external accounts. This can effectively block the exfiltration path even if an attacker substitutes a malicious bucket, though the approach has some limitations.
    • Similarly, in Google Cloud, VPC Service Controls define a security perimeter around projects and services, to block any API call attempting to access Cloud Storage buckets outside the perimeter.

Deploying these controls as a baseline ensures that data cannot leave the trusted environment boundary, neutralizing the core mechanism of this attack technique.

  • AWS offers account regional namespaces for S3 buckets, which scope bucket names to the owning account and region rather than to a single global namespace. This directly eliminates the bucket hijacking vector. If a bucket is deleted, no other account can reclaim its name. This prevents attackers from intercepting traffic by re-registering abandoned bucket names.

For detection, organizations must implement robust monitoring solutions that specifically alert on the attempted deletion of a storage bucket. Security teams should prioritize high-severity alerts for storage deletion API calls, focusing specifically on resources that house sensitive information.

Given the high frequency of storage deletion events in large-scale environments, leveraging data security posture management (DSPM) capabilities is essential. It is particularly important to prioritize monitoring and to focus specifically on high-value, sensitive assets, as shown in a Cortex XSIAM alert in Figure 8.

A screenshot of a dashboard showing a notification about the deletion of a GCP storage bucket containing sensitive data. It includes a security domain case with an alert icon linked to "GCP Storage Bucket.
Figure 8. Cortex XSIAM alert: Deletion of a high-sensitivity bucket detected.

Conclusion

The bucket hijacking technique detailed in this research exploits the global uniqueness of storage resource names in the major cloud providers. We have demonstrated how a configure-and-forget approach to data streams can lead to silent, long-term data exfiltration.

Reliance on a globally unique, static resource name for buckets is an architectural design common across cloud providers. As such, this technique could be portable to other cloud services and providers not covered in this research.

Our findings underscore two primary lessons for the security community:

  • Architecture defines the security boundary: Fundamental design choices made by cloud providers directly influence the security boundaries of our environments. A robust mitigation strategy must include awareness of these architectural nuances and the implementation of guardrails.
  • A cross-cloud exploitation methodology: While cloud providers are often managed as distinct ecosystems, their shared design philosophies allow identical attack techniques to be applied across providers. Our simulations prove that a specific architectural observation can evolve into a universal methodology for hijacking sensitive data streams. We encourage the security industry to adopt a cloud-agnostic mindset. A design flaw discovered in one provider could be a blueprint for exploiting another.

Palo Alto Networks Protection and Mitigation

Palo Alto Networks customers are better protected from the threats discussed above through the following products:

  • Cortex Cloud customers are better protected from the techniques discussed in this article with cloud runtime security operations through the collection, analysis, detection, alerting and prevention of malicious operations on cloud platform and SaaS application audit logs. Cortex has several out-of-the-box rules built into the Analytics module that detect data movement to external buckets. Using behavioral and static alerting techniques on cloud logs during cloud operations runtime, the techniques discussed within the article can be identified. When this occurs, they trigger alerts, which provide early warning and, in some cases, prevention operations to prevent further compromise from these attacks.
  • Cortex Cloud Identity Security can also protect organizations from the techniques discussed in the article. Identity Security encompasses:
    • Cloud Infrastructure Entitlement Management (CIEM)
    • Identity Security Posture Management (ISPM)
    • Data Access Governance (DAG)
    • Identity Threat Detection and Response (ITDR)
  • These tools provide the necessary capabilities to improve identity-related security requirements within cloud environments. This includes:
    • Accurately detecting misconfigurations
    • Identifying unwanted access to sensitive data
    • Conducting real-time analysis surrounding usage and access patterns

Unit 42 Cloud Security Assessment can help turn cloud complexity into actionable security insights.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 000 800 050 45107
  • South Korea: +82.080.467.8774

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Additional Resources

Pickle in the Middle – Hijacking Vertex AI Model Uploads for Cross-Tenant RCE

Posted on by Ori Hadad

Executive Summary

We discovered a vulnerability in the Google Cloud Vertex AI software development kit (SDK) for Python, and responsibly disclosed it to Google. Before Google’s fix, the vulnerability would have allowed an attacker operating entirely from their own Google Cloud project to hijack a victim's model upload and poison it. By exploiting this flaw in vulnerable versions of the SDK, an attacker can achieve remote code execution (RCE) within a target’s Vertex AI serving infrastructure, with zero initial access to the victim's project.

The root enabler of this attack is a predictable default bucket name, combined with a missing ownership check in the SDK's staging logic. When a Vertex AI user uploads a model without specifying a custom staging bucket, the SDK constructs a bucket name using a deterministic pattern based on the project ID and region.

An attacker who knows the victim's project ID can preemptively create this bucket in their own project, a technique known as bucket squatting. The SDK then silently uploads the victim's model artifacts to the attacker-controlled bucket. Subsequently, within a narrow window of opportunity, the attacker replaces the legitimate model with one that carries a malicious payload. Once the victim deploys the compromised model, the attacker's code executes. In vulnerable SDK versions, this can lead to data exfiltration, lateral movement and further compromise of the victim's cloud environment.

We refer to the process of exploiting this vulnerability as Pickle in the Middle because it relies in part on deserializing a built-in module called pickle, as explained below in Pickle Deserialization as Attack Vector.

We reported the vulnerability to the Google security team, and they accepted our findings. The issue affected google-cloud-aiplatform SDK versions 1.139.0 and 1.140.0, which was the latest at the time of testing. Google completed the fixes to address this issue in v1.148.0, which was released April 15, 2026.

We recommend that developers upgrade to fixed versions of the SDK.

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

The Unit 42 AI Security Assessment and Unit 42 Frontier AI Defense service can help identify and mitigate complex AI-specific risks.

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

Related Unit 42 Topics Vertex AI, RCE, Google Cloud, SDKs, Python

Background and Terminology

Vertex AI is a machine learning platform for training and deploying ML models and AI applications. The Vertex AI SDK for Python is the primary client library that developers use to interact with the platform programmatically. We focused our research on the Vertex AI SDK for Python (google-cloud-aiplatform), as many enterprises rely on it to create and manage their AI/ML pipelines, applications and models.

The Vertex AI Model Registry is a centralized repository within Vertex AI where users store, version and manage their ML models. When a user uploads a model to the Model Registry via the SDK, the SDK first stages the model artifacts in a Google Cloud Service (GCS) bucket before registering them with the service. The Model Registry then references these staged artifacts. When the model is deployed to an endpoint, Google's internal infrastructure (specifically, a Per-Product, Per-Project Service Account or P4SA) loads them into a serving container. Figure 1 shows the intended model upload flow.

A diagram illustrating the Model Registry upload flow. The "User Project" section shows "Model.upload()" leading to "Staging Bucket," which connects to "Model Registry." The "Tenant Project" section shows "Google Vertex AI Service Agent" reading from and pushing to "Model Registry," and deploying to "Model Deployed." Arrows depict the direction of data flow between the components.
Figure 1. Uploading a model to Model Registry.

Bucket Squatting

Bucket squatting is a class of vulnerability that takes advantage of the global uniqueness of cloud storage bucket names. Since no two buckets across all of Google Cloud can share the same name, an attacker who is able to predict a bucket name can preemptively create it in their own project. Any subsequent attempt to use a bucket with that name, even from a different project, silently falls back to the attacker's bucket.

Service Agents and Tenant Project

In Google Cloud, many managed services operate through service agents (P4SAs). These are Google-managed service accounts that allow Google Cloud services to access resources. In the case of Vertex AI, the P4SA is responsible for reading model artifacts from the staging bucket and loading them into the serving infrastructure.

Tenant projects are Google Cloud projects that are owned by Google and used to host resources of a managed service. The identities and resources available inside these tenant projects are important aspects to research because they bridge the boundary between Google's infrastructure and the customer's resources. Vertex AI uses tenant projects to host resources such as Kubernetes clusters, containers and service accounts that allow the service to function.

Pickle Deserialization as Attack Vector

Joblib is a set of tools that provides lightweight pipelining in Python. pickle is a built-in module used for serializing and deserializing object structures. ML models in the Python ecosystem are commonly serialized using pickle – or its Joblib wrapper. A critical property of pickle is that deserialization can be leveraged to execute code. Specifically, Python's pickle protocol supports a __reduce__ method that defines how an object should be reconstructed. An attacker who controls a pickle file can define a __reduce__ method that executes arbitrary Python code the moment joblib.load() or pickle.load() is called, before any type of validation occurs. This is a well-known property of pickle (and joblib), and it is the mechanism we used to turn model poisoning into remote code execution.

The Vulnerability

The Vertex AI SDK for Python model upload functionality is vulnerable to bucket squatting in versions 1.139.0 and 1.140.0, the latest versions that were available at the time of testing. When a user does not explicitly provide a staging bucket name, the SDK constructs a bucket name deterministically from the project ID and region, and then checks whether the bucket exists. If the bucket does not exist, the SDK creates it. However, if the bucket exists, the SDK does not verify whether the bucket belongs to the caller's project. This means that an attacker can create a bucket with the same name in their own project, and then wait for the victim to upload a model. Once uploaded, the attacker can replace it with a malicious model. This model carries a payload that executes arbitrary code when deployed and loaded, abusing the pickle deserialization mechanism.

Discovery Methodology

As part of this research, we incorporated a large language model (LLM) into the discovery and code-analysis phase. Analysis that once took days can now be executed significantly faster. By iteratively narrowing the model's focus and instructing it to look for specific patterns, we found paths that led to resources provisioned on the cloud, affected by user-controlled or project-derived inputs.

The vulnerable code was located in gcs_utils.py, inside the stage_local_data_in_gcs() function:

The function constructs the bucket name deterministically from the project ID and region (e.g., my-project-vertex-staging-us-central1). It then calls staging_bucket.exists() to check whether the bucket already exists. The bucket.exists() call returns True for any bucket with that name, regardless of which project owns it.

If the bucket exists, even in a completely different project, the SDK proceeds to upload model artifacts to it without any further verification. Once the model is uploaded, the attacker has a limited window of opportunity to replace it with a compromised one. This malicious model carries a payload that executes arbitrary code when the model is deployed and loaded. After this window, the AI Platform Service Agent (service-PROJECT_NUMBER@gcp-sa-aiplatform.iam.gserviceaccount[.]com) reads the model and the attacker loses their ability to replace it. Our tests show that this window is approximately 2.5 seconds, requiring near-real-time attacker operation, as shown in Phases 2-4 below.

The Attack Chain

Prerequisites

The success of this attack depends on the following conditions:

  • The victim’s default staging bucket does not already exist in the target region. This is the case for any project that has not yet used Vertex AI in that region or has not used the default staging bucket name.
  • The victim does not specify an explicit staging_bucket parameter when calling SDK methods like Model.upload(). When no bucket is specified, the SDK falls back to the deterministic default name.
  • On the attacker's side, the only requirements are a Google Cloud project – in any organization, using any billing account – and knowledge of the victim's project ID, which is often publicly discoverable.

High-Level Flow

The flow of attack phases reflects the key findings of our research:

  • Predictable bucket name and lack of ownership verification, enabling bucket squatting
  • Race condition window that can be exploited to hijack the model upload
  • Pickle deserialization as an RCE vector

Phase 1: Bucket Squatting

The attacker preemptively creates a bucket with the predicted name of the target's staging bucket, in the attacker's own project. The attacker then configures identity and access management (IAM) permissions so that any authenticated Google Cloud identity can read from and write to the attacker’s bucket. This is critical, as the victim's identity (that uploads the model) and Vertex AI’s service agent (which reads the model) must both be able to interact with the bucket.

The code snippet below illustrates how any authenticated user could interact with the bucket.

The legacyBucketReader role ensures that when the victim’s SDK checks whether the bucket exists, the bucket.exists() returns a True response. The objectCreator role allows the victim's SDK to upload artifacts. The objectViewer role allows the Vertex AI service agent to read the artifacts later.

Phase 2: Preparing the Model Replacement Function

The attacker deploys a Cloud Function, which is a serverless compute service in Google Cloud that executes code in response to events. The function is configured with a trigger on google.storage.object.finalize, which fires every time a new object is created (or overwritten) in the specified bucket. This means that the function automatically executes whenever the victim uploads a model artifact to the squatted bucket.

The attacker-created Cloud Function's logic is straightforward. When it detects a new model.joblib file in a vertex_ai_auto_staging path, it downloads the original file and replaces it with a pre-generated malicious payload.

The malicious payload is a joblib serialized Python object with a crafted __reduce__ method. To check the usage of this method, we set up a webhook that receives the victim's service account credentials. When the model is deserialized, it executes code that queries the Google Compute Engine (GCE) metadata server for the serving container's service account credentials and exfiltrates them to an attacker-controlled endpoint.

The reason we use a Cloud Function rather than polling the bucket is timing. According to our tests, the window between the victim's upload and the service agent read is approximately 2.5 seconds. A Cloud Function triggered by google.storage.object.finalize reacts within approximately 800 ms, leaving enough time to replace the file before the service agent reads it. In this way, the attacker wins the race. The victim uploads a legitimate model, but by the time the service agent reads it, the file has been swapped.

Phase 3: Victim Uploads a Model

The victim runs standard SDK code, without unusual configuration or security mistakes, as shown in the following code block:

Because no staging_bucket is specified, the SDK constructs the default name, finds that the bucket exists (which the attacker prepared in Phase 1) and uploads the model artifacts to the existing bucket’s location – the attacker’s project.

Phase 4: The Replacement

As a result of the victim's upload, the Cloud Storage finalize event triggers the attacker's Cloud Function, which immediately replaces the victim's legitimate model with the malicious payload. The entire swap occurs within the opportunity window, well before the P4SA reads the artifact. The service agent then reads the poisoned model instead of the original one, without the victim's knowledge.

The following timeline, captured from our proof of concept, illustrates the replacement flow:

T+0 ms Victim SDK uploads model.joblib (601 bytes)

T+804 ms Cloud Function detects new model

T+1,433 ms Cloud Function replaces new model with RCE payload (601→2,945 bytes)

T+2,460 ms P4SA reads the REPLACED model from the staging bucket

Phase 5: Victim Deploys the Model

The victim deploys the model to an endpoint using standard SDK calls, as shown in the following code block:

The victim has no indication that the model artifacts were tampered with.

Phase 6: Code Execution

When the serving container starts, it calls joblib.load() to deserialize the model. The __reduce__ method in the poisoned payload executes immediately, before the container performs any type validation on the loaded object. In our proof of concept, the payload:

  1. Queries the GCE metadata server for the service account email and OAuth access token
  2. Collects container environment variables (such as project number, endpoint ID, Kubernetes metadata)
  3. Exfiltrates the credentials to an attacker-controlled webhook

Figure 2 shows the six phases of the attack chain.

A diagram illustrating the attack phases of a cloud-based security breach. The phases include preparing a bucket, replacing a model, model upload, deploying the model, operating the model, and code execution. The process shows interactions between "Attacker Project," "User Project," and "Tenant Project." Arrows indicate data flow, including model upload, replacement, and deployment actions leading to credential exfiltration.
Figure 2. Attack chain flow.

Token Exfiltration, Post-Exploitation and Impact

The OAuth token that was exfiltrated to the attacker’s webhook belongs to a service account running in Google's managed tenant project, named custom-online-prediction@<tenant-project>.iam.gserviceaccount[.]com. This token has cloud-platform scope – the broadest possible scope in Google Cloud.

We found that this token allows access to several tenant project resources that extend well beyond the scope of the individual deployment:

  • Cross-deployment model theft: The service account can access GCS buckets belonging to other model deployments within the same tenant project. In our testing environment, we were able to discover and read model artifacts from other deployments, including a complete TensorFlow model with trained weights.
  • BigQuery reconnaissance: The token can enumerate all BigQuery datasets and table names in the victim's project, and read dataset access control lists. This exposes data schema, naming conventions and the identities of other service accounts with data access. This is valuable information for lateral movement.
  • Tenant infrastructure intelligence: The token can read Cloud Logging from the Google-managed tenant project, revealing internal infrastructure details like:
    • Google Kubernetes Engine (GKE) cluster names
    • Active prediction deployments from other workloads
    • Google-internal container image URIs
    • Kubernetes system identities

Mitigation and Collaboration With Google

We reported this vulnerability to the Google security team. Google deployed fixes in v1.144.0 on March 31, 2026 and in v1.148.0 on April 15, 2026.

Figure 3 shows the first fix: the addition of a uuid4 variable with a randomly generated value to the end of the bucket naming routine in the gcs_utils.py script.

A screenshot of a code comparison between two versions of a Python file. It highlights changes related to the creation of a staging bucket. The left side shows the old version where a specific bucket name is generated using a joined string and location. The right side, the updated version, adds a variable to the bucket name. Changes are marked with red and green highlights to indicate deletions and additions, respectively. A red arrow points to the new line with the UUID function.
Figure 3. Change log for the first fix. Source: GitHub.

Figure 4 shows the second fix: the addition of a bucket ownership verification check to the gcs_utils.py script.

A screenshot of a split view of a code file with differences highlighted in green and red. The left side displays the original code, and the right side shows modifications. A red arrow points to a line on the right side, indicating changes related to verifying bucket ownership in the Google Cloud platform utils script.
Figure 4. Change log for the second fix. Source: GitHub.

Disclosure Timeline

  • March 5, 2026: Vulnerability reported to Google Cloud via the Vulnerability Reward Program
  • March 9, 2026: Google assigned top priority to the report
  • March 10, 2026: Google acknowledged the vulnerability, assigned top severity and reported to the product team
  • March 31, 2026: Google deployed the first fix to production
  • April 15, 2026: Google deployed the second fix to production

Conclusion

The growing role of AI in production systems highlights the importance of continuously examining the security resilience of the platforms that support it. This research is one contribution to that effort, and we appreciate Google's collaboration in resolving the vulnerability.

Our research shows that cloud security extends into the developer toolchain and machine learning model lifecycle. The vulnerability that we discovered demonstrates how seemingly minor design flaws can lead to a critical security issue. In vulnerable versions of the SDK, this attack requires no access to the victim's project and no social engineering tactics, and could result in model poisoning, credential theft and cross-tenant compromise.

Google Cloud worked closely with Palo Alto Networks Unit 42 to resolve this issue through our Vulnerability Rewards Program (VRP). They deployed a permanent fix for the Vertex AI SDK for Python in version 1.148.0 on April 15, 2026.

We recommend that all developers update their SDK to version 1.148.0 or later to ensure the new bucket ownership checks are active. As an added best practice, when specifying an artifact_uri that isn't set to a Cloud Storage (gs://) location, users should set the staging_bucket parameter to a Cloud Storage location to help ensure full asset isolation.

Palo Alto Networks Protection and Mitigation

Palo Alto Networks customers are better protected from the threats discussed above through the following products:

Cortex Cloud

  • Organizations are better equipped to close the AI security gap through the deployment of Cortex AI-SPM, which delivers comprehensive visibility and posture management for AI agents across AWS, Azure and GCP environments, as described within this article. Cortex AI-SPM is designed to mitigate critical risks including, over-privileged AI agent access, misconfigurations, and unauthorized data exposure. Cortex AI-SPM enables security teams to enforce compliance with NIST and OWASP standards, monitor for real-time behavioral anomalies, and secure the entire AI lifecycle within a unified cloud security context.
  • Cortex Cloud Identity Security can also protect organizations from the techniques discussed in the article. Identity Security encompasses:
    • Cloud Infrastructure Entitlement Management (CIEM)
    • Identity Security Posture Management (ISPM)
    • Data Access Governance (DAG)
    • Identity Threat Detection and Response (ITDR)

The Unit 42 AI Security Assessment and Unit 42 Frontier AI Defense service can help identify and mitigate complex AI-specific risks.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 000 800 050 45107
  • South Korea: +82.080.467.8774

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Additional Resources

Inside the Modern SOC: The 72-Minute Race

Posted on by Ria Bhatia

The Speed Gap: Where Strategy Meets Reality

This marks the beginning of our series, Inside the Modern SOC: Trends and Insights from Unit 42 Managed Services. This series draws directly from Unit 42 customer environments, security operations center (SOC) assessments, threat hunting engagements and frontline investigation experience to highlight the operational patterns shaping modern security operations.

Through our work helping organizations detect, investigate and respond to threats, one theme continues to surface: The speed gap has become one of the defining operational challenges facing today's SOC. Drawing on findings from the 2026 Unit 42 Global Incident Response Report, we can see that attack timelines have compressed dramatically as adversaries use AI to move faster and automate more of the attack lifecycle. In the fastest cases, attackers moved from initial access to confirmed data exfiltration in just over an hour (72 minutes), representing a 4X year-over-year acceleration.

When security operations still rely on manual triage and fragmented workflows, defenders are forced to operate on a timeline modern attackers have already outpaced. This is not a personnel problem; it’s a process problem. By the time an alert is validated through manual steps, the adversary has often already achieved their objective.

Anatomy of a Modern Identity-Driven Attack

Across recent Unit 42 investigations, we continue to see a consistent pattern: attackers leveraging compromised credentials, identity manipulation, privilege escalation and rapid lateral movement to compress attacks that once unfolded over days into hours, or even minutes. Threat actors such as Muddled Libra (aka Scattered Spider) and Spoiled Scorpius, distributors of RansomHub ransomware, exemplify this broader trend.

The Attacker's Playbook in Action

The Social Entry: Initial access is often gained through compromised credentials, MFA manipulation, help-desk impersonation or other identity-based tactics. This pattern appeared across many of the investigations we handled over the past year. According to the 2026 Unit 42 Global Incident Response Report, 65% of initial access is driven by identity-based techniques.

The Rapid Escalation: Once inside, attackers frequently attempt privilege escalation and administrative account abuse within minutes or hours of gaining access. Unit 42 has observed suspicious identity activity quickly escalating into abnormal administrative behavior and signs of privilege escalation.

The Multi-Surface Pivot: Attackers increasingly move across identity, endpoint, cloud and Software as a Service (SaaS) environments. Once elevated privileges are obtained, they may provision cloud resources, create rogue virtual machines, mount virtual drives or establish persistence to support data staging and exfiltration.

The Rapid Impact: Unit 42 investigations continue to show attackers compressing the time between initial access and business impact. In some cases, threat actors such as Spoiled Scorpius have exfiltrated hundreds of gigabytes of data within hours of gaining access through improperly secured remote access infrastructure.

From a tooling perspective, the warning signs were often already present across the organization's identity and endpoint security controls. Multiple alerts had been generated, but without automated correlation, each appeared low priority in isolation. Connecting these signals manually takes time, a luxury attackers no longer allow.

How Our Unit 42 Managed Services Team Responds

In investigations involving identity-driven attacks, our analysts use the Cortex SecOps platform to quickly connect unusual privileged account activity, PowerShell execution, abnormal authentication patterns, privilege escalation attempts and lateral movement indicators to understand the full scope of an incident. Additional context, including device history, process activity, threat intelligence and behavioral analytics, helps determine whether activity is legitimate or indicative of attacker behavior. By analyzing these behaviors in context, our teams can quickly identify high-confidence incidents and contain compromised accounts before activity expands further across the environment.

Organizations using Managed XSIAM extend this model through AI-driven correlation, integrated response workflows and continuous SOC engineering that helps reduce investigation and response times. This shift from sequential investigation to real-time correlation helps security teams keep pace with compressed attack timelines. Instead of spending critical minutes manually stitching together fragmented alerts, analysts can move quickly from detection to confident response.

Advice for SOC Leaders: Re-Engineer for Velocity

Closing the speed gap requires evolving how your security operations function. Modern threats require an operating model that matches attackers’ velocity.

Move Beyond Sequential Workflows: Shift from linear "Triage → Investigate" models to workflows where enrichment happens automatically in parallel. Analysts should not need to manually search multiple tools to understand whether an alert is serious.

Correlate by Default: Related signals across identity, endpoint, cloud and network activity should automatically group into unified incidents. This reduces investigation time and helps eliminate analyst fatigue caused by fragmented tooling. Per the Unit 42 Global Incident Response Report, in 87% of incidents investigators reviewed evidence from two more distinct sources to establish what occurred. Complex cases drew on as many as 10 sources.

Operationalize Response: Predefine containment actions for common attack scenarios such as compromised accounts, suspicious PowerShell execution, malware activity or unauthorized remote access. When attackers move in minutes, response decisions cannot begin from scratch every time.

Prioritize Behavior Over Indicators: Focus on attacker behaviors such as rapid privilege escalation, impossible-travel logins, unusual access patterns or abnormal process execution chains. These behaviors often reveal malicious intent earlier than static indicators alone.

What's Next

In our next entry in this series, we'll explore another trend keeping security leaders up at night: Attackers have stopped "breaking in" and started "logging in." We'll examine how identity-based attacks are rapidly replacing malware as the preferred path to compromise and what organizations can do to defend against them.

The Unit 42 Managed Services Edge

We help organizations close the speed gap by combining expert-led operations with real-time detection, investigation, and response. Unit 42 Managed Detection and Response (MDR) combines AI-driven automation with world-class threat hunters, analysts, and responders who proactively uncover threats, investigate high-risk activity, and act quickly when minutes matter. Together, these capabilities help organizations accelerate detection, investigation, and containment while improving security outcomes.

For organizations pursuing broader SOC modernization, Managed XSIAM extends these capabilities with 24/7 expert-led operations, integrated response, continuous SOC engineering, and a breach response guarantee that includes 250 hours of Unit 42 Incident Response support. Together, these capabilities help organizations reduce operational complexity, strengthen security outcomes, and build a more resilient security operation prepared for today's threat landscape.

Learn more about Unit 42 Managed Services.

Tracing Digital Intent: New MacOS Tahoe 26 Artifact Discovered

Posted on by Ria Bhatia

Surfacing a New Artifact

Forensic examiners are constantly hunting for data that reveals not just what happened on a system, but the user's intent behind it. With the release of macOS Tahoe 26, a new artifact has surfaced that provides exactly this level of granularity. We have identified a new Biome stream, App.MenuItem, which logs specific menu selections made by users across the operating system.

This artifact offers a step-by-step record of user actions — from compressing files to emptying the trash — providing critical context for user activity across the operating system. This blog outlines where to find this artifact, how to process it and what stories the data can tell.

Apple Biome – A Gold Mine for Forensic Investigators

The Apple Biome system has long been a gold mine for forensic investigators, tracking everything from app usage to media consumption. In macOS Tahoe 26.x, Apple appears to have introduced a new stream specifically designed to track menu selections, likely to facilitate user suggestions or learning behavior.

Location and Structure

The artifact is located at ~/Library/Biome/streams/restricted/App.MenuItem/local. Unlike simple logs, this file contains SEGB-encapsulated protobuf entries. SEGB is the file format used by the Biome. While this format requires specific tooling to parse, the payoff is significant. The stream captures the exact text of menu items selected by the user, along with the timestamp of the activity, providing a narrative of their interaction with the interface.

Parsing the Artifact

Because standard forensic tools may not yet parse this specific stream, examiners can utilize open-source tools like ccl-segb to extract the raw data. In our testing, this artifact is not parsed by the most common commercially available digital forensic tools available.

To process the file:

  1. Export the file(s) from the directory ~/Library/Biome/streams/restricted/App.MenuItem/local.
  2. Run the ccl-segb Python script: python ccl_segb_cli.py <exportedfilename> > outputfilename.txt.
  3. Convert the resulting text output into a CSV format for easier filtering and analysis using a Python script.

Analyzing User Intent

The true value of App.MenuItem lies in its ability to reconstruct a user's workflow. Where a file system event might simply show a file was deleted, this artifact can show the deliberate action of selecting "Move to Trash" followed by "Empty Trash.”

Consider the following sequence of events observed in our sample analysis:

  • 18:32:37: The user navigates using Go > Go to Folder… in Finder.
  • 18:36:59: In TextEdit, the user selects File > Save…, followed by typing "u42validation".
  • 18:37:54: The user highlights a folder named "stolendata" and selects Compress “stolendata”.
  • 18:38:19: The user selects Move to Trash.
  • 18:38:41: The user interacts with the Dock to select Empty Trash.

In this scenario, we see a clear pattern: data creation, compression (likely for exfiltration) and subsequent cleanup. We even see interaction with specific UI elements, such as Copy and Paste Item later in the timeline.

Limitations

While powerful, this artifact is not without limitations. It relies on the menu item text itself. If a menu option does not explicitly contain the file or folder name (e.g., a generic "Open" command vs. "Compress 'Report'"), the specific target of the action might not be visible in this stream alone. However, when correlated with file system logs, App.MenuItem provides the "human" context that technical logs often miss.

Final Thoughts

The discovery of the App.MenuItem artifact in MacOS Tahoe 26 adds a powerful new layer to forensic investigations. By capturing the specific menu choices a user makes, examiners can reconstruct digital intent with greater precision than before. Whether you are investigating data exfiltration or trying to understand a sequence of events, this Biome stream provides a narrative view of user behavior.

As macOS continues to evolve, so must our forensic methodologies. We encourage all examiners working with Tahoe images to verify if this artifact is present and incorporate it into their standard analysis workflows.

Trust No Skill: Integrity Verification for AI Agent Supply Chains

Posted on by Yuhao Wu

Executive Summary

AI agents now extend their capabilities by installing third-party skills the way smartphones install apps. Anyone can publish a skill to a public registry. Anyone can install one into a production agent. And until now, no automated tool has verified what a skill does before it gains privileged access to credentials, files and shell commands inside that agent.

We introduce Behavioral Integrity Verification (BIV), an audit primitive that compares what a skill claims to do against what it does, across all three of its surfaces:

  • Metadata
  • Executable code
  • Natural-language instructions

Applied at registry scale, BIV finds that most skills deviate from declared behavior. The vast majority of those gaps are sloppy documentation, not malice. But a smaller, dangerous slice carries multi-stage attack chains, where individually benign-looking capabilities combine into credential theft, remote code execution or silent data exfiltration.

The agent-skill ecosystem now stands where mobile applications and browser extensions were a decade ago. Extensibility has outpaced the supply-chain audit primitives that should gate it. Security teams running large language model (LLM) agents in production should inventory the third-party skills installed and require a behavioral-integrity check before installation rather than after.

Palo Alto Networks customers are better protected from this type of issue through the following products and services:

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

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

Related Unit 42 Topics LLM, AI Agents, Supply Chain

Background

Enterprises now deploy LLM agents to automate tasks across code generation, IT operations, customer support and internal workflows. These agents are extended with skills, the agent equivalent of an app: a small package that bundles executable code with a YAML manifest and a natural-language SKILL.md file telling the agent when and how to use it.

Once installed, a skill runs inside the agent's privileged context. It can read environment variables, call external services, write files and execute shell commands on behalf of the organization.

Public agent-skill registries now host tens of thousands of these packages. Anyone can publish. Anyone can install.

The platforms that came before, package managers, mobile app stores and browser extension marketplaces, all eventually grew automated audit ecosystems after attackers turned the openness against users. The agent-skill ecosystem has not.

The audit problem in this ecosystem differs from anything earlier platforms faced. A skill's behavior splits across three modalities:

  • Metadata
  • Executable code
  • Natural-language instructions

The metadata declares what the skill is supposed to do. The code and instructions together drive what it does. No existing scanner reads all three, and the registry has no automated way to verify that the two sides match. BIV is the audit primitive that compares them.

The Method: Declared Vs. Actual Behavior

BIV asks one question of every skill: Does what it says match what it does?

To answer that question consistently across tens of thousands of skills, BIV needed a shared vocabulary. We used a fixed taxonomy of 29 capabilities organized into seven families:

  • Network
  • File system
  • Process execution
  • Environment
  • Encoding
  • Credentials
  • Instruction-level threats

Two parallel tracks populate the taxonomy:

  • The declared track reads the metadata. Deterministic parsers handle structural fields like YAML frontmatter and schemas. An LLM then reads natural-language descriptions (README, SKILL.md prose) to extract claimed capabilities, ensuring each claim is grounded in a quoted source span.
  • The actual track reads the code and instructions. Static analyzers cover code across multiple scripting languages (Python, JavaScript, shell) using abstract syntax tree (AST)-level taint analysis, regex and pattern matching. Separately, an LLM reads the natural-language instructions to surface prompt-injection and instruction-override motifs that traditional parsers miss.

A skill passes when its actual capability set fits inside its declared capability set. A skill fails when it does something it never disclosed (an under-specification, the operationally dangerous direction) or declares a permission it never exercises (an over-specification, almost always benign template residue).

Three filters keep the LLM components honest:

  • The first rejects any output that echoes the taxonomy verbatim.
  • The second rejects capability claims not anchored in a quoted source span.
  • The third requires domain-specific keywords in context for high-risk capabilities.

The pipeline ships with file-and-line evidence pointers, so every flagged deviation is auditable by hand.

Findings in the Wild

We crawled the OpenClaw agent-skill registry in early 2026 and ran BIV across all 49,943 listed skills. BIV surfaced 250,706 behavioral deviations, with 80.0% of skills (39,933) showing at least one mismatch between declaration and behavior.

A clustering pass over the deviation explanations produced a 137-cluster taxonomy and, notably, four novel compound threat categories. Each is a multi-step pattern:

  • Exfiltration chains (FILE_READ → base64 → NETWORK_SEND)
  • Remote code execution (RCE) chains (download → write → execute)
  • Code obfuscation (encoding chain → dynamic eval)
  • Data lineage violations (FILE_READ → FILE_WRITE, mostly benign data-pipeline boilerplate)

The threat lives in the chain, not the link. A scanner that checks one capability at a time sees a file read in one row and a network send in another and flags neither in isolation. BIV's contribution is the link between them.

A capability mismatch tells us that something undeclared is happening, not whether the developer was sloppy or hostile. BIV separates the two with a two-step intent classifier.

A deterministic rule engine resolves roughly two-thirds of cases at near-zero cost. An LLM classifier handles the rest by reasoning across a skill's full deviation list, so a multi-step chain is judged as a unit. Figure 1 breaks down 163,754 classified deviations by root cause.

Two side-by-side bar graphs comparing non-adversarial root causes (led by documentation errors) and adversarial threat categories (led by data theft and espionage) with case counts and percentages.
Figure 1. Intent classification of 163,754 clustered deviations.

Our analysis of this breakdown reveals that the skill ecosystem's primary failure mode is specification immaturity, not pervasive malice. Specifically, the classified data highlights two key themes:

  • 81.1% were traced to developer oversight. Documentation errors lead, followed by legitimate helper code, unused declarations and framework dependencies. These call for documentation outreach at the registry, not security review.
  • 18.9% were traced to adversarial intent. This adversarial slice concentrates sharply in data theft and espionage (60% of the adversarial total), then payload and infrastructure, and agent hijacking. Financial, destructive and social engineering combined come to under 1%.

When analyzed at the skill level, the registry decomposes into three governance tiers. The top tier is 5.0% of the registry (2,490 skills) that carry multi-stage attack chains and warrant mandatory security review. The middle tier is 16.8% that carry single-stage adversarial deviations and warrant contextual review. The remaining 72.5% are benign skills whose declared metadata simply needs to catch up to the code.

The top tier has structure worth leveraging. The 2,490 skills carrying multi-stage chains are not 2,490 unrelated alerts.

Two patterns dominate:

  • Silent credential exfiltration (read a secret, transmit it)
  • Instruction-override hijacking (take over the agent's decision loop, then exfiltrate)

Together, they cover 88% of all multi-stage chains. For an analyst running incident response or a registry operator setting review policy, this is operationally significant. The first 88% of the review effort can target two well-defined patterns instead of a flat list.

Where the Real Risk Concentrates

The adversarial fraction of deviations varies sharply across the seven capability families. A registry-wide threshold either over-blocks routine I/O skills or under-reviews the genuinely dangerous categories. Figure 2 plots each category by its adversarial fraction and deviation volume, with compound threat categories indicated by red stars.

Scatter plot mapping adversarial fraction against under-spec deviation volume (log scale). Red stars represent adversarial threats (like Obfuscation and RCE Chains), blue circles indicate system elements (like Network and Filesystem), a gray circle marks Encoding, and a large red circle highlights Credentials.
Figure 2. Per-category adversarial fraction plotted against deviation volume.

As the plot illustrates, three of the four compound threat categories sit in the high-adversarial region. Data lineage violations, dominated by benign data-pipeline boilerplate, is the outlier. We noted the following trends in other threat categories:

  • Instruction manipulation: 96% adversarial. The smallest established capability surface but the highest signal-to-noise ratio. Almost every undeclared prompt-control directive is suspect. This is the agent-specific attack surface that no prior third-party platform had to defend.
  • Credentials: 56% adversarial. It reflects the operational value of secrets to attackers.
  • Network: 37% adversarial. Mid-band; legitimate uses compete with exfiltration motifs.
  • File system (10%) and process execution (12%): Predominantly benign. Routine I/O and command invocation dominate raw volume but rarely indicate hostile intent on their own.

Operationally, this argues for per-category review tiers keyed to BIV's per-capability severity (Critical for credentials and instruction-level capabilities; high for network, process and environment access; medium for file system and encoding). A single threshold is the wrong instrument for this surface.

Beyond the per-capability picture, multi-stage compound chains define the highest-priority hunt patterns. The two dominant exfiltration patterns described above cover 88% of multi-stage chains; four long-tail patterns cover dropper-style payload delivery, encoding-based evasion, persistence and reconnaissance-then-exfiltration. Any installed skill matching one of these six patterns warrants mandatory review.

Conclusion

The agent-skill ecosystem mirrors an inflection point seen in mobile applications and browser extensions a decade ago, where extensibility similarly outpaced audit capabilities. Each of those earlier ecosystems stabilized only after automated cross-modality auditing became routine.

The proposed BIV method reduces the multi-modality audit problem to a typed comparison over a shared capability vocabulary. The same structured evidence supports a registry-scale deviation taxonomy and a two-step root-cause classifier.

The registry-scale findings reveal a clear operational strategy. Documentation interventions at the registry can address the 81.1% non-adversarial bulk. Security review efforts can then focus on the 18.9% that matters, specifically targeting the two dominant attack patterns.

The following limitations should be acknowledged.

  • BIV is static-only, dynamic dispatch and obfuscated payloads escape AST-level analysis.
  • Flagged skills are classifier-predicted candidates for review, not runtime-confirmed exploits.
  • The pipeline is not robust against an adversary who has read this paper and crafts descriptions calibrated to confuse the LLM adjudicator.
  • Backbone backdoors, retrieval-corpus poisoning and runtime memory poisoning fall outside scope and require complementary runtime defenses.

For organizations deploying LLM agents in production today, the action is concrete. Inventory the third-party skills installed and implement a behavioral-integrity check before installation rather than after.

We detailed the full methodology and complete registry-scale analysis behind this post in our research paper.

Palo Alto Networks Protection and Mitigation

Palo Alto Networks customers are better protected from the threats discussed above through the following products:

  • Prisma AIRS is designed to provide layered, real-time protection for AI systems by detecting and blocking threats, preventing data leakage and enforcing secure usage policies across a variety of AI applications.

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

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 000 800 050 45107
  • South Korea: +82.080.467.8774

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Additional Resources

Blinding the Watchmen: Abusing Cloud Logging Services for Defense Evasion and Visibility

Posted on by Yahav Festinger

Executive Summary

Cloud logging services provide comprehensive visibility into actions performed within cloud resources, making them essential for security monitoring. However, this reliance also makes logging services a high-value target for attackers. An attacker who exploits these services could create weak spots, evade detection, and in certain scenarios, establish continuous visibility within a target’s environment.

Services such as Amazon Web Services (AWS) CloudTrail and Google Cloud are powerful for defenders, and prime targets for attackers seeking to remain undetected by disrupting the flow of logs. Attack techniques against cloud logging services primarily fall into two categories:

  • Defense Evasion: Attackers aim to bypass detection systems, to execute attacks unnoticed. This may involve modifying resources within the cloud logging service.
  • Continuous Visibility: Attackers attempt to transfer logs to their own accounts, establishing continuous visibility over the victim's environment.

Understanding these attack scenarios enables organizations to implement the appropriate configurations and detect service misuse.

Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:

The Unit 42 Cloud Security Assessment is an evaluation service that reviews cloud infrastructure to identify misconfigurations and security gaps.

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

Related Unit 42 Topics Cloud, Logging, Google Cloud, AWS, S3 Bucket

Cloud Logging Services

Serving as the authoritative system of record for every event, cloud logging services provide complete visibility into all actions within cloud environments. This comprehensive data enables analysis of past behaviors for both operational debugging and security investigations.

Each cloud provider implements logging services in a unique way. Our recent Cloud Logging for Security article provides an overview of these various services across different cloud providers. In this article, we analyze and demonstrate attack techniques that target the primary logging services within each major cloud provider.

Before examining the logging capabilities offered by major cloud providers, we outline the fundamental components and mechanisms for log delivery. Our analysis focuses on AWS CloudTrail and Google Cloud Logging. Both of these widely used services are designed to provide comprehensive audit trails and operational insights. While this article focuses on specific services, the attack techniques presented may also apply to other cloud logging services.

Background: How Cloud Service Providers Handle Logs

AWS CloudTrail

AWS CloudTrail's primary resource for configurable log collection and delivery is known as a trail. A trail acts as a configuration that specifies how CloudTrail records AWS application programming interface (API) calls and related events in an AWS account. These events include actions taken by users, roles or AWS services.

The main function of a trail is to deliver these captured logs to an Amazon S3 bucket. S3 is a highly scalable, durable, secure object storage service. When a trail is configured, it continuously writes log files containing event records to the designated S3 bucket.

The S3 bucket serves as a centralized, long-term repository for CloudTrail logs. This enables auditing, security analysis and compliance efforts. CloudTrail supports sending native event trails to either the CloudTrail Lake feature, EventBridge or CloudWatch Logs. However, for enterprises with integrations to third-party products, these features might not be relevant or usable.

Google Cloud Logging

Cloud Logging is a fully managed service that collects logs from all of an organization’s Google Cloud resources. Cloud Logging leverages a resource called a sink as the primary mechanism for log delivery. A sink functions as a router that sends log entries to a specific destination. While a sink primarily routes and stores logs in centralized log buckets for analysis and retention, it also offers the flexibility to export logs to other powerful Google Cloud services. For example, logs can be routed to a cloud storage bucket for cost-effective long-term archival. When a sink is configured, it exports log entries that match specific criteria defined by a filter to a designated log bucket.

Defense Evasion

Sophisticated techniques enable attackers to remain undetected within a compromised cloud environment. These methods could involve manipulating or evading logging mechanisms, which are crucial for security monitoring and incident response. Obscured activities can extend an attacker's presence, facilitate data exfiltration or inflict more harm before being discovered.

A wide array of security products including the following are fundamentally dependent on this log data to function:

  • Security information and event management (SIEM)
  • Security orchestration, automation and response (SOAR) platforms
  • Specialized cloud security posture management (CSPM) tools

By disabling, altering or deleting these logs, an attacker can effectively hide themselves from these defensive systems, compromising the security integrity of the entire cloud environment. Attackers often use the following five techniques to accomplish this:

  1. Stop logging
  2. Delete the log storage destination
  3. Delete the log router
  4. Impair logging via attacker-controlled encryption key
  5. Log poisoning

Technique 1: Stop Logging

The most direct method to suspend log flows is to disable the logging mechanism itself. A wide array of security products is fundamentally dependent on this log data to function. By disabling these logs, an attacker can effectively blind defensive systems, compromising the security integrity of the entire cloud environment.

  • In AWS, an attacker with cloudtrail:StopLogging permissions can invoke the stop-logging API call for a specific trail. Once this API is executed, no further logs for that trail are written to the S3 bucket, creating an immediate visibility gap for organizations that created their own trails.
  • In Google Cloud, the equivalent action is disabling the sink. An attacker with logging.sinks.update permissions can set the sink’s disabled field to true to stop logs from being written. The Google Cloud console message shown in Figure 1 reflects this change.
A screenshot of a dialog box titled "Confirm disable sink." It states the sink to be disabled is "sink-blog-simulation." The message explains that disabling it will stop log export to this sink, and new logs will be lost unless captured by another sink. There are two buttons at the bottom: "Cancel" and "Disable," with a link for more options on log sinks.
Figure 1. Message confirming suspension of logs.

Technique 2: Delete Log Storage Destination

Typically, logs are stored in a cloud storage resource. An attacker who obtains permission to this resource could delete the cloud storage, preventing logs from being written. The following scenarios demonstrate this ability.

  • In AWS, an attacker with s3:DeleteBucket permissions can use the delete-bucket API to delete the S3 bucket; this action also requires the s3:DeleteObject permission to empty the bucket. A few minutes after the action, the associated CloudTrail trail's configuration will indicate this deletion, as the notification in Figure 2 shows.
A screenshot of a AWS CloudTrail displaying general details for a trail logging configuration. A red error message states "Bucket doesn't exist" with a "Fix policy" link. "Multi-region trail" is set to Yes, while "Apply trail to my organization" is Not Enabled.
Figure 2. An indication for the bucket deletion in AWS CloudTrail.
  • In Google Cloud, an attacker with logging.buckets.delete permissions can delete the log bucket. In the case of a log bucket, the deletion is not immediate. Once the delete command is issued, the log bucket enters a DELETE_REQUESTED state, remaining in that state for seven days. After this period, the bucket is deleted.
    Google Cloud offers a mechanism to protect against this deletion by providing the ability to lock the logging bucket. Once a bucket is locked, its retention policy becomes permanent and irreversible, meaning the bucket cannot be deleted by any user until every log entry within it has fulfilled the specified retention period.

Technique 3: Delete Log Router

Another defense evasion tactic involves deleting the log routing resource – for example, an AWS trail or a Google Cloud sink. Once deleted, new logs will cease to be written to the designated destination. An attacker can delete a log router by using the delete-trail AWS API or the google.logging.v2.ConfigServiceV2.DeleteSink Google Cloud method.

Technique 4: Impair Logging via Attacker-Controlled Encryption Key

​​An attacker could potentially render cloud logs unreadable by modifying their encryption key. An attack flow using AWS could unfold as follows:

  • When a trail is created in AWS, one of the configuration parameters is the key management service (KMS) key, which is used to encrypt the logs delivered by CloudTrail.
  • An attacker could prevent legitimate access to this key by updating the trail to use an attacker-controlled KMS key and then removing access to the key.
  • Consequently, logs will not be written to the bucket due to the inability to encrypt them with the unusable key.
  • To perform this attack, an attacker first creates an external KMS key with the policy shown in Figure 3 to ensure that the key is accessible to CloudTrail.
A code snippet showing a JSON policy configuration for AWS. The configuration permits CloudTrail access to a key.
Figure 3. Policy to create a KMS key with external access.
  • The attacker uses the update-trail API to modify the KMS key used to encrypt the logs in the S3 bucket.
  • Next, the attacker removes CloudTrail's access to the key by either deleting the key or removing the Allow CloudTrail to access the key statement from the policy. Subsequently, CloudTrail will indicate that there is a configuration issue due to denied bucket access, even though the bucket is correctly configured.
  • From this point on, logs will not be written to the bucket because the KMS key will be inaccessible. Figure 4 shows the message that is displayed after access is disabled.
A screenshot of AWS settings page displaying "General details." It shows "Trail logging" with a red icon and the message "Bucket access denied" with a link to "Fix policy." "Multi-region trail" is set to Yes, while "Apply trail to my organization" is Not Enabled.
Figure 4. Disabling access to the KMS key results in a Bucket access denied error.

Figure 5 shows the attack flow using AWS.

"A diagram illustrating a three-step attack process on AWS CloudTrail. Step 1: Victim account stores logs in an S3 bucket, encrypted with its own KMS key. Step 2: Attacker uses 'update-trail' API to change the KMS key to one they control. Step 3: Attacker removes CloudTrail access to the original key, preventing victim access to logs.
Figure 5. Impair logging via attacker-controlled encryption key attack flow in AWS.

An attack flow using this technique in Google Cloud is as follows:

  • In Google Cloud, a similar attack scenario can be simulated where a log bucket is already pre-configured with customer-managed encryption keys (CMEK). An attacker can then exploit this existing configuration by modifying the CMEK to reference an external key using the following command (the external CMEK must have encrypt/decrypt access granted to the KMS service account): gcloud logging buckets update BUCKET_NAME --location=LOCATION --cmek-kms-key-name FULL_KMS_KEY_NAME

Subsequently, the attacker can remove the permissions granted to the external key. At this point, the victim will be unable to read the logs, as the Google Cloud panel in Figure 6 shows.

A screenshot of a Google Cloud log analysis interface showing an error message. The left panel displays "Log fields data is unavailable because query is invalid." The main section shows a timeline graph with another message stating, "Log histogram is unavailable because query is invalid." Below the graph, a section reads, "Your input is invalid" with zero results listed.
Figure 6. The outcome of an inaccessible encrypted key.

Any attempts to revert the key will result in the error message “rekeying requires that the CMEK service account has decrypt access to the current CMEK key,” as Figure 7 shows.

A screenshot of a terminal displaying an error message related to Google Cloud. The error indicates a failed precondition due to credentials issues with a Google service account regarding GKE keys.
Figure 7. The outcome of an attempt to revert the key.

Technique 5: Log Poisoning

Another defense evasion technique is the direct modification of logs – known as log poisoning. This is an effective technique when logs are pre-configured to be written to a cloud storage resource. In this case, the logs are stored in JavaScript Object Notation (JSON) format and can be modified by an attacker. If stored logs are deleted, added or modified, there is a high likelihood that Security Operations Center (SOC) personnel or analysts would inadvertently use these poisoned logs to conduct log analysis.

  • In AWS, CloudTrail logs are delivered as objects to an S3 bucket. An attacker with s3:GetObject and s3:PutObject permissions on the bucket could download a log file, remove or alter specific events and then re-upload it, overwriting the original file. This breaks the chain of custody and invalidates the audit trail.
  • Figure 8 shows the response to a query from a scenario where an attacker alters a log to avoid detection, and then the victim inspects the log using Amazon Athena.
A screenshot of response to a query from an attack scenario.
Figure 8. Athena query analysis shows the modified log.
  • In Google Cloud, sinks route the logs to cloud storage. An attacker with storage.objects.get and storage.objects.create permissions can perform the same download and overwrite technique.

To mitigate the risk of log poisoning, AWS provides CloudTrail log file integrity validation. This feature provides the ability to cryptographically verify whether log files were modified after they were delivered by CloudTrail. This ability is enabled by default when using the AWS Console to create Trails, but not when using the API or command line interface (CLI).

Continuous Visibility

Upon gaining an initial foothold in a victim environment, an attacker with advanced capabilities would aim to establish long-term, passive visibility into the victim's cloud infrastructure. Instead of running noisy discovery commands that might trigger alerts – or if they lack proper permissions – an attacker can target the log routing mechanism to route logs to their own environment, resulting in real-time visibility. This enables attackers to perform continuous discovery and passively monitor all activity, from new VM deployments and IAM policy changes to sensitive data access. In this way, attackers can map the environment, identify high-value targets, and escalate privileges while potentially remaining invisible to the victim's security monitoring. The following techniques achieve continuous visibility:

  1. Configure new log routing resource
  2. Log redirection

Technique 1: Configure New Log Routing Resource

A direct method for achieving continuous visibility involves creating a new log routing resource – for example, an AWS trail or a Google Cloud sink. The attacker configures the newly created resource to direct logs to an external, attacker-controlled destination.

  • In AWS, the attacker configures CloudTrail logging to their own S3 bucket by using the create-trail API and specifying their bucket in the --s3-bucket-name parameter.
  • In Google Cloud, the attacker utilizes the logging.sinks.create API to set the DESTINATION parameter to the attacker’s intended resource.

Both of the above steps result in all logs being directed to the attacker's chosen destination.

For certain AWS accounts, the CreateTrail operation shows up in CloudTrail. If EventBridge is configured upon AWS account set-up, defenders can use EventBridge to alert on creation events. In this setup, subsequent describe calls of CloudTrail configuration will show the attacker's destination bucket. However, for organizations that use third parties or have not applied these configurations, attackers can carry out adversarial activities without being detected.

Technique 2: Log Redirection

Using this technique, the attacker alters the log routing destination to one within their own environment. This redirects logs to an attacker-controlled resource, enabling the attacker to obtain continuous discovery.

  • In AWS, the attacker updates the --s3-bucket-name parameter when invoking the update-trail API. After modifying the destination bucket, all logs are directed to the attacker’s bucket, providing continuous discovery capabilities on the victim’s account.
  • In Google Cloud, the attacker uses logging.sinks.update permissions to update the destination parameter, achieving the same ability to redirect logs.

Small enterprises that manage their own alert telemetry may notice that Trails have stopped working in this situation, but larger organizations may not be using AWS-native services that would allow them to detect this behavior.

Risk and Impact Assessment

Table 1 summarizes the evasion and visibility techniques, the likelihood that the activity is malicious, and the impact on logging services.

Technique Name Likeliness of Malicious Activity Primary Impact
Stop Logging High Total inability to view logs; usually precedes a larger attack.
Delete Log Storage Destination Medium Destruction of forensic evidence and archived log data.
Delete Log Router Low Disruption of the security pipeline.
Impair Logging via Attacker-Controlled Encryption Key Medium Logs exist but are rendered unreadable.
Log Poisoning Medium Degradation of data integrity.
Configure New Log Routing Resource Low Log exfiltration and potential covert persistence.
Log Redirection High Log exfiltration and potential covert persistence.

Table 1. Risk and impact assessment of evasion and visibility techniques.

Prevention and Awareness

The attack scenarios discussed all stem from modifications to logging service resources. Given the high value of cloud logging service resources, access should be restricted to highly privileged users to help prevent these scenarios. This measure reduces the likelihood of an attacker altering the configuration of such resources.

Amazon Web Services

For every AWS account there is an immutable 90 day CloudTrail Event History of all management events. This fallback ensures that these records cannot be deleted or circumvented. However, data and network events do not appear in this history.

In AWS, limit the update-trail API invocation to highly privileged users. Configure the bucket policy of the associated S3 bucket to prevent non-admin users from making configuration modifications. It's also crucial to ensure that only the CloudTrail service can write objects to these buckets.

Google Cloud

Google Cloud provides a similar safety mechanism to AWS, through its built-in log buckets. The _Required log bucket serves as an immutable repository for essential logs – such as Admin Activity and System Event audit logs – that cannot be disabled, modified or deleted. Alongside this, the _Default log bucket automatically captures a broader range of log entries for a shorter period of time. When creating logging storage for external integration purposes, these built-in buckets will not be relevant. As a result, those manually configured buckets may remain exposed to the specific attack techniques described in this article.

In Google Cloud, restrict the permissions for logging.sinks.update, and protect the destination resource.

Conclusion

Cloud logging services are fundamental for maintaining security posture and operational awareness, providing the definitive record of all activities within a cloud environment. The integrity of the logging infrastructure itself is a critical control, and for this reason has become a primary target for threat actors aiming to operate undetected.

The misuse of cloud logging services can have serious negative outcomes, enabling adversaries to cause blind spots for security teams, exfiltrate sensitive data in real-time, or methodically cover their tracks to evade forensics. By understanding the specific TTPs that threat actors use against these services, defenders can build more resilient detection and prevention strategies.

Palo Alto Networks Protection and Mitigation

Palo Alto Networks customers are better protected from the threats discussed above through the following products and services:

Cortex Cloud customers are better protected from the topics discussed within this article with cloud runtime security operations, through the collection, analysis, detection, alerting and prevention of malicious operations on cloud platform and SaaS application audit logs. Using behavioral and static alerting techniques on cloud logs during cloud operations runtime, the techniques discussed within the article can be identified and trigger alerts which provide early warning – and in some cases, prevention operations to prevent further compromise from these attacks.

The Unit 42 Cloud Security Assessment is an evaluation service that reviews cloud infrastructure to identify misconfigurations and security gaps.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 000 800 050 45107

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Additional Resources

Cortex XDR Alerts on Cloud Logging Services Misuse

Table 2 shows the Cortex alerts that are triggered by this activity in cloud logging services.

Alert Name MITRE ATT&CK® Tactic
AWS CloudTrail has been stopped Defense Evasion (TA0005)
AWS CloudTrail modification Defense Evasion (TA0005), Discovery (TA0007)
Google Cloud logging sink modification Defense Evasion (TA0005), Discovery (TA0007)
Google Cloud Logging Bucket Deletion Defense Evasion (TA0005)
CloudTrail logging deletion Defense Evasion (TA0005)
Google Cloud logging sink deletion Defense Evasion (TA0005)
Logging was impaired via external encryption key Defense Evasion (TA0005), Impact (TA0040)
Suspicious activity on logging bucket Defense Evasion (TA0005)

Table 2. Cortex alerts that indicate malicious activity in cloud logging services.

Threat Brief: Active Exploitation of PAN-OS CVE-2026-0257

Posted on by Unit 42

Palo Alto Networks Unit 42 has observed active exploitation of PAN-OS vulnerability CVE-2026-0257 by an unidentified threat actor attempting to access GlobalProtect. This security flaw involves an authentication bypass in the portal and gateway components of vulnerable versions of PAN-OS® software, which could allow unauthorized attackers to circumvent security controls and initiate VPN connections. This CVE was added to the Known Exploited Vulnerability (KEV) catalog on May 29.

No post-access behavior or lateral movement has been identified as of this time. Only a small portion of the probed devices actually established VPN sessions, resulting in gateway-connected events.

We advise organizations to proactively hunt for the indicators of the activity specified in this report and activate incident response protocols for any successful gateway-connected events linked to these indicators. Additionally, we strongly recommend reviewing the security advisory for CVE-2026-0257, following the available workarounds and mitigations or upgrading to a version that includes a fix for this issue.

For pre-Proof of Concept release (May 29, 2026) activities, search for these IP addresses in GlobalProtect logs to look for successful login connection:

  • 23.128.228[.]6
  • 104.207.144[.]154
  • 146.19.216[.]119
  • 146.19.216[.]120
  • 146.19.216[.]125
  • 179.43.172[.]213
  • 185.195.232[.]139
  • 198.12.106[.]60
  • 202.144.192[.]47

Search GlobalProtect logs for successful gateway-connected events from any IP address using suspicious host IDs or device names, including but not limited to:

  • aa:bb:cc:dd:ee:ff
  • 00:11:22:33:44:55
  • WINDOWS-LAPTOP-001
  • DESKTOP-GP01
  • GP-CLIENT

As part of post-PoC release monitoring, search GlobalProtect logs for successful gateway-connected events matching the following hard-coded client configuration values from the PoC code.

  • endpoint_os_version : Microsoft Windows 10 Pro 64-bit
  • source_user_info.domain : empty

We encourage organizations to consult the official Palo Alto Networks Security Advisory for additional details about the vulnerability, impacted products and configuration guidance. We also recommend reading Rapid7’s technical analysis about the exploitation activity they observed in the wild.

Palo Alto Networks Cortex Xpanse is able to identify publicly exposed PAN-OS gateways and GlobalProtect portals.

Palo Alto Networks has shared our findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

We will update this threat brief as more relevant information becomes available.

The products listed below can help protect PANW customers against exploits targeting CVE-2026-0257.

Palo Alto Networks Product Protections for PAN-OS CVE-2026-0257

Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat.

If you think you might have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 000 800 050 45107
  • South Korea: +82.080.467.8774

Cloud-Delivered Security Services for the Next-Generation Firewall

Advanced URL Filtering can identify known IP addresses associated with this activity as malicious.

Cortex AgentiX

Security analysts can use natural language to prompt the Cortex AgentiX Threat Intel agent to extract file indicators from this threat brief. They can then enrich them, check for sightings in their Cortex tenant and related alerts, and provide a quick summary of the impact to the organization.

Cortex XDR and XSIAM

Cortex XDR and XSIAM provide comprehensive protections for endpoint attacks. It helps block post-exploit activity with its Behavioral Threat Protection, AI-driven local analysis, cloud-based malware analysis and other security engines across Windows, Linux, and Mac systems.

Indicators of the Activity

IP Addresses

  • 23.128.228[.]6
  • 104.207.144[.]154
  • 146.19.216[.]119
  • 146.19.216[.]120
  • 146.19.216[.]125
  • 179.43.172[.]213
  • 185.195.232[.]139
  • 198.12.106[.]60
  • 202.144.192[.]47

Host Names and Mac Addresses

  • aa:bb:cc:dd:ee:ff
  • 00:11:22:33:44:55
  • WINDOWS-LAPTOP-001
  • DESKTOP-GP01
  • GP-CLIENT

Additional Resources

Updated June 9, 2026, at 11:45 a.m. PT to add XDR and XSIAM product coverage language.

When “Hi, This Is IT” Comes Through Microsoft Teams

Posted on by Ria Bhatia

"Hi, IT Department Here!"

It's Friday afternoon. The week has been busy, and everyone is wrapping up before the weekend. One of your workers receives a message (Figure 1) through Microsoft Teams from what appears to be the IT Service Provider.

Figure 1. Simulated Microsoft Teams message request.
Figure 1. Simulated Microsoft Teams message request.

The message is marked as external. The worker previews the message and sees, "Hi, this is the IT Department. We see an issue with your account." The message looks routine and is in MS Teams, not email. The worker accepts the message. The conversation proceeds and the "IT technician" explains that a login anomaly was detected and asks the worker to approve a multi-factor authentication (MFA) prompt to confirm their identity. The conversation continues for a few minutes to maintain credibility, but behind the scenes the compromise is already underway.

This scenario shows how access to trusted internal communications channels allows threat actors to manipulate employees into taking actions that lead to compromise. Recent events utilizing this technique include:

  • Cloaked Ursa (aka APT29, Cozy Bear and Midnight Blizzard) has successfully operationalized this approach. We reported in late 2024 how the threat actor leveraged compromised accounts to send MS Teams messages containing malicious links that redirected victims to credential harvesting pages mimicking legitimate Microsoft login portals.
  • In December 2025, a threat group tracked by Mandiant as UNC6692 used MS Teams to impersonate IT helpdesk staff. The threat actors convinced targeted employees to accept a Microsoft Teams chat invitation from an account outside their organization.

The Rise of Chat-Based Social Engineering

Threat actors have increasingly moved away from traditional phishing techniques toward trusted collaboration tools. In the first four months of 2026, phishing alerts from collaboration tools represented 42% of all phishing alerts in Cortex, up from 30% of all phishing alerts in the preceding four months. Organizations continue to make progress in the effort to prevent email phishing. Email gateways are more intelligent. Awareness training and regular phishing simulations have conditioned users to be cautious with email, but far less so with collaboration tools. Using collaboration tools for malicious operations helps a threat actor blend in with legitimate operations. Threat actors know this and use collaboration tools for phishing, with Microsoft Teams being one of those tools.

Unit 42 has observed threat actors initiating chats with employees in victim organizations through Microsoft Teams using a range of techniques designed to mask their true identity and appear legitimate. Recent activity includes threat actors leveraging typosquatted domains that closely resemble trusted vendors or internal naming conventions. They also sometimes operate from Microsoft 365 tenants that have no previous affiliation with the target organization. In many cases, these tenants are deliberately named to mimic IT support functions, security teams or managed service providers.

In many organizations, Teams federation is enabled by default, allowing users to communicate with external tenants unless restricted by policy. In more advanced scenarios, threat actors bypass the need for deception altogether by compromising legitimate service provider or partner accounts, and leverage existing trust relationships to initiate chats from domains that are already recognized and allowed.

These chat messages can appear directly in an employee’s feed. Microsoft Teams has an impersonation protection feature that presents additional warnings to the chat recipient, but the onus is still on the user to decide whether to accept the message as legitimate. While Teams provides visual indicators that a sender is external, users may overlook these warnings when the sender appears to represent a known vendor, partner or internal support function. Threat actors count on this combination of visual and domain familiarity to impersonate trusted entities. This lowers user suspicion and increases the likelihood of successful social engineering.

As defenders, we must shift the burden away from the user and prevent as many of these malicious chat requests from reaching the user in the first place.

Hardening Microsoft Teams Against External Abuse

Threat actors like Cloaked Ursa succeed not because MS Teams is insecure, but because external communication settings are often too permissive and users tend to trust internal tools.

Effective defense combines user awareness along with strict configuration and identity-centric controls. We discuss these defenses briefly below. Please refer to Microsoft's Best Practices documentation for a more complete discussion of MS Teams security configuration.

User awareness is important and it needs to evolve beyond typical email phishing training. Workers should be explicitly taught that MS Teams messages can originate from outside the organization and are not inherently trustworthy. Training should involve real-world scenarios such as unsolicited “IT support” messages, requests to approve MFA prompts and instructions to reset credentials. These scenarios should teach users to recognize external indicators in MS Teams, to question unexpected outreach and to verify requests through a separate channel such as a help desk number or internal ticketing system.

Securing MS Teams communication involves configuring who users can interact with via chat. One set of configuration settings, shown in Figure 2 below, controls unmanaged or personal accounts. The setting "External users with MS Teams accounts not managed by an organization can contact users in my organization" controls communication initiated by unmanaged or personal accounts. When enabled, it permits users outside of an organization to initiate conversations. If business cases allow, this setting should be disabled to prevent external users from initiating MS Teams chats with internal users. The parent control for this setting is stricter and named "People in my organization can communicate with unmanaged MS Teams accounts." Toggling this setting to "off" completely disables communication with unmanaged or personal accounts, and should be considered if business cases allow.

Figure 2. Microsoft Teams controls for unmanaged or personal accounts. Source: Microsoft

A second and more impactful setting governs federation and is shown in Figure 3. This setting determines whether users from other Microsoft 365 tenants can communicate with your organization. In practice, many companies leave federation open, enabling communication with any external domain. This creates a large and potentially unmonitored attack surface. If business cases allow, a more secure configuration is to choose "Allow only specific external domains" and then add domains with which the organization typically communicates to an Allow list.

Figure 3. Microsoft Teams controls for federation. Source: Microsoft.

Attacks initiated through MS Teams chats ultimately target identity systems. Because of this, MS Teams hardening should include a review of broader identity protections. Conditional Access policies can ensure that even if a user is manipulated, high-risk actions require additional verification or compliant devices. Privileged roles should be governed through just-in-time access models such as Entra Privileged Identity Management, which reduces the impact of any single compromised account. For additional information on cross-tenant intrusions including Teams, please see Microsoft's mitigation and protection guidance on this topic.

Monitoring also plays a critical role here. External chat initiation should be treated as an event worth investigating, particularly when from previously unseen or typosquatted domains, or if followed by authentication anomalies or device registration events. If malicious chats should get through to one or more users, administrators can remove those chats from users' views to prevent future interaction. Organizations with appropriate Microsoft licensing can enable users to report suspicious Teams messages from chats and channels, similar to the "Report Phishing" function in email.

Final Thoughts

The takeaways are simple but important:

  • If external chat is open, attackers will use it. Tightening controls around external chat will reduce risk by constraining an entire attack vector. This reduces the chance of phishing chats reaching the user.
  • Users are conditioned to identify email phishing. Extending user phishing training to cover Microsoft Teams and other collaboration tools creates better awareness and lessens the likelihood of success of a phishing chat that gets through to a user.

Additional Resources

A New Phishing Frontier: From Email to SaaS Collaboration Apps – Palo Alto Networks

How UNC6692 Employed Social Engineering to Deploy a Custom Malware Suite | Google Cloud Blog – Mandiant

Prevent spam or phishing attempts from external chats in Microsoft Teams – Microsoft

Teams security best practices for safer messaging - Microsoft Teams – Microsoft

IT Admins - Manage external meetings and chat with people and organizations using Microsoft identities – Microsoft

Prevent spam or phishing attempts from external chats in Microsoft Teams – Microsoft

Cross‑tenant helpdesk impersonation to data exfiltration: A human-operated intrusion playbook – Microsoft

Remove an external chat from a user's view in Microsoft Teams (admin) – Microsoft

End user reporting for security - Microsoft Teams – Microsoft

 

Operation FlutterBridge: macOS Malvertising Campaign Spreads New FlutterShell Backdoor

Posted on by Samantha Stallings

Executive Summary

We are tracking an increasingly widespread malvertising campaign targeting macOS. This campaign appears to be the next stage of a previous campaign known as JSCoreRunner, which was first identified in August 2025. In recent months, the financially-motivated attackers behind these campaigns transitioned from delivering standard adware, to delivering adware with full backdoor capabilities. We designate this campaign Operation FlutterBridge, and we call the payload that it delivers FlutterShell.

Built using the Flutter framework, FlutterShell infects targets with adware via malicious desktop applications. In addition to its adware functionality, the payload possesses backdoor capabilities, including shell command execution and file system manipulation. Some variants weaponize artificial intelligence (AI) summarization features for data exfiltration by routing documents through an attacker-controlled server before processing them. The FlutterShell malware strain appears to be under active development, with new improvements being rapidly integrated into the code.

Operation FlutterBridge targets a global audience through an extensive Google Ads campaign, with an emphasis on Anglophone and Western European markets, distributed via hundreds of Google-verified advertisements. Our research indicates that the attackers behind this cluster distributed the ads using a series of shell companies, to bypass ad-network vetting and orchestrate these attacks at scale.

We reported these advertisers to Google, which provided the following statement:

Malware has no place on our platforms, and we’ve suspended these advertiser accounts for violating our policies.

We track Operation FlutterBridge and the JSCoreRunner campaign under a cluster of activity that we refer to as CL-CRI-1089.

This article provides a technical overview of the FlutterShell macOS malware and the delivery network behind the malvertising campaigns.

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

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

Related Unit 42 Topics macOS, Malvertising

Campaign Background

CL-CRI-1089 is a cybercrime cluster of activity that has been operational since at least 2023. The attackers behind this cluster are responsible for spreading malicious payloads via malvertising campaigns, targeting both Windows and macOS users through separate, ongoing operations.

The attackers’ modus operandi is consistent across these operations: They distributed malicious advertisements using a network of Google-verified shell companies. These ads were designed to trick targets into deploying malware that masquerades as legitimate desktop applications. While in-the-wild observations suggest the malware functions primarily as adware, it possesses capabilities for far more dangerous behavior, effectively functioning as a backdoor.

Operations attributed to this cluster include the RecipeLister and Calendaromatic Windows campaigns, as well as the JSCoreRunner macOS campaign. The Windows activity was previously tracked by other vendors under the broader “TamperedChef” designation, before Unit 42 researchers deconstructed the activity into distinct clusters. In late 2025, the attackers expanded their operations with Operation FlutterBridge, deploying a new macOS backdoor identified as FlutterShell.

Overview of the FlutterShell Malware

FlutterShell is a macOS backdoor developed using the Flutter framework and designed to masquerade as legitimate software. FlutterShell’s authors implemented a WebView-based architecture that utilizes a JavaScript-to-native bridge. This design allows the attackers to host malicious logic on an external website, rather than hardcoding it into the binary. This enables the attackers to dynamically alter FlutterShell's behavior in real time, without needing to recompile or redistribute the application.

FlutterShell has a set of built-in commands that provide attackers with the following capabilities:

  • Arbitrary command execution
  • File system interaction
  • Environment variables exfiltration

During our investigation, we observed FlutterShell being used as adware. Upon execution, the malware modifies Google Chrome configuration files to hijack the browser, forcing all traffic through an attacker-controlled, ad-filled intermediary site.

We identified several versions of FlutterShell that did not yet contain malicious code. Additionally, an examination of the JavaScript logic hosted on the attackers’ infrastructure revealed multiple unfinished functions. These findings, combined with the frequent appearance of new variants, indicate that the malware is likely under active development.

The use of the Flutter framework presents specific analytical hurdles. The Flutter engine compiles Dart code into a dynamic library and uses an Object Pool to store data. This separates the code from the strings and variables it uses, making it difficult for security analysts to see how the malware actually functions. This feature also makes tracing the execution flow of a Flutter application via static analysis particularly challenging. To overcome these challenges, we used a custom version of Worawit Wangwarunyoo's blutter tool to disassemble the Dart binary and reconstruct the application logic.

FlutterShell Deployment and Masquerading

We encountered three versions of FlutterShell in which the malware posed as a podcast player and two different PDF viewers. These desktop applications were fully functional, effectively concealing the malicious logic executing in the background. Figure 1 shows two of the applications on macOS hosts.

A screenshot of a computer screen split into two main sections. On the left, a podcast application displays a selection of podcast covers, including "The Daily," "Pardon My Take," and "Science Vs." On the right, a PDF viewer application is open, displaying a password-protected file message prompting to unlock the PDF. The background shows a forest scene with tall trees.
Figure 1. FlutterShell masquerading as a legitimate podcast player and PDF viewer application.

All observed samples were signed with valid Apple Developer IDs and successfully passed notarization, meaning Apple's automated security checks did not flag them as malicious at the time of submission. Figure 2 shows the legitimate signature of FlutterShell’s binaries and its successful notarization by Apple.

A screenshot of a notarization confirmation window for the application "podcasts_lounge," signed by Apple Dev ID. It includes details about the file path, entitlements, and signing authorities. The window features buttons for viewing hashes and entitlements, and a close button.
Figure 2. FlutterShell is signed with valid Apple Developer IDs and successfully passed notarization.

At the time of analysis, all three applications containing FlutterShell had zero detections on VirusTotal, as shown in Figure 3 for the PodcastsLounge application.

A screenshot of a security check from VirusTotal indicating a file is safe. It shows a score of 0/65, meaning no security vendors flagged the file as malicious. The file details include a string of alphanumeric characters and the name
Figure 3. Malware analysis conducted on VirusTotal.

FlutterShell Technical Analysis

FlutterShell’s Malicious WebView Architecture

The FlutterShell backdoor logic is not hardcoded into the binary. Instead, FlutterShell employs a WebView-based architecture utilizing a JavaScript-to-native bridge.

In WebView-based architecture, a native application uses an embedded web browser component to display content. The JavaScript-to-native bridge acts as a communication channel between this web content and the host native application, allowing them to exchange data and cross-invoke functionality.

Consequently, the malicious logic of FlutterShell is stored on the attackers’ website and is only triggered when the application loads the specific web content. Figure 4 demonstrates how the application converts web content to native commands.

A diagram illustrates the flow of code execution in an application. It includes a WebView Engine that requests and returns web content, a JavaScript Bridge, and the main components of macOS. The setup interacts with a network, performs command execution, and accesses the file system. The bridge facilitates code execution from WebView to native macOS components.
Figure 4. WebView architecture to native OS code execution graph.

Upon initial execution, FlutterShell waits for a specific duration received dynamically from the command and control (C2) server before contacting the attackers’ website — which contains the malicious JavaScript code — to avoid analysis and build user trust. More details about the backdoor’s delay routine are provided in Appendix A.

JavaScript Bridge Injection Technique

The primary payload of FlutterShell is embedded within the main webpage and a /update-thanks.html subdirectory of the attacker-controlled site. Figure 5 shows the website's landing page.

A software update screen for Podcast Lounge shows a success message. The update features version 1.0.1, with an update date of January 1, 2026, and the status is "Up to Date." The background is a gradient from purple to blue.
Figure 5. “Thank You for Updating!” landing page that hides the malicious logic of FlutterShell.

To facilitate communication between the remote attacker-controlled webpage and the infected local system, the malware injects a JavaScript bridge. This bridge uses a message channel named flutterInvoke to pass JSON-formatted commands from the WebView context into the native Dart environment.

The remote webpage acts as the execution environment for the JavaScript-to-native bridge. By loading the external content, the attackers can send JSON-formatted commands to the application, which are then translated into native system calls and operations on the infected machine.

The main webpage and the /update-thanks.html subdirectory retrieve the core malicious logic from external endpoints: /getConfig and /getUpdateThanksConfig, respectively. These scripts contain the JavaScript code that defines which commands should be executed and configures the supported functionality. This architecture allows the attackers to modify the code in /getConfig and /getUpdateThanksConfig at any moment, dynamically altering FlutterShell's behavior without requiring a software update. Figure 6 shows the HTML page presented to the targeted end-user, followed by the subsequent JavaScript code executed by the payload.

A screenshot of JavaScript code. The function `loadConfig()` loads a script dynamically. If the loading succeeds, a console message confirms success, and a button's text changes to indicate success. If it fails, an error message is logged, the button is enabled, and the text changes to prompt a retry.
Figure 6. JavaScript code in /update-thanks.html responsible for retrieving the malicious logic.

At the time of investigation, the call to /getConfig was either commented out on the main page or the endpoint was unreachable. We also noticed that /getUpdateThanksConfig contained setup functions for commands that were not yet implemented in the FlutterShell binary. The observed inactivity and disabled functions strongly indicate that the malware was still under active development.

Variants and Evolution of FlutterShell

Our investigations up until February 2026 revealed three main variants of the FlutterShell backdoor, each advertised approximately one month apart. The first variant masqueraded as a podcast app named PodcastsLounge while the subsequent variants appeared as PDF viewers named PDF-Brain and PDF-Ninja.

While the three variants masqueraded as different applications, the malicious code and execution flow embedded within them have only minor differences. Notably, the internal package name of the PDF-Brain variant was still labeled podcasts_lounge, revealing its connection to the earlier version.

With each new variant released, we observed developments in the obfuscation used by the attackers behind the campaign. The second variant (PDF-Brain) had some of its strings obfuscated, and the third variant (PDF-Ninja) utilized Flutter’s native --obfuscate flag, which strips debug information and randomizes symbol names, making reverse engineering significantly more difficult. Furthermore, the attackers renamed the malicious commands to mimic legitimate PDF library operations, likely in an attempt to bypass static analysis and Apple's notarization process.

The main differences and overlaps between the three variants are listed in Table 1.

Feature Variant: PodcastsLounge Variant: PDF-Brain Variant: PDF-Ninja
Execution Command exec_sync pdf_sync renderPDF
Command Naming Scheme Descriptive naming 

(e.g: read_file, write_file)

 Descriptive naming 

(e.g: read_file, write_file)

 Deceptive naming 

(e.g: read_pdf, write_pdf)
String Storage (/bin/sh ) Plaintext Base64-encoded Plaintext (regression)
Binary Obfuscation None None Flutter --obfuscate enabled
C2 Domain atsheisdomestic[.]org etoftheappyrince[.]org healightejustb[.]org

Table 1. Feature comparison matrix of FlutterShell variants.

Another feature differentiating the PDF-Brain and PDF-Ninja variants is an AI summarization tool that doubles as a data exfiltration vector. Instead of sending the file content directly to an AI Agent, FlutterShell forwards the content to the attackers’ C2 server, at the https://[attacker_domain]/summarize-text endpoint. The server functions as an intermediary, forwarding the request to the AI agent. This means that while the user receives an AI summary, the attackers can simultaneously harvest and exfiltrate the entire content of every document processed.

Additionally, we observed that the download sites for PodcastsLounge and PDF-Brain malicious applications share a nearly identical design structure, indicating that the attackers reused the web assets for both campaigns. Figure 7 shows screenshots from both sites.

Two screenshots of side-by-side website interface designs. The left side is for "Podcasts Lounge," featuring options to listen, discover, and manage podcasts, with highlighted buttons for exploring and downloading. The right side is for "App Denise," focusing on viewing and editing PDFs, with options to download and learn more. Both interfaces have prominent color schemes and feature navigational buttons and text.
Figure 7. PodcastsLounge delivery website (left) and PDF-Brain delivery website (right).

We also encountered versions of these macOS applications that did not contain any malicious code.

We also noted that the attackers behind CL-CRI-1089 offered Windows versions for all FlutterShell applications. However, up to early February 2026 the Windows versions did not appear to contain any embedded malicious logic. The absence of malicious code in both the macOS and Windows applications may suggest a phased deployment strategy, a technique designed to bypass automated detection.

FlutterShell’s Adware Payload

According to our telemetry, the attackers’ primary goal appeared to be browser hijacking. Upon installation, FlutterShell fingerprints the machine by collecting the hardware’s universally unique identifier (IOPlatformUUID) value using the following command:

ioreg -rd1 -c IOPlatformExpertDevice | grep IOPlatformUUID | sed 's/.*"IOPlatformUUID" = "//; s/"//g'

Next, the malware targets the Google Chrome “Secure Preferences” file. This file functions as an anti-tamper mechanism by storing a validated copy of the user's settings.

FlutterShell modifies the default_search_provider_data block within this file, specifically changing the url and new_tab_url values to the attacker-controlled domain sinterfumesco[.]com. This modification ensures that every time a user with an infected machine performs a search or opens a new tab, the request is hijacked and sent to the attackers’ domain. Figure 8 shows the modified Secure Preferences file.

A screenshot of code displaying JSON data is shown. Red boxes highlight changes made to two fields: "new_tab_url" and "url," with both values altered.
Figure 8. The modified Secure Preferences file.

To apply the URL and domain changes, FlutterShell terminates the Google Chrome process using killall "Google Chrome" and immediately relaunches the process with the following arguments:

Google Chrome "hxxps[:]//sinterfumesco[.]com/search?utn=[Tracking Data]=&q=starttt" --restore-last-session --hide-crash-restore-bubble --noerrdialogs --disable-session-crashed-bubble

These flags force Chrome to connect to sinterfumesco[.]com while suppressing the crash restoration warnings (“Chrome did not shut down correctly”) that would normally appear after a forced termination.

This sequence enables attackers to generate revenue by funneling targeted users through an ad-filled intermediary site or showing ads in the background, before finally redirecting the users to a legitimate search engine. Figure 9 shows the detection of suspicious FlutterShell activity, including executing fingerprinting commands and browser hijacking.

A diagram shows a flow of actions related to the "podcasts_lounge" app. It consists of nodes connected by lines with arrows. Annotations detail commands for executing a fingerprint command and launching Google Chrome with a specific URL. The bottom includes a table listing file actions involving Google Chrome preferences and login data.
Figure 9. FlutterShell browser hijacking activity, as seen in Cortex XDR.

CL-CRI-1089: Campaign Infrastructure and Evolving Tradecraft

We examined the evolution of CL-CRI-1089’s tactics and tradecraft across multiple campaigns since early 2025.

CL-CRI-1089 Ads Delivery Network

Our investigation tracked the activity cluster CL-CRI-1089 through a far-reaching network of Google and YouTube advertisements, both of which are controlled by Google Ads. While Google apparently remediated several ads linked to previous campaigns, the advertiser remained active, and FlutterShell continued to be distributed via hundreds of active advertisements with new instances throughout February 2026.

Verified Shell Entities

Verified Google Ads accounts were the primary distribution vehicle for FlutterShell in this campaign, using verified shell companies AdsParkPro LTD and Advantage Web Marketing LLC. We also observed that this cluster used a different shell entity called SOFT WE ART LIMITED in past Windows campaigns. At first glance, these companies appeared to be legitimate Ukraine and UK-based enterprises, registered years before the malicious activity ever started. Figure 10 shows advertisements by Advantage Web Marketing LLC in the Google Ads Transparency Center.

A webpage displaying advertisement details for "Advantage Web Marketing LLC," based in Ukraine. There are four ad examples listed: "View Template (PDF)," "Print Now (Calendar)," "Printable PDF (Free)," and "Start Download (Free)." Each ad is associated with Convert Flow - Advanced PDF Software.
Figure 10. Tracking Advantage Web Marketing LLC advertisements in Google Ads Transparency Center.

However, although the accounts were verified by Google Ads, a closer look into the three companies revealed the hallmarks of a shell corporation designed for ad-fraud and malware delivery:

  • All three companies have a minimal digital presence beyond their company websites. The websites themselves have minimal functionality and utilize templated structures, likely designed to create an impression of legitimacy.
  • Similar patterns in corporate filings revealed one Ukrainian-based and two UK-based companies led by Ukrainian nationals with no verifiable professional history or digital identity.
  • We identified an approximate one-year latency between the initial Google Ads registration and the first recorded ad spend. This suggests a maturation strategy, in which the attackers allow a legal entity to age, in order to bypass initial fraud-detection filters.

Given the apparent absence of legitimate commercial activity, we assess that these companies were created as a vehicle for this malicious advertising infrastructure.

During our research, we saw proof of the attackers' agility in real-time: AdsParkPro LTD's advertisements were entirely removed from the Google Ads Transparency Center on January 19, 2026. Simultaneously, online business records were modified to list the company as dormant. However, just two weeks later, the actor re-emerged with a new FlutterShell variant, promoted via another verified advertiser, Advantage Web Marketing LLC.

Advantage Web Marketing LLC has been observed not only spreading malicious advertisements but also acting as the signatory for Windows adware variants associated with the CL-CRI-1089 cluster. This suggests that the other identified shell entities (AdsParkPro LTD and SOFT WE ART LIMITED) could also be leveraged in the future to sign malicious binaries.

Adversary Tradecraft and OpSec Failures

Despite the scale and reach of the campaign, the attackers exhibited poor attention to detail in their creative assets. Many advertisements used nonsensical or poorly translated content and generic unpolished visuals. We also observed several instances of cross-contamination, where the actor inadvertently linked the logo of a previous malicious product with the current masqueraded application. Figure 11 shows that PodcastsLounge advertisements display graphics relating to a PDF viewer.

An advertisement with text offering to start a free download, featuring the names "Podcasts Lounge" and "AdsParkPro LTD," alongside a "View PDF" button. Another section repeats "Download (free)" with a "Print Manual" icon.
Figure 11. Cross-contamination between two different malicious ads.

The targeting strategy of the advertisements is broad, but deliberate. While most ads were accessible globally, we identified specific geographic clusters where the actor focused their budget. These included Western European markets (notably France and Germany) and English-speaking regions, including the U.S., Canada and Australia. We identified multiple infected hosts targeted by this threat from correlating regions.

Connecting the Dots Behind CL-CRI-1089 Campaigns

This section details the connection between FlutterShell and the two Windows malware strains operated by the attackers behind CL-CRI-1089, and the strong links between FlutterShell and its predecessor JSCoreRunner. This relationship is evident across their infrastructure, architecture and operational behavior.

The CL-CRI-1089 Connection

By pivoting on infrastructure related to the ad-filled intermediary site used in the FlutterShell campaign, we linked the current macOS campaign to two Windows malware strains: RecipeLister and Calendaromatic. Both of these strains were distributed via malvertising campaigns, and are tracked as part of the CL-CRI-1089 cluster of activity. High traffic rankings for these related domains indicate a wide distribution of the adware.

Calendaromatic and RecipeLister also share technical similarities with FlutterShell, including a WebView-based code architecture that allows dynamic payload changes. In the case of the RecipeLister and Calendaromatic malware strains, the actor encoded content within hidden characters or date synonyms. In FlutterShell, the attacker directly embedded the commands in the website’s content.

All of the malicious applications hijack the victim's browser, redirecting it to similarly structured websites, which present the user with icons linked to well-known brands.

When looking into RecipeLister, we found yet another shell entity responsible for spreading malicious adware — SOFT WE ART LIMITED. This company shares commonalities with other shell companies tied to Operation FlutterBridge: a UK-based entity with one Ukrainian member of personnel who could not be traced to any known real employees. The company’s current website remains active, and shares content and phrasing similarities with AdsParkPro LTD’s previous digital footprint, which has transitioned across three distinct domains since 2024.

The JSCoreRunner Connection

In addition to its connection with Windows-based campaigns, our analysis identified significant links between FlutterShell and the previously documented JSCoreRunner (also known as FileRipple).

As mentioned in a report by Moonlock Labs, JSCoreRunner was also distributed by the same verified publisher — AdsParkPro LTD. This shared distribution point is the first key indicator that the campaigns are connected. Furthermore, the technical characteristics of both strains confirm a shared origin; they both utilize a specialized JavaScript-to-native bridge and exhibit clear similarities in command structure and functionality. These similarities are discussed in further detail in Appendix B.

Figure 12 shows an example of a Cortex XDR alert that successfully flagged FlutterShell activity by identifying browser hijacking activity similar to its predecessor, JSCoreRunner.

A screenshot of Cortex XDR dashboard with a high-priority security alert titled "Staged Malware Activity." Below the title are three tabs: Overview, War Room, and Work Plan. The description notes activity similar to the "JSCoreRunner Browser Hijacker.
Figure 12. Cortex XDR alert for FlutterShell activity flagged as similar to JSCoreRunner.

Conclusion

The evolution from JSCoreRunner to FlutterShell represents a significant increase in technical depth for the attackers behind CL-CRI-1089. By transitioning to the Flutter framework and adopting a dynamic, WebView-based architecture, the attackers have effectively separated their malicious logic from the binary. This shift not only complicates static analysis, but allows the attackers to modify the malware's behavior on the fly, turning what appears to be a nuisance adware strain into a fully functional backdoor.

Furthermore, the scale of the distribution network, coupled with the verified shell entities used to bypass ad-network vetting, highlights the persistent danger of malvertising. The coordination of multiple shell entities, and the rapid development and delivery of new FlutterShell variants, indicates that this campaign is far from over. Up until late March, we continued to witness the distribution of FlutterBridge malware variants. As the attackers behind CL-CRI-1089 continue to refine their JavaScript-to-native bridge techniques, we expect to see this architecture deployed in future campaigns targeting both macOS and Windows environments.

Palo Alto Networks Protection and Mitigation

Advanced WildFire

The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of indicators associated with this malware.

Advanced URL Filtering and Advanced DNS Security

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

Cortex XDR and XSIAM

Cortex XDR and XSIAM help to prevent the threats described in this article, by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, to prevent both known and unknown malware from causing harm to endpoints. The mitigation methods implement malware protection based on the different operating systems – Windows, macOS and Linux.

How the Agentic Assistant Supported the Investigation

Cortex’s AgentiX Agentic Assistant streamlined the investigation by allowing the team to query the data using natural language, providing deeper context and insights, and suggesting clear recommendations on what should be done next. Figure 13 shows the AgentiX interface when finding processes that communicate with a malicious domain used in the FlutterBridge operation.

A screenshot of AgentiX dashboard displaying communication paths. It details access over the last 90 days, with endpoints listed along with dates and times. Sections include 'Plan,' 'Endpoint Investigation,' and 'Summary.' The entries describe interactions between Agentic Assistant and paths. The summary highlights specific access instances.
Figure 13. Finding processes that communicated with atsheisdomestic[.]org, using AgentiX.

Indicators of Compromise

SHA256 Hashes of Malicious Files From FlutterShell Activity (PodcastsLounge)

  • Hash: 021666417de8b9972c179783fe60d4c4ad2d93224e3a0f16137065c960b1b845
  • File name: PodcastsLounge.dmg
  • File description: Disk Image (DMG) installer for the malicious PodcastsLounge application
  • Hash: 363923500ce942bf1a953e8a4e943fbf1fb1b5ed6e5d247964c345b3ad5bfc34
  • File name: podcasts_lounge.app
  • Bundle ID: com.app.podcastsLounge
  • Developer ID: Yasar Sever (UBZDAAV97Y)
  • File description: Main application executable for PodcastsLounge
  • Hash: 8421c902364980e3d762ec6dbbe6b0f40577c27bd79b48c57d098328b2533109
  • File description: Dynamic library (dylib) associated with the PodcastsLounge application

SHA256 Hashes of Malicious Files From FlutterShell Activity (PDF-Brain)

  • Hash: 644fc49fa1006a2a2acace694e5fb83753164e2617051ece6d9dc9ea32329e70
  • File name: PDF-Brain.dmg
  • File description: Disk Image (DMG) installer for the malicious PDF-Brain application.
  • Hash: 9053e8ddaecca1f960c041c944ca8799fc71dc86a4b50d2639ee4e0d2cb82f47
  • File name: PDF-Brain.app
  • Bundle ID: com.app.pdfBrain
  • Developer ID: Batuhan Dabag (FW9NHQ8922)
  • File description: Main application executable for PDF-Brain
  • Hash: b60074d1ea2008a581f432f2dee5f84f78668d9dd8e66f75d03c42dabd89bdea
  • File description: Dynamic library (dylib) associated with the PDF-Brain application.

SHA256 Hashes of Malicious Files From FlutterShell Activity (PDF-Ninja)

  • Hash: 9425e8e39fa8a7212cdd07f0917cb3dfde38a90b87297de2c82a5850aff1e4de
  • File name: PDF-Ninja.dmg
  • File description: Disk Image (DMG) installer for the malicious PDF-Ninja application
  • Hash: 30448686ec900d5213d74f08f0d2b7924c5336a29445b2a434aba8d8b19d7530
  • File name: PDF-Ninja.app
  • Bundle ID: com.pdfninja.app
  • Developer ID: Yusuf Bal (B73CHZ24Y8)
  • File description: Main application executable for PDF-Ninja
  • Hash: 48047c34bbd57fe1e24bc538bc2ce9e0ac4c4eb48d3b0c195b414f0379dc0745
  • File description: Dynamic library (dylib) associated with the PDF-Ninja application

Infrastructure and C2 Traffic

  • URL: hxxps[:]//atsheisdomestic[.]org/update-thanks.html
  • Domain: atsheisdomestic[.]org
  • Description: PodcastsLounge C2
  • URL: hxxps[:]//etoftheappyrince[.]org/update-delay
  • Domain: etoftheappyrince[.]org
  • Description: PDF-Brain C2
  • URL: hxxps[:]//healightejustb[.]org/checkupdateTO.js
  • Domain: healightejustb[.]org
  • Description: PDF-Ninja C2
  • Domain: sinterfumesco[.]com
  • Description: Adware site

Actor-Related Websites

  • Domain: ads-parkpro[.]com
  • Description: Website previously associated with AdsParkPro LTD
  • Domain: adsparkpro[.]top
  • Description: Website previously associated with AdsParkPro LTD
  • Domain: adsparkpro[.]net
  • Description: Website previously associated with AdsParkPro LTD
  • Domain: softwe[.]art
  • Description: Website associated with SOFT WE ART

Additional Resources

Appendix A: Analysis of Additional FlutterShell Features

Loading the WebView

FlutterShell initiates the WebView and loads the attackers’ website in the following cases:

  • Initial execution: Automatically, following a calculated delay received dynamically from the C2.
  • User Interaction: When the targeted user clicks the About or Update buttons in the application settings.

Upon initial execution, FlutterShell waits for a specific duration before contacting the attacker-controlled website. This delay is non-deterministic and is calculated during the application's startup routine:

  1. Immediately after launch, FlutterShell sends an HTTP GET request to [attacker_domain]/api/update-delay to fetch the delay duration in seconds.
  2. If this endpoint is unreachable, the malware defaults to a 600 second (10 minute) delay. If the server responds, but the delay field is null, it defaults to a 1200 second (20 minute) delay.
  3. Once the timer expires, FlutterShell forces the application to the foreground and presents the webpage [attacker_domain]/update-thanks.html.

This calculated delay suggests a deliberate strategy to evade automated sandbox environments, which typically time out within a few minutes. Simultaneously, it builds user trust by maintaining a period of “normal” application behavior before the malicious window appears.

If the user clicks the About or Update buttons in the application settings, FlutterShell loads the attackers’ main website page or the update-thanks.html page, respectively. In both scenarios, the loaded webpages contain JavaScript code that executes immediately upon loading.

FlutterShell’s Update Mechanism via the Sparkle Framework

The FlutterShell backdoor uses the Sparkle software update framework for macOS applications in its update mechanism. However, it significantly deviates from the standard Sparkle protocol, to avoid detection.

In a legitimate implementation, once Sparkle finishes downloading an update to the cache, it triggers a user interface (UI) prompt, such as “A new version is available. Install and Relaunch?”. The update process halts here until the user manually clicks the button to approve the restart. To bypass this user interaction, FlutterShell interrupts the flow the moment the download completes.

Our analysis of this sequence reveals the following flow:

  1. Callback reception: The malware listens for the update completion signal in the function SparkleUpdateService:_handleMethodCall() marked as the string onUpdateCycleFinished from the native macOS layer.
  2. Installation verification: If the update completed without errors, the code checks for the existence of the Sparkle installation directory: $HOME/Library/Caches/com.app.[appname]/org.sparkle-project.Sparkle/Installation/.
  3. Manual execution: Rather than waiting for the user to authorize the install, the malware programmatically executes the open command on the staged app bundle found in the cache.
  4. Forced termination: It immediately executes dart:io exit(), killing the old running process instantly.

This sequence effectively “swaps”" the malware version in real time, without ever showing a dialog box. This ensures that the updated malware begins running without any UI interaction, allowing the attackers to upgrade the backdoor's capabilities silently.

Supported FlutterShell Commands Analysis

FlutterShell’s built-in commands provide full backdoor capabilities, allowing the attackers to execute shell commands and manipulate files on the system. Table 2 lists the commands and capabilities of FlutterShell found collectively within the three identified variants — PodcastsLounge, PDF-Brain and PDF-Ninja.

Category Commands and Features Description
Variant PodcastsLounge PDF-Brain PDF-Ninja
Execution exec_sync pdf_sync renderPDF Executes arbitrary shell commands with current user permissions
Filesystem
  • read_file
  • write_file 
  • read_dir 
  • exists
  • get_home_dir
  • read_pdf
  • write_pdf 
  • read_pdf_dir 
  • pdf_exists
  • get_pdf_dir
  • Read files 
  • Write files 
  • Get directory structure 
Harvesting get_env Extracts environment variables. These may contain high-value assets like plaintext API keys for secondary access.
UI Manipulation close_webview, setSize Resize the application’s windows, likely to reduce user suspicion.

Table 2. An example of FlutterShell’s backdoor capabilities.

We also saw that some variants of FlutterShell have the com.apple.security.files.downloads.read-write macOS entitlement, which gives the malware the capability to read and write to files in the user’s Downloads directory.

Appendix B: Technical Similarities Between JSCoreRunner and FlutterShell

The architectural fingerprints of both JSCoreRunner and FlutterShell malware families are nearly indistinguishable. Both rely on a specialized JavaScript-to-native bridge, using JavaScript as a high-level conductor to trigger low-level system operations.

The most compelling evidence of a shared lineage is the backdoor primitives. We found a set of six identical core commands embedded in both JSCoreRunner and FlutterShell, as Table 3 shows.

Capability FlutterShell JSCoreRunner
Check File/Dir Existence exists/existsSync _fsExistsSync
Execute Command exec_sync/pdf_sync _execSync
File Reading read_file _fsReadFileSync
File Writing write_file _fsWriteFileSync
Dir Enumeration read_dir _fsReaddirSync
Get Home Directory get_home_dir _osHomedir

Table 3. Function name comparison between JSCoreRunner and FlutterShell.

Operationally, the campaign objectives remain consistent. Both have been observed primarily as browser hijackers, with a specific focus on compromising Google Chrome installations to inject ads or scrape sensitive session data.

While the fundamental architecture is the same, FlutterShell represents a significant tactical evolution over JSCoreRunner. The primary shift lies in their different payload delivery methods — while JSCoreRunner’s logic is embedded statically in the binary, FlutterShell’s logic is received dynamically from the C2 server at runtime.

This shift has significant implications for detection and response. Dynamic delivery means attackers can decouple the binary from its logic by updating their logic without needing to recompile the application. In addition, dynamic content delivery allows the attacker to use geofencing and avoid certain regions and entities to download the malware’s payload, thus hindering analysis even more.

2026 World Cup: Discussing The World’s Biggest Game’s Attack Surface

Posted on by Ria Bhatia

The 2026 FIFA World Cup will be the largest sporting event ever staged. Across 39 days, 16 host cities in three nations will host 104 matches, an expanded 48-team tournament and an estimated five-to-six million in-venue spectators alongside a global broadcast audience approaching half the planet.

The tournament opens at Estadio Azteca in Mexico City on June 11, 2026, and concludes at MetLife Stadium in East Rutherford, New Jersey, on July 19, 2026.

This is the first World Cup to be jointly hosted by three nations. Each match runs on a temporary, multi-ring tournament network grafted onto pre-existing NFL, MLS, CFL and Liga MX stadium environments. It depends on a network of municipal services, including public transit, signalized traffic, water and wastewater treatment, regional power, airport operations and emergency services. Each of those touchpoints is in scope for an adversary.

Based on a review of cyber operations against prior mega-events from 2016 through the Milano-Cortina 2026 Winter Games, this assessment finds that disruptive intrusions, criminal fraud at scale and politically motivated distributed denial-of-service (DDoS) and hack-and-leak operations are highly likely. The only meaningful questions are who, against which targets and at what severity.

There are three drivers in the 2026 World Cup risk picture:

  • Iran-nexus activity. The U.S.–Israel–Iran kinetic conflict that began on Feb. 28, 2026 has reordered the threat surface for any U.S.-hosted event. The Handala Hack Team, assessed by the U.S. Federal Bureau of Investigation (FBI) and multiple commercial threat intelligence firms to be a front for Iran's Ministry of Intelligence and Security (MOIS), executed significant wiper attacks in early 2026. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) published a joint advisory AA26-097A confirming an active, ongoing Iranian-affiliated campaign. The campaign targets internet-exposed Rockwell Automation and Allen-Bradley programmable logic controllers (PLCs) in U.S. critical infrastructure, as well as Islamic Revolutionary Guard Corps (IRGC) targeting of Israeli-made Unitronics Vision Series PLCs at U.S. water, energy and municipal targets. These are the same categories of infrastructure that World Cup host cities will be operating under tournament load.
  • Russia-nexus hacktivism. Since 2022, NoName057(16) has conducted over 3,700 verified DDoS attacks against governments and critical sectors in NATO member states. Documented surges keyed to politically symbolic events including the NATO Summit, the Ukraine Peace Summit and claims of intent at the Paris 2022 Olympics and the Milano Cortina 2026 Winter Olympics. Operation Eastwood (July 2025) disrupted but did not eliminate the group. The UK NCSC confirmed continued operations into 2026. The U.S., Canada and Mexico are NATO partners or allies and the World Cup is a politically symbolic event of the highest order.
  • Financially motivated cybercrime. Group-IB identified more than 16,000 fraudulent domains and 90 compromised Hayya fan-portal accounts during World Cup 2022 in Qatar. The 2023 Muddled Libra (operators of ALPHV aka BlackCat ransomware) campaign against entertainment organizations demonstrated that the hospitality stack is a target for ransomware operators. The stack includes reservations, digital keys, point-of-sale (PoS) machines and loyalty data. Ticket fraud, accommodation fraud, transportation QR-code fraud and FanID-equivalent account takeover are prime targets at scale across all three host nations.

The Paris 2024 Olympics is a strong example of a recent precedent. French authorities (ANSSI) confirmed at least 140 cyber events during the Games, including 22 confirmed unauthorized intrusions and a ransomware attack against the Grand Palais venue.

None succeeded in disrupting competition, but only because of preparation that began years earlier. Preparation included exercises against 500 Games-linked facilities, and support by sustained government-industry coordination. The 2026 tournament must clear the same bar across multiple jurisdictions, regulatory bodies and languages.

The Bottom Line

Defenders should plan against the possibility of all of the following:

  • Cybercriminals targeting fans and the hospitality supply chain
  • Iran-nexus disruptive operations against ancillary U.S. infrastructure during the tournament window
  • Pro-Russian and pro-Iran hacktivist DDoS and defacement targeting of host-city, federation and ticketing services
  • A wiper deployed against tournament IT during a high-visibility ceremony

Previous Attacks Against Major International Sporting Events

Event Year Operation / Actor Documented Impact / Primary Source
Rio Summer Olympics 2016 OpOlympicHacking; Fighting Ursa (aka Fancy Bear, APT28) WADA leak Prolonged DDoS against the official Rio website; Fighting Ursa publication of stolen WADA athlete medical records 
Pyeongchang Winter Olympics 2018 Olympic Destroyer wiper; attributed to Razing Ursa (aka GRU Unit 74455, Sandworm) by UK FCDO, Oct 2020 Wi-Fi at opening ceremony, Olympics website, ticketing, broadcast drones disabled. 300+ systems compromised. 12 hours to restore. Credentials in binary referenced 44 Pyeongchang accounts.
Tokyo Summer Olympics 2020/21 Razing Ursa reconnaissance and disruption Over 450 million blocked attempts reported. No disruption to competition. Phishing/social engineering against athletes and ticket-holders persisted.
FIFA World Cup, Qatar 2022 Cybercriminal ecosystem; multiple groups Group-IB: 16,000+ scam domains, 40+ fake mobile apps, 50+ fake social-media accounts, and 90 compromised Hayya FanID accounts (RedLine and Erbium info-stealer credentials).
Rugby World Cup, France 2023 Fiddling Scorpius, distributors of Play ransomware French Rugby Federation systems encrypted three months before kickoff; Personally identifiable information (PII) exfiltrated. No on-field disruption. Reputational and financial damage.
Paris Summer Olympics 2024 Multiple cybercriminal and hacktivist groups; one ransomware actor. ANSSI confirmed 140+ events ANSSI: 140+ events, 119 low-impact, 22 successful intrusions. Ransomware on Grand Palais venue and approximately  40 other museums. DDoS peaks at 190,000 req/sec on official site. No competition was disrupted.
Milan-Cortina Winter Olympics 2026 Italian Foreign Minister Antonio Tajani said in a press conference that Italy thwarted attacks No public confirmation of disruption to competition. Italian National Cybersecurity Agency operated a dedicated command centre throughout the Games.

Table 1. Previous attacks against major sporting events.

Cybercriminal Threats to Fans and the Tournament Supply Chain

Financially motivated cybercrime is the highest-volume, highest-likelihood threat category for the 2026 FIFA World Cup Games.

Ticket Fraud and FanID-equivalent Account Takeover

Based on the Qatar 2022 Games, there are five categories of ticket-themed fraud:

  • Lookalike resale sites
  • Fake social-media reseller accounts
  • Lottery/giveaway phishing
  • Fake mobile applications on official app stores
  • Credential-stuffing attacks against the official fan portal

Hospitality and Accommodation Fraud

Attacks against hospitality businesses and platforms, digital key infrastructure, point of sale (PoS) and identity providers and fake short-term rental properties are another potential area of risk.

QR-Code, Transportation and PoS Fraud

Tournament-specific QR-code fraud is the single fastest-growing variant. There have already been observed pre-tournament listing scams, and a high potential for fake shuttle passes, parking permits and official fan transport QR codes that fail when scanned. The geographic spread of the 2026 games in various cities multiplies opportunities for transit-themed fraud relative to single-host-city games.

Phishing, Malware and Lure Themes

Confirmed lure themes from prior tournaments include:

  • Lottery winnings
  • Ticket cancellations
  • FIFA dispute-resolution decisions
  • Accreditation problems
  • FanID issues
  • Free streaming
  • Counterfeit merchandise

Expect to see typosquatted FIFA domains, malicious mobile applications, infostealers sold on Telegram, and Telegram-based reseller channels moving money via peer-to-peer payment apps as seen in Table 2.

Cybercriminal Vector Primary Targets
Phishing/lookalike domains/typosquatting All fans, especially first-time international travelers
Fake/resold tickets; FanID account takeover Fans buying outside the FIFA platform
Hospitality ransomware (High-profile operators) Hotel chains, property management, casino-resort venues
DDoS against host-city, federation or ticketing services Pro-Russian and pro-Iran hacktivist targets
Hack-and-leak/doxxing of officials, sponsors, athletes Officials, sponsors, athletes
QR-code/transportation/parking fraud Fans moving between host cities
Mobile malware via fake apps in official stores Android primarily; iOS via TestFlight

Table 2. Cybercriminal techniques that are possible during the World Cup.

Geopolitical Threats: Iran-Nexus and Disruptive Hacktivism

The geopolitical context for the 2026 tournament is materially different from any prior World Cup. The U.S.-Israel-Iran conflict has produced a surge in Iran-nexus cyber operations against U.S. organizations. The Russia-Ukraine war and the resulting NATO alignment of all three host nations make pro-Russian hacktivism an additional, parallel risk.

Iran-Nexus: The Handala Hack Team

The Handala Hack Team (aka Banished Kitten, Storm-0842, Void Manticore and Cobalt Mystique) and Ababil of Minab, are just two of several front personas operated by Iran's MOIS directly responsible for wiper attacks, targeting high-level government officials, and doxxing employees of public companies.

Iran-Nexus: CyberAv3ngers and OT Targeting

CyberAv3ngers (aka Shahid Kaveh Group, Bauxite, Hydro Kitten, Storm-0784 and UNC5691) is the IRGC Cyber-Electronic Command's industrial-control-system arm. Its documented escalation curve is the single most important data point for defenders concerned with municipal infrastructure during the FIFA World Cup 2026.

Every World Cup host city in the United States operates municipal water, wastewater and energy infrastructure inside this advisory's threat envelope. A 2024 CISA assessment found over 70% non-compliance with existing safety requirements at U.S. water utilities.

Iran-Nexus: Other Personas and the Electronic Operations Room

Beyond Handala and CyberAv3ngers, multiple Iran-aligned personas — DieNet, APTIran, Cyber Toufan, Cyber Support Front, Iranian Avenger, Cyb3r Drag0nz — have been observed operating through a team named the Electronic Operations Room of Islamic Resistance Axis. This team formed in late February 2026. DieNet has specifically claimed DDoS attacks against Bahrain and Saudi airports and Jordanian banks — transportation and finance targets directly relevant to fan-facing infrastructure.

Russia-Nexus: NoName057(16) and Allied Hacktivists

NoName057(16) has been the most operationally consistent pro-Russian hacktivist group since March 2022, with an attributed 3,700-plus targeted hosts to the group between July 2024 and July 2025. The UK NCSC, Eurojust and Europol issued co-sealed advisories in December 2025 and January 2026 regarding the hacktivist group. Operation Eastwood produced two arrests and seven arrest warrants but did not stop the group, which resumed activity within days.

Three operational characteristics are directly relevant to 2026:

Information Operations
Major global sporting events have proven fertile ground for state-sponsored information operations aimed at sowing distrust in institutions, embarrassing athletes or nations, and amplifying narratives conducive to strategic interests. Russian influence operations are well established with past reported activities surrounding leaked athlete data, AI-enabled deception and defaming, delegitimization of Ukraine and Ukrainian athletes, narratives of the West against Russia, and pro-Kremlin narratives.

The current conflict in Iran opens the door for potential Iran-based narrative amplification, consistent with its observed hybrid offensive approach, specifically aimed at compounding the division of support for kinetic activity and targeting countries or athletes from Gulf states perceived as adversarial.

People’s Republic of China-aligned Dragonbridge has increasingly experimented with and deployed generative AI tools — such as synthetic audio, AI-generated news hosts, avatars, and images — to scale its political influence operations across social media, though these efforts have ultimately failed to garner significant organic engagement from authentic viewers.

Temporary Multi-City Tournament Infrastructure

FIFA's published tournament structure presents a unique and historically large attack surface. Sixteen host cities span three host nations, four time zones and multiple regulatory regimes. Each match operates a layered, ring-based tournament network grafted onto a permanent stadium environment, depends on a temporary commercial supplier ecosystem and pulls on host-city public services that FIFA does not own. Table 3 lists these rings and the primary cyber risk to each.

Network Rings and What Each Ring Is For

Ring Function Primary Cyber Risk
Field-of-play/Video Assistant Referee (VAR)/officiating Goal-line technology, semi-automated offside, Video Assisted Review, in-stadium broadcast cabling Integrity-of-competition attack; broadcast disruption during a key moment
Venue operational network Access control, ticket scanning, screens, public-address, Wi-Fi, accreditation Replay of the Pyeongchang scenario: Wi-Fi, app, ticketing, gates rendered unusable
Tournament management Schedule, results, statistics, athlete management, broadcaster feeds Wiper or ransomware timed to opening match or final; data integrity
Hospitality and commercial VIP access, payments, loyalty, hospitality suites, sponsor activations Hospitality-stack ransomware; PII and payment information exfiltration
Fan-facing digital FIFA app, official ticket resale, FanID, streaming, social Account takeover, FanID compromise, content defacement, mobile malware
Host-city public services Transit, traffic signals, water, wastewater, power, airports, emergency services Iran-nexus OT targeting per CISA AA26-097A; cascade impact on tournament operations

Table 3. Network rings and use cases.

The Supplier Ecosystem

The 2026 supplier ecosystem will be vast. Each host city contracts independently for stadium operations, security, transit, hospitality, food service, signage, fan-zone production and last-mile network connectivity. The Pyeongchang 2018 Olympic Destroyer destructive case is a clear historical warning: Recorded Future identified that Olympic Destroyer samples targeting the IT service provider were timestamped five minutes ahead of samples targeting the host.

Impact on Municipal, State and Federal Infrastructure

Municipal Layer

CISA AA26-097A identifies “Government Services and Facilities (to include local municipalities)” as one of three named target sectors of the active Iran-nexus PLC campaign. Analysis of CyberAv3ngers' targeting found that small municipal authorities are deliberately selected because they manage OT with consumer remote-access tools or expose PLC interfaces directly to the internet. A January 2024 Russian cyberattack on a municipality in Texas resulted in successfully overflowing a water tank after unsuccessful attempts in neighboring water systems. Ransomware attacks on water systems have also occurred.

State and Provincial Layer

Pro-Russian hacktivist DDoS has already demonstrated the ability to take state and local government websites offline for hours. UK NCSC's January 2026 alert specifically called out persistent NoName057(16) targeting of UK local-government services. The U.S., Canadian and Mexican equivalents are inside the same threat envelope.

Federal Layer

Federal agencies have signaled awareness: CISA AA26-097A, the DOJ domain-seizure activity against Iranian cyber fronts and the U.S. State Department's $10 million reward offers indicate active coordination. Defenders should expect and request pre-tournament threat-sharing engagements with CISA, FBI, the Canadian Centre for Cyber Security and Mexico's CERT-MX, mirroring the model that ANSSI ran in advance of Paris 2024.

Cascading-Risk Scenarios

Two specific scenarios merit pre-tournament tabletop exercise.

OT Disruption at Host-City Utility During Match

Scenario: An Iran-nexus actor manipulates a wastewater PLC in a host city overnight before a knockout match, producing a service alert and a forced public-health advisory.

Mitigation
  • Pre-tournament audit of all internet-exposed PLCs per CISA AA26-097A
  • Mandated migration off TeamViewer/AnyDesk for OT
  • Default-credential audits
  • 24/7 OT incident-response retainer
Hospitality Ransomware in Final Week

Scenario: A Muddled Libra-style social-engineering campaign against a major host-city hotel operator collapses room access, mobile check-in and PoS for 48-72 hours during the run-up to the July 19, 2026, final at MetLife Stadium.

Mitigation
  • Pre-tournament tabletop exercises with major hotel groups
  • Explicit verification protocols on IT help desks
  • Segregation of IdP trust from ESXi management
  • Offline runbooks for the property-management system

Prioritized Threat Matrix

The following matrix in Table 4 consolidates the assessed likelihood and severity of each evidence-backed threat vector for the tournament window of June 11-July 19, 2026. Severity is conditioned on the potential impact to fans, host cities and the integrity of the competition.

Threat Vector Severity Primary Actor Class
Phishing, fake tickets, lookalike domains targeting fans Low-medium per fan; cumulative high Cybercriminal
FanID/FIFA-portal account takeover Medium Cybercriminal
Hospitality ransomware against major hotel operator(s) High Cybercriminal (Muddled Libra (aka Scattered Spider)/high-profile actors)
DDoS against host-city, federation or ticketing services Medium Pro-Russian and pro-Iran hacktivist
Hack-and-leak/doxxing of officials, sponsors, athletes Medium-high Iran-nexus (Handala) and adjacent personas
Wiper/destructive operation against a vendor or venue High-critical Iran-nexus state-backed; Russia-nexus state-backed
OT disruption at a host-city utility High Iran-nexus (CyberAv3ngers-class)
Disinformation/AI-generated content around matches Medium Multiple state and non-state actors
Insider compromise at a tournament supplier High Cybercriminal-for-hire; state-backed
Mobile malware via fake apps in official stores Medium Cybercriminal

Table 4. Prioritized threat matrix of likely cyberattacks.

Recommendations

These recommendations are derived from the threat picture above and from public after-action reporting on Paris 2024 and Milan-Cortina 2026. They are prioritized by impact rather than by category.

For the tournament organization and host-city committees

  • Stand up a single, multi-jurisdictional cyber operations center with U.S. CISA, the Canadian Centre for Cyber Security, Mexico's CERT-MX, the FBI, the RCMP and Mexican federal cyber liaison co-located or fully integrated, replicating the ANSSI/Paris 2024 model.
  • Inventory the full vendor and supplier graph for each host city and conduct credential-rotation, default-password and remote-access audits across that graph. Prioritize IT service providers and venue operations, which Recorded Future identified as Pyeongchang's primary breach vector.
  • Mandate that no tournament network, at any ring, permits consumer remote-access tools on production infrastructure for the duration of the tournament window.
  • Pre-position DDoS scrubbing capacity, content-delivery-network failover and rate-limiting on all fan-facing domains. NoName057(16) DDoS volumes during Paris 2024 peaked at 190,000 requests/second; defenders should plan for an order of magnitude above that.
  • Run a destructive-malware tabletop. Validate that backups are isolated, immutable and recoverable inside a four-hour window.

For host-city utilities and municipal operators

  • Audit every internet-exposed PLC, HMI and SCADA component in water, wastewater, energy and transit operations. Apply CISA AA26-097A and AA23-335A guidance specifically: Change all default credentials, place PLCs behind segmented firewalls and eliminate direct internet exposure on ports 44818, 2222, 102, 22 and 502.
  • Engage the FBI, CISA and EPA for sector-specific assessments before kickoff. Where budget is constrained, a single round of vulnerability scans focused on the AA26-097A indicator set is high value.
  • Establish 24/7 OT incident response coverage through the entire tournament window.

For hospitality and venue operators in host metros

  • Treat the IT help desk as the first line of defense and the most likely point of compromise. Implement out-of-band caller-verification protocols; ban credential resets initiated by phone alone; assume that publicly identifiable employees are reconnaissance targets.
  • Segregate identity-provider trust from VMware ESXi management. Previous compromises pivoted from Okta to ESXi to ransomware; that pivot path must be broken architecturally before the tournament, not during it.
  • Maintain offline runbooks for property-management, PoS, digital-key and reservation systems. Confirm pen-and-paper fallback works under load.

For sponsors, federations and broadcast partners

  • Assume executive personal accounts are in scope for state-aligned hack-and-leak operations.
  • Apply phishing-resistant MFA (FIDO2/WebAuthn) to all corporate, executive and high-visibility employee accounts before kickoff. SMS and TOTP MFA are insufficient against the demonstrated tradecraft of Scattered Spider and Handala.
  • Pre-build communications response templates for hack-and-leak scenarios; do not draft them under live attack.

For fans and the traveling public

  • Buy tickets only on the official FIFA platform or a FIFA-authorised resale partner. Do not buy through Telegram, WhatsApp, social media DMs or peer-to-peer payment apps. Use a credit card with chargeback protection.
  • Verify accommodation listings with major platforms; treat off-platform wire transfers and cryptocurrency requests as fraud. Cross-reference street view and listing photos.
  • Treat any QR code presented in transit, parking or fan-zone contexts with skepticism. Cross-check with the host city's official transportation app or website before scanning.
  • On public Wi-Fi, use a reputable VPN for any account-level activity; better still, use cellular data. Disable Wi-Fi auto-join; remove networks after use.
  • Patch mobile devices. Avoid sideloading apps. Verify every FIFA app against the FIFA-published list of official applications.

Final Thoughts

The window for shifting from preparation to live response is closing fast. The 2026 FIFA World Cup conditions are different than at any previous tournament: three host nations, sixteen host cities, a 48-team field, an active U.S.-Israel-Iran kinetic conflict, an ongoing Russia-NATO confrontation and a cybercriminal ecosystem that has industrialized against the hospitality sector since 2023.

The threat actors of greatest concern for 2026 — the Handala Hack Team, CyberAv3ngers, NoName057(16), Muddled Libra, ALPHV affiliates and the broader Iran- and Russia-aligned hacktivist ecosystem — have all demonstrated their capabilities within the last 24 months. This has been proven in public record by what these actors have already accomplished.

Plan for incidents across the full supplier and host-city graph, exercise the response against realistic scenarios and coordinate across jurisdictions before kickoff rather than during the tournament. Where that posture has been adopted, the historical record shows that competition has not been disrupted. Where it has been weaker, adversaries have succeeded. The single most important defender posture for 2026 is to assume the attacks will come.

Additional Resources

Out of the Crypt: The Evolving Cyber Extortion Economy

Posted on by Ria Bhatia

Extortion Activity No Longer Requires Encryption for Payment

This blog dives into the growing trend of data theft and extortion activities which no longer require the use of ransomware to pressure victims into paying a demand. We examine the financially-motivated threat actors using both single and double extortion techniques and what this means for organizations going forward, especially with the arrival of frontier AI models.

Shifting Threat Landscape Observations

As detailed in our 2026 Global Incident Response Report, Unit 42 observed a notable decrease in the use of encryption for extortion-related cases last year. The total percentage in 2025 dropped to 78%, much lower than the near-or-above-90% levels observed between 2021-2024. Other security organizations have seen similar trends, with Google reporting a gradual rise in data theft and extortion incidents from approximately 2% in 2020 to 15% in 2025. Resilience also observed an increase in extortion-only incidents in 2025, rising from 49% in the first half to 65% in the second half.

Threat actors tracked by Unit 42 that have demonstrated a willingness to shift away from using ransomware to pure data theft and extortion include Bling Libra’s (aka ShinyHunters) focus on software-as-a-service (SaaS) applications and Hazy Scorpius’s (aka CLOP) exploitation of an Oracle EBS vulnerability. When examining this precipitous drop in encryption, we see four primary drivers: advanced backup and recovery performance allowing routine re-imaging and restoration, endpoint maturity and automated disruption efficacy, exfiltration speed and the increased pressure from regulatory frameworks where non-compliance fines, class-action lawsuits and systemic reputational damage are greater leverage than operational downtime.

In 2025, pure data-exfiltration campaigns heavily targeted Professional Services, Healthcare and Consumer Services firms with threat actors specifically focused on mid-sized organizations accounting for 64% of victims. Interestingly, while Manufacturing remains the single most disrupted sector overall, Construction has witnessed a 44% year-over-year increase as a data-only extortion hotspot. These firms are attractive targets due to lucrative financial blueprints and bidding data combined with data egress controls.

The current data-only extortion economy is directly fueled by a heavily-regulated compliance landscape, which threat actors have effectively weaponized. Strict mandates like the SEC's 4-day disclosure window and GDPR’s 72-hour reporting rule have created a regulatory countdown clock, allowing threat actors to force rapid negotiations before organizations can complete internal assessments. Because global privacy frameworks, state-level breach notification laws and post-leak class-action litigation have driven the average cost of data-theft extortion to $5.08 million (and over $10 million for broader U.S. breaches), data exposure alone carries disastrous financial liabilities. Threat actors recognize that regulatory penalties are so severe that the compliance framework itself compels corporate payouts.

As recently noted by our Chief Security Intelligence Officer, Wendi Whitmore, it only took 39 seconds for threat actors to move from initial access to data exfiltration in one case.

Differences in Extortion Operations

Unit 42 is actively monitoring several threat actors that are continuously conducting data theft and extortion operations. The notable differences between these attackers is their use of initial access techniques and the number of extortion techniques to pressure victims into payment.

Initial Access via Software Supply Chain Compromise

TGR-CRI-1135 (aka TeamPCP) has been active since at least late 2025. According to Wired, this group has conducted upwards of 20 distinct supply chain compromise attacks which have led to the injection of malicious code into over 500 pieces of software. We previously reported on the group’s activities earlier this year and how their malware was able to successfully exfiltrate sensitive secrets (cloud access tokens, SSH keys, Kubernetes secrets) from victims.

In recent months, TGR-CRI-1135 has been partnering with various ransomware-as-a-service (RaaS) and extortion-as-a-service (EaaS) operators to monetize their ongoing intrusion activities. On the EaaS front, they have been collaborating with the operators of LAPSUS$ Group to extort targeted organizations via their data leak site as shown below in Figure 1.

Figure 1: Screenshot of LAPSUS$ DLS post on May 21, 2026 (Source: Dark Web Informer)
Figure 1. Screenshot of LAPSUS$ DLS post on May 21, 2026. Source: Dark Web Informer.

On the RaaS front, they have been working with the operators of Vect ransomware based on communications observed via the BreachForums cybercrime forum as shown in Figure 2. Unit 42 is also aware of claims by one of Vect’s affiliates, the Rostova Organization, that they are also partnering with TGR-CRI-1135.

Figure 2: Screenshot from HasanBroker’s BreachForums post on March 25, 2026 (Source: Unit 42)
Figure 2. Screenshot from HasanBroker’s BreachForums post on March 25, 2026. Source: Unit 42.

On May 13, 2026, TGR-CRI-1135 announced the release of an open source version of Shai-Hulud on BreachForums as shown in Figure 3. Going forward, as noted in our most recent threat research article, this will likely make attribution more difficult given that copycats may leverage the tool in similar supply chain compromise attacks.

Figure 3. Screenshot from BreachForums post on May 13, 2026. Source: Unit 42.

One notable development related to Vect was the announcement on BreachForums shown in Figure 4 which states that those operators have been removed from the forum. It is unclear if this will have a material effect on their collaboration with TGR-CRI-1135 going forward.

Figure 4. Screenshot from Resolute’s BreachForums post on May 21, 2026. Source: Unit 42.

At this time, Unit 42 is not aware of TGR-CRI-1135 using any additional extortion techniques to pressure victims into paying their ransom demands outside of purely data exfiltration.

Initial Access via Vishing

Bling Libra continues their rampage of infiltrating customer SaaS tenants for data theft and extortion operations, which Unit 42 reported on extensively in 2025. The operators have distanced themselves from the cybercriminal alliance known as Scattered LAPSUS$ Hunters based on a Telegram message shown in Figure 5.

Figure 5. Screenshot from scattered LAPSUS$ hunters part 7 chat on May 11, 2026. Source: Telegram.

However, their playbook has remained relatively unchanged based on Unit 42 observations. They continue to use vishing for initial access, directing unsuspecting victims to phishing sites designed to intercept user credentials and multifactor authentication (MFA) codes and ultimately registering their own devices to establish persistence within targeted environments. The operators still use the same Tox ID to communicate with victims and also maintain a Tor-based data leak site.

In comparison to TGR-CRI-1135, Bling Libra uses additional extortion techniques outside of pure data theft to pressure victims into paying a ransom. Unit 42 is aware of their adoption of both distributed denial-of-service (DDoS) attacks and information leaks to media outlets as added leverage points to extort victims.

On the flip side, an activity cluster tracked by Unit 42 as CL-CRI-1116, which overlaps with public reporting on BlackFile, has followed a similar pattern of activity in terms of a playbook-driven approach with some subtle and not so subtle nuances.

While the attackers behind CL-CRI-1116 also use their own Tor-based data leak site, they do not reuse the same Tox ID across victims and typically use a different registrar to set up their phishing sites in comparison to Bling Libra.

The major difference between CL-CRI-1116 and Bling Libra is the former’s use of swatting employees as a double extortion technique. This act is typically defined as placing a false emergency call to first responders, such as reporting a fake crime at a specific location to trigger a physical response. In many cases, this is expected to create chaos and can potentially even lead to acts of violence.

This convergence between cyber and physical security can lead to complications if these two teams aren’t in regular communications with each other on how to address such a situation, especially as it pertains to executive protection.

One recent development regarding the attackers behind CL-CRI-1116 is the closure of their former data leak site and the rebranding of their program under the name “Redact” with a new data leak site as shown in Figures 6 and 7.

Figure 6. Screenshot from BlackFile data leak site post on May 11, 2026. Source: Unit 42.
Figure 7. Screenshot from BlackFile data leak site post on May 19, 2026. Source: Unit 42.

Looking Forward

In recent weeks, Palo Alto Networks has been at the forefront of providing guidance to organizations on how to secure their environments from the inevitable weaponization of frontier AI models like Mythos by threat actors. These models currently accelerate at finding and chaining vulnerabilities together to exploit flaws in applications and infrastructure alike. For example, Anthropic recently disclosed how Mythos was able to identify approximately 23,000 potential vulnerabilities across 1,000 open source software projects. We have also observed in AI-assisted scenarios that the time from initial access to data exfiltration has dropped to as little as 25 minutes. With this in mind, what do extortion activities, regardless of initial access vector or use of single vs double techniques, look like in the age of frontier AI models?

In terms of software supply chain compromise, TGR-CRI-1135 has already targeted AI environments as part of their ongoing campaigns, but what if they were able to weaponize a frontier AI model to further accelerate the speed and scale of their intrusion activities? This would compound the already complex problem of organizations trying to secure their application development and CI/CD pipelines from these types of attacks. The recent disclosure of the SymJack is a prime example of how AI agents could be leveraged in these types of attacks.

With regards to vishing, AI-powered call center platforms like ATHR can nearly fully automate these attacks for human operators by utilizing AI agents to manage calls and other aspects of the intrusion lifecycle. This service not only lowers the barriers to entry for less sophisticated cybercriminals but also further accelerates attacks for more sophisticated threat actors like Bling Libra. The incorporation of frontier AI models into a platform like this would only exacerbate the speed and scale of attacks leveraging this type of capability.

We believe there is an approximate window of 3-5 months before these frontier AI models are weaponized by threat actors. The time is now for organizations to capitalize on a moment where we as defenders can truly establish a “left of bang” posture against a volatile threat landscape.

Defensive Recommendations

Data Exfiltration Detection and Prevention

  • Deploy data loss prevention (DLP) controls at cloud, endpoint, and network egress points.
  • Baseline and alert on abnormal egress volume and velocity.
  • Monitor for staging behavior.

SaaS Security Posture Management

  • Audit OAuth token grants, third-party app integrations, and API permissions across SaaS platforms.
  • Enforce conditional access policies that restrict SaaS sessions by device compliance, location, and risk score.
  • Implement SaaS audit log aggregation and anomaly detection.

Identity and Vishing Resilience

  • Migrate from OTP-based MFA to phishing-resistant authentication (FIDO2/WebAuthn hardware keys).
  • Implement help desk identity verification procedures that cannot be socially engineered.
  • Conduct targeted vishing simulation exercises.

Software Supply Chain Integrity

  • Implement software composition analysis (SCA) and dependency pinning in CI/CD pipelines.
  • Rotate and vault all secrets exposed to CI/CD environments.
  • Monitor package registries for typosquatting and unauthorized updates to internal or frequently-used packages.
  • Enforce code signing and provenance verification for all artifacts entering production.

AI-Accelerated Threat Preparedness

  • Pressure-test detection and response capabilities against compressed attack timelines.
  • Prioritize vulnerability remediation for internet-facing and AI-discoverable attack surfaces.
  • Deploy voice authentication and call verification controls for inbound calls.

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

Unit 42 Deep and Dark Web is a service that assists with gaining visibility into unknown and emerging risks of content posted on the deep and dark web, informs organizations about the exposure of sensitive information, and helps reduce the time between detection and response.

Unit 42 Frontier AI Defense is an elite service that uses access to frontier models to identify your organization's likely attack paths before attackers can weaponize them.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 000 800 050 45107
  • South Korea: +82.080.467.8774

Tracking Iranian APT Screening Serpens’ 2026 Espionage Campaigns

Posted on by Unit 42

Executive Summary

Unit 42 researchers have observed evidence of cyberattacks by the Iran-nexus advanced persistent threat (APT) group Screening Serpens (aka UNC1549, Smoke Sandstorm and Iranian Dream Job). Based on our visibility, we believe that the group targeted entities in the U.S., Israel and the United Arab Emirates, and likely two additional Middle Eastern entities.

This research follows an evolution through cyberattacks in mid-February through April 2026. The timing of these campaigns aligns closely with that of the regional conflict that started in the Middle East on Feb. 28, 2026. We discovered six new remote access Trojan (RAT) variants developed and deployed between February and April 2026.

Screening Serpens has been active since at least 2022. Their recent activity demonstrates an increase in technical capabilities and operational resilience.

Screening Serpens primarily targets technology sector professionals, using highly tailored social engineering. The group frequently uses personalized recruitment lures that impersonate trusted brands and hiring platforms, to trick targets into initiating the infection chain.

We assess with moderate-high confidence that the campaigns discussed in this article are conducted by Screening Serpens. The group has maintained a consistently high operational tempo throughout March and April 2026.

We have grouped the six newly discovered RAT variants into two new malware families that were deployed in concurrent espionage campaigns. Based on the timing of deployment, our analysis indicates two sets of coordinated cyberattacks. At least one variant was compiled and deployed with specific timing instructions.

Our analysis reveals a continuous cycle of development and deployment, characterized by specialized and upgraded variants with diverse functionalities, as shown in each targeted campaign.

The most critical evolution in the group’s recent campaign uses a technique called AppDomainManager hijacking. This hijack method manipulates the initialization phase of .NET applications to proactively disable the application’s own security mechanisms via a legitimate configuration file. The disabled security in these apps left the targeted entities vulnerable to the deployed multi-functional RATs.

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

Cortex AgentiX Agentic Assistant can assist teams in investigating incidents.

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

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

Screening Serpens Overview

Screening Serpens is an Iran-nexus APT group operating as a cyberespionage group aligned with Iranian intelligence objectives. While historically focused on regional targets in the Middle East, the group gained industry attention in late 2025 when Check Point Research detailed its strategic expansion into Western Europe.

During these campaigns, Screening Serpens consistently set its sights on high-value sectors, heavily targeting aerospace, defense manufacturing and telecommunications organizations. These operations are characterized by targeted social engineering campaigns, using lures designed specifically to trick job seekers in these key sectors.

Between February and April 2026, we identified six new remote access Trojan (RAT) variants that Screening Serpens deployed during the recent regional conflict. Based on VirusTotal metadata, it appears these samples may have been used against targets across the U.S., Israel and the UAE as well as two additional Middle Eastern entities. The samples are split into two distinct malware families:

  • A newly discovered malware family that we call MiniUpdate
  • An evolved iteration of a malware family named MiniJunk that we track as MiniJunk V2

Both families build directly upon the actor's established playbook. Their infection chains begin with targeted spear phishing lures, leveraging DLL sideloading for execution. The threat actor routes command and control (C2) traffic through a set of three to five unique domains, mostly hosted by Azure, dedicated to each target and variant. This technique prevents cross contamination to increase operational resiliency.

Timeline of Recent Cyber Activity

Here is the timeline of events in the recent Screening Serpens campaign:

  • In late 2025, Screening Serpens expanded to targets in Western Europe.
  • In mid-February, 2026, we found an indication of a payload delivery to a Middle Eastern target.
  • In late March 2026, we identified samples uploaded to VirusTotal from organizations in the U.S. and Israel.
  • Additional samples from the UAE and another Middle Eastern entity were discovered in mid-April 2026.

Figure 1 shows the transition from campaign preparation to a surge in coordinated attacks following the onset of the regional conflict.

A timeline illustration in the shape of a serpent, depicting a sequence of cyber campaign events from February 2023 to late 2025. Key events include the start of a Middle Eastern phishing campaign, indications of Iranian conflict, and the introduction of malware, MiniJunk V2. MiniUpdate samples were uploaded throughout March in the U.S. and Israel, and in April from the UAE. The campaign is projected to expand globally by late 2025.
Figure 1. Timeline of Screening Serpens documented activity.

As seen in Figure 1, we observed the MiniUpdate family samples uploaded on March 26, April 15 and April 17. We observed the MiniJunk V2 family samples uploaded on Feb. 17 and in an upload on March 27.

We discuss the MiniUpdate family first in our analysis, and then cover the details of MiniJunk V2.

MiniUpdate RAT Analysis

After reading Check Point's initial report, we pivoted off the specific file name (Hiring Portal.zip) of another known Screening Serpens artifact. In doing so, we uncovered four samples that attackers deployed in two sets of coordinated attacks during the recent conflict. VirusTotal metadata indicates that the campaigns may have targeted entities in the U.S. and Israel on March 26, 2026, and most recently, the UAE and another Middle Eastern entity on April 15 and 17, 2026, respectively.

We named this malware family MiniUpdate, referencing the internal file name that we observed within these payloads: UpdateChecker.dll.

By comparing the two sets of coordinated attacks, we observed continued refinement of the malware’s abilities over the course of a month. The differences we identified between the samples were superficial changes to things like opcode mappings and specific functionalities, such as the latest variant’s ability to exfiltrate files in chunks. The most significant difference between the malware variants is the rotation of their C2 domains. While we observed these active adjustments, we did not observe a significant evolution in the malware itself.

MiniUpdate: March U.S. Campaign

Attackers delivered this variant via an archive file, as part of a campaign impersonating a global air carrier. Deployment of this malware began no earlier than March 26, 2026.

Initial Delivery and Targeted Recruitment Lures

An analysis of the archive's contents reveals a tailored social engineering trap aimed specifically at technical personnel. The ZIP contains a nested payload archive (Hiring Portal.zip) packaged alongside six PDF documents.

These PDFs are crafted job requisitions targeting high-level IT and engineering roles (e.g., Senior Software Engineer Job ID JR205894.pdf). Attackers mimicked legitimate corporate job applications by including specific job IDs, increasing the likelihood that the target will review the descriptions and extract the nested Hiring Portal.zip.

Targets likely believed they were accessing an application portal or a technical assessment. We did not find any indication in this campaign of a breach into the global air carrier’s infrastructure. The impersonation was limited to using its name and branding.

Figure 2 shows all the falsified job documents and the Hiring Portal.zip archive.

A screenshot of a file directory displaying five PDF files and one ZIP file, each related to job roles such as Data Analytics & Business Intelligence Specialist, IT Project & Applications Manager, and Senior Software Engineer. The files have modification dates in March 2023 and range in size from 116 KB to 248 KB.
Figure 2. Contents of the archive.

Figure 3 shows one of the Senior Software Engineer Job ID JR205894.pdf files from this archive, which contains detailed job requirements.

A screenshot of a job description for a Senior Software Engineer at a technology and innovation team. The role involves software solutions for businesses, collaboration with cross-functional teams, and process optimization. Key responsibilities include developing applications, maintaining software, supporting integration, resolving issues, and developing technology strategies. The position mentions collaboration, cloud-based systems, and database management.
Figure 3. A fake job description document, designed by the attacker to impersonate a global air carrier company.

Figure 4 shows the contents of the Hiring Portal.zip archive contained in the initial archive file.

A screenshot of a file explorer window displaying the contents of "Hiring Portal.zip." It includes six files, with size, compressed size, and date modified listed.
Figure 4. Contents of Hiring Portal.zip.

Upon executing setup.exe, the malware triggers a spoofed error window titled Hiring Portal.zip to establish legitimacy with the target, as Figure 5 shows.

Error message from Hiring Portal: 'Couldn't connect to survey server' with an OK button.
Figure 5. Spoofed Hiring Portal error window.

MiniUpdate: March Israel Campaign

This variant was delivered via an archive file, to impersonate an install file for a popular video conferencing platform. Our analysis reveals that this variant was recently deployed, no earlier than March 26, 2026, ostensibly against an Israeli entity.

Social Engineering and Initial Access

Analysis of sequential artifact uploads to VirusTotal from March 2026 provides a view into Screening Serpens’ social engineering tactics. The threat actor actively engaged with the target to deliver convincing lures. By correlating the timeline of these uploads, we can map the sequence of the attack:

  • Establishing trust: The target received a number of authentic video conferencing links, possibly to build trust during the phishing campaign.
  • Initial lure: Capitalizing on the precedent of legitimate links, the attacker delivered a lookalike domain to attempt to compromise the target: hxxps[:]//[redacted][.]live/meeting/edcdba624ddb43c2a1dcf334aa493068

Looking into the response reveals a phishing landing page designed to mimic an authentic meeting invitation. It uses the brand’s familiar styling and contains a "join from workplace app" button. The goal of this cloned frontend design is to trick a target into believing they need to install or update their client software to enter a scheduled meeting.

However, the page contains a payload, hidden within JavaScript code, which redirects the victim’s download request away from the legitimate servers. If the victim interacts with the page, a payload delivery is triggered from a third-party file-sharing service via the following URL: hxxps[:]//2117.filemail[.]com/api/file/get?filekey=T0EnWQ6NugHkW_kLfDxPBEw_um6NSkg9ZwNRQ_5lrKrLLUo35pV8m3TKv1LqF3zZzdUm

  • Payload delivery: The targeted lure tricked the victim into downloading the malicious archive from the impersonating website. This file served as the delivery archive for a malicious sideloading chain.
    There is no indication that the attackers compromised or breached the impersonated organization’s infrastructure or systems. Their brand was only used in the context of impersonation to compel the victim to manually execute the malicious payload.

Figure 6 shows the contents of that archive. The first six files are part of the execution chain, while the last file is a genuine installer for the video conferencing application.

A screenshot of a file directory showing various files and a hidden file beginning with an underscore. File types include Application, Configuration Source, Microsoft Edge HTML, and Application extension, with dates from 2025 and 2026.
Figure 6. Contents of the zip archive.

MiniUpdate: Mid-April Middle Eastern Campaigns

In the attacks that may have targeted entities in the UAE and potentially another Middle Eastern country, we identified two new MiniUpdate variants, compiled and submitted to VirusTotal between April 15 and April 17, 2026. While the initial loading mechanism remains consistent with previous variants, leveraging the same impersonation decoy, this version introduces a few upgrades to its infrastructure and core capabilities.

In the variant that may have targeted an entity in the UAE on April 15, 2026, the threat actor rotated the C2 domains to impersonate a health sector entity, using:

  • PremierHealthAdvisory[.]com
  • PremierHealthAdvisory.azurewebsites[.]net
  • Premier-HealthAdvisory.azurewebsites[.]net

In the variant that may have targeted another Middle Eastern entity on April 17, 2026, the threat actor rotated the C2 domains to impersonate a financial sector entity, using:

  • Ramiltonsfinance[.]com
  • Ramiltonsfinance.azurewebsites[.]net
  • Ramiltons-finance.azurewebsites[.]net

Furthermore, the April variants feature an expanded command dispatcher with 18 distinct opcodes, two more than the earlier March campaigns. This increase is valuable to the attackers because it expands their toolkit for stealing data. The primary new command allows the malware to break large files into smaller chunks during upload, providing a stealthier and more reliable way to exfiltrate data from compromised environments.

MiniUpdate Loading Flow

Advanced AppDomainManager Hijacking: Native EDR Evasion

The threat actor employed a .NET-specific code execution technique known as AppDomainManager hijacking. This method allows the attackers to hijack the execution flow of a legitimate application by manipulating its configuration file, granting them arbitrary code execution before the host application even starts. Consequently, the malware can preemptively disable logging mechanisms and other core features that endpoint security tools rely on to detect and block malicious activity.

At its core, this configuration relies on the <probing privatePath="."/> tag to force the local sideloading of an attacker-controlled assembly. It then instantiates a custom AppDomainManager type (such as MyAppDomainManager) to achieve this Pre-Main() execution.

However, the true sophistication of this variant lies in its native defense evasion directives. By adding just a few specific lines of XML, the threat actor instructs the .NET common language runtime (CLR) to proactively disable its own security mechanisms:

  • Silencing event tracing for Windows: The configuration includes the directive <etwEnable enabled="false"/>. Event Tracing for Windows (ETW) is the primary telemetry source used by modern endpoint detection and response (EDR) solutions to monitor .NET execution, track loaded assemblies and detect malicious behaviors in memory. By disabling ETW natively via the application configuration, the attacker potentially shrouds the EDR to the CLR's runtime behavior without needing to perform suspicious memory patching or API hooking.
  • Bypassing signature validation: The <bypassTrustedAppStrongNames enabled="true"/> directive instructs the CLR to skip strong-name signature validation. This ensures that even if the system normally requires cryptographic verification for loaded assemblies, the attacker's unsigned or tampered InitInstall.dll will load silently without throwing a security exception.
  • Preventing safe redirections: The XML configuration file includes <publisherPolicy apply="no"/>. Publisher policies are typically used by Microsoft to redirect application bindings to newer, safer or patched versions of an assembly. Disabling this default policy ensures that the CLR loads the attacker's localized payload and ignores any system-level overrides.
  • Forced runtime environment (safe mode): The configuration uses the <requiredRuntime safemode="true" imageVersion="v4.0.30319"/> directive. This parameter ensures the application executes in a highly controlled, predictable environment by requiring the exact specified version of the .NET runtime. By forcing this strict environment, the attacker reduces the risk of accidental application crashes, which would generate Windows error pop-ups and logs, immediately alerting the user or defenders that something is wrong.

Figure 7 shows the full XML configuration.

A screenshot of a configuration file with XML code. Important sections are highlighted, including safemode set to true, the useLegacyV2RuntimeActivationPolicy set to "no," and bypassTrustedAppStrongNames set to true.
Figure 7. Contents of setup.exe.config.

This represents a mature living-off-the-land approach to execution. Rather than writing complex shellcode to unhook security monitors or patch ETW in memory, actions that often trigger behavioral alerts, Screening Serpens asks the .NET runtime to turn off its own security mechanisms via a legitimate configuration file. Combined with the Pre-Main() execution timing, the malicious InitInstall.dll payload runs in an entirely unmonitored, highly privileged context.

Stage 1: Installation and Creating Persistence

When the advanced .config file successfully hijacks the CLR initialization, it triggers the execution of InitInstall.dll. This C# assembly acts as the primary loader and installer for the second malware family, MiniUpdate.

Before staging the final payloads, the malware unpacks its configuration. The malware's static constructor uses a custom, two-step cipher to decrypt nine key configuration strings. First, the constructor reverses the input bytes interpreted as UTF-8. Next, it applies a standard ROT13 cipher to the alphabetic characters.

Once the strings are decrypted, the loader initiates a sequence that blends user interface (UI) deception with stealthy file staging and persistence.

1. The decoy UI and lure: To disguise the malicious activity happening in the background, the loader launches a background thread that renders a borderless, transparent window. This window displays a custom circular loading spinner specifically designed to mimic a legitimate installer progress indicator. This window has no taskbar entry, making it difficult for a user to inspect or close, as Figure 8 shows.

A spinning blue loading icon on a white square background.
Figure 8. An interface window mimicking a legitimate installer.

2. Staging the MiniUpdate payload: While the fake spinner is displayed, the malware resolves its current directory and constructs a new hidden installation path under the legitimate local appdata directory of the video conferencing application’s folder.

The malware specifically adds a \bin\update folder to hold its files. If the directory does not exist, the malware creates it. The malware then copies and renames four files from the initial infection folder into this new directory:

  • setup.exe is renamed to update.exe
  • UpdateConfig.xml is renamed to update.exe.config
  • Updater.dll is copied as is
  • UpdateChecker.dll (the MiniUpdate payload) is copied as is

3. Establishing persistence: With the files staged, InitInstall.dll leverages Windows Task Scheduler to ensure the payload survives reboots. It creates a scheduled task that is configured to trigger every day at 09:30 local time.

Figure 9 shows the newly created scheduled task in a controlled test environment.

A screenshot of the Task Scheduler interface displays a task running daily at 8:30 AM. The task is set to start a program. The interface includes tabs: General, Triggers, Actions, Conditions, Settings, and History (disabled).
Figure 9. Task Scheduler window showing the associated scheduled task.

After a final 30-second delay, the loader forces the scheduled task to run immediately, starting the execution of Stage 2 by running update.exe.

Stage 2: Anti-Analysis Checks

When the scheduled task triggers the renamed setup binary (update.exe), the malware initiates a second AppDomainManager hijack to safely transition to the next stage. The threat actor uses the dropped update.exe.config file to reapply their native evasion directives, explicitly disabling ETW and strong name verification. This effectively hollows out the legitimate Microsoft process, allowing the next payload, Updater.dll, to load into an unmonitored memory space.

Operating entirely within this blinded environment, Updater.dll acts as a gatekeeper. Before deploying the core RAT, it ensures the malware is executing within the intended infection chain by performing two strict environmental checks:

  • Process verification: The DLL verifies that the current running process is named update.exe.
  • Sandbox evasion: It checks if the parent process is svchost.exe. Because the malware relies on a scheduled task to launch, svchost is the natural parent. If a security analyst or automated sandbox executes the file directly, this check will fail and the malware will silently terminate.

Once the environment is validated, the loader dynamically constructs the path to the final UpdateChecker.dll payload. It loads the module into memory and invokes the CheckForUpdates export, officially handing over control to the MiniUpdate RAT.

Figure 10 shows the full flow of this MiniUpdate malware.

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

Stage 3: Payload Execution and Core Functionality

The MiniUpdate payload operates via external C2s and a compromised digital signature. This variant is driven by a 16-opcode dispatcher, giving attackers extensive control over file operations, shell execution and process manipulation.

C2 Architecture and Network Execution

This variant is designed to cycle through three different command servers in a specific order, checking each one for instructions:

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

The following user agent is used in the communication:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36

  • Digital signature misuse: This payload is digitally signed under the name of a software company whose signature appears to have been stolen or impersonated.
  • Operations security (OPSEC) shift (plaintext strings): MiniUpdate stores all API names, C2 domains and endpoints in plaintext within the .rdata section. This lack of string obfuscation suggests either a rushed deployment cycle or the involvement of a different development cell within the threat group. Conversely, the MiniJunk V2 samples featured heavy Mixed Boolean-Arithmetic and XOR obfuscation.
Core Capabilities

The analyzed payload functions as a highly versatile backdoor, granting the attacker near-complete operational control over the compromised host's file system, processes and environment. Command polling occurs via GET requests to the /agent/poll endpoint. The internal command dispatcher processes a Base64-decoded binary format and supports 16 distinct opcodes. Key capabilities include:

  • Arbitrary command execution: Executes shell commands via cmd.exe /c
  • Dynamic code execution: Loads arbitrary DLLs directly into memory to run specific exported functions
  • Process manipulation: Enumerates running processes and terminates them
  • Data exfiltration: Uploads files to the C2 server, including support for chunked uploads
  • Privilege escalation: Requests User Account Control (UAC) elevation
  • Persistence: Creates a logon-triggered scheduled task named WindowsSecurityUpdate, with built-in capabilities to remove or reinstall this task

MiniJunk V2 Analysis

We assess the second malware family identified in this campaign, MiniJunk V2, is an evolved version of the previously documented MiniJunk malware, featuring updated core functionalities. We correlate this malware family to Screening Serpens, based on the setup.exe file in the lure archive. As documented in Check Point reporting, the threat actor uses this exact legitimate binary to sideload their malicious payloads. Furthermore, we observed the same defense evasion tactics that Check Point's research outlined. Across all samples, the threat actor uses junk code and padding to artificially inflate the file size, successfully bypassing endpoint detection and scanning limits.

On Feb. 17, 2026, a MiniJunk V2 sample appearing to target an entity in the Middle East surfaced shortly before the regional conflict. Our visibility indicated another campaign on March 27, 2026, that may have targeted an entity in the U.S. one month after the conflict began. This timeline strengthens our assessment that the payload is a recently upgraded version derived from previously documented campaigns, illustrating a continuous cycle of development and deployment.

MiniJunk V2: February Middle Eastern Campaign

On Feb. 17, 2026, we identified evidence of a spear-phishing campaign targeting a professional working in the technology sector, based in a Middle Eastern country. Our analysis of the files in the malicious archive indicates that the preparation for this campaign and its malware development began in late 2025. The threat actor conducted careful reconnaissance, exploiting the target's active job-hunting footprint to engineer a customized lure. To establish legitimacy and coerce the target to execute their payload, the attackers shared a spoofed recruitment URL from a legitimate, well-known employment website.

Social Engineering and Initial Access

The threat actor initiated the attack by distributing a spoofed recruitment URL: hxxps[:]//[REDACTED][.]com/career/recreuitment/[REDACTED]. This endpoint currently returns an HTTP 404 Not Found status code, which we assess was a visual decoy intended to mislead the target.

The URL’s specific misspelling (recreuitment) indicates an intentional, fraudulent fabrication, engineered with the knowledge that the link would remain non-functional by design. Analysis shows no indication that the impersonated organization’s infrastructure, systems or domains were compromised or breached.

The group likely used this non-functional URL to prompt the target to take a work around solution into an offline portal. The target would then be redirected to a dedicated storage instance hosted within an attacker-managed ONLYOFFICE workspace. This infrastructure served as the delivery point for the primary payload, where the victim was induced to download a malicious archive disguised as legitimate recruitment materials

The attack execution advances when the victim complies with the lure instructions, manually retrieving and downloading the weaponized Portal.zip archive. This archive contains a file named Setup.exe and three hidden files. Since the default Windows settings do not reveal hidden files, a user would not normally see these three files. Figure 11 shows the contents of the archive.

A screenshot showing file explorer windows with a "Portal.zip" folder. The folder contains files including "Setup.exe." Another window displays "Folder Options," highlighting the default Windows setting to hide certain files. A label points to hidden files loaded by "Setup.exe".
Figure 11. Contents of the Portal.zip archive containing hidden files, with uevmonitor.dll used as the payload for the attack.

One of the hidden files is a malicious DLL named uevmonitor.dll that contains the payload for this attack. If a user runs the Setup.exe file, the action initiates an infection chain under the context of the logged-in user.

AppDomainManager: Sideloading and Hijacking

During our analysis of the MiniJunk V2 sample, we observed the threat actor using an older version of .config file to facilitate local sideloading. In this instance, the attackers authored a custom malicious DLL named uevmonitor and deployed it alongside a legitimate .NET executable. To successfully sideload their payload into the host process, they used the <probing privatePath="./"/> directive, forcing the application to prioritize its local working directory, which is a key prerequisite for DLL sideloading.

The original MiniJunk configuration lacked operational security measures such as evasion features, making it susceptible to detection. The attackers updated their newer tool, MiniUpdate, with stealthy evasion techniques. Figure 12 shows the original .config file, which was used only for sideloading the uevmonitor.dll file.

A screenshot of a code snippet showing XML configuration settings.
Figure 12. Contents of the .config file.

Technical Analysis of the Payload

Serving as the primary loader, the uevmonitor.dll assembly initiates the infection chain once executed by the initial, legitimate Setup.exe host process. It silently drops two embedded payloads into the local AppData directory:

  • SoftwareLicencing.exe: a renamed, legitimate Microsoft setup binary
  • unbcl.dll: the core malicious payload

To maintain its foothold, the loader creates a scheduled task for persistence named Synchronize OS and simultaneously displays a decoy system error to the user to mask this background activity. The sequence culminates when the scheduled task triggers SoftwareLicencing.exe, which specifically sideloads the malicious unbcl.dll into its trusted memory space. This action successfully deploys the heavily obfuscated RAT, granting the attacker operational control via externally-hosted C2 infrastructure.

Figure 13 demonstrates the entire flow to deploy the malicious RAT, including AppDomainManager hijacking and two DLL sideloading instances.

A flowchart depicting the process of the MiniJunk V2 malware. It includes stages such as displaying a decoy error message, saving payloads to a scheduled task location, dropping various files, and executing the final payload. Key files mentioned include malicious archive, legitimate setup.exe and various DLLs.
Figure 13. MiniJunk V2 malware flow.
C2 Loop and Network Execution

During execution, the malware dynamically decrypts data within its code to retrieve five C2 domains:

  • licencemanagers.azurewebsites[.]net
  • LicenceSupporting.azurewebsites[.]net
  • PeerDistSvcManagers.azurewebsites[.]net
  • ThemesManagers.azurewebsites[.]net
  • ThemesProviderManagers.azurewebsites[.]net

These domains mimic legitimate Windows service names, attempting to blend in with network communication.

Simultaneously, the malware uses Mixed Boolean-Arithmetic decryption to construct a hard-coded User-Agent string. The resulting string mimics legitimate Microsoft Edge browser traffic:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36 Edg/144.0.0.0

Behavioral analysis confirms that the malware interacts with specific API endpoints on the C2 servers. The endpoints implemented are:

  • /api/app/check: The initial beacon, handling victim registration and establishing the session.
  • /api/app/update: Retrieves execution commands and downloads subsequent payloads.
  • /api/app/comment: Exfiltrates data and sends operational status reports to the threat actor.

The malware’s .rdata section is packed with thousands of junk strings, including Java and Python tracebacks, SQL queries and .NET exceptions. These strings repeat every 0x1E50 bytes. This repetition serves two purposes:

  • Flooding string extraction tools with irrelevant data
  • Inflating the binary size to around 12 MB in an attempt to bypass file-size limits on certain automated sandboxes

The sideloading chain and malicious executable triggered Cortex XDR to flag this threat as high risk. It also prevented the threat from executing before any user interaction could take place. Figure 14 shows this detection and prevention.

A screenshot of Cortex XDR report interface. The summary details a DLL Hijacking issue identified, involving WildFire Malware detection and a suspicious DLL. Two issues are listed: "WildFire Malware" with one alert for a suspicious DLL detected, and "DLL Hijacking" also with one alert. The event details section provides specific information, such as time, status, and path. The report also features a graph and information to the right side.
Figure 14. The infection chain originating in malicious DLL sideloading (categorized "DLL Hijacking"), as seen, detected and prevented by Cortex XDR.

MiniJunk V2: March U.S. Campaign

While tracking the unique SoftwareLicencing.exe file, we discovered a newly developed malware variant that may have been deployed against a U.S.-based target. First submitted to VirusTotal on March 27, 2026, the malware is delivered within an archive named Portable platform.zip. This malware sample appears to have been actively developed and used during the recent regional conflict.

This latest iteration features a complex, multi-stage execution chain designed to evade detection. It relies on a social-engineering decoy graphical user interface (GUI) to deceive the target while quietly establishing a heavily obfuscated C2 connection.

Social Engineering and Initial Access

The infection begins with the Portable platform.zip lure archive, hosted on a unique ONLYOFFICE DocSpace: hxxps[:]//docspace-y4cumb.onlyoffice[.]com/storage/files/root/folder_3602000/file_3601577/v1/content.zip[...]

Figure 15 shows the archive content.

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

Figure 16 shows the file folder content.

Screenshot of a file explorer window displaying two files, with their names, modification date and time and sizes listed. Navigation and sorting options are visible at the top.
Figure 16. Contents of file folder inside Portable Platform.zip.

Upon extraction, the archive initiates a DLL sideloading sequence. The execution flow leverages the legitimate Setup.exe, which subsequently loads two malicious components:

  • Unbcl.dll: a social-engineering decoy
  • Connection.dll: the primary payload, a RAT

The execution of Unbcl.dll creates a background thread displaying a GUI to the target. The window is titled “Meeting Room” and prompts the victim to provide a “Meeting Room URL.” This provides a plausible reason for the execution, tricking the victim into believing they are joining a legitimate web conference while the primary C2 beacon operates silently in the background.

Figure 17 shows the decoy window.

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

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

  1. It performs a hard-coded date-based validity check to ensure that the RAT runs on any date that is after March 27, 2026, 13:30:00 UTC. This validity check serves as an execution trigger that potentially enables the threat actor to avoid sandbox analysis, bypass initial security screenings and maintain a low profile until the predetermined operational phase begins.
  2. If successful, the RAT spawns the main worker thread, constructs a file path using its internal name (SystemtUpdateTaskMachine.exe) and performs an instance check to ensure it is only running once.

Technical Analysis of the Payload

The Connection.dll payload is another RAT with multiple capabilities and defense evasion mechanisms.

Once in the main loop, the malware XOR-decrypts (using a single-byte key, 0x8A) data within its code to acquire a Chrome-based User-Agent string and three URLs using Azure-hosted C2 domains. These domains impersonate global companies operating within the technology, cybersecurity and artificial intelligence sectors:

  • hxxps[:]//NanoMatrix.azurewebsites[.]net
  • hxxps[:]//QuantumWeave.azurewebsites[.]net
  • hxxps[:]//ElementShift.azurewebsites[.]net

The malware beacons to the primary C2 base URL via an HTTP POST request. Depending on the parsed response, the malware will execute chunked uploads or downloads via specific transfer URLs or create additional threads for command execution.

Conclusion

The continuous tracking of the Iran-nexus APT group, Screening Serpens, reveals a persistent threat group that has remained active in recent months. The group has increased its operations since the regional conflict that started in February 2026, deploying two families of RAT variants across entities in up to five different countries.

A defining characteristic of these recent campaigns is the deep personalization of the attackers' lures. By leveraging tailored social engineering tactics, including fake job requisitions and spoofed video conferencing meeting invitations, the attackers lure victims into initiating the infection chain, thereby exposing their organizations to further exploitation.

We observed a significant evolution in the group’s tradecraft: For the first time, Screening Serpens has fused its standard DLL sideloading techniques with advanced AppDomainManager hijacking. By weaponizing the .NET initialization process and manipulating legitimate configuration files, the group can now preemptively bypass traditional security telemetry and execute payloads before most standard endpoint defenses are fully initialized. This tactic effectively allows attackers to establish persistence and maintain full operational control over the exfiltration of sensitive data.

Instead of relying solely on known malware indicators, defenders should ensure that EDR tools are fine-tuned to detect DLL sideloading and AppDomainManager hijacking. Treating these specific execution techniques as high risk will help organizations to identify behavioral anomalies associated with trusted, signed binaries loading untrusted modules.

As of April 2026, Screening Serpens activity shows no signs of slowing down and has continued to orchestrate sustained, adaptive global cyber campaigns. Organizations may expect further attempts in the near term and should harden their defensive posture to prepare for potential compromise attempts.

By leveraging its cutting-edge ecosystem, Palo Alto Networks customers are better protected from the threats discussed above through these industry-leading products:

  • The Advanced WildFire machine-learning models and analysis techniques have been updated to protect against the indicators shared in this research. Advanced WildFire is powered by Precision AI.
  • Advanced URL Filtering and Advanced DNS Security identify and block known domains and URLs associated with this activity in real time.
  • Cortex XDR and XSIAM help to prevent the threats described in this article, by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, to prevent both known and unknown malware from causing harm to endpoints — all in a single interface.
  • Cortex Cloud customers are better protected against operations that target cloud environments through the proper placement of Cortex Cloud XDR endpoint agent and serverless agents. Screening Serpens’ use of cloud infrastructure to host command and control endpoints points to cloud architecture functionality. Cortex Cloud is designed to protect a cloud’s posture and runtime operations against the threats outlined here. It also helps detect and prevent malicious operations, configuration alterations and exploitation within cloud environments.
  • Cortex AgentiX Agentic Assistant streamlined our investigation by enabling the team to query the data using natural language, providing deeper context and insights, and suggesting clear recommendations on what we should do next. Figure 18 shows the AgentiX interface when querying for malicious activity in a tenant.
A screenshot of AngentiX report detailing an 'Endpoint Investigation' about DLL hijacking events. It includes sections on issue details, key findings and insights, a case overview, and a request for further action. The report mentions techniques like DLL Sideloading and TRAPS (Threat Response Automation Service).
Figure 18. Querying for malicious activity in the tenant, using AgentiX.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 000 800 050 45107
  • South Korea: +82.080.467.8774

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

Domains:

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

URLs:

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

SHA256 Hashes:

MiniUpdate: US Campaign

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

MiniUpdate: Israel Campaign

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

MiniUpdate: UAE Campaign

  • bc3b44154518c5794ce639108e7b9c5fecb0c189607a26de1aaed518d890c7ad - UpdateChecker.dll

MiniUpdate: Middle Eastern Campaign

  • 74882085db2088356ed7f72f01e0404a0a98cda88ef56fb15ce74c1f36b26d27
  • bc3b44154518c5794ce639108e7b9c5fecb0c189607a26de1aaed518d890c7ad - UpdateChecker.dll

MiniJunk V2: Middle Eastern Campaign

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

MiniJunk V2: U.S. Campaign

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

Additional References

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

Posted on by Sheida Azimi

Executive Summary

ROADtools is a publicly available toolkit for offensive and defensive security purposes that attackers have integrated into cloud attacks. The tool is designed to:

  • Enumerate Entra ID
  • Register devices in Entra ID
  • Acquire, exchange and manipulate Microsoft Entra ID tokens

ROADtools is an open-source framework written in Python and built for red-teaming and research. It primarily targets the identity and authentication layers of Azure, and focuses on how accounts, applications and tokens operate in tenants.

To avoid detection, ROADtools operates through legitimate Microsoft APIs and can mimic typical traffic. Further defense evasion can be achieved by configuring request attributes such as user-agent strings. These capabilities have made ROADtools a valuable asset for attackers. Nation-state threat actors have used it in recent cloud intrusions for discovery, persistence and defense evasion. Attackers involved in a targeted phishing campaign in early 2025 used tooling that matches ROADtools' token management capabilities.

We provide an accessible overview of ROADtools, including how it evades detection and how nation-state threat actors and other adversaries misuse it. To aid defenders in protecting organizations against this threat, we also provide:

  • Straightforward hunting queries that can reveal ROADtools usage
  • Practical recommendations to detect and prevent the effectiveness of ROADtools within an environment

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

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

Related Unit 42 Topics Microsoft Azure, Cloud, MITRE

Tool Overview

ROADtools is able to interact with Entra ID via legitimate APIs, and to customize user-agent strings — both of which help it to evade detection. The tool includes several modules — two of which we discuss in this article - and a set of shared libraries.

The ROADrecon Module

The roadrecon module is designed for internal discovery and enumeration. It gathers organizational data and identity information from Entra ID (formerly Azure Active Directory), including:

  • Users
  • Groups
  • Roles
  • Devices
  • Service principals
  • Applications
  • Directory configurations

Results are stored in a local SQLite database that can be viewed through a custom web interface. This provides a graphical way to navigate the tenant and identify relationships or privileged objects that attackers could use for persistence or escalation. Figure 1 shows Entra ID Groups within the ROADrecon graphical web interface.

A screenshot of the ROADrecon interface displays a menu on the left with options like Home, Users, and Administrative Units. The main area shows a list with headings: Name, Description, Group type, and Group source. The list includes groups such as "All Users" and others.
Figure 1. Entra ID Groups in the ROADtools web interface.

The roadrecon module originally queried the Azure AD Graph API to enumerate Azure AD resources. However, Microsoft has stated the Azure AD Graph API is being retired and all new or existing applications must migrate to Microsoft Graph API, which breaks a fundamental component of the original roadrecon functionality.

As of May 2026, an msgraph branch exists in the official ROADtools Github repository but has not been updated since April 2025. Subsequent development has continued in a separate, community-maintained fork, where partial roadrecon functionality has been implemented using the Microsoft Graph API. This fragmentation means users might encounter inconsistent functionality, while attackers can still enumerate Entra ID accounts and resources, as described in the Discovery section below.

The Token eXchange (roadtx) Module

The roadtx module facilitates token acquisition and exchange, enabling attackers to interact with Entra ID’s authentication endpoints. It supports several OAuth 2.0 and OpenID Connect authentication flows (sign-in methods), including:

  • Entering a device code from another device (device code flow)
  • Reusing a refresh token to get new access
  • Allowing an application to request access on behalf of a user (known as an on-behalf-of or OBO flow)

The output of roadtx is typically a set of OAuth 2.0 access and refresh tokens in JSON format, which can be used to authenticate against Microsoft cloud services. The roadtx module can be used to register devices with Entra ID, replay stolen tokens and manipulate token lifecycles. This capability allows attackers to persist in an environment and bypass multi-factor authentication (MFA).

Supporting both roadrecon and roadtx is roadlib, the library layer that handles low-level authentication and API requests. The roadlib module provides the core functionality for ROADtools. It abstracts much of Microsoft’s authentication complexity, allowing an attacker or researcher to script token requests and API calls without having to know every OAuth detail.

This module is flexible and can be pointed at different API endpoints, including custom or non-Microsoft endpoints. This feature makes ROADtools easy to adapt to other security tooling and enables it to target a wider range of authentication systems.

With the above functionality in mind, the rest of this article explains how adversaries leverage ROADtools to perform their operations and what defenders can do to protect against ROADtools.

Threat Actor Usage and Industry Targeting

The use of ROADtools has evolved from a red-team utility to an attack tool. Industry reports illustrate that various nation-state threat actors are leveraging the tool to conduct malicious activity:

  • Early observation of a nation-state actor operationalizing the ROADtools framework came in late 2021, when Microsoft reported on activity by Cloaked Ursa (aka Midnight Blizzard or APT29). The group’s campaigns began with highly targeted spear phishing to gain initial access. Cloaked Ursa subsequently leveraged ROADtools to conduct discovery and enumerate victims’ Azure AD (now Entra ID) environments.
  • Microsoft reported the Iranian state-sponsored threat actor Curious Serpens (aka Peach Sandstorm, APT33) using ROADtools in malicious operations in 2023. After gaining initial access through password spray attacks, the threat actor used tools, including ROADtools for internal discovery.
  • Volexity reported in 2025 on a targeted phishing campaign during which a state-affiliated threat actor, which it calls UTA0355, was able to register a rogue device with Entra ID. Attackers were able to acquire a new token with full access to the Microsoft Graph API. The tooling Volexity reported matched the roadtx module’s token management capabilities.

MITRE ATT&CK® Tactics

MITRE ATT&CK provides a structured way to describe how attackers operate. Organizing findings by MITRE ATT&CK Tactics, Techniques and Procedures enables defenders to:

  • Map attacker behaviors to a common language
  • Compare those behaviors across intrusions
  • Prioritize detections and mitigations based on the actions attackers take

In the sections that follow, we reference specific MITRE techniques to show how ROADtools components enable those behaviors, including:

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

Persistence

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

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

The ROADtools roadtx module can register new devices in Entra ID. Attackers register or join devices to gain a durable means of persistence through a controlled account. Registration allows a rogue device to appear as a legitimate object in the Entra ID device inventory. Depending on the Entra ID configuration, a registered or joined device may also enable attackers to bypass MFA and conditional access policies (CAPs).

To register a device using roadtx, an attacker must first obtain valid credentials. The attacker can then use these credentials with roadtx to authenticate via one of the supported authentication flows, to acquire an access token for the Azure device registration service (urn:ms-drs:enterpriseregistration.windows[.]net).

After authentication, the attacker runs roadtx again, which calls the Azure device registration API to create a new device entry. The roadtx module writes the device certificate and key to the local file system and registers the device in Entra ID. Note that roadtx has default values for some command parameters. Unless specified otherwise, the devices will be registered as:

  • OS: Windows
  • OS Version: 10.0.19041.928
  • Name: DESKTOP-<RANDOM 8 DIGITS>

While these default values can be useful for detection purposes, they are also simple to change. All defaults can be viewed by running roadtx device -h from the command line, or by viewing them in the roadtx source code.

Figure 3 shows how an attacker uses a previously acquired refresh token to authenticate to the Azure device registration service and register a new device with the name mydevice.

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

Defense Evasion

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

Callout box with an icon of a cloud with circuit lines and the biohazard symbol paired with text that reads, "roadtx turns stolen credentials into access that can bypass controls."
Figure 4. MITRE ATT&CK technique T1550.

Attackers try to acquire tokens because those tokens let them access company data and cloud services on behalf of a user or service, often without triggering a new interactive sign-in, enabling activity that blends in with legitimate API usage. Tokens allow attackers to move laterally, copy data and obtain persistent access in a target environment, bypassing interactive controls like MFA.

By leveraging a Primary Refresh Token (PRT), an attacker can maintain access to cloud applications by silently obtaining new access tokens in the background, which are then used in subsequent API requests, eliminating the need for repeated logins. The roadtx prt command allows attackers to acquire such a PRT. Full details of the process for registering a device and PRT acquisition are described by the ROADtools author.

Using roadtx, attackers can automate the misuse of a stolen PRT. This automation involves performing the token exchange and API call workflows that are needed in order to acquire fresh user access tokens and to call services such as Microsoft Graph non-interactively. A single device-bound PRT compromise can provide an attacker with persistent, programmatic access across the tenant.

Discovery

Technique: T1087 Account Discovery (Figure 5).

Callout box with an icon of a face, followed by the text: "Once tokens are obtained, roadrecon can quickly translate them into actionable intelligence."
Figure 5. MITRE ATT&CK technique T1087.

Attackers perform account discovery to map an environment, identify high-value accounts and find lateral movement or privilege escalation targets. Ongoing efforts within the ROADtools community to adopt the Microsoft Graph API have enabled continued use of roadrecon for account discovery.

To use roadrecon for discovery, attackers must first authenticate to acquire the refresh and access tokens that allow access to the Microsoft Graph API. The authentication must use a client ID that has the necessary permissions for all the Microsoft Graph API endpoints that they wish to enumerate.

The Microsoft Graph API version supports a new roadrecon command-line parameter -mg that points the code to the Microsoft Graph API to enumerate resources such as:

  • /users
  • /groups
  • /devices
  • /servicePrincipals
  • /applications

This enumeration enables attackers to harvest account names, devices, roles, group membership and service-principal metadata. These are written to the local SQLite database as previously noted.

Figure 6 below lists devices registered in Entra ID as shown in the ROADtools custom web interface. This example is from a test environment but serves to illustrate the ease of discovering resources in the environment. Note the OS Version 10.0.19041.928 circled in red. As described earlier, this is currently the default value that roadtx uses when registering a device, and is different than the OS version for the other hosts, making it a good indicator of ROADtools activity.

A screenshot of the ROADReconf interface displaying a list of devices. Each entry includes columns for name, manufacturer, enabled status, model, operating system, and trust type. One entry is highlighted in red showing the OS version.
Figure 6. ROADtools custom web interface.

Defender Perspective

The discussion so far has focused on how adversaries can misuse ROADtools. It is equally important to understand what defenders can do in response. Preventive controls and active threat hunting offer organizations multiple opportunities to detect and disrupt these techniques.

Preventive Controls to Limit Token Misuse

ROADtools is challenging for defenders to detect because it operates within expected behavior. It does not exploit buffer overflows or drop binaries onto hosts, but instead uses the authentication flows and APIs that organizations rely on every day. Implementing layered identity defenses can limit how attackers misuse ROADtools. Defenders should consider the following controls:

  • Enable Entra ID token protection: Enabling token protection reduces the value of stolen refresh tokens. Binding refresh tokens to a specific device (token protection/“client claims”) is one of the most direct ways to prevent the replay or misuse of tokens obtained by roadtx. This makes it harder for adversaries to export and reuse tokens from other hosts.
  • Restrict device code flow via conditional access: CAPs can restrict risky flows, such as device code, where they are not needed. Attackers use roadtx to misuse device code flow because it works well for script-based attacks. Blocking or restricting this flow to only trusted scenarios (like registered devices, trusted IP address ranges or specific apps) cuts off an attack path.
  • Audit OAuth apps regularly: Auditing applications for delegated and application permissions that have been granted helps eliminate excessive privileges that attackers target. Attackers can use roadtx to obtain tokens for any registered app if permissions are in place. Custom or abandoned apps with overly broad Microsoft Graph, SharePoint or Exchange permissions are prime targets. A cloud security posture management (CSPM) or cloud-native application protection platform (CNAPP) solution can help defenders conduct regular reviews, to reduce the attack surface.
  • Limit privilege exposure: Even if an attacker manages to obtain a token, organizations can greatly reduce potential damage by using privileged identity management (PIM) or privileged access management (PAM) to limit standing privileges and conditional access to require step-up authentication. These measures enforce least privilege and minimize the impact of a compromised account.
  • Correlate logs across multiple sources: Detection and threat hunting depend on event correlation. Prepare for this by bringing Azure audit logs, Microsoft Graph API activity logs, sign-ins and Office 365 activity together into a security information and event management (SIEM) platform to provide the visibility needed to spot anomalous API usage.

These controls help prevent and detect common attack techniques and lay the groundwork for effective threat hunting. With these controls in place, defenders can more effectively search for suspicious token usage, authentication flows or discovery activity before they escalate into compromise.

An attacker using roadtx for authentication is using valid credentials. As such, defenders must establish a baseline of normal activity for that user or resource to understand whether a sign-in is malicious or legitimate.

Microsoft Entra ID Protection provides two important reports for this purpose:

  • Risky sign-in reports surfaces attempted and successful user access activities where the legitimate owner might not have performed the sign-in
  • Risky user reports surfaces user accounts that might have been compromised (e.g., a leaked credential that was detected or the user signing in from an unexpected location in the absence of planned travel)

Hunting ROADtools Activity

With preventive controls in place, the next step is to actively look for signs of misuse. Threat hunting in this context goes beyond reviewing alerts. It requires systematically searching for anomalous patterns in device joins and registrations, and for token issuance and Graph API calls that could indicate suspicious roadtx or roadrecon activity.

Device Registration

Start by looking for evidence that adversaries are running ROADtools to register or join devices into Entra ID. Inspect audit events that relate to device registration, highlighting which users or service principals initiated the action. The broader objective is to detect when an attacker attempts to establish persistence in Entra ID by creating and controlling unauthorized devices.

Token Misuse

Next, look for evidence of token misuse. We have discussed how roadtx and roadlib are designed to acquire and refresh tokens programmatically. To defenders, that activity looks different from a standard browser or app sign-in. These differences include:

  • Scripted user agents
  • Service principals authenticating outside of expected patterns
  • Automated sign-in behavior that doesn’t resemble human use

The goal is to flag when an attacker is misusing tokens to blend in with legitimate activity while running scripted, malicious roadtx commands against the tenant. For example, an attacker may run roadtx with a version of python-requests (a Python library that supports HTTP) that is not usually seen in an organization's environment. Or even simpler, sign-ins via Python might not be expected in an organization at all, or only from certain IP ranges.

Microsoft Graph API

Finally, look for evidence of attackers using roadrecon to access the Microsoft Graph API and enumerate users, groups, service principals, applications and devices. These discovery activities are not limited to ROADtools and can be performed directly through Microsoft Graph API calls using custom scripts or other tooling.

For defenders, the key is to watch Microsoft Graph API logs for bursty, repetitive queries against those endpoints. Legitimate administrators rarely perform these actions in bulk. Defenders must migrate any roadrecon detections that rely on Azure AD Graph activity logs to use Microsoft Graph activity logs instead.

Conclusion

ROADtools is an example of the dual use of security tooling. Released as a framework to interact with Azure AD for offensive and defensive security purposes, attackers have adopted ROADtools as a platform for real-world intrusions against Microsoft cloud environments. We have seen how its features map to MITRE ATT&CK techniques, and identified the alignment with attacker tactics of persistence, defense evasion and discovery.

For defenders, the challenge lies in ROADtools’ use of legitimate APIs and authentication flows. ROADtools activity can easily blend into normal cloud operations. Identifying malicious use of this toolset requires careful attention to anomalies in user agents, IP addresses, activity type and Graph API usage. Mitigations like token protection, conditional access policies, cloud security audits and privileged identity management provide additional layers of defense.

Palo Alto Networks Protection and Mitigation

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

  • Cortex Cloud endpoint protection can help protect organizations from threats expressed within this article. Cortex Cloud 2.1 can detect and prevent malicious operations through the use of behavioral and AI enabled analytics to detect when cloud and container endpoints are targeted. Additionally, it can detect when cloud platform IAM policies associated with those targeted endpoints are being misused and alert teams when assets are vulnerable to these threats.
  • Cortex XDR and XSIAM customers can use the hunting, investigation and detection queries below to identify potentially suspicious activity related to the threats discussed in this article. In addition, Cortex Identity Threat Detection and Response (ITDR) can help in detecting authentication and credential-based threats by analyzing user activity from multiple data sources including endpoints, network firewalls, Active Directory, identity and access management solutions, and cloud workloads.
  • The Unit 42 Cloud Security Assessment is an evaluation service that reviews cloud infrastructure to identify misconfigurations and security gaps.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 000 800 050 45107

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Hunting, Investigation and Detection Queries

The queries below are designed to help Palo Alto Networks customers hunt for, investigate, and identify potentially suspicious activity using Cortex XDR. Results returned by these queries should not be considered inherently malicious and require further analysis to determine their significance.

Cortex XQL Queries

Device Registration

The XQL query below hunts for threat actors using ROADtools to register or join devices in Entra ID, focusing on audit events that reveal initiating identities and potential attempts to establish persistence through unauthorized device creation. Depending on the environment in which this is run and in what timeframe, the query could return a large set of results. A 24-hour timeframe spanning any suspicious activity is a good starting point. Look for results from unexpected or suspicious locations or identities. Also, look for any device names that do not conform to expected naming conventions in your organization.

Token Misuse

The following query looks for evidence of token misuse, as roadtx and roadlib generate authentication patterns that might differ from regular user sign-ins. Focus on anomalies like scripted user agents, unusual service principal activity, and automated sign-in behavior – such as unexpected Python-based access – that may indicate threat actors executing malicious actions.

Microsoft Graph API

The following XQL query looks for roadrecon activity by monitoring Microsoft Graph API logs for high-volume, repeated enumeration of users, groups and applications – behavior uncommon for legitimate administrators. We built the following hunt query to detect this enumeration pattern, revealing when a threat actor is systematically mapping out the directory. The API call threshold should be adjusted to values indicating outliers in your organization.

Indicators

User-Agent string in HTTP headers of network traffic:

  • roadtools
  • python-requests/<version>

Additional Resources

Tracking TamperedChef Clusters via Certificate and Code Reuse

Posted on by Sheida Azimi

Executive Summary

This article documents novel activity clusters that have significant overlap with the publicly described threat known as TamperedChef (aka EvilAI). TamperedChef-style malware is trojanized productivity software, such as PDF editors or calendars, that deliver malicious payloads.

These campaigns typically employ malicious ads that direct users to sites hosting the applications. While this style of malware shares many similarities in technical operation, installation lures and distribution methods, we do not attribute it to a single author or group.

TamperedChef-style malware samples share characteristics with potentially unwanted programs (PUPs) and adware. These include robust mechanisms to remain persistent, and end-user licensing agreements (EULAs) that attempt to legally cover the software's questionable actions. However, TamperedChef-style malware is far more stealthy than PUPs or adware, remaining dormant for weeks to months before activating. This includes continuous command and control (C2) methods enabling adversaries to retrieve additional payloads, such as information stealers, proxy tooling or remote access Trojans (RATs).

We have been tracking several campaigns of TamperedChef-style activity starting in 2024, with three distinct clusters: CL-CRI-1089, CL-UNK-1090 and CL-UNK-1110. Between the three clusters of activity, we have identified over 4,000 samples across 100 unique variants.

Palo Alto Networks customers are better protected from TamperedChef activity discussed in this article through the following products and services:

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

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

The Rise of Malicious Productivity Applications

Since early 2024, we have observed a sharp increase in information stealer-style incidents originating from software mimicking legitimate productivity tools (e.g., PDF editors, ZIP file extractors, GIF image makers). Upon deeper inspection, these applications generally contain code that enables the delivery of arbitrary binaries. These features are typically used to deploy stealer malware.

In 2025, our telemetry revealed over 100 unique variants of malware masquerading as productivity software. They all contained a malicious component, such as basic RAT capabilities, or delivering adware and infostealers.

Due to their legitimate functionality and tendency to remain dormant for long periods of time, these applications often go unnoticed by the victim. They are also commonly downplayed or miscategorized by defenders and security researchers as potentially unwanted programs (PUPs). Because these applications can execute arbitrary code on victims' machines, either directly or indirectly through module loads, these threats are more significant than mere background annoyances or adware.

We have been able to track over 4,000 file hashes and 81 unique code signing organisations through several methods, including:

  • Reviewing code-signing certificates of the binaries
  • Analyzing code reuse among the binaries
  • Open-source intelligence (OSINT) on corporate structures for organizations distributing the binaries
  • Leveraging ad transparency platforms to hunt for advertising overlaps that can identify additional organizations distributing the binaries

We have identified TamperedChef-style malware campaigns starting in 2023. These malicious productivity application campaigns include AppSuite PDF, Calendaromatic, JustAskJacky and CrystalPDF.

Masquerading in Plain Sight

The actors behind these campaigns take steps not commonly observed with other adware groups to remain undetected. In some cases, these attackers appear to diversify their revenue streams through more aggressive and malicious activities. This diversification includes deploying infostealers, establishing residential proxies and exhibiting behavior that resembles access brokers.

These applications avoid many of the common indicators that users are trained to associate with downloading malicious software, such as:

  • Distributing via well-built, legitimate-looking websites
    • Without ads (as shown in Figure 1)
    • Appearing modern and credible
    • Containing common elements like descriptions, legal terms and contact pages
  • Leveraging unique and contextually relevant domains for each campaign
  • One-click download buttons distributed by large content distribution networks (CDNs) to minimize friction
  • Providing promised functionality with minimal bloat, meaning victims are not likely to suspect anything is amiss
Screenshots of four website homepages in a collage advertising PDF software. The top left shows "Sonic PDF" offering premium PDF software for Windows with advanced features. The top right is "PDF SuperDrive," highlighting professional PDF software and its user base stats. The bottom left is "Crystal PDF," featuring a free download for PDF conversion and management. The bottom right is "ImageryX," promoting neural creativity with vibrant visuals.
Figure 1. Examples of download pages for TamperedChef-style fake productivity applications.

Attackers also employ several tricks to avoid detection. These tricks include:

  • Using code signing to increase the apparent legitimacy of the binaries
  • Rebuilding binaries with only minor changes on a frequent basis to minimize the effectiveness of static or hash-based detection
    • The exact frequency varies, but is typically between one week and one month per rebuild
  • Remaining dormant for periods of weeks to months before retrieving or running malicious components

This combination of technical and social masquerading enables these applications to remain undiscovered, unreported and free to operate without resistance for months — if not years — at a time.

What Is Adware vs. Malware?

Adware is a class of software designed to increase the number of ads a user observes. The more ads they observe, the more money for the distributor. This is typically done with some form of browser manipulation or additional free tooling bundled alongside downloads.

Adware sits in a middle zone between malware and legitimate software, often employing malware-like tactics to maintain persistence or display more ads to users. The distinction between malware and adware can be so fine that they are indistinguishable from each other when statically analyzed, only becoming clear after misuse occurs. Adware and malware are also often interlinked, with many seemingly legitimate adware developers overstepping into malware territory, either naively or intentionally.

Modern adware also walks the line between legal and illegal behavior. EULAs are ways that the groups behind adware and TamperedChef-style malware attempt to protect themselves legally. Examples of this are found on websites distributing TamperedChef-style software, such as one from hxxps[:]//www.crystalpdf[.]com/conditions:

“The Additional Services offer users enhanced, tailored features. Be aware that using these services may modify your browser’s new tab settings or installed features, possibly altering your browser configuration.”

However, TamperedChef-style programs execute commands remotely, exfiltrate users' credentials and deploy malware without consent. These actions firmly place them in the malware category.

A Historical Review of TamperedChef (Aka EvilAI)

The name TamperedChef was initially given to a cluster of activity that included several malicious recipe applications, PDF editors, manuals and search assistant applications. It started to see widespread installation in June 2025, with some evidence suggesting these applications have been in the wild since February 2025.

As reporting on malicious productivity apps within the cybersecurity community grew, TamperedChef became a broad, informal term for several productivity software campaigns. These campaigns are likely not all operated by the same group.

The confusion in previous reporting is understandable, as many of the actors are leveraging extremely similar tactics, techniques and procedures (TTPs) and lures. The differences only become apparent when observing the infrastructure, code quality and organizations tied to the code signing. It is important to understand these differences to separate the attackers' motivations, capability and risks.

We identified and tracked three major clusters of activity that share many of the same operational traits, but we believe these represent three distinct groups. We track the three main activity clusters as CL-CRI-1089, CL-UNK-1090 and CL-UNK-1110.

The CL-UNK-1110 cluster is most commonly associated with the TamperedChef alias and includes campaigns distributing applications such as:

  • JustAskJacky
  • GoCookMate
  • RocketPDFPro
  • ManualReaderPro

Acronis has researched and reported on this cluster in detail. While this cluster remains active and significant, the primary focus of our analysis will be on the two other clusters, CL-CRI-1089 and CL-UNK-1090.

The CL-CRI-1089 cluster has been identified as active since early 2023. It includes several high-profile campaigns distributing applications such as:

  • Calendaromatic
  • DocuFlex
  • AppSuite PDF

These campaigns leverage a diverse set of deployment methods and show the most change when it comes to the malware’s techniques and tactics. This group leveraged infrastructure and code-signing certificates related to Ukrainian, Malaysian and British entities, which has remained consistent over the last two years of operation.

CL-UNK-1090 is unique in its clear evidence of vertical integration between marketing and malware creation. Similar to other clusters, the group behind this cluster distributes its malware via malicious advertisements (aka malvertisements).

A review of public records on corporate structures shows that, unlike the other groups, CL-UNK-1090 operators own both the code-signing companies and the ad agencies distributing the malware. This cluster used primarily Israeli infrastructure and code signing entities. It is responsible for several recent campaigns, including:

  • CrystalPDF
  • Easy2Convert
  • PDF-Ezy

Victimology

We have observed approximately 12,000 unique instances of this fake productivity software across our customer base. Our analysis shows that this threat is global with no significant geographic or sector targeting within the Managed Threat Hunting customer base.

The data highlights that while Israel and the U.S. see slightly higher targeting than other countries, TamperedChef-style malware is seen globally in non-negligible volumes.

This is consistent across all three clusters, indicating that they all appear to operate globally.

Tracking TamperedChef-Style Samples

Understanding the capability of these threats is crucial to detection, response and disruption. Fortunately, the malware operators have made several design decisions that we can leverage to identify and link large portions of their operations.

Tracking via Code-Signing Certificates, Code Reuse and Infrastructure Overlaps

One unique attribute of the TamperedChef-style malware is that almost all the first-stage binaries are signed with legitimate code-signing certificates. Attackers used code-signing to add stealth to these payloads. However, a lack of proper certificate hygiene allowed us to follow these samples further than any one campaign.

We initially identified code signing reuse with the Calendaromatic campaign. This campaign involved a simple Neutralinojs framework-based calendar app, contained in a 7z self-extracting archive (SFX). The calendar app would operate as expected, but it also contained a relatively basic RAT that enabled attackers to collect and install a second-stage payload.

This campaign gained some attention due to its novel use of homoglyphs to obfuscate the incoming command strings. The 7zSFX when extracted contains both a calendaromatic-win_x64.exe binary that is essentially just a wrapper for the real bulk of the code, a heavily obfuscated Neutralinojs resource file named resources.neu.

Public reporting highlighted that the 7zSFX file was signed by CROWN SKY LLC. Digging further through malware repositories, we identified four total files with the same core behavior of a 7zSFX file containing a calendaromatic-win_x64.exe binary and a resources.neu file. The resources.neu file varied across the samples. However, all appeared to contain similar functionality with differing C2 locations.

Of these four samples identified, we identified two unique signers. Samples one and two were signed by CROWN SKY LLC and sample three was signed by MARKET FUSION INNOVATIONS LLC. The final sample was found to not be signed and may not have been deployed widely.

Code-signing certificates are considered private material and not commonly shared between entities. A single code base signed by two uniquely authored certificates generally indicates that a single entity or actor is in possession of both code-signing certificates. This can occur for several reasons, including certificate theft, a single entity with ownership of two or more organisations (e.g., shell corporations) or organisations providing code signing as a service.

Reviewing sample repositories for evidence of this new signer, we found two additional campaigns that we identified as related to the Calendaromatic operators: PDFPrime and ManualzPDF. Both PDFPrime and ManualzPDF campaigns share striking similarities and likely share a codebase.

Similarities between the samples include:

  • The same C2 domain structures
  • Shared code signing dates
  • Shared embedded PDF editors

However, these samples are very distinct from the Calendaromatic campaign, sharing no code. This highlights attackers’ preference to abandon codebases upon discovery rather than iterate and evolve. Figure 2 below shows a simplified view of these certificate chains.

A diagram shows two orange boxes labeled "CROWN SKY LLC" and "MARKET FUSION INNOVATIONS LLC" on the left with arrows pointing to three other boxes labeled "Calendomatic.exe," "ManualzPDF.exe," and "PDFPrime.exe.
Figure 2. Simplified signature flow of reuse between samples.

The PDFPrime and ManualzPDF campaigns have several distinct variants, all with different code signers. Due to the high degree of code overlap, we clustered 34 samples to the PDFPrime/ManualzPDF codebase. We call these samples PixelCheck due to the C2 domains leveraging the format of pixel.toolname[.]com. They represent some of the earliest evidence of the Calendaromatic operator’s activity originating in late 2023.

Pivoting through sample repositories to identify other examples of the PixelCheck variant, seven additional signers were identified in the code of related malware:

  • ADVANTAGE WEB MARKETING LLC
  • Europae-Solutio Ltd
  • SP Development and Solution Limited
  • BUZZ BOOST ADVERTISERS LLC
  • ADSMARKETO LLC
  • LLC MATCH-TWO-USERS
  • Monetize forward LLC

Tracking these samples via code signing overlaps involves:

  • Identifying the code signers
  • Mapping their certificate chains
  • Pivoting to similar samples
  • Repeating the steps with newly identified signers

This iterative approach uncovered an extensive network of seemingly disparate samples, all linked to a single group through certificate ownership.

While effective, this discovery method relies on lax operational security. True certificate isolation would prevent expanded identification and limit certificate burning.

Reusing code signing across variants also does not appear to be a cost-saving measure, as multiple campaigns often use unique signers rather than reusing a small set of certificates. If cost minimization was the primary goal, we would not see these cases of individual certificate use.

Certificate reuse most commonly appears to be a result of poor testing practice, where attackers use previous certificates on early samples of a new campaign before they can procure a dedicated certificate.

At the current cost of code-signing certificates, burning more than two certificates per campaign carries heavy financial costs. As a result of this research, we attributed a total of 34 unique code-signing certificates related to the Calendaromatic campaign to the CL-CRI-1089 cluster.

Based on the current cost of code-signing certificates, this inefficient approach likely cost the operators over $10,000 in certificate expenses alone. This further highlights the scale of this operation, where this sum is likely considered a reasonable operational cost.

Tracking via Advertising

Much of the TamperedChef-style malware distribution is via ads, and as such it is subject to ad transparency. Ad transparency is a byproduct of regulation requiring players in the distribution of advertising to provide insights into ad content and owners. Many of the major platforms in the space have their own version of an ad transparency tool or dataset, and investigators can use these to map and track malvertising campaigns.

In most cases, ad transparency platforms enable searching either by the advertiser or the site being advertised. While the definition of an advertiser can be complicated, for the most part, the advertiser is the entity that sold or is selling an ad within the platform.

This means there is no guarantee that the malware operator and the ad seller are the same or related entities. However, it implies that the malware operator has interacted with the advertiser in some capacity (e.g., exchanging funds or ad details). Advertisers using these advertising marketplaces are held to certain standards by the platforms and must abide by the terms of service, which distribution of malware would typically breach.

TamperedChef-style campaigns are different from many other malvertising campaigns, as the malware creators and advertisers are generally vertically integrated. This vertical integration means advertisers also create the malware and, on occasion, sign the code. This direct link between code signers and advertisers implies a strong relationship between malware operators and distributors. This link can provide a starting point to map the wider network distributing this malware.

This is particularly evident with activity in CL-UNK-1090 being run by attackers that are clearly well versed in using ad marketplaces to distribute their malware. For CL-UNK-1090, we identified more than 20,000 unique ads deployed over several years via ad transparency platforms. This volume of ads is unlikely to originate from an individual. The OneZip campaign belonging to the CL-UNK-1090 cluster provides a real-world illustration of how tracking these clusters through advertising commonality and agencies works.

OneZip is a malicious compression tool with binaries signed by TAU CENTAURI LTD observed in the wild in early 2025. OneZip was distributed via the site onezipapp[.]com (Figure 3 shows the landing page).

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

By leveraging ad transparency platforms, we find that a single advertiser (CANDY TECH LTD) creates and distributes ads for onezipapp[.]com. Based on information from these platforms, CANDY TECH LTD has distributed approximately 4,000 ads that appear related to malicious productivity applications starting in June 2024.

Figure 4 below shows an example of the ads distributed. While not the most innovative, attackers have taken care with these ads to consider language, format, logo and branding. This indicates an actor well-versed in the AdTech space.

Screenshots of three adjacent banners promoting OneZip's file compression service in French, English, and German. Each banner has the OneZip logo and a download button featuring a zipped folder icon. The company name "Candy Tech Ltd" is displayed at the bottom of each banner.
Figure 4. Example OneZip ads run by CANDY TECH LTD.

Between June 2024 and December 2024, ad transparency platforms report that CANDY TECH LTD pushed ads for JustConvertFiles, a similar TamperedChef-style campaign. JustConvertFiles is a malicious file conversion tool similar in operation to all other TamperedChef-style samples.

JustConvertFiles binaries are signed by B.L.A ASPIRE LTD and PASTEL CONCEPTION LTD, and entities with these names are both observed reusing certificates. These entities appear to be responsible for several other campaigns, including:

  • PDFPilot
  • SwiftNav
  • ShinyPDF
  • FileEase

Based on advertising transparency data, we have not observed CANDY TECH LTD representing any campaigns other than TamperedChef-style malware.

CANDY TECH LTD is also observed in the malware creation stages, too. Several TamperedChef-style binaries are signed by CANDY TECH LTD or have other links to an entity with this name. These include:

  • ZipMakerPro
  • GifsMakerPro
  • ScreensRecorder
  • RapiDoc (contained a copyright stub with CANDY TECH LTD, but not signed)

We then performed the following activities to substantially flesh out CL-UNK-1090 and CL-CRI-1089, and to identify additional campaigns:

  • Leveraging known TamperedChef download URLs
  • Identifying the advertiser
  • Pivoting around the public information on these advertisers

These advertising pivots are not without limitations, and many malvertising actors do not have the expertise to set up the AdTech infrastructure, instead relying on established entities for distribution. This makes any sensible linking through public sources much more difficult, as most of the time, the malware advertising only accounts for a small percentage of the advertisers' overall ad presence. In these cases, other methods are likely to be more effective. However, when possible, investigating the distributor can provide more information.

Tracking via Co-location and Corporate Structures

The TamperedChef-style malware footprint is large and well-organised, with hundreds of campaigns and large sums of money invested. All TamperedChef certificates are validated by an organization, which means certificate authorities require a corporate entity to fulfill OV/EV requirements to be granted certificates.

Certificate issuers impose these validation requirements to aid in maintaining the reputation of signed code. There is a cost, of both money and time, for adversaries to establish a corporation for the sole purpose of signing code.

Corporate structures tend to leave traces, particularly in countries where data is publicly available. This opens new avenues for discovery.

OSINT sources such as private and government-run corporate search engines can be used to gain rapid insights into corporate entities. Our primary focus areas when tracking code-signing entities were:

  • Co-location, especially in residential dwellings
  • Companies with a handful of employees and minimal presence, especially when owned by much larger corporations, can indicate possible shell corporations
  • Shared ownership structures, particularly when shared ownership is by an individual and not a corporate entity
  • History of company renames (especially renames that are potentially aligned with malware campaigns)

With the CL-UNK-1090 cluster, we can use CANDY TECH LTD as an example again. Ad transparency data indicates that CANDY TECH LTD is registered in Israel. Leveraging Israeli company search engines, we found CANDY TECH LTD with a listed phone number, website, address and ownership structure.

Figure 5 below shows the webpage for CANDY TECH LTD.

Screenshot of Candy Tech webpage with a minimalist design. Illustration of a person sitting on abstract shapes using a laptop. Text reads "Powerful Utility Tools Made Simple." A button labeled "Learn More" is displayed below. The navigation menu includes "Home," "About," and "Contact."
Figure 5. CANDY TECH LTD webpage.

From public records, Zizik with me is the director of CANDY TECH LTD and Fairark Systems Ltd. consists of option holders for the company.

Zizik with me and Fairark Systems Ltd. are listed as having sole ownership stakes in several companies in Israel, such as:

  • AMARYLLIS SIGNAL LTD
  • TAU CENTAURI LTD
  • RED ROOT LTD
  • BITTERN SKY LTD
  • TOGO NETWORKS LTD

The list of companies that we mined from the Zizik with me and Fairark Systems Ltd. ownership structures — as well as some minor variations and co-location checks — match the names of companies that signed significant volumes of TamperedChef-style code. With high confidence, we believe these ownership structures link all cases to a single group.

Additionally, many of these companies have undergone several name changes in the past three years. Many of the old names match names that were used to sign TamperedChef-style malware.

Fairark Systems Ltd. is the registered name of FireArc, an Israeli advertising company. It states it creates games, connected TV applications, eCommerce solutions and, notably, utility applications. Figure 6 shows this statement on its website.

Screenshot of a webpage from FireArc featuring five sections: Gaming, CTV, ECommerce, Content, and Utility Apps. Each section has a brief description and a "Learn More" link. The top menu includes About, Business Units, Company, Careers, and Contact.
Figure 6. FireArc marketing pages stating they create utility applications.

Additionally, the RapiDoc campaign created by CANDY TECH LTD has a program database (PDB) (D:\!Work\Clients\<user>\Projects\RapiDoc\SrcForTests\RapiDoc\x64\Release\RapiDoc\RapiDoc.pdb). This could have been left by mistake in the RapiDoc binaries installed during execution.

PDBs are created during the build process for binaries and contain useful symbol and debug information. Binaries that are productionized tend to remove the PDB, as it can provide reverse engineers a head start when analyzing a binary, which is not desirable for either legitimate software or malware. PDBs, where applicable, were for the most part removed from other TamperedChef-style samples, indicating that this was likely an error.

The SHA256 hashes for the binaries containing the PDB are:

  • 248de1470771904462c91f146074e49b3d7416844ec143ade53f4ac0487fdb44
  • 2231bfa7c7bd4a8ff12568074f83de8e4ec95c226230cccc6616a1a4416de268

The Wide-Reaching Web of TamperedChef

Leveraging several linking methods, we broadly identified significant portions of these activity clusters’ operations, mapping several networks of TamperedChef-style malware. While this may not represent their entire infrastructure, it highlights the pervasive nature of this threat. We supply all identified samples, domains, signers and any other relevant details in the Indicators of Compromise section.

CL-CRI-1089

Using Calendaromatic as a starting point, we mapped out the CL-CRI-1089 cluster to include 34 unique code-signing entities. Our primary method of identification was code and certificate reuse. We observed some evidence of shared corporate addresses with code signers. However, generally, each entity was separately created and operated.

The CL-CRI-1089 cluster included malvertisements generated through self-created and likely dedicated companies. This cluster did not appear to cross-contaminate advertising entities with code-signing entities. This cluster primarily leveraged companies based out of Ukraine, Malaysia, Singapore, the U.S. and the UK to perform operations. In cases where the owner's place of birth was recorded by the UK government, all owners were of Ukrainian origin.

We identified over 3,300 samples related to CL-CRI-1089 across Palo Alto Networks and public sample databases, with the vast majority related to productivity software.

CL-UNK-1090

We mapped out CL-UNK-1090 primarily through a combination of real-world incidents, OSINT on the FireArc corporate structures and advertising network links. Certificate and code reuse were present but formed less of a basis for discovery.

We found CL-UNK-1090 used 39 Israeli corporations for certificate generation. This cluster included changed organization names to mine these structures for multiple certificates, so the real number of organizations is likely less than 39. We identified approximately 750 samples related to CL-UNK-1090, all with productivity application themes.

Malvertising as a Service: How Did the Threat Scale?

The scale of TamperedChef-style malware is immense. We found evidence of the two tracked clusters (CL-CRI-1089 and CL-UNK-1090) across more than 50% of Managed Threat Hunting customers. If this number is an accurate representation of the wider community, it shows an operation on a scale rarely observed.

The distribution and scale of these campaigns come with high monetary and labor costs. TamperedChef-style actors are likely to have bought much of their success. They have positioned themselves less as malware experts than as advertising and logistics specialists.

Buying Legitimacy: Purchasing Code-Signing Certificates

Code signing as a practice provides authenticity and integrity validation to binaries, but it can be misused by malicious actors. Purchasing code-signing certificates offers a marginal increase in binary trustworthiness. However, they come with strict identity validation and cost, which can deter many malware developers.

These requirements did not impede any of the TamperedChef actors, and one of their key strengths comes from a deep understanding of the business side of advertising. The development of several shell companies appeared minimally impactful and provided a reusable pool of code-signing certificates. In the case of CL-UNK-1090, it appeared that renaming existing companies was enough to be granted new, valid certificates, further lowering the barrier for entry.

In recent months, we’ve identified a trend of these clusters moving away from code signing. This shift could be occurring because these binaries are becoming better understood and researched. The damage done by identifying an entire campaign through tracking code signers may now outweigh the benefits gained through signing binaries.

Buying Speed: The Influence of Distributed Development and AI

The rate and scale at which the TamperedChef-style actors deploy new campaigns is incredibly fast. Attackers run tens of campaigns simultaneously, with new ones being developed constantly.

The CL-CRI-1089 cluster, in particular, demonstrates a high degree of variation. Each campaign features an entirely new set of TTPs, delivery methods, languages, functionality and C2 structures. This suggests a new codebase for each campaign, and potentially even different developers.

The code quality also shows a lack of mature development practices and teams likely inexperienced with malware development. This does somewhat work in favor of TamperedChef binaries, as upon first glance, the C2 methods are not always obvious.

In the case of CL-CRI-1089, the codebases are highly variant. However, they share common certificates, demonstrating limited code reuse between campaigns. This may indicate they were created by several development teams or that generative AI was at least partially responsible for the set of campaigns.

Distribution infrastructure setup appears to be largely driven using generative AI. This is particularly evident with the distribution websites where the content of pages for different campaigns appears visually similar. However, they have distinct Document Object Model (DOM) structures. This is indicative of a non-deterministic development practice, which is characteristic of content generated by large language models (LLMs).

Buying Visibility: Hijacking the Advertising Pipeline and Search Engine Optimization (SEO)

TamperedChef-style samples for all clusters are distributed primarily through malvertisements, sponsored results and search engine marketing techniques. Our telemetry for real-world infection chains commonly shows victims browsing terms like “free calendar prints” or “document formatting” before being served the malvertisements.

TamperedChef-style malware establishes a distribution-first approach. Getting installed by the masses is far more important to the operators than managing persistent and reliable C2.

Technical Analysis of TamperedChef Malware Samples

Operational Commonalities Across All Samples

While none of the identified TamperedChef malware samples are technically complex, they vary significantly between campaigns. All samples tend to share a common set of TTPs and second-stage payloads, which only serves to further highlight the motivations and risks these TamperedChef-style malware samples pose.

These universal TTPs include:

  • Leveraging code signing for the first-stage payloads
  • Implementing a robust persistence mechanism, almost always through scheduled tasks or registry Run keys
  • Initial information gathering and exfiltration typically occurring on install
    • This usually involves simple data collection, like system version, hostname and active browsers.
    • However, we have seen more targeted information gathered, including patch levels, user details, domain information, geolocation and screen size.
  • Employing a delayed activation technique to evade detection
    • Initially, the samples mimic legitimate applications, remaining dormant for days or even weeks.
    • Upon activation, they trigger the next stage, which typically involves downloading and executing an additional payload delivered via an upstream API.
  • Obfuscating the malicious components
    • This is the clearest evidence to suggest that these binaries are not just simple adware.
    • Most of the campaigns we observed used some form of obfuscation or defense evasion techniques for their loader or stealer components.
    • While obfuscation is used for intellectual property (IP) protection, in this case, the routines were primarily for de-obfuscating incoming payloads within the loader components.
    • Since no other parts of the binaries were obfuscated, IP protection was likely not the main reason for these methods.

Delivering Second Stage Malware

TamperedChef-style malware, when activated, can deliver arbitrary payloads, but in practice sticks to two primary categories: adware and browser hijackers or RATs and stealer malware. Which payload it delivers depends on the campaign specifics. TamperedChef rarely deploys both simultaneously.

Adware and Browser Hijacking

The primary objective of the majority of the TamperedChef-style binaries is to distribute ads or gain some form of control over the user’s browser. This has been achieved via either:

  • Installing a new adversary-controlled default search engine in the user’s primary browser
  • Installing an entirely new adversary-controlled browser (e.g., OneBrowser)

Both these methods enable adversaries to control the content searched, ads displayed to victims and, in the case of the browser installation, full control over user cookies and credentials.

Stealers and RATs

While adware can be disruptive and undesirable, it does not generally pose a major organizational risk. TamperedChef-style binaries, on the other hand, display a level of stealth, defense evasion and persistence that is unusual and excessive for adware.

This likely further indicates that the true threat of the TamperedChef-style malware goes beyond adware and into more insidious use cases. This is backed by real-world cases where attackers have consistently deployed active C2 and stealer-style malware as second stages targeting victims’ browser credentials or for information gathering.

These second-stage stealers range in capability, targets and formats but are almost always deployed after a dormancy period of weeks. Evidence of more exotic payloads has been observed too, but far less frequently and not en masse. An example of this was the AppSuite campaign that saw the sporadic installation of proxy-style malware.

Distilling the Motivations

Our analysis shows that CL-CRI-1089 activity focuses on criminal-style activity targeting credentials, deploying adware and in some cases proxy-style payloads. Based on sample and corporate analysis, the operators of CL-CRI-1089 are globally distributed but centrally operated.

In contrast, the motivations behind CL-UNK-1090 activity are far less clear. This activity appears to be solely managed by a much smaller group of entities related, at least in part, to a seemingly successful advertising agency.

These samples are all designed to look like adware. However, the samples do not operate like adware, housing RATs with .NET loader-style capabilities that legitimate adware or productivity software do not require.

In real world cases, we have not observed the same volume of malicious second stage deployments from samples tracked as CL-UNK-1090 as we have with the CL-CRI-1089 samples. However, second stages deployed by CL-UNK-1090 are more stealthy, existing primarily in memory and include RAT deployments, browser hijackers and adware.

Detection, Prevention and Response to Future Threats

Preventive Recommendations

Some key preventive steps to combat this threat are:

  • Education: Ensure users are aware of this style of threat and know that even legitimate looking software can carry risks
  • Endpoint/extended detection and response (EDR/XDR): Ensure updated EDRs/XDRs are in place on all hosts within an environment
  • Enterprise browsers: Enterprise browsers can help protect against this threat and ensure that in the event of compromise, saved credentials remain secure
  • Device hardening: Consider hardening user endpoints to prevent the installation of software from untrusted sources

Detection and Response

Due to the prevalence of these threats, continuous active monitoring and hunting can have a very high return on investments however due to the varied nature of these threats hunting queries vary in effectiveness.

If these threats are identified, our general remediation advice is to:

  • Remove and/or quarantine all files associated with the malicious software
    • These are generally located in the installation folder
  • Ensure that persistence mechanisms such as the created scheduled tasks are removed to prevent reinfection
    • Consider running a full malware scan of the host as it may identify any second-stage components
  • Consider revoking active tokens for the impacted users and resetting their credentials
    • It is likely that any browser-based credentials are potentially compromised
  • Review access logs to ensure that the impacted users' credentials are not actively being misused

Conclusion

TamperedChef-style campaigns are likely to continue to misuse advertising pipelines to deliver malware, developing and adapting new lures and evasion methods. The prevalence of the CL-CRI-1089, CL-UNK-1090 and CL-UNK-1100 clusters will likely serve as a blueprint for future malvertising campaigns.

New trends, such as moving away from using code signing, will require new tracking methods to be developed to remain ahead of these actors' operations.

Palo Alto Networks Protection and Mitigation

Palo Alto Networks customers are better protected from the threats discussed above through the following products:

Cortex XDR and XSIAM help to prevent the threats described in this blog, by employing the Malware Prevention Engine. This approach combines several layers of protection, including Advanced WildFire, Behavioral Threat Protection and the Local Analysis module, designed to prevent both known and unknown malware from causing harm to endpoints.

Prisma Browser helps to prevent access to known malicious campaigns using Advanced URL Filtering, Advanced Web Protection (Live Page Scanning) which runs AI models within the browser to detect and block attack patterns, file download scanning and protection on the default search engine.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 000 800 050 45107

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

Table 1 lists the signers’ organization noted in code-signing certificates used in the TamperedChef-Style malware samples we found in our research.

Signer Related Cluster
CANDY TECH LTD CL-UNK-1090
G.R.CIGAR. LTD CL-UNK-1090
TAU CENTAURI LTD CL-UNK-1090
AMARYLLIS SIGNAL LTD CL-UNK-1090
METROPOLITAN DESIGN LLC CL-UNK-1090
BLACK INDIGO LTD CL-UNK-1090
Red Root LTD CL-UNK-1090
A1A Marketing Ltd. CL-UNK-1090
GOLD HARMONY LTD CL-UNK-1090
BEGONIA LIFE LTD CL-UNK-1090
SAMBUSAK LLC CL-UNK-1090
ACTIVE INTELLECT AI LLC CL-UNK-1090
VAST LAKE LTD CL-UNK-1090
LONG SOUND LTD CL-UNK-1090
B.L.A ASPIRE LTD CL-UNK-1090
VANILLA FORCE LTD CL-UNK-1090
SELA LINES LTD CL-UNK-1090
WIND TRUST LTD CL-UNK-1090
BLUE TAKIN LTD CL-UNK-1090
ORCHID MARS LTD CL-UNK-1090
ENIGMATIC SAOLA LTD CL-UNK-1090
TROPICAL RIFF LTD CL-UNK-1090
BITTERN SKY LTD CL-UNK-1090
astro bright ltd CL-UNK-1090
my tech media ltd CL-UNK-1090
LIGHTNER TOK LTD CL-UNK-1090
TOGO NETWORKS LTD CL-UNK-1090
CHRONO ORION LTD CL-UNK-1090
LOGOS AQUA LTD CL-UNK-1090
Impresan Solutions OÜ CL-UNK-1090
Shopcut LLC CL-UNK-1090
Judy Wanjiru CL-UNK-1090
Keen Internet Technologies Ltd CL-UNK-1090
ROYAL STEP LTD CL-UNK-1090
Smart Contract LLC CL-UNK-1090
DORNOVI LTD CL-UNK-1090
Green Topaz Ltd CL-UNK-1090
LOGOS AQUA LTD CL-UNK-1090
SPARROW TIDE LTD CL-UNK-1090
mania tech ltd CL-UNK-1090
PASTEL CONCEPTION LTD CL-UNK-1090
Mainstay Crypto LLC OneBrowser Signers
Crowd Sync LLC OneBrowser Signers
WORK PRODUCT, INC. OneBrowser Signers
Chickadee Digital OneBrowser Signers
Riya Software OneBrowser Signers
Eman Group, LLC OneBrowser Signers
MATCH-TWO-USERS LLC CL-CRI-1089
TWEAKSCODE LLC CL-CRI-1089
AFFILIDADOS CL-CRI-1089
MARKET FUSION INNOVATIONS LLC CL-CRI-1089
BUZZ BOOST ADVERTISERS LLC CL-CRI-1089
ADSMARKETO LLC CL-CRI-1089
CROWN SKY LLC CL-CRI-1089
Summit Nexus Holdings LLC CL-CRI-1089
Europae-Solutio Ltd CL-CRI-1089
SP Development and Solution Limited CL-CRI-1089
Echo Infini SDN BHD CL-CRI-1089
COMMERCE GROUP TECHNOLOGY LTD CL-CRI-1089
ALGORYTHM TECH LTD CL-CRI-1089
Byte Media Sdn Bhd CL-CRI-1089
GLINT SOFTWARE SDN. BHD CL-CRI-1089
Global Tech Allies ltd CL-CRI-1089
SOFT SOLUTIONS HUB CL-CRI-1089
Monetize forward LLC CL-CRI-1089
ADVANTAGE WEB MARKETING LLC CL-CRI-1089
Incredimarket CL-CRI-1089
ILLUSION MEDIA SOLUTIONS CL-CRI-1089
Virtual Media App Ltd CL-CRI-1089
DEV SPOTS LLC CL-CRI-1089
Digit Consult CL-CRI-1089
Outsource Genius LLC CL-CRI-1089
OneStart Technologies LLC CL-CRI-1089
Apollo Technologies Inc CL-CRI-1089
Caerus Media LLC CL-CRI-1089
Digital Promotions Sdn. Bhd. CL-CRI-1089
Eclipse Media Inc. CL-CRI-1089
Astral Media Inc CL-CRI-1089
Incredible Media Inc CL-CRI-1089
STYLE SOLUTION LIMITED CL-CRI-1089

Table 1. Signers of code-signing certificates from the TamperedChef-style malware samples.

Additional Resources

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

Posted on by Mark Lim

Executive Summary

This article examines new obfuscation techniques the Gremlin stealer malware uses to conceal malicious payloads within embedded resources. We analyze a variant protected by a sophisticated commercial packing utility that employs instruction virtualization, transforming the original code into a custom, non-standard bytecode executed by a private virtual machine.

Gremlin stealer siphons sensitive information from compromised systems and exfiltrates it to attacker‑controlled servers for potential publication or sale. It targets web browsers, system clipboard and local storage to exfiltrate sensitive information like:

  • Payment card details
  • Browser cookies
  • Session tokens
  • Cryptocurrency wallet data
  • FTP and VPN credentials

This threat has rapidly evolved, incorporating new anti-analysis safeguards into recent builds.

Palo Alto Networks customers are better protected from Gremlin Stealer through our Network Security solutions and Cortex line of products, including:

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

Related Unit 42 Topics Infostealer, Telegram, Cryptocurrency

New Gremlin Site for Publishing Data

Using data from our internal threat intelligence, we identified a new Gremlin stealer variant. This variant exfiltrates stolen data to a newly deployed site at hxxp[:]194.87.92[.]109 as shown in Figure 1.

Screenshot of a computer screen displaying a login interface for "GREMLIN" on a dark background. It includes input fields for username and password, with a prominent green "Login" button.
Figure 1. New Gremlin site.

At the time of discovery, VirusTotal showed zero detection for this new Gremlin site hxxp[:]194.87.92[.]109, its associated URLs or any retrieved artifacts. There were no block list entries, community reports or malicious categorizations as shown in Figure 2.

Screenshot of a VirusTotal webpage analyzing a URL. The analysis shows 0 out of 71 security vendors flagged the URL as malicious. Status is 200 with the content type listed. Tabs for details, relations, content, telemetry, and community are visible.
Figure 2. Gremlin Stealer’s new site detection on VirusTotal.

After data theft, the malware bundles harvested artifacts into a ZIP archive, including:

  • Browser cookies
  • Session tokens
  • Clipboard contents
  • Cryptocurrency wallet data
  • FTP and VPN credentials

The malware names the file using the victim’s public IP address to identify the source, and then uploads it to the attacker-controlled site, as shown in Figure 3.

Screenshot of a dashboard interface of the "Gremlin" application displaying statistics such as the number of online devices (11), data usage (0.83 MB), and uptime (12:40:52). The interface includes sections with buttons labeled in Russian for each device, showing options to "Online" and "Delete.
Figure 3. Gremlin site published data.

Technical Analysis

In this section, we present a comparative analysis of older and newer Gremlin stealer variants, highlighting the key changes and describing our process for extracting the final-stage payloads.

Hiding Payload in Resource

The latest iteration of the Gremlin stealer has an increased focus on stealth, specifically designed to evade static analysis tools. In this version, the malware authors have shifted the malicious payload into the .NET Resource section, masking it with XOR encoding to bypass signature-based detection and heuristic scanning.

Figure 4 shows how the resource section appears as an opaque block of data, hiding strings and API calls that would otherwise trigger alerts.

Screenshot of a hex editor displaying hexadecimal code on the right pane and a directory tree on the left, including folders like "Version Info" and "Configuration Files." The displayed code includes both hexadecimal and ASCII representations.
Figure 4. Resource section.

By applying a single-byte XOR decryption routine, we recovered the plain-text configuration. Figure 5 shows that this reveals the hard-coded command-and-control (C2) URLs and exfiltration paths.

Screenshot of a text document showing a process for XOR decryption and URL extraction. The text notes successful URL findings with keys 20, 31, and 49. The process concludes with a message stating "Decryption and URL extraction complete".
Figure 5. XOR decryption on resource section.

Gremlin stealer uses the resource section to mirror the tactics of several high-profile malware families that frequently use this area for payload obfuscation, including:

Comparison with Older Version

Comparing past and present versions reveals a clear evolution in Gremlin stealer’s anti-analysis techniques. Legacy samples (shown in Figure 6) lacked obfuscation, leaving function exports and internal symbols intact.

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

The current iteration implements a staged loading mechanism. Each critical function is decrypted and mapped into memory from the .NET resource section only when needed. This method forces analysts to perform dynamic debugging to observe any meaningful program behavior.

Key Enhancements in the Latest Variant

Gremlin stealer’s evolution from a basic credential harvester to a modular toolkit is evident in several key architectural upgrades:

  • Expanded target scope: Gremlin stealer includes a dedicated Discord token extraction module, which signifies a pivot toward targeting digital identity and social engineering.
  • Active financial fraud: The latest variant shifts from passive data theft to active financial interference. This crypto clipper functionality continuously monitors the system clipboard for strings matching cryptocurrency wallet patterns. When it detects a match, the malware replaces the victim's address with the attacker’s wallet in real time, diverting funds during transactions.
  • Advanced persistence: The WebSocket-based session hijacking module represents its most significant technical upgrade. This allows Gremlin stealer to hijack active, live browser sessions and bypass modern cookie protections by requesting the data directly from the running browser process.

Sample Packed Using a Complex Commercial Packing Utility

We uncovered an iteration of Gremlin stealer (SHA256 2172dae9a5a695e00e0e4609e7db0207d8566d225f7e815fada246ae995c0f9b) packed using a packing utility, as shown in Figure 7 below.

Screenshot of Exeinfo PE software window displaying file information. The header shows version 0.0.9.0 by A.S.L. The main section includes details about a file named '217.exe', such as entry point, file offset, and subsystem. A section below highlights "(PACKED mode)". Various buttons and icons are visible on the right
Figure 7. Packed Gremlin variant.

Let’s discuss the obfuscation and anti-analysis techniques this variant uses.

Code Obfuscation and Anti Analysis

Identifier Renaming (The “No-Labels” Technique)

Imagine trying to cook in a kitchen where every can, box and spice jar has its label replaced with a random, short name like a, b, c, hf or ze. The malware authors applied this technique to the variant’s code.

  • What it is: They replaced every meaningful name for a class, method or variable with a meaningless one.
  • Why it's effective: It removes all context. A method originally named StealPasswordsFromChrome might become a(). A variable named decryptionKey might become b. This forces an analyst to manually trace every single function call to figure out its purpose, which is incredibly time-consuming.
  • Example: In the file hf.cs, the main orchestrator class is named hf, and its primary methods are a, b and c. In bb.cs, the class for stealing browser data is BrowserCredentialStealer, but in the original obfuscated code, it was just bb.
String Encryption (The “Secret Decoder Ring” Technique)

In this technique, malware authors made readable strings appear as gibberish. Instead of writing a word like password or a URL like hxxps://api[.]telegram[.]org directly in the code, the malware stores them encrypted.

  • What it is: All important strings are hidden. The code only contains numbers that act as a key to a secret decoder function. When the program needs a string, it passes these numbers to the decoder, which then returns the real string.
  • The decoder ring function: The secret decoder is the method _003CModule_003E.c(int, int, int).
    • It takes three integers as input
    • It uses these numbers to calculate an offset and a length
    • It opens an embedded resource file (named resource in the .csproj file) which contains all the encrypted strings
    • It seeks the calculated offset, reads the specified number of encrypted bytes and uses the third integer as a key to decrypt them
    • It returns the final, readable string
  • Why it's effective: It completely hides the malware's intentions from static analysis. Analysts cannot simply search the code for suspicious keywords like Telegram, wallet.dat or api.ipify[.]org because they don't exist in plain text. Instead, analysts must either run the program in a debugger to see what strings are produced or reverse-engineer the decoder function.
  • Example: A line like this from the original code:

csharp

// This is what the obfuscated code looks like

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

When executed, the c() function would run its decoding operation, and the URL variable would then contain: csharp

// This is the real value at runtime

string url = "http://api.ipify.org/?format=json";

Control-Flow Obfuscation (The “Maze of Useless Roads” Technique)

This technique makes the code's logic intentionally confusing, like turning a straight road into a maze of dead ends and pointless loops that all eventually lead to the same place.

  • What it is: The decompiler output is filled with complex and nonsensical if-else statements, goto jumps and mathematical operations that don't actually affect the outcome. These are designed to confuse both human analysts and automated analysis tools.
  • Why it's effective: It breaks the logical flow that a person would expect to see. It makes it hard to determine which path the code will actually take, even though in many cases, there's only one real path. This significantly increases the time and effort required for reverse engineering.
  • Example: There are many switch statements and goto labels (e.g., IL_00c8, IL_0138) that create a tangled web of execution, even though the underlying logic is a simple sequence of await Task.Run(...).

Conclusion

While the core architecture and exfiltration methods via private web panels or the Telegram Bot API remain consistent, this latest variant of Gremlin stealer represents an evolution into a more complex threat. By transitioning from a simple data exfiltration tool to a more advanced modular stealer, Gremlin now targets Chromium-based browsers. It uses memory-resident techniques to hijack active session tokens and sensitive data directly from running processes, rather than relying solely on static database files.

This threat’s scope has broadened, as evidenced by a dedicated Discord token stealer. This module scans multiple paths and uses regex validation to compromise modern communication platforms.

The malware’s author has also added a clipboard hijacker. This new monetization feature enables persistent financial fraud. It continuously monitors the clipboard, replacing cryptocurrency wallet addresses with attacker-controlled ones.

Palo Alto Networks Protection and Mitigation

Palo Alto Networks customers are better protected from the threats discussed above through the following products:

  • The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the IoCs shared in this research.
  • Advanced URL Filtering and Advanced DNS Security identify known domains and URLs associated with this activity as malicious.
  • Advanced Threat Prevention has an inbuilt machine learning-based detection that can detect exploits in real time.
  • Cortex XDR and XSIAM are designed to:
    • Prevent the execution of known malicious malware, and also prevent the execution of unknown malware using Behavioral Threat Protection and machine learning based on the Local Analysis module.
    • Protect against credential gathering tools and techniques using the new Credential Gathering Protection available from Cortex XDR 3.4.
    • Detect post-exploit activity, including credential-based attacks, with behavioral analytics, through Cortex XDR Pro.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

  • North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
  • UK: +44.20.3743.3660
  • Europe and Middle East: +31.20.299.3130
  • Asia: +65.6983.8730
  • Japan: +81.50.1790.0200
  • Australia: +61.2.4062.7950
  • India: 00080005045107

Indicators of Compromise

SHA256 hashes of the Gremlin stealer samples analyzed for this article:

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

URLs

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

Additional Resources

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

Default Heading

Read the article Right Arrow