"What is DNS hijacking and how does it differ from DNS spoofing?"

"DNS hijacking involves taking control of the DNS resolution process itself — either by compromising a resolver, router, registrar account, or ISP infrastructure — so that authoritative responses are altered at the source. DNS spoofing (cache poisoning) injects forged records into a resolver's cache without compromising the resolver itself. Hijacking is typically more persistent and harder to detect because the malicious records originate from a legitimate-looking authoritative source."

"Can HTTPS protect me from DNS hijacking?"

"Partially. If an attacker hijacks your DNS and redirects a domain to their server, the TLS handshake will fail unless the attacker also possesses a valid certificate for that domain. However, if the attacker obtains a fraudulent certificate (via a compromised CA or a misissued cert), HTTPS provides false assurance. Certificate Transparency (CT) logs are the primary defense — they allow domain owners to detect unauthorized certificate issuance within hours."

"What is DNSSEC and does it fully prevent DNS hijacking?"

"DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records, allowing resolvers to verify that responses originated from the authoritative zone and were not tampered with. It prevents record manipulation and cache poisoning but does NOT protect against registrar-level hijacking (where the attacker controls the zone itself) or against attacks on the resolver before DNSSEC validation is applied. It also does not encrypt query content."

"What is DNS-over-HTTPS (DoH) and how does it help?"

"DoH encrypts DNS queries between the client and resolver using HTTPS, preventing ISP-level interception and local network eavesdropping. It stops passive monitoring of DNS queries and prevents on-path attackers from modifying responses in transit. However, it shifts trust to the DoH provider (e.g., Cloudflare, Google) and does not protect against hijacking at the authoritative zone level or registrar compromise."

"How do attackers obtain registrar credentials to perform registrar-level hijacking?"

"Primarily through spear-phishing campaigns targeting domain administrators, credential stuffing attacks using breached password databases, and SIM-swapping to bypass SMS-based MFA. The Sea Turtle APT group specifically targeted registrar employees and ICANN-adjacent organizations to pivot into DNS infrastructure they did not directly own."

"What is a CAA record and how does it limit certificate issuance?"

"A Certification Authority Authorization (CAA) DNS record specifies which Certificate Authorities are permitted to issue TLS certificates for a domain. If an attacker attempts to obtain a certificate from an unauthorized CA, that CA is required to check the CAA record and refuse issuance. While not foolproof (a hijacked DNS zone can modify CAA records), combined with CT monitoring it significantly narrows the window for fraudulent certificate issuance."

"How quickly can DNS hijacking attacks take effect and how long do they persist?"

"Router-level and ISP-level hijacking take effect immediately for clients using those resolvers. Registrar-level or authoritative zone changes propagate globally within minutes to hours depending on TTL values. The DNSpionage campaign maintained persistent access for over a year in some cases before detection, demonstrating that without active monitoring, these attacks can persist indefinitely."

DNS Hijacking: Redirecting Your Traffic Without You Knowing

The Domain Name System is the phone book of the internet. When your browser resolves bank.example.com, it trusts the answer it receives. DNS hijacking exploits that trust — an attacker who controls the DNS resolution path can silently redirect your traffic to infrastructure they control, intercept credentials, and serve malware, all while your browser displays a lock icon and a familiar URL.

This post dissects every major DNS hijacking vector, walks through real APT campaigns that used these techniques at scale, provides detection logic you can deploy today, and covers defenses that meaningfully reduce your attack surface.

How DNS Resolution Actually Works

Before examining attack vectors, understanding the resolution chain is essential.

When a client queries mail.corp.example.com:

The client asks its stub resolver (typically the OS resolver, configured via DHCP or static config)
The stub resolver forwards to a recursive resolver (e.g., your router, corporate DNS server, or 8.8.8.8)
The recursive resolver walks the delegation tree: root → .com TLD nameservers → example.com authoritative nameservers → answer
The answer is cached at the recursive resolver for the record’s TTL
The cached answer is returned to the client

Every hop in this chain is a potential hijack point.

Attack Vector 1: Router/Local DNS Hijacking

The most common consumer-facing attack. The attacker modifies the DNS server setting on a home or SOHO router, either by:

Exploiting an unauthenticated admin interface (CVE-2019-19494 on Broadcom-based routers, for example)
Using default/weak credentials (admin:admin, admin:password)
Drive-by exploitation via cross-site request forgery (CSRF) against the router’s admin panel from a malicious website

Once the router’s upstream DNS is changed to an attacker-controlled resolver, every device on the network sends DNS queries to the attacker. The attacker’s resolver returns legitimate answers for most domains (to avoid detection) and malicious answers for targets of interest.

Attack flow:

Attacker hosts a malicious page with JavaScript that fires a CSRF request to http://192.168.1.1/apply.cgi?dns1=203.0.113.5
Victim visits the page; browser silently submits the request
Router’s primary DNS is now the attacker’s resolver
Subsequent queries for banking domains return attacker-controlled IPs
Attacker’s server presents a cloned login page and captures credentials

This technique was used in the GhostDNS campaign (2018), which compromised over 100,000 Brazilian routers and redirected banking customers to credential-harvesting sites.

Attack Vector 2: ISP-Level and BGP-Assisted Hijacking

ISPs occupy a privileged position in the DNS resolution chain. An attacker who compromises ISP DNS infrastructure (or who is a rogue ISP) can manipulate responses for all downstream customers.

BGP hijacking (covered separately in another post) enables a related attack: by announcing a more specific BGP prefix for a DNS provider’s IP space, an attacker can intercept DNS traffic destined for legitimate resolvers like 8.8.8.8 or 1.1.1.1. Queries arrive at the attacker’s infrastructure instead, which then relays modified responses.

The 2018 AWS Route 53 / MyEtherWallet incident demonstrated this at scale. On April 24, 2018, attackers used BGP hijacking to intercept traffic destined for Amazon’s Route 53 DNS service. DNS queries for myetherwallet.com were answered with a malicious IP. The attacker’s server presented a valid-looking site with an EV TLS certificate obtained from a different CA. Approximately $152,000 in Ethereum was stolen before the attack was mitigated (~2 hours).

Attack Vector 3: Registrar-Level Hijacking (Sea Turtle APT)

This is the most sophisticated and impactful vector. Instead of attacking the resolution path, the attacker compromises the registrar or registry account that controls a domain’s NS records — pointing the domain to nameservers they control.

Sea Turtle (also tracked as Cosmic Gale, UNC1234) is an Iranian-nexus APT group active since at least 2017. Cisco Talos published their detailed analysis in April 2019. The campaign targeted:

Country-code TLD registries (including NASK for .pl, and NIC.tr)
Registrars serving government and military domains
DNS providers (including Netnod, a root DNS operator)

Attack flow:

Spear-phish registrar employee or compromise their VPN credentials
Log into registrar admin panel and change NS records for target domain (e.g., ministry.gov.xx) to attacker-controlled nameservers
Obtain a legitimate TLS certificate for the target domain from Let’s Encrypt or another CA (possible because the attacker now controls DNS, which Let’s Encrypt uses for domain validation)
Configure attacker nameservers to respond with attacker IP for target hostnames, legitimate answers for all others
Deploy credential-harvesting infrastructure at the attacker IP
MiTM all inbound connections: capture credentials, relay to legitimate service, restore original NS records

The credential harvesting phase typically lasted hours to days — long enough to capture VPN credentials from government employees attempting to authenticate, which then enabled deeper network compromise.

Affected organizations included the Greek government’s ccTLD manager, a Lebanese ISP, and multiple Middle Eastern governments. The campaign was active from at least 2017 through 2020 and likely beyond.

Attack Vector 4: DNSpionage Campaign

Cisco Talos documented the DNSpionage campaign in November 2018, identifying it as a separate but related campaign also targeting Middle Eastern infrastructure. Key technical characteristics:

Attackers compromised Lebanese government and UAE aviation sector domains via registrar credential theft
DNS A records were changed to attacker IPs for specific subdomains (webmail, remote access portals)
TTLs were deliberately set very low (typically 60–300 seconds) to limit cached evidence
The campaign used a custom malware family (DNSpionage RAT) delivered via the redirected login pages

The combination of low TTLs and selective targeting (only redirecting specific subdomains rather than entire domains) made the attacks extremely difficult to detect via passive DNS monitoring.

Attack Vector 5: Chollima and North Korean DNS Targeting

The Lazarus Group cluster tracked as Chollima has used DNS manipulation as part of supply chain and financial institution attacks. While less documented at the DNS infrastructure level compared to Sea Turtle, Lazarus operations have involved:

Compromising DNS configurations of cryptocurrency exchange domains
Using DNS hijacking in combination with code signing certificate theft to deliver signed malware
Targeting South Korean financial institutions with registrar-level redirection

CISA Advisory AA21-048A (February 2021) documents North Korean actors’ use of DNS infrastructure manipulation as part of broader cryptocurrency theft operations.

Detection: Identifying DNS Hijacking in the Wild

Detecting TTL Anomalies and Unexpected Record Changes

Low or rapidly changing TTLs are a red flag. Legitimate enterprise domains rarely have TTLs below 300 seconds.

 1# Query a domain from multiple resolvers and compare results
 2dig @8.8.8.8 mail.corp.example.com A +short
 3dig @1.1.1.1 mail.corp.example.com A +short
 4dig @9.9.9.9 mail.corp.example.com A +short
 5dig @208.67.222.222 mail.corp.example.com A +short
 6
 7# Check TTL values — inconsistency across resolvers indicates potential hijacking
 8dig @8.8.8.8 mail.corp.example.com A | grep -E "^mail|IN\s+A"
 9
10# Query authoritative nameservers directly (bypass cache)
11dig mail.corp.example.com A +trace +nodnssec
12
13# Check which nameservers are authoritative for a domain
14dig corp.example.com NS +short
15
16# Verify NS records match expected registrar configuration
17whois corp.example.com | grep -i "name server"

Comparing Responses Across Resolvers (Python)

 1#!/usr/bin/env python3
 2"""
 3dns_monitor.py — Compare DNS responses across multiple resolvers
 4to detect hijacking. Alert on discrepancies.
 5"""
 6import dns.resolver
 7import dns.exception
 8import json
 9from datetime import datetime
10
11RESOLVERS = {
12    "google": "8.8.8.8",
13    "cloudflare": "1.1.1.1",
14    "quad9": "9.9.9.9",
15    "opendns": "208.67.222.222",
16}
17
18DOMAINS_TO_MONITOR = [
19    "mail.corp.example.com",
20    "vpn.corp.example.com",
21    "login.corp.example.com",
22]
23
24def query_resolver(domain, resolver_ip, record_type="A"):
25    resolver = dns.resolver.Resolver(configure=False)
26    resolver.nameservers = [resolver_ip]
27    resolver.timeout = 5
28    resolver.lifetime = 10
29    try:
30        answers = resolver.resolve(domain, record_type)
31        return {
32            "ips": sorted([str(r) for r in answers]),
33            "ttl": answers.rrset.ttl,
34            "error": None
35        }
36    except dns.exception.DNSException as e:
37        return {"ips": [], "ttl": None, "error": str(e)}
38
39def check_for_hijacking(domain):
40    results = {}
41    for name, ip in RESOLVERS.items():
42        results[name] = query_resolver(domain, ip)
43
44    # Collect all unique answer sets
45    answer_sets = [
46        frozenset(r["ips"]) for r in results.values()
47        if r["ips"]
48    ]
49
50    # Flag if resolvers disagree
51    if len(set(answer_sets)) > 1:
52        print(f"[ALERT {datetime.utcnow().isoformat()}] Discrepancy detected for {domain}")
53        for resolver_name, data in results.items():
54            print(f"  {resolver_name}: {data['ips']} (TTL={data['ttl']})")
55        return True
56
57    # Flag suspiciously low TTLs
58    ttls = [r["ttl"] for r in results.values() if r["ttl"] is not None]
59    if ttls and min(ttls) < 300:
60        print(f"[WARN {datetime.utcnow().isoformat()}] Low TTL for {domain}: min={min(ttls)}s")
61
62    return False
63
64if __name__ == "__main__":
65    for domain in DOMAINS_TO_MONITOR:
66        check_for_hijacking(domain)

DNSSEC Validation

 1# Check if a domain has DNSSEC enabled
 2dig corp.example.com DNSKEY +short
 3
 4# Validate the full DNSSEC chain
 5dig corp.example.com A +dnssec +multi
 6
 7# Check for DS records at the parent zone (indicates DNSSEC delegation)
 8dig corp.example.com DS @a.gtld-servers.net +short
 9
10# Use delv for detailed DNSSEC validation output
11delv @8.8.8.8 corp.example.com A +rtrace
12
13# Verify a specific record's RRSIG
14dig corp.example.com A +dnssec | grep -E "RRSIG|A\s+[0-9]"

Detecting DNS Interception on Your Network

 1# iptables rule to log DNS queries going to unexpected destinations
 2# (Run on a Linux gateway/router)
 3iptables -I OUTPUT -p udp --dport 53 ! -d 192.168.1.1 -j LOG \
 4  --log-prefix "DNS-BYPASS: " --log-level 4
 5
 6# Same for TCP DNS
 7iptables -I OUTPUT -p tcp --dport 53 ! -d 192.168.1.1 -j LOG \
 8  --log-prefix "DNS-BYPASS-TCP: " --log-level 4
 9
10# Monitor with: journalctl -k | grep DNS-BYPASS
11
12# Verify that DNS traffic isn't being transparently proxied
13# by comparing responses from your configured resolver vs direct query
14MY_RESOLVER=$(cat /etc/resolv.conf | grep nameserver | head -1 | awk '{print $2}')
15echo "Configured resolver: $MY_RESOLVER"
16dig @$MY_RESOLVER example.com A +short
17# If your ISP is hijacking, this may differ from authoritative answer

SIEM Detection Logic

Splunk — Hunting for TTL anomalies in DNS logs:

index=dns sourcetype=dns_logs
| eval record_type=if(isnull(record_type), "A", record_type)
| where record_type="A" AND ttl < 300
| stats count min(ttl) as min_ttl values(answer) as answers by domain
| where count > 5
| sort - count

Splunk — Detect sudden NS record changes:

index=dns sourcetype=dns_logs record_type=NS
| stats values(answer) as ns_servers by domain _time
| streamstats window=2 current=true list(ns_servers) as ns_history by domain
| where mvcount(ns_history) > 1
| eval changed=if(mvindex(ns_history,0) != mvindex(ns_history,1), "YES", "NO")
| where changed="YES"

Certificate Transparency Monitoring

CT logs are one of the fastest ways to detect unauthorized certificate issuance:

 1# Monitor CT logs for your domain using crt.sh API
 2curl -s "https://crt.sh/?q=%.corp.example.com&output=json" | \
 3  python3 -c "
 4import json, sys
 5from datetime import datetime
 6
 7certs = json.load(sys.stdin)
 8for c in certs:
 9    issued = c.get('not_before', '')
10    cn = c.get('common_name', '')
11    issuer = c.get('issuer_ca_id', '')
12    print(f'{issued} | {cn} | CA={issuer}')
13" | sort -r | head -50
14
15# Automate with certspotter (open source)
16# certspotter -watchlist domains.txt -script /path/to/alert.sh

Defense: Hardening DNS Infrastructure

1. DNSSEC Deployment

DNSSEC must be enabled both at the registrar (DS record publication) and at the authoritative nameserver level. For a zone signed with BIND:

 1# Generate Zone Signing Key (ZSK) and Key Signing Key (KSK)
 2dnssec-keygen -a ECDSAP256SHA256 -b 256 -n ZONE corp.example.com       # ZSK
 3dnssec-keygen -a ECDSAP256SHA256 -b 256 -n ZONE -f KSK corp.example.com # KSK
 4
 5# Sign the zone
 6dnssec-signzone -A -3 $(head -c 1000 /dev/random | sha1sum | cut -b 1-16) \
 7  -N INCREMENT -o corp.example.com -t corp.example.com.zone
 8
 9# Publish the DS record at your registrar
10# (use the output of dnssec-dsfromkey on the KSK file)
11dnssec-dsfromkey Kcorp.example.com.+013+XXXXX.key

2. DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT)

For clients, configure encrypted DNS to prevent on-path interception:

 1# Configure systemd-resolved to use DoT (DNS-over-TLS)
 2# /etc/systemd/resolved.conf
 3[Resolve]
 4DNS=1.1.1.1#cloudflare-dns.com 9.9.9.9#dns.quad9.net
 5DNSOverTLS=yes
 6DNSSEC=yes
 7
 8# Restart
 9systemctl restart systemd-resolved
10
11# Verify
12resolvectl status | grep -E "DNS Server|DNS over TLS|DNSSEC"

For enterprise deployment, configure your DNS resolver (e.g., Unbound) to forward over TLS:

# /etc/unbound/unbound.conf snippet
forward-zone:
    name: "."
    forward-tls-upstream: yes
    forward-addr: 1.1.1.1@853#cloudflare-dns.com
    forward-addr: 9.9.9.9@853#dns.quad9.net

3. Registrar Security Controls

Enable registrar lock (also called domain lock or transfer lock) — prevents unauthorized domain transfers and NS record changes without multi-step verification
Use a registrar that supports Registry Lock (EPP serverTransferProhibited, serverUpdateProhibited, serverDeleteProhibited) — requires out-of-band verification for any changes
Enable MFA on all registrar accounts — prefer TOTP or hardware tokens over SMS
Restrict registrar account access by IP allowlist where supported
Monitor registrar account login events and change notifications via email/webhook

4. CAA Records

Publish CAA records to restrict which CAs can issue certificates for your domain:

1# Example zone file CAA records
2corp.example.com.  CAA 0 issue "letsencrypt.org"
3corp.example.com.  CAA 0 issue "digicert.com"
4corp.example.com.  CAA 0 issuewild "digicert.com"
5corp.example.com.  CAA 0 iodef "mailto:security@corp.example.com"
6
7# Verify your CAA records are published
8dig corp.example.com CAA +short

5. Passive DNS Monitoring

Subscribe to passive DNS services that retain historical DNS records. When an attacker changes your NS records, passive DNS will show the change:

Farsight DNSDB — commercial, comprehensive historical passive DNS
CIRCL Passive DNS — free, covers many TLDs
RiskIQ / Microsoft Defender TI — commercial, includes change alerting

1# Using CIRCL's passive DNS API (free, rate-limited)
2curl -s "https://www.circl.lu/pdns/query/corp.example.com" | \
3  python3 -m json.tool | grep -E "rrname|rrtype|rdata|time_last"

6. RPZ (Response Policy Zones)

Deploy DNS RPZ on your recursive resolvers to block known malicious domains and prevent resolution of attacker infrastructure:

# BIND RPZ configuration snippet
zone "rpz.block" {
    type master;
    file "/etc/bind/rpz.block.db";
    allow-query { none; };
};

# In options block:
response-policy {
    zone "rpz.block" policy NXDOMAIN;
};

MITRE ATT&CK Mapping

T1584.002 — Compromise Infrastructure: DNS Server
T1557 — Adversary-in-the-Middle (result of DNS hijacking)
T1040 — Network Sniffing (credential capture via hijacked DNS)
T1556 — Modify Authentication Process (credential harvesting via cloned portals)

Summary

DNS hijacking encompasses a range of attack techniques from trivial router exploitation to sophisticated registrar-level compromises by nation-state actors. The Sea Turtle APT demonstrated that DNS infrastructure attacks can persist undetected for years when organizations lack proactive monitoring. Effective defense requires a layered approach: DNSSEC for record integrity, DoH/DoT for transport security, registry lock for registrar protection, CAA records and CT monitoring for certificate oversight, and passive DNS monitoring for change detection. No single control is sufficient — the combination is what makes the attack surface meaningfully harder to exploit.