- Google's October 6 disclosure, as relayed by an Akamai post, says attackers who compromised three country registries obtained 12 trusted certificates for Google and YouTube domains. Google's systems were not breached.
- The weak link was DNS, which certificate authorities use to confirm who controls a domain. Google has not said how the registries were compromised.
- Teams should inventory every domain and its registry, watch DNS and Certificate Transparency logs, and ask which registry-level protections are available and whether they apply.
A padlock shows who controlled DNS, not who owns the name
A certificate authority hands out a certificate to whoever proves control of a domain name. The proof is a check against DNS, the internet's address book. Other organizations run that address book. A company can secure its servers, cloud accounts and certificate tools and still be exposed through a domain.
A caution on sourcing. This story rests on an Akamai blog post from October 22, 2026. Its author, Chaturbhuj Singh, is the architect of Akamai DNS Posture Management, and the post promotes that product. The incident facts come from Google's October 6 disclosure, which the post relays. Akamai did not run its own investigation.
What Google disclosed
Akamai's post, citing Google's disclosure, says attackers had compromised the registries for three country domains. They are .gh for Ghana, .sl for Sierra Leone and .as for American Samoa. Google did not say how the registries were compromised. That method is still unknown.
With that access, the attackers changed DNS records for selected domains below those registries. This let them pass the ownership checks. Google's disclosure, as relayed, says they obtained at least 12 publicly trusted certificates for Google and YouTube domains.
Certificate Transparency logs are public records of issued certificates. The certificates appeared over six days. The first showed up under .gh on September 22 and the last under .as on September 27. The .sl domain fell between them, on September 25. Let's Encrypt issued 11 and ZeroSSL issued one. All were revoked by October 1.
Google said its own systems were not compromised. The post adds that nothing suggests the authorities were breached. Google blocked the certificates in Chrome. The logs also showed unauthorized certificates for other brands, and Google told them.
Why the validation check passed
One way to prove control is a DNS challenge. The requester publishes a specific record, and the authority looks for it. Whoever runs the authoritative DNS can publish that record. Depending on the setup, DNS changes can also redirect HTTP-based checks.
So the attackers did not need Google's cloud or web servers. In the post's words, they needed the validation system "to see what they want it to see." The authority sees only what DNS tells it. The certificate system worked largely as designed, but it trusted a compromised answer.
This shows why CAA records help less than they seem to. A CAA record is a DNS entry that names which authorities may issue for a domain. It narrows the options for an attacker. But it is served through the same DNS. The post says CAA is no substitute for securing DNS. It does not say whether the affected domains had CAA records.
Monitoring works differently, because it sits outside the compromised path. The post notes that Google's legitimate certificates came from Google Trust Services. The unauthorized ones came from other issuers. An alert on a new issuer would have stood out.
The post also lists registry lock and DNSSEC. Registry lock restricts changes at the registry. DNSSEC lets resolvers check that DNS answers are genuine. The post presents them as upfront protections for domain owners. Whether they would hold against a compromised registry is not established.
Overlooked domains extend the exposure
Think of the regional team that registered a country domain years ago. Then an acquisition added hundreds more names. Years later, nobody holds the full picture. The post describes this drift, and says such domains often sit under many registries with very different security practices. A firm may guard its main .com well and see little of the rest.
The post recalls a 2012 breach of Pakistan's PKNIC registry, which redirected hundreds of .pk domains, google.com.pk among them. It also cites a later campaign called Sea Turtle. According to the post, it obtained certificates by compromising registries and DNS providers. The researchers did not tie that campaign to any state.
This remains one incident. The post gives no count of how often such attacks occur. Its argument that software agents are exposed more, because they cannot spot an imposter host, is also a claim, not something this incident showed.
What leaders should ask their teams
Can we list every domain we own and the registry behind each one? Who gets an alert if nameservers change on a valuable domain? Who reviews new certificates from issuers we do not normally use? Is the CAA policy checked as the outside world sees it, not as a dashboard shows it?
Add one more. Which registry-level protections, such as registry lock and DNSSEC, are available for our key domains, and are they in use? Recovery also needs a plan. The post says restoring DNS records is not enough. Teams must find and revoke certificates issued during the affected period.
The lesson is plain. Part of your security is decided by registries you have never evaluated. Start with the domains nobody remembers registering.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Akamai.
