# New Developments in LLM Hijacking Activity

Compromised AWS IAM access keys were used to invoke Bedrock LLMs; attacker then created new IAM users and Bedrock policies for persistence, blocked by SCPs.

- Payout: Real-world hack
- Severity: medium
- Program: AWS Bedrock
- Analysis by: Wiz Research
- Disclosed: 2024-12-15
- Write-up quality: 6/10
- Original: https://www.wiz.io/blog/jinx-2401-llm-hijacking-aws
- Library page: https://bugbountylibrary.com/r/blog%3Awiz-io-blog-jinx-2401-llm-hijacking-aws
- Tags: area:cloud domain:cloud impact:funds-loss impact:internal-access kind:incident platform:threat-intel sev:medium tech:aws technique:recon vuln:misconfiguration vuln:privilege-escalation vuln:secrets-leak

**Target:** AWS IAM users and Bedrock model invocation APIs
**Root cause:** Leaked/compromised IAM user access keys (AKIA) granted initial access; overly permissive IAM users (including AdministratorAccess) allowed creation of new IAM users, keys, and Bedrock-permissioned policies for persistence.
**Steps:**
1. Attacker obtains compromised IAM user access keys (AKIA) and authenticates from Proton VPN IPs.
2. Calls `bedrock:InvokeModel` against models like `anthropic.claude-3-sonnet-20240229-v1:0`; attempts fail.
3. Uses IAM permissions to call `CreateUser` and `CreatePolicy` (policy named `New_Policy` granting `bedrock:InvokeModel`, `bedrock:InvokeModelWithResponseStream`, `bedrock:GetModelInvocationLoggingConfiguration` on `*`), plus `CreateAccessKey`.
4. Creates console profile for new user and calls `PutUseCaseForModelAccess` to complete LLM agreement.
5. Calls `CreateFoundationModelAgreement` to request model access; blocked by SCPs.
6. Retries `InvokeModel` with new credentials; blocked by SCP.
7. Repeats with two more IAM users matching regex `^[A-Z][a-z]{5}[0-9]{3}$`; all fail.
**How found:** Threat hunting for known LLM abuse techniques plus honeypot IOC analysis surfaced an IAM user on a Proton VPN IP making repeated failed InvokeModel calls; error messages revealed follow-on CreateUser/CreatePolicy attempts, and the same pattern was then searched across other AWS environments.
**Exploitation:** With compromised IAM keys, attacker attempted to invoke Bedrock models to monetize unauthorized LLM access. Where the IAM user had AdministratorAccess, they created persistence via new IAM users/keys and a Bedrock-permissioned policy, then tried to complete model access agreements via console. All invocation attempts were ultimately blocked by Service Control Policies.
**Escalation:** Pivoted from a single compromised IAM user to creating new IAM users, access keys, and a custom Bedrock policy to persist and expand LLM access.
**Insight:** Failed API error messages (AccessDenied on InvokeModel) reveal attacker intent and follow-on IAM enumeration/creation attempts; hunt for IAM users with consistent naming regexes and custom policies scoped to LLM invoke actions, and check for PutUseCaseForModelAccess console calls as a signal of model-agreement abuse.

## Proof of concept (copied exactly from the original report)

**IAM policy granting Bedrock invoke permissions**

```
{ "Effect": "Allow", 
 "Resource": "*", 
 "Action": ["bedrock:InvokeModel", 
 "bedrock:InvokeModelWithResponseStream", 
 "bedrock:GetModelInvocationLoggingConfiguration"] 
}
```

**Attacker IAM username regex pattern**

```
The IAM username matched the following regex: ^[A-Z][a-z]{5}[0-9]{3}$. 

- The IAM policy name was `New_Policy`, and included the following permissions:
```