Attackers Hijack .gh, .sl, and .as Domains to Obtain Unauthorized SSL Certificates
Attackers hijacked .gh, .sl, and .as DNS to obtain unauthorized TLS certificates for Google and other organizations.
Chrome's Secure Web and Networking team disclosed on October 6, 2026 that attackers compromised authoritative DNS for the Ghana (.gh), Sierra Leone (.sl), and American Samoa (.as) country-code domains. By changing DNS records, they passed certificate domain validation and obtained unauthorized HTTPS certificates for Google properties and later other organizations, without breaching Google itself. Google blocked the certificates in Chrome using CRLSets and worked with the issuing authorities to revoke them. The report does not name the attackers, list every affected domain, or say whether the certificates were used to intercept traffic.
- Compromised .gh, .sl, and .as DNS enabled unauthorized certificate issuance.
- Google says its own systems were not breached.
- Chrome blocked the rogue certificates and issuers revoked them.
- CAA policies cannot stop issuance during an active DNS hijack.
Full article551 words · extracted from gbhackers.com · click to collapse
Attackers compromised the infrastructure of third-party country-code top-level domains (ccTLDs) for Ghana (.gh), Sierra Leone (.sl), and American Samoa (.as).
They modified authoritative DNS records to obtain unauthorized HTTPS certificates for Google domains and other organizations.
Attackers Hijack Domains
In a disclosure on October 6, 2026, Chrome’s Secure Web and Networking Team stated that these incidents did not involve a breach of Google’s systems. Instead, the attackers targeted the affected ccTLD namespaces, which put any domain using those suffixes at risk.
Google promptly blocked the unauthorized certificates for its properties in Chrome and coordinated with issuing certification authorities to revoke them. Further analysis revealed certificates linked to additional organizations, prompting broader protective measures on the browser.
The attacks exploited the relationship between DNS control and certificate issuance. Certification authorities typically verify that applicants control a requested domain before issuing certificates.
Depending on the validation method, proving control may involve publishing a specific DNS record. Consequently, an attacker controlling authoritative DNS can falsely appear to fulfill domain validation requirements without authorization from the legitimate owner.
Google emphasized that it had no reason to believe that the certification authorities issuing the affected certificates acted improperly. Instead, the disclosure identified compromised DNS infrastructure as the root cause of the trust failure.
The incident report does not specify the attackers, disclose the initial compromise method, list affected domains, or provide a total certificate count. It also does not clarify whether the certificates were used to intercept traffic or impersonate services.
Chrome implemented CRLSets to reject unauthorized certificates. Chromium describes CRLSets as its primary method for quickly blocking certificates in emergencies, rather than a complete replacement for all certificate revocation methods.
Initially, Google blocked certificates covering its own properties, and Certificate Transparency analysis later revealed additional affected organizations, including major global brands and commonly used online services.
Chrome proactively blocked those certificates and, where possible, reached out to impacted organizations. Google also coordinated with issuing authorities to ensure revocation and extend protection beyond Chrome.
Chrome users do not need to take any action to benefit from these protections. However, Google cautioned that its investigation might not have identified every affected domain, and Chrome-specific measures may not reliably protect users of other clients.
Google recommends continuous monitoring of Certificate Transparency across all domain portfolios, including parked domains and regional properties.
CT logs provide publicly auditable records, and monitoring services can alert owners when certificates or precertificates are issued for their domains. Organizations operating .gh, .sl, or .as domains should review recent entries for any unexpected certificate issuances.
Google also suggests implementing restrictive Certification Authority Authorization (CAA) policies with ACME account bindings. RFC 8657 defines the accountUri and validationMethods parameters, allowing supported CAA policies to limit certificate issuance to specific accounts and validation methods. Organizations must verify that their chosen authority supports these restrictions.
While CAA cannot prevent issuance during an active DNS hijack, restoring restrictive policies after recovery can stop attackers from exploiting cached domain-validation results to obtain additional certificates.
Google stated it would continue to advocate for shorter certificate lifetimes and reduced validation reuse across the HTTPS ecosystem.
Stops Cyber threats before impact with 21 min faster MTTR. Integrate ANYRUN’s Sandbox in your SOC.
Divya is a Senior Journalist at GBhackers covering Cyber Attacks, Threats, Breaches, Vulnerabilities and other happenings in the cyber world.