"Following our initial mitigation, Certificate Transparency (CT) log data revealed additional organizations, including several leading global brands and widely used online services, believed to have been impacted by the same attacks," Google explained.
How attackers abused ccTLD registries and DNS
Attackers gained control not by breaking into Google’s infrastructure but by compromising third‑party operators and changing authoritative DNS records for domains in several country‑code top‑level domains (ccTLDs). With control of those DNS records, the threat actor could create the DNS validation entries that Certificate Authorities (CAs) require to prove domain ownership.
The source material describes the CA verification step in concrete terms: CAs typically require a requester to publish a TXT record containing a random value supplied by the CA. By modifying authoritative DNS records, the attacker placed the required validation records, requested valid HTTPS/TLS certificates, and then pointed the hijacked domains at infrastructure they controlled. That combination — valid certificates and redirected DNS — let the attacker impersonate legitimate brands and serve arbitrary content from the affected domains.
Affected ccTLDs: .GH, .SL, and .AS
Google identified that the attacks touched domains within the ccTLDs for Ghana (.GH), Sierra Leone (.SL), and American Samoa (.AS). The company underlined that the incident "affected domains of other organizations in the .GH, .SL, and .AS ccTLDs" and "did not involve a compromise of Google’s systems." The initial breach vector, as reported, was the compromise of third‑party ccTLD operators and the subsequent modification of authoritative DNS records.
The cyber insurance questionnaire just landed. Now what?
SOC 2, HIPAA, insurance renewals - someone has to own security strategy. Nubivance provides fractional CISO leadership without the full-time salary.
Get a security leadGoogle's response: CRLSets, CT logs and revocations
Google took immediate technical and investigative steps. The company blocked the unauthorized certificates for its properties in Chrome through CRLSets — an "emergency mechanism" designed to allow quick blocking of selected revoked or untrusted HTTPS certificates — and worked with the issuing authorities to revoke the certificates, extending protection to other clients. After examining Certificate Transparency logs, Google identified additional certificates that appeared connected to the attacks, proactively blocked those certificates in Chrome, and notified affected organizations where possible.
Chrome users, Google said, do not need to take action to be protected by these mitigations. The company cautioned, however, that its analysis might not have identified every affected domain and that CRLSets only covers Chrome users; "Chrome interventions reliably protect non‑Chrome users," Google warned, they do not.
Guidance for domain owners: CT monitoring and CAA records
Google urged domain owners to monitor Certificate Transparency logs across their entire domain portfolios, explicitly including parked domains. The company also recommended publishing restrictive Certification Authority Authorization (CAA) DNS records to limit issuance to authorized ACME accounts and to specified validation methods.
Google clarified the limits of those measures: CAA records cannot stop certificate issuance during an active DNS hijack, because the attacker can complete validation while in control of DNS. However, CAA records can prevent obtaining additional certificates via cached validation after legitimate DNS control has been restored, thereby reducing the risk of follow‑on issuance once an incident is remediated.
Separately, Google said it has "no reason to believe that the issuing CAs acted improperly." The announcement did not name the attackers or quantify how many certificates were confirmed to have been hijacked.
What this means for technologists and security teams, affected enterprises, and end users
- Technologists and security teams: The event highlights the value of continuous CT log monitoring across every registered name, including parked and rarely used domains, and the tactical use of CAA records to limit future issuance once DNS control is restored.
- Affected enterprises and procurement leaders: Where Google was able to identify impacted organizations, it notified them. Enterprises should expect to coordinate with registries and issuing CAs and to verify DNS and certificate inventories for signs of unauthorized issuance.
- End users and the general public: Chrome users received automatic protection via CRLSets and do not need to act; users of other browsers may not be protected by Chrome’s interventions and thus remain potentially exposed to certificates that Chrome has blocked.
The incident illustrates a simple but powerful reality: control of authoritative DNS records can be turned into trusted HTTPS certificates, and that combination can be used to impersonate legitimate services. Google’s mitigations secured Chrome users and blocked identified certificates, but the company acknowledged it may not have found every affected domain and did not identify the attacker or the total number of hijacked certificates. Domain owners, registries, and CAs will now be left to address the remaining blind spots the logs reveal and to harden validation and monitoring processes going forward.
