> ## Content Index > Fetch the complete content index at: https://f4n6.co.uk/llms.txt > Use this file to discover other available public pages before exploring further. # UNC6993 and others exploit cloud tokens for LLMJacking fraud - URL: https://f4n6.co.uk/security-feed/unc6993-and-others-exploit-cloud-tokens-for-llmjacking-fraud/ - Published: 2026-11-02T16:55:00.000Z - Updated: 2026-11-02T16:55:00.000Z - Author: Jeff Davies - Tags: #security-feed, UNC6993 ## 1\. Executive summary Mandiant reports multiple 2026 intrusions in which financially motivated clusters hijacked enterprise access to large language models, a tactic it calls LLMJacking, with fraudulent resource charges exceeding $100,000 USD in a single day and cumulative charges at some organisations reaching $1 million USD before access was revoked. Victims were in North America, South America and Asia Pacific across financial services, retail, technology and transportation. The dominant initial access vector was exposed or stolen cloud identity tokens (IAM credentials, Service Account keys, GitHub Personal Access Tokens and active session tokens), and one cluster, UNC6993, also ran a session-hijacking page that captured users' raw JSON access tokens to bypass password and MFA controls. No CVE in this item carries a verified CVSS score, EPSS value or CISA KEV entry, and UNC6993 has no MITRE ATT&CK profile, so the attribution is unconfirmed. For EMEA financial services the exposure is direct: any institution running cloud LLM services, model gateways or agentic workloads with broadly scoped keys can be monetised against within hours, and the cost lands on the victim's cloud bill. ## 2\. Regulatory framing | Article | Trigger (the fact in this item) | Practical impact | | ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | DORA Art. 17 | Fraudulent LLM resource consumption and unauthorised IAM/service-account creation constitute an ICT-related incident on production cloud infrastructure | The incident management process must cover cloud LLM abuse as a defined incident class, with detection, escalation and revocation runbooks | | DORA Art. 19 | Charges exceeding $100,000 USD in a single day and up to $1 million USD cumulative, with unauthorised enablement of LLM services | Cost and service impact of this scale requires assessment against the major-incident classification and reporting thresholds | | NIS2 Art. 21(2)(d) | Initial access came through stolen Service Account keys, GitHub PATs and third-party API keys, and through a suspected web application vulnerability in a containerised dependency | Supply chain security measures must extend to cloud identity material and the model routing and dependency components in the LLM stack | ## 3\. Technical analysis & attack chain Mandiant describes a consistent lifecycle across the incidents it responded to in 2026\. The confirmed steps, as reported: 1. Initial access through exposed or stolen cloud identity tokens: IAM credentials, Service Account keys, GitHub Personal Access Tokens and active session tokens. In mid-2026 UNC6993 compromised a cloud instance through a misconfigured Service Account key and used that access to grant further access to an LLM API. 2. Credential validation. One actor harvested exposed corporate LLM API keys from public GitHub repositories and ran automated validation sweeps using minimal single-token requests (`max_tokens=1`) to confirm the keys worked while staying under EDR and SIEM volume anomaly thresholds. 3. Privilege escalation and persistence. Actors enumerated cloud services, code repositories and data stores for credentials; used token-creation privileges on compromised workloads to mint temporary credentials for high-privilege service accounts; created unauthorised IAM and service accounts; attached administrative policies to service roles; and injected SSH public keys into compute instance host configuration files and instance metadata. 4. Monetisation. Actors enabled managed generative platforms, created additional API keys, subscribed victim accounts to Pay-As-You-Go agreements, selected premium foundation models and launched high-volume inference streams. A "burn and rotate" strategy of continuously creating and deleting short-lived service accounts bypassed rate limits while the actor audited the billing interface. UNC6993 accumulated over $100,000 USD in billing charges in this way. The session-hijacking page is the technique most likely to reach a bank's own staff. UNC6993 hosted a page masquerading as an application portal to join a group of LLM users. It tricks users into navigating to the legitimate LLM service website and pasting their raw JSON payload containing an active access token, which is then posted to the backend API to bypass password and MFA controls. Phishing-resistant MFA does not stop this, because the token is captured after authentication. Two further access paths are reported. One actor combined a stolen PAT giving access to private code repositories with exploitation of a suspected web application vulnerability in a package running in a containerised cloud environment; the vulnerability is not named. Another used compromised IAM credentials of corporate users and cloud federation tokens to programmatically generate fresh access keys, circumventing MFA. On the LiteLLM gateway, a follow-on cluster that had acquired pre-validated Virtual Keys from the initial-access actor exploited a user ID rebind vulnerability in the `/key/regenerate` endpoint, tracked as CVE-2026-40217, to elevate standard Virtual Keys into full PROXY\_ADMIN master administrative credentials. NVD has not scored CVE-2026-40217 in the data available here and it has no CISA KEV entry, so no verified severity applies; the source describes it as a privilege-escalation flaw. No fixed LiteLLM release is named in public reporting. Monetisation infrastructure. GTIG describes a division of labour between actors establishing initial access and operators running "LLM Mixers", illicit routing gateways that proxy, aggregate and resell unauthorised LLM access. UNC6993 used the open-source tools new-api (a centralised model hub and gateway) and gcli2api (an API proxy converting CLI tools into frontier model endpoints), likely to aggregate stolen keys and balance load; GTIG believes it sells access through underground storefronts. One actor made more than 500,000 LLM API calls in under eight hours using stolen third-party API keys to power the token routing service jet-night.com, passing nearly one million dollars in token costs to the victim. Jet Night advertises an unlimited token plan at approximately $60 USD per month against a typical $100 to $250 USD, and GTIG assesses it relies on stolen keys. Another actor deployed custom proxy relay infrastructure (ai-relay) on lookalike domains, including one masquerading as the victim's internal host, to siphon LLM access into the newapi\[.\]pro resale ecosystem. Agentic tooling. One actor deployed a containerised backdoor using the Manus agent framework that queried an upstream LLM to reason through instructions and execute the resulting commands locally, supported by SearXNG metasearch and agent-infra/sandbox execution environments, and provisioned GPU compute across multiple regions with API quota-increase requests. Exposure of self-hosted endpoints is a separate, lower-volume path. An automated script called the `/api/create` endpoint to register the actor's own models on publicly exposed Ollama endpoints. This detail and the Ollama reference appear in the Google Cloud version of the report; the excerpt circulated by The Register does not carry it. Confidence caveats. The incident detail, the UNC6993 attribution and the Jet Night assessment are single-sourced to Mandiant and GTIG; The Register's coverage repeats the same figures and adds no independent corroboration. The Symantec honeypot research on an autonomous LLM-abusing agent (reported by Help Net Security on 2026-10-23) is a separate event and is not part of these intrusions; it is noted here only because it describes the same class of resource theft. ## 4\. Mitigation & containment P1 within 24 hours - Hunt cloud audit logs for enablement of LLM services on projects where they were not previously active. Mandiant found LLM services were not enabled at the time of compromise in multiple incidents, and unauthorised enablement should be treated as a critical security event. On GCP, alert on `google.api.serviceusage.v1.ServiceUsage.EnableService`; on Azure, on `Microsoft.CognitiveServices/accounts/deployments/write`. - Review IAM for unauthorised accounts and roles: new service accounts, administrative policies attached to service roles, and accounts with names resembling internal billing or optimisation utilities. Revoke and rotate any credential with LLM API scope that is not tied to a known workload. - Search compute instance metadata and host `authorized_keys` files for SSH public keys that were not deployed through configuration management. - Check model gateway logs for `max_tokens=1` and zero-temperature single-token requests, the validation pattern Mandiant reports. Treat clusters of them from one key as a compromise indicator. - Set hard spending caps and per-model API quotas on every LLM service before the next billing cycle; the loss in these incidents accrued in hours, not weeks. - Brief staff on the token-paste page: no legitimate LLM provider asks a user to paste a raw JSON payload containing an access token into a third-party portal. Report and block the domain pattern. P2 within 72 hours - Enforce least privilege on LLM service access. Deny LLM API permissions to every user and service account that does not explicitly require them. - Move secrets into a centralised secrets management platform with automated rotation to shorten the life of any leaked key. - Enable data-plane logging where it is off by default. GCP Gemini Enterprise Agent Platform inference sits in Data Access logs, which are disabled by default and must be enabled through IAM audit policy; Azure model invocations require Diagnostic Logs. Without these, inference abuse is invisible. - Restrict outbound connections from cloud workloads through VPC firewall rules to known IP addresses where feasible, to limit relay and proxy egress. - Automate secret scanning across GitHub and GitLab and revoke any LLM API key found in source. P3 within 7 days - Patch model routing gateways. CVE-2026-40217 in the LiteLLM `/key/regenerate` endpoint allows Virtual Key to PROXY\_ADMIN escalation; no fixed release is named in public reporting, so restrict access to the endpoint and audit Virtual Key issuance until the vendor publishes one. - Segment API keys by model endpoint, environment and usage limit so a key for a utility model cannot invoke frontier models. - Run configuration audits for publicly exposed LLM endpoints, including Ollama instances, and close any that answer on the internet. - Isolate any workload that executes LLM-generated code or database queries in a process-isolated sandbox. ## 5\. Indicators of compromise | type | value | confidence | source | | ------ | ----------------- | ---------------------------------------- | ----------------------- | | domain | jet-night\[.\]com | high (named by Mandiant as an LLM Mixer) | Google Cloud / Mandiant | | domain | newapi\[.\]pro | high (named by Mandiant as an LLM Mixer) | Google Cloud / Mandiant | ```iocs domain jet-night[.]com domain newapi[.]pro ``` No file hashes, IP addresses or host artefacts are published in the source material; Mandiant states that fuller indicators are in a GTI Collection available to registered users. The open-source tools new-api, gcli2api, LiteLLM, Manus, SearXNG and XMRig are legitimate or dual-use software and are not indicators. Behavioural indicators | behaviour | where to observe | confidence | | ------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | ----------------------------------------------------- | | Single-token validation requests (max\_tokens=1) against LLM APIs | model gateway and API access logs | high (reported by Mandiant) | | Enablement of LLM services on projects where they were previously off | cloud control-plane audit logs | high | | Creation and rapid deletion of short-lived service accounts | IAM audit logs | high | | Calls to view, alter or delete model invocation logging configuration by non-IaC principals | CloudTrail, Azure Activity/Diagnostic Logs, GCP Cloud Audit Logging | high | | SSH keys injected into instance metadata or host configuration | compute instance metadata, authorized\_keys | high | | High-volume ThrottlingException, ValidationException or ResourceNotFoundException spikes from bedrock.amazonaws.com | CloudTrail | medium (pattern guidance, not tied to a named victim) | ## 6\. Detection The sources give no file artefacts, command lines or mutexes for the LLMJacking tooling itself, so a YARA rule would have nothing genuine to match. Detection rests on cloud audit behaviour. The Sigma rule below targets the logging-tampering and service-enablement events Mandiant names. ```yaml title: Cloud LLM Service Enablement or Invocation Logging Tampering id: 8f3c2a71-4d6e-4b9a-9c1e-llmjack0001 status: experimental description: Detects enablement of cloud LLM services and tampering with model invocation logging, behaviours Mandiant associates with LLMJacking monetisation. author: Adverse Trace date: 2026/11/02 references: - https://cloud.google.com/blog/topics/threat-intelligence/llmjacking-monetizing-compromised-cloud-models/ logsource: product: aws service: cloudtrail detection: selection_logging: eventName: - PutModelInvocationLoggingConfiguration - DeleteModelInvocationLoggingConfiguration selection_model_access: eventName: - PutUseCaseForModelAccess - CreateFoundationModelAgreement filter_iac: userIdentity.type: AssumedRole userIdentity.arn|contains: 'terraform' condition: (selection_logging or selection_model_access) and not filter_iac falsepositives: - Approved infrastructure-as-code changes to model access level: high ``` A companion rule for GCP service enablement: ```yaml title: GCP Gemini Enterprise Agent Platform Service Enabled id: 1b7e9d20-5a4f-4c88-b2d3-llmjack0002 status: experimental description: Alerts on enablement of Gemini Enterprise Agent Platform services, which Mandiant reports actors use to turn on LLM billing in victim projects. author: Adverse Trace date: 2026/11/02 references: - https://cloud.google.com/blog/topics/threat-intelligence/llmjacking-monetizing-compromised-cloud-models/ logsource: product: gcp service: auditlogs detection: selection: protoPayload.methodName: google.api.serviceusage.v1.ServiceUsage.EnableService protoPayload.serviceName: aiplatform.googleapis.com condition: selection falsepositives: - Approved project onboarding level: high ``` ## 7\. Sources - Google Threat Intelligence Group / Mandiant, "The Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources", https://cloud.google.com/blog/topics/threat-intelligence/llmjacking-monetizing-compromised-cloud-models/, 2026-11-02 - The Register, "Token thieves costing companies $100K+ per day in illicit LLM charges", https://www.theregister.com/security/2026/11/02/token-thieves-costing-companies-100k-per-day-in-illicit-llm-charges/5306967, 2026-11-02 - Help Net Security, "Hackers hijack exposed AI models to launch cyberattacks at victims' expense", https://www.helpnetsecurity.com/2026/10/23/llmjacking-agent-hijacks-exposed-ai-models/, 2026-10-23 (separate Symantec honeypot research, not part of the Mandiant incidents) ## 8\. Adverse Trace position Adverse Trace assesses this as a high-impact financial and operational threat to EMEA financial services institutions running cloud LLM services, with the loss concentrated in cloud billing and in the exposure of infrastructure credentials pulled from secret managers, not in customer data. The incident detail and the UNC6993 attribution are single-sourced to Mandiant and GTIG; UNC6993 has no MITRE ATT&CK profile, so we treat the attribution as unconfirmed and will not use the name for blocking or threat hunting on its own. No CVE in this item has a verified CVSS score, EPSS value or CISA KEV entry, and CVE-2026-40217 in particular is unscored by NVD in the data we hold, so we do not assign it a severity. We will monitor for a published LiteLLM fix for CVE-2026-40217 and for the GTI Collection indicators, and we will reissue this advisory if either appears. Clients should treat unauthorised LLM service enablement as a P1 detection event and confirm spending caps are in place before the next billing cycle. --- [Read the original source →](https://cloud.google.com/blog/topics/threat-intelligence/llmjacking-monetizing-compromised-cloud-models/?ref=f4n6.co.uk) *Published via PulseTrace — Adverse Trace threat intelligence.*