8 minhigh
Someone Else Is Using Your AI
FortiGuard Labs documented an LLMjacking attack where a leaked long-lived AWS IAM access key with AdministratorAccess was used to create a new IAM user, subscribe to foundation models through AWS Marketplace, and invoke them for inference. The attacker generates Bedrock service-specific credentials for the new identity to supplement direct API invocations. Because the attack uses valid credentials and legitimate cloud APIs, it is indistinguishable from normal usage at the API level without contextual logging and correlation.
Sens:▲ 24hConf:high
Detection / Hunteropenrouter
What Happened
Attackers are stealing cloud account credentials to access paid AI models on Amazon Web Services and reselling that access to others. They take a leaked access key, create a new user inside the victim's account, subscribe to expensive AI models, and start running them, leaving the victim with the bill. This can cost over $46,000 per day. Any organization using AWS is potentially affected if their access keys are exposed. It matters because the attackers use normal cloud features, making the activity look legitimate unless you have detailed logging turned on. Organizations should enable full cloud logging, avoid long-lived access keys, and watch for new users or AI subscriptions that appear unexpectedly.
Key Takeaways
- Attackers use leaked long-lived AWS IAM keys with AdministratorAccess to create new IAM users, subscribe to foundation models via AWS Marketplace, and invoke them for inference at the victim's expense.
- The entire attack chain executes in minutes using legitimate cloud APIs, making Bedrock InvokeModel calls from a compromised identity indistinguishable from legitimate usage at the API level.
- Financial exposure can exceed $46,000 per day for Claude 2.x-class inference and over $100,000 per day for Claude 3 Opus, with attackers reselling access as subscription chatbot services.
- Detection requires both CloudTrail logging and Bedrock invocation logging (disabled by default), as CloudTrail alone does not capture request-level inference details.
- The attack depends entirely on long-lived, broad-scope IAM keys; short-lived role-assumed credentials would break the chain.
Affected Systems
- Amazon Web Services (AWS) accounts
- Amazon Bedrock
- AWS Marketplace
- AWS IAM
Vulnerabilities (CVEs)
None identified.
Attack Chain
- Initial Access: Leaked long-lived AWS IAM access key with AdministratorAccess used to access victim account
- Persistence: New IAM user created within victim account
- Resource Subscription: Foundation models subscribed via AWS Marketplace using CreateAgreementRequest/AcceptAgreementRequest on agreement-marketplace.amazonaws.com
- Credential Generation: Bedrock service-specific credentials generated for the new IAM identity via AWS long-term API key mechanism
- Impact: Foundation models invoked (InvokeModel), generating inference charges against victim account; access potentially resold to third parties
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: Yes
- Platforms: FortiCNAPP (Lacework) LQL policies
FortiCNAPP ships multiple LQL detection policies covering this attack chain, including IAM policy changes (lacework-global-12), Bedrock logging deletion (lacework-global-2037), Bedrock throttling exceptions (lacework-global-2038), Marketplace agreement creation (lacework-global-2906), IAM service-specific credential creation (lacework-global-2907), IAM access key changes (lacework-global-13), new AWS user creation (lacework-global-14), and Bedrock posture policies (lacework-global-1999 through 2002, 2781). Rule bodies are not reproduced here; refer to FortiCNAPP documentation.
Detection Engineering Assessment
copy:
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | None | This is a cloud-native attack using AWS APIs. EDR agents on endpoints have no visibility into IAM key usage, Marketplace subscriptions, or Bedrock invocations. |
| Network Visibility | Low | API calls to AWS services use TLS and appear as legitimate cloud API traffic. Network monitoring alone cannot distinguish compromised-but-valid credential usage from legitimate usage. |
| Detection Difficulty | Hard | The attack uses valid credentials and legitimate AWS APIs as designed. A single signal (e.g., first-time Bedrock use) is not actionable on its own. Effective detection requires correlating multiple signals across identity creation, credential issuance, marketplace subscription, and invocation patterns. |
Required Log Sources
- AWS CloudTrail (management events)
- AWS CloudTrail (data events for Bedrock)
- AWS Bedrock invocation logging
- AWS Config for IAM posture monitoring
Hunting Hypotheses
copy:
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Consider hunting for IAM users created shortly before a Bedrock model subscription event on AWS Marketplace, as this sequence indicates an attacker provisioning a new identity to subscribe to foundation models. | AWS CloudTrail events: CreateUser, CreateAgreementRequest, AcceptAgreementRequest on agreement-marketplace.amazonaws.com | Persistence and Resource Subscription | Medium — legitimate automation or infrastructure-as-code pipelines may create users and subscribe to services in sequence, though this is uncommon for Bedrock specifically. |
| Consider hunting for Bedrock service-specific credentials being created for IAM identities that were themselves recently created, as this indicates an attacker generating alternative credentials for a planted identity. | AWS CloudTrail: CreateServiceSpecificCredential events correlated with CreateUser events within a short time window | Credential Generation | Low — service-specific credential creation for newly created users is uncommon in normal operations. |
| Consider hunting for Bedrock invocation logging being disabled or deleted, as this is a defense-evasion step an attacker would take to hide inference abuse. | AWS CloudTrail: DeleteInvocationLogging or configuration changes to Bedrock logging settings; AWS Config posture findings | Defense Evasion | Low — disabling audit logging is rarely legitimate and should be treated as suspicious in any context. |
| Consider hunting for Bedrock ThrottlingException events, which indicate an identity is invoking models at high volume, consistent with reselling inference access to multiple third parties. | AWS CloudTrail: ThrottlingException events on Bedrock InvokeModel API calls | Impact | Medium — legitimate workloads may occasionally hit throttling limits, but sustained or frequent throttling from a single identity warrants investigation. |
| Consider hunting for first-time Bedrock InvokeModel calls originating from IP addresses not previously associated with the account's normal usage patterns, paired with new IAM identity creation. | AWS CloudTrail: InvokeModel events with sourceIPAddress field correlated against historical IP baselines and CreateUser events | Impact | Medium — new office locations, VPN egress points, or legitimate new services may produce unfamiliar IPs. |
Control Gaps
- CloudTrail alone does not capture Bedrock request-level invocation details; Bedrock invocation logging is disabled by default and must be explicitly enabled.
- Standard IAM access key monitoring does not cover Bedrock service-specific credentials, which are issued through a separate API call.
- Signature-based network security tools cannot distinguish legitimate AWS API calls made with stolen credentials from those made with authorized credentials.
- Posture policies for Bedrock configuration are not auto-enabled in default compliance frameworks and require explicit enablement.
Key Behavioral Indicators
- New IAM user creation followed by AWS Marketplace agreement acceptance within a short time window
- Bedrock service-specific credential creation for a recently created IAM identity
- Bedrock invocation logging disabled or deleted after being previously enabled
- Sustained Bedrock ThrottlingException events from a single identity
- First-time Bedrock InvokeModel calls paired with unfamiliar source IP addresses or new identities
- AdministratorAccess policy attached to a newly created IAM user
False Positive Assessment
Medium
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting. Consider auditing all AWS accounts for long-lived IAM access keys with AdministratorAccess or broad privileges and rotating or replacing them with short-lived role-assumed credentials.
- If applicable, enable AWS CloudTrail management and data events on every account if not already active.
- Consider enabling Bedrock invocation logging on all accounts with Bedrock access, as it is disabled by default and provides request-level detail that CloudTrail alone does not capture.
- Evaluate whether any recently created IAM users in your AWS accounts have Bedrock subscriptions or service-specific credentials that were not provisioned through your standard processes.
Infrastructure Hardening
- Consider eliminating long-lived IAM access keys entirely where workloads support role-assumed credentials or temporary STS tokens.
- If your organization supports it, evaluate implementing AWS IAM permission boundaries or SCPs (Service Control Policies) to restrict which identities can subscribe to AWS Marketplace agreements or create Bedrock service-specific credentials.
- Consider enabling FortiCNAPP or equivalent CSPM posture policies for Bedrock configuration (e.g., lacework-global-1999 through 2002, 2781) if you use such tooling.
- Where supported by your tooling, consider implementing alerts for IAM policy changes that attach AdministratorAccess to any identity.
User Protection
- Consider rotating any IAM access keys that have been exposed in public repositories, CI/CD logs, or shared documents, regardless of perceived age.
- If your organization uses CI/CD pipelines, evaluate whether secrets are stored in a managed secrets manager rather than as long-lived environment variables.
- Consider implementing AWS access key age policies that automatically flag keys older than a defined threshold for review.
Security Awareness
- Consider rolling into existing awareness programs a reminder that cloud credentials should never be committed to version control or shared in plaintext channels.
- If applicable, educate engineering teams on the financial risk of exposed cloud credentials beyond data exfiltration, specifically resource hijacking through AI model subscriptions.
- Consider training cloud administrators to recognize that first-time AI service usage in an account should be corroborated with a second signal before being treated as benign or malicious.
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping5 techniques
Tactic
Initial Access
Tactic
Persistence
Tactic
Stealth
Tactic