Hijacked .gh, .sl and .as ccTLDs used to get Google certificates

📌 Later developments: Node.js: ten vulnerabilities fixed, four rated high severity (October 21, 2026) · eMudhra: trivial CA keys, revocations and trust stores to update (October 20, 2026)

On 6 October 2026 Google’s Chrome Secure Web and Networking Team disclosed a series of attacks against three country-code top-level domains (ccTLDs): .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa). During the hijacks the attackers modified authoritative DNS records and obtained unauthorized HTTPS certificates for several Google domains and for domains belonging to other organizations. Google says it became aware of the attacks the week before.

There are no CVEs: the problem is not a flaw in a product, but control over name resolution upstream of the affected sites.

What happened

According to Google, its own systems were not compromised and, given the nature of the attacks, there is no reason to believe that the certificate authorities (CAs) that issued the certificates did anything wrong. Google has not said which domains were affected or how many certificates were obtained.

On how the attackers gained control of DNS, the sources stay general: Infosecurity Magazine and The Hacker News describe a compromise of the registries of the three ccTLDs, while the Google statements quoted by the press speak of hijacks with changes to authoritative DNS records, without details on the technique.

Google’s response, according to Infosecurity Magazine:

• Chrome blocked the unauthorized certificates for Google properties through CRLSets, the mechanism the browser uses to block certificates quickly in an emergency;
• Google worked with the issuing CAs to revoke the certificates, so that users of other clients would also be protected;
• Certificate Transparency (CT) logs then revealed further affected organizations, including major global brands and widely used online services: those certificates were also blocked in Chrome, and Google contacted the organizations where possible.

Technical details: why a hijacked DNS is enough

Before issuing a certificate, a CA checks that the requester controls the domain. Whoever controls the authoritative DNS records can interfere with that check and obtain a valid certificate without breaching the site’s own systems. As The Register points out, the attacker then holds both the traffic routing (via DNS) and the certificate’s private key:

1. users who type the correct address can be sent to a copy of the site;
2. the browser shows no warning, because the certificate comes from a trusted CA;
3. the attacker can intercept or modify data sent to the impersonated site and abuse the brand for phishing or malware distribution.

There is also an effect that outlasts the attack. CAs may reuse an already passed domain control validation for a certain period: according to Google, even after the owner has regained control of DNS, the attacker could exploit that cached validation to obtain new certificates.

MITRE ATT&CK (our own mapping, the sources do not give one): T1584.001 (Compromise Infrastructure: Domains) for the hijack and T1588.004 (Obtain Capabilities: Digital Certificates) for the certificates obtained.

Impact on European and Italian companies

The direct risk concerns anyone with domains under .gh, .sl or .as, including regional or defensive registrations, which are often parked and seldom watched. The lesson is general, though: trust in HTTPS depends on the security of the whole DNS chain, from the registry to the provider hosting the zone, and an upstream hijack leaves no trace on the systems of the impersonated site.

Google itself warns that browser-side intervention should not be relied on: its analysis may not have identified every affected domain, and Chrome’s blocks do not reliably protect people using other clients.

For NIS2 entities, registrars and DNS providers are part of the supply chain to be covered by risk management. A certificate issued for one of your domains without authorization is an event to analyse, including for the purpose of notifying the national CSIRT.

What to do now

1. Build an inventory of your domains, including parked ones and regional ccTLDs: you cannot monitor what you do not know about.
2. Continuously monitor CT logs for all your domains: it is how you learn, in near real time, that someone has obtained a certificate in your name.
3. If you have domains under .gh, .sl or .as, review recent CT entries right away for unexpected certificates.
4. Publish restrictive CAA records, which state which CAs may issue certificates for the domain. Google recommends also restricting them to specific ACME accounts and validation methods (the accounturi and validationmethods extensions), for example: 0 issue "ca.example; accounturi=https://ca.example/acct/123; validationmethods=dns-01". During an active hijack CAA does not block issuance, because the attacker also controls those records; once restored, however, it prevents cached validations from being reused to obtain new certificates.
5. Do not count on the browser as your only defence, especially for users and applications that do not use Chrome.

Google also said it will keep working on changes across the HTTPS ecosystem, including shorter certificate validity periods and less reuse of domain control validation.

How ARXDOME helps

ARX Expose starts from the domains declared for your company and shows their attack surface, including names and certificates, with a daily check; it also flags lookalike domains registered by others, often used for phishing. With ARX Horizon you can query indicators of compromise and the reputation of an address directly from the portal.

Last updated: 8 October 2026