Hackers Compromise Country-Code Top-Level Domains to Obtain Fraudulent HTTPS Certificates for Google and YouTube

In a sophisticated and alarming cyber incident, malicious actors successfully compromised three country-code top-level domains (ccTLDs), enabling them to acquire unauthorized HTTPS certificates for several high-profile Google and YouTube web properties. Google disclosed the security breach, emphasizing that while its internal corporate infrastructure and core systems remained entirely uncompromised and secure, the integrity of multiple regional domains was temporarily undermined by the registry-level attacks.

The affected top-level domains included .gh for Ghana, .sl for Sierra Leone, and .as for American Samoa. By seizing control of these regional registries, the attackers gained the technical capability to request and secure valid cryptographic certificates for domains operating beneath those extensions. With fraudulent HTTPS certificates in hand, malicious actors could theoretically orchestrate advanced man-in-the-middle attacks, posing as legitimate Google or YouTube properties over ostensibly secure, encrypted connections to intercept or examine private user data transmitted to those sites.

The Swift Response and Certificate Transparency Logs

Upon discovering the security lapse, Google moved quickly to neutralize the threat within its ecosystem. The company utilized CRLSets—its proprietary mechanism for rapidly blocking problematic or unauthorized digital certificates in emergency scenarios—to prevent the Google Chrome browser from trusting the fraudulent credentials. Simultaneously, Google collaborated closely with the certificate authorities (CAs) responsible for issuing the certificates to ensure their immediate revocation, a vital step designed to protect web users browsing via alternative platforms and third-party applications.

While Google chose not to publicly name all of the targeted domains in its initial disclosure, public records housed within Certificate Transparency (CT) logs revealed critical forensic details. Certificate Transparency functions as an open, auditable public ledger where all newly issued TLS/SSL certificates are permanently recorded to prevent the clandestine deployment of unauthorized credentials. Analysis of these public logs identified at least 12 distinct certificates issued between September 22 and September 27. These fraudulent instruments specifically covered prominent Google and YouTube regional assets, including google.com.gh, google.sl, and google.as.

Investigative security reports published by industry researchers via specialized CT search utilities, such as ctlogs.dev and Cert Spotter, corroborated the scope of the incident. The data showed that 11 of the fraudulent certificates were issued by the automated certificate authority Let’s Encrypt, while a single certificate was generated by ZeroSSL. The temporal pattern of the issuance mapped directly to the compromise of the individual regional registries: the .gh certificates appeared in the logs on September 22, the .sl assets followed on September 25, and the .as entries surfaced on September 27.

Understanding the Mechanics of the Registry Hijacks

The issuance of a domain-validated certificate typically requires the applicant to demonstrate administrative control over the target domain, a verification process frequently satisfied by adding a specific text record or token to the domain’s Domain Name System (DNS). During the course of the attacks, the perpetrators successfully altered the authoritative DNS records for the affected country-code registries. Consequently, the certificate authorities fulfilled the validation requests under the legitimate belief that the applicants held authorized control over the namespaces. Google explicitly noted that it has found no evidence of wrongdoing or negligence on the part of the certificate authorities, which followed standard validation protocols based on the manipulated DNS states.

The fraudulent instruments were exclusively domain-validated certificates, which verify domain control through automated challenges. Historically, routine certificates for these specific regional domains—such as google.com.gh, google.sl, and google.as—were predominantly issued by Google Trust Services, Google’s proprietary certificate authority. The sudden appearance of third-party issuers like Let’s Encrypt and ZeroSSL inside the public logs served as an immediate red flag for security monitors.

Representatives from Let’s Encrypt confirmed the issuance and subsequent revocation of the certificates on the organization’s community forums. Matthew McPherrin, a member of the Let’s Encrypt team, verified that certificates covering Google and YouTube assets had indeed been processed during the window of the registry hijacks and were subsequently revoked following coordinated security alerts.

Broader Implications and Remediation Efforts

Because the public investigations focused primarily on a targeted subset of prominent Google and YouTube domains, cybersecurity analysts believe the total volume of affected organizations could be significantly higher. Google’s internal analysis of the Certificate Transparency data indicated that other prominent global brands and widely utilized online services were similarly caught in the crosshairs of the same malicious campaign, though these secondary victims were not publicly identified.

Review of the certificate lifecycle logs demonstrated that remediation occurred over a period spanning late September and early October. The initial batch of .gh certificates and the ZeroSSL asset were successfully revoked on September 26, while the remaining nine certificates associated with the Sierra Leone and American Samoa namespaces were revoked on October 1. The duration between the initial logging of a fraudulent certificate and its eventual revocation ranged from roughly a day and a half to nearly a full week.

Google confirmed that it learned of the registry hijacks during the week preceding its public advisory and immediately initiated defensive measures. Beyond shielding Chrome users and urging certificate authorities to revoke the compromised assets, the tech giant reached out directly to other impacted organizations where feasible. However, the company emphasized that while browser-level blocks protect Google Chrome users, domain owners cannot rely solely on browser mitigations to safeguard their user base.

Due to the inherent complexity and labyrinthine nature of DNS architecture, security teams acknowledged that automated monitoring cannot guarantee the identification of every single compromised domain. Furthermore, standard browser-level mitigations do not provide comprehensive protection for individuals utilizing alternative web browsers or legacy applications.

Defensive Recommendations for Domain Owners

In response to the multi-tiered threat model exposed by the ccTLD hijacks, security professionals and standards bodies reiterate the necessity of robust defensive configurations for domain administrators. Chief among these recommendations is the implementation of strict DNS Certification Authority Authorization (CAA) records. A CAA record allows a domain owner to declare which certificate authorities are explicitly authorized to issue digital certificates for their domain names, effectively tying the hands of unauthorized CAs even if traditional validation checks are temporarily spoofed.

While a standard CAA record cannot entirely prevent an attacker from requesting a certificate while a live DNS hijack is actively underway—since a sophisticated adversary with administrative DNS access can simply remove or rewrite the CAA record during the attack window—it provides crucial retroactive protection. Once the legitimate owner restores control of their authoritative DNS infrastructure, a strict CAA policy prevents CAs from issuing subsequent certificates based on cached domain validations.

Under current baseline requirements established by the CA/Browser Forum, certificate authorities are permitted to reuse a completed domain validation check for up to 200 days. This policy window creates a dangerous security window where an attacker who successfully passes a validation check during a brief DNS hijack can return days later to request additional valid certificates long after the initial intrusion vector has seemingly closed. Industry standards are steadily tightening this window; the permitted reuse period is scheduled to drop to 100 days by March 2027 and further decrease to just 10 days by March 2029. Major certificate authorities like Let’s Encrypt have similarly announced aggressive internal roadmaps to shrink validation reuse timelines significantly in the coming years.

Security audits conducted immediately following the October disclosures confirmed that the primary Google and YouTube domains affected by the ccTLD compromises maintained strict CAA records pointing exclusively to Google Trust Services, effectively insulating those high-value namespaces from unauthorized re-issuance attempts once normal registry operations were reestablished.