Attackers hijacked top-level domains, minted fake security certs for Google and other orgs

1. Executive summary

Attackers compromised the third-party operators of three country-code top-level domains, .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa), modified authoritative DNS records, and obtained unauthorised HTTPS certificates covering several Google domains and domains belonging to other unnamed organisations. Google's own systems were not breached, and Chrome blocked the suspected counterfeit certificates across the affected ccTLDs, but Google states that browser-side intervention should not be relied on and that it cannot guarantee its analysis identified every affected domain. Any EMEA financial services firm holding a domain, a parked property, or a regional brand site under .gh, .sl or .as should treat its DNS records and certificate issuance history as potentially manipulated. No CVSS score, CVE, or CISA KEV entry applies to this item; the verified reference data resolved no CVEs, so severity here is assessed on operational impact, not a scored vulnerability.

2. Regulatory framing

3. Technical analysis & attack chain

The confirmed sequence, from Google's disclosure as reported:

1. Attackers compromised the third-party operators of the .gh, .sl and .as ccTLDs. The compromise was of the registry operators, not of Google.
2. With that access, the attackers modified authoritative DNS records for domains under those TLDs.
3. The attackers obtained unauthorised HTTPS certificates covering several Google domains and domains belonging to other organisations.
4. Chrome identified and blocked suspected unauthorised certificates across the affected ccTLDs during the incidents. Google states Chrome users are already protected.
5. Google states it has no reason to believe the certification authorities that issued the impacted certificates did anything wrong.

The mechanism matters more than the specific domains, which Google did not name. Control of the authoritative DNS records lets an attacker redirect a correct URL to an illegitimate copy. Because the attacker also holds the private key for the unauthorised certificate, the impersonated site presents a valid TLS chain and the browser raises no security alert. The attacker then controls both the traffic routing and the key, so traffic to the impersonated site can be intercepted or modified, and the trusted organisation's brand can be used to distribute malware or run phishing. This is the operational risk: a user typing the correct address, or following a correct link, reaches attacker-controlled content without a certificate warning.

Google's stated limits are the part defenders should act on. Browser-side blocking should not be relied on to protect users. Google says it cannot guarantee its analysis identified every affected domain, and that Chrome interventions do not reliably protect non-Chrome users. Any organisation with a domain in .gh, .sl or .as is therefore in scope for its own review regardless of whether Google named it.

Two caveats. First, the affected domains and organisations beyond Google are unnamed in all sources; do not assume a firm is unaffected because it was not listed. Second, the account of the compromise rests on Google's disclosure as carried by The Register, Help Net Security and The Hacker News; the underlying registry-side forensic detail (how the registry operators were compromised, over what period, and by whom) is not in the source material, and no actor is named or attributed. Treat any attribution as unconfirmed.

4. Mitigation & containment

P1 (within 24 hours)

• Inventory every domain, subdomain and parked property under .gh, .sl and .as. Include regional brand sites and defensive registrations, which are the properties most often forgotten and the ones Google specifically calls out.
• Review recent Certificate Transparency log entries for each of those domains and flag any certificate the organisation did not request. This is the near real-time alert Google recommends.
• Verify current authoritative DNS records for those domains against a known-good baseline. Where no baseline exists, reconstruct one from registrar records and change history, and treat unexplained records as suspect.
• Do not rely on Chrome's blocking as the control. Confirm the firm's non-Chrome user population (Firefox, Safari, Edge, mobile browsers, API clients, and any service that pins or validates certificates) is covered by an independent check.

P2 (within 72 hours)

• Publish restrictive CAA DNS records for all domains, not only the ccTLD properties. Google's guidance is to restrict issuance to specific authorised accounts and validation methods, and to prevent attackers using cached validation state to mint new certificates after a hijack ends. Note the limit Google states: CAA does not stop issuance during an active DNS hijack, it protects the domain after DNS control is restored.
• Add continuous CT log monitoring across all domains as a standing control, with alerting routed to the team that can act on it.
• Confirm the registry operators for any .gh, .sl or .as domain are recorded in the ICT third-party inventory with a named owner, and request their incident timeline and remediation status.

P3 (within 7 days)

• Review certificate issuance and DNS change procedures for ccTLD properties against the CAA policy now published, and remove any stale validation state or cached authorisations that could be reused.
• Where the firm cannot obtain assurance from a registry operator, assess whether the domain needs to remain in that namespace, and document the decision.

5. Indicators of compromise

No indicators of compromise available in the source material. The sources name no domains, IP addresses, certificate serial numbers, hashes, or registry operator identities. Google did not disclose which specific domains or organisations were affected.

The sources do describe observable behaviours. These are not atomic indicators and are not suitable for the copyable block.

6. Detection

Insufficient indicators to author detection rules. The sources contain no distinctive strings, command-line flags, mutex names, file names, registry keys, or hard-coded values belonging to the threat. The only artefacts named are the ccTLDs .gh, .sl and .as, which are legitimate namespaces and would produce false positives across every domain in those TLDs; a rule built on them would detect the namespace, not the attack. Detection for this item is behavioural and log-based, as set out in §5: CT log monitoring for unexpected issuance, and DNS change monitoring against a known-good baseline.

7. Sources

• The Register, "Attackers hijacked top-level domains, minted fake security certs for Google and other orgs", https://www.theregister.com/security/2026/10/07/attackers-hijacked-top-level-domains-minted-fake-security-certs-for-google-and-other-orgs/5301718, 2026-10-07
• Help Net Security, "Hackers hijack three country-code domain registries, obtain HTTPS certificates for Google domains", https://www.helpnetsecurity.com/2026/10/07/google-unauthorized-https-certificates-cctld-hijacks/, 2026-10-07
• The Hacker News, "Attackers Hijack .gh, .sl, and .as Registries to Obtain Certificates for Google Domains", https://thehackernews.com/2026/10/attackers-hijack-gh-sl-and-as.html, 2026-10-07

8. Adverse Trace position

We assess this as a high operational-impact, low-technical-complexity incident for any EMEA financial services firm with a presence under .gh, .sl or .as, and as a monitoring obligation for firms without one. There is no CVE, no CVSS score and no CISA KEV entry for this item, so the risk is not a patchable vulnerability: it is trust in DNS resolution and certificate issuance for the firm's own domains, which the firm does not fully control. The single most important fact is Google's own statement that it cannot guarantee its analysis identified every affected domain and that browser blocking does not reliably protect non-Chrome users, which means absence from Google's disclosure is not evidence of safety. The attribution is unconfirmed; no actor is named in any source and the registry-side compromise method is not described. We will monitor Certificate Transparency data and registry operator statements for the .gh, .sl and .as namespaces, and we will update this advisory if Google or the affected registries publish the domain list or a root cause. Clients should treat the P1 inventory and CT log review as the immediate action, and should not wait for a named-domain list before checking their own properties.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.