---
id: "domain-hijacking"
kind: "glossary-term"
title: "domain hijacking"
language: "en"
category: "Security and abuse"
updated: "2026-10-10T10:28:55Z"
canonical: "https://tldlog.com/glossary/domain-hijacking/"
translations:
  es: "https://tldlog.com/es/glosario/secuestro-dominio/"
  de: "https://tldlog.com/de/glossar/domain-hijacking/"
  fr: "https://tldlog.com/fr/glossaire/detournement-nom-domaine/"
  it: "https://tldlog.com/it/glossario/furto-dominio/"
  pt-BR: "https://tldlog.com/pt/glossario/sequestro-dominio/"
  ru: "https://tldlog.com/ru/glossariy/ugon-domena/"
  zh-Hans: "https://tldlog.com/zh/cihui/yuming-jiechi/"
---

# domain hijacking

Taking control of someone's domain name without permission, for example by stealing registrar account passwords, misusing an auth code or tricking support staff. The attacker may change name servers or transfer the name away. Transfer locks, registry lock and two-factor login reduce the risk.

Domain hijacking means someone takes control of a domain name away from its rightful holder without permission. The attacker can then send the website and email elsewhere, or move the name to another account. Getting it back can be slow, so prevention and good records matter.

## What domain hijacking is

ICANN's SSAC defined it in 2005 as "the wrongful taking of control of a domain name from the rightful name holder", a term covering several kinds of attack. Two outcomes are common: the attacker changes the DNS so that a name server the holder does not run answers for the domain, or changes the contact details and takes the domain outright.

The harm includes lost email, phishing sites on a trusted name, eavesdropping, defaced websites and extortion. Customers and partners are often hit too, and the SSAC stresses that even a temporary loss of control is serious.

## How domains are stolen: accounts, DNS and forgotten records

**Accounts.** Attackers guess or steal passwords, phish them, or trick the holder or registrar staff. Some attack the registrar or registry directly. Older cases used public WHOIS data and re-registered the expired domain behind an administrative contact's email address. Once inside, an attacker can change name servers, contacts and locks, or transfer the name.

**DNS.** Changing where a domain points is a common goal. DNS hijacking changes the answers. Cache poisoning needs no account: forged answers are planted in a resolver, which repeats them to its users.

**Forgotten records.** Some hijacks need no password. If example.com uses name servers under example.net and example.net lapses, whoever registers it next can control where example.com points. A 2024 SSAC report cites research finding that, as of September 2020, a related registrar practice, renaming name servers to "sacrificial" domains anyone can register, had exposed over 500,000 domains in gTLDs and put the resolution of over 163,000 under unauthorized control. A lame delegation or a record pointing to an abandoned outside service opens similar gaps.

## Signs your domain has been hijacked

None of these proves a hijack, but each deserves a check:

- a registrar notice about a change you did not make, or a transfer you did not request;
- a WHOIS or RDAP lookup showing locks removed or different name servers;
- email that stops arriving, or a website showing content that is not yours.

## How to protect your domain

The SSAC says locks and authorization codes "can prevent some hijacking incidents"; no measure guarantees safety. ICANN and its SSAC advise:

- a different password for each account, and 2FA or another multi-factor login where the registrar offers it (this varies by registrar);
- registrar locks (clientTransferProhibited, clientUpdateProhibited), and a registry lock as a second layer;
- contact email on a mail server outside the domain, so a changed DNS cannot block the notices;
- current contact details and timely renewal;
- treating every notice as a reason to check, logging in directly instead of following email links, and removing access for staff who leave;
- monitoring status and DNS answers, and DNSSEC signing and validation;
- proof kept in advance: registration and billing records, logs, registrar correspondence, legal and tax documents.

## Recovering a hijacked domain

For gTLDs, the main rules are ICANN's Transfer Policy, in the version published 21 February 2024 and in force as of October 2026. ccTLDs such as .es follow their own registry rules, so holders should check with their registrar or registry.

1. **Contact your registrar at once.** ICANN gives this as the first step.
2. **Prove your prior link to the name** with the records above.
3. **The registrar uses the TEAC**, an emergency channel reserved for registrars, registries and ICANN staff. As of October 2026, a first answer is due within 4 hours.
4. **The registry undoes the transfer** within five calendar days of a valid notice, for example both registrars agreeing it was a mistake or broke the policy, a court order, or proof that the gaining registrar missed the TEAC deadline. After a registry dispute decision it has fourteen calendar days, unless a court action is filed.
5. **If the registrars disagree,** as of October 2026 the losing registrar, not the holder, may file under the TDRP within 12 months.
6. **The holder can submit an Unauthorized Transfer Complaint to ICANN**, but ICANN cannot require a registrar to return a name. Courts remain an option; a lawyer can advise. The UDRP is for trademark disputes, not account theft.

Example: the holder of example.com gets a notice that its name servers changed, logs in directly and finds the name at another registrar. The holder calls their registrar and sends invoices and past registrar emails, and the registrar contacts the other registrar's TEAC. No result is guaranteed.

### Changes adopted in 2026, not yet in force

On 7 June 2026 the ICANN Board adopted all 47 recommendations of the Transfer Policy Review. As of October 2026 they still need implementation and have no effective date. The TEAC would have 24 hours to answer instead of 4, first contact would be expected within 720 hours of the loss, and updates would follow at least every 72 hours. Transfers would be restricted for 720 hours after registration and after a transfer, and the 60-day lock after a change of registrant would end. Holders would be notified within 10 minutes of a Transfer Authorization Code (TAC) being issued and within 24 hours of a registrant data change. A dispute route for registrants is only to be studied.

## Related attacks: DNS hijacking and subdomain takeover

- **DNS hijacking:** control of the DNS answers, not of the registration.
- **Cache poisoning:** forged answers in a resolver.
- **Subdomain takeover:** a leftover record pointing to a resource someone else can claim.
- **Sitting Ducks attack:** a lame delegation claimed at a DNS provider.
- **Expired domain takeover:** a domain others depend on is left to lapse.
- **Domain shadowing:** hidden subdomains added through a stolen account.

## Sources

- [A Registrant's Guide to Protecting Domain Name Registration Accounts (SAC 044)](https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-044-en.pdf)
- [Transfer Policy (version published 21 February 2024)](https://www.icann.org/en/contracted-parties/accredited-registrars/resources/domain-name-transfers/policy)
- [About Unauthorized Transfers and Changes of Registrant - ICANN](https://www.icann.org/resources/pages/unauthorized-2013-05-03-en)
- [Transfer Policy Review PDP WG Final Report (dated 4 February 2025)](https://gnso.icann.org/sites/default/files/policy/2025/correspondence/tpr-team-to-gnso-council-04feb25-en.pdf)

## related terms

- [registry lock](https://tldlog.com/glossary/registry-lock/)
- [transfer lock](https://tldlog.com/glossary/transfer-lock/)
- [auth code](https://tldlog.com/glossary/auth-code/)
- [DNS hijacking](https://tldlog.com/glossary/dns-hijacking/)