DNS Hijacking Doesn't Need a Zero-Day, Just Your Registrar Login

Most of the breaches in this series involve a bug: a deserialization flaw, an SSRF gadget, a permission chain nobody meant to grant. DNS hijacking usually involves none of that. An attacker gets into your registrar account or the AWS account holding your Route 53 hosted zone, changes a handful of records or repoints your nameservers, and now every visitor, every API client, and every ACME certificate check for your domain goes wherever the attacker wants. No exploit, no patch, just an authentication failure one layer above the infrastructure you actually monitor.

Root cause

Domains have two independent control planes, and most teams only harden one of them. The registrar account (Route 53 Domains, GoDaddy, Namecheap, whoever you bought the name from) controls which nameservers are authoritative for the domain — win that account and you can point the whole domain at infrastructure you own, bypassing the hosted zone entirely. The DNS host (Route 53’s hosted zone, in most AWS setups) controls the actual records — win that and you can retarget individual names like www, api, or mail without touching nameserver delegation at all. Both are reachable through the same weak points that compromise any AWS account: a phished IAM/root credential, a leaked access key with route53:ChangeResourceRecordSets scoped too broadly, a stale email address on the registrant contact that an attacker resets via “forgot password,” or a support-desk social-engineering call to the registrar itself — the exact technique behind several high-profile crypto-exchange and news-site hijacks over the past few years. Registrar accounts are especially soft targets because they’re touched once at domain purchase and then forgotten; nobody rotates that password or reviews its MFA status on the same cadence as production AWS credentials.

Blast radius

A hijacked A or CNAME record silently redirects traffic — no browser warning, no failed connection, because the attacker can request a Let’s Encrypt or ACM certificate for the domain once they control DNS resolution, satisfying the domain-validation challenge and getting a fully valid TLS certificate for a domain they don’t own. That means phishing pages served under your real domain with a green padlock, mail rerouted via a changed MX record for business email compromise, and OAuth or SSO callback URLs hijacked if the attacker controls a subdomain used in a redirect allowlist. Because DNS changes propagate through caching resolvers over their TTL rather than instantly, the attack has a built-in persistence window even after you notice and revert — a 24-hour TTL means stale resolvers keep serving the attacker’s records for up to a day after the fix lands, and any DNSSEC signing keys or delegation left unrotated let a sophisticated attacker re-establish control after a naive cleanup. Domain hijacks have taken down cryptocurrency platforms and redirected their traffic to phishing clones for hours, and the same pattern applies to any SaaS or e-commerce domain — the record type doesn’t matter, only which service trusts DNS to prove identity.

Remediation

Lock down the registrar first, since it’s the layer most teams neglect: enable registrar transfer lock and registry lock where your TLD supports it (most gTLDs do via the registrar; it requires an out-of-band confirmation — phone call or notarized request — before nameservers can change), and put the Route 53 Domains account or third-party registrar login behind hardware-key MFA, not SMS, since SIM-swapping is a documented bypass for exactly this attack. On the AWS side, scope route53:ChangeResourceRecordSets and route53domains:* to a narrow admin role instead of leaving it reachable from broad Route53FullAccess policies, and require MFA on that role via an IAM policy condition (aws:MultiFactorAuthPresent). Enable CloudTrail logging for Route 53 API calls specifically — they’re global-service events that land in us-east-1 regardless of your other resources’ region, which trips up teams who only ship CloudTrail alerts for their primary region. Turn on DNSSEC on the hosted zone so a hijacked nameserver delegation without the matching signing keys fails validation for DNSSEC-aware resolvers, and keep TTLs on critical records (mail, SSO callbacks, apex) shorter than you’d otherwise want — the convenience cost of more frequent lookups is small next to cutting your hijack persistence window from a day to minutes. Finally, monitor externally: a certificate-transparency log watcher (crt.sh or a CT-monitoring service) alerting on any newly issued certificate for your domain catches a hijack the moment the attacker requests TLS for their redirect, often before you’d notice the DNS change itself.

If you take one thing from this: audit who can log into your registrar account today, not just your AWS console. It’s the account nobody has touched since the domain was purchased, and it’s the one that bypasses every control you’ve built inside AWS.