DNS hijacks at three ccTLDs led to fake Google certificates

On October 6, Google disclosed that attackers had compromised the registries of three country-code top-level domains (ccTLDs) to obtain unauthorized HTTPS certificates for several of its domains. The affected extensions were .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa). While Google’s internal systems remained secure, the breach allowed threat actors to impersonate Google services over encrypted connections, posing a significant risk to user data privacy.

What happened

The attackers gained control over the authoritative DNS records for domains under these three ccTLDs. By modifying these records, they demonstrated domain control to Certificate Authorities (CAs), which is the standard method for validating ownership before issuing a TLS certificate. This process allowed them to request and receive valid certificates for names such as google.com.gh, google.sl, and youtube.as. Google stated that it had no reason to believe the CAs acted improperly, as they followed standard validation procedures based on the manipulated DNS data.

Certificate Transparency (CT) logs, which serve as a public record of all issued certificates, revealed at least 12 unauthorized certificates issued between September 22 and September 27. Let’s Encrypt issued 11 of these certificates, while ZeroSSL issued one. The attacks occurred in waves, with .gh domains targeted on September 22, .sl on September 25, and .as on September 27. Google worked with the respective CAs to revoke these certificates and used Chrome’s CRLSets feature to block them within its browser. However, users of other browsers remained vulnerable until the revocations propagated globally.

Key details

• Affected Registries: The compromise involved the ccTLDs for Ghana (.gh), Sierra Leone (.sl), and American Samoa (.as).
• Certificate Count: At least 12 unauthorized certificates were issued for seven distinct Google and YouTube domain names.
• Issuing Authorities: Let’s Encrypt issued 11 certificates, and ZeroSSL issued one; all were domain-validated.
• Timeline: Certificates were logged between September 22 and September 27, with revocations occurring between September 26 and October 1.
• Detection Method: The unauthorized certificates were identified through public CT logs using services like ctlogs.dev and Cert Spotter.
• Broader Impact: Google indicated that other global brands and online services were also targeted, though specific names were not disclosed.

Background

To understand this incident, it is helpful to know how TLS certificates are issued. CAs rely on Domain Validation (DV) to confirm that the requester controls the domain. This is often done by checking for a specific record in the domain’s DNS settings. If an attacker compromises the DNS registry, they can insert these validation records, tricking the CA into issuing a certificate. Once issued, this certificate allows the attacker to create a convincing, encrypted clone of the legitimate site, enabling man-in-the-middle attacks where user data can be intercepted.

Certificate Transparency (CT) logs were introduced to mitigate such risks by making all certificate issuances public. This allows domain owners and security researchers to monitor for unauthorized certificates. Additionally, CAA (Certification Authority Authorization) records allow domain owners to specify which CAs are permitted to issue certificates for their domains. While CAA records can prevent unauthorized issuance from non-listed CAs, they are ineffective if the attacker has full control over the DNS and can remove or alter the CAA record itself.

Why it matters

For teams that self-host software or manage their own domains, this incident underscores the fragility of trust in the DNS ecosystem. Even if your internal infrastructure is secure, a compromise at the registry level can lead to unauthorized certificates being issued for your domains. This means that relying solely on the presence of a valid HTTPS lock icon is no longer sufficient to guarantee site authenticity. Self-hosters must actively monitor for unexpected certificate issuances to detect potential hijacks early.

Furthermore, the response time for revocation varied significantly, with some certificates remaining valid for nearly a week after detection. During this window, users visiting the spoofed sites could have had their data exposed. For IT managers, this highlights the importance of having independent monitoring systems that do not rely on browser vendors to protect users. Proactive detection through CT log monitoring can reduce the window of exposure and allow for faster reporting and revocation.

What you can do

• Monitor CT Logs: Set up automated alerts for any new certificates issued for your domains using CT log monitoring services. This includes parked domains and regional ccTLD variations.
• Implement CAA Records: Publish strict CAA records in your DNS to restrict which CAs can issue certificates for your domains. Ensure these records are tied to your specific CA account where possible.
• Review DNS Security: Audit your domain registrar and DNS provider security settings. Enable multi-factor authentication and review access logs for any unusual activity.
• Report Unauthorized Certificates: If you detect an unauthorized certificate, file a Certificate Problem Report with the issuing CA immediately. They are required to investigate and respond within 24 hours.
• Check Regional Domains: If you operate in or have domains under .gh, .sl, or .as, review recent CT log entries specifically for these extensions to ensure no unauthorized certificates were issued.
• Educate Users: Inform your users that browser-based protections may not be immediate. Encourage them to verify URLs carefully and report any suspicious behavior.