Domain Mayday EP05: The 2024 Squarespace DeFi Domain Mass-Hijack

In July 2024, the most dangerous thing about a crypto project's website was not a smart-contract bug or a leaked private key. It was the registrar that owned the domain.

For a stretch of days that month, users who typed a familiar address into their browser — the official site of a lending protocol they trusted, a bridge they had used a hundred times — landed exactly where they expected, on a page that looked exactly right, and then watched their wallets drain. Nothing had been hacked in the usual sense. No one had cracked a password or phished a seed phrase. The attackers had simply walked in through the front door of the domain itself, because that front door had been left unlocked during a corporate move most of these projects never noticed.

The move was the migration of Google Domains to Squarespace. The unlocked door was Squarespace's authentication defaults. And the result was a coordinated wave of DNS hijacks against crypto and DeFi projects controlling, in the words of one researcher, billions of dollars of assets.

How a registrar migration created a mass attack surface

Domains are not usually thought of as a fleet. Each one feels like a single, private thing — your address, your control panel, your DNS records. But registrars hold them in bulk, and when one registrar's entire customer base moves to another, every account in that base moves on the same migration logic, with the same defaults, at the same time. Whatever weakness exists in that logic is not a one-off bug. It is a property of the whole fleet.

That is what made the 2024 incident a mass event rather than a string of unlucky individual compromises.

In June 2023, Squarespace purchased roughly 10 million domain names from Google Domains, after Google announced it was shutting its registrar down. Over the following year, Squarespace has been migrating users for roughly 10 million domain names purchased in the transaction. To make the transition feel seamless, Squarespace pre-created accounts for the people associated with each migrated domain, keyed to the email addresses Google had on file.

Seamless was exactly the problem. A migration that asks nothing of the user is a migration where the user has not proven anything — not their password, not their identity, not their control of the email. The accounts existed, the domains were attached, and the only thing standing between a domain and whoever showed up first was a login screen that, for these migrated accounts, asked for almost nothing.

The July 2024 hijacks

The attacks started on July 9 and ran through the following days. They were not subtle. A wave of coordinated DNS hijacking attacks targets decentralized finance (DeFi) cryptocurrency domains using the Squarespace registrar, redirecting visitors to phishing sites hosting wallet drainers, as BleepingComputer reported.

The first one to make noise was one of the biggest names in DeFi lending. Security firm Blockaid, which investigated the incident, found that visitors to these sites were being redirected to malicious pages designed to drain funds from connected wallets. The fake sites were not crude knockoffs. According to Blockaid, these fake dApps were running the latest iteration of the Inferno draining kit, designed to trick users into signing transactions that would empty their wallets.

The list of confirmed victims read like a roll call of the ecosystem. The hijacked entities included Celer Network, Compound Finance, Pendle Finance, and Unstoppable Domains. For Compound, its main domain had been taken over to display a phishing page. Celer caught the attempt and swiftly recovered its DNS records; Pendle experienced similar issues and warned its users to revoke wallet approvals.

What was at stake — and what users lost

The cruelty of a domain hijack is that it defeats every habit users are taught to rely on. Check the URL. Make sure it's the real site. Look for the lock icon. All of that advice assumes the domain still points where it is supposed to. When the attacker controls the domain's DNS, the URL is real — it is the project's genuine address — and it resolves to the attacker's server. The padlock is green. The address bar is honest. The page is a trap.

That is why wallet-drainer kits like Inferno pair so naturally with DNS hijacking. The drainer doesn't need to steal a password; it needs the victim to connect a wallet and sign. And a user who arrived at their lending protocol's real domain has no reason to hesitate before approving a transaction. The phishing site inherits all the trust the legitimate domain spent years earning.

How bad could it have been? The number that captured the scope was not the count of confirmed thefts but the count of exposed projects. Blockaid's analysis, reported by Decrypt, was blunt: roughly 228 DeFi protocol front ends are still at risk, because every one of them sat behind the same migrated-account weakness. The hijacks that happened were a sample. The attack surface was the whole crypto cohort that had ridden the Google-to-Squarespace migration.

How it happened: the migration's authentication flaw

The mechanism, once researchers reconstructed it, was almost embarrassingly simple — which is what made it dangerous at scale.

Start with two design choices. First, Squarespace did not verify that the person logging in actually controlled the email on the account. As the researchers put it, Squarespace doesn't require email verification for new accounts created with a password. Second, the migrated accounts had been pre-built but not yet claimed — they had no password set. So when someone arrived with the right email, since there's no password on the account, it just shoots them to the 'create password for your new account' flow.

Put those together and the attack writes itself. The email addresses tied to migrated domains were not secret — admin and registrant contacts are often public or guessable. An attacker who simply registered the account first, using a known migrated email, before the real owner ever logged in, walked away with control of the domain. MetaMask lead product manager Taylor Monahan, one of the researchers who dissected the incident, described the blind spot precisely: Squarespace never accounted for the possibility that a threat actor might sign up for an account using an email associated with a recently-migrated domain before the legitimate email holder created the account themselves.

Why did the pre-linking exist at all? Convenience. The researchers concluded that Squarespace assumed all users migrating from Google Domains would select the social login options — Google OAuth — rather than email-and-password. The system pre-linking all emails to domains, regardless of whether the account already exists, likely because they wanted users to be able to OAuth with Google and immediately have access to all their domains, as the researchers explained to The Register. But the email-and-password path was never closed off, and on that path nothing proved control of the inbox.

There was one more accelerant. During the migration, the protection that should have caught this was switched off: as part of the transition to Squarespace, multi-factor authentication was turned off on accounts. Even a domain owner who had carefully enabled MFA on Google Domains arrived at Squarespace with that MFA stripped away. No password to crack, no second factor to bypass, no email to intercept — for a migrated, unclaimed account, possession of a guessable email address was the whole authentication story.

Response and mitigation

The crypto-security community moved faster than the registrar. Researchers — among them Samczsun, Taylor Monahan, and Andrew Mohawk — published the mechanism, and Blockaid circulated lists of still-vulnerable front ends so projects could check whether they were exposed. Affected projects raced to reclaim their accounts, reset DNS records, and warn users to revoke token approvals granted to the malicious sites.

The immediate remediation advice was the same for everyone still on a migrated account: log in and claim the account before an attacker does, set a strong unique password, and — above all — re-enable multi-factor authentication, which the migration had silently removed. Squarespace, for its part, worked to lock down the migrated accounts and the account-creation flow. But the structural lesson outlived the patch: a security control that a vendor turns off during a migration is, for the duration of that migration, a control that does not exist.

What this teaches about registrar security and MFA

The Squarespace hijacks are not really a story about one company's misconfiguration. They are a story about where domain control actually lives, and how fragile the layer above the blockchain remains.

A few lessons generalize well beyond July 2024:

1. The registrar account is the real root of trust — not the smart contract. None of the affected protocols had a contract bug. Their on-chain code was fine. The attackers took the domain, and the domain is what users type, trust, and connect their wallets to. A project can be flawless on-chain and still hand its users to an attacker if its DNS control plane is weak.

2. MFA is only protection if it survives migrations. The painful detail here is that MFA didn't fail under attack — it was removed before the attack, as a migration convenience. Treat MFA status as something to re-verify after every account move, transfer, or vendor change, not something to set once and forget.

3. "Seamless" is a security trade-off. Every step a migration skips for the user's convenience is a step where identity goes unproven. Pre-created accounts, auto-linked emails, and no-verification logins are all friction the user didn't feel — and friction is, very often, the thing that was keeping attackers out.

4. Guessable identifiers are credentials in disguise. The "secret" that unlocked these domains was an email address that was never secret. Any system where knowing a public identifier grants control is one impersonation away from compromise.

5. The blast radius of a registrar equals its entire customer base. Individual domain security doesn't matter if the registrar's default behavior is weak, because the default applies to everyone at once. Where your domain lives, and how that custodian handles authentication, is a security decision as consequential as any you make on-chain.

The Namefi angle

The 2024 hijacks happened in the gap between "who really owns this domain" and "who can log into the account that controls it." In the traditional model, those two things are only loosely connected: ownership is a record in a registrar's database, and access to it is gated by whatever authentication that registrar happens to enforce that week — including in the middle of a 10-million-domain migration where the gate was, briefly, wide open.

Namefi is built to close that gap. By representing domain ownership as a tokenized, on-chain asset that stays compatible with DNS, control becomes something you can verify cryptographically rather than something that rests on a guessable email and a vendor's login defaults. Ownership lives in a wallet you control, transfers are auditable, and the question "who is allowed to change this domain's records" has a tamper-resistant answer instead of a customer-support answer.

That would not have made Squarespace's migration flawless. But it changes the failure mode. An attacker who registers an account with a known email does not thereby own a tokenized domain — ownership is not a row that a half-initialized account can quietly claim. The control plane for a name should be as hard to spoof as the assets it guards. In July 2024, for hundreds of crypto projects, it wasn't. That gap is exactly the one worth engineering away.

Sources and further reading

• Krebs on Security — Researchers: Weak Security Defaults Enabled Squarespace Domains Hijacks
• BleepingComputer — DNS hijacks target crypto platforms registered with Squarespace
• Blockaid — Squarespace Domain Hijacking Incident: Attack Report
• SecurityWeek — Hackers Exploit Flaw in Squarespace Migration to Hijack Domains
• Decrypt — More Than 220 DeFi Protocols Still 'at Risk' From Squarespace DNS Hijack
• The Register — Infoseccers claim Squarespace migration linked to DNS hijackings at Web3 firms
• Socket — Squarespace Domain Hijacks Enabled by Email Address Exploit on Migrated Accounts
• SiliconANGLE — Multiple crypto domains hijacked from Squarespace due to Google Domains migration flaw
• Cybernews — Squarespace crypto domains under DNS attack, lack of MFA to blame
• Hackread — DeFi Hack Alert: Squarespace Domains Vulnerable to DNS Hijacking
• CircleID — Security Lapses Lead to Squarespace Domain Hijacks