How to detect domain hijacking early
You detect domain hijacking early by watching your domain's registration record for the changes an attacker has to make to steal it: a transfer lock coming off, the nameservers or registrant details being rewritten, or a pendingTransfer flag appearing. Each of those shows up in WHOIS or RDAP, often well before the transfer is final and while you can still stop it.
The standard advice, turn on a registrar lock and enable two-factor authentication, is necessary and not sufficient. A lock holds only until someone who controls the account removes it, and controlling the account is the whole point of a hijack. Prevention lowers the odds. Detection is what gives you the minutes that decide whether you keep the name.
What domain hijacking is, and how it differs from DNS hijacking
Domain hijacking is unauthorized control of the registration itself. The attacker takes over your registrar account, or convinces the registrar to hand the name over, then redirects the domain or moves it to a registrar they control. That is a different failure from DNS records being tampered with, where the name still belongs to you but resolves to the wrong place. A hijack changes who owns the name. The damage is worse and the recovery is slower, because you are now arguing ownership with a registrar instead of fixing a record.
The ways in are well understood, and ICANN has documented them since its first report on domain name hijacking:
- Registrar account compromise. Phishing, a reused password, or a missing second factor, and the attacker is in. This is the common path.
- Social engineering the registrar directly. A support request backed by forged identity documents, asking to move the name or reset access.
- A stale or compromised registrant email. Whoever controls the contact inbox drives password resets and transfer approvals.
- An expired registration that lapses and gets re-registered by someone else. A different mechanism, covered in domain expiry monitoring, but the end state looks the same: the name is no longer yours.
The perl.com hijack, in brief
In January 2021, perl.com, the home of the Perl language since the 1990s, was taken from its owner for about a week. No password was cracked. The site's own postmortem named the cause directly:
"There was a social engineering attack on Network Solutions, including phony documents and so on."
From there the name was moved away, bounced between two registrars (one in China, then one in Germany) to complicate any rollback, pointed at a parked page, and listed for sale on Afternic for 190,000 dollars before it was recovered. The recovery worked because the rightful owner was well known and the community escalated loudly, which is not a plan most teams can rely on.
Every step left a mark in the registration record. The sponsoring registrar changed. The nameservers changed. The expiry date was pushed years ahead so the name could not lapse back. Anyone diffing those fields would have seen the takeover as it happened. The problem was not visibility. It was that nobody was watching in time.
The signals that show up before you lose the domain
A hijack is not one event, it is a sequence of edits to the registration record, and most of them are visible from outside. Start from what a protected domain looks like in WHOIS, with the registrar lock in place:
Registrar: RESERVED-Internet Assigned Numbers Authority
Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibitedThose clientTransferProhibited and clientUpdateProhibited flags are the registrar lock, set by your registrar at your request. The alarm is any change to this picture. Mapped to what each change tends to mean:
| Change in WHOIS or RDAP | What it usually means |
|---|---|
clientTransferProhibited disappears |
the lock was removed, the first step before any transfer |
pendingTransfer status appears |
a move to another registrar is already in flight |
| sponsoring registrar changes | the transfer completed, the name has moved |
| nameservers replaced | traffic and email are being redirected |
| registrant or admin email rewritten | control of future approvals is being taken |
| expiry date jumps years ahead | the name was renewed to entrench it and block a lapse-back |
The order is the point. A lock coming off and a pendingTransfer flag are the early signals, the ones that appear while the transfer can still be rejected. Once the sponsoring registrar has changed, the name is already gone and you are into recovery, which is measured in days or weeks, not minutes.
How to watch these yourself
Reading the record once is a single command. RDAP returns the same facts as structured JSON, including the status array, which is the field that matters most here:
curl -s -H "Accept: application/rdap+json" \
https://rdap.verisign.com/com/v1/domain/example.com"status": [
"client delete prohibited",
"client transfer prohibited",
"client update prohibited"
]Detection is running that check on a schedule, diffing the result against the last snapshot, and alerting the moment a watched field moves. The window you are buying is real but narrow. Once a transfer is initiated you have a limited time to reject it through your registrar, and the code that authorizes a transfer (long called the AuthInfo code, now being replaced by a short-lived Transfer Authorization Code under ICANN's updated Transfer Policy) is exactly what an attacker holding your account can generate. The policy is mid-overhaul, with shorter locks and that time-limited code, but the signals above do not depend on which version is in force.
Watching the public record has one blind spot worth naming. Many country-code registries, and GDPR-redacted records generally, hide the contact fields, so a registrant-email rewrite can be invisible from outside. The transfer status, the registrar, and the nameservers usually stay visible even then, which is why those are the signals to lean on.
Prevention that raises the bar
Detection tells you a takeover is underway. These make it harder to start in the first place:
- Use a registry lock, not just a registrar lock. A registrar lock (
clientTransferProhibited) can be removed by anyone in the account. A registry lock (server-side, such as Verisign Registry Lock for .com) requires manual, out-of-band verification before any change, so a compromised account is not enough on its own. It costs money and slows your own legitimate changes, which is the real tradeoff. - Put two-factor authentication on the registrar account, and use an authenticator app rather than SMS where you can.
- Keep the account recovery email on a different domain from the one you are protecting, so a hijack of one does not lock you out of the other.
- Treat the registrant email as a credential, because it drives every reset and transfer approval. Lock it down the way you would a password.
Where this fits with WebPixie
WebPixie's domain monitoring runs the WHOIS or RDAP check daily across more than 1,000 TLDs and alerts on exactly these changes: a status-flag flip, a registrar change, a nameserver swap, a contact rewrite. Paired with domain expiry monitoring, it covers both ways a domain leaves your control: the renewal you missed, and the transfer you never authorized.
A hijack often surfaces as redirected traffic before anyone checks the registration record, so the resolution layer is worth watching alongside it. What DNS monitoring catches covers that half of the same problem.