Assess my case

What is Domain hijacking? Definition and meaning

Domain hijacking is the unauthorized transfer of a domain name's registration from its legitimate holder to another party, achieved by exploiting a registrar's account systems, abusing the transfer process, or compromising the registrant's credentials.

Domain hijacking sits at the intersection of a technical breach and a legal harm. The registrant's name disappears from the registration record – replaced by a stranger's – and with it goes control over DNS, email routing, and any web service tied to that name. The remedy depends on speed: registrars can reverse unauthorized transfers within defined windows, but once those windows close, court action or a specialist escalation process is usually the only path back. Recovery is possible but not guaranteed, and every day of delay narrows the options.

This page defines domain hijacking precisely, separates it from the term most often confused with it, traces it through the applicable rules, and maps the fact patterns that practitioners most commonly see.

What domain hijacking is – and what it is not

Domain hijacking is an unauthorized act: a change to the registration record that the legitimate holder did not authorize and would not have authorized. The change is typically a registrar-to-registrar transfer, a change of registrant contact (a "push" or ownership change within the same registrar), or a modification of the name servers that redirects traffic without touching the ownership record at all.

The term people most often confuse it with is cybersquatting. Cybersquatting – the subject of the UDRP – is opportunistic: a third party registers a domain that is identical or confusingly similar to someone else's trademark, exploiting the gap between the mark and the registry. Domain hijacking targets a domain that is already registered and already belongs to the victim. No bad-faith registration decision was made; instead, an existing registration was stolen. That distinction matters enormously for the remedy: the UDRP governs who should hold a domain, not who actually holds it after a theft. A hijacking claim belongs in a different forum.

Domain hijacking is equally distinct from domain dispute in the UDRP sense. A UDRP panel weighs rights and bad faith at the time of registration. A hijacking recovery proceeding asks a simpler factual question: was this transfer authorized by the legitimate registrant?

Where domain hijacking sits in the governing rules

No single international treaty governs domain hijacking directly. The rules that matter most are the contractual ones – the registrar's terms of service, the ICANN Registrar Accreditation Agreement (RAA), and the transfer policies that flow from it.

ICANN's Inter-Registrar Transfer Policy sets conditions that must be satisfied before a registrar-to-registrar transfer can proceed. Among them: the registrant must expressly authorize the transfer, typically via a confirmation email sent to the address of record. A hijacking often works by first compromising the email account, then authorizing the domain transfer. The compromised email account is the attack surface; the domain transfer is the visible symptom.

The RAA requires registrars to respond to abuse reports and to cooperate with legitimate transfer-reversal requests. Since 5 April 2024, amendments to ICANN's Registrar Accreditation Agreement have introduced explicit DNS abuse obligations – requiring contracted parties to take prompt, reasonable and appropriate action on well-evidenced abuse. Those obligations do not directly adjudicate ownership, but they create a lever: a well-drafted abuse report referencing the RAA obligations, submitted quickly, can trigger a registrar hold that prevents further transfers while the matter is resolved.

The UDRP does not apply to hijacking. A UDRP panel may note that a registrant's account was compromised, but the Policy's three elements – confusing similarity, no legitimate interest, and bad faith at registration – do not map onto a theft scenario where the hijacker never made a registration decision. National courts and, in some zones, specialist registrar escalation procedures are the primary routes.

How domain hijacking happens: three recognizable patterns

Practitioners see the same mechanics recur across gTLDs and ccTLDs. Understanding the pattern tells you where the evidence will be and which recovery route is viable.

Pattern 1 – Social engineering of the registrar. The attacker contacts the registrar's support team, impersonates the registrant, and persuades an agent to change the email address of record or issue a transfer authorization code (auth code). This is a people problem, not a technology problem. The evidence trail lives in the registrar's support ticket logs, and the best countermeasure is registrar lock combined with a registrar that requires multi-factor authentication before any account change.

Pattern 2 – Email account compromise followed by silent transfer. The attacker first gains access to the email account associated with the domain registration. The registrar sends the standard transfer-authorization email; the attacker approves it; the domain moves. The registrant discovers the loss only when the site goes dark or the email stops. This pattern often leaves a window for recovery under the Inter-Registrar Transfer Policy's dispute period – but only if the victim acts within that window. Delay is the enemy.

Pattern 3 – DNS hijacking without a registrar transfer. Here, ownership of the domain record does not change – only the name server entries do. The attacker modifies the DNS so that traffic reaches a server they control, while the WHOIS or RDAP record still shows the legitimate registrant. Visitors see a convincing copy of the real site; the registrant sees nothing wrong until reports arrive. This pattern is technically domain hijacking but creates a different legal posture: the registrant still owns the domain but has lost operational control. The remedy is a DNS change reversal, usually a registrar-level change of name servers, combined with investigation of how the attacker gained access to the registrar account.

Why this term matters to registrants and brand owners

A hijacked domain is an immediate operational emergency. Email breaks. The web presence disappears or, worse, impersonates the legitimate holder. If the domain supports a payment workflow or a customer authentication system, the consequences extend well beyond inconvenience.

The legal consequences compound if recovery is delayed. Most registrar transfer-reversal policies run on tight timelines – often measured in days, not weeks. Once a domain is re-registered or transferred a second time, tracing and recovering it becomes substantially harder. Courts can and do order transfers back to legitimate holders, but litigation timelines are longer than the windows registrar policies provide. Speed of action is therefore a legal requirement, not merely a preference.

The distinction between domain hijacking and ordinary domain dispute also matters for insurance and for internal IT governance. A hijacking is a security incident; it should trigger incident-response procedures, registrar escalation, and in serious cases, an application to a court for emergency injunctive relief. A court recovery action may be the correct route when registrar escalation fails or when the domain has already moved through multiple registrars.

For brand owners with large portfolios, the preventive posture matters as much as the recovery route. Registrar lock – a status that blocks transfers and DNS changes unless the lock is explicitly removed – is the primary technical defense. The guide registrar lock escalation io explains how the lock mechanism works and how to escalate when a registrar's process stalls.

Related terms and common misconceptions

Three related terms often appear alongside domain hijacking, and each describes something meaningfully different.

Reverse domain name hijacking (RDNH) is a finding a UDRP or DRS panel makes against a complainant, not a registrant. It means the complaint was filed in bad faith to deprive a legitimate registrant of their domain. The phrase is a term of art in arbitral proceedings; it has nothing to do with technical theft of a registration. See also the concept of What is Mutual jurisdiction clause? Definition and meaning, which governs where a losing complainant may be sued after a UDRP proceeding.

Registrar lock (also styled the EPP "clientTransferProhibited" status) is the principal preventive control. It does not prevent all forms of hijacking – a sufficiently skilled attacker who compromises both the registrar account and the associated email can still effect a transfer – but it eliminates the most common attack vector.

Domain theft is a colloquial synonym for domain hijacking. The two terms describe the same event; "domain hijacking" appears more frequently in registrar policies and legal filings, while "domain theft" is common in trade press and incident reports.

A myth worth addressing directly: some registrants assume that because arbitration handles domain disputes, it will also handle hijacking. For most hijacking cases that is not the position. The UDRP was designed for bad-faith registration, not for unauthorized transfers. Court action – or, as a faster first step, registrar escalation backed by the RAA obligations – is the correct route for a genuine theft.

COGNOMEN focuses exclusively on domain-name disputes. We handle court action and domain theft recovery, assess the technical and legal record of the incident, escalate to registrars under applicable policies, and where necessary pursue court proceedings with local litigation counsel in the relevant jurisdiction. For an assessment of your domain situation, contact info@cognomenlaw.com.

Related at COGNOMEN

Frequently asked questions

What is domain hijacking?

Domain hijacking is the unauthorized transfer or modification of a domain name's registration record, removing it from the legitimate holder's control without their consent. It is achieved through account compromise, social engineering of a registrar, or exploitation of the transfer authorization process. Unlike cybersquatting – which involves bad-faith registration of someone else's mark – hijacking targets a domain that already belongs to the victim. The UDRP does not govern it; registrar escalation and court action are the primary remedies.

How is domain hijacking proven or established?

A hijacking claim typically rests on three categories of evidence: proof of the legitimate holder's original registration (RDAP or WHOIS history, registrar records, invoices), documentation of the unauthorized change (transfer confirmation emails the victim never sent, support-ticket logs, DNS change records), and evidence of the attacker's conduct (IP access logs, phishing emails, social-engineering correspondence). Courts and registrars both assess whether the registrant actually authorized the transfer. If no authorization was given – and the record shows that – the case for reversal is strong, though outcome depends on the specific facts and the registrar's cooperation.

Why does domain hijacking matter to my domain?

A hijacked domain breaks email, takes down web services, and can expose your customers to fraudulent impersonation of your brand. The legal harm compounds with delay: most registrar transfer-reversal windows are short, and once a domain moves through a second transfer, recovery becomes harder and costlier. Acting within the registrar's dispute window – and seeking legal advice immediately – preserves options that close quickly. If you believe your domain has been hijacked, contact info@cognomenlaw.com for an assessment of the situation and the recovery routes available.

Author: — Court anticybersquatting and domain theft recovery. Meet the team.

Speak with Cognomen Law

For a scoped view of your domain matter, contact info@cognomenlaw.com. Discuss your matter

No obligation. Confidential. We reply within two hours in business hours.

This publication is general information and does not constitute legal advice. For advice on your situation, contact info@cognomenlaw.com.