# DNS Exfiltration — Agent Resolver Spawn With Encoded Query Name After Secret Staging

- **Severity:** High
- **Signature ID:** `9f3c1d7a-4b62-4e58-9a1c-0d6f2b8e5714`
- **MITRE ATLAS:** AML.T0051 (LLM Prompt Injection)
- **OWASP:** LLM01 (Prompt Injection)

## Summary

An AI coding agent's shell access is misused to smuggle secrets out of a network by hiding encoded data inside DNS hostnames. Instead of sending data over normal channels that are watched, the attacker piggybacks it on ordinary-looking DNS lookups.

## How the attack works

An attacker manipulates the AI agent (via prompt injection) to first read or stage sensitive data — credentials, tokens, or other secrets — inside the same command session. That data is then encoded, typically as base64, base32, or hex. Finally, the agent runs a DNS lookup tool such as dig, nslookup, host, or getent, with the encoded data embedded as part of the hostname being resolved. Because the DNS query itself leaves the network, the encoded payload rides out as part of a lookup that looks superficially normal. This detection covers only that final lookup step, corroborated by the earlier staging and encoding activity in the same session — it does not confirm the prompt injection itself or capture the actual DNS traffic on the wire.

## Why it matters

An organization can lose credentials, tokens, or other sensitive data through a channel that is rarely inspected as closely as HTTP or file transfers, and the exfiltration can be dressed up to look like routine DNS resolution.

## What you can do

- Restrict AI agent shell access so it cannot invoke DNS lookup utilities (dig, nslookup, host, drill, getent hosts, resolvectl) directly.
- Monitor DNS query names for unusually long labels, excessive subdomain segmentation, or high-entropy strings that suggest encoded data.
- Ensure secrets and credentials used by automation (including ACME/DNS-01 challenge scripts) are scoped narrowly and not readable by general-purpose agent processes.
- Review any alerts jointly with the session's preceding commands before acting, since legitimate DNS blocklist queries and certificate automation can trigger similar patterns.

## Known benign look-alikes

- DNS blocklist / reputation lookups that hash the subject into the query label (Spamhaus DBL hashblock, URIBL, SURBL) run from a shell in the same session as a base64/cut pipeline — the hex or base64 label plus the encoding stage can satisfy the corroboration bar.
- ACME dns-01 automation and DNS-provider scripts that read an API token from .env / .aws/credentials to publish a challenge and then poll the record with dig; the token read is genuine secret staging and the challenge label is long.
- Security engineers and red teams exercising DNS-exfiltration tooling (dnscat2, dnsteal, iodine, dns2tcp) or CTF/lab exercises on the developer's own machine.
- Debug or CI helper scripts that base64 a config blob and, within the same 5-minute window and process session, run dig/nslookup connectivity checks against long generated hostnames (ephemeral preview environments, per-build review-app DNS names).
- Service-discovery tooling that queries SRV/TXT names built from many stacked labels, executed alongside a credential-reading step for the same service.

## References

- https://attack.mitre.org/techniques/T1071/004/
- https://attack.mitre.org/techniques/T1048/003/
- https://atlas.mitre.org/techniques/AML.T0051
- https://genai.owasp.org/llmrisk/llm01-prompt-injection/

---
Source: https://www.netzilo.com/threats/dns-exfil-resolver-channel