How a country code hijack broke the internet's chain of trust

I remember sitting in a windowless data center in 2011 when the DigiNotar news broke. Back then, a single compromised certificate authority in the Netherlands allowed attackers to mint fraudulent credentials for Google. It felt like a fundamental betrayal of the math that keeps the web safe. Fast forward to late 2026, and the industry is dealing with a version of the same nightmare, though the entry point has shifted. A multi-billion dollar security apparatus was defeated by the digital equivalent of a locksmith stealing the master keys from a small-town hardware store.

Google recently confirmed that attackers hijacked three country code top-level domains (ccTLDs): .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa). By gaining control of these namespaces, the actors modified authoritative DNS records for specific high-value targets. This control allowed them to bypass the automated validation checks that certificate authorities use to verify ownership. The result was the issuance of unauthorized TLS certificates for several Google domains and other major global brands. This is the architectural paradox of modern security: a company can spend millions on zero trust and hardware security keys, yet its digital identity remains tethered to the administrative security of a distant registry.

The mechanics of the domain control bypass

To understand why this happened, we have to look at how a website proves who it is. When an organization requests a TLS certificate, the issuing Certificate Authority (CA) must verify that the applicant actually controls the domain. The industry standard for this is Domain Control Validation (DCV). The CA asks the applicant to perform a specific task, such as hosting a unique file at a specific URL or, more commonly, creating a specific DNS record. If the CA sees the correct record on the authoritative nameservers, it issues the certificate.

In this incident, the attackers did not need to hack Google. They hacked the TLD infrastructure itself. Once they controlled the nameservers for .gh, .sl, and .as, they pointed the DNS records for targeted subdomains to their own servers. When the CA performed the automated check, the attackers’ server provided the correct response. The CA followed its protocol perfectly, but it was talking to an impostor. The system is a digital vault that works only if the bouncer at the door actually knows what the real owner looks like.

Why browser blocks are a temporary fix

Google updated Chrome to block these unauthorized certificates immediately. This is a reactive measure that protects millions of users, but it highlights a systemic weakness. The process of revoking a certificate is notoriously slow. Traditional methods like Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP) often fail due to privacy concerns or network latency. Consequently, browser makers have moved toward hardcoded blocklists to provide immediate protection.

From a risk perspective, this intervention is a band-aid. Google admitted that Chrome interventions do not protect users on other browsers, nor can the company be certain it identified every affected domain. If an attacker possesses a validly signed certificate that a browser has not yet blocked, they can perform a man-in-the-middle attack. They can intercept traffic, decrypt sensitive data, and present a "secure" padlock icon to the victim. The integrity of the connection is gone, and the user has no way to know the difference.

The dark matter of the corporate network

DNS is often the dark matter of enterprise security. It is invisible, pervasive, and frequently overlooked until something breaks. Many organizations treat their TLD relationships as a simple billing matter rather than a mission-critical security dependency. When you register a domain in a country code TLD, you are placing your trust in that nation's registry security, their government’s stability, and their technical resilience.

Looking at the threat landscape, this incident demonstrates that attackers are moving up the supply chain. Instead of attacking a hardened perimeter, they are targeting the decentralized components of the internet's core infrastructure. A breach at the TLD level is stealthy because it does not trigger internal alarms. The organization’s servers are fine, the employees are not clicking phishing links, and the firewall is quiet. Yet, the brand’s identity is being forged elsewhere.

Implementing certification authority authorization

Google is advising domain owners to publish Certification Authority Authorization (CAA) DNS records as a countermeasure. A CAA record is a policy statement that tells the world which specific CAs are allowed to issue certificates for a domain. If a rogue actor tries to get a certificate from CA "A," but the CAA record only lists CA "B," the request should be denied.

However, CAA records are only effective if they are restrictive and if the CAs honor them. More importantly, if an attacker hijacks the DNS, they can simply delete or modify the CAA record before requesting the fraudulent certificate. Google suggests that these records can prevent attackers from reusing cached validation data, but they are not a silver bullet. They are a granular tool that adds a layer of friction for the attacker, but they still rely on the integrity of the DNS itself.

The importance of certificate transparency logs

Behind the scenes, the most effective way to spot this kind of activity is through Certificate Transparency (CT) logs. CT is a system of public, append-only logs that record every TLS certificate issued by participating CAs. Every time a certificate is minted for your domain, it appears in these logs.

Proactively speaking, every security team should monitor these logs for their domains. If a certificate appears from a CA you do not use, or at a time you did not request one, you are likely looking at a hijack in progress. I use several automated tools that alert me via Signal the moment a new certificate is issued for any property I manage. This forensic visibility is the only way to detect a TLD-level hijack before it results in a massive data breach.

Lessons from the DigiNotar era

This incident is a reminder that the certificate system has systemic flaws. In 2011, the DigiNotar breach was a digital hostage situation for the people of Iran, whose traffic was intercepted by their government using forged certificates. While the current TLD hijack seems focused on brands and services, the technical vulnerability is identical. We are still using a centralized trust model in a decentralized world.

Encryption is a shatterproof digital vault only if the keys are handled with absolute integrity. When the infrastructure that validates those keys is compromised, the vault door is left wide open. The attackers in this case showed that you do not need to break the encryption to win. You only need to convince the system that you are the rightful owner of the vault.

Practical takeaways for security leaders

Security is often about managing dependencies you do not control. While you cannot secure the infrastructure of a foreign TLD registry, you can control how your organization responds to these risks.

• Audit your domain portfolio and identify which domains are registered under ccTLDs with less stringent security protocols.
• Publish CAA records for all mission-critical domains to limit which authorities can issue credentials.
• Set up real-time monitoring of Certificate Transparency logs to catch unauthorized issuance within minutes.
• Enable DNS Security Extensions (DNSSEC) where possible to add cryptographic signatures to your DNS data, making hijacks harder to execute.
• Revise your incident response plan to include a protocol for rapid certificate revocation and browser-vendor coordination.

As a countermeasure, these steps ensure that even if the TLD registry fails, your team has the visibility to react before the damage becomes systemic. The goal is to move from a reactive posture to a resilient one. Security is not a state you achieve, but a process you maintain.

Sources:

• Google Security Blog: Tracking Recent TLD Hijacks and Unauthorized Certificates
• NIST Special Publication 800-15: Minimum Interoperability Requirements for PKI Components
• CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates
• RFC 6844: DNS Certification Authority Authorization (CAA) Resource Record
• MITRE ATT&CK Framework: T1584.001 (Compromise Infrastructure: Domains)

Disclaimer: This article is for informational and educational purposes only and does not replace a professional cybersecurity audit or incident response service.