Domain hijacking is the unauthorised takeover of a domain's registration or DNS settings, usually by compromising the account at the registrar, so that the attacker can point the domain at infrastructure they control. For a Web3 project, that means users who type the correct address and see a familiar interface can be served a cloned frontend that asks them to sign token approvals or transfers to the attacker. No smart contract needs to be exploited.
The attacks against crypto projects that are documented in public post-mortems did not rely on breaking DNS cryptography. They relied on the weakest step in the chain of trust: a registrar's support desk, an account recovery process or a platform vulnerability. That is why the most effective controls are operational, and why they belong in a security programme rather than being left to whoever bought the domain.
What Domain Hijacking Is, and What It Is Not
Several attacks redirect users to the wrong server, and the controls differ for each:
- Domain hijacking changes the authoritative record of the domain itself, typically the nameservers set at the registrar. Every resolver on the internet then follows the attacker's instructions until the change is reversed and caches expire.
- DNS record tampering changes records inside the DNS hosting account (for example an A or CNAME record) without touching the registration.
- DNS cache poisoning and BGP hijacking manipulate how resolvers or networks reach the legitimate infrastructure, rather than the domain's configuration. These are covered in our guide to man-in-the-middle attacks in crypto.
This article focuses on the first two, because they are where crypto projects have repeatedly lost control.
How It Has Happened to Crypto Projects
Balancer, September 2023: social engineering of the registrar
Balancer's post-mortem states that at around 00:42 CET on 20 September 2023 an attacker changed the nameservers for balancer.fi after a successful social engineering attack on EuroDNS, the registrar for the domain. Balancer says no one on its frontend team lost credentials or was infected with malware. A forked phishing frontend asked users to approve tokens to malicious addresses. Balancer reports that EuroDNS did not respond until around 08:30 CET and that control was not returned until around 10:30 CET. A community estimate of losses cited in the post-mortem was $364,000.
Galxe, October 2023: forged documents at the registrar
Galxe's incident statement records that on 6 October 2023 an individual impersonated an authorised member of Galxe, contacted the support team at its registrar Dynadot, and used falsified documentation to have the account credentials reset. At 06:02 PDT the attacker changed the nameservers. Galxe estimated that around 1,120 users were affected and around $270,000 was stolen. Its response included taking down the API gateway to its backend and revoking all access tokens, and wallet partners temporarily flagged the domain as a phishing site.
dYdX, July 2024: a platform weakness, then account recovery abuse
The dYdX post-mortem describes two separate takeovers of dydx.exchange after the domain was migrated from Google Domains to Squarespace. On 9 July 2024, attackers changed the nameservers, but the attack was mitigated because DNSSEC remained configured at the registrar, so validating resolvers rejected the forged answers. Squarespace later confirmed an exploited issue with OAuth logins, fixed on 12 July. On 23 July, a second takeover succeeded: dYdX states that Squarespace customer service reset the account in a human-initiated recovery that bypassed the 2FA on every admin account, without contacting the other listed admins. This time the attacker also removed DNSSEC. dYdX reports two affected users and approximately $31,000 lost, and moved the domain to another registrar.
Several other DeFi projects using Squarespace reported hijacking attempts in the same period, and the Security Alliance (SEAL) coordinated an industry incident response.
In each documented case, the attacker never needed the project's own passwords or hardware keys. They persuaded or bypassed someone else's process. A domain is only as secure as the least careful person who can change it on your behalf.
What Attackers Do With a Hijacked Domain
The pattern in public reports is consistent. The attacker serves a copy of the real frontend with modified wallet interactions. Balancer's post-mortem describes token approvals, permit signatures and Permit2 transactions being used depending on what each victim held. Because approvals can outlive the session, a victim may lose tokens they receive later. Galxe's statement shows a further risk: once an attacker controls a domain, anything that trusts that domain, such as API endpoints, cookies, OAuth redirects and email, may also be exposed. Its decision to take down the API gateway and revoke access tokens reflects that.
Registrar and Registry Controls
Choose a registrar for its security process, not its price
The registrar is now part of your attack surface. Before you rely on one, check whether it supports hardware security keys for account login, whether it allows multiple named administrators with role separation, and, critically, what its support desk will do when someone claims to have lost access. The dYdX and Galxe incidents both turned on recovery processes. Ask the registrar in writing how account recovery works and whether it can be restricted to require confirmation from more than one listed administrator.
Registry lock, not just registrar lock
ICANN's EPP status codes distinguish between client statuses, set by the registrar (for example clientTransferProhibited and clientUpdateProhibited), and server statuses, set by the registry (serverUpdateProhibited, serverDeleteProhibited and serverTransferProhibited). A registrar lock can be removed by anyone who controls the registrar account. A registry lock applies the server statuses. Verisign's service description, filed with ICANN, states that changes to a locked domain follow a secure, authenticated process: an authorised individual at the registrar requests removal, Verisign validates that individual, the change is made, and the lock is reinstated. Verisign also notes that nameserver host records can be locked separately and that combining registry and registrar locks helps stop nameserver re-delegation attacks. For a domain that fronts a protocol, registry lock turns a ten-minute takeover into a multi-party process. Availability depends on the top-level domain and registrar, which is one reason Balancer said it was considering moving away from the .fi domain.
Treat domain administration as privileged access
- Use dedicated administrator accounts with hardware key MFA, not a founder's personal email.
- Keep the registrant contact email on a domain different from the one being protected, so a hijack cannot also capture password reset mail.
- Review who can change the domain at least quarterly and remove former staff promptly, as you would for any privileged access.
- Record the registrar account, recovery contacts and escalation numbers in the incident response plan before you need them.
DNS and Certificate Controls
- DNSSEC. Signing the zone means that, for users behind validating resolvers, forged answers fail validation. The first dYdX hijack shows the value. The second shows the limit: an attacker with full registrar access can remove the DS record, so DNSSEC complements registry lock rather than replacing it.
- CAA records. Certification Authority Authorization records restrict which certificate authorities may issue certificates for the domain. They will not stop an attacker who controls the nameservers from changing them, but they reduce the options for mis-issuance through other routes.
- Separate DNS hosting and registrar accounts. Splitting registration and DNS hosting between providers, each with its own hardware key protected admin accounts, means one compromised account is not enough to change everything.
- Frontend integrity. Content Security Policy, Subresource Integrity for third-party scripts, and published build hashes or an alternative content-addressed mirror give users and wallets more ways to detect that something has changed. These overlap with supply chain defences, since a compromised dependency produces the same outcome as a compromised domain.
Detection: Knowing Within Minutes
Balancer's users noticed the attack because the interface asked them to approve tokens to an address beginning and ending in zeros. That is not a detection strategy. Monitoring that would have alerted the team directly includes:
- Polling the registry (via RDAP or WHOIS) for changes to nameservers, DS records and EPP status codes, with alerts on any change.
- Monitoring the A, AAAA, CNAME and NS records served by public resolvers from several regions.
- Watching Certificate Transparency logs for new certificates issued for the domain or its subdomains.
- Synthetic checks that load the production frontend, hash the served JavaScript bundles and alert if they differ from the deployed build.
- Routing these alerts into the same on-call process as protocol monitoring. Our guide to Web3 SIEM and security logging covers alert design.
The First Hour: A Response Playbook
- Warn users immediately on every official channel, telling them not to connect wallets or sign anything on the domain. Both Balancer and Galxe did this within about an hour of detection.
- Contact wallet providers and security partners to get the domain flagged. Galxe reports that MetaMask and Coinbase Wallet temporarily marked the site as phishing, and dYdX worked with SEAL and wallet teams to block the malicious site.
- Escalate with the registrar using the pre-agreed emergency contacts. Balancer's experience of several hours without a response shows why these must be established in advance.
- Protect what trusts the domain. Take down or isolate APIs, revoke sessions and tokens, and check whether email for the domain could have been intercepted.
- Publish revocation guidance listing the malicious spender addresses so users can revoke approvals and permits.
- Preserve evidence, including registrar logs, DNS history and the malicious bundle, for the post-mortem and any law enforcement report.
Communication during the incident matters as much as the technical fix. Our guide to crypto crisis communications covers sequencing and wording.
Mapping Controls to Attack Paths
| Attack path | Preventive control | Detective control |
|---|---|---|
| Registrar support desk social engineering | Registry lock; registrar with restricted, multi-admin recovery | Registry status and nameserver change alerts |
| Account recovery bypassing 2FA | Registry lock; written recovery policy; recovery contacts on a separate domain | Alerts on admin and contact changes where the registrar supports them |
| Registrar platform vulnerability | Registry lock; DNSSEC | Nameserver and DS record monitoring |
| DNS hosting account compromise | Hardware key MFA; separate DNS and registrar accounts | Resolver record monitoring; bundle hash checks |
| Malicious certificate for the domain | CAA records | Certificate Transparency monitoring |
Frequently Asked Questions
What is domain hijacking in crypto?
Domain hijacking is the unauthorised takeover of a project's domain registration or DNS settings so that its website points to attacker-controlled infrastructure. In crypto, the attacker typically serves a cloned frontend that asks users to sign token approvals, permits or transfers that drain their wallets.
How do attackers hijack a crypto project's domain?
Public post-mortems show three main routes: social engineering of the registrar's support desk (Balancer and Galxe in 2023), abuse of account recovery processes that bypass 2FA (dYdX in July 2024), and vulnerabilities in the registrar's own platform, such as the Squarespace OAuth issue in July 2024.
What is the difference between registrar lock and registry lock?
A registrar lock uses client EPP statuses that anyone controlling the registrar account can remove. A registry lock uses server statuses set by the registry, and removing it requires an authenticated request that the registry validates independently, which makes it far harder for an attacker with registrar access to change nameservers.
Does DNSSEC stop domain hijacking?
DNSSEC helps but is not sufficient alone. In the first dYdX incident in July 2024, DNSSEC caused validating resolvers to reject the forged nameserver answers. In the second, the attacker had full registrar access and removed DNSSEC. It should be combined with registry lock and monitoring.
What should a protocol do in the first hour of a domain hijack?
Warn users on all official channels not to connect wallets, ask wallet providers and security partners to flag the domain, escalate with the registrar through pre-agreed contacts, isolate APIs and revoke sessions that trust the domain, and publish the malicious spender addresses so users can revoke approvals.
Sources
- Balancer: DNS Security Incident Post Mortem (3 October 2023)
- Galxe: October 6th DNS Security Incident Statement and Guide
- dYdX: DNS Nameserver Hijacking Postmortem
- BleepingComputer: DNS hijacks target crypto platforms registered with Squarespace (12 July 2024)
- ICANN: EPP Status Codes, What Do They Mean and Why Should I Know?
- Verisign: Registry Lock Service Status
- ICANN Registry Request Service: Verisign Registry Lock proposal (2009)