LLMJacking: How Cloud Identity Theft Fuels AI Abuse

Enterprise adoption of large language models has created a new form of cloud abuse: attackers are no longer interested only in stealing data or deploying cryptocurrency miners. They are also looking for ways to use an organization’s identity credentials, model quotas, and GPU capacity to run or resell generative AI services.

Google Threat Intelligence Group (GTIG) and Mandiant describe this activity as LLMJacking in their report, “The Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources”. Their research draws on multiple incidents investigated in 2026 involving organizations in North America, South America, and Asia Pacific, including companies in financial services, retail, technology, and transportation.

The central finding is operational rather than theoretical: compromised access to cloud-hosted models can be converted into immediate financial gain. Mandiant observed individual incidents in which fraudulent resource consumption exceeded $100,000 in a day, while cumulative charges at some organizations reached $1 million before access was revoked. The research also shows that the criminal market is becoming specialized, with some groups obtaining access and others operating infrastructure that resells it.

How the LLMJacking chain begins

According to GTIG and Mandiant, operators generally pursue one of two initial paths. They may discover an LLM endpoint that has been exposed without adequate protection, or they may obtain credentials that provide access to cloud infrastructure and model APIs.

Publicly reachable LLM services are particularly attractive because an attacker may be able to test whether the service will accept requests or allow models to be registered. The researchers describe testing of exposed Ollama endpoints and automated calls to an /api/create endpoint. These activities can turn an overlooked development or internal service into a source of unauthorized model execution and hosting expense.

However, the dominant access route across the investigations was compromised cloud identity material. The observed credentials included IAM credentials, cloud service-account keys, GitHub personal access tokens, and active session tokens. LLM API keys exposed in public repositories were also harvested and tested.

One incident involved the cluster identified as UNC6993, which GTIG reported had obtained access through a misconfigured service-account key and then used that access to grant additional access to an LLM API. In another case, a stolen GitHub personal access token provided access to private repositories, while a suspected web application vulnerability in software running inside a containerized cloud environment was also involved. The supplied research does not identify that suspected vulnerability by CVE number.

The research also describes phishing designed to capture active sessions rather than passwords. A page made to resemble an application portal instructed users to visit a legitimate LLM service and paste a raw JSON payload containing an active access token. The token was then sent to a backend API, allowing the operator to bypass password and multifactor authentication controls. This is an assessment of the observed technique; it does not mean that MFA was universally defeated across the incidents.

In a separate case, compromised corporate IAM credentials were used with cloud federation tokens to generate fresh access keys. GTIG also observed automated validation of stolen API keys through very small requests, including requests configured with max_tokens=1. The researchers assess that this low-volume testing helped operators confirm which credentials worked while reducing the chance of triggering volume-based alerts.

Expansion, privilege abuse, and persistence

After obtaining an initial foothold, the operators described by Mandiant did not immediately limit themselves to model calls. They searched the surrounding cloud environment for additional access and higher-value resources.

Observed reconnaissance included mapping services and identity policies across cloud regions, examining code repositories, reviewing access logs, and querying data-warehouse metadata for database credentials, administrator passwords, and sensitive columns. In a containerized environment, one actor cloned repositories to search for hardcoded secrets, configuration variables, and developer credentials. The investigation also recorded cloud object-storage activity associated with targeted data theft.

Identity permissions were then used to expand control. In one case, service-account permissions that allowed token creation were abused to generate temporary credentials for higher-privileged service accounts. The resulting access exposed infrastructure credentials, internal database passwords, and third-party API keys stored in cloud secret managers.

Persistence mechanisms included creating unauthorized IAM and service accounts, attaching administrative policies to service roles, and adding SSH keys to compute instances. Some accounts were disguised as internal billing-optimization utilities. In another example, environment-wide SSH keys were inserted into compute-instance metadata. These findings matter because a cloud account may remain compromised even after an organization revokes the first credential used by the attacker.

GTIG also documented exploitation of an LLM routing application. After obtaining prevalidated virtual keys, a follow-on cluster exploited a user-ID rebinding flaw in the /key/regenerate endpoint of a LiteLLM gateway. The report identifies this vulnerability as CVE-2026-40217 and states that it allowed standard virtual keys to be elevated into PROXY_ADMIN master credentials. The research presents this as a specific observed incident, not evidence that every LiteLLM deployment is vulnerable or compromised.

From unauthorized inference to resale

The monetization phase took several forms. Operators enabled managed generative-AI services, created additional API keys, subscribed victim accounts to pay-as-you-go plans, selected premium models, and launched high-volume inference streams. One group used a “burn and rotate” approach, repeatedly creating and deleting short-lived service accounts while watching the billing interface.

Some actors used the compromised environments to host proxy endpoints and agentic workloads. GTIG observed deployments that used custom Node.js proxy bundles, containerized workloads, and gateway software to expose access compatible with multiple frontier models. One reported workload used the Manus agent framework together with SearXNG and sandbox execution environments. The supplied research describes these components as part of an observed deployment; it does not establish that they were present in every incident.

The researchers also observed GPU provisioning attempts across multiple regions, including requests for high-end hardware and quota increases. In other cases, the goal was not simply to consume the victim’s resources but to sell access to them.

GTIG uses the term “LLM Mixers” for illicit routing services that aggregate stolen credentials, distribute requests, measure usage, and resell access to underground customers. The report describes cooperation between an access-producing cluster and a downstream monetization cluster, illustrating a division of labor within the emerging ecosystem.

The research names jet-night[.]com and newapi[.]pro as network indicators associated with LLM Mixer activity. It also reports that one service handled more than 500,000 API calls in less than eight hours and passed nearly $1 million in token costs to a victim organization. GTIG assesses that unusually low subscription prices offered by such services are consistent with the use of stolen API keys, but this is a researcher judgment rather than proof that every low-cost AI service operates unlawfully.

What defenders should monitor

Early warning depends on treating changes to AI services as security events, not merely billing or configuration events. Mandiant states that in multiple investigations, the relevant LLM services were disabled before compromise and enabled by the attacker afterward.

Security teams should alert on unexpected service enablement, new model deployments, newly created API keys, quota increases, subscription changes, and sudden growth in inference activity. Low-volume validation requests deserve attention alongside large spikes. Requests using very small output limits, such as max_tokens=1, may indicate credential testing when they are inconsistent with normal application behavior.

Cloud audit logs should be reviewed for model discovery, inference, identity, and logging changes. The report recommends monitoring AWS Bedrock operations such as model invocation, foundation-model enumeration, model-access changes, and logging-configuration changes. In Azure, teams should examine Cognitive Services resource and deployment events, inference-endpoint activity, and diagnostic-setting modifications. In Google Cloud, relevant visibility includes service enablement, model and endpoint enumeration, prediction operations, and changes to audit-log or export configuration.

These controls require the right logs to be enabled. The research notes that some Google Cloud data-access logs relevant to inference are disabled by default because of volume and ingestion costs. Organizations should make an explicit risk-based decision about enabling them, particularly for production model projects and sensitive workloads.

What organizations should do now

• Reduce identity exposure. Store cloud keys and API secrets in centralized secret-management systems, rotate them automatically, and remove credentials from source repositories. Use phishing-resistant MFA for cloud, developer, and administrative platforms.
• Apply least privilege. Separate development and production identities, restrict service-account token creation, limit access to LLM services, and prevent ordinary workloads from creating administrative accounts or keys.
• Constrain model access. Scope API keys by environment, model, endpoint, and usage limit. Use quotas, spending caps, and granular budget alerts to reduce the impact of unauthorized inference.
• Harden the exposure surface. Audit public endpoints, containerized applications, model gateways, cloud firewall rules, instance metadata, and repository contents. Include routing middleware such as LiteLLM in vulnerability-management and patching programs.
• Control egress and traffic volume. Where practical, restrict outbound connections to approved destinations and apply rate limits at gateways or web-application firewalls. Investigate new public proxies and unexpected automated clients.
• Discover shadow AI. Maintain an inventory of models, agents, gateways, credentials, and cloud projects. Unmonitored experimentation can create the same exposure as an intentionally deployed service.
• Prepare for response. If abuse is suspected, revoke affected tokens and keys, disable unauthorized services and accounts, review persistence such as SSH keys, preserve cloud and application logs, and contact the cloud provider about fraudulent usage.

Conclusion

LLMJacking combines familiar cloud identity abuse with a newer and potentially expensive target: production-grade AI capacity. The investigations from GTIG and Mandiant show that the attack can progress from exposed endpoints or stolen credentials to privilege escalation, persistence, model consumption, and underground resale.

The most effective defense is not a single AI-specific control. It is coordinated identity governance, secret hygiene, gateway security, detailed audit logging, strict quotas, and rapid detection of service and billing changes. Organizations that treat model access as a privileged cloud resource will be better positioned to identify misuse before unauthorized inference becomes a major operational or financial incident.

Sources

Google Threat Intelligence Group / Mandiant: The Rise of LLMJacking: How Threat Actors Monetize Compromised Cloud and Model Resources