DNS Hijacking

How Does DNS Hijacking Work?

Every visit to a website starts with a DNS lookup. Your device asks a resolver, which is usually run by your company, your internet provider or a public service. The resolver follows the delegation from the top-level domain registry to the domain’s own name servers and passes their answer back.

DNS hijacking means someone changes one link in that chain. CISA describes the account-based form in one line: with stolen credentials, an attacker can “modify the location to which an organization’s domain name resources resolve”. The user still types or clicks the correct name. Only the address behind it is different.

The answer can be changed in five places. The higher up the chain the change sits, the more people it reaches.

The resolver row has a quieter variant. ICANN’s Security and Stability Advisory Committee described it in 2008 as DNS response modification. When a name does not exist, for example after a typing error, the authoritative server answers with a “name error”.

A third party running a resolver can silently change that answer. The new one says the name exists and points to an address the operator chose, often an ad or search page. SSAC lists “NXDomain hijacking” among its labels. It notes that any resolver on the path could modify the answers it forwards.

This is hijacking by the operator, not by an attacker. It can still send users to a host the domain owner does not control.

The first three rows change what one group of users sees. The last two change the domain itself. Talos notes that an NS change can redirect anyone in the world who looks up the domain. That is why CISA, Talos and Mandiant focus on registrar and DNS host accounts.

What Do Attackers Gain From a Hijacked Domain?

Most attackers do not want your website. They want what passes through your domain name, and the cases on this page show several payoffs.

• Logins. The attacker’s server sits in front of the real mail or VPN login, keeps the password and passes the user on. Talos says the only sign for victims was a brief lag after they entered their details.
• Mail. CISA lists A, MX and NS records as the ones changed. A new MX record sends incoming mail to the attacker first.
• Malware delivery. Software that fetches settings or updates over plain HTTP trusts whatever address DNS returns. In 2026 this let attackers push an implant through a Sogou Input Method helper, as our analysis of the Sogou Input Method case explains.
• Cloud accounts. MITRE ATT&CK notes that DNS control can let an attacker prove ownership of a domain to a SaaS service and create a new administrative account.

HTTPS does not stop this. Because the attacker sets the DNS records, CISA warns, they can also obtain valid encryption certificates for the organization’s domain names, and users “receive no error warnings”.

Mandiant saw attackers run certbot to get Let’s Encrypt certificates for hijacked mail hosts. The certificate is real; only the request was not yours. Our certificate authority entry explains how such checks work.

The result is an adversary-in-the-middle position on your own domain name. Users see the right address and a valid padlock, and still talk to the attacker.

How Is DNS Hijacking Different From DNS Spoofing, Domain Hijacking and Subdomain Takeover?

These terms overlap, and many pages use them loosely. Two questions separate them: what did the attacker change, and who controls the domain afterwards?

CERT/CC describes cache poisoning as introducing “forged DNS information into the cache of a caching nameserver”. ICANN’s Security and Stability Advisory Committee (SSAC) defines domain name hijacking as “the unauthorized transfer or wrongful taking of control of a domain name”. A lookalike domain never touches your DNS at all.

Forgotten records that point at deleted resources are the usual route to a takeover of one name. Our guide to subdomain takeover and dangling DNS records shows that chain step by step with DNS output from a lab run. DNS is also abused as a hidden channel for malware traffic through tunneling and fast flux, which redirects nobody; our DNS abuse analysis covers those techniques.

What Do Real DNS Hijacking Cases Look Like?

2011, DNSChanger (devices). In November 2011 US prosecutors announced Operation Ghost Click and the arrest of a ring of seven people who allegedly infected millions of computers with DNSChanger malware. The malware sent DNS lookups to rogue servers.

To keep victims online after the arrests, the FBI replaced those servers with clean ones. CISA then urged owners to clean their computers before the replacement servers were switched off on 9 July 2012.

2017 to 2019, registrars and DNS hosts. Mandiant reported a wave of DNS hijacking against government, telecom and internet infrastructure organizations across the Middle East and North Africa, Europe and North America.

It saw three methods. Attackers changed A records in a DNS provider’s panel with stolen credentials. They changed NS records through a compromised registrar or country-code registry. They also ran DNS servers of their own that lied only about selected names.

Cisco Talos tracked a campaign it named Sea Turtle and counted at least 40 compromised organizations in 13 countries. Its targets included registrars, telecom companies and internet providers, used as a way into the final victims. The hijacks lasted from a couple of minutes to a couple of days. In some cases the attackers set the record’s time to live (TTL) to one second, likely so the change would not linger in caches.

On 22 January 2019 CISA issued Emergency Directive 19-01. It ordered US federal agencies to audit their DNS records, change DNS account passwords and add multi-factor authentication within 10 business days, and to monitor Certificate Transparency logs. CISA has since closed the directive. Its guide for other organizations repeats the same four actions, and they still make a good short checklist.

2024 to 2026, home and office routers. On 7 April 2026 the US Justice Department announced a court-authorized operation against a network of hijacked small office and home office routers. It attributes the activity to Russia’s GRU Military Unit 26165, also known as APT28. Since at least 2024, the unit had stolen credentials for thousands of TP-Link routers and pointed their DNS settings to its own resolvers.

For selected targets, those resolvers returned fake records for services such as Microsoft Outlook Web Access. The actors then collected passwords, authentication tokens and emails from devices behind the routers.

2026, a software update channel. On 4 November 2026 ESET reported that a China-aligned group delivered the DarkVigil implant through Sogou Input Method for Windows. A helper program fetched its configuration over plain HTTP, so whoever answered the DNS lookup chose the files it downloaded.

ESET does not know where the DNS manipulation happens. It lists modified router settings, a router implant or interception at the internet provider as possible routes.

Why Are Registrar and DNS Host Accounts the Weak Point?

The registrar account, the DNS provider’s panel and any hosting panel that edits DNS hold the keys to the whole domain. CISA found that different parts of an organization often own different domains and records, so “many organizations lack central visibility” into them. For US federal agencies, gaining that visibility was “the most labor intensive and challenging” part of the directive.

One registrar login also tends to control many domains. SSAC warns that an attacker who takes over such an account can change DNS for every domain in it. If the contact addresses sit on those same domains, the attacker can also block the registrar’s warning emails.

These logins are traded. For the Cybercrime Report 2026 initial access chapter, we read 200 priced texts from posts labelled as access sales. They come from Brandefense Blackhole, our cybercrime database, between 1 January and 27 October 2026.

One January post offered 1,000 cPanel logins, described as valid, for an advertised $30 for the lot. A February post asked $100 for a single cPanel login on a government-domain site.

Neither the prices nor any sale were verified, as our analysis of web shell, cPanel and RDP offers explains. The risk is plain all the same. The cPanel Zone Editor creates, edits and deletes DNS zone records unless the host has switched it off. When a domain’s DNS is hosted on that server, a stolen hosting login can work as a DNS login.

How Do You Check Whether Your DNS Has Been Hijacked?

Work from the outside in, in the order CISA gave: the delegation at the registry, then the records, then the certificates. The commands below are standard dig, whois and curl queries. We ran them on 10 November 2026 against example.com, a name IANA reserves for documentation, and trimmed the output.

1. Check the delegation at the registry. Ask one of the .com registry’s own name servers which name servers it lists for the domain. A name server you do not run or pay for is the strongest sign of an NS change, the method Talos saw in Sea Turtle. CISA asked agencies to check NS records first.

   $ dig +norecurse NS example.com @a.gtld-servers.net
   ;; AUTHORITY SECTION:
   example.com.   172800  IN  NS  hera.ns.cloudflare.com.
   example.com.   172800  IN  NS  elliott.ns.cloudflare.com.

2. Compare answers from different resolvers. Ask your own resolver and two public ones about the hosts that matter most: the website, mail, VPN and single sign-on. Different answers are a lead to check, not proof. An address in a network you have never used is worth a call to whoever runs that service.

   $ dig +short A www.example.com @1.1.1.1
   104.20.23.154
   172.66.147.243
   $ dig +short A www.example.com @8.8.8.8
   104.20.23.154
   172.66.147.243

3. Read the lock status. The registry’s whois lists the domain’s status codes. Here the three registrar locks are set, but no registry lock. The table further down explains each code.

   $ whois -h whois.verisign-grs.com example.com | grep -i status
   Domain Status: clientDeleteProhibited
   Domain Status: clientTransferProhibited
   Domain Status: clientUpdateProhibited

4. Check DNSSEC. A DS record at the parent means the zone is signed. The ad flag means the resolver says it validated the signatures. The DNSSEC standard RFC 4033 calls that flag a hint, to rely on only when you trust the resolver and the path to it.

   $ dig DS example.com +short @1.1.1.1
   2371 13 2 C988EC423E38...C83D245A
   $ dig +dnssec example.com A @1.1.1.1 | grep flags
   ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

5. Search Certificate Transparency logs for certificates nobody ordered. crt.sh returned 12 log entries for unexpired certificates naming example.com, from several issuers. Two stand out: a 2021 certificate from a test authority and one whose issuer crt.sh could not find. On a documentation domain that is harmless noise. On your own domain, each entry like that is a question for whoever manages certificates. Talos saw attackers take a certificate from a different authority than the one the victim used.

   $ curl -s "https://crt.sh/?q=example.com&output=json&exclude=expired" 
       | jq -r '.[] | .not_before[0:10] + "  " + .issuer_name' | sort -u
   2021-08-31  ... CN=AS207960 Test CA
   2023-01-27  Issuer Not Found
   ...
   2025-11-20  C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA OV R36
   2026-09-24  C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA DV E36
   2026-09-26  C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3

6. Check devices and routers. See which resolvers a computer really uses: Get-DnsClientServerAddress on Windows, resolvectl status on Linux with systemd-resolved, scutil --dns on macOS. Compare them with the resolvers your network should hand out. Port 53 traffic to any other resolver can mean malware or a changed setting moved the device. On routers, follow the Justice Department’s 2026 advice: verify the resolvers in the settings, install current firmware, replace end-of-life models and close remote management.
7. Look back with passive DNS. Talos advises watching passive DNS records for your domains. CISA adds that history shows whether a hijack happened, but does not stop a current one. Look for short-lived changes and a TTL that suddenly drops to seconds.

Our dnstwist and crt.sh brand watch walkthrough shows how to automate the certificate search for your own names. The signals below are the ones the cases on this page left behind.

How Do You Prevent DNS Hijacking?

Protect the accounts first, then make every change slow and visible. A practical order for most organizations:

1. Put registry lock on the domains that carry mail, VPN, single sign-on and the main website. Talos recommends it because the registrar must then give the registry an out-of-band confirmation before any change. SSAC calls it a second level of security on top of registrar locks.
2. Use phishing-resistant multi-factor authentication on every account that can change DNS: registrar, DNS provider, hosting panels and the systems that manage your own name servers. CISA names security keys and PIV cards and says text message codes are not recommended. Where a provider offers no MFA, CISA’s advice is to move to one that does.
3. Keep one inventory of domains, registrars, DNS hosts and who holds each login. SSAC suggests splitting important domains across separate accounts and using contact addresses on a different domain, so one stolen account cannot silence the warnings.
4. Turn every registrar notice about name servers, contacts or status into a ticket that someone confirms, as SSAC advises.
5. Sign your zones with DNSSEC and validate answers on your resolvers, as Talos advises in its follow-up report. DNSSEC lets a resolver check that an answer came from the zone and was not altered, which blocks cache poisoning. It is not account protection: DS records reach the registry through your registrar, so the registrar account still controls which keys resolvers trust.
6. Encrypt lookups between devices and the resolver you trust, and control port 53. Ordinary DNS queries are unencrypted. DNS over TLS (RFC 7858) encrypts them, which removes opportunities for “eavesdropping and on-path tampering”. DNS over HTTPS (RFC 8484) does the same over HTTPS. Then block or log outbound port 53 traffic to other resolvers, so a changed setting cannot quietly send devices elsewhere. The limit: this protects only the last hop, not a changed resolver or changed domain records.
7. Watch Certificate Transparency logs for your domains and look into every certificate nobody ordered, as CISA directed.
8. Patch internet-facing systems. Talos tied first access in its 2017 to 2019 campaign to spear-phishing and known flaws in products such as Cisco ASA, Apache Tomcat, Drupal and phpMyAdmin.
9. Keep routers on supported firmware with remote management closed, as the Justice Department advised in April 2026.

Registrar locks are worth setting, but they are not enough alone. SSAC notes that some registrars lift the lock and set it again automatically when the account owner logs in, so whoever holds the login can make changes. Registry locks need the registry’s own verification.

What Should You Do If Your DNS Was Hijacked?

1. Get back into the registrar or DNS account, change the password, enforce MFA and remove users nobody recognizes.
2. Restore name servers and records from a known good copy. Start with NS and MX, the records CISA told agencies to check first.
3. Find certificates issued for your names during the window and revoke any that were requested fraudulently, as CISA advised in its 2019 alert on DNS infrastructure hijacking.
4. Treat every login entered during the window as stolen. Talos recommends a network-wide password reset from a computer on a trusted network. Also end sessions and revoke tokens, which the 2026 router case shows attackers collect.
5. Check what the attacker could set up while they controlled your DNS: new domain verifications and admin accounts in cloud and SaaS consoles, and mail that reached their servers.
6. Use passive DNS history and your logs to fix the exact window, and keep the evidence for the registrar and for any report.

Brandefense External Attack Surface Management lists the domains, subdomains and certificates linked to your organization, and its misconfiguration detection checks DNS records, including dangling ones.

Historical records can reveal earlier infrastructure relationships without proving a hijack. Our DNS history lookup guide explains how to validate old observations and ownership.