Unexpected nameserver or registrar changes: early signs of domain hijacking

Domain hijacking means someone other than you gains control over where your domain points. The most direct ways are changing the nameservers, transferring the domain to another registrar, or editing DNS records in your DNS provider account. Each of these is a normal administrative action, which is why an unexpected change is the earliest and clearest warning sign.

Whoever controls your DNS can send your website visitors and your incoming email to their own servers. Because they control the domain, they can also obtain valid TLS certificates for it, so visitors see no browser warning.

The good news is that these changes are visible from outside, and registrars and registries offer locks that make them much harder to carry out.

How DNS hijacking happens in practice

In January 2019, CISA issued Emergency Directive 19-01 after a campaign in which attackers obtained credentials for accounts that could change DNS records. They altered A, MX and NS records to route web and mail traffic through infrastructure they controlled, and obtained valid certificates for the affected domains. The directive (since sunset) required agencies to audit DNS records, change passwords on DNS accounts, add multi-factor authentication and monitor Certificate Transparency logs. Those 4 steps remain a good baseline for any organization.

The common entry points are:

• A compromised registrar or DNS provider login, often through a reused or phished password.
• A compromised email account that receives the registrar's password reset messages.
• Social engineering of the registrar's support staff.
• An expired domain re-registered by someone else, covered in what happens when your domain expires.

What an unexpected change looks like

Keep a record of what is normal for your domain, then compare:

• Nameservers (NS): a switch from your usual DNS provider to unfamiliar servers.
• Registrar: the domain now sponsored by a registrar you have never used.
• A, AAAA and CNAME records: your website suddenly pointing to an IP address in a network you do not use.
• MX records: mail routed through a server you did not set up.
• EPP status codes: protective locks such as clientTransferProhibited removed without a reason.
• New certificates: a certificate for your domain issued by a CA you do not use.

How to check your domain yourself

Read the current values directly:

dig NS example.com +short
dig A example.com +short
dig MX example.com +short
whois example.com | grep -i -E "registrar:|name server|status"

Save the output. Run the same commands regularly and compare. A difference you cannot explain is worth an immediate question to whoever manages your DNS.

For certificates, search Certificate Transparency logs on crt.sh for your domain and look at the issuers. See Certificate Transparency logs explained.

Locks: registrar lock and registry lock

ICANN's EPP status code reference describes the statuses that protect a domain:

• clientTransferProhibited: set by your registrar. The registry rejects requests to transfer the domain to another registrar. This is the common "registrar lock" and should be on for every domain you are not actively moving.
• clientUpdateProhibited and clientDeleteProhibited: the registry rejects updates or deletion until your registrar removes the status.
• Registry lock: some registry operators offer a service that sets serverUpdateProhibited, serverTransferProhibited and serverDeleteProhibited. These are set at the registry level rather than in your registrar account, and ICANN notes that removing a server status generally takes longer, which is the point. Ask your registrar whether it is available for your top-level domain.

A registrar lock alone does not help if the attacker logs in to your registrar account, because they can remove it. A registry lock adds a step outside that account, so a stolen registrar password alone is not enough.

Hardening the accounts that control DNS

• Multi-factor authentication on the registrar and DNS provider accounts, preferably a security key or passkey rather than SMS.
• A dedicated contact email for the registrar, on a mailbox protected as strongly as the registrar account itself.
• Few people with access, and access removed when someone leaves.
• A CAA record listing the certificate authorities you use, defined in RFC 8659. For example:

example.com.  CAA 0 issue "letsencrypt.org"

CAA does not stop a hijacker who controls your DNS from editing it, but it makes unplanned issuance from other CAs harder and a CAA change itself becomes a signal.

If you see a change you did not make

1. Contact your registrar and DNS provider through a known channel, not a link from an email.
2. Restore the correct NS, A and MX records and re-enable locks.
3. Change passwords and reset multi-factor authentication on those accounts and on the email account that receives their notices.
4. Check Certificate Transparency logs for certificates issued during the window and ask the issuing CA to revoke any you did not request.
5. Treat passwords and sessions used on your site and mail during that window as possibly exposed.

Checklist

• Baseline of NS, A, MX, registrar and status codes saved.
• Registrar lock on, registry lock considered.
• Multi-factor authentication on registrar, DNS and the linked mailbox.
• CAA record published.
• Regular comparison against the baseline.

Where Datahorses fits

Datahorses watches your company from the outside and checks your nameservers, registrar, DNS records and newly issued certificates for changes. We do not enter your systems and need no access. An unexpected change is reviewed by a person and sent to you with what changed, when, and what to do first. See how we guard and what happens when we find something.