Domain Hijacker

Critical Fraud & Abuse

Domain hijacking involves the unauthorized transfer of a domain name's registration to a different registrar or owner, achieved through social engineering, credential theft, registrar account compromise, or exploitation of weak domain transfer authorization controls. Once hijacked, the attacker can redirect all DNS-dependent services — web, email, VPN, and API endpoints — to infrastructure they control, enabling large-scale credential harvesting, man-in-the-middle attacks, and business disruption. Recovery can take days to weeks, causing catastrophic downtime.

<path stroke-linecap="round" stroke-linejoin="round" d="M12 9v3.75m9-.75a9 9 0 11-18 0 9 9 0 0118 0zm-9 3.75h.008v.008H12v-.008z" />

Critical Severity

This threat is classified as critical severity. Immediate action required.

🔍Indicators

  • Unexpected WHOIS registrar change or registrant contact update
  • Unauthorized NS record modifications pointing to unknown nameservers
  • SSL/TLS certificate issued by an unexpected CA for the domain (check Certificate Transparency logs)
  • Email MX records changed to unfamiliar mail servers (enabling credential interception)
  • Domain transfer confirmation emails received without a transfer request initiated
  • DNSSEC DS records deleted or replaced
  • Traffic to the domain suddenly resolving to foreign IP addresses
  • Auth code (EPP key) requested without operator initiation

🛡Detection Methods

Monitor WHOIS for changes

# Store current WHOIS snapshot
whois example.com > /tmp/whois_baseline.txt

# Compare later (cron job)
whois example.com | diff /tmp/whois_baseline.txt - | mail -s "WHOIS change alert" [email protected]

Monitor Certificate Transparency logs

# Use crt.sh API to detect unexpected certificates
curl -s "https://crt.sh/?q=%.example.com&output=json" | \
  jq '.[] | {issuer: .issuer_name, logged_at: .entry_timestamp, name: .name_value}'

DNS record monitoring

# Check NS records
dig NS example.com +short

# Check MX records
dig MX example.com +short

# Alert on unexpected changes (automate with cron)
EXPECTED_NS="ns1.expectedprovider.com"
ACTUAL_NS=$(dig NS example.com +short | head -1)
[ "$ACTUAL_NS" != "$EXPECTED_NS" ] && echo "NS CHANGE DETECTED" | mail -s "DNS Alert" [email protected]

Snort — detect DNS response with changed NS

alert udp any 53 -> $HOME_NET any \
  (msg:"Unexpected NS record in DNS response"; \
   content:"|00 02|"; offset:6; depth:2; \
   classtype:policy-violation; sid:9100021; rev:1;)

Mitigation

  1. Enable registrar lock (EPP status: clientTransferProhibited) on all domains — prevents unauthorized transfers without manual unlock.
  2. Use registrar-level two-factor authentication (2FA) and unique, strong passwords for all registrar accounts.
  3. Enable DNSSEC to cryptographically sign DNS records, making unauthorized changes detectable.
  4. Monitor Certificate Transparency logs continuously using services like crt.sh, Facebook CT Monitor, or SSLMate CertSpotter.
  5. Set up WHOIS change alerts using monitoring services (e.g., WHOIS Alert, DomainTools Monitor).
  6. Use a registrar with strong account recovery controls — avoid registrars that allow recovery via simple email verification.
  7. Implement Registry Lock (server-level EPP locks) for critical domains — requires out-of-band verification (phone call, physical presence) to transfer.
  8. Maintain an offline record of auth codes, current NS, registrar contacts, and account credentials in a secure vault (e.g., 1Password).
  9. Respond immediately: contact the registrar's abuse team, ICANN Compliance, and law enforcement if hijacking is detected.

📋Real-World Examples

In January 2019, the Sea Turtle campaign (attributed to a state-sponsored actor) hijacked DNS records for over 40 organizations in the Middle East and North Africa, including government agencies and ISPs, by compromising registrar accounts and redirecting traffic to attacker-controlled servers to harvest VPN and email credentials. In 2014, the Malaysia Airlines website was hijacked via its registrar (Melbourne IT), with DNS redirected to a page claiming MH370 was found — the domain was not recovered for approximately 22 hours.

Related Terms

More in Fraud & Abuse