Domain Hijacking: Registrar Locks, Nameserver Changes and Recovery

There is a category of compromise where no server is breached, no malware runs, and nothing on your network misbehaves — and yet every user, every email and every API call goes to the attacker. The domain was taken at the registrar, and everything downstream followed the new records obediently.

Domain hijacking is an account security problem wearing a DNS costume. Understanding why that distinction matters is most of the exam value here.

How Domains Get Taken

Registrar account compromise. The most common route. Credentials for the domain account are phished, reused from another breach, or belong to a former employee whose access was never removed. The attacker logs in and changes the nameservers.

Social engineering the registrar. Support staff are persuaded to transfer the domain or reset access, often with forged documentation or a convincing story about a departed administrator.

Expiration. Not an attack at all, and surprisingly frequent. The renewal notice went to a mailbox nobody reads, the domain lapsed, and someone else registered it. Expired domains are monitored and bought within minutes.

DNS provider compromise. The registrar account is intact but the hosting provider's control panel is not, so the records change without the domain moving.

Unauthorized transfer. The domain is moved to a different registrar using a leaked authorization code.

Why DNSSEC Does Not Help Here

This catches people out. DNSSEC proves that a response came from whoever controls the zone and was not altered in transit. An attacker who owns the registrar account is whoever controls the zone. They can publish new keys, sign whatever they like, and validation will pass cleanly.

DNSSEC defends the path. Registrar controls defend the ownership. Different layer, different threat.

What the Attacker Gets

Control of a domain is close to total control of an organization's public identity:

• Web traffic redirected to a cloned site, with a valid certificate obtained through domain validation — because proving domain control is exactly what the attacker can now do
• Email redirected by changing MX records, which captures password resets for every SaaS account the organization uses
• Password reset flows for third-party services hijacked wholesale
• Certificate issuance for any subdomain

The email angle is the one that turns a domain hijack into a full organizational compromise, since single sign-on recovery and vendor portals both fall back to email.

Controls That Work

• Registrar lock (clientTransferProhibited) — blocks transfers until explicitly lifted. Free, and off by default at some registrars.
• Registry lock — a stronger tier applied at the registry, requiring out-of-band human verification for any change. Appropriate for domains the business depends on.
• Multifactor authentication on the registrar account, using phishing-resistant factors where the registrar supports them.
• Dedicated role accounts, not personal ones. Domains registered under an individual's personal email leave with that individual.
• Auto-renew plus long registration periods, with expiry tracked as an asset in the CMDB rather than in someone's calendar.
• CAA records — restrict which certificate authorities may issue for the domain, limiting what an attacker can obtain quickly.
• Monitoring — alert on nameserver changes, WHOIS changes and new certificates issued for your domains. Certificate transparency logs are public and free to watch.

Domain and DNS accounts are textbook candidates for privileged access management, since they are high-impact, rarely used and frequently forgotten.

Detection and Recovery

Detection usually comes from outside — users reporting a wrong site, mail bouncing, a certificate appearing in transparency logs. Internally, a change to authoritative nameservers should generate an alert in the SIEM, because legitimate nameserver changes are rare enough that every one deserves a look.

Recovery is slow, and that is the part worth internalizing. Regaining the account is only the start; propagation delays mean the attacker's records persist in caches for as long as the TTL allows, and a hostile TTL may have been set very high on purpose. Lowering TTLs in advance of any planned change is the cheap preparation nobody does until after the first incident.

Treat it as a full incident: the attacker likely captured credentials and reset tokens during the window, so post-recovery work includes forcing password resets and reviewing authentications across every service that trusts the domain. That sequencing belongs in the incident response playbook before you need it.

Exam Focus

Recognize registrar account compromise from a scenario where DNS records changed but no internal system was breached. Know that DNSSEC does not prevent it. Know registrar and registry locks by name, and know CAA records restrict certificate issuance. And expect expired domain registration to appear as a distractor that turns out to be the correct answer.