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

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

Speakers: Dan Gansel, Security Researcher, API Security

Conference: fwd:cloudsec

YouTube: https://www.youtube.com/watch?v=uk1kXYELPao

Overview

In this insightful talk from fwd:cloudsec, Dan Gansel, a security researcher at API Security, unveiled a sophisticated command and control (C2) channel that could bypass AWS's stringent Data Perimeter controls. The research, titled "No Way Out? C2 Through AWS Data Perimeter via Bedrock-AgentCore," demonstrated how a combination of an undocumented API and an intended design behavior within AWS Bedrock Agent Core could be abused to exfiltrate sensitive data and establish bidirectional C2, even in highly protected AWS environments. This talk highlights a critical challenge for cloud security: the potential for seemingly innocuous or undocumented service features to be weaponized against robust security postures.

Gansel's presentation meticulously detailed two distinct side channels. The first facilitated data exfiltration by leveraging a server-side request from AWS infrastructure to an attacker-controlled endpoint during the validation of an agent's configuration. The second, a data infiltration channel, exploited an unauthenticated, previously undocumented API within Bedrock Agent Core, enabling attackers to deliver commands to compromised workloads. The convergence of these two channels created a fully functional C2 mechanism, proving particularly problematic because it circumvented the AWS Data Perimeter model, which is designed to prevent such cross-organizational data flows.

The significance of this research lies in its demonstration that even AWS's "best available defense against data exfiltration and C2 channels" can be bypassed by understanding the subtle interactions and underlying mechanisms of newly introduced services. As AI services like Bedrock rapidly integrate into enterprise cloud environments, this talk serves as a crucial reminder for organizations to thoroughly assess the security implications of these complex platforms and their peripheral components, rather than solely focusing on the AI models themselves.

Background

▶ Watch: Introduction to talk and speaker Dan Gansel (0:00)

The genesis of this research began with Dan Gansel's observation of an unusual API mentioned in an AWS blog post about Bedrock Agent Core runtime's inbound authentication. Specifically, a 401 error response message section contained a reference to a peculiar API: get runtime protected resource metadata API (PRM API). What made this API stand out was its complete absence from any official AWS documentation or API reference guides, immediately raising a red flag for a security researcher. This undocumented nature, coupled with its appearance in an authentication context, hinted at a potential oversight or an internal-facing API that might have unintended external exposure.

AWS Bedrock Agent Core is AWS's suite for building AI agents, designed to orchestrate various components, including observability tooling and, crucially for this research, identity management. It supports both AWS Identity and Access Management (IAM) and JWT custom authorizer options for inbound authentication. To enable the JWT custom authorizer, developers must configure a discovery URL, typically pointing to an OpenID Connect (OIDC) provider like Cognito, Auth0, or Okta. This discovery URL is fundamental to how Bedrock Agent Core validates JWT tokens by fetching the necessary metadata from the OIDC server. The core problem this talk addresses stems from how AWS's internal validation mechanisms for this discovery URL, combined with the behavior of the undocumented PRM API, could be manipulated to achieve stealthy C2.

Key Findings

▶ Watch: Background: Bedrock Agent Core, identity management, JWT (2:00)

Dan Gansel's research uncovered two critical side channels within AWS Bedrock Agent Core that, when chained together, formed a robust Command and Control (C2) mechanism capable of bypassing AWS Data Perimeter controls.

1. Data Exfiltration Channel (Server-Side Request Forgery via UpdateAgentRuntime):

• Mechanism: When an AWS Bedrock Agent is created or updated, if a developer configures an invalid discovery URL (e.g., one that doesn't point to a legitimate OIDC provider), AWS's Bedrock Agent Core service performs a server-side request from its own infrastructure to validate this URL.
• Abuse: An attacker with one-time code execution on a victim's workload (and the create or update agent runtime permission) can set this discovery URL to an attacker-controlled OIDC server. By embedding sensitive data, typically Base64 encoded, into the URL path (e.g., https://attacker.com/sensitive_data_b64/required_suffix), the server-side validation request from AWS's internal network inadvertently exfiltrates this data to the attacker's server.
• Impact: This bypasses VPC endpoint policies because the request originates from AWS's internal network, not the victim's VPC. It also circumvents identity-based controls as it's an unauthenticated HTTP request from the AWS service itself.

1. Data Infiltration Channel (Undocumented, Unauthenticated PRM API for Command Delivery):

• Mechanism: Gansel discovered an undocumented and unauthenticated API: get runtime protected resource metadata API (PRM API). When an unauthenticated request is sent to an agent runtime, it returns a WWW-Authenticate header containing a Protected Resource Metadata URL (PRM URL). Calling this PRM URL (which ends with /oauth2/protected_resource) returns authorization server data, derived from the agent's configured discovery URL.
• Abuse: Initially, calling this API on a victim's agent required knowing its Agent Resource Name (ARN), which includes the victim's account ID and region – non-trivial knowledge for an attacker. Gansel's innovative solution was for the attacker to deploy their own Bedrock Agent Runtime in various regions. Since the attacker controls this runtime, they know its ARN. The attacker configures their agent's discovery URL to point to an attacker-controlled OIDC server that, when queried via the PRM API, returns malicious commands as part of the authorization server data.
• Impact: A compromised victim workload, instead of making an API call to its own agent, calls the PRM API against the attacker's controlled agent runtime. Because the PRM API is unauthenticated and not bound by VPC endpoint policies (at the time of discovery), the victim's workload can retrieve commands from the attacker's infrastructure.

Combined C2 and Data Perimeter Bypass:

The crucial finding is that these two channels, when combined, create a full bidirectional C2. The victim receives commands via the unauthenticated PRM API (infiltration) and sends back command output or sensitive data via the server-side request forgery during UpdateAgentRuntime (exfiltration). Both channels were found to bypass AWS's Data Perimeter model, which relies on three conditions (network expected, identity trusted, resource trusted) and three mechanisms (SCPs, VPC endpoint policies, resource-based policies). The server-side request from AWS's network for exfiltration, and the unauthenticated nature of the PRM API for infiltration, rendered these Data Perimeter controls ineffective.

Technical Deep Dive

▶ Watch: Discovery of unauthenticated Protected Resource Metadata (PRM) API (3:15)

The technical core of this research revolves around the interplay of an undocumented API and a specific server-side validation behavior within AWS Bedrock Agent Core.

Discovery of the PRM API

The initial breakthrough came from a blog post discussing 401 error responses from the Agent Core runtime. This blog mentioned an API, get runtime protected resource metadata API, which was conspicuously absent from all official AWS documentation. This hinted at an internal or unadvertised endpoint.

Gansel's methodology to understand this API involved sending an unauthenticated request (i.e., without an Authorization header) to an Agent Core runtime invocation URL. In response, the runtime returned a WWW-Authenticate header. This header contained a Protected Resource Metadata URL (PRM URL), typically ending with /oauth2/protected_resource. When a curl request was made to this PRM URL, it returned authorization server data. This data was essentially the configured discovery URL of the agent, minus the /oauth2/protected_resource suffix. This confirmed the existence of an unauthenticated API that exposed configuration details.

Data Exfiltration Channel: SSRF via UpdateAgentRuntime

The first functional side channel leverages a server-side request forgery (SSRF) vulnerability disguised as an intended validation mechanism.

When configuring a Bedrock Agent Core, developers must specify a discovery URL for JWT custom authorizers. If this URL is malformed or invalid, Bedrock Agent Core will return an error message: "ODIC discovery endpoint is not valid." This error, however, is a result of AWS's internal infrastructure attempting to validate the provided URL by making a server-side HTTP request to it.

The attack flow is as follows:

1. Prerequisite: An attacker gains one-time code execution on a victim's workload or developer machine. This workload must have the create or update agent runtime IAM permission. This is a common scenario in supply chain attacks or compromised credentials.
2. Payload Crafting: The attacker crafts a malicious discovery URL that points to an attacker-controlled OIDC server. Crucially, this URL includes sensitive data (e.g., whoami output, PII, AWS credentials) Base64 encoded within its path. For example: https://attacker.com/exfil_data_b64_encoded_sensitive_info/oauth2/protected_resource. An optional prefix can be added to differentiate command outputs.
3. API Call: The compromised victim workload calls the UpdateAgentRuntime API, passing the malicious discovery URL as part of the agent's configuration.
4. Server-Side Request: AWS's Bedrock Agent Core service, in an attempt to validate the discovery URL, makes an HTTP request from its own internal infrastructure to the attacker-controlled endpoint.
5. Data Exfiltration: The attacker's server receives this request, and because the sensitive data was embedded in the URL path, it is effectively exfiltrated. The ODIC discovery endpoint is not valid error is returned to the victim, but the data has already left the network.

This exfiltration method is particularly potent because the server-side request originates from AWS's network, not the victim's VPC. This means it bypasses VPC endpoint policies, which are designed to control outbound traffic from the VPC to AWS services. Furthermore, since it's an unauthenticated HTTP request from the AWS service, it also bypasses organizational guardrails (SCPs) and resource-based policies that rely on identifying a trusted identity or resource.

Data Infiltration Channel: PRM API for C2

The exfiltration channel provides a way to send data out, but for a full C2, an attacker also needs a way to send commands in. The previously discovered unauthenticated PRM API fills this gap.

The initial challenge was that to use the PRM API against a victim's agent, the attacker would need to know the victim's Agent ARN, which includes their account ID and region. This is generally not public knowledge. Gansel's ingenious solution was to flip the model:

1. Attacker-Controlled Agent: The attacker deploys their own Bedrock Agent Runtime in an AWS account they control. They can deploy these in multiple regions to ensure availability.
2. Known ARN: Since the attacker controls this agent, they know its full ARN (e.g., arn:aws:bedrock:us-east-1:123456789012:agent/XYZ).
3. Malicious OIDC Server: The attacker configures their agent's discovery URL to point to an attacker-controlled OIDC server. This server is specifically designed to return malicious commands when queried by the PRM API.
4. Victim Infiltration: The compromised victim workload, instead of calling its own agent's PRM API, is instructed to call the PRM API against the attacker's controlled agent runtime ARN.
5. Command Delivery: Because the PRM API is unauthenticated and, at the time of discovery, was not enforced by VPC endpoint policies, the victim's workload successfully retrieves the "authorization server data" which, in this case, is the malicious command embedded by the attacker.

This infiltration path also bypassed VPC endpoint policies because the PRM API was not bound by them. It had no identity by feature (unauthenticated), and the attacker's resource (their agent) had no resource-based policy relevant to the victim's egress.

Data Perimeter Bypass Explained

AWS's Data Perimeter model aims to enforce three conditions for every API call:

1. Network Expected: Is the request coming from one of my networks?
2. Identity Trusted: Is the request coming from one of my organizational identities?
3. Resource Trusted: Is the request intended for one of my organizational resources?

It uses three mechanisms:

• Service Control Policies (SCPs): Organizational guardrails on identities.
• VPC Endpoint Policies: Control outbound traffic to AWS services.
• Resource-Based Policies: Restrict access to resources.

Exfiltration Path Bypass:

• Network Expected: Yes, because the victim's workload is compromised and initiates the UpdateAgentRuntime call from the victim's network.
• Identity Trusted: Yes, the call uses the victim's trusted identity.
• Resource Trusted: Yes, the call is against the victim's agent resource.
• The critical bypass occurs behind the scenes: AWS makes a server-side request from its own network to the attacker's endpoint. This request is not subject to the victim's VPC endpoint policies, has no identity (just an HTTP request), and targets an attacker-controlled resource, rendering Data Perimeter ineffective for the actual data transfer.

Infiltration Path Bypass:

• VPC Endpoint Policies: Not bound by them (at the time of discovery).
• Identity: No identity by feature, as the PRM API is unauthenticated.
• Resource-Based Policy: The PRM API has no resource-based policy. Even if it did, the attacker controls their own agent and its policies.

In summary, both channels exploit fundamental characteristics—server-side requests originating from AWS's internal network and an unauthenticated API—to completely circumvent the Data Perimeter's intended protections.

Demo / Proof of Concept

▶ Watch: New threat scenario: Achieving bidirectional command and control (7:00)

Dan Gansel demonstrated a full, bidirectional Command and Control (C2) channel in a simulated highly protected AWS banking environment. The demo illustrated the practical impact of chaining the data exfiltration and infiltration channels.

The setup involved:

1. An attacker-controlled endpoint (an AWS Lambda function acting as both a command server and an OIDC server).
2. An attacker-controlled agent runtime deployed in the attacker's AWS account.
3. A victim workload (representing a compromised machine within the bank's AWS environment) with the necessary create or update agent runtime permissions.

The demonstration began by showing the victim workload receiving a command. The whoami command was chosen as a simple, impactful initial command.

• The victim workload initiated a call to the PRM API of the attacker's agent runtime.
• The attacker's Lambda (acting as the OIDC server) responded with the whoami command embedded in the "authorization server data" returned by the PRM API.
• The victim workload executed whoami.
• To exfiltrate the output, the victim workload then called the UpdateAgentRuntime API, configuring its own agent with a malicious discovery URL. This URL contained the Base64-encoded output of the whoami command (e.g., arn:aws:iam::123456789012:user/compromised-user).
• AWS's internal infrastructure made a server-side request to the attacker's Lambda (acting as the OIDC server), effectively exfiltrating the whoami output. The Lambda's logs confirmed receipt of the whoami output.

To further illustrate the impact, Gansel escalated the demonstration to exfiltrate sensitive data from a private S3 bucket belonging to the bank.

• A command to read data from the private S3 bucket was delivered via the PRM infiltration channel.
• The victim workload executed this command, retrieving data from the bank's S3 bucket.
• The retrieved sensitive data (demonstrated as 30 kilobytes) was then Base64 encoded and exfiltrated to the attacker's Lambda via the UpdateAgentRuntime server-side request forgery.
• The attacker's Lambda successfully received and logged the 30KB of sensitive data, demonstrating a significant breach of confidentiality even within a Data Perimeter-protected environment.

The demo clearly established that an attacker could achieve continuous, bidirectional C2, executing arbitrary commands and exfiltrating data, all while bypassing AWS Data Perimeter controls.

Defensive Implications

▶ Watch: Overcoming PRM ARN obstacle for data infiltration and C2 (7:50)

This research carries significant defensive implications, particularly for organizations operating under stringent security controls like AWS Data Perimeter. While AWS has taken some action, a critical exfiltration path remains.

1. AWS Fix for Infiltration Channel:

• PRM API Enforcement: AWS has addressed the infiltration channel by enforcing VPC endpoint policies on the PRM API calls. This means that customers can now configure their VPC endpoint policies to deny outbound calls to unknown or untrusted Bedrock Agent ARNs.
• Action Required: Defenders must ensure their VPC endpoint policies are correctly configured to explicitly allow traffic only to their own organizational Bedrock Agent Runtimes and deny all others. Without the appropriate "allow" policy, the fix will not prevent infiltration attempts to attacker-controlled agents.

1. Exfiltration Channel (SSRF via UpdateAgentRuntime) - "By Design":

• Unfixed Behavior: Crucially, the data exfiltration path, which leverages the server-side request from AWS's infrastructure during UpdateAgentRuntime validation, remains unfixed. AWS has stated this behavior is "by design" and is consistent across other services where server-side validation requests are made to arbitrary URLs.
• Defender Challenge: This means that if an attacker gains the create or update agent runtime permission on a workload, they can still exfiltrate data from within a Data Perimeter by embedding it in a malicious discovery URL. This path will continue to bypass VPC endpoint policies.

1. Detection Mechanisms (CloudTrail Indicators):

• CreateOrUpdateAgent API Calls: Defenders should monitor CloudTrail logs for the CreateAgent and UpdateAgent API calls.
• Unusual Frequency: These API calls should not occur with high frequency. An unusual spike could indicate malicious activity.
• Discovery URL Content: Scrutinize the discoveryUrl parameter within these API calls. Legitimate discovery URLs should point to well-known OIDC providers (e.g., Cognito, Auth0, Okta, accounts.google.com). Any URL pointing to an unknown domain, an IP address, or containing suspicious looking Base64 encoded data should be investigated immediately.
• Base64 Data: Implement detection rules to specifically look for Base64 encoded strings within the discoveryUrl path, as this is a primary indicator of data exfiltration.

• PRM API Calls (Infiltration) - No CloudTrail: Unfortunately, **PRM API calls are not logged in CloudTrail**. This makes direct detection of infiltration attempts via CloudTrail impossible.
• Runtime Sensors: As an alternative, defenders should deploy runtime sensors on their workloads. These sensors can inspect outbound HTTP requests made by applications.
• ARN Validation: Specifically, the sensor should monitor for outbound requests to Bedrock Agent PRM URLs. If such a request is detected, the sensor should parse the Agent ARN contained within the URL and validate the account ID against a list of allowed, organizational account IDs. Any request to a PRM URL belonging to an external or unknown account ID should trigger an alert.

1. General Security Best Practices:

• Least Privilege: Enforce strict least privilege for all IAM roles and users. Workloads should only have the absolute minimum permissions required for their intended function. The create or update agent runtime permission is a powerful one and should be tightly controlled.
• Careful Assessment of New Services: As new AI services like Bedrock are rapidly adopted, organizations must perform thorough security assessments of all their components, not just the AI models themselves. The risk often lies in the underlying identity, networking, or configuration management features.
• Intended Functionality Abuse: This research underscores that "intended functionality" can be abused to bypass security controls. Security teams must think adversarially and consider how legitimate service behaviors could be weaponized.

In conclusion, while AWS has patched the infiltration vector, the exfiltration path remains a significant concern, requiring proactive detection and vigilant monitoring from defenders.

Key Takeaways

• Undocumented APIs Pose Risk: The initial discovery of the get runtime protected resource metadata API (PRM API) highlights that undocumented or internal APIs can have significant security implications if exposed or misused.
• Data Perimeter Bypass Achieved: A sophisticated C2 channel was demonstrated that successfully bypassed AWS Data Perimeter controls, which are designed to prevent data exfiltration and cross-organizational C2. This was achieved by exploiting server-side requests originating from AWS's internal network and an unauthenticated API.
• Infiltration Channel Fixed, Exfiltration Remains: AWS fixed the PRM API issue, now enforcing VPC endpoint policies on its calls, which breaks the infiltration part of the C2 if policies are correctly configured. However, the data exfiltration path via server-side request forgery during UpdateAgentRuntime validation is considered "by design" and remains unpatched.
• Vigilant CloudTrail Monitoring is Crucial: Defenders must actively monitor CloudTrail logs for CreateAgent and UpdateAgent API calls, specifically looking for unusual frequencies, suspicious discoveryUrl content, and Base64 encoded data within URLs.
• Runtime Sensors for PRM API Detection: Since PRM API calls are not logged in CloudTrail, runtime sensors are necessary to monitor outbound traffic from workloads, validate the account ID in any PRM API call's ARN, and alert on requests to non-organizational Bedrock Agents.
• Least Privilege and New Service Assessment: Strict adherence to least privilege is vital to minimize the impact of compromised workloads. Furthermore, organizations must conduct thorough security assessments of new services, especially rapidly adopted AI platforms, focusing not just on the core AI functionality but also on underlying identity, networking, and configuration components.

About the Speaker(s)

Dan Gansel is a Security Researcher at API Security, based in Tel Aviv, Israel. His work focuses on uncovering vulnerabilities and improving the security posture of various systems, particularly in the cloud and API domains. A fun fact mentioned during his talk is that he has been learning German on Duolingo for over five years, showcasing his dedication to learning and mastering complex systems, whether languages or security architectures. His research on AWS Bedrock Agent Core exemplifies his expertise in diving deep into cloud service internals to identify potential attack vectors.