In an escalating wave of sophisticated internet infrastructure attacks, malicious actors successfully compromised three country-code top-level domains (ccTLDs), enabling them to acquire unauthorized HTTPS certificates for several prominent Google domains. Google disclosed the security incident, clarifying that while its own corporate systems and internal networks remained entirely unbreached and secure, the overarching integrity of domains operating under specific national extensions was severely compromised.
The targeted country-code top-level domains included .gh for Ghana, .sl for Sierra Leone, and .as for American Samoa. By hijacking the authoritative Domain Name System (DNS) records associated with these national registries, attackers were able to trick automated certificate authorities into issuing valid cryptographic credentials. Holding such a certificate allows a malicious actor to potentially impersonate the legitimate website over a fully encrypted HTTPS connection, creating a severe risk that sensitive private data transmitted by unsuspecting users could be intercepted, decrypted, or read.
Responding swiftly to the emerging threat, Google leveraged its proprietary security mechanisms to protect its ecosystem. The technology giant utilized CRLSets—its specialized emergency system designed to rapidly push updates and block compromised or unauthorized certificates within the Google Chrome browser—to intercept and invalidate the rogue credentials. Simultaneously, Google coordinated directly with the external certificate authorities responsible for issuing the unauthorized documents to ensure they were globally revoked, offering a critical layer of defense for individuals utilizing alternative web browsers and third-party software applications.
While Google refrained from explicitly listing every targeted domain in its initial public disclosure, a rigorous analysis of public Certificate Transparency logs provides deep visibility into the scale of the operation. Certificate Transparency logs serve as an essential, tamper-evident public record where all newly issued digital certificates must be registered by certificate authorities. Reviewing these public ledgers reveals that at least twelve unauthorized certificates were generated between September 22 and September 27. These credentials targeted high-profile Google and YouTube properties operating beneath the compromised national extensions, including specific domains such as google.com.gh, google.sl, and google.as.
The mechanics of how these unauthorized certificates were procured point directly to the manipulation of foundational internet protocols rather than a failure of the certificate authorities themselves. Typically, a certificate authority issues an HTTPS certificate only after the applicant demonstrates administrative control over the target domain, a verification frequently accomplished by adding specific records to the domain’s DNS configuration. During the course of these security incidents, attackers successfully altered the authoritative DNS records for the affected country-code registries. Consequently, Google emphasized that the certificate authorities acted in good faith based on manipulated validation signals, and there is no current indication that the issuers themselves were compromised or acted improperly.
Independent security researchers at The Hacker News identified the fraudulent certificates on October 7 by querying specialized Certificate Transparency search platforms, specifically ctlogs.dev and Cert Spotter. Their findings confirmed that a total of twelve certificates had been issued across seven distinct domains. Out of this total, Let’s Encrypt issued eleven of the unauthorized certificates, while ZeroSSL issued a single certificate.
The issuance timeline recorded in the public logs unfolded systematically across three distinct days, targeting one national top-level domain at a time. The campaign began with the .gh domain on September 22, shifted focus to the .sl registry on September 25, and concluded with the .as extension on September 27. Every single one of the twelve flagged credentials fell under the category of domain-validated certificates, which rely strictly on proving technical control over the domain at the time of the request. A historical review of records dating back to at least September 10 indicated that legitimate, routine certificates for google.com.gh, google.sl, and google.as are normally sourced exclusively from Google Trust Services, Google’s proprietary certificate authority.
Addressing the community regarding the incident, Matthew McPherrin, a staff member at Let’s Encrypt, verified the occurrence on the organization’s community forum on October 7. Responding to user inquiries about whether Let’s Encrypt certificates had been erroneously issued amid the registry hijacks, McPherrin confirmed that credentials for Google and YouTube had indeed been generated before being swiftly revoked.
Because security researchers and investigators focused their initial inquiries primarily on a narrow set of well-known Google and YouTube assets, industry experts believe the true scope of the attack may be significantly broader. Google itself noted that data extracted from Certificate Transparency logs strongly indicated that other prominent organizations, major global brands, and widely utilized online services were similarly caught in the crosshairs of the exact same DNS hijacking campaign, though the company chose not to publicly name the other impacted entities.
Monitoring tools and certificate tracking platforms confirmed that all twelve fraudulent certificates had been successfully revoked by early October. The two .gh certificates alongside the single ZeroSSL credential were officially invalidated on September 26, while the remaining nine certificates associated with the other extensions were revoked on October 1. The duration between the initial logging of a fraudulent certificate and its eventual revocation varied, with the shortest gap spanning approximately a day and a half and the longest stretching to nearly a week. Notably, the first .as certificate was logged on September 27, roughly one day after the unauthorized .gh certificates had already been neutralized.
Google stated that it became aware of the registry hijacks during the week preceding its October 6 public advisory and immediately initiated mitigation protocols. Although the company did not publish exact calendar dates for when the underlying infrastructure hijacks occurred or outline the precise timeline of its internal counter-operations, it confirmed that Chrome users are fully protected against these specific threats without requiring any manual intervention.
Nevertheless, security engineers cautioned that domain owners cannot rely solely on browser-level mitigations to safeguard their users. Because DNS hijacking is a deeply complex and multifaceted threat vector, the Chrome Secure Web and Networking Team acknowledged that their analysis could not definitively guarantee the identification of every single impacted domain. Furthermore, emergency blocks implemented within the Chrome browser architecture do not inherently extend protection to individuals browsing the web via alternative software applications.
To fortify infrastructure against similar attacks moving forward, security experts and browser maintainers emphasize the implementation of CAA, or Certification Authority Authorization, records. A CAA record allows domain administrators to declare explicitly which certificate authorities are authorized to issue digital certificates for their specific domain names. While a standard CAA record cannot inherently prevent a certificate from being issued while a DNS hijack is actively underway—since a sophisticated attacker capable of manipulating DNS could temporarily remove or alter the CAA record to bypass restrictions—it provides critical protection once administrative control is successfully reclaimed.
Because certificate authorities are permitted under baseline industry standards to reuse completed domain validation checks for subsequent certificate requests, an attacker who successfully passes validation during a brief hijack window could potentially request additional credentials even after the initial compromise has ended. Enforcing a strict CAA record effectively blocks these subsequent attempts by disallowing unauthorized issuers.
Industry standards governing the reuse of domain validation checks have grown increasingly stringent over time. The baseline requirements historically allowed certificate authorities to cache and reuse a domain check for up to 200 days. However, under an updated schedule approved by the CA/Browser Forum—an industry consortium comprising certificate authorities and major browser vendors—this reuse limit is slated to drop significantly to 100 days by March 2027, and further down to just 10 days by March 2029. Individual issuers have also begun adopting more aggressive timelines independently. Let’s Encrypt announced that it limits domain check reuse to 30 days and intends to reduce that window to a mere seven hours by the year 2028.
An examination of public records confirmed that all seven domains targeted in the recent incident maintained strict CAA records, with Google Public DNS returning validation configurations pointing exclusively to Google Trust Services for every affected zone. As the cybersecurity community continues to analyze the implications of these coordinated registry compromises, the incident underscores the critical importance of robust DNS security, continuous monitoring of Certificate Transparency logs, and proactive cryptographic governance across all levels of the global internet infrastructure.
