The previous chapters covered attacks on the DNS protocol itself — poisoning caches, forging responses, intercepting queries. But some of the most devastating DNS-related attacks don’t touch the DNS protocol at all. Instead, they target the infrastructure around DNS: domain registrar accounts, routing tables, and the trust relationships that hold the internet together.
These attacks are harder to detect, harder to defend against, and often invisible to the victim until the damage is done.
DNS Hijacking Methods
DNS hijacking redirects DNS queries or modifies DNS records through means outside the DNS protocol. The attacker doesn’t need to race a cache poisoning attempt or break encryption — they simply change the authoritative data at the source, targeting the registries, registrars, and infrastructure that manage domain records.
Router-Level Hijacking
The simplest DNS hijacking targets the user’s local network. A compromised home router can:
- Change the DNS server settings delivered via DHCP, pointing clients to a malicious resolver
- Intercept DNS traffic on port 53 and redirect it to the attacker’s resolver, regardless of what DNS server the client has configured
- Modify DNS responses in transit, replacing legitimate IP addresses with the attacker’s
This attack is common in consumer environments where routers run outdated firmware with known vulnerabilities. The DNSChanger malware (discovered in 2011) infected millions of computers and routers, redirecting DNS queries to rogue servers that injected fraudulent ads and redirected users to malicious sites. When the FBI seized the rogue DNS servers, they had to operate replacement servers for months to avoid cutting off internet access for millions of infected users.
ISP-Level Hijacking
ISPs can manipulate DNS responses for their own purposes — and many do:
- NXDOMAIN redirection — when a user types a non-existent domain, instead of returning an NXDOMAIN (not found) error, the ISP redirects to a search or advertising page. This violates DNS protocol standards (RFC 1035 defines NXDOMAIN as an authoritative “name does not exist” response) but is commercially profitable.
- Content filtering — ISPs may be legally required to block certain domains. They implement this by returning false DNS responses for blocked domains.
- Transparent DNS proxying — some ISPs intercept all traffic on port 53, regardless of the configured DNS server, and redirect it to their own resolver. Even if you configure 8.8.8.8, your queries go to the ISP’s server.
ISP-level manipulation is a primary motivation for encrypted DNS (DoH/DoT). When DNS queries are encrypted and sent to a resolver outside the ISP’s control, these techniques become ineffective.
Registrar Account Compromise
The most dangerous DNS hijacking targets the domain’s registration itself. If an attacker gains access to a domain owner’s registrar account, they can:
- Change nameserver records — point the domain to authoritative servers they control
- Modify DS records — break or replace DNSSEC validation
- Change registrant information — take ownership of the domain
- Transfer the domain — move it to a registrar under their control
Once the attacker controls the nameserver delegation, they control all DNS responses for the domain. They can serve any content they want, intercept email (by modifying MX records), and even obtain valid TLS certificates for the domain (since certificate authorities validate domain control through DNS).
This isn’t theoretical. It happens regularly to high-profile targets.
Notable Incidents
MyEtherWallet BGP Hijack (2018)
In April 2018, attackers hijacked the IP address space used by Amazon’s Route 53 DNS service through a BGP attack. By announcing more-specific routes for Amazon’s DNS IP ranges from a compromised ISP in Ohio, the attackers redirected DNS queries intended for Amazon’s servers to their own infrastructure.
For approximately two hours, users querying for myetherwallet.com through affected resolvers received DNS responses pointing to a phishing server in Russia. The phishing site presented a clone of MyEtherWallet’s interface and stole approximately $150,000 in cryptocurrency from users who entered their private keys.
This attack was remarkable because it didn’t compromise MyEtherWallet’s domain or registrar account. Instead, it attacked the routing infrastructure to intercept DNS queries in transit — a level of sophistication that most domain owners have no ability to defend against.
Sea Turtle Campaign (2017-2019)
The Sea Turtle campaign, attributed to a nation-state actor and documented by Cisco Talos in 2019, was one of the most sophisticated DNS hijacking operations ever discovered. The attackers systematically compromised DNS infrastructure across the Middle East and North Africa to intercept communications of government agencies, intelligence services, and critical infrastructure operators.
The attack methodology was multi-layered:
- Compromised registrar accounts — attackers gained access to domain registrar portals through spear-phishing and credential theft
- Modified NS records — pointed victim domains to attacker-controlled nameservers
- Obtained valid TLS certificates — with control over DNS, the attackers could pass domain validation checks and obtain certificates from public CAs
- Man-in-the-middle — the attackers proxied traffic through their servers, decrypting it with the fraudulently obtained certificates, then re-encrypting and forwarding to the legitimate server
Victims had no indication anything was wrong. Their domains resolved. Their websites loaded. Their email worked. But every packet passed through the attacker’s infrastructure.
The campaign targeted ccTLD registries (the organizations managing country-code top-level domains), DNS registrars, and DNS hosting providers — attacking the DNS infrastructure itself rather than individual domains. This made it exceptionally difficult to detect and remediate.
DNSpionage (2018-2019)
The DNSpionage campaign, also attributed to nation-state actors, targeted government agencies and private companies in Lebanon and the UAE. Attackers compromised DNS records to redirect email traffic through their servers, harvesting credentials and intercepting sensitive communications.
Like Sea Turtle, DNSpionage obtained valid TLS certificates for hijacked domains, making the interception invisible to end users. The campaign demonstrated that DNS hijacking combined with certificate fraud creates a nearly undetectable surveillance capability.
BGP Hijacking: Going Below DNS
The Border Gateway Protocol (BGP) is the routing protocol that determines how traffic flows between networks on the internet. It operates on trust — when a network announces that it can reach a particular IP address range, other networks believe it and route traffic accordingly.
BGP has no built-in authentication. Any network (autonomous system) can announce any IP prefix, and its neighbors will accept the announcement if it looks reasonable. This makes BGP hijacking possible: an attacker announces routes for IP addresses they don’t own, and traffic intended for those addresses flows to the attacker instead.
How BGP Hijacking Targets DNS
DNS is particularly vulnerable to BGP attacks because:
-
DNS resolver IPs are well-known — Google’s 8.8.8.8, Cloudflare’s 1.1.1.1, and similar public resolvers have fixed, published IP addresses. An attacker who hijacks these addresses can impersonate the resolver.
-
Authoritative nameserver IPs are discoverable — the IP addresses of a domain’s authoritative servers are public information. Hijacking those addresses allows the attacker to serve fake DNS responses.
-
DNS is latency-sensitive — BGP hijacks typically affect only a portion of the internet (networks that accept the fraudulent route). But DNS queries that are misdirected even briefly can poison caches that serve thousands of users.
The BGP Hijacking Process
Normal routing:
User → ISP → [Internet] → Google DNS (8.8.8.8)
After BGP hijack:
User → ISP → [Internet] → Attacker (claiming to be 8.8.8.8)
The attacker announces a more-specific route for the target IP range. BGP prefers more-specific routes, so networks that receive the fraudulent announcement route traffic to the attacker instead of the legitimate destination. The attacker can then:
- Answer DNS queries with false data — redirecting users to phishing or malware sites
- Proxy queries to the real resolver, selectively modifying responses — a surgical man-in-the-middle
- Harvest query data — building a surveillance database of DNS traffic
Mitigation Strategies
Registry Lock
Registry lock (sometimes called registrar lock or domain lock) adds an additional layer of protection to critical domains. When a domain has registry lock enabled:
- Changes to nameserver records, DS records, or registrant information require manual verification by the registry operator
- The verification typically involves out-of-band confirmation — a phone call to a pre-registered security contact
- Automated or API-based changes are blocked
Registry lock doesn’t prevent all attacks, but it adds a significant barrier. An attacker who compromises a registrar account still can’t modify a registry-locked domain without also compromising the out-of-band verification process.
Most TLD registries offer some form of registry lock, though it’s often a premium service. For high-value domains (financial institutions, government agencies, major brands), it’s an essential protection.
Multi-Factor Authentication
The most effective defense against registrar account compromise is strong authentication:
- MFA on all registrar accounts — hardware security keys (FIDO2/WebAuthn) provide the strongest protection
- Separate credentials — don’t reuse passwords from other services
- Audit logging — monitor registrar account activity for unauthorized changes
- Role separation — limit the number of people with registrar account access
RPKI (Resource Public Key Infrastructure)
RPKI addresses BGP hijacking by adding cryptographic authentication to route announcements. It allows IP address holders to create Route Origin Authorizations (ROAs) — signed statements declaring which autonomous systems are authorized to announce their IP prefixes.
Networks that implement RPKI validation can reject BGP announcements that aren’t backed by valid ROAs. If Google creates a ROA stating that only AS15169 is authorized to announce 8.8.8.0/24, networks doing RPKI validation will reject a fraudulent announcement from any other AS.
RPKI adoption has grown significantly since 2018, with major networks (Cloudflare, Google, Amazon, and many large ISPs) implementing both ROA creation and route validation. However, RPKI is not yet universal — many networks still accept unvalidated routes, leaving gaps that attackers can exploit.
Certificate Transparency
Certificate Transparency (CT) logs provide a defense against the fraudulent certificate issuance that accompanies DNS hijacking. All publicly trusted CAs must log certificates in CT logs, and domain owners can monitor these logs for unexpected certificates issued for their domains.
If an attacker obtains a certificate for your domain by hijacking DNS validation, the certificate will appear in CT logs — often within minutes. Monitoring services (like Facebook’s CT monitoring tool, Sectigo’s, or open-source alternatives) can alert domain owners to unauthorized certificates, enabling rapid response.
Key Takeaways
- DNS hijacking targets the infrastructure around DNS — registrar accounts, routing tables, and trust relationships — not the protocol itself
- Registrar compromise is the most direct attack: changing NS records gives the attacker complete control over a domain’s DNS
- BGP hijacking can redirect DNS traffic by manipulating internet routing — as demonstrated by the MyEtherWallet attack
- Nation-state campaigns (Sea Turtle, DNSpionage) combine DNS hijacking with fraudulent TLS certificates for invisible interception
- Registry lock adds manual, out-of-band verification to critical domain changes
- RPKI addresses BGP hijacking by authenticating route announcements cryptographically
- Certificate Transparency provides an early warning system for fraudulent certificate issuance