No malware. No stolen credentials. No exploit chain. Someone registered a piece of phone-routing DNS that nobody owned, and by the next day their system held records of hundreds of thousands of calls to US military bases. Nothing about it required attacking anyone, which is exactly why it should worry you.
What actually happened, and what did not
Security practitioner Wiktor Stefański summarized the incident on LinkedIn after it spread through an r/cybersecurity thread :
"No hack. No breach. Just a bit of DNS that nobody owned, so they registered it."
The registrant claimed an orphaned record in the phone system's routing infrastructure, and call detail records for US military bases started arriving the following day. Stefański links a fuller write-up, but public detail beyond his summary is thin, so treat the finer points as reported rather than independently confirmed. The shape of the failure is clear, though, and it matches a class of accident telecom people have warned about for years.
Before going further, let me clear out what this story is not, because the coverage keeps blending it with unrelated incidents. It has nothing to do with the UC San Diego and University of Maryland researchers who pulled unencrypted calls and military traffic off satellite backhaul with under $800 of equipment. It is not the CMI Management open directory that left more than 70,000 Army files unauthenticated for over a year. It is not the 500-plus UK service members exposing base locations through Strava. Those are separate failures with separate lessons. This one is about DNS and call metadata, full stop.
How one DNS record ends up with your call logs
Telephony runs on name lookups
Most people picture phone calls as wires and switches. Modern telephony is DNS lookups all the way down. When a call routes over SIP, proxies resolve NAPTR, SRV, and A records to find the next hop for a domain. ENUM goes further and maps telephone numbers themselves into DNS under e164.arpa, so routing a number range can depend on a delegation someone set up during a migration years ago. Separately, every session border controller and softswitch generates call detail records and exports them, over RADIUS accounting, syslog, or SFTP, to a hostname typed into a config file by an engineer who may have left in 2019.
Control the name, and you control where the traffic or the logs go. That is the whole trick.
Records lose owners quietly
The paths to orphanhood are boring. A carrier migrates platforms and the old domain lapses. A vendor contract ends, the hosted SBC is decommissioned, but a CNAME still points at it. A test number block gets an ENUM delegation that nobody deletes. Expired telephony domains get scooped up in bulk by drop-catchers, because domains with residual traffic are valuable to parkers and researchers alike. The registrant in this case appears to have claimed the record and then disclosed what landed, which is the friendly version of this story. The unfriendly version never writes a blog post.
The organizational seam makes it worse. Telecom config belongs to one team, DNS to another, the vendor contract to procurement. Nobody owns the record in the middle, so nobody renews it.
Why it scales, and why it persists
A single routing record can front an entire number block. That is how one registration produces hundreds of thousands of call records overnight instead of a trickle. And because vendor logging is on by default, the CDR stream exists whether anyone asked for it or not. Nothing pages when a log destination changes hands. Calls kept completing. The only symptom was data arriving somewhere new.
Stefański's warning is the one to pin to the wall:
"One misconfigured record at your VoIP provider and the metadata (who called who, when, how long) can sit in a stranger's log file for months."
The metadata is the product
"No content" is a weak comfort
The fastest way to lose an argument about metadata is to look at what states actually collect. The 2013 disclosures showed the FISA Court ordering a Verizon subsidiary to hand over logs for all customer calls. PRISM, running since 2007, was described in leaked documents as "the number one source of raw intelligence used for NSA analytic reports" and accounted for 91% of NSA internet traffic acquired under Section 702. Governments spent enormous budgets obtaining exactly this class of data. Nobody does that for information with no intelligence value.
Metadata also analyzes better than content. It is structured, it scales, and it does not need translation. A month of CDRs yields a cleaner network graph than a year of intercepted audio.
What an analyst reads in base call records
Put yourself on the other side of this dataset. Call volume to a base's main line and family support offices has a rhythm, and changes in that rhythm track operational tempo. A sustained uptick in off-hours traffic often precedes exercises or deployments. Recurring calls between a base and specific logistics firms, fuel suppliers, or medical providers sketch the support structure around it, including relationships that were never public. Calling trees between command numbers reveal who is on call and how escalation actually flows. You can reconstruct a working org chart without hearing a single word.
For a military base, the pattern is the secret. The content of the calls is almost secondary.
The two objections I hear
First: "Nobody listened to anything, so where is the harm?" Covered above, but add the irreversibility problem. Once a stranger holds months of your traffic patterns, takedown requests do not rewind analysis already done. Stefański put it bluntly: "You can't put privilege back on a leak."
Second: "We are not a military base." Same plumbing. Your calls traverse the same SIP and ENUM infrastructure, and your VoIP provider has the same class of record. Merger talks, layoff planning, litigation strategy, and your real customer list are all visible in call patterns to anyone holding your CDRs. The failure mode is generic even if this headline was not.
Audit your own call path this week
Map every name the phone system trusts
Pull the hostnames out of your SBC and PBX configs (proxy, registrar, outbound trunk), your provider portal settings, voicemail-to-email relays, RADIUS accounting targets, and every CDR export destination. Then resolve all of them:
dig SRV _sip._udp.yourdomain.com
dig NAPTR 1.2.3.4.5.5.5.1.2.0.2.e164.arpa
# Flag anything in your inventory that no longer resolves
while read -r name; do
ips=$(dig +short "$name" A)
[ -z "$ips" ] && echo "UNRESOLVED: $name" || echo "$name -> $ips"
done < telephony-dns.txtVerify what each name resolves to today, not what the config author intended when they wrote it. In other words, check the socket, not the installer. Any hostname landing outside your or your carrier's known netblocks is an incident, not a curiosity.
Verify ownership like it matters
Check expiry on every domain in the call path and lock them down:
curl -s "https://rdap.org/domain/yourdomain.com" \
| jq '.events[] | select(.eventAction=="expiration")'Decision rules I use: auto-renew plus registrar lock on anything routing-critical, expiry alerts at 90, 60, and 30 days, and multi-year registration for domains fronting number blocks. Also monitor the records themselves for drift, because silent changes in trusted infrastructure do not raise dashboard warnings on their own. We saw the same dynamic in the miniOrange SAML forgery bugs: the trust layer fails quietly, so the check has to be something you built, not something you assumed.
Put the CDR stream under governance
Know where your records are born: the SBC, the carrier, the billing platform. Set retention by policy rather than vendor default, and most organizations need months for billing disputes and abuse investigations, not indefinite archives. Access should be named accounts with MFA and logged reads. Then follow the egress: where do exports go, who owns that hostname, when does its domain expire. One more detection worth building: alert on a sharp drop in daily CDR volume at your collector. A silent falloff can mean the stream found a new home.
Ask your provider the one question
Stefański's recommended question for any IT provider is the right place to start:
"Who owns our phone-routing DNS records, and when did we last check them?"
Add two follow-ups: show me the export path for our CDRs, and tell me what you log, where it lives, and how long you keep it. Get the answers in the contract.
If you find a dangling record
The order matters: contain first (reclaim or repoint the record), scope second (how long was it unowned, what flowed where), notify third. It is the same triage logic as the first hour of a supply-chain alert. And a caution from the separate CMI case: a researcher reported that exposure to US-CERT in 2024 and the data reportedly stayed up anyway. Reporting is not remediation. Verify closure yourself.
This class of failure sits in the gap between annual tests, in the DNS records and log pipelines nobody re-examines after go-live. If that gap is familiar, Axeploit's pentest workflow is built to keep coverage continuous rather than yearly. The next orphaned record will not wait for your assessment cycle.
Key takeaways
- An unowned phone-routing DNS record funneled logs of hundreds of thousands of calls to US military bases to a stranger, with no hack involved. The failure was asset management, not adversary sophistication.
- Call metadata without content still exposes staffing rhythms, supplier relationships, and command structure. Bulk telephony metadata was a flagship state collection target for a reason.
- One record can front an entire number block, and nothing alerts when a log destination changes hands, so exposures persist for months.
- This week: inventory every hostname your telephony stack trusts, confirm each domain's ownership and expiry, and follow your CDR stream to its final destination.
- Ask your provider who owns the phone-routing DNS records and when they last checked. Put CDR handling in the contract.
