Registrar credentials get phished, reused across breached password dumps, or left without two-factor authentication turned on – and once an attacker holds that login, domain shadowing lets them quietly create malicious subdomains under a legitimate, trusted domain without ever touching the main website. The parent site keeps running exactly as before, which is precisely why the technique stays undetected for months in a lot of environments.
What Domain Shadowing Actually Looks Like in Practice
Domain shadowing is a registrar-account-level compromise, not a DNS protocol flaw. An attacker gets valid credentials to a domain registrar or DNS management panel – GoDaddy, Namecheap, Cloudflare, Route 53, whatever the organization uses – and instead of changing the nameservers or defacing the main site, they add new A or CNAME records for subdomains nobody is watching.
A compromised account for example.com might suddenly have malware-c2.example.com pointing to an attacker-controlled IP, or secure-login.example.com hosting a phishing kit that harvests Office 365 credentials. The apex domain and www record are untouched. Uptime monitors stay green. Nobody gets paged.
This is exactly why the technique is popular in exploit kit campaigns – Cisco Talos documented large-scale domain shadowing tied to the Angler exploit kit back in 2015, and the pattern has resurfaced repeatedly since, including in campaigns abusing GoDaddy accounts with weak or reused passwords. The attacker isn’t after the domain’s content; they’re after its reputation. A subdomain of a 15-year-old logistics company’s domain sails through spam filters and URL reputation checks that would flag a freshly registered lookalike domain in seconds.
Why Registrar Accounts Are the Weak Link
Most organizations put far more security effort into their web application and email systems than into the registrar account that controls the DNS zone underneath both. It’s common to find a registrar login still tied to a departed employee’s personal email, protected by a password last rotated in 2019, with no 2FA enabled because “it’s just where we renew the domain once a year.”
That single account is effectively the root of trust for everything the domain touches – SPF and DKIM alignment, TLS certificate issuance via ACME DNS-01 challenges, every subdomain that exists or could exist. Compromise it and an attacker inherits all of that trust at once. Registrar accounts also tend to sit outside normal IAM and SSO governance, since they’re managed by whoever set up the domain years ago rather than by the identity team.
Common Mistakes That Let This Go Unnoticed
A few patterns show up again and again in incidents involving domain shadowing:
Trusting DNS record counts instead of content. A team checks that “the zone file looks about the same size” rather than diffing the actual record set. Domain shadowing often adds only two or three new records, which is invisible if nobody’s comparing against a baseline.
No alerting on registrar login events. Most registrars support login notifications or audit logs, but almost nobody has these forwarded to a SIEM or even to a monitored inbox. The compromise event itself – a login from an unfamiliar IP range – goes unreviewed.
Treating DNS as an IT chore instead of a security asset. The registrar password is often shared in a spreadsheet or password manager entry with broad access, reviewed only when the renewal invoice arrives once a year.
Busting the “It’s Just Subdomains” Myth
A common misconception is that domain shadowing is a low-severity nuisance because the attacker “only” gets subdomains, not the main site. That framing misses the actual damage. Attackers use these subdomains for phishing pages that inherit the parent domain’s SPF/DKIM alignment and mail reputation, for exploit kit landing pages, and for command-and-control infrastructure that blends into normal-looking traffic logs.
Because the subdomains are created and often deleted within days, they frequently don’t show up in a certificate transparency review scheduled quarterly, and they’re gone before an annual DNS audit ever gets scheduled. The blast radius isn’t “a subdomain” – it’s the entire trust relationship a domain has built up with browsers, mail filters, and threat intelligence feeds.
Detecting and Responding to Domain Shadowing
An experienced security engineer starts from the assumption that any new subdomain is suspicious until proven otherwise, rather than assuming the DNS zone is static between reviews. A practical response sequence looks like this:
First, enforce hardware-token or app-based 2FA on every registrar and DNS management account – SMS-based 2FA is not sufficient here, since SIM-swapping is a documented vector against exactly this kind of account. Second, restrict registrar account access to a small, named group and remove standing access for anyone who doesn’t need it week to week. Third, establish a known-good baseline of every subdomain and DNS record currently in the zone, dated and stored somewhere reviewable. Fourth, put continuous change detection in place so new or modified records generate an alert within minutes rather than at the next scheduled audit. Fifth, when an unauthorized record does appear, remove it, rotate the registrar credentials and any API tokens immediately, and check certificate transparency logs for certificates issued against the rogue subdomain, since that reveals how long it was live and whether TLS was used to make phishing pages more convincing.
Real-time change detection is what closes the gap between “attacker adds a record” and “someone notices” – quarterly or even monthly manual reviews leave weeks of exposure window, which is more than enough time for a phishing campaign to run its full course and get taken down on its own.
FAQ
How is domain shadowing different from a subdomain takeover?
Subdomain takeover exploits a dangling DNS record pointing to a deprovisioned cloud resource that an attacker can claim – the domain owner’s account is never touched. Domain shadowing requires actual compromise of the registrar or DNS provider account, after which the attacker creates entirely new records rather than claiming abandoned ones.
Can domain shadowing happen if I use a managed DNS provider like Cloudflare or Route 53?
Yes. The DNS provider’s infrastructure isn’t the weak point – the account credentials controlling it are. Cloudflare and Route 53 both support hardware or app-based MFA and audit logging, but only if an organization actually enables and monitors them.
How quickly can attackers exploit a compromised registrar account?
Malicious subdomains have been observed appearing within hours of a credential compromise in documented exploit kit campaigns, since the process of adding a DNS record takes seconds once panel access is obtained. This is why waiting for a scheduled audit cycle isn’t an adequate control on its own.
Locking down the registrar account with hardware 2FA and a tight access list solves half the problem; the other half is knowing, in near real time, the moment a record changes that nobody on the team authorized.