Module 2 · Lesson 4

Domain Hijacking and Mitigation Strategies

11 min read

dnssecuritydomain-hijackingregistrareppdnssecsea-turtle

Domain Hijacking and Mitigation Strategies

Most DNS attacks exploit protocol weaknesses or infrastructure misconfigurations. Domain hijacking is different: it exploits the trust chain that lets registrars control nameserver delegation. The DNS protocol works exactly as designed. The attacker just has the keys.

When Sea Turtle — a nation-state threat actor linked to Turkish interests — ran their campaign from 2017 to 2019, they compromised registrars and registry operators directly. They didn't need to exploit DNS software. They just changed NS records, waited for TLS certificates to be issued to their infrastructure, and intercepted traffic. Governments, telecoms, and internet infrastructure companies across the Middle East and North Africa lost control of their domains. Some didn't notice for months.

How Domains Get Stolen

1. Registrar Account Compromise

The most common path. Attacker gains access to the registrar account (registrar like GoDaddy, Namecheap, or Gandi) and changes the nameserver records. From that point, they control where all DNS queries for the domain are answered.

Attack vectors:

  • Credential stuffing (reused passwords from other breaches)
  • Phishing the registrar account email address
  • SIM swapping to take over SMS-based 2FA
  • Weak password reset mechanisms at the registrar

Once they have the account, changing NS records is a web form. It takes 30 seconds. The change propagates in minutes.

2. Registrar-Level Social Engineering

Some registrars have support teams that will make account changes via phone or email if you provide "verification." The verification is often a domain name + last four of a credit card. Neither is hard to obtain.

In 2019, a researcher documented social engineering attacks against multiple domain registrars by calling support with minimal information. Several transferred control without proper verification. This is not theoretical.

3. Transfer Exploits

Domain transfers between registrars are governed by the EPP (Extensible Provisioning Protocol) and require an authorization code (also called auth-info code or transfer key). If an attacker gets this code, they can initiate a transfer to a registrar they control.

Code leakage vectors: compromised email (auth codes are usually sent by email), weak registrar security (auth codes generated predictably or stored insecurely), or social engineering.

4. Registrar or Registry Infrastructure Compromise

The Sea Turtle campaign primarily targeted registrars and registry operators directly, not individual domain owners. By compromising registrar infrastructure, they could modify DNS records for any domain at that registrar — without needing the individual account credentials.

This is why registrar-level locks and registry-level locks exist at different tiers.

EPP Status Codes and Registrar Locks

Every domain has EPP status codes that control what operations can be performed on it. These are the lock mechanisms.

Check your domain's status:

whois example.com | grep -i status

Common status codes:

CodeMeaning
clientTransferProhibitedTransfer to another registrar blocked (client = registrar level)
clientUpdateProhibitedUpdates to domain data blocked
clientDeleteProhibitedDomain deletion blocked
serverTransferProhibitedTransfer prohibited at registry level (stronger)
serverUpdateProhibitedUpdates prohibited at registry level
serverDeleteProhibitedDeletion prohibited at registry level

Registrar lock = client-level locks. The registrar sets these. If your registrar account is compromised, the attacker can remove these locks before making changes.

Registry lock = server-level locks (serverTransferProhibited, serverUpdateProhibited, serverDeleteProhibited). These are set at the registry level — the entity that operates the TLD (like Verisign for .com). Changing registry locks requires out-of-band verification (phone call, email to registry, sometimes physical verification). A compromised registrar account cannot remove registry locks without that verification.

Registry lock is the real protection for high-value domains. It's often called "Domain Name System Security Extensions" Registry Lock or just "Registry Lock" depending on the registrar.

Availability: Most major registrars offer registry lock for .com/.net (Verisign Registry Lock). Cost is usually $100-$500/year. For domains worth protecting, this is nothing.

# Check if registry lock is active
whois yourdomain.com | grep -i "serverTransferProhibited\|serverUpdateProhibited"

The Sea Turtle Campaign: Technical Breakdown

Cisco Talos published their analysis in April 2019. The campaign, active since 2017, targeted:

  • Telecoms in the Middle East and North Africa
  • ISPs
  • Government agencies
  • A top-level domain registry

The technique was elegant in its simplicity:

  1. Compromise a registrar or DNS service provider (not the target itself)
  2. Modify NS records for target domains to point at attacker-controlled nameservers
  3. Use the now-in-place DNS control to pass domain validation checks for TLS certificates (DV certificates only require DNS control)
  4. Stand up a TLS-terminating proxy on the attacker's infrastructure
  5. Forward traffic to the real servers after inspecting it

The targets' users connected to the attacker's servers over valid HTTPS (no certificate warning). Credentials, session tokens, and communications were intercepted. The targets' servers worked normally — they just received traffic that had already been read.

The detection path was unusual: some targets noticed their TLS certificates had been reissued (Certificate Transparency logs are publicly auditable). Others noticed anomalous entries in CT logs for their domains. This is why monitoring Certificate Transparency is worth adding to your security operations.

How to Protect a High-Value Domain

Minimum Baseline

  • Enable registrar-level locks (clientTransferProhibited, clientUpdateProhibited, clientDeleteProhibited)
  • Use a strong unique password for your registrar account
  • Use hardware 2FA (FIDO2/WebAuthn). Not SMS. Not TOTP if avoidable.
  • Use an email address for the registrar account that is itself on a separate, well-secured domain (not the domain you're trying to protect)

For Domains That Matter

  • Enable registry lock. For .com/.net domains with Verisign, this means any NS or DS record changes require out-of-band verification. Sea Turtle couldn't have done what they did to registry-locked domains.
  • Monitor Certificate Transparency. Tools like certspotter or services like Cert Spotter (sslmate.com), Facebook's CT monitoring, or your own crt.sh queries.
# Query crt.sh for certificates issued for your domain
curl -s "https://crt.sh/?q=%.yourdomain.com&output=json" | jq '.[].issuer_ca_id, .[].not_before, .[].name_value' | head -40
  • Monitor WHOIS for NS changes. Several services (DomainTools, SecurityTrails) will alert you when nameservers change. You can also script your own:
#!/bin/bash
DOMAIN="yourdomain.com"
CURRENT_NS=$(dig +short NS $DOMAIN | sort | tr '\n' ',')
EXPECTED_NS="ns1.expected.com.,ns2.expected.com.,"

if [ "$CURRENT_NS" != "$EXPECTED_NS" ]; then
    echo "ALERT: NS records changed for $DOMAIN"
    echo "Current: $CURRENT_NS"
    # send alert
fi
  • Use DNSSEC. With DNSSEC enabled, a resolver that validates signatures will detect forged responses from a hijacked nameserver — as long as the DS record at the parent zone is still correct. (If the attacker controls the parent zone as well, DNSSEC won't help. Registry lock is the backstop.)

  • Choose a registrar with actual security posture. Some registrars have better security teams, cleaner support verification processes, and faster incident response than others. For high-value domains, spend the extra money on registrars that take security seriously.

Key Takeaways

  • Domain hijacking targets registrar accounts and infrastructure, not the DNS protocol itself
  • EPP status codes are the lock mechanism. Registry-level locks (serverTransferProhibited) are significantly stronger than registrar-level locks
  • Sea Turtle (2017-2019) compromised registrars and DNS providers directly, then used DNS control to intercept traffic over valid TLS
  • Certificate Transparency logs are your early warning system for DNS hijacking attacks
  • For any domain with significant business or security value: registry lock + hardware 2FA + CT monitoring is the minimum viable security posture

Further Reading

Up Next

Lesson 05 covers DNSSEC: the chain of trust, how signing actually works, and why despite being the right answer to cache poisoning and some hijacking scenarios, it's still not universally deployed.