Threat intel

Google disclosed on October 6 that attackers had compromised the third-party operators running three country-code top-level domains (ccTLDs): .gh for Ghana, .sl for Sierra Leone and .as for American Samoa. They changed the authoritative DNS for chosen domains under those endings and used that control to obtain browser-trusted HTTPS certificates for several Google domains and for domains of other organisations, which Google describes only as leading global brands and widely used online services. Google says its own systems were not breached and that it has no reason to think the certificate authorities (CAs) that issued the certificates did anything wrong.

Chrome now blocks the certificates and the CAs have revoked them, so Chrome users are covered for the certificates Google found. Google itself says it cannot guarantee it found every affected domain, and its blocks do not protect other browsers, apps or embedded clients. If your organisation owns any name under .gh, .sl or .as, including parked or regional domains nobody looks at, check it now.

How it works

A registry runs the zone for a whole top-level domain. For each domain under it, the registry publishes NS records (the delegation that says which nameservers answer for that domain) and, for domains signed with DNSSEC, a DS record that ties the domain's signing key to the chain of trust. Whoever controls the registry zone decides where every resolver on the internet goes to ask about every domain under that ending. According to the reporting, the attackers changed authoritative records and nameserver delegations for selected domains in all three namespaces.

That is enough to pass domain validation (DV), the check a CA runs before it issues a certificate. With ACME, the protocol Let's Encrypt and ZeroSSL use, the CA asks the applicant to prove control in one of two common ways: publish a TXT record at _acme-challenge.<domain> (dns-01), or serve a token at http://<domain>/.well-known/acme-challenge/ (http-01). Both start with a DNS lookup. Once the delegation points to the attacker's nameservers, the CA's lookups reach the attacker, the challenge succeeds, and the CA has behaved correctly by its own rules. CAs now check from several network locations to catch routing tricks near a single vantage point, but a change made at the authoritative source looks the same from everywhere.

A certificate alone does nothing. To use it, the attacker still has to get victims' traffic to a server they control, for example by keeping the DNS redirect live or by sitting on a network path. Public reporting has not established whether any traffic was intercepted.

What attackers did

Certificate Transparency (CT) logs, the public append-only logs where CAs must record every certificate they issue, show the activity ran from September 22 to 27, with the attackers working through one namespace at a time. Google said it learned of the hijacks the week before its disclosure. It has not said how the registry operators were compromised, who is behind it, or how many certificates were issued, and iTnews reported that the registry operators did not respond before publication.

The counts differ between outlets, and neither is an official total:

• The Hacker News found at least 12 unauthorised certificates for Google and YouTube names, 11 from Let's Encrypt and one from ZeroSSL. All 12 showed as revoked in CT search tools by October 7.
• iTnews compared CT logs with Chrome's blocklist and counted 32 certificates issued to the attackers between September 22 and 27, covering other brands as well. These included wildcard certificates from Let's Encrypt and ZeroSSL, and one from Cloudflare's CA for a domain linked to another large technology company. CircleID notes this figure has not been independently reproduced.

Google blocked the certificates for its own properties through CRLSets, a list of revoked certificates Chrome downloads in the background, and asked the issuing CAs to revoke them so that other browsers and clients are covered once they check revocation. It then searched CT logs for more certificates from the same campaign, blocked those in Chrome as well, and contacted the affected organisations where it could.

What to do

1. Check any .gh, .sl and .as domains you hold

List every domain your organisation owns under these endings, including marketing, redirect and defensively registered names. For each one, search CT logs (crt.sh accepts a query such as %.example.com.gh to include subdomains) for certificates issued from September 22 onwards by a CA or ACME account you do not use. Then confirm the delegation is back to your nameservers: dig +trace NS example.com.gh shows the NS records the registry is publishing. If you sign the zone, compare the DS record too, since an attacker at the registry could change it.

If you find a certificate you did not request, ask the issuing CA to revoke it, report it to the registry, and treat any traffic to that name during the window as potentially intercepted: rotate credentials and session tokens for services reachable under it.

2. Monitor CT for your whole portfolio

Google asks domain owners to monitor CT logs continuously across their entire portfolio. Use a CT monitoring service (Cert Spotter and many attack surface tools offer this) for all apex domains and alert on any issuer outside your list. Include parked and regional registrations, which are the ones most likely to change without anyone noticing.

3. Publish restrictive CAA records with an account binding

A CAA record tells CAs which of them may issue for a domain. Google recommends going further with RFC 8657, which lets a record name the specific ACME account and validation methods allowed, for example 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/<your-id>". Be clear about its limit: CAA lives in the same DNS the attacker controls during a hijack, so it cannot stop issuance while the hijack lasts. It matters afterwards. CAs may reuse a completed validation for up to 200 days under the CA/Browser Forum rules in force since March 15, 2026, and an account binding stops an attacker from turning a validation cached during the hijack into new certificates once you have DNS back.

4. Know what DNSSEC and registry lock do and do not cover

DNSSEC signs your zone so resolvers and CAs can detect forged answers, and registry lock makes the registry refuse delegation changes until you confirm them out of band. Both are worth having against the more common attacks: a stolen registrar login or spoofed DNS responses. Neither helps much when the registry itself is compromised, because the registry publishes both the delegation and the DS record. For critical services, avoid depending on a single ccTLD whose operator you cannot assess.

The wider lesson

A certificate for one of your names can be issued by anyone who controls the DNS above it, and that includes registries you have never assessed. Google's planned fixes, shorter certificate lifetimes and shorter validation reuse through the Chrome Root Program, shrink how long a hijack keeps paying off. The reuse limit is already scheduled to fall to 10 days by March 2029. Until then, a CT alert is often the only signal a domain owner gets that someone else holds a valid certificate for their name.

Our attack surface management work keeps an inventory of every domain you own and watches CT logs for certificates you did not order, and safeguarding and hardening covers CAA, DNSSEC and registry lock settings. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

---

Sources: Google: Chrome's response to recent ccTLD registry hijacks, BleepingComputer, The Hacker News, Infosecurity Magazine, Help Net Security, iTnews, CircleID, SecurityWeek, Hardware Busters, TechJuice, Privacy Guides, DigiCert on validation reuse changes.