Hijacking is a category, not a single event
Domain hijacking is any unauthorized change to a domain's registration or its delegation — the NS records that tell the internet which nameservers answer for the name. Someone else takes over who controls the domain, where it points, or both, without the registrant's permission. The standard summary describes it as changing the registration of a domain name without the permission of its original registrant, or by abuse of privileges on domain hosting and registrar software systems.
That second clause carries more weight than it looks like it does. A large share of documented hijacks never touch the registrant's credentials at all. They exploit a privilege held by somebody else in the chain: a support agent, a reseller, an upstream technical partner, a DNS provider. The registrant did nothing wrong and still lost the name.
Because "hijacking" spans everything from a five-minute nameserver change to a laundered inter-registrar transfer, the first diagnostic question is always the same: did the registration record change, or only the resolution? The answer determines whether you are dealing with a problem measured in hours or one measured in months.
Three control planes
There are three distinct places an attacker can stand, and each has a different signature and a different fix.
The registrar account
Credential theft, phishing, keyloggers, or compromise of the registrant's email account — which is the password-reset path for everything else. This is the plane where an attacker can do the most damage in the fewest steps, because from inside the panel they can change contacts, lift the lock and request the transfer code in sequence.
Registrar or reseller staff and systems
Social engineering of first-tier support, documented in SSAC's SAC007 as far back as 2005, or compromise of a provider's own credentials at an upstream partner. Gandi's July 2017 incident is the clearest published example of the latter: attackers obtained Gandi's login credentials for a technical partner's web portal, believed to have been captured over an insecure connection because the platform permitted plain HTTP, and used them to change NS, MX and SPF records for 751 domains across 34 top-level domains between 08:04 and 09:44 UTC. Everything was reverted by 13:50 UTC.
The DNS operator and record layer
CISA Emergency Directive 19-01, Mitigate DNS Infrastructure Tampering, issued 22 January 2019, describes attackers who compromise user credentials to access DNS administration accounts, alter A, MX and NS records to redirect traffic, and then obtain valid TLS certificates for the affected names so that interception produces no browser warning at all.
Subdomain takeover, the adjacent failure
A fourth pattern deserves separate treatment because it does not require compromising anything. Subdomain takeover is claiming a third-party service that an abandoned DNS record still points at — a dangling CNAME aimed at a deprovisioned hosting account, CDN bucket or SaaS tenant that anyone can now re-register.
Nobody breaks in. The organization left a door standing in a field and someone walked through it. The early-2024 "SubdoMailing" campaign is the scale demonstration: more than 8,000 domains and subdomains belonging to brands including eBay, Marvel, McAfee, MSN and The Economist were used to send mail that inherited the parent domain's reputation.
The defense is an inventory discipline rather than a security control. Every DNS record that points at a service you no longer pay for is a liability, and the only reliable way to find them is to enumerate your own zone and check what each target actually resolves to now.
The certificate problem nobody plans for
Certificates issued during a hijack survive the hijack. That single sentence is the most commonly missed part of incident response on a domain.
Once an attacker controls DNS for a name, they can satisfy the domain-validation check that certificate authorities use, obtain a valid TLS certificate, and interpose themselves without triggering any browser warning. CISA ED 19-01 describes exactly this step. Revert the DNS records and the traffic comes home — but the certificate remains valid until it expires or is revoked, and it is useful again the moment the attacker regains any position.
Which is why Certificate Transparency logs, the public append-only record of every certificate issued, searchable by domain, belong in both the detection and the cleanup phases. ED 19-01 makes CT-log monitoring a required action. Gandi's own incident report shows the discipline in practice: it examined the 18 SSL certificates issued during its incident window and confirmed that all of them were legitimate. Checking and finding nothing is the point.
Speed is the entire game
Where the hijack is a DNS-only change, reversal can take hours: Gandi's 751 domains were altered starting at 08:04 UTC and fully restored by 13:50 UTC the same day. Where it involves an inter-registrar transfer, you move onto policy timelines instead, and those are the ones worth memorizing:
- 4 hours — the Transfer Emergency Action Contact response window under the ICANN Transfer Policy, the fastest registrar-to-registrar escalation path that exists.
- 24 hours — the Registrar of Record's response requirement.
- 5 calendar days — the registry's response window, after which a non-responding Registrar of Record produces default approval.
- 60 days — the post-transfer and post-Change-of-Registrant transfer locks.
- 12 months — the deadline for a losing registrar to file under the Registrar Transfer Dispute Resolution Policy.
- 10 business days — CISA ED 19-01's compliance window for its four required actions: audit DNS records, update passwords on DNS-managing accounts, enable multi-factor authentication on those accounts, and monitor Certificate Transparency logs.
None of these clocks help if nobody starts them. perl.com sat hijacked from roughly September until a 27 January detection. Detection latency, not procedural difficulty, is what converts a recoverable incident into a contested one.
What people get wrong
- Treating a hijack as an IT ticket. It routes to the registrar's abuse and emergency channel, not the normal queue. The Transfer Policy created the TEAC with a 4-hour obligation for exactly this, and it is worth knowing your registrar's path to it before you need it.
- Fixing DNS without rotating the credentials used to change it. ED 19-01 orders the password change and MFA rollout alongside the record audit, in the same 10-business-day window, because reverting records against a still-valid stolen credential just schedules the next incident.
- Rotating only the credential that obviously failed. After a single partner portal was compromised, Gandi reset credentials across all 150 of its technical platforms. That is the correct blast radius assumption.
- Skipping the certificate check, for the reasons above.
- Not noticing. A hijack that leaves nameservers alone breaks nothing visible. perl.com's transfer to another registrar in December went unremarked; it was the later nameserver change that tripped monitoring.
Controls that hold
Ranked roughly by how much attack surface each one removes:
- Registry lock, where the registry offers it. Verisign's Registry Lock Service covers .com, .net, .cc and .name, applies the server-side EPP statuses
serverUpdateProhibited,serverDeleteProhibitedandserverTransferProhibited, and requires that an authorized individual at the registrar be contacted by Verisign by phone and supply an individual security phrase before the name can be unlocked. That out-of-band step is what defeats a compromised control panel, because the panel cannot lift it. - Non-SMS multi-factor authentication on the registrar account, the DNS-hosting account, and the email account that resets both. ED 19-01 requires MFA on all accounts that can change DNS records and states that SMS-based MFA is not recommended.
- Registrar lock —
clientTransferProhibited— left on as the default state. - Continuous CT-log and DNS-change monitoring, run from outside the accounts being monitored.
- Known emergency contact paths. SAC007's fourth recommendation is that registrars make emergency support contact information available to other registrars, resellers and registry operators. The perl.com account confirms why it matters: once everyone who needed to talk to each other had good contact information, the process mostly took care of itself.
The documented record
Hijacking is not a theoretical risk with anecdotal support. It has a twenty-year evidentiary record, and the pattern barely changes.
panix.com, 14 January 2005 — transferred without authorization from Dotster to Melbourne IT through a reseller, with a nameserver change that resulted in the loss of service for thousands of customers of Public Access Networks Corporation. HZ.com, 15 February 2005 — a two-letter domain moved without owner consent, discovered by the owner through a WHOIS query and recovered with documentation. hushmail.com, 24 April 2005 — DNS configuration modified to point at an unauthorized server. All three are recorded in SAC007.
Then: Lenovo and Google Vietnam, briefly hijacked in 2015. Gandi, 7 July 2017 — 751 domains redirected to a host serving an exploit kit, a toolkit that attacks visitors' browsers automatically. US federal agencies, 2018–2019 — the DNS tampering campaign that prompted an emergency directive. perl.com, 2021. SubdoMailing, early 2024. Fur Affinity, 19 August 2024.
Twenty years apart, the same three moves: get a credential, change a record, hope nobody is watching.