Google domains hijacked via ccTLD registry breach: the identity lesson in DNS trust

Updated 8 October 2026. This briefing separates what has been confirmed from what has only been claimed, and will be updated as the facts develop.

Google has disclosed that attackers compromised third-party operators of three country-code top-level domain (ccTLD) registries, covering .GH (Ghana), .SL (Sierra Leone) and .AS (American Samoa), and modified authoritative DNS records for domains within them. Using that control, the attackers obtained unauthorized HTTPS certificates for several Google domains and domains belonging to other organisations, allowing them to impersonate legitimate brands and serve arbitrary content to visitors without triggering browser warnings.

Google says its own systems were not compromised at any point and that it has no reason to believe the certificate authorities that issued the fraudulent certificates acted improperly. The company blocked the unauthorized certificates for its own properties in Chrome using CRLSets, an emergency revocation mechanism, and worked with the issuing CAs to revoke them. Reviewing Certificate Transparency (CT) logs afterwards, Google found additional certificates it believes are linked to the same attacks, affecting what it describes as several leading global brands and widely used online services. It has blocked those in Chrome too and notified affected organisations where it could identify them.

Google has been explicit that its mitigation is incomplete. It warns that, given the complexity of DNS hijacks, it cannot guarantee its analysis caught every affected domain, and that Chrome's blocking does not protect users of other browsers. Neither BleepingComputer nor The Register report has named the attackers, the number of certificates confirmed hijacked, or the full list of affected organisations.

What is confirmed, and what is not

• Confirmed: attackers compromised third-party operators of the .GH, .SL and .AS ccTLD registries and altered authoritative DNS records.
• Confirmed: unauthorized HTTPS certificates were obtained for several Google domains and for domains of other, unnamed organisations.
• Confirmed: Google's own internal systems were not breached; the attack worked entirely through the DNS and certificate issuance chain outside Google's control.
• Confirmed: Google used Chrome's CRLSets mechanism to block the fraudulent certificates for its own properties and has since blocked further certificates found via CT log review.
• Confirmed: Google has no reason to believe the issuing CAs acted improperly, meaning the certificate authorities followed normal validation steps that were subverted by the DNS hijack itself.
• Not confirmed: the identity of the attackers, their motive, or the total scale of hijacked domains and certificates. Google has not published these details.
• Not confirmed: whether every affected domain has been identified. Google states this explicitly as a limitation of its own investigation.
• Not confirmed: any specific harm to end users, such as credential theft or malware delivery, resulting from the impersonation. Neither source reports a confirmed downstream compromise.

The identity angle

This incident is a textbook case of machine identity failure sitting above the layer most organisations monitor. A TLS certificate is, in effect, a credential that asserts "this domain is who it claims to be." Normally that assertion depends on domain validation through DNS, which in turn depends on the integrity of the registry that holds the authoritative records. When attackers compromise the registry operator rather than the certificate authority or the domain owner, they can satisfy a CA's validation checks legitimately, because from the CA's point of view the DNS evidence is genuine. The weak identity here is not a user account or an employee credential; it is the domain itself, and by extension every certificate that domain is entitled to hold. Any organisation with a presence, parked or active, in a compromised ccTLD inherits this exposure regardless of how well its own internal identity controls are run. Human identities are a secondary concern in this specific incident; the primary casualty is trust in domain-level machine identity, the kind that underpins every HTTPS connection, API call and federated login that depends on a trusted domain name.

What to check this week

1. Inventory every domain your organisation holds, including parked, legacy and regional ccTLD domains that nobody actively manages day to day.
2. Set up continuous monitoring of Certificate Transparency logs across that full domain portfolio, not just your primary production domains.
3. Publish restrictive Certification Authority Authorization (CAA) records on every domain, limiting issuance to specific authorised CAs, accounts and validation methods.
4. Treat CAA as a post-incident safeguard, not a real-time defence; understand it cannot stop certificate issuance during an active DNS hijack but does prevent abuse of cached validation once control is restored.
5. Review any domains you hold in .GH, .SL or .AS specifically, and check recent CT log entries for unexpected certificate issuance.
6. Confirm your incident response plan includes a path for rapid certificate revocation requests to your CAs, separate from your normal change process.
7. Do not rely on Chrome's CRLSets or any single browser's blocking as your protection; assume users on other browsers remain exposed until certificates are formally revoked.

The takeaway

This is not a Google breach; it is a demonstration that domain trust can be subverted from above the organisation entirely, through registries that most security teams never think to monitor. The practical defence is visibility: know every domain you hold, watch the CT logs for all of them, and lock down CAA records before an attacker needs you to.

If you would like a second pair of eyes on your exposure, get in touch.