Domain Hijacking: How It Happens and How to Stop It
In April 2026 attackers social-engineered a national registry directly and took a domain that had every normal protection enabled. Around 1.2 million dollars vanished. Here is how hijacking actually works, and the version nobody notices.
September 9, 20266 min readSecurity · DNS · Hijacking
The short answer. There are two attacks with similar names. Domain hijacking steals the registration. DNS hijacking leaves the registration alone and changes where the name points, which means your record still looks perfectly normal while your traffic goes somewhere else. The second is far more common and much harder to notice.
Domain and DNS hijacking, together with subdomain takeover, ranked as the top cybersecurity threats organisations actually experienced in 2025, according to CSC's CISO Outlook 2026. This is not an exotic risk.
The two attacks
| Domain hijacking | DNS hijacking | |
|---|---|---|
| What is taken | The registration itself | Control of where the name points |
| Registration record | Changes, shows a new owner or registrar | Unchanged. Still shows you. |
| How you notice | Registrar access stops working | Often you do not |
| How it is done | Account takeover, social engineering | Nameserver or DNS record change |
| Recovery | Slow, sometimes a formal dispute | Fast, once you notice |
The dangerous asymmetry. Domain hijacking is worse but announces itself. DNS hijacking is recoverable but silent, and the silence is the point. An attacker who redirects your mail can read password resets for every service you use while your domain record still says everything is fine.
How it actually happens
Account takeover
The most common route, and the least sophisticated. Your registrar login is reused, phished, or protected by SMS two-factor that was defeated with a SIM swap.
Once inside, the attacker changes the nameservers or starts a transfer. Everything they do is a legitimate action performed by an authenticated user, so nothing looks anomalous to the registrar.
Email compromise
Domain control is authorised through the registrant email address. Whoever reads that mailbox can approve transfers, request auth codes and reset the registrar password.
This is why an expired domain whose email lived at that same domain is such a bad situation, and why the registrant address should never be at the domain it controls.
Social engineering the registrar or registry
The most alarming variant, because your own security posture is not what fails.
On 14 April 2026, the CoW Swap domain was hijacked by social-engineering Finland's Traficom registry directly. Roughly 1.2 million dollars was lost. The attacker did not need the owner's password, their two-factor code, or their email. They convinced the organisation above the registrar.
State-level actors do this too. On 7 and 8 April 2026, the US Department of Justice, the FBI, the UK's NCSC, Microsoft and Lumen Technologies issued a joint disclosure about APT28 conducting DNS hijacking operations.
This is the case for monitoring rather than only hardening. Every protection in the next section is worth enabling, and none of them stops an attack that goes over your head. What catches that is noticing the change quickly.
Expiry
Not an attack, but the same outcome. A domain that lapses and is registered by someone else is gone, and there is no dispute process for forgetting to pay. The lifecycle is here.
What an attacker does with it
Once they control where your name points:
- Serve a copy of your site and harvest logins from people who typed your address correctly
- Receive your email, which means password resets for everything else you own
- Pass domain validation for a TLS certificate, so the fake site shows a valid padlock
- Send mail as you, with your SPF and DKIM working in their favour
- Sell the domain onward through several hands, which makes recovery far harder
The email consequence is the one people underrate. Control of your MX records is control of every account that can be reset by email, which is most of them.
The defences, in priority order
1. Turn on the registrar lock
This sets clientTransferProhibited on the domain and blocks transfers outright. Most registrars apply it by default now. Check that yours did, and turn it back on after any transfer, because it comes off during the process and is easy to forget.
2. Use app-based two-factor, not SMS
Your registrar account is the master key to your entire online presence. SMS codes are defeated by SIM swapping, which is a routine attack rather than a theoretical one. Use an authenticator app or a hardware key.
3. Move the registrant email off the domain
If [email protected] is the registrant address for yourdomain.com, then anyone who hijacks the DNS also captures the mailbox that could have proved it was yours. Use an address at a different domain entirely.
4. Monitor nameservers and registrar
This is the control that catches what the others miss. Locks and two-factor protect the registration. They do nothing about a DNS-level attack, and nothing about an attack that goes through the registry rather than through you.
An unexpected nameserver change has no benign explanation you would not already know about. It should reach you within minutes, and the alert should say what the value changed from, so you can tell instantly whether it was your own team.
That is the specific thing Domain Hub records: the previous value beside the new one on every change, with urgent changes sent as they are found rather than held for a digest. More on what is worth watching.
5. Consider a registry lock for critical names
Distinct from the registrar lock. A registry lock sets serverTransferProhibited and similar codes at the registry, and removing them requires an out-of-band, manual verification process.
It is inconvenient by design, costs extra, and is not offered by every registrar. For a domain the business genuinely depends on, that inconvenience is the product.
6. Enable DNSSEC
DNSSEC cryptographically signs your DNS records so resolvers can verify the answers were not tampered with in transit. It does not stop someone who has taken over your account from publishing new signed records, so it is not a hijacking defence on its own, but it closes the tampering-in-transit route.
If it happens
Speed matters more than process, and the order matters.
- Contact your registrar immediately, by phone if they have one. Ask them to freeze the domain.
- Change every password on the registrar account and the registrant email, from a device you trust.
- Document everything. Screenshots of the current record, timestamps, what changed and when. You may need this formally.
- If a transfer is already in progress, the window to stop it is small. This is the emergency path.
- If the transfer completed, you are into a formal dispute. Registrars have a transfer dispute process, and UDRP exists where you hold trademark rights.
- Assume the email was read. Rotate credentials for everything resettable through that address.
Recovery gets dramatically harder once the name has moved between registrars twice. The first hours are worth more than the following month.
The uncomfortable summary
You can do everything right and still lose a domain, because part of the attack surface is other people's staff. Locks, two-factor and a separate registrant address remove the easy routes, and they are all worth doing today.
What they cannot do is tell you when something changed anyway. That is a detection problem, and detection is the only control that works against an attack you did not participate in.
If you hold names your business depends on, check what they currently look like, then set them to be watched. The cost of noticing in minutes rather than weeks is the entire difference between an incident and a loss.
Put the research to work.
Check your shortlist across the extensions that matter, then save the strongest names to a project.
Check a domain