DNS Attacks Explained: How Hackers Reroute Users to Malicious Sites

To understand how DNS is attacked, we must first understand the basic flow of a DNS resolution and where the vulnerabilities lie. When a user types a URL into their browser, the operating system first checks its local DNS cache. If the IP isn't found, it queries a recursive DNS resolver (typically provided by the ISP or a public service like Google's 8.8.8.8).

If the recursive resolver doesn't have the answer cached, it embarks on a hierarchical query process:

1. It queries a Root Name Server to find the Top-Level Domain (TLD) server (e.g., the .com server).
2. It queries the TLD Server to find the Authoritative Name Server for the specific domain.
3. It queries the Authoritative Name Server, which provides the final IP address.
4. The recursive resolver caches this answer and returns it to the user.

The primary vulnerability lies in the fact that standard DNS queries and responses are sent in cleartext (usually over UDP port 53) and lack cryptographic signatures. A recursive resolver generally trusts the first seemingly valid response it receives that matches the Transaction ID of its query. This implicit trust model is what attackers ruthlessly exploit.

DNS Attacks encompass a variety of sophisticated techniques, each with distinct methodologies and impacts. We will analyze the most critical of these attack vectors.

DNS Cache Poisoning (DNS Spoofing)

DNS Cache Poisoning is perhaps the most insidious form of a DNS attack because it affects the infrastructure itself, not just an individual user.

In a cache poisoning attack, the adversary's goal is to inject a fraudulent DNS record into the cache of a recursive DNS resolver. When the resolver attempts to fetch the IP for bank.com, the attacker races to send a forged response containing a malicious IP address before the legitimate Authoritative Name Server can respond.

To succeed, the attacker must perfectly forge the DNS response, which requires matching the 16-bit Transaction ID and the source/destination ports of the original query. Historically, this was difficult, but vulnerabilities like the famous Kaminsky Flaw (discovered by Dan Kaminsky in 2008) demonstrated how attackers could force resolvers to issue predictable queries, making it drastically easier to brute-force the Transaction ID and successfully poison the cache.

Once poisoned, any user relying on that recursive resolver who attempts to visit bank.com will be silently redirected to the attacker's phishing server. The user's browser will display the correct URL, but the underlying IP is compromised, making detection exceedingly difficult for the average user.

DNS Hijacking

While Cache Poisoning attacks the resolver, DNS Hijacking targets the domain's authoritative records directly. This is typically achieved not by exploiting the DNS protocol itself, but by compromising the administrative accounts that manage the domain.

Attackers employ techniques like spear-phishing, credential stuffing, or exploiting vulnerabilities in a domain registrar's web portal to gain unauthorized access to a victim's domain management account. Once inside, they alter the DNS A records (which map the domain to an IP) or the NS records (which specify the Authoritative Name Servers).

By changing the A record, the attacker instantly reroutes all global traffic destined for the legitimate site to an infrastructure they control. This was famously executed by the Syrian Electronic Army, who hijacked the DNS records of major media outlets like The New York Times and Twitter, redirecting their millions of visitors to propaganda pages.

DNS Rebinding Attacks

DNS Rebinding is a highly technical attack designed to bypass the Same-Origin Policy (SOP) implemented by web browsers. The SOP is a fundamental security mechanism that prevents a malicious script running on attacker.com from accessing data on internal-network.local.

In a rebinding attack, the adversary registers a domain (malicious.com) and configures a custom DNS server with a very short Time-To-Live (TTL), perhaps just a few seconds.

1. The victim visits malicious.com, and the DNS resolves to the attacker's web server IP.
2. The browser loads malicious JavaScript.
3. The DNS record immediately expires due to the short TTL.
4. The malicious script then requests data from malicious.com again.
5. This time, the attacker's DNS server responds with an IP address belonging to a device on the victim's internal network (e.g., 192.168.1.1, their home router, or an internal corporate server).
6. Because the domain name (malicious.com) hasn't changed, the browser's SOP allows the script to interact with the internal IP, enabling the attacker to exfiltrate data or exploit vulnerabilities on internal devices that are otherwise shielded from the internet.

DNS Amplification (DDoS)

DNS is frequently weaponized to conduct massive Distributed Denial of Service (DDoS) attacks. Because DNS operates primarily over UDP (a connectionless protocol), it is trivial for an attacker to spoof their source IP address.

In a DNS Amplification attack, a botnet sends millions of DNS queries to publicly accessible, open DNS resolvers. Crucially, they spoof the source IP of these queries to be the IP address of the target victim. They also request particularly large DNS records (such as asking for all DNSSEC records or the ANY record).

The open resolvers process the queries and send the massive responses (which can be 50 to 100 times larger than the initial query) to the spoofed source IP—the victim. The victim's network is suddenly overwhelmed by a colossal flood of unsolicited DNS responses, saturating their bandwidth and causing a complete denial of service.

The consequences of a successful DNS attack are multifaceted and can be devastating to an organization.

• Mass Credential Compromise: Cache poisoning and hijacking lead directly to credential harvesting. Users logging into what they believe is their corporate portal or bank are actually handing their credentials directly to attackers, bypassing Multi-Factor Authentication (MFA) if the attacker uses adversary-in-the-middle (AiTM) proxy techniques.
• Malware Distribution and C2: Attackers use hijacked domains to host malware payloads. Because the domain itself has a positive reputation, network security appliances may not flag the downloads. Furthermore, advanced malware uses DNS for Command and Control (C2) communication (DNS Tunneling), encapsulating malicious instructions within seemingly benign DNS queries to bypass egress firewalls.
• Reputational and Financial Damage: When a company's domain is hijacked, the loss of customer trust is profound. E-commerce sites lose revenue for every minute of downtime or redirection, and the regulatory fines associated with data breaches resulting from hijacked portals can be substantial.

Defending against DNS Attacks requires a comprehensive strategy that addresses vulnerabilities at the registrar level, the resolver level, and within the corporate network.

Implementing DNSSEC (DNS Security Extensions)

DNSSEC is the definitive cryptographic solution to DNS Cache Poisoning. It adds digital signatures to DNS records at the Authoritative Name Server level. When a recursive resolver queries a DNSSEC-enabled domain, it retrieves both the IP address and the cryptographic signature. The resolver then validates the signature using the domain's public key. If the signature is invalid or missing, the resolver knows the response has been forged and drops it. While DNSSEC does not encrypt the query (it remains visible to eavesdroppers), it guarantees the authenticity and integrity of the response.

Securing Domain Registrar Accounts

To prevent DNS Hijacking, organizations must treat their domain registrar accounts as critical infrastructure.

• Mandatory MFA: Enforce robust Multi-Factor Authentication (preferably hardware security keys like YubiKeys) for all accounts with access to DNS management.
• Registry Lock: Utilize Registry Lock services offered by TLD registries. This requires out-of-band, manual verification (often a phone call to authorized personnel) before any changes to NS records or domain ownership can be processed, effectively stopping automated hijacking attempts.

Restricting and Monitoring Internal DNS

Organizations must gain visibility into their DNS traffic.

• Disable Open Resolvers: Ensure that internal DNS servers do not act as open resolvers for the external internet to prevent them from being used in Amplification attacks.
• DNS Filtering and Sinkholing: Implement enterprise DNS filtering solutions (like Cisco Umbrella or Cloudflare Gateway) that cross-reference requested domains against threat intelligence feeds. If an endpoint attempts to resolve a known malicious domain or a DGA (Domain Generation Algorithm) domain associated with malware C2, the DNS server should sinkhole the request, returning a null IP and alerting the SOC.
• Monitor for Anomalies: Security Information and Event Management (SIEM) systems should monitor DNS logs for unusually high volumes of queries from specific endpoints, queries for exceptionally long domain names (indicative of DNS tunneling), or rapid changes in DNS resolution patterns.