Three Country-Code Registries Were Hijacked and Google's Certificates Were Issued. Nothing Failed. That Is the Problem

Introduction

On Monday, October 6, 2026, Google's Chrome Secure Web and Networking Team published a disclosure with an unusual shape for a security incident. It did not begin with a bug. It did not begin with a phishing campaign or a malware family or a stolen credential. It began with three names ending in a dot.

An unidentified group of attackers had compromised the third-party operators that run the country-code top-level domain registries for .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa). Holding the authoritative DNS records for those zones, they obtained valid, publicly trusted HTTPS certificates for domains they did not own — among them several belonging to Google, and properties of YouTube. Google says its own systems were never compromised, and that it has "no reason to believe the Certification Authorities (CAs) that issued the impacted certificates did anything wrong."

Both of those statements should worry you more than an admission of a bug would. The certificate authorities did exactly what they are required to do. Every validation check passed. The attacker did not defeat the system; the attacker became the thing the system asks.

This is the second time in recent memory that national namespaces have been the attack surface rather than individual domains, and it lands in the middle of a year that has already demonstrated how thin the layer beneath the padlock icon has become. For anyone who reads our cybersecurity coverage with an eye to architectural risk rather than patch cycles, the ccTLD incident is the clearest statement yet that the vulnerability is not in the certificate. It is in everything the certificate stands on.

What was actually issued

The first certificate appeared in the public logs on 22 September, under the .gh zone. Two days later the activity moved to Sierra Leone's .sl zone, and four days after that to American Samoa's .as. On each of those three days, most of the certificates for that zone were issued inside a ninety-minute window. That clustering is the tell: no organic application pattern produces that shape. A human, or an automated tool driven by one, sat down and requested a set of names.

The volume depends on which count you accept, and the spread is itself informative. Google's own disclosure named no certificates at all. Security researchers working through the Certificate Transparency logs found at least twelve certificates covering seven domains in an initial pass — two under .gh, six under .sl, four under .as. A separate audit by the Australian outlet iTnews, which cross-referenced the public CT logs against Chrome's own blocklist, counted 32 certificates issued between 22 and 27 September, and noted several international brand names beyond Google. Because the CT logs are public and searchable but nobody searched them exhaustively for every affected organisation, the honest reading is that 32 is a floor, not a total.

Eleven of the certificates in the first pass came from Let's Encrypt and one from ZeroSSL, the Sectigo-issued free authority. iTnews reported that the attackers used wildcard certificates from both, and that a further certificate for a different major technology brand came from Cloudflare's own certificate authority — a detail that may eventually help identify the group, because Cloudflare-issued certificates require the domain to be added to a Cloudflare account.

The names recovered include google.com.gh, google.sl and google.as, plus YouTube properties. Two of the .gh certificates and the ZeroSSL certificate were revoked on 26 September. The remaining nine were revoked on 1 October.

The mechanism: control of DNS is control of the name

Almost every certificate on the public web is issued after a domain control validation check that asks a single question — can the requester demonstrate control of the name? In practice, for automated issuance, the answer is published as a token value in a DNS record, and an automated client at the certificate authority fetches it. This is the ACME HTTP-01 challenge, and it is the mechanism that made HTTPS deployable at web scale in about a decade.

It is also deliberately cheap and almost entirely automated, and that is not a design flaw. It is the design. Every certificate issued in the last decade was cheap because nobody verified a human identity or a contract. Speed and cost were the entire point.

But here is the consequence, which is rarely stated as plainly as it deserves to be: authority over a name sits exactly where authority over DNS sits. Nothing else. A domain's owner, its registrar, its hosting provider — none of them are consulted. If you control the authoritative DNS for a zone, you are, for validation purposes, the rightful owner of every name in that zone. Including the defensive registrations nobody has touched in a decade, and including names that resolve to somebody else's infrastructure.

So the attackers did not need to compromise Google. They did not need to compromise a registrar or a hosting provider or a certificate authority. They needed to compromise three operators — the organisations that hold the registries for three small nations — and then they were the legitimate owners of an entire national namespace, at least for as long as they held the DNS.

That is why the affected set runs well past Google. Any organisation holding a name under .gh, .sl or .as was in scope, including companies that registered defensive names years ago and forgot about them. Google, reviewing CT data, found other affected organisations "among them well-known global brands and widely used online services", and pushed their certificates into Chrome's blocklist too. It declined to name them.

What Chrome did, and the two gaps it admits

Chrome's response was fast and, within its own logic, correct. The browser pushed the unauthorised certificates into CRLSets, its emergency blocklist — the same mechanism used to kill certificates from misbehaving CAs like DigiNotar in 2011 and Comodo in 2013. It worked with the issuing authorities on revocation, so that clients outside Chrome would also stop trusting the certificates. It swept the CT logs for further issuance from the affected zones. And it told users plainly that they needed to do nothing: Chrome users are already protected.

Let us Encrypt confirmed the issuance on its own community forum, in a post by staff engineer Matthew McPherrin: "Yes, certificates for Google and Youtube were issued, and have been revoked."

Google is equally frank about what it could not do. It stated that it "cannot guarantee that our analysis identified every affected domain" — an admission worth sitting with, because it means the revocation list is itself an estimate. And it addressed the general lesson directly: "browser-side intervention should not be relied on to protect your users." CRLSets protect Chrome. A phone browser, an API client, a smart TV, a satellite link, a building automation controller — none of those consult Chrome's blocklist. For a hijacked namespace, the fraction of traffic that CRLSets can reach is a rounding error.

That gap is not new, but this incident is a clean demonstration of it. The defence worked. For the largest browser on the largest platform. On a set of certificates that would have been accepted by everything else.

What a domain owner can actually do

Google's advice to affected organisations was CT monitoring across the full portfolio, including parked and regional country-code names that generate no traffic and therefore attract no attention. Alongside that, restrictive CAA records — the DNS record that tells a certificate authority which of its own accounts may issue for a name, and by which validation methods.

Both are worth doing and both are worth doing now, for every name you hold, not only the ones in the three affected zones. Neither is prevention.

CAA is the weaker of the two, and Google concedes the reason: CAA cannot stop issuance while an attacker holds the DNS. If the attacker controls the authoritative zone, they control the CAA records in that zone too. CAA's value arrives afterwards — it prevents an attacker from reusing cached validation material once legitimate control has been restored, which shortens the tail of the incident rather than the incident itself.

CT monitoring is the genuinely useful control, because it is the only one that tells you about a problem rather than preventing it. Every CA is required to log every certificate it issues to public, append-only, globally replicated logs. That log is the record of what has been done in your name, including things you did not authorise. An organisation that reads its own CT entries monthly knows about an unauthorised certificate within days. An organisation that does not, learns about it when a browser warns a user.

The precedent nobody has forgotten

This technique is old. In 2012, a breach of Pakistan's PKNIC registry redirected 284 .pk domains to an attacker-controlled server, including google.com.pk and apple.pk. In 2011, the Dutch certificate authority DigiNotar was compromised and issued 531 fraudulent certificates for \.google.com in an operation researchers named Black Tulip; roughly 300,000 unique IP addresses, almost all in Iran, subsequently requested google.com with those certificates in hand.

The most instructive of the precedents came in 2019, when Cisco Talos reported on Sea Turtle, what it described as a nation-state group that hijacked domains belonging to at least 40 organisations across 13 countries — in part, Talos said, by compromising registrars and registries. Three months later Talos linked Sea Turtle to a breach of ICS-FORTH, the operator of Greece's .gr registry, and to the hijacking of three Greek government domains. Sea Turtle installed certificates from Let's Encrypt, Comodo and Sectigo on its man-in-the-middle infrastructure; Talos called the technique "certificate impersonation."

That last detail is what distinguishes the current incident from a database breach. Sea Turtle's operators combined registry access with routing control and used the certificates to sit in the middle of live traffic. There is no published evidence that anyone has done that here. Google notes that most of the hijacked names simply redirect to Google's main properties, so the absence of observed interception means less than it would for a registry whose names hosted real, distinct services. But the capability is demonstrated, it is old, and nobody has explained how the three operators were breached or whether the registries are now secure. None of the three operators has issued a statement. iTnews says it contacted all three and received no replies.

Conclusion

The uncomfortable conclusion of the ccTLD hijacks is that, during a registry-level compromise, 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. This is an accountability gap that no amount of vendor-side engineering closes, because the vulnerable component sits one level below the party that would have to fix it.

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 worth taking seriously, while being clear about what it is. It is not a fix for the hijack. It is a fix for how long a hijack keeps paying after the DNS is back. Shorter lifetimes mean a compromised registry that is cleaned up on a Tuesday stops producing trusted certificates by Wednesday. Less cached validation means an attacker who held DNS for six days cannot keep reusing validation artefacts for six weeks. Both reduce the payout window. Neither touches the window itself.

The concrete action for most organisations is smaller and more immediate: read your own Certificate Transparency entries this month, including the country-code and parked names you registered defensively and forgot. The hijacked zones were .gh, .sl and .as. The list of names nobody checks is far longer, and it is where the next one will be found.

Images

The certificate detail panel of a desktop browser displaying a Let's Encrypt certificate — the same free, automated authority that issued eleven of the twelve certificates recovered from the hijacked .gh, .sl and .as zones. Illustrative image: it is an unrelated, valid certificate, not one of the attacker-issued records.

An ICANN general meeting. The ccTLD registries are not operated by ICANN but by separate national or regional registries, often as third-party operators — precisely the layer that was compromised here. Illustrative image of an unrelated meeting.

References

• 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 hijack ccTLDs to fake certs for Google — iTnews
• 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
• Certificate Authority Compromise Leads to Rogue Certificates (Operation Black Tulip) — Google Security Blog
• Misha Ageev, Cisco Talos research on Sea Turtle — Cisco Talos