Attackers Hijacked the .gh, .sl and .as Country Domains and Minted HTTPS Certificates for Google

Google says attackers compromised the .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa) country-code top-level domains and used that control to obtain HTTPS certificates for several of its domains and for other organizations’ sites. Google’s post, published on October 6, does not say which domains were hit or how many certificates were issued. Public records fill in part of that gap: Certificate Transparency logs and certificate authority revocation data show six certificates for Google’s own names in the three namespaces, first logged between September 22 and September 27 and all since revoked.

On October 7 the .as registry added a first-hand account. It said an unauthorized party “gained access to the AS Domain Registry (.as) back-end system and altered the designated DNS (nameservers) of eight .as domains,” and that the changes were used to obtain TLS certificates for some of the affected domains “without the registrants’ authorization.”

What Google and the .as registry have said

Google’s post from the Chrome Secure Web and Networking Team says attackers “modified authoritative DNS records and obtained unauthorized HTTPS certificates covering several Google domains, as well as domains belonging to other organizations.” It adds that the incidents “did not involve a compromise of Google’s systems” and that the company has “no reason to believe the Certification Authorities (CAs) that issued the impacted certificates did anything wrong.”

Chrome blocked the certificates for Google properties through CRLSets, which Chromium’s documentation calls “the primary means by which Chrome quickly blocks certificates in emergency situations,” and Google worked with the issuing CAs to get them revoked. Certificate Transparency (CT) data then “revealed additional organizations, including several leading global brands and widely used online services,” and Chrome blocked those certificates too. Google also warns that it “cannot guarantee that our analysis identified every affected domain, nor do Chrome interventions reliably protect non-Chrome users.” Coverage by BleepingComputer, The Register and Ars Technica repeats those points, and none of it names the attackers, the specific affected domains or how many certificates were issued.

The .as registry’s statement is more specific about its own side. It says the unauthorized changes were identified “within hours of being made” and that the correct delegations were restored, that the response team “isolated the compromised system, rebuilt the affected infrastructure and closed the point of entry,” and that the analysis so far has identified eight affected domains, two of them held by the registry itself and not in active use. The registry says it is working with certificate authorities to revoke unauthorized certificates and that its investigation “is continuing with the provider of our registry software.” It does not name that provider. It also says nothing about the .gh or .sl registries, whose sites showed no incident notice when I checked on October 8.

What the public record shows for Google’s own names

On October 8 I searched the Cert Spotter Certificate Transparency database for google.com.gh, google.com.sl and google.as. Each search returned 192 certificates from Google Trust Services, Google’s own CA. It also returned six certificates from other CAs: one from Let’s Encrypt for the Ghana name, one from Let’s Encrypt and one from ZeroSSL for the Sierra Leone name, and three from Let’s Encrypt for the American Samoa name. A second pass that included subdomains and started at the first of those certificates found no further certificates from other CAs. Let’s Encrypt certificates carry a start-of-validity time about an hour earlier than the moment they were logged, so the table uses the log timestamps embedded in each certificate. I checked revocation against Let’s Encrypt’s published CRLs and, because the ZeroSSL certificate has no CRL pointer, against the OCSP responder named in the certificate itself.

Four things stand out.

The namespaces fell in order. The first certificate for each namespace was logged in the order Google lists them: .gh on September 22, .sl on September 25 and .as on September 27. That fits attackers working through the registries one after another, although the logs show only when certificates were issued, not when each delegation was changed.

The requests look automated. The two .sl certificates were logged one second apart, which fits a single tool requesting certificates from both CAs at once. The three .as certificates were logged over about 44 minutes, which implies the attacker’s name servers were answering for google.as for something like that long.

Three wildcards point to DNS validation. Three of the six certificates are wildcards. Let’s Encrypt’s FAQ is explicit: “Wildcard issuance must use the DNS-01 challenge.” That challenge proves control by publishing a TXT record under the name. For those three, the attacker’s servers must have answered for the validation record, which matches the pattern Google describes of altered authoritative DNS.

Revocation lagged the hijack. The .as registry says it caught the changes within hours, but the certificates stayed valid for days: between 1.4 and 6.6 days passed from logging to revocation, and each certificate had roughly 90 days of validity ahead of it when it was issued. Restoring DNS does not undo a certificate that was already issued. The CAs also recorded different reasons: Let’s Encrypt’s CRLs list cessationOfOperation for all five of its certificates, while the ZeroSSL OCSP response says privilegeWithdrawn. Those codes are coarse and do not say who asked for revocation. Google’s post says it became aware of the hijacks “last week”; the earliest revocation here is dated September 26, ten days before the post.

These records cover only Google’s own names. Cert Spotter’s free tier refuses searches of a whole country domain, so I could not enumerate the other organizations’ certificates that Google mentions, and a certificate in the logs shows that it was issued, not that anyone was served it.

Why the usual defenses did not stop it

CAA. A Certification Authority Authorization (CAA) record tells CAs who may issue for a domain. Today google.com.gh, google.com.sl and google.as all publish 0 issue "pki.goog", the record Google’s documentation gives for authorizing Google Trust Services, and they point to Google’s own name servers (checked through Google Public DNS on October 8). Yet Let’s Encrypt and ZeroSSL issued. If the same record was in place in September, those CAs did not see it, which fits their validation and CAA lookups going to whichever servers the delegation pointed to at the time. Google’s post says as much: CAA “can not prevent certificate issuance during an active DNS hijack.”

Multi-perspective validation. The CA/Browser Forum’s Baseline Requirements have CAs corroborate domain validation and CAA checks from several network vantage points before issuing, a process they say “can improve protection against equally-specific prefix Border Gateway Protocol (BGP) attacks or hijacks.” That is a defense against routing attacks. If the delegation itself points at the attacker’s servers, every vantage point is sent to the same place and sees the same answers.

Reused validation. Google notes that “CAs are permitted to cache and reuse completed domain control validation (DCV) checks for subsequent issuance.” The Baseline Requirements cap that reuse at 200 days for certificates issued between March 15, 2026 and March 15, 2027, at 100 days from March 15, 2027, and at 10 days from March 15, 2029. Under those rules a validation won during a hijack could in principle be reused for months unless a CA is stricter than the cap or a CAA record forbids the request.

CAA with account binding. This is where the record helps. RFC 8657 defines CAA parameters that name specific CA accounts and validation methods, and Let’s Encrypt’s documentation says the account parameter exists so that “someone who temporarily hijacks your domain, but doesn’t have access to your ACME Account key, can’t issue malicious certificates.” Google’s post makes the point for after the hijack ends: restoring such a record stops an attacker from using cached validation to mint new certificates. The record Google serves for these three names today is the CA-only form, with no account or validation-method parameters.

DNSSEC. A signed zone vouches for whatever its operator publishes, so it cannot flag a delegation changed inside the registry’s own back end. The three namespaces also differ in whether they are signed: as of October 8 the root zone carries no DS record for .gh or .sl, so validation has no chain of trust to follow beneath them, while .as has one (key tag 46004). IANA’s root zone database records for the three delegations were last updated on 2023-12-11 (.gh), 2021-10-08 (.sl) and 2026-08-04 (.as), all before the incident, which fits Google’s description of a compromise inside the ccTLD operators rather than at the root.

A familiar pattern, with no named actor

Cisco Talos described a similar playbook in 2019 under the name Sea Turtle. It called that campaign “the first known case of a domain name registry organization that was compromised for cyber espionage operations” and described “certificate impersonation,” in which attackers obtain a certificate for the victim’s domain from a different provider than the one the victim normally uses. Talos named Let’s Encrypt and Comodo as examples. Nothing in the public record ties the current incidents to that campaign, and Google names no actor.

What is still unknown

Google has not said who is behind the hijacks, which other organizations were affected or how many certificates were issued. The .as registry has described an intrusion into its back-end system but not how the intruder got in, and no public statement from the .gh or .sl registries turned up in my search. Whether the three registries share software is also unstated: the .as registry says its investigation is continuing with its software provider, and none of the sources says whether the other two use the same one.

What domain owners can do now

Google’s advice has two parts: monitor Certificate Transparency across “their entire domain portfolio, including parked or regional ccTLD properties,” and publish restrictive CAA records that bind issuance to specific ACME accounts and validation methods. The .as registry adds two more: check nameserver delegations and review who has access to registrar accounts. In practice that comes down to three habits.

Alert on any issuer you did not choose. Every one of the six certificates above came from a CA other than Google Trust Services, so for these names the simplest possible rule, an alert on any issuer outside your approved list, would have flagged all six as soon as they reached the logs.

Bind issuance to your own ACME account. Let’s Encrypt’s documentation shows the syntax; the account number below is its placeholder, and remember that the record only helps once DNS control is back.

example.org. CAA 0 issue "letsencrypt.org;accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890"

Compare delegations. Check the name servers your registry publishes for each domain against the ones you expect, including for parked and regional domains you rarely look at.

For background on how resolvers handle trust at the DNS root, see our piece on the root key rollover. Our Merkle Tree Certificates tutorial builds a miniature certificate authority on the same kind of Merkle tree proofs that Certificate Transparency logs rely on.