LLMjacking is an emerging attack vector where threat actors hijack access to cloud-based AI models using stolen credentials. Unlike “traditional” breaches targeting human users and passwords, LLMjacking attacks focus on exploiting non-human identities (NHIs), the machine accounts and secrets that make generative AI (GenAI) services go round. Compromised NHIs like API keys allow cybercriminal groups to quietly abuse expensive large language models (LLMs), generate content, and even exfiltrate sensitive data, all at the victims’ expense.
Recent high-profile incidents, like the Microsoft Azure AI abuse, where the Storm-2139 threat actor group systematically stole API keys from Microsoft customers to bypass security controls and generate illicit content on the dark web, and the discovery of 11,908 exposed secrets in the Common Crawl dataset used to train models like DeepSeek, clearly demonstrate the critical risks of LLMJacking and NHI exposure.
To understand how real-world attackers operate when they find exposed NHIs and tokens, security researchers at Entro, exposed valid AWS API keys across public platforms then monitored what happened next. The findings reveal how quickly threat actors move, their reconnaissance attempts and how they attempt to exploit GenAI access.
Figure 1: The LLMJacking kill-chain observed in the research. Once an NHI is exposed and found, attackers rapidly move through reconnaissance, model enumeration, and eventual exploitation. The process is highly automated, with bots API calling exposed secrets, validating their permissions, and attempting unauthorized AI model invocations.
Enterprise Security for AI Agents & Non-Human Identities
Baiting the Blackhats: When AWS Secrets Go Public
The Entro Labs security research team first created a few dedicated AWS environments with real AWS keys and deliberately leaked them across different public services. The chosen websites mimic where accidental leaks often happen: public GitHub code repositories, snippets on Pastebin, and developer subreddits on Reddit.
Figure 2: One of the exposed AWS credentials on pastebin.com. Entro Labs’ recent research found that almost 44% of NHI tokens get exposed via code repos, chat logs, and collaboration channels.
Each key was a fully functional AWS credential set (access key ID + secret access key) with controlled access to specific AWS cloud services (like S3 buckets, AWS AI model endpoints, etc.). The exposed credentials were then monitored for anomalous activity by the Entro platform, tracking how quickly and in what ways attackers attempted to exploit these NHIs. The research captured every access attempt, including timestamps, source IPs, user-agent strings, and the specific AWS actions invoked via API calls.
This approach provided a rare, unfiltered peek into read attackers’ behavior, revealing who finds leaked secrets, how fast they act, and what tactics they use to probe and exploit AI models using NHIs.
Fast & Curious: Minutes to First Unauthorized Access Attempt
It turns out, threat actors are extremely fast in discovering and exploiting the exposed NHIs. In our Entro Labs experiments, the first reconnaissance attempts occurred within 17 minutes on average after a token was leaked – and the fastest attempt hit in only 9 minutes. This means an exposed cloud key and secrets can be probed by malicious actors almost immediately, often well before an organization even realizes they are public. Such speeds are consistent with other documented secret-leak research, which has observed canary tokens being grabbed in seconds or minutes on popular platforms.
However, unlike canary tokens, Entro researchers used fully functional AWS credentials with controlled permissions, ensuring attackers were interacting with “authentic” secrets rather than decoys.
Figure 3: Attackers waste no time, the average time-to-access of exposed secrets on different exposure locations. Source: cybenari
What followed were a mix of automated scripts and human-driven exploits, revealing a playbook of quick reconnaissance and opportunistic abuse. This minimal time-to-first-access highlights that attackers employ continuous automated scanning of code shares, forums, and paste sites for any credentials. In practice, the moment an AWS key is accidentally pushed to GitHub or mentioned on Reddit, the countdown to compromise has already begun.
The window for defenders to react and remediate is relatively small, emphasizing the need for real-time NHI detection and response as well as automatic key revocation to beat the attackers’ speed.
Reconnaissance Methods: Automated Bots & Manual Procedures
The NHI governance data revealed a telling mix of attack methods and tactics used to exploit the leaked AWS keys. The majority of access attempts had clear evidence of automation. User-agent strings indicated scripts and tools written in Python – for instance, many requests came from clients identifying as botocore/* (the AWS SDK) or popular HTTP libraries like python-requests.
This aligns with the idea of stealthy bots crawling public sites, instantly testing any keys they find. In one case, an attacker’s script accessed the key less than 10 minutes after exposure, suggesting an automated pipeline from leak discovery to exploitation.
However, not all activity was bot-driven. Entro’s research also captured evidence of manual exploitation attempts. A subset of requests originated from a “Mozilla” user-agent (Firefox) – something a normal browser would use, not an AWS SDK. This implies human attackers likely noticed the leaked key and manually attempted to use it, perhaps by loading AWS web console endpoints or employing developer tools. Such manual actions might be an attacker validating the key in a browser or exploring what they can do interactively.
The combination of fast, scripted attacks and slower, hands-on attempts shows that both opportunistic bots and human adversaries are in play. The bots cast a wide net to scoop up exposed NHIs at scale, while skilled individuals may intervene to maximize the value of a particularly interesting credential (for example, a key hinting at access to AI models or high cloud privileges).
From a defender’s view, these patterns are crucial. Automated attacks mean any exposed secret will be jumped on 24/7 no matter the hour/date. Meanwhile, the presence of manual attacker sessions might indicate a more targeted breach intent (a person exploring the environment for deeper intrusion or abuse).
In our research, both methods were observed back-to-back – a script rapidly validating the AWS keys’ validity, followed by a manual reconnaissance attempt via browser. This dual nature of attack tactics shows a critical need to detect both machine-like anomalies (unusual programmatic access) and human-like ones like a normally “headless” machine identity suddenly using a web browser.
Inside the Attackers’ Playbook: Final Recon Before LLM Abuse
A clear pattern emerged in how attackers proceeded after obtaining the NHIs. Rather than immediately launching resource-intensive AI jobs, the attackers first performed additional reconnaissance to gauge the key’s capabilities. In fact, the very first API calls made with the stolen AWS keys were benign-looking queries to enumerate available services and permissions.
For example, one attacker first used the exposed key to invoke AWS’s GetCostAndUsage API call – essentially checking the cloud spend on the account, most probably to gauge its value and potential for further exploitation.
Figure 4: An attacker attempted to invoke GetCostAndUsage, likely to assess account value for further exploitation
Interestingly, Entro Labs didn’t observe GetCallerIdentity, a commonly expected API call for initial credential validation, likely because attackers aim to evade detection, knowing that defenders have come to expect and monitor for this API call.
Another NHI thief made 9 consecutive calls invoking the GetFoundationModelAvailability command, successfully listing the available LLMs within the compromised AWS account. The requests originated from a Mozilla browser. This suggests a deliberate reconnaissance effort – before attempting model invocation, the attacker first verified which AI models (e.g., GPT-4, Claude, DeepSeek, etc.) were accessible. This appears to be a common LLMjacking tactic, where threat actors assess available AI resources and platforms before launching unauthorized queries or trying to monetize stolen access.
Figure 5: One threat actor successfully listed the available LLM models associated with the compromised AWS key
During the initial reconnaissance phase the attackers deliberately did not run actual AI prompts, likely to avoid racking up immediate costs or triggering usage alarms. Entro’s researchers observed analogous behavior: the stolen AWS keys were first used to query model availability and to fetch configuration info. Only after mapping out the token’s power did the attackers attempt actual AI model invocations.
Figure 6: AWS Bedrock offers a wide range of GenAI models from providers like Anthropic, Amazon, and DeepSeek. Threat actors with compromised AWS keys can use this catalog to identify and potentially abuse any available models if the stolen credentials have sufficient permissions.
LLMJacking Live: Real-Life Attempts To Generate Content
Our data showed that once attackers confirmed they could invoke, for example, an Anthropic Claude model via the stolen AWS key, they proceeded to attempt generating content using the InvokeModel command, essentially trying to turn our “compromised” AWS account into their own GenAI playground.
Figure 7: a couple of samples of the hundreds of attempts by threat actors to invoke different GenAI models using our compromised AWS keys.
These weren’t just a few casual attempts – our logs show a relentless, automated effort by the threat actors who systematically tested various models, demonstrating persistence and automation in their attempts to hijack our AI resources.
Fortunately, we had no intention of conducting a pro-bono LLMJacking operation on our end, so we set strict permissions on the exposed AWS tokens, ensuring that while attackers could attempt reconnaissance and model invocation, no actual AI workloads could be executed or abused to generate content, the attempts we’ve witnessed clearly indicated the intent to run illicit AI ops.
This kind of illicit usage can have a severe financial impact. Some advanced AI models bill at hundreds of thousands of tokens per query, meaning an attacker can burn significant cloud credits or money very quickly. Recent analysis estimated that an attacker running undiscovered could cost victims over $46,000 in AI service charges per day – draining cloud budgets in hours.
Beyond financial damage, there’s also potential misuse of the models, generating malicious or harmful content under the victim’s credentials. In the incident mentioned above, Microsoft has recently dismantled a cybercrime operation that did exactly this: they scraped exposed credentials from public exposure sources to abuse Azure OpenAI services, altering the AI models’ guardrails and producing harmful content (like deepfake images and explicit material) for profit. All of that was powered by compromised NHIs.
Final Words and Recommendations: Securing NHIs Against LLMJacking
Our research and its findings provide a microcosm of the larger LLMjacking threat landscape. We’ve seen how exposed non-human identities become immediate targets for automated reconnaissance and exploitation. Organizations leveraging GenAI services must take proactive security measures to prevent LLMjacking.
Here’s what you can do:
- Detect & monitor NHIs in real-time: Use continuous scanning to detect exposed secrets in code repositories, logs, and collaboration tools.
- Implement automated secret rotation: Minimize exposure time by automatically rotating or revoking leaked credentials the moment they are detected.
- Enforce least privilege: Restrict and right-size your NHIs only to necessary permissions, preventing attackers from misusing GenAI services even if they obtain a valid key.
- Monitor unusual API activity: Set up alerts for anomalous NHI behavior, such as unexpected model invocations or excessive billing requests.
- Educate developers on secure NHI management: Train teams to avoid hardcoding secrets, use vaults for credential storage, and adopt best practices for secrets hygiene.
By implementing these measures, security teams can significantly harden their organization’s non-human identities posture against compromise. The goal is to minimize the chances of an NHI exposure, and to maximize the chance of detecting it quickly when they do get abused. In an era of GenAI and LLMjacking, where AI access is a hot commodity for threat actors, such measures are not optional anymore.
