DNS hijacking is the redirection of a domain name’s traffic by changing the DNS records that tell the internet where the domain lives, without the owner’s authorization. The domain stays registered to its rightful owner; what changes is where it points. In the attacks that drew a government emergency directive in January 2019, attackers used stolen registrar and DNS provider credentials to repoint nameservers and mail records for hours at a time, obtained valid certificates for the hijacked names, and intercepted email before putting the records back. This guide defines DNS hijacking, separates it from the attacks it is confused with, walks through the Sea Turtle and DNSpionage campaigns as the research describes them, and sets out what to monitor, how to respond, and how to prevent it. It is part of our domain security hub.
DNS hijacking, domain hijacking and DNS spoofing
Three terms get mixed together, and each calls for a different defense. Domain hijacking is registration theft: the attacker transfers the domain to another registrar or another account so that the registration itself changes hands. Recovery means getting the registration back, a subject covered in our guide to what domain hijacking is. DNS spoofing, also called cache poisoning, is the forgery of DNS answers in transit, so that a resolver accepts and caches a false address without any record anywhere being changed. DNSSEC was designed against that attack.
DNS hijacking sits between the two. The registration is untouched and the records are not forged; they are legitimately edited by someone who should not have been able to edit them. Because the changed records are published by the real nameservers or the real registry, every resolver on the internet, validating or not, faithfully distributes the attacker’s answer. That is the defining feature of DNS hijacking: the infrastructure works exactly as designed, on behalf of the wrong person.
The three places DNS hijacking happens
The first is the registrar account. Whoever controls the registrar login controls the NS (nameserver) records that delegate the domain, and can point the whole domain at nameservers the attacker runs. Registrars also hold EPP credentials (Extensible Provisioning Protocol, the channel registrars use to send changes to the registry), and a stolen EPP credential lets an attacker change delegations for every domain under that registrar without touching any customer account at all.
The second is the DNS provider account. If the zone is hosted at a managed DNS service, whoever controls that login can edit individual records, an A record for the website or an MX record for mail, while the nameservers stay unchanged. These edits are harder to notice than a nameserver change.
The third is the resolver or the network. A compromised router, a malicious resolver, or a poisoned cache can redirect users on one network without touching the domain’s records. This is the only one of the three that DNSSEC validation can defeat directly, and the only one the domain owner cannot see from the registrar or DNS provider side.
DNSpionage, Sea Turtle and the January 2019 incidents
The campaign first reported publicly in late 2018 under the name DNSpionage targeted government and telecommunications organizations in the Middle East. The attackers obtained credentials for registrar and DNS provider accounts, redirected mail and web records to servers they controlled, and used the brief window of control to obtain domain-validated certificates so that intercepted connections showed no browser warnings. In April 2019 a related and broader campaign was reported under the name Sea Turtle. It extended the same technique up the chain, compromising registrars and even ccTLD registry operators to reach targets through their DNS infrastructure rather than through the targets’ own systems.
The clearest technical account of how the registrar-level attacks worked comes from Packet Clearing House. In its briefing to the ICANN DNS Symposium in May 2019, Bill Woodcock described attacks in which a registrar EPP credential, found in the spoils of an attack against a third party, was used to change NS records, but not DS records, in four one-hour windows on December 13, December 14 and January 2. During those windows a Comodo domain-validation certificate was issued and placed into IMAP proxying infrastructure that harvested credentials from Middle Eastern government mail users. The records were then restored. Without continuous monitoring, an administrator would have seen nothing wrong.
Later measurement confirmed the pattern at scale. Researchers at UC San Diego retroactively identified 41 hijacked domains between January 2017 and March 2021, 33 of them associated with the Sea Turtle campaigns, plus 24 targeted domains where attackers had prepared infrastructure but not yet redirected traffic, in their paper Retroactive Identification of Targeted DNS Infrastructure Hijacking. Victims spanned more than twenty countries and 15 top-level domains, and government ministries were the largest category. The attackers obtained suspicious certificates for 40 of the hijacked domains, 28 from Let’s Encrypt and 12 from Comodo, and only four of those certificates were ever revoked. For 51 percent of the hijacked domains, the attacker’s redirection lasted at most one day.
Two lessons follow. The dwell time was short, so daily checks would have missed most of the hijacks. And the certificates outlived the hijacks, so an attacker holding a valid certificate could intercept traffic again later without touching DNS a second time.
CISA Emergency Directive 19-01
On January 22, 2019, the Department of Homeland Security issued Emergency Directive 19-01, Mitigate DNS Infrastructure Tampering. It gave federal civilian agencies 10 business days to complete four actions: audit all public DNS records to verify they resolved to the intended locations, change the passwords on all accounts that could modify DNS records, add multi-factor authentication to those accounts, and begin monitoring Certificate Transparency logs (public, append-only logs of every certificate issued by participating authorities) for certificates issued for agency domains that the agency did not request. Status reports were due January 25 and completion reports February 5, 2019.
The four actions are a usable template for any organization, and the FDIC’s experience shows what carrying them out looks like under a deadline. The FDIC Office of Inspector General’s audit of the agency’s response found that the FDIC audited all 178 of its public DNS records, changed passwords for 37 DNS-capable accounts (plus one that had been omitted from its completion report), and implemented multi-factor authentication for every account able to change DNS records by the February 5 deadline. It also began weekly reviews of Certificate Transparency log data supplied by CISA. The number that stands out is 37: a single agency had nearly forty accounts that could change its DNS, which is why the inventory step comes first.
What changed after 2019
The 2019 campaigns moved DNS hijacking from a theoretical concern to a documented nation-state technique with a federal response, and they changed what a reasonable security posture looks like. Before 2019, DNS records were treated as configuration. After 2019, the accounts that can change them are treated as privileged credentials, Certificate Transparency monitoring became a standard control rather than a specialist tool, and registry lock moved from a niche product to a baseline for high-value domains. The threat did not go away; the same technique works against any organization whose registrar or DNS provider login can be phished.
What to monitor
Three signals catch nearly every DNS hijack. The first is a change to NS records at the registry, which is visible in the public delegation and should never happen without a planned change request. The second is a change to A, AAAA or MX records in the zone, particularly a change that is reverted within hours. The third is the issuance of a certificate for one of your domains that you did not request, visible in Certificate Transparency logs. Monitoring should run continuously, because the measured dwell time in the Sea Turtle campaigns was often a day or less. Our domain monitoring hub describes how these checks fit together.
How to respond to a DNS hijack
First, regain control of the account that was used, whether registrar or DNS provider, by contacting the provider’s security or abuse channel and proving ownership. Then revert the changed records to their known-good values and confirm from several outside networks that the correct answers are being served. Next, search the Certificate Transparency logs for every certificate issued for the domain during and after the hijack and ask the issuing authorities to revoke them, because a surviving certificate lets the attacker intercept traffic again. Once the records are back, rotate every credential that could have been exposed: registrar and DNS logins, API keys, EPP credentials if you hold them, and the passwords of any mail users whose connections passed through the attacker’s proxy. Finally, review mail flow for the hijack period to understand what was intercepted, and treat any mailbox that authenticated during that window as compromised.
Prevention
Prevention follows the three places the attack happens. Protect the registrar account with multi-factor authentication, a unique password, and a short list of who can log in; our guide to registrar account security covers the details. Add a registry lock (a registry-level hold that blocks changes to nameservers and other registry data until the registrar verifies the request out of band) to every domain that carries revenue, email or customer logins, because a registry lock stops a nameserver change even when the attacker holds the registrar password. Harden the DNS provider account the same way, and limit who can edit the zone. Enable DNSSEC so that resolver-level forgery is rejected, while understanding that it does nothing against an attacker who edits the records through a stolen account. And monitor continuously, because every other control can fail silently and monitoring is the only one that tells you so.
How DNAccess helps with DNS hijacking
We help organizations inventory every account that can change their DNS, put registry locks and multi-factor authentication in place, and respond when a hijack has already happened, working with registrars and certificate authorities to revert records and revoke certificates. Our DNShield domain name monitoring watches nameserver, DNS record and certificate changes so that a hijack measured in hours is caught in hours. To talk through a specific domain or incident, contact us.