The attack that is designed not to be noticed
Domain shadowing is what happens when an attacker who holds your DNS or registrar credentials quietly adds new subdomains — names beneath your domain, such as login.example.com under example.com — pointing at servers they control, and leaves everything you actually use running perfectly. Your website loads. Your mail flows. No monitoring alert fires, because nothing has stopped working.
Palo Alto Networks Unit 42 classifies it as a subcategory of DNS hijacking and draws the distinction explicitly: ordinary hijacking disrupts existing services and therefore alerts the owner, whereas shadowing is engineered not to (Unit 42). That is the whole design. The attacker is not after your traffic; they are after your reputation — the accumulated registration age and clean history that causes security products to let a name through.
This inverts the usual triage instinct. With most DNS incidents, the outage is the alarm. Here the absence of an outage is the point, and the only thing that will find it is looking on purpose.
How the rogue records get there
The sequence is short and does not require anything clever once the first step is done.
- Credentials for the zone are obtained. A registrar account, a DNS hosting panel, or an API key. Cisco Talos, documenting the Angler exploit-kit campaigns that put the term into circulation in 2015, attributed the credential supply to large-scale phishing of registrant accounts — the registrant login, not the web server.
- Records are added rather than edited. Existing A, MX, NS and TXT records are left untouched. This is the deliberate choice that keeps the attack quiet.
- The new subdomains point at attacker infrastructure — exploit-kit landing pages, phishing forms, or command-and-control. They are typically randomly generated, short-lived, and rotated in bulk, so any single name you find is one of many and probably already retired.
- Reputation is inherited. The subdomain carries the parent domain's age and clean history, and the parent is not itself malicious, so reputation-based filtering — security products deciding whether to allow a domain based on its age, history and prior behavior — underperforms badly.
An exploit kit, in this context, is a hosted toolkit that fingerprints a visitor's browser and serves whichever exploit fits. It needs a steady supply of clean-looking hostnames, which is exactly what a shadowed zone provides.
Two variants, and one of them is invisible to you
It is worth separating these, because they are found in different ways.
- Zone-level shadowing. Records are added directly in your DNS zone. They appear in a full zone export, so a diff against a known-good inventory finds them.
- Delegated shadowing. The attacker adds an NS record delegating a child zone — say
cdn.example.com— to nameservers they run. Your zone now contains one innocuous-looking delegation, and everything beneath it lives in a zone you cannot see, cannot export and cannot audit.
Delegated shadowing is the case that defeats a zone review conducted by someone reading for obviously malicious names. There is nothing malicious to read. There is one extra NS record that looks like infrastructure. The only reliable check is asking whether every delegation in the zone corresponds to a service you deliberately delegated, and to a provider you can name.
Wildcard records make both variants worse. A single * A record answers for every possible subdomain with no per-name record to find, so an attacker who can add or point a wildcard gets unlimited hostnames and leaves one line of evidence.
The detection gap, measured
The claim that shadowing evades detection is not an impression. Unit 42 measured it. Over a study period running from 25 April to 27 June 2022, passive DNS analysis — querying a database of DNS answers actually observed in the wild, rather than the records you think you have — identified 12,197 shadowed domains. Of those, only 200, about 1.6 percent, were flagged as malicious by any vendor on VirusTotal. In one phishing campaign within the same data set, 649 shadowed subdomains were identified and only 151, roughly 23 percent, were flagged (Unit 42, 2022).
Read those two numbers together. The security industry, in aggregate, was seeing somewhere between one in four and one in sixty of these names. If your assurance that your domain is clean rests on nobody having reported it, that assurance is worth approximately what those percentages suggest.
The business consequence is delayed and indirect. Blocklisting and reputation damage attach to the parent domain, which is yours, and they outlast the cleanup — mail deliverability degrades, browser interstitials appear, and partners start asking questions about a campaign that ended weeks ago.
Why DNSSEC does not help here
This deserves stating flatly, because it is a common and comfortable misreading. DNSSEC places cryptographic signatures on DNS answers so that a resolver can detect a forged answer (RFC 4033). Shadowed records are not forged. They were added through the provisioning path, by someone holding valid credentials, and they are signed by your own keys along with everything else in the zone.
A signed zone therefore attests, correctly and cryptographically, that the attacker's phishing subdomain is authentic. That is not a flaw in DNSSEC; it defends the resolution path, not the provisioning path. Sign your zones anyway. Just do not record it as a mitigation for this threat, because in a control review it will be counted as one.
Common mistakes
- Concluding the zone is clean because the site loads and mail flows. That is the attack's design goal, not evidence of safety.
- Auditing the records you remember creating, rather than enumerating every record actually present.
- Deleting the shadow records without rotating the credentials that created them, which guarantees recurrence and teaches the attacker to be quieter.
- Overlooking wildcard records, which serve unlimited attacker subdomains from a single entry.
- Not checking for additional registrar-account users, delegated sub-accounts or API keys added by the attacker — persistence often lives in the account, not the zone.
- Missing added NS delegations, which hide the malicious records in a zone you have no visibility into.
The first item is the one that costs the most time. I have seen zone reviews closed as clean on the strength of a site that was still up, which is the equivalent of confirming a burglary did not happen by checking the front door still opens.
Finding it, and keeping it found
Detection here is a process problem rather than a tooling problem.
- Export the full zone on a schedule and diff it against a known-good inventory. Shadowing appears as additions, which is precisely what a diff catches and a spot-check does not.
- Keep DNS in version control, so every record has an author, a timestamp and a review — the OWASP subdomain-takeover cheat sheet recommends version-controlled DNS for exactly this audit trail, and the benefit carries over.
- Run passive DNS lookups against your own domain, which shows what subdomains the outside world has observed resolving, including names under delegated child zones you cannot export.
- Monitor Certificate Transparency logs. Subdomains intended to look legitimate usually need HTTPS, and the certificate frequently surfaces before anything else does.
- Audit API keys, delegated users and account contacts on the same schedule as passwords, and put multi-factor authentication on registrar and DNS accounts.
- Avoid wildcard records; where a wildcard is genuinely required, monitor what it is actually being asked for.
What policy does and does not cover
There is no ICANN consensus policy that names domain shadowing. Contractually and legally it is unauthorized access to a registrant account, and the applicable framework is the registrar's own account-security terms together with the DNS abuse provisions of the Registrar Accreditation Agreement. Where the conduct is criminal, that is a matter for counsel and for law enforcement, not for a support ticket.
Policy clocks do become relevant if the same credential compromise was also used to move the domain. Under the ICANN Transfer Policy, the registrar of record has five calendar days to respond to a transfer request before it is automatically approved, and a Form of Authorization is valid for 60 days from issue (ICANN Transfer Policy). A shadowing discovery therefore warrants an immediate check of the domain's transfer status, not just its records. The attacker who added subdomains had, at that moment, everything needed to attempt more.