Attackers Hijack .gh, .sl, .as Domain Registries for Rogue HTTPS Certificates

Key Takeaways

• Attackers compromised the authoritative DNS records for the .gh, .sl, and .as country-code top-level domains.
• This compromise enabled the malicious actors to obtain unauthorized HTTPS certificates for Google and other prominent organizations.
• Google’s internal systems were not breached; the attack targeted third-party domain infrastructure used for certificate validation.
• Chrome automatically blocked the identified rogue certificates via CRLSets, and Google coordinated with Certificate Authorities for broader revocation.
• Organizations, especially those with .gh, .sl, or .as domains, are advised to actively monitor Certificate Transparency logs and implement restrictive Certification Authority Authorization (CAA) records.

Domain Registry Hijacks Lead to Rogue HTTPS Certificates

In a significant cybersecurity incident, threat actors successfully compromised the domain registries for Ghana (.gh), Sierra Leone (.sl), and American Samoa (.as). This breach allowed them to illicitly acquire HTTPS certificates for various entities, including Google, as well as other major brands and widely used services. Google confirmed that its Chrome browser automatically blocked these fraudulent certificates, while the company worked with Certificate Authorities (CAs) to revoke those issued for its own properties.

Google’s October 6 disclosure revealed that it became aware of these attacks in the preceding week. The compromise specifically targeted the domain endings associated with Ghana, Sierra Leone, and American Samoa, rendering any domain utilizing these extensions potentially vulnerable. However, Google did not confirm that every domain within these TLDs had been hijacked.

Google explicitly stated that its own internal systems remained unbreached throughout the incident. Furthermore, the company found no evidence of wrongdoing on the part of the Certificate Authorities that issued the affected certificates. Instead, the attackers exploited vulnerabilities within the third-party domain infrastructure upon which certificate validation processes rely.

How DNS Hijacking Facilitated Certificate Issuance

The core of the attack involved manipulating authoritative DNS records. These records are fundamental to the internet’s naming system, providing definitive answers to domain lookups. By gaining control over these records, attackers could effectively impersonate domain ownership during the critical domain control validation (DCV) checks performed by Certificate Authorities.

Domain control validation is a process designed to confirm that a certificate requester has control over a specific domain, rather than verifying the legitimate business owner. For instance, a CA might require a requester to publish a unique DNS record. An attacker who controls the domain’s DNS can fulfill this requirement, thereby passing the validation check without the actual owner’s consent.

An unauthorized HTTPS certificate can be a powerful tool for attackers aiming to impersonate trusted websites, especially if they can also redirect users to their malicious servers. It is crucial to understand that encryption alone does not guarantee security; a connection can be encrypted even when communicating with an unintended or malicious party. Google’s public statement did not specify whether these rogue certificates were actively used to intercept user traffic.

As of now, Google has not publicly identified the attackers, detailed their initial access methods, or provided a comprehensive list of all affected domains and certificates. These omissions leave the full scope and impact of the incidents largely undefined.

Chrome’s Response and Broader Implications

Google’s initial response involved blocking unauthorized certificates specifically for its domains using CRLSets, Chrome’s mechanism for rapidly revoking certificates during urgent security events. Concurrently, Google engaged with the issuing Certificate Authorities to initiate broader revocation, extending protection beyond Chrome to other clients that enforce certificate revocation.

Subsequent investigations, leveraging Certificate Transparency logs, uncovered additional rogue certificates linked to other organizations, including prominent brands and widely used services. Google promptly blocked these certificates within Chrome and notified the affected organizations where feasible. Chrome users benefit from this protection automatically, requiring no direct action on their part.

Despite these proactive measures, Google cautioned that its investigation might not have identified every compromised domain. Therefore, browser-level blocking should not be considered a substitute for diligent monitoring by domain owners. Furthermore, Chrome’s protections do not extend to users of other web browsers or applications.

Organizations are strongly advised to proactively monitor Certificate Transparency logs across their entire domain portfolio, which includes parked domains and regional website variations. Owners of .gh, .sl, and .as domains should pay particular attention to recent log entries for any certificates they did not request. Implementing alerts for suspicious certificate issuance can significantly enhance a defender’s posture.

Google also recommends the adoption of restrictive Certification Authority Authorization (CAA) records, specifying approved ACME accounts and validation methods. While CAA records cannot prevent issuance during an active DNS hijack, they can mitigate risks by preventing attackers from reusing cached validation after domain control is restored. Long-term solutions include promoting shorter certificate lifetimes and reducing validation reuse, alongside ongoing advancements in Chrome’s certificate security initiatives.

What You Should Do

• Monitor Certificate Transparency Logs: Regularly review Certificate Transparency logs for all your domains, including subdomains and parked domains, to detect any unauthorized certificate issuances.
• Implement Restrictive CAA Records: Configure Certification Authority Authorization (CAA) records to specify which Certificate Authorities are authorized to issue certificates for your domains and which validation methods are permitted.
• Review .gh, .sl, and .as Domains: If your organization owns domains with the .gh, .sl, or .as extensions, meticulously review recent Certificate Transparency log entries for any certificates you did not explicitly request.
• Stay Informed: Keep abreast of security advisories from browser vendors and Certificate Authorities regarding certificate security.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.