Domain Hijacking vs DNS Hijacking: How Attacks Happen

Domain hijacking concerns unauthorized control of a domain registration; DNS hijacking concerns unauthorized changes to where a name resolves. They can overlap: someone who compromises a registrar account may change the nameservers and thereby redirect DNS. But an attacker can also alter DNS at a separate provider without transferring the domain.

The third row is related operational risk, not automatically theft of an active registration. These distinctions tell you which account or service needs recovery. A transfer lock alone does not secure an external DNS account.

Mandiant's DNS hijacking investigation documents both compromised DNS-provider credentials used to change A records and compromised registrar or ccTLD access used to change NS records. Attackers also obtained certificates for redirected services. Its response guidance includes MFA, checks of DNS records, and certificate monitoring. The five paths below apply those distinctions to practical controls.

1. Social engineering against the registrar's support team

Many high-profile hijacks have not required a technical exploit. They have relied on a phone call or support request.

The pattern: an attacker collects enough information about a target—WHOIS history, LinkedIn, leaked password dumps, social media—and then calls or emails the registrar's support team impersonating the owner. They ask for a password reset, an email change, or a transfer auth code. If the support agent runs a checklist that the attacker has prepared for, the account changes hands.

This path does not require a vulnerability in the registrar's code; it exploits the human in the loop.

Controls that reduce the risk:

• A hard registrar-side rule that ownership changes require either a notarized document or a multi-factor challenge against the registrant's existing channel.
• Registry lock (separate from registrar lock), where the registry operator itself refuses to act on transfer or contact changes without an out-of-band confirmation. Available on .com, .net, and many ccTLDs.
• Verifying which registrar you actually use and removing the others. Brands that started in 2007 often have stale accounts at three or four registrars with weak credentials.

2. Registrar account compromise (the credential path)

The technical cousin of social engineering. The attacker phishes the registrar account credentials, or finds them in a credential-stuffing dump, and logs in directly. From there they unlock the domain, change the contact email, and request a transfer.

Controls that reduce the risk:

• Phishing-resistant MFA on the registrar account. Use FIDO2/WebAuthn authentication, such as a security key, where supported. It binds authentication to the site's name to resist phishing. If that option is unavailable, TOTP from an authenticator app adds protection beyond a password alone, but the code can still be phished: it is a fallback, not phishing-resistant authentication. NIST distinguishes WebAuthn's phishing resistance from OTP authentication. SMS-based 2FA also remains vulnerable to SIM swapping.
• A registrar that supports per-domain locks in addition to per-account locks, so a single account compromise cannot unlock everything at once.
• Audit trail and alerting on contact changes, nameserver changes, and transfer requests. The attacker's first move is to silence those alerts; if they fire to a channel the attacker does not control, you get warning time.

3. DNS provider takeover

Even if the registrar account is locked down, the name servers that the registrar publishes might point to a DNS provider with a separate account—Cloudflare, Route 53, NS1, DNSimple, your own BIND server. If the attacker gets into that DNS account, they do not need to touch the registrar. They just rewrite the A, MX, and TXT records and traffic follows.

This is often the easier path for attackers, because brands invest in registrar security but treat the DNS provider as "infrastructure" with weaker controls.

Controls that reduce the risk:

• The same 2FA rigor on the DNS provider account as on the registrar. Treat it as equally sensitive. It is.
• DNSSEC, signed at the zone level. DNSSEC does not prevent a DNS provider account compromise: if an attacker can publish records through the provider and the provider signs them with the zone's active keys, validating resolvers will treat those answers as authentic. What DNSSEC does block is in-path tampering, cache poisoning, and forged answers that are unsigned or wrongly signed, assuming the parent publishes the correct DS records. See RFC 4033-4035 for the protocol details.
• Multi-provider DNS with separate accounts and credentials, using multi-signer DNSSEC. This helps with availability and provider isolation, but it only works if every provider serves the intended zone data and the DNSKEY/DS sets are coordinated correctly. It is not a magic override where resolvers automatically prefer the uncompromised provider.

4. Nameserver hijacks via stale delegations and dangling records

A subtler variant: the domain itself is fine, but a subdomain points (via CNAME or NS record) at a third-party service that the original owner no longer controls. The attacker registers the resource on the third-party side and now answers for the subdomain.

Examples:

• A subdomain CNAMEd to an old Heroku, S3, or Azure asset that has been released. The attacker re-claims that asset name and gets a valid TLS cert.
• A delegated NS record pointing at a DNS provider account that has been deleted. The attacker creates a fresh account using that exact host pattern and serves whatever records they want for the subdomain.

These are catalogued under the umbrella term dangling DNS. The risk grows with large, poorly inventoried subdomain estates because abandoned third-party mappings can remain live after the underlying resource is removed.

Controls that reduce the risk:

• A complete inventory of every NS, CNAME, and ALIAS record in every zone you own, with an owner for each.
• Automated dangling-DNS scanners that re-resolve every record on a schedule and flag the ones pointing at third-party services that no longer respond. GitHub's blog and Detectify Labs have long-running write-ups of this attack class.
• Decommissioning records the same day you decommission the underlying service.

5. Expired-domain reclamation

The simplest and least sympathetic attack: the registrant forgot to renew. The grace period passes. The domain drops back into the pool. Someone else registers it.

This sounds like an operational failure, not a security incident, but the impact is identical—someone else now controls the name, and all of the trust signals that were built up over years (SPF, DKIM, OAuth callbacks, password reset emails, payment integrations) start flowing to a stranger. Several public incidents involved attackers buying expired domains specifically because the previous owner had registered them as the iss claim in OAuth tokens or as the sender for transactional email.

Controls that reduce the risk:

• Multi-year renewal (5-10 years) on any domain that touches authentication, payments, or production traffic. Check the allowed term and recurring cost for the TLD; advance renewal reduces one source of expiry risk.
• Auto-renewal with monitored payment and failure alerts. Cards expire and payment attempts fail, so auto-renewal is only effective when a team watches the failure channel.
• Calendar reminders at 90, 60, 30, and 7 days that fire to a team address, not the inbox of one person who might leave the company.

What good looks like

Pulling the controls together, the baseline for any domain that matters looks like this:

Not every control is available for every TLD or provider. The goal is to document which controls apply, identify uncovered paths, and add compensating monitoring rather than treating the table as a universal guarantee.

How Namefi changes the picture

Most of the controls above exist as features at one registrar, one DNS provider, or one workflow tool, and security depends on the weakest relevant account. Namefi adds an on-chain token as a parallel control layer for a traditional DNS registration. As the two-layer model explains, the NFT can become the control point for supported ownership and transfer actions while the registrar and registry layers continue to operate the DNS name.

That can reduce exposure to registrar-dashboard credential theft or support-driven changes when the workflow actually requires wallet authorization. It does not make social engineering impossible or remove path 1 entirely: the domain still depends on registrar and registry processes, the wallet introduces its own key-management and recovery risks, and DNS-provider accounts remain separate attack surfaces. DNSSEC, renewal controls, account security, and incident recovery are still required.

Sources and further reading

• NIST — SP 800-63B-4, Authenticator and Verifier Requirements, sections 3.1.4 and 3.2.5: OTP authentication is not phishing-resistant; WebAuthn uses verifier name binding. Fetched 2026-09-15.

• Mandiant — Global DNS Hijacking Campaign: DNS Record Manipulation at Scale, techniques 1–2 and detection/mitigation recommendations. Fetched 2026-09-15.

• ICANN — Transfer Dispute Resolution Policy scope.

• IETF — DNSSEC RFCs 4033/4034/4035 and multi-signer DNSSEC RFC 8901.

• CISA — Multi-factor authentication guidance.

• Detectify Labs — Hostile subdomain takeover write-up.

• Verisign — Registry lock for .com/.net.