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: 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

HTTP header parameters sent by the implant to the server

Checking for the presence of the CyberStrikeAI agent on the system

Delivery and execution of the CyberStrikeAI agent

Identical build metadata for the Windows and Linux implant samples, indicating a shared build environment

Differences in CyberStrikeAI versions on the command-and-control servers

Alert regarding the detection of CyberStrikeAI communication with a C2 server

NDR:NAD alert: reconnaissance via LDAP queries detected

Visualization via the Research Graph on the Kaspersky Threat Intelligence Portal

Demonstration of attributing a malicious implant to the CyberStrikeAI framework

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