What Is DNS Hijacking? [+ Examples & Protection Tips]

DNS hijacking is a type of attack where attackers manipulate DNS responses to redirect users to unauthorized or malicious destinations. This can involve compromising DNS servers, altering domain records, or intercepting DNS traffic.

The technique enables credential theft, malware distribution, and impersonation of legitimate services.

9 min. read
Listen

 

How does a DNS hijacking attack work?

DNS hijacking attacks manipulate how domain names resolve to IP addresses. 

Basically, the attacker interferes with DNS responses to reroute users to a site under their control—and the user often doesn’t notice the redirection.

Architecture diagram is divided vertically into two labeled sections: 'Normal DNS resolution' on the left in blue and 'DNS hijacking' on the right in red. In the 'Normal DNS resolution' section, a client labeled 'Example.com' sends two blue arrows labeled 1 and 2 to a DNS server. The DNS server then communicates with another DNS server labeled 'Example.com' using arrows labeled 3 and 4. In the 'DNS hijacking' section, a client labeled 'Example.com' sends two red arrows labeled 1 and 2 to a 'Hijacked DNS server.' That hijacked server then routes the request to a 'Malicious server' using red arrows labeled 3 and 4, bypassing the legitimate DNS server shown beneath it. The structure visually contrasts legitimate DNS resolution with a hijacked resolution that redirects traffic to a malicious server.

Here's how a typical DNS hijacking attack works, step by step:

  1. The attacker identifies a target

    This could be a public website, internal domain, or DNS provider account. The attacker looks for weak points in the DNS infrastructure or admin access.

  2. The attacker gains access

    They might steal credentials, exploit vulnerabilities, or use social engineering to compromise DNS servers, registrar accounts, or local routers.

  3. The attacker modifies DNS settings

    They change DNS records or inject forged responses to redirect traffic from the legitimate IP address to a maliciousone.

  4. The user submits a DNS query

    The user tries to visit a domain as usual—typing the address in a browser or using an app that initiates a connection.

  5. The query resolves to the attacker's IP

    Instead of reaching the real server, the DNS response points to a server controlled by the attacker.

  6. The user reaches a fake or malicious destination

    That could be a phishing site, malware host, or an impersonation of the original service. Everything appears normal unless the user checks the certificate or inspects the site closely.

In other cases, the attacker doesn't change official DNS records. Instead, they intercept queries in transit and respond with spoofed data. 

If the DNS traffic isn't encrypted or verified, the forged response is accepted. The user gets redirected silently, even though nothing changed in the DNS configuration itself.

 

What are the different types of DNS hijacking attacks?

Diagram titled 'Types of DNS hijacking attacks' and shows four labeled blocks arranged in a horizontal sequence from left to right. Each block is enclosed in a dashed border and connected to the next with a small dotted line. The first block is labeled '1. Local DNS hijack' and is shaded in light red. The second block is labeled '2. Router DNS hijack' and is a slightly darker red. The third block is labeled '3. Meddler-in-the-middle attack' and is a bright red. The fourth block is labeled '4. Rogue DNS server' and is the darkest red of the group. The blocks sit on a light gray background that spans the lower half of the image.

There are several distinct techniques attackers use to carry out DNS hijacking. Each one targets a different part of the DNS resolution process—from individual devices to network infrastructure. 

Understanding how these attack types differ helps clarify the scale, risk, and response required for each.

Let’s take a closer look:

Local DNS hijack

In a local DNS hijack, the attacker compromises a specific device. This often involves installing malware that modifies DNS settings on the host system. Once the local resolver is changed, all DNS queries from that device can be redirected.

Diagram titled 'Local DNS hijack' shows a sequence where a device queries a recursive DNS resolver. The resolver checks the local device’s configuration and returns control to the device. However, the device has a corrupted local host file, which overrides normal DNS resolution. As a result, instead of forwarding the request to a legitimate DNS server, the device redirects the query to a fake website. The intended path to the legitimate DNS server is shown as inactive with a dotted line ending in an 'X,' indicating it is bypassed due to the local corruption.

Here’s why that’s important:

Even if the organization’s upstream DNS infrastructure remains secure, the infected device will still receive malicious responses. The attacker’s DNS server can now return forged IP addresses for any domain the user attempts to reach. The user ends up on a spoofed site without realizing anything has changed.

Example: MyEtherWallet attack (2018)

In 2018, attackers used malware to alter local DNS settings on users' machines and redirect traffic from MyEtherWallet to a fake website.

 

Architecture diagram titled 'BGP & DNS hijacks targeting myetherwallet.com' shows how users are redirected to a fake website through a BGP hijack and DNS manipulation. On the left, a group of users issues a DNS query asking, 'What is myetherwallet.com?' The query is sent to a recursive DNS server, which typically would contact the root and .com servers and then forward the query to the legitimate authoritative DNS server shown on the far right in green. However, a red dotted line labeled 'BGP hijack' redirects traffic to an imposter authoritative DNS server in red instead. This server falsely resolves 'myetherwallet.com' to an IP in eastern Ukraine. The recursive DNS server caches this incorrect information and returns it to the users, who are then directed to an imposter website shown at the bottom left. All malicious elements in the diagram—including the recursive DNS server, imposter authoritative DNS server, and imposter website—are shaded in red. The legitimate authoritative DNS server is the only component in green. Arrows indicate the flow of the DNS query and resolution path.

The spoofed site prompted users to enter private wallet keys, which the attackers then used to steal their cryptocurrency. This local DNS hijack resulted in over $150,000 in reported losses.

Router DNS hijack

Router DNS hijacks target the network gateway instead of individual devices. Attackers scan for routers with default credentials or known firmware vulnerabilities. Once they gain access, they update the router’s DNS configuration.

Architecture diagram titled 'Local DNS hijack' shows a sequence where a device queries a recursive DNS resolver. The resolver checks the local device’s configuration and returns control to the device. However, the device has a corrupted local host file, which overrides normal DNS resolution. As a result, instead of forwarding the request to a legitimate DNS server, the device redirects the query to a fake website. The intended path to the legitimate DNS server is shown as inactive with a dotted line ending in an 'X,' indicating it is bypassed due to the local corruption.

The impact is broader. Every device on the network that uses the router’s DNS settings will be redirected. That makes it especially dangerous in home or small office environments where users rarely check router settings. In other words: one compromised router can hijack DNS for an entire network.

Example: Unpatched D-Link Routers Targeted (2019)

In 2019, attackers exploited vulnerabilities in unpatched D-Link routers, altering their DNS settings to redirect users to malicious websites.

Image showing the web interface of a D-Link DSL-2640B router displaying device information under the 'Status' tab. The screen includes sections for device info, internet setup, wireless LAN, and LAN configuration. In the 'INTERNET SETUP' section, the 'Primary DNS Server' and 'Secondary DNS Server' fields are highlighted in red and display unauthorized IP addresses: 69.65.41.3 and 195.22.26.248. These DNS values appear beneath the authentication details and above the connection status. To the right of the router interface, a caption reads: 'Screenshot from a compromised D-Link DSL-2640B router showing unauthorized DNS settings.' The router interface uses a black, grey, and orange color scheme, with navigation tabs labeled Setup, Advanced, Maintenance, Status, and Help.

The compromised routers pointed DNS requests to rogue servers hosted by OVH Canada and later to servers in Russia, affecting numerous users.

Meddler-in-the-middle attacks

These attacks exploit the space between a user’s query and the DNS server’s response. So, the attacker sits in the communication path and injects a forged DNS reply before the legitimate server can respond.

Architecture diagram illustrating a meddler-in-the-middle (MITM) attack during DNS resolution. A client or user attempts to access example.com by sending a DNS query to a server. The server then queries a DNS server for the IP address linked to example.com. Instead of receiving the legitimate response, the attacker intercepts the request and sends a forged DNS response pointing to IP address 203.0.113.77. This redirects the client to a spoofed site labeled 'Man-in-the-middle,' which mimics www.example.com using the attacker’s IP address. Meanwhile, the legitimate DNS server’s response, which points to the real site https://example.com at IP address 198.51.100.42, is never received by the client. The flow shows two possible paths, one ending with the attacker and the other with the legitimate website, highlighting how the false DNS response overrides the real one.

That forged response is accepted if the client doesn’t validate it. As a result, the user is redirected to a site controlled by the attacker. This attack is more likely to succeed on networks that lack DNS encryption or DNSSEC validation. It can also happen without the attacker needing access to any endpoint or server.

Example: TrickBot's shaDll Module (2023)

In 2023, cybersecurity researchers identified a TrickBot module named "shaDll" that facilitated MitM attacks.

Module name SHA256 hash
shadDll32
3f9c1b749e6d1e88aa45e8a274c1b5c1a213e0d46e672a5c029c5e79974db7f3
shadDll64
e8743c1fc51d2e49f79a1a3a4c7d99e713b217de08b5d2cd2f1d3f6c6436a8c4

This module installed illegitimate SSL certificates on infected computers, allowing attackers to intercept and manipulate web traffic. By redirecting web activity and injecting malicious code, the attackers could capture sensitive information from unsuspecting users.

Rogue DNS server

A rogue DNS server is a legitimate-appearing server that has been compromised or intentionally deployed by the attacker. When a user query reaches that server, it returns forged IP addresses for legitimate domains.

Architecture diagram titled 'Rogue DNS server' illustrates a DNS resolution flow involving a user, a recursive DNS resolver, and a compromised authoritative DNS server. The user sends a query to the recursive DNS resolver, which then queries the authoritative DNS server. The authoritative server has been compromised, as indicated by an icon labeled 'Altered DNS record' above it. The server responds with a forged DNS record, sending an altered response that resolves to a malicious IP. The recursive resolver relays this malicious response back to the user. A dotted line between the resolver and the user is labeled 'Altered response to malicious IP.'

This technique works well when attackers can trick users or systems into using the rogue server. That could happen via malware, misconfiguration, or even upstream compromise of a public resolver. Once the rogue server is in place, the attacker controls the resolution process and can redirect as needed.

Example: DNS Predators Hijack Domains (2024)

In 2024, researchers uncovered that approximately 70,000 domains had been hijacked through compromised DNS servers.

A timeline diagram shows the sequence of events for two domains hijacked in 2024 during a DNS record manipulation campaign. The top half is labeled 'TDS: aphecalenterprises[.]com' and lists four events. On March 7, 2019, La Container Inc. registers the domain with TierraNet. On December 6, 2021, La Container changes the domain registrant organization name to Aphecal Enterprises. On June 26, 2022, TierraNet transfers the domain to GoDaddy, though nameservers remain with TierraNet. On October 15, 2024, an entity named Horrid Hawk hijacks the domain and changes A records to malicious M247 IP addresses 38[.]180[.]226[.]70. The bottom half is labeled 'Landing: agbizwichita[.]prg' and also lists four events. On July 28, 2008, the Agri-Business Council of Wichita purchases the domain. On July 15, 2015, an unknown user creates a domain. On October 1, 2021, another unknown user registers the domain with GoDaddy and uses Linode DNS services. On October 17, 2024, Horrid Hawk hijacks the domain and changes A records to malicious DigitalOcean IP addresses 167[.]71[.]65[.]159. A caption at the bottom reads: 'Timeline of two domains hijacked in 2024 as part of a large-scale DNS record manipulation campaign.'

Attackers altered DNS records to redirect legitimate traffic to malicious sites, exploiting vulnerabilities in domain management practices. This large-scale hijacking highlighted the critical need for robust DNS security measures.

 

How to protect against DNS hijacking

The diagram titled 'How to protect against DNS hijacking' is divided into three color-coded sections: mitigation in red, detection in light blue, and prevention in dark teal. Under the red 'Mitigation' section, four bullet points branch out listing: identify and restore affected DNS settings, flush DNS caches across all layers, investigate the cause of compromise, and communicate with stakeholders. The light blue 'Detection' section lists five items: monitor for unusual DNS behavior, analyze DNS records at scale, use automated detection systems, apply machine learning for scoring, and look for endpoint-level indicators. The dark teal 'Prevention' section includes: secure DNS management systems, enable DNS-level protections, harden DNS infrastructure and endpoints, and audit for misconfigurations. Each category is displayed with its associated tasks branching out horizontally from the central vertical flow of the diagram. The Palo Alto Networks logo appears in the upper left corner.

DNS hijacking isn't always easy to spot—and it's even harder to recover from once in motion. 

Which means the best defense is a layered approach that spans detection, mitigation, and prevention. 

Each plays a different role:

  • Detection focuses on spotting signs of tampering.

  • Mitigation addresses what to do if a hijack is already underway. 

  • And prevention aims to block attacks before they start. 

Let's break each one down.

Detection

Detecting DNS hijacking requires a mix of behavioral monitoring, network analysis, and system-level audits.

Here's how to break it down:

  1. Monitor for unusual DNS behavior

    Look for signs that DNS resolution isn't functioning as expected, such as:

    • Redirects to unfamiliar domains

    • SSL certificate mismatches on trusted sites

    • Browser security warnings despite no recent changes

Tip:
Cross-reference browser warning events with DNS logs. If multiple endpoints show cert mismatches for the same domain, it may signal tampering upstream—not isolated client issues.
  1. Analyze DNS records at scale

    At the network level, inspect DNS records for inconsistencies.

    • Watch for new A or NS records pointing to unusual IP addresses
    • Check for geographic or hosting shifts that don’t align with past patterns
    • Use passive DNS (pDNS) to see how domains have resolved over time
Tip:
Tag and track high-risk domains (e.g., those tied to financial apps or sensitive internal portals) for more aggressive change monitoring and alerting.
  1. Use automated detection systems

    Well-tuned systems can catch anomalies before they escalate.

    • Filter out known-good domains to reduce noise
    • Flag records with unexpected changes, like long-established domains suddenly pointing to obscure IPs
    • Correlate findings with WHOIS data and registrar updates
Tip:
Add change detection rules that monitor TTL values. A sudden drop in TTL on a previously stable record may suggest an attacker trying to force faster propagation of forged entries.
  1. Apply machine learning for scoring

    For large DNS datasets, models can help prioritize alerts.

    • Analyze patterns across dozens of features, such as hosting churn or domain age
    • Assign a risk score to each suspicious record
    • Reduce false positives and surface high-likelihood threats for human review
Tip:
Weight scoring models to favor anomalies in critical domains over low-risk ones. It helps prevent alert fatigue and ensures high-value assets get more scrutiny.
  1. Look for endpoint-level indicators

    In smaller environments, detection often happens closer to the user.

    • Notice slow-loading pages, pop-ups, or unfamiliar redirects
    • Inspect local DNS settings for unauthorized changes
    • Review resolver logs and DNS query paths regularly
Tip:
Automate periodic collection of DNS configuration from endpoints and compare it against known-good baselines. This helps flag silent local changes made by malware.

A teal rectangular call-to-action banner features a circular white line icon on the left side, depicting a network server with a magnifying glass and a leaf symbol above it. To the right of the icon, white bold text reads: 'Not sure if your DNS is already compromised? Unit 42 offers compromise assessments to help identify silent exposures.' Below this text is a white-outlined oval button with the label 'Learn more' centered inside. The banner uses a clean, minimal layout with evenly spaced elements.

Mitigation

Mitigating DNS hijacking means taking quick, focused action to stop the redirection and limit the damage.

Here’s how to approach it step by step:

  1. Identify and restore affected DNS settings

    Start by pinpointing where the redirection occurred:

    • Check registrar accounts, DNS provider consoles, and router configuration
    • Restore the correct DNS records for all impacted domains
    • Temporarily redirect traffic away from attacker-controlled infrastructure if needed
  2. Flush DNS caches across all layers

    Remember: Correcting DNS settings isn’t enough on its own. Hijacked entries may remain in local and upstream caches.

    Clear caches on browsers, local resolvers, recursive resolvers, and CDNs. Otherwise, users may still be routed to malicious destinations.

Tip:
Don’t forget application-level caches. Some browsers or apps cache DNS separately from the OS or resolver. Validate behavior in critical apps after the flush.
  1. Investigate the cause of compromise

    Understanding how the attack happened is critical for closing gaps.

    • Review registrar access logs and audit recent DNS changes
    • Check endpoints and routers for signs of malware or credential theft
    • If an account was compromised, reset credentials and enforce MFA and IP allowlisting
Tip:
Correlate login times from registrar activity logs with threat intel feeds. If access came from IPs tied to known attacker infrastructure, it strengthens your attribution and remediation path.
  1. Communicate with stakeholders

    If users interact with a spoofed site, fast communication helps reduce further impact.

    • Notify users, partners, or customers who may have been exposed
    • Coordinate with internal security and legal teams
    • In some cases, report the incident to DNS authorities or law enforcement

Prevention

Preventing DNS hijacking means reducing exposure across the systems and services that manage DNS.

Here’s how to build a strong defense:

  1. Secure DNS management systems

    Start by locking down the accounts and infrastructure that control DNS:

    • Use strong, regularly rotated passwords
    • Enable multi-factor authentication on registrar, provider, and router accounts
    • Limit access to only trusted personnel and systems
Tip:
Use a dedicated account with no email access or web browsing capability for managing DNS records. This reduces phishing exposure on critical admin credentials.
  1. Enable DNS-level protections

    Add safeguards that validate DNS activity:

    • Turn on DNSSEC to authenticate DNS responses and reduce spoofing
    • Use client lock features at your registrar to prevent unauthorized changes
  2. Harden DNS infrastructure and endpoints

    Stop attackers from gaining a foothold:

    • Separate authoritative name servers from resolvers
    • Patch known vulnerabilities in DNS software and router firmware
    • Restrict zone transfers to trusted hosts
    • Scan endpoints regularly for malware
  3. Audit for misconfigurations

    Mismanaged records create easy openings.

    • Remove stale, incorrect, or expired DNS entries
    • Review DNS zones periodically to ensure everything is current
    • Clean up unused records to reduce attack surface
Tip:
Mark unused DNS records as "quarantined" before deletion. If nothing breaks after a predefined period (e.g., 30 days), you can safely remove them—without risk.

The CTA banner features a teal background with bold white text on the right reading, 'Validate your readiness against DNS hijacking. Explore the Unit 42 Threat Cyber Risk Assessment.' Below the text is a white-outlined button labeled 'Learn more.' On the left is a circular icon showing a checklist above a stylized shield-and-leaf symbol.

 

What are the differences between DNS hijacking, DNS spoofing, and DNS cache poisoning?

Scroll the table to read further.
Attack type Goal Common methods Target Detection difficulity Mitigation approach Prevention approach
DNS hijacking Redirect users to a malicious site by taking over or modifying DNS settings Router compromise, DNS registrar account takeover, malware DNS settings at the user, router, or domain registrar level Moderate to high Restore DNS settings, flush caches, secure access points Use MFA, strong passwords, DNSSEC, regular audits
DNS spoofing Alter DNS responses to mislead users without changing DNS settings Man-in-the-middle attacks, forged DNS responses, redirection DNS responses in transit or systems interpreting them Moderate Stop redirection, block malicious IPs or domains Use encrypted DNS, monitor for spoofed responses
DNS cache poisoning Insert forged DNS records into a resolver's cache to mislead multiple users Flooding resolvers with fake responses, query ID prediction Caching resolvers that serve DNS responses to many users High, especially without DNSSEC Flush cache, use DNSSEC, patch vulnerabilities Deploy DNSSEC, use randomized query parameters, patch resolvers

These terms are often used interchangeably—but they don’t mean the same thing. Each one describes a different technique for redirecting users to the wrong destination by manipulating the DNS resolution process. Knowing the differences can help teams understand the scope of an attack and respond appropriately.

DNS hijacking is the broadest category. It refers to any situation where DNS settings or behavior are maliciously altered to reroute traffic. That could mean changing router settings, compromising a DNS registrar account, or redirecting queries at the resolver level. The goal is to send users to an attacker-controlled destination while everything else appears normal.

DNS spoofing is a specific tactic used within hijacking. In spoofing attacks, the attacker forges a DNS response to trick a client or server into accepting a fake IP address for a domain. It’s often used in meddler-in-the-middle scenarios or captive networks to intercept traffic. Spoofing doesn’t necessarily require persistent access—it just needs the fake response to arrive before the real one.

Architecture diagram titled 'DNS spoofing' shows a user attempting to access a website through a DNS server. Step 1 indicates the attacker injecting a fake DNS entry into the DNS server. Step 2 shows the user issuing a request to the real website, which is intercepted by the DNS server. Step 3 shows the request resolving to a fake website, represented by a red icon with a warning symbol. The legitimate path to the real website is shown but not followed, as the DNS server redirects the user based on the attacker’s injected entry.

DNS cache poisoning targets recursive resolvers by injecting false DNS records into their cache. Once poisoned, the resolver returns the attacker’s response to every client until the entry expires or is cleared. This approach can impact many users at once and is especially dangerous when DNSSEC is not in use. Cache poisoning is one way to achieve DNS spoofing, but it’s not the only method.

Architecture diagram titled 'DNS cache poisoning' illustrates a four-step sequence. In step 1, a user sends a DNS request for a domain such as example.com to their local DNS resolver. In step 2, because the server lacks a cached record, it forwards the request to a root authoritative DNS server. In step 3, before the legitimate response arrives, an attacker inserts a forged DNS entry into the local server. In step 4, the local DNS server stores the forged record and resolves the user’s request to the attacker-controlled IP address, which leads to a fake website. The real website remains unused.

In other words:

DNS hijacking describes the overall compromise. DNS spoofing is how fake answers get delivered. And cache poisoning is one way those fake answers get stored and spread.

The CTA banner has a teal background with bold white text on the right that reads, 'Stop new DNS-layer attacks today. Get a 90-day DNS Security free trial.' Beneath the text is a white-outlined button labeled 'Start your free trial.' On the left is a circular icon showing a network diagram with nodes connected around a central padlock.

 

DNS hijacking FAQs

DNS hijacking redirects users to malicious destinations by altering DNS resolution. DNS tunneling uses DNS requests to exfiltrate data or maintain command-and-control channels by embedding payloads in DNS queries. Hijacking targets resolution. DNS tunneling abuses DNS as a covert communication method.
A DNS attack exploits weaknesses in the Domain Name System to disrupt resolution, redirect traffic, exfiltrate data, or impersonate domains. Techniques include DNS hijacking, spoofing, cache poisoning, and tunneling.
In 2024, attackers compromised DNS servers managing ~70,000 domains, altering DNS records to redirect traffic to malicious sites. This large-scale hijacking exploited poor domain management and outdated DNS protections.
In 2018, attackers used malware to alter local DNS settings and redirect MyEtherWallet users to a fake site. They harvested private keys and stole over $150,000 in cryptocurrency.
Look for unexpected redirects, browser warnings, mismatched SSL certificates, or DNS settings pointing to unknown servers. Sudden slowness, pop-ups, or login prompts on trusted sites can also signal hijacking.
Detecting DNS tunnels involves inspecting DNS traffic for anomalies like unusual query lengths, consistent subdomain patterns, or large volumes of outbound requests. Machine learning and behavioral baselines help identify covert channels.
Common types include DNS hijacking, spoofing, cache poisoning, tunneling, typosquatting, and domain takeovers. Each abuses DNS to redirect traffic, steal data, or disrupt services through manipulation or misconfiguration.