Attackers Compromise Three ccTLDs to Obtain Unauthorized HTTPS Certificates for Google Domains

In a sophisticated cyber incident highlighting the vulnerabilities inherent in global domain name infrastructure, attackers successfully compromised three country-code top-level domains (ccTLDs) to obtain unauthorized HTTPS certificates for several high-profile Google and YouTube domains. Google disclosed the security breach, confirming that while its internal corporate infrastructure remained entirely secure and unbreached, any web traffic directed through domains ending in .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa) was exposed to potential interception and decryption risks.

The acquisition of unauthorized cryptographic certificates represents a severe security threat in modern web infrastructure. With a valid HTTPS certificate matching a major target domain, a malicious actor is theoretically positioned to execute adversary-in-the-middle attacks. This enables them to masquerade as the legitimate service over an encrypted connection, potentially allowing them to inspect, manipulate, or steal private data transmitted by unsuspecting users.

Upon detecting the unauthorized certificate generation, Google moved swiftly to mitigate the threat. The company utilized CRLSets—its specialized emergency mechanism for rapidly distributing blocks for compromised or untrusted certificates—to actively block the illegitimate credentials within the Google Chrome browser. Simultaneously, Google coordinated directly with the certificate authorities (CAs) responsible for issuing the documents to ensure their immediate revocation, a crucial step designed to extend protection to users navigating the web via alternative browsers and applications.

Although Google opted not to publish a comprehensive list of all impacted domains, a thorough examination of public Certificate Transparency (CT) logs revealed extensive activity. CT logs serve as an append-only public record where all newly issued TLS/SSL certificates must be registered, providing security researchers and organizations with visibility into certificate issuance patterns. According to records compiled via CT search engines such as ctlogs.dev and Cert Spotter, at least 12 distinct certificates were issued between September 22 and September 27 for core Google and YouTube properties operating under the compromised ccTLDs, including prominent assets such as google.com.gh, google.sl, and google.as.

The mechanics of how these unauthorized certificates were generated point to external manipulation of domain control validation rather than any systemic failure on the part of the certificate authorities. Typically, a CA issues an SSL/TLS certificate only after the applicant successfully demonstrates administrative control over the target domain, commonly verified by modifying Domain Name System (DNS) records or placing a specific challenge file on a web server. In the course of these recent incidents, attackers successfully altered authoritative DNS records during the registry hijacks, effectively tricking automated validation systems into believing they possessed legitimate authority over the ccTLD namespaces. Consequently, Google emphasized that it has no reason to suspect any procedural negligence or wrongdoing by the CAs involved in issuing the certificates.

What Certificate Logs Show

Security analysis conducted by The Hacker News and verified through public monitoring tools brought the scope of the incident to light. The investigative findings indicated that the 12 unauthorized certificates spanned seven distinct domains. Among the issuing authorities, Let’s Encrypt accounted for 11 of the fraudulent certificates, while ZeroSSL issued one.

The timeline extracted from the CT logs demonstrates a methodical, staggered execution by the attackers, targeting one ccTLD registry at a time over a multi-day window. The compromise of the .gh registry manifested first, with certificates appearing in the logs on September 22. This was followed by the .sl registry on September 25, and finally the .as registry on September 27. Every single one of these 12 credentials was classified as a domain-validated certificate, issued subsequent to standard automated checks confirming domain control. Historical records reviewing domain configurations dating back to at least September 10 confirmed that legitimate prior certificates for these specific regional extensions were consistently issued by Google Trust Services, Google’s proprietary CA.

Public statements from issuing organizations corroborated the timeline of discovery and remediation. Matthew McPherrin, a staff member at Let’s Encrypt, addressed inquiries on the organization’s community forum, explicitly confirming that certificates for Google and YouTube properties were indeed generated during the registry hijacks and had subsequently been revoked.

While the public investigation focused primarily on a narrow subset of Google and YouTube assets, analysis of the broader Certificate Transparency data suggested that the campaign was not exclusively tailored to Google. The logs pointed toward several other prominent organizations, including well-known global brands and widely utilized online services, that Google believes were caught in the crosshairs of the same coordinated attacks, though those entities were not publicly identified.

What the Response Covers

Tracking data from Cert Spotter demonstrated that rapid remediation efforts were enacted following the discovery of the certificates. All 12 unauthorized credentials were successfully revoked by early October. Specifically, the two certificates associated with the .gh domain and the single ZeroSSL certificate tied to .sl were revoked on September 26, while the remaining nine Let’s Encrypt certificates were neutralized on October 1.

The duration between the initial appearance of a certificate in the public logs and its eventual revocation varied, with the shortest interval spanning approximately a day and a half, and the longest stretching to nearly a full week. The first .as certificate entered the logs on September 27, roughly 24 hours after the .gh certificates had already been successfully revoked.

Google reported that it became aware of the domain hijacks the week prior to its public advisory and initiated immediate countermeasures. However, the tech giant refrained from disclosing precise dates regarding when the underlying registry compromises occurred or when its own defensive actions were finalized. In addition to securing its own properties, Google utilized Chrome’s blocking mechanisms to mitigate the risk posed by certificates discovered for other third-party organizations, reaching out directly to affected entities wherever feasible.

Reassuring Chrome users, Google noted that individuals browsing the web require no manual intervention on their part. Nevertheless, the company stressed that domain owners should not rely exclusively on web browsers to protect their user base from sophisticated infrastructure-level attacks. Because DNS hijacks involve complex, external points of failure, the Chrome Secure Web and Networking Team explicitly stated that their analysis could not guarantee the identification of every single affected domain, cautioning that browser-level blocks do not offer uniform protection across different software ecosystems.

Google’s disclosures intentionally omitted specific operational details, such as whether any of the fraudulent certificates were actively deployed in live attacks to impersonate Google infrastructure or harvest user data. Furthermore, the company did not name the threat actors behind the operations, outline the exact vector used to compromise the country-code top-level domain registries, or confirm whether the underlying vulnerabilities at the ccTLD registries had been fully remediated.

What Domain Owners Should Do

In the wake of the incident, security experts and Google outlined vital defensive measures for domain administrators aiming to harden their infrastructure against similar campaigns. A primary recommendation centers around the implementation of CAA (Certification Authority Authorization) records within the Domain Name System.

A CAA record allows domain owners to declare explicitly which certificate authorities are authorized to issue certificates for their domains. While a standard CAA record cannot inherently prevent a certificate from being issued while a DNS hijack is actively underway—since a sophisticated attacker possessing administrative control over the DNS can simply remove or overwrite the record—the setting plays a critical defensive role once rightful ownership is restored.

Under standard operating procedures, certificate authorities are frequently permitted to reuse a completed domain validation check for subsequent certificate issuance requests over a specified window of time. Consequently, an attacker who successfully passes validation during a temporary hijack could potentially exploit that cached validation to request additional certificates after the primary intrusion has ended and domain control has been recovered. Maintaining a strict CAA record effectively blocks such subsequent attempts by restricting issuance exclusively to trusted, organization-owned certificate authorities.

The governance standards established by the CA/Browser Forum—an industry body comprising certificate authorities and browser vendors—historically permitted CAs to reuse domain validation checks for up to 200 days. However, regulatory tightening has accelerated security timelines. Under an updated schedule approved by the forum, the maximum allowable validation reuse window is slated to decrease to 100 days, with further reductions planned for future years. Individual issuing authorities have also moved proactively; Let’s Encrypt, which issued the vast majority of the unauthorized certificates in this incident, announced plans to significantly shorten its validation reuse periods to minimize the operational window available to malicious actors following a transient domain control compromise.

Verifying current infrastructure security configurations revealed that the targeted domains have since been reinforced. Independent technical checks confirmed that Google Public DNS successfully returned strict CAA records for the impacted domains on October 7, pointing exclusively to pki.goog, the designated domain infrastructure managed by Google Trust Services. Security analysts and system administrators continue to monitor public Certificate Transparency logs using cryptographic fingerprints to ensure complete visibility and rapid detection of any future unauthorized credential generation attempts across global top-level domains.