Attackers Hijacked Three Country-Code Registries and Got Valid Google Certificates. Nothing in the Chain Malfunctioned

Google's Chrome Secure Web and Networking Team disclosed on 6 October that attackers hijacked three country-code top-level domains — .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa) — by compromising the third-party operators that run them. Holding the authoritative DNS records for those zones, the attackers then obtained valid, publicly trusted HTTPS certificates for domains they did not own, several of them Google's.

The striking part is not that certificates were mis-issued. It is that, on the available evidence, nothing in the chain malfunctioned.

These incidents did not involve a compromise of Google's systems. [...] Due to the nature of the attacks, we have no reason to believe the Certification Authorities (CAs) that issued the impacted certificates did anything wrong.

Google's systems were untouched. The certificate authorities applied the checks they are required to apply, and the checks passed. The attacker simply occupied the position those checks consult.

What was issued

Google named no certificates. The Hacker News went to the Certificate Transparency logs on 7 October and found at least twelve, covering seven domains, issued over six days in late September.

Eleven came from Let's Encrypt and one from ZeroSSL. The two .gh certificates and the ZeroSSL certificate were revoked on 26 September; the remaining nine on 1 October. The names covered include google.com.gh, google.sl and google.as, along with YouTube properties. Because only a limited set of names was searched, the real total is probably higher. Let's Encrypt confirmed the issuance on its own community forum, where staff engineer Matthew McPherrin wrote:

Yes, certificates for Google and Youtube were issued, and have been revoked.

Domain validation is a DNS question, and nothing more

Almost every certificate on the public web is issued after a domain control validation check that asks one thing: can the requester demonstrate control of the name, typically by publishing a value the CA specifies in DNS. That check is deliberately cheap and fully automated. It is the reason HTTPS went from a minority of traffic to nearly all of it in a decade, and it is not a design flaw.

But it does mean that authority over a name sits exactly where authority over DNS sits. Compromise a registry rather than a single domain and you are, for validation purposes, the owner of everything beneath it — an entire national namespace at once, including the defensive registrations whose owners have not logged into them in years. That is why the affected set runs well past Google. Reviewing CT data, Google says it found other affected organisations, among them "well-known global brands and widely used online services", and blocked their certificates in Chrome too.

What Chrome did, and the limits it admits

Chrome pushed the unauthorised certificates into CRLSets, its emergency blocklist, worked with the issuing CAs on revocation so that non-Chrome clients benefit, and swept CT logs for further issuance. Google states plainly that Chrome users need take no action.

It is equally plain about the two gaps. It "cannot guarantee that our analysis identified every affected domain", and CRLSets protect Chrome and nothing else:

browser-side intervention should not be relied on to protect your users

What a domain owner can actually do

Google's advice is CT monitoring across the full portfolio — parked and regional names included — and restrictive CAA records bound to specific ACME accounts and validation methods. Both are worth doing. Neither is prevention. Google concedes that CAA cannot stop issuance while an attacker holds the DNS; its value arrives afterwards, denying the reuse of cached validation once legitimate control is restored.

That is the uncomfortable conclusion. During a registry-level hijack, the domain owner has no preventive control whatsoever. The only party that can prevent it is the registry operator, whose security posture most affected brands have never evaluated and cannot influence. Which is why the structural remedy Google gestures at — shorter certificate lifetimes and less reuse of cached domain validation, through the Chrome Root Program — is not a fix for the hijack. It is a fix for how long a hijack keeps paying after the DNS is back.

Still unknown

Who did this, how the three operators were breached, and whether the registries are now secure. None of the three has issued a statement. No evidence has been published that any certificate was used to intercept traffic — though for a set of names that largely redirect to Google's main properties, absence of observed abuse means less than it would elsewhere. Google says it contacted the other affected organisations where it could, and named none of them.

The practical takeaway is narrow and worth acting on: if you hold a name under .gh, .sl or .as — including one you registered defensively and forgot — read your own CT log entries for late September.

Sources: Chrome's Response to Recent ccTLD Registry Hijacks — Google Security Blog · Attackers Hijack .gh, .sl, and .as Registries to Obtain Certificates for Google Domains — The Hacker News · Attackers hijacked top-level domains, minted fake security certs for Google and other orgs — The Register · Hackers hijack Google domains after breaching ccTLD registries — BleepingComputer · Hackers hijack three country-code domain registries — Help Net Security · Chrome's Response to Recent ccTLD Registry Hijacks — Let's Encrypt Community