Google Warns of LLMJacking as Attackers Resell Compromised Cloud AI Access

Google Threat Intelligence Group (GTIG) has detailed a growing cybercrime operation in which threat actors compromise enterprise access to large language models (LLMs), use victims' cloud resources to run AI workloads, and resell unauthorized model access through underground services.

The activity, known as LLMJacking, has affected organizations across North America, South America, and Asia Pacific, spanning financial services, retail, technology, and transportation.

In a report published on November 3, 2026, Google Threat Intelligence Group and Mandiant describe how financially motivated threat actors are targeting exposed LLM endpoints, stealing cloud identity credentials, compromising API keys, and exploiting model-routing infrastructure to gain control of enterprise AI resources.

The financial impact can be substantial. Across individual investigations, Google observed fraudulent resource-consumption charges exceeding $100,000 in a single day. At some organizations, cumulative charges reached $1 million before access was revoked.

The report also identifies an emerging underground business model involving LLM Mixers, illicit routing gateways that aggregate unauthorized model access and resell it to subscribers.

What Is LLMJacking?

LLMJacking is the unauthorized use of an organization's cloud-based LLM resources by threat actors who gain access to its model infrastructure or credentials.

Unlike traditional cryptojacking, where attackers consume computing resources to mine cryptocurrency, LLMJacking focuses on exploiting access to commercial AI models and related cloud infrastructure.

Attackers can use stolen API keys, compromised cloud identities, or exposed model endpoints to run their own inference requests using the victim's resources.

The resulting activity can generate significant cloud bills in a short period. Rather than gradually consuming computing capacity, attackers can generate large volumes of model requests and pass the associated costs to the compromised organization.

Google's investigations also reveal that some threat actors go beyond direct resource theft. They establish proxy infrastructure, aggregate compromised credentials, and sell access to AI models through underground marketplaces.

This creates a criminal ecosystem in which one group may obtain initial access while another manages the infrastructure used to monetize compromised LLM resources.

How Attackers Gain Initial Access to Enterprise AI Resources

Google identifies exposed or stolen cloud identity tokens as the dominant initial access vector across its LLMJacking investigations. These included IAM credentials, Service Account keys, GitHub Personal Access Tokens (PATs), and active session tokens.

Threat actors also targeted publicly exposed LLM endpoints and harvested LLM API keys. These represent additional routes through which attackers could obtain access to enterprise AI resources.

Exploiting Publicly Exposed LLM Endpoints

Some attackers search for publicly exposed model services rather than interacting with customer-facing AI chatbots.

Google describes an example involving publicly accessible Ollama endpoints. A threat actor used an automated script to test exposure by calling the /api/create endpoint and attempting to register their own models.

This approach allows attackers to use exposed model infrastructure directly, potentially increasing hosting costs for organizations that have left services accessible without sufficient protection.

The report distinguishes this backend targeting from earlier resource theft involving manipulation of customer support chatbots to perform unauthorized tasks such as code generation.

Stealing Cloud Identity Credentials and API Keys

Google describes several intrusion examples illustrating how cloud credentials and API keys were abused.

In mid-2026, the threat cluster UNC6993 compromised a cloud instance through a misconfigured Service Account key and used the access to obtain further permissions for an LLM API.

The group also hosted a session-hijacking page disguised as an application portal for LLM users. Victims were directed to the legitimate LLM service and tricked into pasting a raw JSON payload containing an active access token. The token was then sent to the attacker's backend, allowing the attackers to use the captured session to access the victim's account without relying on the normal password and multifactor authentication process.

In another investigation, a threat actor combined a stolen GitHub PAT, which provided access to private code repositories, with the suspected exploitation of a web application vulnerability in a package running inside a containerized cloud environment.

Other incidents involved compromised corporate IAM credentials and cloud federation tokens. Attackers used these credentials to programmatically generate fresh access keys and circumvent MFA requirements.

Google also observed opportunistic harvesting of corporate LLM API keys from public GitHub repositories.

To validate stolen keys, one group performed automated credential checks using minimal single-token requests with max_tokens=1. These small requests helped confirm whether credentials were usable while avoiding the volume anomalies that might otherwise trigger endpoint detection and response (EDR) or security information and event management (SIEM) alerts.

Lateral Movement and Persistence: Expanding Control Across Cloud Environments

After gaining initial access, threat actors attempt to expand their privileges, identify additional resources, and maintain access to compromised environments.

Google observed attackers conducting reconnaissance across cloud services, code repositories, databases, and storage systems.

The activity was not limited to finding additional LLM credentials. Attackers also searched for infrastructure secrets and access paths that could provide broader control over enterprise environments.

Repository and Cloud Infrastructure Reconnaissance

In one investigation, a threat actor examined multiple cloud regions to map available services and identity policies.

In another incident involving a containerized cloud environment, the attacker performed extensive repository reconnaissance. They cloned sensitive codebases and searched for hardcoded secrets, configuration variables, and developer credentials.

The attacker also reviewed access logs to identify credentials associated with secondary cloud environments.

Google observed database queries used to search cloud data warehouse metadata for database credentials, administrator passwords, and sensitive columns. The activity also included cloud object storage operations associated with targeted data theft.

These actions show how an initial compromise involving AI resources can lead to wider enterprise infrastructure exposure.

Privilege Escalation and Unauthorized Persistence

Threat actors also abused cloud identity permissions and virtual machine configurations to maintain access.

In one incident, an attacker used service accounts associated with compromised workloads and exploited token-creation permissions to generate temporary credentials for high-privilege service accounts.

This activity resulted in the exfiltration of infrastructure credentials, internal database passwords, and third-party API keys from cloud secret managers.

Other observed persistence methods included:

• Creating unauthorized IAM accounts and Service Accounts.

• Attaching administrative policies to service roles.

• Establishing interactive management sessions with running virtual machines.

• Injecting unauthorized SSH public keys into host configuration files.

• Adding environment-wide SSH keys to compute instance metadata.

One threat actor created deceptive backdoor Service Accounts disguised as internal billing optimization utilities.

These techniques allowed attackers to establish access that could remain available beyond the initial credential compromise.

LiteLLM Vulnerability Enabled Privilege Escalation

Google also observed attackers exploiting vulnerabilities in LLM routing software to expand their control over compromised environments.

In one investigation, a follow-on threat cluster received pre-validated Virtual Keys from the group responsible for initial access.

The attackers then exploited a user ID rebind vulnerability in LiteLLM's /key/regenerate endpoint, identified as CVE-2026-40217.

According to Google, the vulnerability allowed the attackers to elevate standard Virtual Keys into full PROXY_ADMIN master administrative credentials.

This provided deeper control over the compromised LiteLLM environment and supported persistent access.

The incident illustrates that LLM security extends beyond cloud identity management and API key protection. Model gateways and routing middleware can also become critical points of compromise.

Organizations using such software should include it in their vulnerability management and patching processes.

LLM Abuse: Turning Compromised AI Resources into Revenue

The ultimate objective of LLMJacking is to monetize unauthorized access to foundation models and cloud resources.

Google observed several approaches, including direct model usage, API proxying, automated model streaming, and GPU infrastructure provisioning.

Enabling AI Services and Generating Fraudulent Charges

After obtaining cloud access, threat actors frequently enabled generative AI services and created additional API keys to expand their operations.

In one incident, UNC6993 attempted to generate additional API keys and enable associated services within victim cloud projects. The activity quickly accumulated more than $100,000 in billing charges.

Another threat actor subscribed compromised accounts to Pay-As-You-Go agreements, selected premium foundation models, and launched high-volume inference streams.

To work around rate limits, the actor used a strategy described as "burn and rotate". This involved repeatedly creating and deleting short-lived Service Accounts while monitoring the cloud provider's billing interface to track the financial impact.

Deploying Proxies, Agents, and GPU Infrastructure

Some attackers also used compromised environments to host their own proxy endpoints and agentic workloads.

Google describes a threat actor that enabled agents, deployed publicly accessible reverse proxies, and used custom Node.js proxy bundles to expose endpoints compatible with multiple frontier LLMs.

These services were rebranded under a persona known as D1337-KAIROS.

The actor also deployed a containerized backdoor using the Manus agent framework. The workload queried an upstream LLM to reason through instructions and execute resulting commands locally.

The environment included SearXNG metasearch and agent-infra/sandbox execution environments.

To increase available compute capacity, the attacker provisioned GPU-powered compute instances, attempted to launch high-end hardware across multiple regions, and requested quota increases through the cloud provider's API.

The actor also hosted LiteLLM gateways on external servers to manage and route API traffic.

These observations demonstrate that compromised cloud environments can be used for more than unauthorized inference requests. They can also support proxy infrastructure, automated workloads, and additional compute operations.

LLM Mixers: The Underground Market for Stolen AI Access

One of the most significant findings in the report is the growing division of labor between threat actors who compromise enterprise environments and operators who monetize the resulting AI access.

Google refers to the downstream services as LLM Mixers.

These services operate as illicit routing gateways that proxy, aggregate, and resell unauthorized LLM access to underground subscribers.

They can combine stolen credentials from multiple accounts, route API requests through different resources, measure usage, and make it harder to identify the source of the requests.

How Threat Actors Aggregate and Resell Compromised Credentials

Google observed UNC6993 using open-source tools including:

• new-api: A centralized model hub and API gateway.

• gcli2api: An API proxy tool that converts command-line interface tools into standard frontier model endpoints.

The tools were likely used to aggregate stolen API keys and balance request loads across multiple accounts.

Google assesses that the threat actor sells access to these tools through underground storefronts.

This creates a resale model in which the victim organization pays for the model usage while underground customers receive access to the compromised resources.

Jet Night: More Than 500,000 API Calls in Less Than Eight Hours

Another investigation involved a threat actor that executed more than 500,000 LLM API calls in less than eight hours.

The actor used stolen third-party API keys to power a token-routing service called Jet Night, hosted at jet-night.com.

Google reports that Jet Night passed nearly $1 million in token costs to the victim organization.

The service advertised an unlimited token plan for approximately $60 per month, claiming access to frontier models.

GTIG assessed that the advertised pricing was unusually low compared with the estimated cost of providing a comparable consumer service. It estimated that this level of service would typically cost between $100 and $250 per month.

Based on the pricing and other observations, Google believes Jet Night relies on stolen API keys to operate profitably.

The service also advertised multiple outages through its public Telegram channel. Google assessed that these outages were likely associated with stolen credentials being revoked as victims discovered the compromises.

Custom Relay Infrastructure and the NewAPI Resale Ecosystem

Google also identified a threat actor operating custom proxy relay infrastructure called ai-relay.

The infrastructure was hosted on deceptive lookalike domains. In one example, the attacker registered a domain designed to resemble the victim's legitimate internal host.

The relay infrastructure was used to redirect commercial LLM access into the illicit newapi[.]pro resale ecosystem.

This allowed underground customers to use AI resources while the associated API consumption was charged to the compromised organization's corporate account.

Google Expects LLMJacking Activity to Increase

GTIG expects threat actors to increasingly prioritize LLMJacking over traditional resource theft such as cryptojacking.

The assessment is based on the immediate monetization opportunities created by underground LLM Mixers.

Google expects attackers to refine automated reconnaissance targeting exposed API tokens and vulnerabilities in model-routing middleware as enterprises adopt higher-tier AI models and agentic workflows in production environments.

The company also expects the division of labor between initial-access operators and downstream monetization groups to support the development of a larger illicit resale marketplace.

This is Google's forward-looking assessment, rather than a confirmed prediction of how every threat group will operate.

Detection and Hunting: Identifying Unauthorized AI Resource Usage

Google emphasizes that defenders need early visibility into changes to cloud LLM accounts and services.

In several Mandiant investigations, the targeted LLM services were not enabled when the initial compromise occurred. Attackers used compromised access keys to modify cloud environments and activate services such as Amazon Bedrock and Gemini API.

Google recommends treating unauthorized enablement of LLM services as a critical security event.

Google Security Operations Detection Rules

Google Security Operations customers can access relevant detection rules through the Cloud Threats, Mandiant Frontline Threats, and Mandiant Hunting Rules rule packs.

The report identifies the following rule names for detecting activity discussed in its investigations:

These rules cover activity such as credential creation, unauthorized account changes, firewall modifications, SSH key persistence, and potential data exfiltration.

Cloud Audit Logs and API Events Defenders Should Monitor

Google provides platform-specific recommendations for identifying unauthorized AI service activation, model usage, reconnaissance, and attempts to interfere with logging.

AWS: Monitor CloudTrail and Bedrock API Activity

Organizations using Amazon Bedrock should monitor CloudTrail events associated with bedrock.amazonaws.com.

Google recommends reviewing API activity across four areas.

1. Resource exploitation

Monitor direct model execution through:

• Converse

• InvokeModel

• InvokeModelWithResponseStream

2. API throttling and error spikes

Look for high-volume increases in:

• ThrottlingException

• ValidationException

• ResourceNotFoundException

Google notes that these error patterns could indicate automated spraying activity targeting cloud infrastructure.

3. Model discovery and target scoping

Monitor reconnaissance operations used to identify available models and access requirements:

• ListFoundationModels

• ListInferenceProfiles

• GetFoundationModelAvailability

• PutUseCaseForModelAccess

• CreateFoundationModelAgreement

4. Logging changes and evasion

Review activity involving:

• GetModelInvocationLoggingConfiguration

• PutModelInvocationLoggingConfiguration

• DeleteModelInvocationLoggingConfiguration

Google recommends treating attempts to disable logging by principals that are not associated with Infrastructure as Code (IaC) as high severity.

The report also recommends examining User-Agent strings for automated tools and SDKs, including claude-cli, aws-sdk-rust, and aws-sdk-go-v2.

Azure: Monitor Control Plane and Data Plane Activity

For Azure environments, defenders should monitor Azure Activity Logs and Diagnostic Logs associated with the Microsoft.CognitiveServices namespace.

Google highlights several areas.

1. Model execution

Model invocations occur on the data plane and require Diagnostic Logs to be enabled.

Monitor for high volumes of POST requests to inference endpoints, including Completions and Chat Completions APIs.

On the management plane, review unauthorized deployment creation through:

Microsoft.CognitiveServices/accounts/deployments/write

2. Resource discovery

Monitor operations used to discover AI resources, models, and deployments:

• Microsoft.CognitiveServices/accounts/read

• Microsoft.CognitiveServices/accounts/deployments/read

3. Logging configuration changes

Review attempts to inspect or modify diagnostic settings:

• Microsoft.Insights/diagnosticSettings/read

• Microsoft.Insights/diagnosticSettings/write

• Microsoft.Insights/diagnosticSettings/delete

These events can help identify attempts to determine whether model invocations are being recorded or to change the logging configuration.

GCP: Enable and Monitor Gemini Enterprise Agent Platform Audit Logs

For Google Cloud environments, GTIG recommends monitoring Cloud Audit Logging for Gemini Enterprise Agent Platform activity associated with:

aiplatform.googleapis.com

A key consideration is that inference operations are recorded in Data Access logs. Google states that these logs are disabled by default because of their volume and ingestion costs.

Organizations must manually configure IAM audit policies to track this activity.

1. Service enablement

Monitor the following method for unauthorized service activation:

google.api.serviceusage.v1.ServiceUsage.EnableService

2. Model execution

With Data Access audit logging enabled, monitor inference operations including:

• google.cloud.aiplatform.v1.PredictionService.Predict

• google.cloud.aiplatform.v1.PredictionService.GenerateContent

• google.cloud.aiplatform.v1.PredictionService.StreamGenerateContent

3. Model and endpoint discovery

Monitor reconnaissance through:

• google.cloud.aiplatform.v1.ModelService.ListModels

• google.cloud.aiplatform.v1.EndpointService.ListEndpoints

• google.cloud.aiplatform.v1.PublisherModelService.ListPublisherModels

4. Logging and audit configuration changes

Review attempts to inspect IAM audit policies and log exports through:

• google.iam.v1.IAMPolicy.GetIamPolicy

• google.logging.v2.ConfigServiceV2.ListSinks

• google.logging.v2.ConfigServiceV2.GetSink

These events can help identify activity aimed at determining whether Data Access logs are enabled or reviewing log export configurations.

Mitigation and Remediation: Reducing Exposure to LLMJacking

Google recommends prioritizing Identity and Access Management (IAM) and software supply chain security because these areas represent common paths into cloud environments.

Its guidance covers credential protection, least-privilege access, repository security, API monitoring, model gateway vulnerabilities, and controls over cloud resource consumption. The following measures are among the recommendations outlined in the report.

Credential Hygiene

Use a centralized secrets management platform to control sensitive credentials and keys.

Automate secret and key rotation to reduce the period during which leaked credentials remain usable.

Least-Privilege Access

Ensure users and Service Accounts have only the permissions required for their roles and tasks.

Avoid granting unnecessary access to cloud LLM services. Deny permissions that are not explicitly required.

Code and Repository Monitoring

Automate secret scanning across code repositories, including GitHub and GitLab.

Identify exposed API keys and credentials added to source code so they can be removed promptly.

Routine Configuration Audits

Regularly audit cloud service configurations to identify exposed endpoints, unintended permissions, and potential attack paths.

Rate Limiting and Network Restrictions

Use web application firewall capabilities, such as Google Cloud Armor, to enforce rate limits for individual client connections.

Where feasible, restrict outbound connections from cloud services through VPC firewall rules to known IP addresses.

Budget Alerts and API Quotas

Configure granular API quotas for individual models to limit request volumes.

Use spending caps and budget alerts to identify unusual consumption and reduce the risk of excessive charges.

Phishing-Resistant MFA

Enforce phishing-resistant multifactor authentication across cloud identity providers, management consoles, and developer platforms.

This helps reduce the risk associated with stolen credentials and session tokens.

Discover Unauthorized AI Infrastructure

Use Security Posture Management tools to scan hybrid cloud environments for unauthorized or unmonitored tools, models, and infrastructure.

Google refers to this as Shadow LLM Discovery.

Restrict API Key Permissions

Use granular API key scopes to separate access by model endpoint, environment, and usage limit.

For example, a token intended for a basic utility model should not automatically provide access to expensive, high-tier frontier models.

Monitor Credential Validation Sweeps

Review model gateway and API access logs for unusual low-volume requests.

Google specifically identifies patterns such as max_tokens=1 and zero-temperature requests as potential signs of automated credential validation.

Patch Application and Model Routing Software

Include application code, containerized workloads, and machine learning dependencies in vulnerability management processes.

Google recommends automated SAST, DAST, and SCA scanning, along with rapid patching of centralized model proxies and routing gateways such as LiteLLM.

The report specifically highlights the LiteLLM privilege escalation vulnerability CVE-2026-40217.

Isolate Dynamic Workloads

Where LLM applications execute generated code or database queries dynamically, use highly virtualized, process-isolated, or serverless sandbox environments.

Use Trusted Model Repositories

Restrict model downloads and pipeline dependencies to trusted internal registries or approved enterprise catalogs.

This helps reduce exposure to compromised models containing preconfigured backdoors.

Map and Validate Attack Paths

Google also recommends graph-based exposure modelling to map cloud assets, application code, and data flows.

Organizations can use this approach to identify multi-step attack paths and prioritize remediation.

The report additionally recommends automated adversarial exposure validation to test external attack surfaces, identify exposed endpoints, and simulate credential validation activity.

Indicators of Compromise

Google has published indicators of compromise through a GTI Collection available to registered users.

The report identifies two network indicators:

These domains can support threat hunting and investigation, but organizations should use the complete GTI Collection for additional indicators rather than treating the two listed domains as an exhaustive set.

What Organizations Should Take Away

Google's findings highlight how enterprise AI infrastructure is becoming a target for financially motivated cybercrime.

The risk extends beyond stolen API keys or unauthorized model usage. Attackers can combine compromised identities, cloud permissions, exposed repositories, model-routing vulnerabilities, and proxy infrastructure to build a monetization operation around an organization's AI resources.

For defenders, this means AI security needs to be integrated into existing cloud security practices.

Credential management, least-privilege access, repository scanning, model gateway patching, audit logging, API quotas, and billing alerts all play a role in reducing exposure.

The report also shows why monitoring only large spikes in model usage may not be sufficient. Attackers can first validate credentials through minimal requests, modify cloud permissions, enable services, and establish persistence before launching high-volume inference activity.

Conclusion

Google Threat Intelligence Group's investigation describes an evolving LLMJacking ecosystem in which threat actors compromise enterprise AI resources and turn unauthorized access into an underground business.

The emergence of LLM Mixers adds another layer to the threat. Instead of using stolen model access only for their own operations, attackers can aggregate compromised credentials, route requests through proxy infrastructure, and resell access to underground customers.

With individual incidents producing more than $100,000 in daily fraudulent charges and some organizations accumulating costs of up to $1 million before access was revoked, the financial consequences can be significant.

For organizations adopting cloud-hosted AI models, protecting API credentials alone is not enough. Security teams also need visibility into cloud identities, model gateways, service activation, inference activity, logging changes, and unexpected consumption across their AI infrastructure.