How to secure your DNS infrastructure against modern domain hijacking

In July 2024, the cybersecurity and Web3 communities watched in real-time as over 130 decentralized finance (DeFi) protocols—including major players like Compound Finance and Pendle—had their domains hijacked. Millions of dollars were put at risk as user traffic was silently rerouted to wallet-draining phishing sites.

The root cause wasn't a sophisticated zero-day exploit in a web server. It was a vendor migration. When Squarespace acquired Google Domains, the automated migration process allowed attackers to create accounts using the domain owners' email addresses without enforcing Multi-Factor Authentication (MFA) by default. Attackers bypassed the perimeter entirely, seized control of the DNS records, and executed a massive, coordinated hijacking campaign.

Domain hijacking (or domain theft) is no longer a relic of the 1990s internet. Today, it is a highly lucrative, automated, and devastating attack vector. If an attacker controls your domain, they control your email, your SSL/TLS certificates, your application traffic, and ultimately, your brand's trust.

For DevOps engineers, security professionals, and IT administrators, securing the DNS infrastructure is a foundational requirement of the Zero Trust model. This comprehensive guide explores the modern threat landscape of domain hijacking and provides actionable, technical implementation strategies to lock down your digital real estate in 2025.

The Modern Anatomy of Domain Hijacking

Attackers have largely abandoned brute-force password guessing in favor of sophisticated, targeted techniques. Understanding how domains are stolen today is the first step in building a resilient defense.

1. Adversary-in-the-Middle (AiTM) Phishing

Standard MFA (like SMS codes or TOTP authenticator apps) is no longer sufficient to protect registrar accounts. Attackers deploy reverse-proxy phishing frameworks like Evilginx to intercept the authentication flow.

When an IT administrator logs into a spoofed registrar login page, the reverse proxy passes the credentials and the TOTP code to the legitimate registrar. The registrar grants a session cookie, which the proxy intercepts and steals. The attacker then injects this cookie into their own browser, completely bypassing MFA and gaining full control over the domain settings.

2. Social Engineering the Registrar

In late 2023, the Web3 credential network Galxe suffered a domain hijacking resulting in roughly $270,000 in stolen user funds. The attacker didn't hack Galxe's internal systems; instead, they spoofed authorized personnel and convinced the registrar's customer service team to reset the account credentials. If your domain's security relies entirely on the training of a tier-1 support agent at a retail registrar, your domain is vulnerable.

3. Subdomain Takeovers via Cloud Sprawl

As organizations rapidly spin up and tear down cloud services, they often forget to clean up their DNS records. A "dangling DNS" record is a CNAME pointing to a cloud resource (like an AWS S3 bucket, Azure Web App, or GitHub Pages site) that has been deleted.

Attackers continuously scan the internet for these dangling records. Once found, they simply claim the abandoned resource name at the cloud provider, effectively hijacking the subdomain. This allows them to serve malicious content, steal session cookies scoped to the base domain, or bypass CORS policies.

4. Domain Expiration and Drop Catching

One of the most common, yet easily preventable, forms of domain hijacking occurs when a domain registration expires. Whether due to an expired corporate credit card, employee turnover, or a lost notification email, a dropped domain is instantly registered by automated "drop catching" bots. Once lost, recovering the domain requires expensive legal action or paying exorbitant extortion fees to the squatter.

EPP Status Codes: Registrar Lock vs. Registry Lock

To defend against unauthorized transfers and modifications, domain owners must understand the Extensible Provisioning Protocol (EPP) status codes. These codes dictate what actions can be performed on a domain at the registry level (e.g., Verisign for .com domains).

The Illusion of Safety: Registrar Lock

Most retail registrars offer a simple toggle switch called "Registrar Lock." When enabled, it applies the following EPP status code:

• clientTransferProhibited: Instructs the registry to reject any requests to transfer the domain to another registrar.

While useful, this code is prefixed with client, meaning it is applied and removed by the registrar. If an attacker compromises your registrar account via AiTM phishing, they can simply toggle the lock off, removing the protection instantly.

The Enterprise Standard: Registry Lock

Mission-critical domains require Registry Lock. This applies server-level EPP codes that cannot be removed through the registrar's web portal or API.

• serverTransferProhibited: Prevents transfer to another registrar.
• serverUpdateProhibited: Prevents modifications to the domain details (like changing nameservers).
• serverDeleteProhibited: Prevents the domain from being deleted.

When Registry Lock is active, making any DNS delegation or transfer changes requires a manual, out-of-band verification process. The registrar must physically call designated, authorized contacts at your organization, verify identities via secure passphrases, and then manually request the registry to temporarily lift the lock.

You can verify your domain's current EPP status using a simple terminal command:

whois example.com | grep "Domain Status"

Output for a highly secured domain:

Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: serverDeleteProhibited https://icann.org/epp#serverDeleteProhibited
Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited
Domain Status: serverUpdateProhibited https://icann.org/epp#serverUpdateProhibited

If you only see clientTransferProhibited, your domain is vulnerable to account compromise.

Technical Defenses & Implementation Guide

Securing your domains requires a defense-in-depth approach spanning access controls, DNS configurations, and continuous monitoring.

1. Upgrade to an Enterprise-Grade Registrar

Retail registrars are built for volume and automated self-service, which inherently introduces security risks for enterprise clients. Organizations should migrate critical domains to enterprise registrars such as Cloudflare Custom Domain Protection, CSC Digital Brand Services, or MarkMonitor.

Enterprise registrars provide:
* Strict Role-Based Access Control (RBAC) and SSO integration.
* Mandatory Registry Lock capabilities.
* Dedicated account managers (eliminating the risk of tier-1 support social engineering).
* Offline, cold-storage management for ultra-high-value domains.

2. Enforce Phishing-Resistant MFA (FIDO2)

To defeat AiTM phishing attacks, you must eliminate shared secrets (like passwords and TOTP codes) from the authentication flow. Enforce FIDO2 / WebAuthn hardware security keys, such as YubiKeys, for all users accessing the registrar portal or DNS management console.

FIDO2 protocols cryptographically bind the authentication token to the specific TLS origin (the actual URL of the login page). If an attacker uses a reverse proxy on login.fake-registrar.com, the hardware key will refuse to authenticate because the origin does not match the registered domain, stopping the attack dead in its tracks.

3. Implement CAA Records to Prevent Fraudulent Certificates

If an attacker briefly hijacks your DNS, their immediate next step is usually to provision a valid SSL/TLS certificate for your domain to make their phishing site appear legitimate.

You can slow down or prevent this by implementing a Certificate Authority Authorization (CAA) DNS record. A CAA record explicitly whitelists which Certificate Authorities (CAs) are allowed to issue certificates for your domain.

Here is an example BIND zone file configuration that restricts certificate issuance exclusively to Let's Encrypt, and specifies an email address to notify if a fraudulent issuance is attempted:

; Restrict certificate issuance to Let's Encrypt
example.com.    IN  CAA 0 issue "letsencrypt.org"

; Restrict wildcard certificates to Let's Encrypt
example.com.    IN  CAA 0 issuewild "letsencrypt.org"

; Request violation reports via IODEF
example.com.    IN  CAA 0 iodef "mailto:security@example.com"

While an attacker who controls your DNS could technically delete this record, doing so takes time and creates a noisier audit trail. Furthermore, CA provisioning systems cache CAA records, which can delay the attacker's ability to instantly generate a certificate.

4. Audit Cloud Infrastructure for Dangling DNS

DevOps teams must integrate subdomain takeover scanning into their CI/CD pipelines. Tools like Nuclei by ProjectDiscovery can automate the detection of dangling DNS records pointing to unclaimed cloud resources.

You can run a targeted scan against your infrastructure using the following command:

# Provide a list of your subdomains
nuclei -l subdomains.txt -t takeovers/

To prevent this permanently, implement Infrastructure as Code (IaC) lifecycle hooks. When a Terraform or Pulumi script destroys an AWS S3 bucket or an Azure Web App, it must simultaneously trigger the deletion of the associated Route53 or Cloudflare CNAME record.

The Critical Role of Expiration Tracking

The most embarrassing—and frequent—cause of domain loss isn't a sophisticated nation-state hack; it's a missed renewal date.

Relying on email reminders sent to a single employee (who may have left the company) or an auto-renew toggle tied to an expired corporate credit card is a recipe for disaster. When domains or SSL certificates expire, your application experiences immediate downtime, and dropped domains are instantly scooped up by malicious actors.

This is where dedicated infrastructure monitoring becomes non-negotiable. Using a platform like Expiring.at allows DevOps and IT teams to centralize the expiration tracking of all domains and SSL/TLS certificates across the entire organization.

Instead of relying on registrar emails, you can:
* Track the exact expiration dates of all domains, regardless of which registrar holds them.
* Monitor SSL/TLS certificate validity to prevent unexpected browser warnings.
* Route alerts directly into your team's workflow via Slack, Microsoft Teams, or custom webhooks well before the expiration date hits.
* Maintain an immutable audit log of your infrastructure's lifecycle.

By treating domain and certificate expiration as critical alerting metrics alongside CPU usage and memory consumption, you eliminate the operational blind spots that lead to accidental hijacking.

Compliance and Regulatory Pressures (NIS2)

Domain security is no longer just a technical best practice; it is becoming a strict legal requirement. The European Union's NIS2 Directive, which took effect in October 2024, mandates stringent cybersecurity measures for critical infrastructure, including DNS service providers and TLD name registries.

Under NIS2, organizations are held accountable for their supply chain security. If your business relies on a registrar with weak access controls, you may be found non-compliant in the event of a breach. Furthermore, SOC 2 and ISO 2