From 5352ffb9d2e97c2d99859c7c214990b8acd6a04b Mon Sep 17 00:00:00 2001 From: HackTricks News Bot Date: Thu, 9 Apr 2026 02:10:35 +0000 Subject: [PATCH] Add content from: Cracks in the Bedrock: Agent God Mode --- .../aws-bedrock-post-exploitation/README.md | 93 +++++++++++++++++++ 1 file changed, 93 insertions(+) diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-bedrock-post-exploitation/README.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-bedrock-post-exploitation/README.md index b620ee9a2..c5c12860d 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-bedrock-post-exploitation/README.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-bedrock-post-exploitation/README.md @@ -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:::memory/*` +- `arn:aws:bedrock-agentcore:::runtime/*` +- `arn:aws:ecr:::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= +aws iam list-role-policies --role-name "$ROLE_NAME" +aws iam get-role-policy --role-name "$ROLE_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= +``` + +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= +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) @@ -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}}