In the world of web security, some of the most dangerous vulnerabilities are not the result of sophisticated zero-day exploits or novel attack techniques. Instead, they stem from something far more mundane: forgotten DNS records. Subdomain takeovers represent a class of vulnerability where an attacker gains control of a subdomain belonging to a target organization, typically by claiming an unclaimed or abandoned external service that the subdomain points to.

While subdomain takeovers have been a known issue in traditional Web2 environments for years, the rise of Web3 has given these attacks a far more dangerous edge. The use of user private keys connecting to user interfaces, combined with the signing of on-chain transactions, makes subdomain takeovers especially dangerous in the blockchain ecosystem. Client-side code can effectively be customized to the attacker's liking while maintaining a legitimate-looking URL - and in Web3, that can mean wallet-draining phishing kits deployed behind a trusted domain.

In the worst-case scenario, this can lead to domain security bypasses and even compromise of private keys, making this vulnerability particularly critical for any protocol or application handling user funds.

What Is a Subdomain?

Before diving into the technical details of subdomain takeovers, it is important to understand what a subdomain actually is. A subdomain is a prefix added to a domain name to create a separate, distinct section of a website. For example, blog.example.com and shop.example.com are subdomains of example.com, directing users to a blog and an online store respectively.

Think of it like an electrical outlet. If you have your own appliance (host) plugged into it, everything works fine. But if the outlet is live and unoccupied, anyone who plugs in can start drawing power - or in this case, serving content under your domain name.

Organizations commonly use subdomains to organize different services, applications, and environments. A company might use app.company.com for their main application, staging.company.com for a development environment, and docs.company.com for documentation hosted on a third-party platform like GitHub Pages or ReadTheDocs.

How DNS and CNAME Records Work

At the core of subdomain takeovers lies the Domain Name System (DNS), the internet's address book. When a user visits a subdomain, their browser performs a DNS lookup to determine where to send the request. One of the most common DNS record types involved in subdomain takeovers is the CNAME record (Canonical Name record).

A CNAME record creates an alias from one domain name to another. For instance, an organization might create a CNAME record pointing docs.company.com to company.github.io, delegating the hosting of their documentation to GitHub Pages. When a user visits docs.company.com, DNS resolves the CNAME to the GitHub Pages server, which then serves the content.

The critical issue arises when the destination service is removed or decommissioned, but the CNAME record is left in place. This creates what is known as a dangling DNS record - a pointer to a resource that no longer exists.

What Is Dangling DNS?

A dangling DNS record is any DNS record that continues to point to a nonexistent or outdated resource. The most common scenario involves CNAME records, but A records, MX records, and NS records can also become dangling if the underlying infrastructure is decommissioned without cleaning up the DNS configuration.

Dangling DNS records are far more common than most organizations realize. A study analyzing over 440,000 DNS records found that more than 21% pointed to non-resolving resources, indicating widespread dangling subdomains at risk of takeover across the internet.

Common scenarios that create dangling DNS records include:

• Decommissioned cloud services: An AWS S3 bucket, Azure Blob Storage container, or Heroku app is deleted, but the CNAME record remains
• Expired trial accounts: A SaaS platform trial expires, the service is removed, but DNS still points to it
• Platform migrations: An organization migrates from one hosting provider to another without cleaning up old DNS entries
• Personnel changes: The engineer who set up a subdomain leaves the company, and the record is forgotten
• Domain registrar transitions: Domains transferred between registrars may carry over stale configurations

How Subdomain Takeovers Work

A subdomain takeover occurs when an attacker identifies a dangling DNS record and claims the abandoned external resource that the subdomain points to. The attack typically follows a straightforward process:

1. Reconnaissance: The attacker enumerates subdomains of a target organization using tools like subfinder, amass, or dnsrecon. They look for subdomains returning errors such as "404 Not Found," "NoSuchBucket," or provider-specific error pages indicating the service is unclaimed.
2. Verification: The attacker confirms that the subdomain has a CNAME record pointing to an external service and that the resource on that service is unclaimed or available for registration.
3. Claim: The attacker registers the same resource name on the external service. For example, if docs.company.com points to company.github.io and that GitHub Pages site does not exist, the attacker creates a GitHub repository named company.github.io under their own account.
4. Exploitation: Once the resource is claimed, the attacker controls the content served on the subdomain. They can host phishing pages, distribute malware, steal cookies set from the main domain via cross-site scripting, or in the case of Web3 - deploy wallet-draining scripts.

Commonly Vulnerable Services

Not all external services are equally susceptible to subdomain takeovers. The vulnerability depends on whether the service allows users to claim custom domain configurations. Services that are frequently exploited include:

• GitHub Pages: If a CNAME points to org.github.io and no repository with that name exists, an attacker can create one
• Amazon S3: Deleted S3 buckets leave behind "NoSuchBucket" errors - an attacker can recreate the bucket in their own AWS account
• Heroku: Deprovisioned Heroku apps can be reclaimed by any user who registers the same app name
• Azure: Various Azure services including Blob Storage, Traffic Manager, and App Services can be targeted
• Shopify, Squarespace, and other website builders: Custom domain configurations on these platforms can be exploited if the store or site is removed
• Fastly, CloudFront, and CDN providers: CDN configurations pointing to decommissioned origins can be hijacked

Case Study: The Squarespace Domain Hijacking Incident

One of the most significant real-world demonstrations of how Web2 infrastructure vulnerabilities can devastate Web3 protocols occurred on July 9, 2024, when multiple Web3 protocols with Squarespace-registered domains fell victim to a coordinated domain hijacking attack.

What Happened

The attack originated from an infrastructure transition. In June 2023, Google sold its domain registration business (Google Domains) to Squarespace, prompting a forced migration of all Google Domains infrastructure to Squarespace's platform throughout mid-2024. This migration introduced a critical security gap.

The domains that were migrated from Google Domains to Squarespace were either publicly known or easily discoverable through basic reconnaissance. As part of the migration process, Squarespace presumed that users would select social login options like "Continue with Google" or "Continue with Apple" to set up their new Squarespace accounts. However, Squarespace never accounted for the possibility that a threat actor might sign up for an account using an email associated with one of the migrating domains.

If an administrator never set up their Squarespace account - whether because they had left the company, did not respond to migration notifications, or simply were unaware - anybody who registered with that email address on Squarespace now had root access to control the domain.

Multi-Factor Authentication Disabled

Making matters worse, users who migrated from Google Domains to Squarespace had their Multi-Factor Authentication (MFA) disabled as part of the migration process. This was reportedly done to reduce the likelihood of administrators being locked out of their accounts during the transition. However, it removed a critical security barrier and left accounts protected by only a password - or in some cases, no authentication at all if the account had never been properly claimed.

Affected Protocols

The domain hijacks took place between July 9 and July 12, 2024, targeting several prominent cryptocurrency and DeFi platforms, including:

• Compound Finance - one of the largest DeFi lending protocols
• Celer Network - a cross-chain interoperability platform
• Pendle Finance - a yield tokenization protocol
• Unstoppable Domains - a Web3 domain name service

Attackers leveraged their control over these domains to modify DNS records, redirecting legitimate traffic to malicious websites. Behind these legitimate-looking domains, the attackers deployed wallet-draining phishing kits designed to steal cryptocurrency funds from users who connected their wallets to what they believed were the official protocol interfaces.

Lessons from the Incident

This incident powerfully illustrated several key points:

• Web2 infrastructure is the foundation of Web3: Even decentralized protocols depend on centralized domain infrastructure
• Domain registrar transitions are high-risk events: Any migration between registrars should be treated as a security-critical operation
• MFA should never be disabled during migrations: Convenience should not override security, especially for domain management
• DNS monitoring is essential: Protocols should actively monitor their DNS records for unauthorized changes

Why Subdomain Takeovers Are Especially Dangerous in Web3

While subdomain takeovers in traditional Web2 environments are primarily used for phishing, cookie theft, and brand damage, the impact in Web3 is orders of magnitude more severe. Several characteristics of the Web3 ecosystem amplify the risk:

• Wallet connections: Users routinely connect their wallets to web interfaces. A compromised subdomain serving a malicious frontend can prompt users to sign transactions that drain their funds
• Transaction signing: Unlike Web2 where stolen credentials can often be reset, signed blockchain transactions are irreversible. Funds sent to an attacker's address cannot be recovered
• Trust in URLs: The Web3 community frequently shares and references specific URLs. A taken-over subdomain that previously hosted a legitimate tool, bridge, or staking interface will be trusted by users without question
• Client-side execution: Web3 frontends execute critical operations client-side, including transaction construction and wallet interactions. An attacker controlling the frontend controls the entire user interaction flow
• High-value targets: DeFi protocols routinely handle billions in total value locked. Even a brief period of domain compromise can result in massive financial losses

Consequences of a Successful Takeover

When an attacker successfully takes over a subdomain, the potential consequences extend well beyond simple defacement:

• Cookie theft: If the parent domain sets cookies that are accessible to subdomains, the attacker can steal session tokens and authentication credentials
• Cross-site scripting (XSS): The attacker can execute JavaScript in the context of the parent domain, potentially accessing sensitive data or performing actions on behalf of authenticated users
• Phishing: The attacker can host convincing phishing pages under a trusted domain, bypassing many anti-phishing defenses
• Content Security Policy bypass: If the parent domain's CSP trusts its subdomains, the attacker can circumvent these protections
• Email interception: If MX records are involved, the attacker can intercept emails sent to the subdomain
• Wallet draining: In Web3 contexts, the attacker can deploy scripts that prompt users to approve malicious transactions
• Supply chain compromise: If the subdomain hosts scripts loaded by the main application, the attacker gains code execution within the main application context

Mitigating Subdomain Takeovers

Preventing subdomain takeovers requires a combination of proactive monitoring, disciplined infrastructure management, and defense-in-depth strategies.

DNS Record Hygiene

The most fundamental defense is maintaining clean DNS records. Organizations should regularly audit their DNS configurations to identify rogue CNAMEs, unused subdomains, and any records pointing to resources that no longer exist. If a subdomain is no longer in use, the DNS record should be removed immediately rather than left dangling.

Implement a process where any decommissioning of a service, application, or cloud resource includes a mandatory step to remove or update the associated DNS records.

Monitoring and Alerting

Deploy continuous DNS monitoring that alerts on any unauthorized changes to DNS records. Tools and services exist that can enumerate subdomains, check for dangling records, and detect potential takeover conditions before attackers exploit them.

For Web3 protocols specifically, monitoring should also watch for unexpected changes in the content served by subdomains, as these could indicate a takeover in progress.

DNSSEC

DNS Security Extensions (DNSSEC) add cryptographic signatures to DNS records, making them tamper-proof and preventing attackers from rerouting traffic through DNS record manipulation. While DNSSEC does not prevent subdomain takeovers directly (since the issue is with the service behind the DNS record, not the record itself), it provides an additional layer of protection against DNS-based attacks and should be enabled wherever possible.

Domain Registrar Security

Secure your domain registrar account with the strongest available protections:

• Enable multi-factor authentication on all registrar accounts
• Use registrar lock features to prevent unauthorized transfers
• Monitor registrar notifications and act on any migration or transfer communications promptly
• Maintain up-to-date contact information to ensure you receive critical security notifications
• If your registrar is acquired or migrates to another platform, treat the transition as a security-critical event

Infrastructure Best Practices

• Wildcard DNS avoidance: Do not use wildcard DNS records unless absolutely necessary, as they can mask takeover opportunities
• Service ownership documentation: Maintain a clear mapping of which subdomains point to which services and who owns each one
• Offboarding procedures: Include DNS record review in employee and vendor offboarding checklists
• Principle of least privilege: Restrict who can create and modify DNS records to authorized personnel only

Closing Thoughts

Subdomain takeovers sit at the intersection of Web2 infrastructure and Web3 risk. They are not novel, they are not technically complex, and they are almost entirely preventable with proper hygiene. Yet they continue to cause significant damage because organizations underestimate the blast radius of a forgotten DNS record.

The Squarespace incident demonstrated that even the largest DeFi protocols are vulnerable when the underlying Web2 infrastructure is compromised. Decentralization at the protocol layer does not protect against centralization at the domain layer.

For any organization operating in the Web3 space, DNS security is not optional. Regular audits, proactive monitoring, strong registrar controls, and a disciplined approach to infrastructure decommissioning are essential components of a mature security posture. The cost of prevention is a fraction of the cost of a successful attack - and in Web3, where transactions are irreversible and funds can vanish in seconds, that cost difference is measured in millions.