Registrar Account Compromise

One credential, the whole portfolio

Registrar account compromise is an attacker getting into the control panel where your domains live — by stealing your password, taking over your email, or talking a support agent into it. It is the root cause behind a large share of the incidents catalogued under theft and hijacking, and it has a property none of the others do: it puts every domain in the account at risk simultaneously.

That is the part organizations underestimate. A portfolio consolidated into one account for administrative convenience is a portfolio with one shared failure. The convenience is real. So is the correlation.

It is also the scenario where policy protects you least. Nothing in ICANN's consensus policies stops someone who is authenticated as you; the transfer rules exist to verify that a request came from the account holder, and by that standard the request did. The only real limits are the 60-day locks and how fast the account is regained. Once names have left the account or the registrar, the situation converts into the disputed track, where the Registrar Transfer Dispute Resolution Policy sets a twelve-month filing deadline and the remedies belong to registrars rather than to you.

Three entry points, all documented

Your credentials

Phishing, credential stuffing — automated login attempts using passwords leaked from other sites — keyloggers, and compromise of the registrant's email account, which is the password-reset path for the registrar account and therefore the higher-value target. CISA Emergency Directive 19-01, issued 22 January 2019 after a campaign against US federal agencies, describes the identical first step: attackers compromise user credentials to access DNS administration accounts.

The registrar's own staff

SSAC's SAC007 recorded, in 2005, an attacker who was able to socially engineer a first-tier customer support agent into making a change to an administrative contact email account. This has not gone away. Krebs on Security reported in November 2020 that GoDaddy employees were manipulated in attacks against multiple cryptocurrency services, and the account behind the 2021 perl.com theft attributes it to a social engineering attack on the registrar involving phony documents.

An upstream provider or reseller

Gandi's July 2017 breach was not a customer-account compromise at all. Attackers obtained Gandi's own login credentials for a technical partner's web portal, believed captured over an insecure connection, and used them to alter 751 domains. A reseller — a company selling domains under an accredited registrar's accreditation rather than its own — adds one more account whose compromise reaches your names without touching anything you control.

What happens in the first hour after they get in

The post-access sequence is consistent enough to be treated as a signature.

First, change the account or contact email so that every subsequent notification — contact change, lock removal, transfer confirmation — goes to the attacker instead of to you. This step is what makes the rest quiet.

Then one of two branches. The fast branch is DNS: change nameservers or records to redirect traffic and mail. It works within minutes and it is reversible within hours by whoever regains the account. The slow branch is the registration: pull the AuthInfo code — the password-like string that authorizes moving a domain to another registrar — and push an inter-registrar transfer. Slower to execute, far harder to reverse, and the branch a thief takes when the goal is to sell rather than to intercept.

Either branch may include the certificate step. CISA ED 19-01 describes attackers obtaining valid encryption certificates for the organization's domain names, so that interception produces no browser warning. A certificate obtained during the compromise remains valid after you have fixed everything else, which is why it belongs on the cleanup list and not merely the detection list.

Registry lock is the control that answers this specific problem

Most domain security advice is generic. This is not: registry lock exists precisely because an attacker inside the control panel can undo anything the control panel can set.

A registrar lock — the EPP status clientTransferProhibited — is set and cleared by your registrar, which means it is set and cleared from the account the attacker now holds. A registry lock moves the authorization step outside the panel entirely. Verisign's Registry Lock Service, which covers .com, .net, .cc and .name, sets the server-side statuses serverUpdateProhibited, serverDeleteProhibited and serverTransferProhibited, and requires that an authorized individual at the registrar be contacted by Verisign by phone and provide an individual security phrase before the name can be unlocked. Verisign describes that out-of-band step as helping protect against automation errors and system compromises.

Read the EPP statuses on any domain and you can tell instantly which regime applies. Statuses beginning client are set by the registrar. Statuses beginning server are set by the registry. If a high-value name shows only client statuses, its entire defense sits behind one login.

SAC007's first recommendation, that registries ensure Registrar-Lock and EPP authInfo are implemented according to specification, was the 2005 version of the same argument.

Multi-factor authentication, and the kind that does not count

MFA — a second login factor beyond the password — is the highest-value control available on the account itself, and CISA ED 19-01 requires it for all accounts on systems that can make changes to DNS records. It also says, in as many words, that SMS-based MFA is not recommended, consistent with NIST guidance.

That caveat is not pedantry. SIM-swap attacks target exactly the population that owns valuable domains, and an SMS second factor delivered to a number an attacker has ported is not a second factor at all. App-based or hardware-token authentication is the meaningful version.

Three accounts need it, not one: the registrar account, the DNS-hosting account if it is separate, and the email account that can reset both. Protecting the registrar login while leaving the recovery mailbox on a password alone is a common and self-defeating configuration — and it is worse when that mailbox is hosted on a domain inside the same registrar account, because losing the account then loses the recovery channel too. perl.com's write-up makes the point directly about using the registered domain for contact email: when the domain no longer handles your mail, nobody can reach you.

Assume the intruder was there longer than you think

Dwell time — how long an intruder is inside a system before detection — is the variable that turns a contained incident into a systemic one, and domain infrastructure produces unusually long dwell times because a well-executed compromise breaks nothing visible.

perl.com was compromised around September 2020 and transferred to another registrar in December with nameservers deliberately left unchanged; nothing failed, so nobody looked. Detection came on 27 January 2021 through independent DNS monitoring. At the provider scale, GoDaddy disclosed in February 2023 a multi-year breach in which attackers stole source code and installed malware — a reminder that the account you log into is only as trustworthy as the platform underneath it.

The operational consequence is that incident scope should be set by what an attacker could have reached over the plausible window, not by what visibly broke. Gandi's response is the standard worth copying: after one technical partner portal was compromised, it reset credentials across all 150 of its technical platforms, and it verified the 18 SSL certificates issued during the incident window rather than assuming none had been.

The remediation set, and its clock

CISA ED 19-01 gives four required actions and a 10-business-day window, and it remains the clearest published control set for this threat despite being written for federal agencies:

• Audit DNS records for all domains, verifying that each resolves to the intended location.
• Update passwords on all accounts that can make DNS changes.
• Enable multi-factor authentication on those accounts — not SMS.
• Monitor Certificate Transparency logs for certificates issued on your domains.

Three failure patterns recur in real remediations. Rotating only the credential that obviously failed, when the correct assumption is that anything reachable from it is also suspect. Skipping the certificate audit, so a valid certificate survives the cleanup. And fixing records without fixing access, which reverts the symptom and preserves the cause.

Where names have already left the registrar, the recovery route is the losing registrar's emergency escalation — the Transfer Emergency Action Contact carries a 4-hour response obligation — and, beyond that, the twelve-month TDRP window described in the transfer material.

Structural changes worth making before anything happens

Some of what follows is cited policy; some is practice. I will mark which is which, because the distinction matters when you are justifying budget.

Cited: non-SMS MFA on every account that can change DNS; clientTransferProhibited on by default; registry lock on names whose loss would be material; scheduled DNS record audits rather than post-incident ones; continuous Certificate Transparency monitoring. SAC007 adds a fourth recommendation that registrars publish emergency support contact information to other registrars, resellers and registry operators — the registrant-side version of that is keeping your registrar's emergency contact path on file offline, where a compromised account cannot hide it from you.

Practice, not policy: separate high-value domains into their own account with their own credentials, so a single compromise does not expose the whole portfolio. In my experience this is the change organizations resist most and regret not making most, because the administrative overhead is visible every week and the benefit is invisible until the day it is the only thing that mattered.

One further note on the policy landscape. No ICANN consensus policy specifically mandates account security at registrars; SAC007's ninth recommendation asked ICANN to investigate whether stronger and more publicly visible enforcement mechanisms were needed for registrars that fail to comply with the transfer policy, and its eighth asked registrars to improve registrant awareness of hijacking and impersonation. Twenty years on, the awareness gap is still where most of these incidents begin.

Frequently Asked Questions