LLMJacking：遭竊憑證助長 LLM 存取權轉售，累計費用達 $1M

1. Overview

• Article: The Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources
• Source: Google Threat Intelligence Group
• Published: 2026-11-02
• Original: Google Threat Intelligence Group
• Related Source: LiteLLM Official Advisory: CVE Matching Check
• Related Malware: ai-relay
• Related Threat Group: UNC6993
• Related CVE: CVE-2026-40217 (Discrepancy noted between Google's report and LiteLLM's official advisory response)
• Related Products: Cloud IAM, LLM API, LiteLLM, new-api, gcli2api
• Severity: critical

2. Executive Summary

Multiple threat actors are abusing stolen cloud credentials, LLM API keys, and public endpoints to resell LLM quotas to third parties. Mandiant confirmed an incident where a victim organization incurred approximately $1 million in unauthorized usage charges before access was revoked. Note that pathways involving privilege escalation or persistence in cloud environments must be distinguished from pathways that directly abuse LLM API keys or public endpoints.

3. Attack Flow

Alternative pathways and monetization flows compiled by Google from multiple response cases. Path A, Path B, and subsequent monetization have different prerequisites and scopes, and the observed tools and actions were not all executed consecutively in a single incident.

Attack Path A: Compromising Environments via Cloud Credentials

1. Using exposed or stolen IAM credentials, service account keys, PATs, or session tokens to access corresponding cloud environments or repositories.
2. Enumerating cloud services, repositories, and data stores depending on the incident to search for additional credentials or high-privilege IDs.
3. When the required privileges are available, attackers expand their privileges or persistence through service account creation, administrator policy attachment, SSH key injection, and token generation. A separate threat cluster was reported to have escalated to LiteLLM administrative privileges using pre-acquired Virtual Keys.
4. Enabling managed LLM services with obtained privileges, creating additional API keys and GPU instances, and requesting quota increases. These operations were observed across multiple separate incidents and were not all executed in a single attack.

Attack Path B: Direct Abuse of LLM API Keys or Public Endpoints

1. Sending minimal requests such as max_tokens=1 to LLM API keys found in public repositories to verify their validity has been confirmed.
2. Executing inference within the scope of privileges and quotas of validated API keys. This path alone does not grant cloud-wide management console privileges or GPU instance creation rights.
3. In a separate incident involving a public Ollama endpoint, an attacker called /api/create to attempt registering and executing a custom model.

Subsequent Monetization: Resale via LLM Mixers and Proxies

1. Bundling unauthorized LLM access via gateways or relay infrastructure to resell inference quotas to third parties. This is distinct from directly selling stolen tokens themselves.
2. UNC6993 utilizes new-api and gcli2api. Google infers the aggregation and load balancing of stolen keys alongside sales via underground storefronts, though this does not mean all threat actors use the same toolset.
3. In another incident, stolen API keys were used on resale platforms such as jet-night.com and newapi.pro via ai-relay.

4. Attacker Positioning and Execution Locations

• Depending on the attack path, access targets include public repositories, public LLM endpoints, cloud IAM, model gateways, and containerized workloads. In paths abusing only LLM API keys, compromise of management consoles or compute instances within the victim's cloud was not confirmed.

5. Perspective of Victims and Administrators

Victims

• Manifests as a sudden spike in LLM API usage fees, exhausted quotas, unfamiliar model usage, or service suspensions.

Administrators

• Observed as the enablement of unused LLM services, creation of API keys or service accounts, changes to IAM policies, addition of SSH metadata, repository cloning, access to secret management infrastructure, and creation of GPU instances.

6. Conditions for Success and Failure

Success Conditions

• In pathways abusing cloud credentials, cloud/repository operations permitted by the ID serve as the starting point. Privilege escalation, LLM service enablement, key creation, and compute creation each require corresponding privileges or vulnerability exploitation.
• Pathways abusing LLM API keys require valid keys along with model invocation privileges and quotas, while public endpoint pathways require states that accept requests without authentication or similar constraints. Cloud management privileges are not mandatory for these paths.
• In the LiteLLM privilege escalation incident, attackers used pre-acquired Virtual Keys. For discrepancies between CVE numbers and patched version mappings, refer to the caveats in Sections 12 and 14.

Failure Conditions and Countermeasures

• Apply secret scanning, short-lived credentials, phishing-resistant MFA, the principle of least privilege, explicit Deny rules for unused LLM privileges, and key scope isolation.
• Contain damage expansion through model-specific quota limits, budget alerts, rate limits, network allowlists, and prompt updates and protection of model gateways.

7. What Happens Upon Success

• Secrets, database passwords, and external service API keys on the cloud are stolen.
• Access is persisted via the creation of administrator privilege IDs or the addition of SSH keys.
• LLM quotas and GPU compute are abused and resold. Mandiant reported unauthorized usage exceeding $100,000 per day and unauthorized charges reaching approximately $1 million for certain organizations before access was revoked (it is not explained that the entire $1 million occurred in under 8 hours).
• The victim organization's account is abused for third-party activities through the resold resources.

8. Observable Logs

• Email: Invitation emails or fake portal URL guidance prompting the pasting of raw JSON tokens.
• Proxy / SWG / DNS: Traffic records to jet-night.com, newapi.pro, unknown LLM proxies, and public Ollama endpoints.
• Endpoint / EDR: Execution of cloud CLIs, repository cloning, external transmission of archives via curl/wget, and modification of SSH keys.
• Identity / IdP: Creation of service accounts or access keys, token generation, issuance of federation tokens, administrator policy attachment, and suspicious sessions.
• SaaS / Cloud: Enablement of LLM services, model invocations, API key creation, quota increase requests, GPU instance launches, access to secret management infrastructure, and surges in billing amounts.
• Network: High-frequency inference requests following validation traffic via minimal requests such as max_tokens=1, burst traffic to multiple regions, and outbound traffic to unknown relay servers.

9. Attack Success Assessment

Malware Execution or Authentication Success Confirmed

• Judgment Stage: Malware Execution or Authentication Success Confirmed (malware_or_authentication_success) / Scope: Multiple cloud compromise incidents
• Basis: Public Information: Google reported multiple incidents where attackers actually accessed cloud environments and LLM APIs using stolen tokens and API keys.

Information Theft or Session Compromise Confirmed

• Judgment Stage: Information Theft or Session Compromise Confirmed (data_or_session_compromise) / Scope: Multiple cloud compromise incidents
• Basis: Public Information: Theft of credentials and secrets from repositories, secret management infrastructure, and data stores has been confirmed.

Follow-on Compromise Confirmed

• Judgment Stage: Follow-on Compromise Confirmed (follow_on_compromise) / Scope: Monetization of LLM resources
• Basis: Public Information: Creation of unauthorized accounts, API keys, and GPU instances, enablement of LLM services, and resale and billing generation via LLM Mixers have all been confirmed.

10. Investigation Playbook

Trigger

• Use sudden surges in LLM billing, enablement of unused services, creation of unfamiliar API keys or service accounts, and validation traffic with max_tokens=1 as investigation triggers.

Initial Triage

• Identify billed accounts, invoked models, key IDs, execution principals, source IPs, User-Agents, request frequencies, and the timestamp when services were initially enabled.

Endpoint

• Preserve processes, SSH keys, startup scripts, containers, repository clone artifacts, archive creation logs, and outbound traffic records for related workloads.

Identity / Cloud

• Cross-reference IAM change histories, token generation, federation settings, secret access events, PAT usage histories, and GitHub audit logs.

Follow-on Compromise

• Track the deployment or abuse of new-api, gcli2api, LiteLLM, and ai-relay, unauthorized GPU instances, connections to public proxies, and the theft of credentials for other clouds.

Containment

• Revoke abused keys, sessions, and tokens, isolate unauthorized IDs and instances, disable unnecessary LLM services and quotas, and rotate related secrets.

Assessment

• Evaluate key validity checks, cloud logins, secret theft, persistence, resource abuse, and external resale as distinct stages.

11. Defense and Detection Ideas

Single Event Detection

• Detect the enablement of normally disabled LLM services, generation of PROXY_ADMIN keys, attachment of administrator policies, and addition of SSH keys project-wide.

Time-Series Correlation

• Correlate key validation via minimal requests, service enablement, key/account creation, quota increases, massive inference invocations, and billing surges as an integrated attack chain.

Hunting Perspectives

• Uncover LLM API keys, service account JSON files, and PATs lingering in public and private repositories, and cross-reference them with unknown sources in usage logs.

Blind Spots in Log Design

• Missing model gateway request bodies, key IDs, cloud audit logs, or billing exports will delay the discovery of unauthorized use and the identification of cost sources.

Priority Countermeasures

• Prioritize migration to short-lived credentials, enforcement of least privilege and key scope limitations, setting quota and budget limits, secret scanning, and gateway vulnerability remediation.

12. Facts / Inference / Hypothesis

Facts

• In 2026, Mandiant responded to LLMJacking incidents across multiple organizations in North America, South America, and the Asia-Pacific region spanning financial, retail, technology, and transportation sectors.
• The primary initial access vector across multiple incidents consisted of exposed or stolen cloud credentials, including IAM credentials, service account keys, GitHub PATs, and valid session tokens. Additionally, public LLM endpoints and LLM API keys found in public repositories were abused.
• UNC6993 breached cloud instances using misconfigured service account keys, while another tactic bypassed passwords and MFA via fake portals prompting users to paste raw JSON containing valid access tokens.
• Attackers verified LLM API key validity using minimal requests with max_tokens=1 to evade detection triggered by normal traffic volume anomalies.
• Following intrusion, activities confirmed included cloud service, repository, and data store enumeration, cloning of private repositories, credential theft from secret management infrastructure, creation of IAM/service accounts, SSH key injection, and administrator policy attachment.
• Google reported an incident where pre-acquired Virtual Keys were used to exploit user ID rebind in LiteLLM's /key/regenerate, escalating privileges to PROXY_ADMIN and mapping it to CVE-2026-40217. Meanwhile, LiteLLM's official advisory GHSA-wxxx-gvqv-xp7p describes the same CVE number as a sandbox escape in /guardrails/test_custom_code, meaning target endpoints, prerequisite privileges, and impacts differ, leaving the mapping unresolved.
• Attackers enabled managed LLM services, added API keys, created GPU instances, increased quotas, executed burn-and-rotate of service accounts, and resold secured quotas via LLM Mixers or reverse proxies.
• Google reported that an attacker performed over 500,000 LLM API invocations in under 8 hours, utilizing stolen API keys for token routing on jet-night.com. In the same Jet Night incident, approximately $1 million in costs was shifted to the victim organization. However, it is not explicitly stated that this billing aggregation period matches the under-8-hour window. In other separate incidents, unauthorized usage exceeding $100,000 per day was observed.

Inference

• While not all low-priced LLM gateways utilize stolen resources, Google assesses based on matching pricing, scale of usage, and outage patterns that Jet Night relies on stolen keys.

Hypothesis

No additional hypotheses. Unverified items are documented under "Uncertainties and Limitations".

13. MITRE ATT&CK Mapping

14. Uncertainties and Limitations

• Individual victim organization names, details of all threat clusters, purchasers of resold resources, and total financial damages have not been publicly disclosed. The ~$1 million figure for the Jet Night incident represents an individual case cost reported by Google and is not a general value across all incidents. It remains unspecified whether the billing aggregation period matches the under-8-hour window during which over 500,000 API calls were observed.
• Regarding the privilege escalation in LiteLLM /key/regenerate reported by Google, the correct CVE mapping, affected versions, and fixed versions remain unconfirmed. Care must be taken not to directly apply patched versions for alternative endpoints described in the official GHSA as a countermeasure for this vector.

15. Impact on SOCs and Organizations

Organizations should treat LLM API keys as high-value cloud resources and monitor service enablement, API key creation, low-volume key-validation requests, quota increases, spikes in inference-token consumption, and billing changes together. They should also investigate GitHub PATs, service account keys, federation tokens, and model gateways across the different intrusion paths that can lead to LLM abuse.

16. Summary by Role

• SOC: Correlate validation traffic with max_tokens=1, LLM service enablement, API key creation, quota increases, and spikes in inference requests across a timeline.
• Administrators: Design out unnecessary LLM API privileges via explicit Deny rules, enforce key scope isolation, quotas, budget limits, and rotation, and ensure thorough protection and updates for model gateways.
• Users: Do not trust external portals demanding cloud tokens or raw JSON pasting, and immediately revoke keys suspected of exposure.