No Way Out? C2 Through AWS Data Perimeter via Bedrock-AgentCore

### Overview In this presentation at Forward CloudSec, Dan Gonzalo, a security researcher at Upwind Security, demonstrates how an undocumented Bedrock AgentCore runtime API and OIDC configuration validation behavior could be combined to establish a stealthy bidirectional command-and-control (C2) channel bypassing AWS's data perimeter controls.

### Key Topics - **Bedrock AgentCore Runtime & Inbound Authentication**: Understanding AgentCore's identity management, including IAM and JWT custom authorizers requiring an OIDC discovery URL (such as Amazon Cognito). - **The Undocumented PRM API**: Discovery of the unauthenticated `Get runtime protected resource metadata` (PRM) endpoint exposed via a `WWW-Authenticate` header upon receiving a 401 error. - **Data Exfiltration Side Channel**: Abusing AWS server-side validation during AgentCore create/update operations to exfiltrate base64-encoded sensitive data embedded within an OIDC discovery URL to an attacker-controlled endpoint. - **Data Infiltration Side Channel**: Using an attacker-controlled AgentCore runtime to serve malicious instructions via unauthenticated PRM API calls, completely unaffected by initial VPC endpoint policies. - **Bypassing the AWS Data Perimeter**: Assessing how both side channels completely evade the three core data perimeter checks (expected network, trusted identity, and trusted resource). - **Detection and Remediation**: Inspecting CloudTrail logs, deploying runtime sensors, and reviewing AWS's fix regarding VPC endpoint policy enforcement.

### Technical Details The attack flow relies on an initial one-time code execution on a compromised workload or developer machine that possesses `create` or `update` agent runtime permissions.

1. **Data Exfiltration via OIDC Discovery Validation**: When an invalid or new configuration is submitted via `update agent runtime`, AWS initiates a server-side HTTP request from its own infrastructure to validate the OIDC discovery endpoint. An attacker crafts a discovery URL pointing to their OIDC server containing base64-encoded exfiltrated data within the path. Because the validation request originates from AWS's network directly to an external HTTP endpoint, it bypasses customer VPC endpoint policies, SCPs, and resource control policies. 2. **Infiltration via Attacker-Controlled Agent Runtime**: While an attacker cannot easily guess the ARN of a victim runtime to pull data directly, they can create their own AgentCore runtime in an attacker-controlled AWS account. Because the PRM API call is unauthenticated and originally bypassed VPC endpoint policies, the compromised victim workload can make an outbound PRM API request to the attacker's runtime ARN across regions, retrieving arbitrary commands (e.g., executing `whoami` or reading from a private S3 bucket). 3. **Weaponized C2**: Pairing these channels creates a functional reverse shell. Dan demonstrated executing commands and exfiltrating up to 30 kilobytes of data from a private bank S3 bucket.

### Takeaways Following responsible disclosure, AWS acknowledged Dan's research and updated the PRM API so it is now subject to VPC endpoint policy enforcement, allowing organizations to block unapproved outbound PRM calls and break the C2 infiltration channel. However, the exfiltration behavior remains by design across several AWS services that validate external endpoints. Organizations must enforce least privilege on AgentCore runtime configuration permissions, monitor CloudTrail for unusual AgentCore update frequencies and non-standard OIDC URLs, and deploy workload runtime sensors to inspect outbound PRM calls pointing to foreign AWS account IDs.