Your Employees Typed the Right URL — And Still Got Hacked
In April 2022, researchers at Avast documented a campaign where a threat actor compromised home routers and used DNS hijacking to redirect users from legitimate banking sites to pixel-perfect phishing clones. Victims typed the correct URL into their browser. Their browser showed the correct domain name. They still handed their credentials to attackers.
That's the essence of a DNS spoofing attack — and it's one of the most insidious threats in network security because it undermines the one thing users are trained to trust: the address bar.
This post breaks down how DNS spoofing works, why traditional security advice fails against it, and the concrete steps your organization needs to take right now.
What Is a DNS Spoofing Attack?
DNS spoofing — also called DNS cache poisoning — is an attack where a malicious actor corrupts the Domain Name System resolution process so that a legitimate domain name resolves to a wrong, attacker-controlled IP address. When your employee types bank.example.com, their device asks a DNS resolver for the IP address. If that resolver has been poisoned, it returns the attacker's IP instead.
The result: your user lands on a fake site, often identical to the real one, and enters credentials, downloads malware, or triggers a data breach — without ever seeing a warning.
DNS Spoofing vs. DNS Hijacking: What's the Difference?
People use these terms interchangeably, but they're distinct. DNS spoofing poisons the cache of a resolver or intercepts queries in transit. DNS hijacking compromises the DNS server itself or modifies a device's DNS settings (like the router-based attacks Avast documented). Both produce the same outcome — misdirected traffic — but the attack surface is different, which matters when you're building defenses.
How a DNS Spoofing Attack Actually Works
Here's the step-by-step mechanics, stripped of textbook abstraction.
Step 1: The Attacker Identifies a Target Resolver
Every organization relies on DNS resolvers — either their ISP's, a public resolver like Google's 8.8.8.8, or an internal one. The attacker identifies which resolver the target network uses. This is trivial reconnaissance.
Step 2: The Attacker Races the Legitimate Response
When a DNS resolver doesn't have a cached answer, it queries upstream authoritative servers. The attacker floods the resolver with forged responses, each guessing the transaction ID of the pending query. If the attacker's forged response arrives before the real one and matches the transaction ID, the resolver accepts it.
This is the classic Kaminsky attack, disclosed by Dan Kaminsky in 2008. It exploited the fact that DNS transaction IDs are only 16 bits — giving attackers a realistic chance of guessing correctly.
Step 3: The Poisoned Record Gets Cached
Once the resolver accepts the forged response, it caches the bad record. Every user on that network who requests that domain gets sent to the attacker's server — for the duration of the TTL (time-to-live) value the attacker set. A long TTL means hours or days of misdirected traffic.
Step 4: Credential Theft and Malware Delivery
The attacker's server hosts a clone of the target site. Users enter credentials, download files, or interact with forms — all feeding data directly to the threat actor. In sophisticated campaigns, attackers use this foothold to deliver ransomware payloads or establish persistent access.
The $4.88M Reason You Can't Ignore This
IBM's 2024 Cost of a Data Breach Report pegged the global average breach cost at $4.88 million. DNS spoofing attacks are particularly expensive because they're hard to detect and can affect every user on a network simultaneously. A single poisoned resolver serving 500 employees means 500 potential credential theft events before anyone notices.
I've seen organizations discover DNS poisoning only after their banking credentials were used for wire fraud — days after the initial compromise. By then, the attacker had pivoted from credential theft to full account takeover.
Why Traditional Security Advice Falls Short
Most security awareness training tells users to "check the URL" and "look for the padlock." Against a DNS spoofing attack, both fail.
The URL is correct — the domain name hasn't changed. The attacker intercepted the resolution, not the address. And attackers routinely provision TLS certificates for their malicious servers using automated certificate authorities. The padlock appears. The URL looks right. The page looks identical.
This is why your cybersecurity awareness training program needs to go beyond surface-level advice. Users need to understand that even "correct" URLs can lead to malicious destinations — and they need to recognize secondary indicators like unexpected login prompts, certificate warnings, or behavioral anomalies.
7 Defenses That Actually Work Against DNS Spoofing
1. Deploy DNSSEC Across Your Domains
DNS Security Extensions (DNSSEC) cryptographically sign DNS records so resolvers can verify responses haven't been tampered with. CISA has published extensive guidance on DNSSEC implementation at cisa.gov. If your organization controls its own domains, enabling DNSSEC is the single most effective technical countermeasure.
2. Use DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT)
Traditional DNS queries travel in plaintext — trivially intercepted on any network. DoH and DoT encrypt the query, preventing on-path attackers from injecting forged responses. Configure your endpoints and internal resolvers to use encrypted DNS.
3. Enforce Multi-Factor Authentication Everywhere
Even if a DNS spoofing attack captures a user's password, multi-factor authentication blocks the attacker from using it. MFA is your safety net when prevention fails. NIST SP 800-63B provides detailed guidance on authentication assurance levels at nist.gov.
4. Monitor DNS Query Logs for Anomalies
Sudden changes in DNS resolution patterns — a domain that's resolved to the same IP for months suddenly pointing somewhere new — are red flags. Your SOC should alert on these changes, especially for critical domains like email providers, banking, and SaaS applications.
5. Implement Zero Trust Network Architecture
A zero trust approach assumes the network is already compromised. Every access request gets verified, regardless of network location. This limits the blast radius when DNS spoofing succeeds — because even after landing on a poisoned page, lateral movement and resource access require continuous authentication.
6. Run Phishing Simulations That Include DNS Scenarios
Standard phishing simulations test email-based social engineering. But your employees also need to recognize scenarios where legitimate-looking sites behave unexpectedly. Your phishing awareness training program should include exercises that train users to report anomalies — even when the URL looks correct.
7. Harden Your Resolvers
If you operate internal DNS resolvers, patch them aggressively. Randomize source ports (the primary Kaminsky mitigation). Restrict recursive queries to internal clients only. Disable open resolution. These are basic hygiene steps that eliminate the easiest attack paths.
What Does a DNS Spoofing Attack Look Like to the Victim?
From the user's perspective, nothing looks wrong. The URL is correct. The page loads normally. The login form appears as expected. This is what makes DNS spoofing particularly dangerous — there's no visible indicator of compromise for the average user.
In my experience, the first sign is usually downstream: an account gets taken over, a wire transfer goes to the wrong destination, or ransomware appears on the network days later. The root cause gets traced back to credentials stolen via a spoofed DNS resolution that nobody noticed.
The Verizon 2024 Data Breach Investigations Report found that stolen credentials were involved in 31% of all breaches over the past decade. DNS spoofing is one of the quietest ways attackers harvest those credentials at scale. You can review the full DBIR findings at verizon.com.
The Organizational Blind Spot Nobody Talks About
Most organizations focus their security budgets on endpoint protection and email filtering. DNS security gets treated as an infrastructure concern — something the network team handles. That's a mistake.
DNS is the foundation of every network interaction. Every web request, every API call, every SaaS login starts with a DNS query. When that foundation is compromised, every layer built on top of it is compromised too.
I've audited organizations with six-figure SIEM deployments that had zero monitoring on their DNS resolvers. They could detect a suspicious PowerShell script in milliseconds but would miss a poisoned DNS cache for days. That's the blind spot.
Build the Human Firewall Alongside the Technical One
Technical controls like DNSSEC, encrypted DNS, and resolver hardening are essential. But a DNS spoofing attack ultimately targets your people — their credentials, their trust, their daily workflows. You need both layers.
Train your teams to report anything unexpected during authentication — a second login prompt, a page that loads slightly differently, a certificate warning that disappears. These micro-anomalies are often the only human-detectable signals of DNS manipulation.
Start with a structured security awareness training program that covers DNS-based threats alongside traditional phishing and social engineering. Then layer in realistic phishing simulations that test whether your employees escalate suspicious behavior even when the surface indicators look normal.
DNS spoofing isn't going away. The protocol's fundamental design — built for speed, not security — means attackers will always probe for resolver weaknesses. Your defense needs to be just as persistent.