Skip to content

Guides · Domain registration

Expired Domains as an Attack Path: What to Monitor

Lapsed nameserver, script and SPF domains let anyone who registers them take over your traffic. Real 2026 cases and the dependencies to watch.

Updated 14 November 2026 · 7 min read

Most teams track when their own domains expire. Far fewer track the domains their infrastructure depends on: the nameserver host in an NS record, the domain in a <script src>, the vendor in an SPF include:. When one of those lapses, anyone can register it, and whoever holds it inherits the trust you gave it.

Two incidents reported this month show the pattern from two sides.

Case 1: Government nameservers on an unregistered domain

On November 8, 2026, researcher Antonio Cheong published a write-up about South Korea's National Cyber Security Center (ncsc.go.kr). His logs from September 2026 show the zone's NS records pointing at three names: ns.ncsc.go.kr, ns1.aegis-k.com and ns2.aegis-k.com. An RDAP lookup for aegis-k.com in his log returns Object not found (404). In other words, two of the domain's three nameservers sat on a domain anyone could register.

How he found it matters for defenders. He used Certificate Transparency logs to build a list of government domains worldwide, then checked their nameservers. He reports about 21 hits for expired nameservers. He says South Korea had the most straightforward disclosure process and fixed the issue within two months, and that he paid "a couple hundred dollars to register all the expired nameservers so nobody else could." He also notes that this attack vector has been in academic literature since 2016.

What I could see myself on November 9, 2026: the NS set returned for ncsc.go.kr still listed ns1.aegis-k.com and ns2.aegis-k.com, and Verisign RDAP shows aegis-k.com as registered on 2026-09-07 with Cloudflare nameservers. RDAP doesn't show the registrant, so I can't confirm who holds it or what the fix involved. Either way, a delegation to a domain you don't control only stays safe as long as the current holder means well.

Why it's serious: whoever controls an authoritative nameserver for a zone can answer queries for it. That can include MX and A records, and, depending on how the CA validates, DNS records used for certificate issuance. The author points specifically to intercepting mail and internal traffic. DNSSEC wasn't in place here, according to the post.

Case 2: A lapsed analytics domain, reused by an attacker

The NIKKE PC launcher incident is often summarized as "an expired domain got snatched." RyanOps' analysis (Nov 4, 2026), based on two public technical reports, says that's only half right, and the difference is worth getting straight.

What the analysis confirms:

  • insightjs.com had a real history. crt.sh shows around twenty Amazon-issued certificates for api. and cdn.insightjs.com from August 2019 to June 2021, then a gap of more than five years.
  • Verisign RDAP shows the domain was created again on 2026-09-27 at 01:59:19 UTC. I got the same registration timestamp from RDAP on November 9.
  • About four hours and forty minutes later, official JavaScript files on the publisher's CDN were modified to load a script from insightjs.com. The launcher loads those files. According to the reports RyanOps cites, the files stayed modified for at least 37 days, and the payload could run commands and steal credentials.

What it does not support: neither technical report says the launcher ever used insightjs.com before. The attacker got write access to the CDN (how is still unknown) and picked a lapsed domain with a legitimate-looking history so the injected line would look less out of place.

Two lessons for dependency monitoring still come out of it:

  1. Domain age and history aren't trust signals. A 2019 certificate history made a domain registered that day look established.
  2. Fallback domains are dependencies too. The injected code tried insightjs.org if .com failed. RyanOps reports that .org was registered by someone else on November 3. The analysis infers that whoever holds that domain can run JavaScript in launchers that still have the modified files cached. Any hard-coded fallback hostname you don't own is an open door.

The dependency domains worth inventorying

You can't monitor what you haven't listed. For each domain you or your clients run, pull out every external registrable domain it relies on:

DNS delegation

  • NS records at the parent and in the zone. Compare both, because they can drift. Flag any nameserver hostname whose registrable domain you don't own.
  • Glue and vanity nameservers on domains that were part of an old provider or acquisition.
  • CNAME targets pointing at SaaS or cloud hostnames.

Email

  • SPF include: and redirect= targets. Per RFC 7208 §5.2, include triggers a recursive check of the referenced domain's SPF record, and a match produces a pass. If an included domain lapses and someone else registers it, they can publish an SPF record that authorizes their own servers to send as you.
  • MX hosts and DKIM selector CNAMEs pointing at vendor domains.

Web

  • Third-party script, style and iframe sources. Crawl your pages and collect every external src. Include fallbacks and anything loaded dynamically, not just what's in the HTML.
  • Old marketing, analytics and widget domains left in templates after the vendor relationship ended.

What to monitor on each dependency

For every domain on that list:

  • Registration status and expiry date via RDAP. Alert on approaching expiry, on "not found" (unregistered), and on a new creation date. A creation date newer than when you started depending on the domain means it changed hands.
  • Registrar and nameserver changes. A switch to a different registrar or parking/suspension nameservers is worth a look. (On November 9, RDAP showed insightjs.com on suspended-domain.com nameservers.)
  • New certificates in CT logs. In the NIKKE case, a new Let's Encrypt certificate for analytics.insightjs.com appeared on October 6, 2026, after a five-year gap. A fresh certificate on a dependency domain that had been quiet is an early signal.
  • Resolution changes. New IPs or ASNs for NS and script hosts.

And for your own domains: track expiry, auto-renew status and registrar lock, and keep the renewal contact on a mailbox someone actually reads.

Practical commands

# Nameservers a zone currently answers with
dig +short NS example.com

# Registration and expiry for a .com/.net dependency (Verisign RDAP)
curl -s https://rdap.verisign.com/com/v1/domain/vendor-example.com \
  | jq '.events[] | {eventAction, eventDate}'

# SPF chain: look at each include target
dig +short TXT example.com | grep spf

A 404 from RDAP for a domain in your NS set, SPF chain or script sources is an incident, not a ticket for later.

FAQ

What is a dangling nameserver? An NS record pointing at a hostname on a domain that has expired or was never registered. Whoever registers that domain can run the nameserver and answer DNS queries for your zone.

Can an expired third-party script domain compromise my site? Yes. If your pages still load a script from it, whoever registers the domain controls the code that runs in your visitors' browsers. Remove unused references and monitor the ones you keep.

How often should dependency domains be checked? Expiry dates change slowly, but registration and NS changes can happen any day. A daily RDAP/DNS check plus CT log alerts is a reasonable baseline.

A note on Nameward

I'm building Nameward, a domain and certificate monitoring tool for MSPs and ops/security teams. Its domain side is meant to do the work above: find the external domains your zones, mail and pages depend on, and watch their registration, expiry, nameservers and new certificates. You can sign up at nameward.app. If you'd like to join the beta, or you have a case where this went wrong, get in touch.

Sources (accessed November 9, 2026)

Free scan

No signup. Only scan domains you own or manage.

More in Domain registration