Domain Registrar Compromise Playbook: Regaining Control of Domains and Records

Whoever controls your registrar account controls where your domain points, who receives your email and who can obtain certificates in your name. A registrar compromise is different from an ordinary DNS hijack: the attacker can change name servers, contact details and even the registrar of record, and every fix you make at the DNS host can be undone from the registrar portal. This playbook template covers a takeover of the registrar account, an unauthorised change of registrant, an unauthorised inter-registrar transfer and a lapsed or deleted domain. It draws on the ICANN Transfer Policy and Transfer Dispute Resolution Policy, ICANN's EPP status code guidance, CISA Emergency Directive 19-01 and NCSC guidance on managing public domain names. It is written for incident managers, DNS and network owners, and identity teams. Adapt the bracketed text before adoption.

How to use this template

• Replace text in square brackets, such as [Organisation], [Domain Owner], [Registrar] and [SIEM], with your own names. "Must" is mandatory; "should" is recommended.
• Decision points are marked D1 to D6. Record each decision, who made it and when, in the incident log.
• Policy details reflect the ICANN pages cited below. ICANN notes that a revised Transfer Policy was published on 21 February 2024, so confirm current time limits with [Registrar] and on icann.org when you adopt this template, and re-check yearly.
• If only records at your DNS host changed and the registrar account is intact, use the DNS Hijack Playbook instead. Background on records, DNSSEC and monitoring is in the DNS Security Guide. Practise both with the Tabletop Exercise Scenario Pack.

1. Scope and triggers

1.1 This playbook applies to every domain registered by or for [Organisation], including brand, marketing, email-only and parked domains held in the [Domain Register].

1.2 Triggers: registrar notification of login, contact or lock changes; monitoring alert on NS, MX or DS records; a certificate transparency alert for a certificate you did not request; users or customers reporting a changed website or bounced email; the domain showing a new registrar in RDAP or WHOIS.

1.3 Relevant ATT&CK techniques: T1584.001 Compromise Infrastructure: Domains and T1584.002 Compromise Infrastructure: DNS Server (taking over your domain or its name servers), and T1557 Adversary-in-the-Middle where traffic is redirected through attacker infrastructure. Lookalike registrations are a separate problem: see the Typosquatting and Lookalike Domains Guide.

2. Roles and contacts

2.1 [Organisation] must keep, outside the affected domain, a contact sheet with: [Registrar] abuse and security phone numbers, the account ID, the reseller (if any), the registry operator for each top-level domain, the registry lock procedure and its authorised callers, and personal phone numbers for the incident roles. If your own email is redirected, an emergency address on a separate domain is the only way the registrar can reach you.

2.2 The registrar is your first contact. Under the Transfer Policy, registrars keep a Transfer Emergency Action Contact (TEAC) for urgent transfer issues, open only to registrars, registry operators and ICANN staff, which must give a non-automated human response within 4 hours. You cannot call the TEAC yourself: ask [Registrar] to use it.

3. Detection and triage

1. Freeze the evidence first: capture RDAP or WHOIS output, current NS, A, AAAA, MX, TXT and DS records from more than one public resolver, the registrar portal audit log, account notification emails and timestamps. Do this before any change.
2. Establish what changed and when: compare with the last known-good zone export and the [Domain Register]. Check name servers and DS records first, because they control everything below them.
3. Check registrar status codes: clientTransferProhibited, clientUpdateProhibited and clientDeleteProhibited are set by the registrar; serverTransferProhibited, serverUpdateProhibited and serverDeleteProhibited are set by the registry. A missing lock that you had set is itself an indicator.
4. Search certificate transparency logs (for example crt.sh or Cert Spotter, as NCSC suggests) for certificates issued since the first suspicious change. Anyone who controls DNS can pass domain validation.
5. Check email impact: MX changes, new SPF includes, new DKIM selectors, and mail volume drops. See the DMARC, SPF and DKIM Guide.
6. Check identity impact: new verification TXT records, new or changed federated domains in the IdP, and SSO redirect or metadata URLs on the domain.

D1: Severity. Critical: name servers, MX or registrar of record changed on a domain used for login, email or customer services. High: account takeover with no record change yet, or an unauthorised change of registrant. Medium: a lock removed or contact changed on a parked domain. The [Incident Manager] assigns severity within [30] minutes of the trigger.

4. Containment

D2: Which route first? If you still have access to the registrar account, secure it yourself (4.1). If you do not, go straight to the registrar's security team (4.2). If the domain has moved to another registrar, go to 4.3. Run these in parallel where staff allow.

4.1 Account still accessible: reset the password from a clean device; remove unknown users, API keys and sessions; re-enrol MFA, preferring phishing-resistant methods; restore the account and registrant email to an organisational mailbox that is not hosted on the affected domain; re-apply registrar locks; cancel any pending change of registrant or outbound transfer.

4.2 Account lost: call [Registrar] security, give the account ID and ask them to freeze the account and the domains, block outbound transfers and hold any pending changes. Provide proof of ownership: invoices, payment records, registration documents and corporate identity, which NCSC advises keeping for exactly this purpose.

4.3 Domain transferred away: ask [Registrar] to contact the gaining registrar through the TEAC immediately. Under the Transfer Policy a registry can undo a transfer when both registrars agree it was a mistake, after a dispute decision, under a court order, or when the gaining registrar fails a TEAC deadline.

4.4 Where the attacker already obtained certificates, the [PKI Owner] asks the issuing certificate authority to revoke them, as CISA ED 19-01 requires of US federal agencies for unauthorised certificates.

5. Eradication

1. Restore name servers and DS records at the registrar from the known-good record. A wrong DS record will make a DNSSEC-signed zone fail validation; if keys may be compromised, coordinate a key rollover with the [DNS Engineer].
2. Restore zone content at the DNS host and audit every record, NS records first, as ED 19-01 directs.
3. Rotate every credential that touches the domain: registrar users, registrar API keys used by automation, DNS host accounts and API tokens, ACME account keys, and CI/CD secrets that manage records. Change passwords and add MFA on all accounts that can change DNS, again as ED 19-01 requires. See the Secrets Rotation Runbook Template.
4. Remove persistence: extra registrar users, forwarding rules on the registrant mailbox, added IdP domains or federation trusts, new CAA records that allow an attacker's CA, and mail forwarding at the registrar.
5. Find the root cause: phished registrar login, takeover of the contact mailbox, reseller compromise, social engineering of registrar support, or an expired domain. If the contact mailbox was the path, also run the Account Takeover Response Playbook.

D3: Dispute or negotiate? If the registrars cannot agree to undo a fraudulent transfer, the losing registrar can file under the Transfer Dispute Resolution Policy within 12 months of the transfer. The respondent has seven calendar days to reply, a panel decides within 30 days, and a decision takes effect after a 14-day waiting period unless court proceedings are filed. Only registrars file under the TDRP, so [Legal] works through [Registrar]; court action remains available to either party. [Legal] decides with the [Incident Manager].

6. Recovery

1. Bring back services in order: authoritative DNS, email (MX, SPF, DKIM, DMARC), SSO and login endpoints, then websites and APIs. Records cached by resolvers expire on their TTL, so expect a tail of wrong answers.
2. Reissue certificates for affected names with fresh keys, and confirm every unauthorised certificate is revoked. See the Certificate Transparency Guide.
3. Verify identity trust: confirm the IdP still lists only your verified domains, that SAML metadata and OIDC redirect URIs are unchanged, and revoke sessions and refresh tokens issued during the hijack window. See the Identity Provider and SSO Security Guide.
4. Check email that went astray: mail delivered to attacker MX hosts during the window may include password reset links, invoices and supplier messages. Treat password resets sent in that window as compromised.
5. Apply registry lock to high-value domains (D4) and confirm the authorised unlock callers.
6. Monitor NS, MX, DS and CT logs daily for [30] days.

D4: Registry lock. Apply registry lock to every domain used for email, login or payment where the registry offers it. Accept slower legitimate changes as the price.

D5: Close containment? The [DNS Engineer] confirms records match the known-good state from three resolvers, and the [Domain Owner] confirms locks and contacts are correct, before the [Incident Manager] closes.

7. Communication and notification

• Channels: assume corporate email and the website are untrusted until DNS is restored. Use pre-agreed phone trees, a status page on a separate domain and social accounts.
• Customers and users: tell them which time window was affected, not to trust links or emails from that window, and to expect certificate warnings to stop.
• Suppliers and partners: warn finance contacts that invoice or bank detail emails from the window may be fraudulent.
• Regulators: if redirected email or login traffic exposed personal data, [Legal] applies the [Regulatory Register], for example GDPR Article 33 (72 hours from awareness). See the Breach Notification Laws by Country Guide.
• Registrar and registry: keep a written record of every case number and call.

8. Post-incident review

8.1 Within [10] working days, using the Post-Incident Review and Root Cause Analysis Template. D6: decide whether to consolidate domains with one registrar that supports registry lock and strong MFA.

8.2 Record: first unauthorised change, detection time, time to registrar contact, time to restore NS and MX, certificates issued, emails and sessions exposed, and why monitoring did or did not fire.

Implementation guidance

Prevention that shortens this playbook.

Rollout. Phase 1: build the [Domain Register] with registrar, registry, expiry, lock status, owner and the services each domain supports. Phase 2: move the registrar account to named users with MFA and an out-of-band contact email, and treat registrar and DNS API keys as non-human identities with owners and rotation. See the Secrets Management Guide. Phase 3: apply registry lock to a pilot domain, test the unlock procedure end to end (this is your rollback path), then extend to all critical domains. Phase 4: exercise the playbook yearly. Small organisations with a handful of domains should start with MFA, auto-renew and a separate contact mailbox; large organisations should consolidate registrars and feed registrar audit logs into [SIEM].

Framework mapping.

Metrics. Percentage of critical domains under registry lock; percentage of registrar accounts with MFA on every user; domains with an expiry inside 30 days and no auto-renew; mean time from an NS or MX change to alert; mean time from trigger to registrar contact (target under [1] hour).

Common failure patterns.

• Fixing records at the DNS host while the attacker still holds the registrar account and changes them back.
• Registrar contact email hosted on the hijacked domain, so recovery and transfer notices go to the attacker.
• Registry lock applied but no one knows the unlock procedure or the authorised callers.
• Forgetting certificates: rogue certificates stay valid after DNS is restored unless revoked.
• Rotating human passwords but not the registrar and DNS API keys used by automation.
• Domains registered on a former employee's personal account or card.

Standards and references

• ICANN: Transfer Policy
• ICANN: Transfer Dispute Resolution Policy
• ICANN: EPP Status Codes, What Do They Mean, and Why Should I Know?
• CISA: Emergency Directive 19-01, Mitigate DNS Infrastructure Tampering
• NCSC: Managing public domain names
• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• MITRE ATT&CK: Compromise Infrastructure: Domains

Related NHI Mgmt Group resources: DNS Hijack Playbook · DNS Security Guide · Certificate Transparency Guide · Incident Response Plan Template · Identity Provider and SSO Security Guide