DNS Hijacking: How It Happens and How to Detect It

DNS hijacking is the act of redirecting a domain's traffic by modifying its DNS records without authorization. It's one of the most effective attacks available because it's invisible to the end user; the URL bar still shows the correct domain name.

How DNS Hijacking Works

There are several ways an attacker can modify your DNS records:

Registrar Account Compromise

Your domain registrar controls your NS records (the records that determine which nameservers are authoritative for your domain). If an attacker gains access to your registrar account through credential stuffing, phishing, or social engineering support staff, they can point your domain to nameservers they control.

From there, they serve whatever DNS records they want. They can direct your website traffic to a lookalike site, redirect email to their servers, or selectively proxy traffic to intercept specific data while forwarding the rest to maintain the illusion that everything is normal.

This is what happened in the 2019 Sea Turtle attacks, and it remains the highest-impact variant of DNS hijacking.

DNS Provider Compromise

If your DNS hosting provider is compromised, attackers can modify records directly without touching your registrar. This happened in 2016 when attackers modified DNS records for a major Brazilian bank (all 36 of the bank's domains) through the DNS provider.

BGP Hijacking to Intercept DNS

By manipulating BGP (Border Gateway Protocol) routes, an attacker can redirect traffic destined for your DNS provider's IP addresses through their own network. They respond to DNS queries with forged answers, then release the route. This is difficult to execute but nearly impossible to detect without external monitoring.

Local DNS Hijacking

Malware on a user's device can modify the local DNS resolver settings, directing all queries to an attacker-controlled server. This affects individual machines rather than domains, but it's worth mentioning because it's the most common form of DNS hijacking by volume.

Rogue Employees

Internal actors with access to DNS management can modify records. This could be malicious (redirecting traffic) or accidental (a misconfiguration during maintenance). Without an audit trail, you can't distinguish between the two.

Why It's Hard to Detect

DNS hijacking is uniquely dangerous because:

The domain name doesn't change. Unlike phishing with lookalike domains, the URL is exactly correct. Browser security indicators (padlock, green bar) can still appear if the attacker obtains a valid certificate, which is trivial with automated CAs like Let's Encrypt.

The impact can be selective. Sophisticated attackers don't hijack everything. They might only redirect traffic for a specific subdomain, or only for users in a specific geography, making it harder to notice.

DNS caching masks the timing. Because DNS responses are cached, the hijacked records propagate gradually. Some users see the legitimate site while others see the attacker's version, depending on when their resolver's cache refreshes.

No server-side logging. Your web server logs won't show anything unusual because the traffic never reaches your server. The attacker's server handles the requests.

How to Detect DNS Hijacking

Monitor DNS Records Continuously

The single most effective defense is monitoring your DNS records from an external perspective and alerting on any change. If your A record suddenly points to a different IP, or your NS records change to unfamiliar nameservers, you want to know within minutes.

This is more effective than it sounds. Most DNS hijacking attacks require modifying records that are visible to anyone who queries your DNS. An external monitor querying your records periodically will catch these changes.

Monitor Certificate Transparency Logs

When an attacker needs a TLS certificate for your domain (and they usually do, to avoid browser warnings), that certificate issuance is logged in Certificate Transparency logs. Monitoring CT logs for unexpected certificates for your domain is a strong early warning signal.

Enable Registrar Lock and 2FA

Most registrars support a "registrar lock" (also called clientTransferProhibited) that prevents domain transfers and NS changes without explicit authorization. Combined with strong two-factor authentication on your registrar account, this significantly raises the bar for account-based attacks.

DNSSEC

DNSSEC adds cryptographic signatures to DNS records. If an attacker modifies your records but can't sign them with your keys, DNSSEC-validating resolvers will reject the forged responses. It's not a complete solution (it doesn't help if the attacker compromises your registrar and disables DNSSEC), but it protects against cache poisoning and man-in-the-middle attacks.

Maintain a DNS Audit Trail

An audit trail of every DNS change (who changed what, when, and from what value to what value) is essential for incident response. Without it, you're left trying to reconstruct the timeline from incomplete evidence after the fact.

Response Playbook

If you detect unauthorized DNS changes:

1. Verify the change is real. Query from multiple locations to confirm it's not a caching artifact.
2. Revert the records immediately. If you still have access to your DNS provider, change them back. If the NS records were hijacked at the registrar, contact them directly.
3. Rotate credentials. Change passwords and API keys for your registrar and DNS provider accounts. Assume they've been compromised.
4. Check Certificate Transparency logs. Determine if any certificates were issued during the hijack period.
5. Review the audit trail. Identify exactly what changed and when. This determines the scope of exposure.
6. Notify affected parties. If traffic was intercepted, users who connected during the hijack window may have had their credentials captured.

The window between hijack and detection is what matters. Minutes of exposure is an inconvenience; days or weeks of exposure is a breach. Monitoring is what determines which one you're dealing with.