Domain hijacking explained: How it happens and how enterprises can prevent it

What is domain hijacking, also known as domain takeover, and why does it matter for enterprise cybersecurity? A compromised domain can disrupt websites, email and critical services, a real exposure hiding in plain sight. Effective protection requires understanding how attackers gain domain control and strengthening the ownership and DNS safeguards that prevent it.

Here’s a number worth sitting with. During a 2024 monitoring initiative, Infoblox found around 800,000 registered domains that were vulnerable to something called the Sitting Ducks attack, a technique where an attacker hijacks abandoned or misconfigured DNS delegation records instead of stealing a password. Of those, roughly 70,000 had actually been hijacked. That distinction matters: this is not a global count of domain hijacking incidents. It shows the scale of one particular weakness.

So why does this keep happening? For enterprises, the problem usually comes down to distributed control. Think about what “owning a domain” actually involves. A corporate domain looks like one simple asset, but in practice, managing it is often a shared responsibility across several teams and providers. One team may handle registration. Another provider may manage DNS. Employees or third parties may have administrative access.. And then there’s the email account used to recover logins on the registrar or DNS side, which is its own quiet dependency most people forget about. It’s a pattern that shows up often in portfolio audits: the dependency nobody flagged turns out to be the actual point of failure.

This is why domain security cannot stop with protecting the registrar account. One layer can be secure while another remains exposed. Sitting Ducks is a good example of exactly that: a domain can point to a DNS provider that no longer actually controls it, letting an attacker claim the domain there without ever touching the registrar account.

What does “protecting a domain” actually mean? Effective domain ownership protection starts with one basic question: who controls each link in this chain, and what depends on it? That question also gives us a useful domain hijacking definition: it’s not about losing a password. It’s about losing legitimate control. In this article we’ll explain how hijacking actually happens, how it differs from related threats, and how enterprises can prevent, detect, and respond to it.

What is domain hijacking?

Domain hijacking happens when someone takes control of a registered domain without the permission of the person or organisation that should control it. That does not always mean stealing the domain outright. An attacker might get into the registrar account, change the nameservers or alter other settings that decide where the domain points and who can manage it.

This is where two terms that are easy to mix up matter. The registrant is the person or organisation that registered the domain and holds the right to use it. The registrar is the company through which the domain is registered and managed. An organisation registering a domain for its business, for example, is typically the registrant, while the company it registered through is the registrar.

That distinction matters because having the domain registered in your organisation’s name is only part of keeping it secure. Someone still needs access to the registrar account, DNS provider and recovery methods used to manage it. Those details also need to stay current. An old email address or forgotten account can become a security problem long before anyone notices something is wrong.For a business-critical domain, that’s really what control means in practice, not just holding the registration, but knowing exactly who can act on it and through what account.

Let’s walk through a simple example. An attacker gains unauthorised access to a company’s registrar account and changes its nameservers. Visitors trying to reach the site are redirected somewhere else entirely. This is a straightforward illustration of what domain hijacking in cyber security actually looks like: legitimate access is used to redirect the domain’s traffic without the registrant’s knowledge.

How does domain hijacking happen?

There is no single route to domain hijacking. An attacker might steal registrar credentials, exploit excessive third-party access, or take advantage of a DNS delegation weakness. Once inside, they can change nameservers, alter registration details or initiate a transfer. The method varies, but the result is the same: the organisation loses control over part of how its domain is managed.

Credential stuffing

One route starts with a password exposed somewhere else entirely. Attackers take usernames and passwords from previous data breaches and try them against registrar accounts, a technique known as credential stuffing.. This works when the same credentials have been reused across different services. In other words, the breach does not need to involve the registrar at all. A password exposed through another service could still give an attacker access to the account controlling the domain.

Multi factor authentication makes that much harder. A stolen password alone is no longer enough to get into the account, which is why it is an important safeguard for registrar access.

Compromised administrative or recovery email

Registrar security often comes down to the email identity used for administration and recovery. If an attacker compromises that mailbox, they may be able to interfere with password resets or account recovery.

This becomes especially difficult for an enterprise when administrative identities are outdated, shared, or poorly protected. Recovery can also become harder if the organisation happens to depend on services affected by the domain incident itself.

Phishing and social engineering

Attackers can impersonate authorised contacts or trusted organisations to obtain login credentials and other sensitive information. Those details can then be used to access domain registrar accounts. Sometimes it’s not even about credentials; attackers may simply try to manipulate people involved in administrative or recovery processes.

So what’s the defence here? Protect privileged credentials and reduce reliance on identities that are easy to impersonate. Transfer and approval procedures can vary, so organisations should follow their registrar’s current processes and the applicable ICANN policy.

Misused or compromised privileged access

Here’s something worth remembering: domain access is rarely limited to one central team. Employees, former employees, agencies, resellers, and other service providers may all have privileges. API credentials can open up another route into administrative functions.

Enterprises need to know who can actually change their critical domains. Named users, third-party accounts, and API credentials all deserve regular review. Access that is excessive, poorly governed, or just quietly left in place creates more opportunities for domain control to be affected.

In practice, the same few weaknesses tend to recur: ownership spread across teams with no single accountable owner, contact details nobody’s updated in years, and third-party access nobody thought to revoke.

Unauthorized domain transfer requests

An attacker may also submit a domain transfer request. Weak transfer protection or outdated contact information can leave an organisation more exposed to an unauthorised transfer.

This is exactly why transfer controls and accurate administrative information form part of protecting a domain. Common transfer controls include registrar lock, sometimes called transfer lock, which prevents a transfer from being initiated at all while enabled. There’s also the EPP authorization code required under ICANN policy, which deserves to be treated with the same care as a password. And many registrars send confirmation requests to the registrant’s administrative email before a transfer is approved. Organisations also need to understand the current transfer procedures used by their registrar.

Registrar compromise

Not every weakness originates inside the organisation. Attackers may target weaknesses in registrar platforms or security settings entirely outside the organisation. 

This is a perfect real-life example of exactly that: in 2024, a flaw in Squarespace’s migration of domains acquired from Google Domains left MFA disabled on migrated accounts. Attackers exploited the gap to hijack domains belonging to several companies and redirect them to phishing sites, without the domain owners doing anything wrong themselves.

That’s why provider choice and escalation arrangements form part of domain governance. An organisation should know which providers can make important changes and what safeguards surround that access. It should also know how to reach those providers quickly when a critical change needs to be stopped or reversed.

Expired domain registrations

This one’s a bit different from the rest. A domain that reaches the end of its registration lifecycle can eventually become available for someone else to register. If the legitimate owner fails to renew it in time, another party may be able to acquire it.

It’s worth being clear about what this is and isn’t: this is a lifecycle risk that needs careful management. It is not the same as an unauthorised takeover of an active registration. This is exactly why Ilkari offers an automated renewal system, helping ensure your domains stay active and protected without relying on manual renewal. 

DNS delegation and authoritative DNS takeover

Here’s a path that catches a lot of people off guard. An attacker does not always need access to the legitimate registrar account. Access to DNS control alone may be enough to redirect website traffic or email towards malicious destinations, without ever changing domain ownership.

This can happen through lame delegation, where a domain’s records point to nameservers that aren’t actually configured to serve it. If the DNS provider on the receiving end also fails to verify ownership before letting someone claim the domain there, an attacker can take control of the domain’s authoritative DNS, the servers that hold the official records for where its traffic should go, all without ever entering the legitimate registrar account.

Real-life documented examples of domain hijacking

Three documented cases show how phishing, a flawed provider migration, and a DNS misconfiguration each led to real domains being seized and redirected, none through a stolen password.

Phishing and social engineering: a fake login page, 2023

An attacker ran search ads for a fake registrar login page. A domain administrator entered their credentials there without realizing it wasn’t real, and the attacker used those credentials to log straight into the actual registrar account.

From there, the domain was transferred to a different registrar entirely. The organisation had a transfer lock in place, and it didn’t stop the transfer, part of a documented case of credential theft leading to domain hijacking through phishing sites.

Registrar compromise: a flawed migration, 2024

Squarespace migrated roughly 10 million domains from Google Domains in 2024. Weak security defaults left multi-factor authentication switched off on every migrated account, and attackers found the gap within days, exploiting it between July 9 and July 12.

The hijacked domains belonged to real, operating businesses, including a decentralised lending platform holding over $2 billion in customer assets, a blockchain interoperability protocol whose bridge had processed over $200 million in transfers the previous month, and a yield-trading platform used by thousands of investors. All were seized and redirected to phishing sites at the same time, through no fault of their own security practices.

DNS delegation: Sitting Ducks, ongoing since 2018

Sitting Ducks exploits lame delegation, a DNS misconfiguration where a domain’s nameserver records point to a provider that isn’t actually configured to serve it. An attacker who spots the gap can claim the domain there directly, without the registrar account ever being touched or showing any sign of compromise.

Infoblox’s 2024 monitoring found roughly 800,000 domains vulnerable to this exact weakness, and about 70,000 already hijacked.

Domain hijacking vs DNS hijacking and related threats

These four terms get lumped together a lot, but they’re different problems, and mixing them up can lead an organisation to protect against the wrong thing. Domain hijacking, DNS hijacking, spoofing and cybersquatting get lumped together a lot, but they’re different problems, and mixing them up can lead you to protect against the wrong thing. A useful way to tell them apart is to ask one simple question: what does the attacker actually control or abuse? It could be the genuine domain, its DNS resolution, an imitation of the brand, or a separately registered domain. 

DNS hijacking

DNS hijacking happens when someone changes a domain’s DNS records without permission. Nameserver records work like a forwarding address: when someone types in a company’s domain, these records tell the internet where that request should actually go.

If those records are improperly configured or compromised, sometimes called domain name system hijacking, an attacker can change that forwarding address without ever touching the company’s actual domain account, sending visitors somewhere else entirely. This DNS domain hijacking risk can expose users to phishing schemes, malware infections, or theft of sensitive data. It exists whether or not the organisation still retains ownership of the registered domain itself.

DNS spoofing

DNS spoofing is a different threat, despite the similar name. DNS hijacking targets a domain’s own nameserver records. DNS spoofing, also called cache poisoning, targets a resolver elsewhere on the network instead, introducing forged DNS information into its cache. The resolver ends up returning an incorrect IP address for the domain.

The result: traffic meant for the legitimate website may end up somewhere else entirely, including a machine controlled by an attacker.

Domain spoofing

Domain spoofing works differently. The attacker never takes control of the genuine domain at all. Instead, they create something close enough to fool people: a lookalike domain like it could be paypa1.com instead of paypal.com, a copycat website, or an email that appears to come from a trusted sender.

The main difference is that in this case the legitimate organisation keeps full control of its real domain throughout. The security problem isn’t loss of control. It’s impersonation, playing out in the inboxes and browsers of people who never touch the real domain at all.

Cybersquatting

Cybersquatting is a different problem entirely. Someone registers a separate domain in bad faith, hoping to profit from another company’s trademark or brand. It might be a domain that matches the trademark outright, the brand name under a different top-level domain, a “.net” instead of a “.com”, say, or a common misspelling designed to catch people typing too fast.

A similar domain isn’t necessarily cybersquatting. It takes more than resemblance to prove that. ICANN’s Uniform Domain-Name Dispute-Resolution Policy lays out what actually has to be shown before a dispute holds up.

Why is domain hijacking particularly risky for enterprises?

Domain hijacking can be particularly risky for them because one domain may support several important services all at once. Losing control can affect much more than a public website. Operations, communications, and customer facing systems may all depend on that same single domain. 

The first question worth asking is a practical one: what depends on this domain?  A primary corporate domain, one that’s actually running live services, can have a very different risk profile from a defensive registration the company holds but never actively uses.

Operational disruption: Changes to DNS or domain control may interrupt websites, applications, portals, APIs, and other services.

Email and identity risk: A domain can support corporate email and trusted communications. And here’s the part people often miss: a compromise may also interfere with account recovery for other services, since password resets often depend on this domain’s email addresses.

Customer and brand trust: An attacker controlling an established domain may benefit from its existing reputation while directing users towards malicious content.

Revenue and digital performance: Domains connected to ecommerce, campaigns, or lead generation can create commercial exposure when disrupted.

Legal and regulatory exposure: This one depends heavily on the specifics. The consequences depend on the incident, affected systems, and applicable law. Domain hijacking does not automatically mean a data breach or regulatory violation.

Third-party dependencies: Registrars, DNS providers, agencies, SaaS services, and other providers can make both the control chain and recovery process more complicated.

For an organisation managing a whole portfolio of domains, one question can make prioritisation much easier: what stops working if this domain is lost? In practice, the domains worth protecting most aren’t always the ones with the most visible traffic. They’re the ones quietly holding up email, authentication or revenue in the background. That’s a far more useful way to think about it than treating every registration exactly the same.

How to prevent domain hijacking

Domain hijacking prevention begins with visibility, accountability and controlled administration. Enterprises need to know which domains they control, who can administer them, and which services depend on them. A secure registrar account is only part of that protection. Administrator identities, DNS, transfer controls, renewals, and monitoring also need attention, with stronger domain ownership protection applied to the domains the business depends on most.

• Choose a reputable registrar: Don’t just go with the cheapest or most familiar name. Look beyond price and name recognition. Assess authentication, administrative controls, lock options, and incident support. The registrar should also support the top level domains (TLDs) and controls the organisation requires.
• Use strong authentication: Apply strong authentication to registrar and DNS accounts, as well as the email accounts used to recover them. MFA helps, but it’s not a silver bullet: it does not address DNS delegation weaknesses or every form of third party compromise.
• Limit access: Give domain administration privileges only to the people and providers that need them. Review administrators regularly. Remove access for former employees and suppliers promptly. And don’t forget: external administrators and API credentials should be reviewed alongside internal users.
• Enable WHOIS protection: WHOIS protection reduces unnecessary public exposure of domain registration details. It’s worth being clear about what it actually does: it does not guarantee protection against takeover. By limiting exposed contact information, it can add a layer of protection against attempts to use that information for social engineering or identity theft. Enterprise domain protection services, such as Ilkari’s Premium WHOIS Protection, mask ownership information across hundreds of TLDs. Learn more about Ilkari’s Premium WHOIS Protection
• Protect registration and transfers: Registrar locks, transfer locks and registry locks sound similar and often get used interchangeably, but they’re not the same thing. A registrar lock, sometimes called a transfer lock, restricts certain changes made through the registrar, a transfer lock helps prevent the domain from being moved to another registrar and, a registry lock adds another layer of protection at the registry level and is particularly useful for critical domains. None of these offer a complete solution on its own though, and requirements vary by registrar and registry, so current documentation should be checked before relying on any one of them.
• Secure DNS control: Treat nameserver changes and authoritative DNS permissions with the same care as registrar access. Limit access to the people who genuinely need it, check that domain delegations still point where they should, and keep an eye on sensitive DNS changes. Use DNSSEC where appropriate. 
• Monitor renewals and the domain lifecycle: If a business critical domain expires, the organisation risks losing control of an asset that websites, email or other services may depend on. Give someone clear responsibility for renewals. Keep payment and administrative details current, and monitor expiry dates. The same care is needed when retiring a domain. Old DNS records and connections to other services can remain in place long after the domain is no longer actively used.
• Monitor for unauthorised changes: Watch for unexpected changes to registration information, domain status, nameservers, and important DNS records. Use current RDAP (Registration Data Access Protocol) records, the modern replacement for WHOIS lookups, where appropriate. Keep ownership evidence and registrar correspondence somewhere accessible so they can support a recovery claim if control is disputed. 

What should a company do if its domain is hijacked?

If a company suspects domain hijacking, the first priorities are containment and accurate diagnosis. Secure the identities and systems that could let the attacker keep control, then work out whether the problem involves registration administration, authoritative DNS, a recovery identity, or an inter-registrar transfer.

The answer determines which providers need to act and what needs to be restored. the answer determines which providers need to act and what needs to be restored.

• Contain privileged access: Secure registrar, DNS, and linked recovery accounts. Revoke unauthorised sessions and protect remaining privileged identities that could be used to regain control.
• Gather evidence and identify the affected layer: Preserve registration, DNS, and account evidence. Check nameservers, domain status, and transfer information to establish what changed.
• Contact the relevant providers: Notify the appropriate registrar immediately. Alert DNS, hosting, or email providers when their platforms are part of the affected control chain.
• Restore legitimate control: Restore authorised DNS and services. Review affected systems for unauthorised changes and remove access or configurations that could allow continued control.
• Communicate and assess downstream exposure: Loop in legal and communications teams early, and inform staff or customers only once the available evidence shows they face a genuine risk.
• Escalate, report and harden: Follow applicable registrar, registry, or transfer dispute processes. Review the incident and strengthen access, locking, monitoring, and recovery preparation.

Enterprises that recover fastest tend to have this ready before anything happens: a registrar escalation contact that isn’t a general support form, ownership documentation on hand, and a current map of which services depend on each critical domain

Worth remembering: there is no universal administrative shortcut for recovering a hijacked domain, and filing a complaint does not by itself guarantee restoration. The relevant process depends on what actually happened. TDRP, the Transfer Dispute Resolution Policy,*addresses unauthorised transfers between registrars, while UDRP deals with abusive registrations such as cybersquatting rather than ordinary unauthorised transfers. Knowing which one applies is often the first thing legal counsel or the registrar will need to confirm.

Conclusion

Domain hijacking is, at its core, a loss of control over an important digital asset. Protecting that asset requires more than securing a registrar login. Enterprises need ongoing visibility over ownership, privileged access, DNS, renewals, and the services that depend on important domains.

The level of protection should reflect what the domain supports. A domain used for email, authentication, or customer services deserves governance that matches those dependencies. The rule of thumb is simple: the more the business relies on a domain, the more carefully its control should be managed. Domain security is an ongoing responsibility, not something that can be configured once and forgotten.

For enterprises managing large or complex domain portfolios, this is best approached as a matter of enterprise domain management rather than a single team’s responsibility. Treating business critical domains with the same discipline as other essential infrastructure, with clear ownership, active monitoring, and a defined escalation path, is what turns domain security from a reactive fix into a lasting safeguard.