You’ve hardened your servers. You’ve deployed endpoint detection. Your SOC team monitors alerts around the clock. But none of that matters when an attacker rewrites the internet’s address book and redirects your traffic before it ever reaches your infrastructure.
That’s the quiet devastation of DNS hijacking. It’s an attack class that doesn’t breach your firewall so much as render it irrelevant.
DNS hijacking exploits the foundational trust layer of the internet: the Domain Name System.
When an attacker gains control of your DNS records, they control where your users go. They can intercept credentials, exfiltrate data, impersonate your services, and issue fraudulent TLS certificates. And they do this all while your servers sit untouched, logging nothing unusual. The vulnerability itself depends on your infrastructure.
This post breaks down how DNS hijacking works, why certain industries are disproportionately targeted, and what your team can do to detect and prevent it.
How DNS Resolution Works: A Quick Refresher
Before dissecting the attacks, it’s worth revisiting how DNS resolution actually works. Every time a user types a domain name into a browser, a multi-step lookup translates that human-readable name into an IP address.
Here’s the simplified chain:
User’s device → Recursive resolver → Root nameserver → TLD nameserver → Authoritative nameserver → IP address returned
First, the user’s device checks its local cache. If it doesn’t have a fresh answer, it queries a recursive resolver (typically operated by the user’s ISP or a provider like Cloudflare or Google). The recursive resolver, if it doesn’t already have the answer cached, walks up the DNS hierarchy: it asks a root nameserver which points to the appropriate top-level domain (TLD) nameserver (like .com or .io), which in turn points to the authoritative nameserver for the specific domain. That authoritative nameserver responds with the final IP address, and the answer flows back down the chain to the user.
Every link in this chain represents a potential attack surface. The recursive resolver trusts the authoritative nameserver. The authoritative nameserver is determined by records at the registrar. The registrar account is protected by credentials and (hopefully) multi-factor authentication. The routing layer that carries all of this traffic relies on the Border Gateway Protocol (BGP), which was designed in an era when trust was implicit.
DNS hijacking, in its various forms, exploits weaknesses at one or more of these links.
Attack Methodologies
Not all DNS hijacks look the same. Attackers choose their entry point based on opportunity, and there are more entry points than most teams realize. The four methodologies below represent the most common and consequential attack paths. They range from stolen passwords to manipulated internet routing. Each exploits a different link in the DNS chain, but they all converge on the same outcome: your users end up somewhere you didn’t send them.
1. Credential Compromise at the Registrar or DNS Provider
This is the most straightforward vector, and it’s alarmingly common. Every domain is managed through a registrar account (GoDaddy, Namecheap, Cloudflare, etc.) or a dedicated DNS hosting provider. If an attacker compromises the credentials to that account — through phishing, credential stuffing, password reuse, or social engineering of support staff — they gain the ability to modify DNS records directly.
Once inside, the attacker can change A records to point your domain to a server they control, modify MX records to intercept email, update NS records to delegate your entire zone to their own nameservers, or alter TXT records to pass domain validation for a fraudulent TLS certificate.
The 2019 “DNSpionage” campaign, attributed to APT groups operating in the Middle East, used exactly this playbook. Attackers compromised DNS provider accounts, modified records to redirect traffic through interception nodes, obtained Let’s Encrypt certificates for the hijacked domains, and performed man-in-the-middle attacks on VPN and webmail portals. The target organizations’ servers were never breached. Their DNS was simply rewritten underneath them.
Why it works: Many organizations treat their registrar account as an administrative afterthought. Credentials are shared among team members, MFA is optional or disabled, and there’s no monitoring for unauthorized record changes. The registrar is, functionally, a single point of failure for your entire domain.
2. DNS Cache Poisoning
Cache poisoning attacks target the recursive resolver rather than the authoritative source. The goal is to inject a forged DNS response into the resolver’s cache so that all subsequent queries for a given domain return the attacker’s IP address.
The classic version of this attack was demonstrated by Dan Kaminsky in 2008. The attacker floods the recursive resolver with forged responses to a query, attempting to guess the correct transaction ID and source port before the legitimate response arrives. If the forged response is accepted, the poisoned record is cached and served to every user who queries that resolver — potentially thousands or millions of people — until the TTL (time to live) expires.
Modern resolvers have implemented mitigations like source port randomization and query name randomization (0x20 encoding), which significantly increase the entropy an attacker must guess. But cache poisoning hasn’t disappeared. Variants like the SAD DNS attack (2020) demonstrated that side-channel vulnerabilities in the Linux kernel could be exploited to de-randomize source ports, reopening the attack surface. Hackers continue to find new angles.
Why it works: Cache poisoning doesn’t require compromising any account. It exploits the fact that DNS was designed without built-in authentication. A recursive resolver has no native way to verify that a response actually came from the authoritative nameserver — it accepts the first valid-looking response it receives.
3. BGP Hijacking
BGP hijacking operates one layer below DNS, at the network routing level. The Border Gateway Protocol is how autonomous systems (ASes) on the internet announce which IP address ranges they’re responsible for. It’s a trust-based system: when an AS announces a route, other routers generally accept it.
An attacker who controls an AS (or compromises one) can announce a more specific route for the IP address range used by a target’s authoritative nameservers. Internet traffic destined for those nameservers is then rerouted through the attacker’s network, where they can serve forged DNS responses.
In April 2018, attackers used a BGP hijack to reroute traffic destined for Amazon’s Route 53 DNS service, specifically targeting the authoritative nameservers for MyEtherWallet.com. For approximately two hours, users querying for MyEtherWallet received responses pointing to a phishing server. The attackers stole approximately $17 million in cryptocurrency. The target’s DNS records were never modified. The route to the DNS infrastructure itself was hijacked.
Why it works: BGP has no built-in authentication mechanism. Route announcements are accepted on trust. While initiatives like RPKI (Resource Public Key Infrastructure) exist to validate route origins, adoption remains incomplete. According to NIST data, as of 2024, only about 40% of IPv4 routes are covered by valid RPKI ROAs (Route Origin Authorizations).
4. Registrar Account Takeover via Social Engineering
Distinct from simple credential compromise, this vector targets the human support layer at registrars and hosting providers. Attackers call support lines, impersonate domain owners, present fabricated identification, and convince support agents to transfer domain ownership or reset account credentials.
The attack on Squarespace-managed domains in July 2024 illustrated a variation on this theme. Following the migration of Google Domains’ portfolio to Squarespace, attackers exploited weaknesses in the account creation flow for migrated domains. Because many domain owners hadn’t yet created Squarespace accounts, attackers were able to claim those accounts using email addresses associated with the domains. Multiple cryptocurrency and Web3 projects were affected, including Compound Finance, Celer Network, and Pendle Finance.
Why it works: No amount of technical hardening can fully compensate for a support agent who can override account protections. The human element remains the most unpredictable variable in the security chain.
Why Crypto Projects Are Prime Targets
Cryptocurrency and DeFi projects face a uniquely dangerous threat surface when it comes to DNS hijacking, for several interconnected reasons.
Immediate financial payoff. Unlike traditional enterprises where DNS hijacking might be used for espionage or long-term credential harvesting, hijacking a crypto project’s frontend can yield millions in minutes. Users connecting wallets to a spoofed dApp interface are signing transactions that drain their wallets directly to the attacker. There’s no weeks-long lateral movement, no exfiltration pipeline. The theft is atomic and immediate.
Irreversible transactions. Blockchain transactions can’t be rolled back. Once funds are transferred to an attacker’s wallet, there is no chargeback mechanism, no bank to call, no wire recall. The finality that makes blockchains useful also makes them unforgiving when the frontend layer is compromised.
Decentralized teams, centralized infrastructure. Many crypto projects operate with distributed, pseudonymous teams. Their smart contracts may be decentralized and immutable, but their domain names, DNS records, and frontend hosting are managed through conventional, centralized infrastructure — often with unclear ownership and inconsistent security practices. The gap between the security model of the protocol and the security model of its web presence is where attackers live.
High-value, low-maturity targets. Newer projects frequently manage billions in TVL (total value locked) while operating with the security posture of a startup. Registrar accounts may be tied to a single founder’s personal email. DNS changes may not be monitored. Domain locks may not be enabled.
The pattern is consistent across incidents: MyEtherWallet (2018), PancakeSwap (2021), Curve Finance (2022), and the wave of Squarespace-related hijacks in 2024. It is also a recurring operational reality.
Detection and Prevention Strategies
Understanding the attack surface is half the problem. The other half is closing it. So, we’ve got good news, and bad news. The good news is that most DNS hijacking incidents exploit gaps that are well understood and entirely preventable. The bad news is that most organizations haven’t addressed them yet. The following strategies are ordered roughly by effort-to-impact ratio, starting with the changes your team can make this afternoon.
Lock Down Your Registrar Account
This is the lowest-effort, highest-impact step, and it’s still skipped by a remarkable number of organizations. Enable multi-factor authentication (hardware keys preferred) on every registrar and DNS provider account. Use a unique, strong password. Limit account access to the minimum number of people necessary. Enable registrar lock (also called “clientTransferProhibited”) and, if available, registry lock — a server-side lock that requires out-of-band verification (often a phone call with a PIN) before any record changes can be made.
Deploy DNSSEC
DNSSEC (Domain Name System Security Extensions) adds cryptographic signatures to DNS responses, allowing recursive resolvers to verify that a response hasn’t been tampered with and that it genuinely originated from the authoritative source. It directly mitigates cache poisoning attacks and provides a layer of integrity verification across the resolution chain.
DNSSEC isn’t a silver bullet — it doesn’t protect against registrar account compromise (if the attacker can modify records, they can modify DNSSEC keys too) — but it closes a significant attack surface. It should be considered baseline hygiene for any domain handling sensitive traffic.
Monitor DNS Records Continuously
You can’t respond to what you don’t detect. Implement continuous monitoring of your DNS records — A, AAAA, MX, NS, TXT, CNAME, and SOA records at minimum. Alert on any unauthorized change. Several commercial and open-source tools support this, including DomainSure’s own monitoring platform, which provides real-time alerting on record modifications, WHOIS changes, and certificate transparency log entries.
Monitor Certificate Transparency Logs
Certificate Transparency (CT) logs are a public record of every TLS certificate issued by participating Certificate Authorities. By monitoring CT logs for your domains, you can detect if an attacker has obtained a fraudulent certificate — a common step in DNS hijack attacks, since the attacker needs a valid cert to avoid browser warnings. Tools like CertSpotter, Facebook’s CT monitoring, or integrated platforms like DomainSure can automate this surveillance.
Implement BGP Monitoring and RPKI
If your organization operates its own authoritative nameservers or ASN, implement RPKI to sign your route announcements and validate the announcements you receive. Monitor BGP route changes using services like BGPStream, RIPE RIS, or Cloudflare Radar. For most organizations that rely on third-party DNS providers, choosing a provider with robust BGP security practices and anycast infrastructure reduces exposure.
Reduce TTL for Critical Records — Strategically
Lower TTLs mean poisoned cache entries expire faster, reducing the window of impact. However, very low TTLs increase query volume and can affect performance. A reasonable approach: keep TTLs moderate during normal operations but have a runbook to drop them quickly during an active incident to accelerate recovery once records are corrected.
Frequently Asked Questions
How is DNS hijacking different from DNS spoofing?
The terms are sometimes used interchangeably, but there’s a useful distinction. DNS spoofing typically refers to injecting forged responses at the protocol level (cache poisoning). DNS hijacking is a broader category that includes modifying records at the source (registrar/provider compromise), rerouting traffic (BGP hijacking), and any other method that results in users being directed to attacker-controlled infrastructure through DNS manipulation.
Can HTTPS protect me from DNS hijacking?
Partially. If the attacker redirects your domain but doesn’t have a valid TLS certificate, users will see a browser warning. However, attackers routinely obtain valid certificates for hijacked domains using automated CAs like Let’s Encrypt, which validate domain control via DNS or HTTP challenges — both of which the attacker controls during a hijack. Once the attacker has a valid cert, HTTPS provides no protection.
Does DNSSEC prevent all DNS hijacking?
No. DNSSEC protects the integrity of DNS responses in transit, which mitigates cache poisoning. But if an attacker compromises your registrar account and modifies records at the source — including DNSSEC signing keys — the signed responses will still validate. DNSSEC is an essential layer, not a complete solution.
How quickly can a DNS hijack be detected?
Without monitoring, hijacks have gone undetected for hours or even days. With continuous DNS record monitoring, certificate transparency monitoring, and anomaly detection, detection can happen within minutes of a record change. The gap between those two scenarios is the gap between losing millions and catching an attack before it causes damage.
What should we do during an active DNS hijack?
Immediately contact your registrar to regain control and revert records. Revoke any fraudulent certificates by contacting the issuing CA. Notify users through out-of-band channels (social media, status pages hosted on separate infrastructure). Lower TTLs to accelerate propagation of corrected records. Conduct a post-incident review of registrar account security, access controls, and monitoring gaps.
The Bottom Line
DNS hijacking succeeds because it targets the layer between your users and your infrastructure. It exploits a layer that most security programs treat as someone else’s problem. Your firewall can’t block an attack that never touches your network. Your IDS can’t flag traffic that was rerouted before it arrived.
The fix we’re suggesting here is a posture shift: treating your domain and DNS infrastructure as tier-one critical assets, with the same rigor you apply to your production servers.
That means locking down registrar access. Deploying DNSSEC. Monitoring records continuously. Watching certificate transparency logs. And having a response plan for when (not if) something changes unexpectedly.
DomainSure provides continuous DNS monitoring, DNSSEC management, and real-time alerting for domain and nameserver changes. If your domain is critical to your business, your DNS security shouldn’t be an afterthought. Learn how DomainSure can help →
Apply for a Domainsure Invite
Get a Free Domain Health Check
Due to high demand: allow up to 24 hours for report delivery.
