Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -130,11 +130,101 @@ The core issue is that the backend lets the model decide **who may do what** by
- Treat each collaborator as a separate trust boundary: scope action groups narrowly, validate tool inputs in the backend, and require server-side authorization before high-impact actions.
- Bedrock **pre-processing** can reject or classify suspicious requests before orchestration, and **Guardrails** can block prompt-injection attempts at runtime. They should be enabled even if prompt templates already contain “do not disclose” rules.

## AWS - AgentCore Runtime Role Wildcards -> Cross-Agent Compromise

### Overview

Some AgentCore deployment workflows auto-create a runtime execution role for each agent. If that role is generated with wildcard resource ARNs instead of being pinned to the agent's own runtime, memory, and ECR repository, compromising one agent identity can break isolation across other agents in the same AWS account.

This is a **post-compromise abuse path caused by insecure IAM defaults / bad scoping**, not a Bedrock memory corruption bug.

### Why this matters

The dangerous pattern is a runtime role that can access peer-agent resources such as:

- `arn:aws:bedrock-agentcore:<region>:<account>:memory/*`
- `arn:aws:bedrock-agentcore:<region>:<account>:runtime/*`
- `arn:aws:ecr:<region>:<account>:repository/*`

With that scope, a compromised low-value agent can often:

- pull container images from other agents or unrelated workloads
- recover internal identifiers and configuration from those images
- read or poison another agent's memory if the target `MemoryID` is known
- invoke peer runtimes to expand blast radius

### Recon: identify the isolation break

Review the runtime execution role attached to the compromised agent and look for wildcard access in inline or attached policies:

```bash
ROLE_NAME=<runtime_role_name>
aws iam list-role-policies --role-name "$ROLE_NAME"
aws iam get-role-policy --role-name "$ROLE_NAME" --policy-name <policy_name>
aws iam list-attached-role-policies --role-name "$ROLE_NAME"
```

High-signal findings:

- `bedrock-agentcore:GetMemory`, `bedrock-agentcore:RetrieveMemoryRecords`, `bedrock-agentcore:CreateEvent`, `bedrock-agentcore:DeleteMemoryRecord` on `memory/*`
- `bedrock-agentcore:InvokeAgentRuntime` on `runtime/*`
- `ecr:GetAuthorizationToken`, `ecr:BatchGetImage`, `ecr:GetDownloadUrlForLayer` on wildcard ECR scope

### Exploitation chain

#### 1. Exfiltrate a target agent image from ECR

If the runtime role can pull from arbitrary ECR repositories, use the normal ECR post-exploitation flow to download the victim agent image:

{{#ref}}
../aws-ecr-post-exploitation/README.md
{{#endref}}

After pulling the image, inspect the filesystem and environment artifacts for agent-specific identifiers and secrets.

#### 2. Extract the target `MemoryID`

In the Unit 42 case, the pulled image exposed a file like `env-output.txt` containing:

```text
BEDROCK_AGENTCORE_MEMORY_ID=<victim_memory_id>
```

Any baked-in config file, environment export, startup script, or application log containing the target memory identifier turns memory access from guesswork into a deterministic step.

#### 3. Read or poison the target agent memory

Once the target `MemoryID` is known and the compromised role already has wildcard memory access, dump conversation state or tamper with it:

```bash
MEMORY_ID=<victim_memory_id>
aws bedrock-agentcore get-memory --memory-id "$MEMORY_ID"
aws bedrock-agentcore retrieve-memory-records --memory-id "$MEMORY_ID"
```

If the same role also has write/delete event or memory-record permissions, the target agent's long-term context can be modified to influence future behavior.

#### 4. Invoke peer runtimes

If `bedrock-agentcore:InvokeAgentRuntime` is granted on `runtime/*`, any compromised agent can trigger execution of peer agents. This becomes more dangerous when chained with memory poisoning or when the invoked agent has access to more sensitive tools or datasets.

### Notes

- This technique is different from the standalone **Code Interpreter execution-role pivot** documented here:

{{#ref}}
../../aws-privilege-escalation/aws-bedrock-privesc/README.md
{{#endref}}

- The key post-exploitation idea here is **cross-agent lateral movement through overly broad runtime-role scoping**, with ECR exfiltration used to recover the identifiers needed to target another agent's memory.
- AWS documentation now explicitly warns that the auto-created AgentCore IAM policies are for **development/testing**, not production. In production, restrict each agent role to its exact runtime, memory, interpreter, and repository resources.


## References

- [When AI Remembers Too Much – Persistent Behaviors in Agents’ Memory (Unit 42)](https://unit42.paloaltonetworks.com/indirect-prompt-injection-poisons-ai-longterm-memory/)
- [When an Attacker Meets a Group of Agents: Navigating Amazon Bedrock's Multi-Agent Applications (Unit 42)](https://unit42.paloaltonetworks.com/amazon-bedrock-multiagent-applications/)
- [Cracks in the Bedrock: Agent God Mode (Unit 42)](https://unit42.paloaltonetworks.com/exploit-of-aws-agentcore-iam-god-mode/)
- [Retain conversational context across multiple sessions using memory – Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-memory.html)
- [How Amazon Bedrock Agents works](https://docs.aws.amazon.com/bedrock/latest/userguide/agents-how.html)
- [Advanced prompt templates – Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/advanced-prompts-templates.html)
Expand All @@ -143,5 +233,8 @@ The core issue is that the backend lets the model decide **who may do what** by
- [Monitor model invocation using CloudWatch Logs and Amazon S3 – Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/model-invocation-logging.html)
- [Track agent’s step-by-step reasoning process using trace – Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/trace-events.html)
- [Amazon Bedrock Guardrails](https://aws.amazon.com/bedrock/guardrails/)
- [Runtime permissions - Amazon Bedrock AgentCore](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-permissions.html)
- [Get started with the Amazon Bedrock AgentCore starter toolkit in Python](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-get-started-toolkit.html)
- [Bedrock AgentCore starter toolkit source](https://github.com/aws/bedrock-agentcore-starter-toolkit)

{{#include ../../../../banners/hacktricks-training.md}}