DNS Hijack Undercuts TLS Trust

Control of the internet's certificate system rests on a simple assumption: that the entity proving it owns a domain actually owns it. According to Google, attackers found a way to break that assumption at scale — not by defeating cryptography, but by first seizing the plumbing that tells the internet where a domain lives. The result was a batch of counterfeit TLS certificates minted for Google properties and other major brands, issued through the normal automated channels that browsers and operating systems are built to trust.

Google disclosed the incident on Tuesday, describing a campaign that began with hijacks of three country-code top-level domains. From there, the attackers manipulated DNS records to clear the industry's standard ownership checks and walk away with unauthorized certificates.

Three ccTLDs as the entry point

The campaign targeted the .gh, .sl, and .as country-code top-level domains, according to Google. Country-code domains are administered by registries that, in many cases, operate with far fewer resources and less scrutiny than the bodies overseeing generic top-level domains like .com or .org. That makes them a comparatively soft target for anyone looking to gain authoritative control over a namespace rather than a single domain.

Once the attackers had hijacked those top-level domains, the source article reports, they modified authoritative DNS records for selected domains inside those namespaces. Authoritative records are the final word on where traffic for a given domain should go. Whoever controls them effectively controls the domain's identity on the network.

With that control in hand, the attackers could change the IP addresses of a chosen list of websites and send and receive traffic on those sites. That ability is significant because it allowed them to alter nameserver delegations for selected domains — the very evidence that certificate authorities rely on when validating that an applicant controls a domain.

How the validation check was defeated

Certificate authorities don't hand out TLS certificates on trust. Before issuing one, a CA runs automated domain control validation, a check designed to confirm the applicant actually controls the domain in question. The methods vary, but the principle is consistent: prove you can respond in a way only the real domain owner could.

By controlling DNS records and nameserver delegations for selected domains, the attackers were able to satisfy those checks. Google said the attackers passed industry validation requirements by proving control of the domain through the hijacked infrastructure.

What the attackers obtained as a result were x.509 certificates — the credential type that uses a digital signature to bind a domain name such as google.com to a public key. The public key is openly available; the private key is meant to be held only by the site operator. When a connection shows the keys match, a visitor knows they're connected to the authentic site rather than an impostor. An unauthorized certificate, paired with a matching private key, lets an attacker cryptographically impersonate the affected infrastructure.

Google said the attackers obtained unauthorized certificates for several Google domains as well as for several leading global brands and widely used online services. It did not name the affected domains it owns, nor did it identify any of the other organizations whose domains were caught up in the campaign.

Google's response and its limits

Google said it updated Chrome to block all of the certificates it identified as unauthorized, and worked with the issuing certification authorities to ensure the unauthorized certificates for Google properties were revoked. Chrome users, the company said, do not need to take any action to be protected.

But Google was explicit that the browser-level fix is not a substitute for domain owners protecting themselves. In a statement, the company said:

"While Chrome took steps during these incidents to identify and block suspected unauthorized certificates across the affected ccTLDs, browser-side intervention should not be relied on to protect your users. Due to the complexity of DNS hijacks, we cannot guarantee that our analysis identified every affected domain, nor do Chrome interventions reliably protect non-Chrome users."

— Google, in its disclosure of the incident.

That warning matters because browser-side blocking only reaches people using that browser. Users of other browsers, mail clients, and any application that validates certificates independently would not benefit from Chrome's intervention.

Google's guidance to domain owners included monitoring certificate transparency logs for unexpected issuance across their domains, and publishing restrictive Certification Authority Authorization, or CAA, DNS records. The CAA mechanism is intended to prevent attackers from reusing cached validation data after DNS control has been restored — a scenario where the original hijack is over but its residual effects could still be exploited.

Open questions and slow revocation

The full scope of the campaign remains unclear. According to the source, it is not immediately known what the other affected organizations are, how many unauthorized certificates were issued, or whether all of them — aside from those for Google domains — have been blocked.

That uncertainty is compounded by how certificate revocation works. The process for officially revoking a certificate is slow and cumbersome, which is why browser makers have built faster mechanisms to block specific certificates at the browser level rather than waiting for the revocation machinery to catch up.

With all known unauthorized certificates now blocked, the immediate risk is mitigated. But as Google acknowledged, any certificates that remain undiscovered still pose a threat. The gap between "all known certificates are blocked" and "all certificates are blocked" is precisely where the risk lives.

What the incident did not involve

Google was careful to note what did not happen. According to the company, the incident did not involve the compromise of the infrastructure of any of the affected domain owners, and the certificate authorities followed all of the applicable requirements.

That distinction is important for how the failure is understood. No one broke into a company's servers, and no CA skipped a mandated step. Instead, the attackers manipulated the layer beneath both — the DNS infrastructure that validation checks depend on. The validation process worked as designed; it was fed false evidence.

The result is a case where every party followed the rules and a trust failure still occurred. That is a harder problem to patch than a bug, because it lives in the assumptions the system makes about who controls a domain at the moment validation runs.

A familiar pattern with new mechanics

This is not the first time threat actors have obtained unauthorized certificates, and the source places the new campaign in that longer history. A 2011 hack of Netherlands-based certificate authority DigiNotar allowed attackers to mint counterfeit certificates for Google.com and more than 200 other high-traffic domains. Those certificates were used against at least 300,000 people with ties to Iran as they browsed the sites impersonated by the forged certificates.

Similar incidents have occurred many times since, according to the source, most often through failures by certificate authorities — but also, in some cases, through failures on the part of domain holders themselves. The new campaign is notable for routing around the CA entirely at the validation stage, using control of top-level infrastructure rather than a flaw inside an issuing authority.

The numbers behind the incident

• 3 country-code top-level domains hijacked: .gh, .sl, and .as
• 200+ high-traffic domains compromised through counterfeit certificates in the 2011 DigiNotar hack
• 300,000 people with ties to Iran targeted using those forged certificates

Beyond those figures, the source does not provide a count of how many certificates were issued in the current campaign, how many organizations were affected, or how many domains Google itself lost certificates for.

Why this matters beyond the affected brands

The practical lesson for domain owners is that the certificate system's protections are not entirely self-executing. A browser update can block a known bad certificate, but it cannot find every one, and it cannot cover every application a user might rely on. Monitoring certificate transparency logs and publishing restrictive CAA records are measures Google is advising precisely because they operate at a layer the browser cannot reach.

For organizations that hold domains, the incident suggests that DNS control is not just an availability concern but a security boundary for identity. If an attacker can briefly take over the records that prove domain ownership, the certificates that follow are technically valid — which means the failure may not be visible as an error to anyone until it is too late. This could mean that the most durable defense is continuous monitoring rather than one-time configuration, and a willingness to treat certificate issuance as something to watch, not something to assume.