Squarespace Domain Hijackings: Migration Aftermath

Squarespace Domain Hijackings: The 2024 GoDaddy Migration Aftermath

📋 Key Takeaways
  • Beginning in early July 2024, attackers started hijacking domain names that customers had migrated from Google Domains to Squarespace after Google exited the registrar business in 2023.
  • Google announced the wind-down of its registrar business in June 2023, selling the business and its customer base to Squarespace, which committed to migrating every domain with renewal pricing locked for a year.
  • Every takeover path converged on one prize — an authenticated Squarespace session with domain management rights.
  • Traditional businesses lose SEO and email when a domain falls; crypto services lose the vault door’s signage.
9 min read · 1,661 words
Educational & Ethical Use Only — This article is provided for educational and ethical cybersecurity research purposes only. The techniques described should only be used on systems you own or have explicit permission to test. Always follow responsible disclosure and the laws applicable to you. Mitigations are included so engineers can harden real systems.
Cloud & Infrastructure· 9 min read

What Happened? The July 2024 Squarespace Domain Hijackings

Beginning in early July 2024, attackers started hijacking domain names that customers had migrated from Google Domains to Squarespace after Google exited the registrar business in 2023. Within days, crypto phishing crews had turned at least a dozen of the stolen names — some tied to exchanges handling daily volumes in the millions — into fake login pages harvesting wallet credentials. The root cause was procedural, not a zero-day: inherited accounts left unclaimed, a password-reset flow that honored stale WHOIS mailboxes, and domain-level DNS control granted to whichever account claimed the name. By 18 July, when this post published, web3 security firms had cataloged the campaign, and domain owners everywhere were re-learning an old lesson: domain ownership is account security.

Quick Answer: After Google Domains shut down and Squarespace inherited roughly 10 million domains in 2023, many owners never completed Squarespace account claiming. Attackers who could control legacy email addresses (or abuse Squarespace’s password-reset and domain-claim flows) took over unclaimed domains, redirected MX and A records, and pointed web3-linked names at crypto-drainer phishing pages. At least a dozen domains fell in July 2024 alone, including names used by exchanges and DeFi services. No vendor product was exploited in the classic sense — the victims’ assets were seized through the humble machinery of registrar account recovery.

The campaign’s target selection revealed its economics. Crypto-adjacent domains are valuable precisely because users trust bookmarked names: an exchange’s trading interface, an NFT marketplace’s help subdomain, a bridge’s status page. A drainer kit behind a legitimate-looking hostname converts at rates plain phishing can only dream of, so crews specialize in acquiring such hosts. Web3 researchers tracing the July wave noted the same infrastructure fingerprints across victims — drainer payloads, quiet MX rewrites to catch password resets, and rapid issuance of TLS certificates for the impostor pages, courtesy of automated certificate authorities that make any takeover look padlock-legitimate within minutes. Among the names publicly reported in the first wave were crypto projects including Cetus (cetus.zone) and Pendle Finance (pendle.finance).

The Google Domains Exit, One Year Later

Google announced the wind-down of its registrar business in June 2023, selling the business and its customer base to Squarespace, which committed to migrating every domain with renewal pricing locked for a year. The migration mechanics — domains moved as unclaimed assets attached to invoicing identities, with owners encouraged to create Squarespace accounts to manage them — left a gap between ownership on paper and control in practice. A meaningful fraction of the 10-million-name estate was never claimed into a secured account. Opportunistic crews spent the following year enumerating that gap: names with live traffic, names in active crypto use, names whose historical WHOIS contacts pointed at mailboxes attackers could register or reclaim.

Date Event
2023-06 Google announces Google Domains exit; Squarespace acquires the registrar business and ~10M domains
2023-08→2024-05 Migrations proceed; unclaimed domains accumulate; some domains sit in locked, unclaimable states pending verification
2024-07-10 (circa) First hijack reports: web3-linked domains redirect to drainer pages; researchers begin tracking
2024-07-15→17 Coordinated disclosure pressure; Squarespace forces password resets and locks down the affected claim flows; victim count passes a dozen
2024-07-18 Registrar confirms remediation; security press broadly covers the campaign; this post publishes amid cleanups

Attack Mechanics: Possession Is Ten-Tenths of the Law

Every takeover path converged on one prize — an authenticated Squarespace session with domain management rights. From there, the attack is boring: change DNS records, re-point MX to capture mail, host a pixel-perfect clone of the original service, install a drainer. Some crews entered via stale-WHOIS mailbox control: domains whose registrant contacts predated the migration still listed addresses on mail providers that had since recycled or allowed re-registration of those mailboxes. Others entered via reset-flow abuse against accounts with weak recovery posture. Registrar-side hardening — tighter reset and claim flows for unclaimed assets — closed specific doors mid-campaign, but the class of vulnerability (account state older than the owner’s attention) remains exactly where it has lived since the 1990s.

Why Crypto Services Took the Headline Damage

Traditional businesses lose SEO and email when a domain falls; crypto services lose the vault door’s signage. Several July victims were exchanges, token-swap frontends, or infrastructure providers whose users interact through a browser with real money. A spoofed exchange page asking for a seed phrase or a malicious transaction signature has direct, irreversible payout — no card-chargeback safety net — so drainer crews treat each hijacked crypto hostname as a temporary money printer until detection kills it. The broader lesson travels well beyond web3: any domain whose trust relationship with users is strong enough to survive a takeover (banks, government portals, internal tooling) carries the same latent risk when its registrar account rots.

  • Inherited estates rot: every mass registrar migration creates an unclaimed-assets pool; attackers inventory them patiently for high-value names.
  • WHOIS mailboxes are keys: expired or recyclable registrant email addresses remain the cheapest takeover vector in domain security.
  • TLS automation launders legitimacy: free automated certificates made impostor pages indistinguishable at the padlock level; users must judge site content, not the padlock.
  • MX capture compounds: rewriting mail records during a takeover intercepts password-reset emails for every service tied to the domain — turning one hijack into many.

Frequently Asked Questions

Was Squarespace itself hacked?

No system compromise at Squarespace has been demonstrated. The campaign abused legitimate account-recovery and domain-claim flows against weakly claimed assets — attacker-controlled legacy mailboxes, unclaimed domains, loose reset posture. Squarespace responded with forced password resets and claim-flow lockdowns for the affected population. Framing this as a Squarespace breach misses the durable lesson: registrar account hygiene is a customer-side control, at every registrar.

How do I tell if a domain I own was affected?

Audit, don’t assume. Log in to the registrar and verify that: your registrant/WHOIS contact mailboxes are ones you still control; DNS records match your inventory; MX still points to your mail provider; no unfamiliar accounts hold domain permissions; and every certificate issued for the name (checkable via public Certificate Transparency logs, e.g., through crt.sh) corresponds to your own hosting. Any surprise — especially CT-log certificates from issuers you never used, dated within the July 2024 window — warrants immediate DNS review and credential rotation.

What is the permanent fix for this class of attack?

Registry lock where available (a high-friction, human-verified change path offered for critical names on many major TLDs), registrar transfer locks and 2FA on the registrar account, corporate domain-asset inventories with periodic ownership reviews, and breaking the circularity of mail-on-your-own-domain by keeping at least one WHOIS contact on an independent email provider. High-value names deserve the same change control as production infrastructure — because, as July 2024 showed, that is exactly what they are.

Why Security Researchers Saw This Story on Web3 Desks First

Outlets and researchers noticed the campaign through its monetization, not its mechanism — the first hijacked domains served crypto drainers, so blockchain-security firms saw the on-chain flows before anyone saw the DNS changes. That visibility skew is worth remembering: infrastructure attacks surface wherever the money moves first. Had the same unclaimed-domain estate been mined for corporate intranet names, regional bank portals, or government microsites, the takeover wave might have run for weeks before anyone with a public voice noticed — and discovery would have come from an incident-response team, not a threat-intel desk. Visibility follows money; defenders cannot afford to.

The Defense Playbook: Registrar Controls That Actually Stop Takeovers

Almost every control that would have blunted the July 2024 wave existed before the first domain fell — the failure was adoption. A workable playbook for any organization that owns domains, in rough order of leverage:

  • Registry lock for crown-jewel names: a high-friction, human-verified change path at the registry level that no registrar-account compromise can bypass. It defeats exactly the attack class seen here — an authenticated session rewriting DNS at will.
  • Transfer locks on everything, by default: registrar-level transfer locks stop the fast path of moving a name to an attacker-controlled registrar, buying time for monitoring to catch the attempt.
  • Hardware-backed 2FA on registrar accounts: SMS and email second factors fail precisely when the attacker already controls mail (via MX rewrites) or phone-porting. FIDO2 keys or TOTP on a dedicated, monitored account raise the cost dramatically.
  • WHOIS contacts on independent mail: keep at least one registrant contact on a mailbox hosted outside the domain being protected — otherwise the reset path for the domain runs through the domain itself, a circularity attackers exploited.
  • An owner and a review date for every name: mass migrations create orphan estates; an annual audit that claims, locks and verifies each domain is the only structural cure.

Detection: Catching a Hijack Before Your Users Do

The July victims typically learned of the takeover from researchers or users, not from their own telemetry. Closing that gap means watching the three surfaces a hijacker must touch:

  • Certificate Transparency: every TLS certificate issued for your domains is logged publicly within minutes. CT monitoring (crt.sh feeds, Cert Spotter, or cloud monitors) is the single highest-value alarm — the impostor pages in this campaign needed valid certificates to look legitimate.
  • DNS change alerting: export your intended NS, MX and A records as a baseline and alert on any delta. An MX rewrite to an unfamiliar host is both the attacker’s mail-capture step and your earliest reliable signal.
  • Registrar notifications as a sensor: route every registrar email — transfer requests, WHOIS edits, password resets — to a monitored shared inbox. Silence around a change is itself an indicator that mail is being intercepted.

None of this is exotic. The Squarespace wave was a decade-old attack pattern executed against a freshly created orphan-asset pool, and the defenses that work against it are equally old. Registrar security is unglamorous infrastructure hygiene — which is exactly why it keeps being skipped, and exactly where the next migration wave will get hit.

More on this topic

Hmmnm
Published by Hmmnm

Hands-on cybersecurity tutorials, CVE breakdowns, and guided learning paths — written and lab-tested by the Hmmnm team.

🛡️ Hmmnm also delivers this expertise as a service — security testing, assessment & training.
Keep going — the structured way
This post is one step. The learning paths chain the next ones for you, with progress tracking and no account needed.
Follow a learning path →

Prabhu Kalyan Samal

Application Security Consultant at TCS. Certifications: CompTIA SecurityX, Burp Suite Certified Practitioner, Azure Security Engineer, Azure AI Engineer, Certified Red Team Operator, eWPTX v3, LPT, CompTIA PenTest+, Professional Cloud Security Engineer, SC-900, SC-200, PSPO I, CEH, Oracle Java SE 8, ISP, Six Sigma Green Belt, DELF, AutoCAD. Writing about ethical hacking, security tutorials, and tech education at Hmmnm.