Key Facts at a Glance

• Google says several of its domains were affected by a recent hijack of third-party country-code top-level domains.
• The targeted ccTLDs were .gh for Ghana, .sl for Sierra Leone, and .as for American Samoa.
• Attackers modified authoritative DNS records and obtained unauthorized HTTPS certificates for Google domains and other organizations.
• Google says the certification authorities that issued the certificates should not be blamed because of the attack's nature.
• Google blocked the unauthorized certificates in Chrome and worked with issuing CAs to revoke them.
• Certificate Transparency log analysis showed that other global brands and popular online services were also affected.
• Google recommends monitoring CT logs and publishing restrictive CAA DNS records after DNS control is restored.
• Google warns that cached domain control validation checks could let attackers mint new certificates after a hijack ends.

What the ccTLD Hijack Involved

Google has disclosed that several of its domains were affected by a recent hijack of third-party country-code top-level domains. The incident occurred last week and targeted the .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa) ccTLDs, putting all domains with those suffixes at risk. During these hijacks, attackers modified authoritative DNS records and obtained unauthorized HTTPS certificates covering several Google domains, as well as domains belonging to other organizations, the internet giant says.

The attack did not rely on a flaw in the certification authorities themselves. According to Google, the CAs that issued the certificates are not to be blamed, given the nature of the attacks. Instead, the hijackers gained control over DNS records for the affected ccTLDs, which allowed them to redirect traffic and prove control over domains in ways that certificate authorities could not easily distinguish from legitimate requests.

Why Authoritative DNS Control Is So Powerful

Authoritative DNS records are the instructions that tell the internet where a domain should send visitors. When an attacker modifies those records, they can redirect email, web traffic, and other services to infrastructure they control. In the case of a ccTLD hijack, the attacker may be able to alter records for many domains at once, because the compromised registry or registrar-level systems sit above individual domain owners. That creates a broad blast radius that can affect organizations that had no direct security failure of their own.

For HTTPS, DNS control is especially sensitive because domain control validation is often used to prove that a certificate requester owns or manages a domain. If an attacker can manipulate DNS responses, they may satisfy those checks and obtain a certificate that browsers will trust. The result is a padlock that appears valid to users, even though the certificate was issued to an attacker. This is why DNS hijacks are often followed by certificate abuse, and why defenders treat unauthorized certificates as a serious escalation.

Unauthorized HTTPS Certificates and Chrome Blocking

Immediately after learning of the incident, Google blocked the unauthorized certificates for its domains in Chrome and worked with the issuing CAs to revoke them. That two-part response is important. Revocation tells the certificate authorities to mark the certificates as no longer valid. Blocking in Chrome provides a faster protection layer for users, because browser vendors can push updates or maintain blocklists that prevent trust in known-bad certificates even before every relying party has processed a revocation.

Google also analyzed Certificate Transparency log data and found that multiple other organizations had been affected. Those organizations included global brands and popular online services. The CT logs are public, append-only records of certificates that CAs issue. They are designed to make certificate issuance auditable, and they can reveal unauthorized certificates even when an organization was not the direct target of a notice. In this case, the logs helped show that the ccTLD hijacks had consequences beyond Google's own domains.

To ensure users of those sites were kept safe as soon as possible, Google proactively blocked those certificates in Chrome. Where possible, the company reached out to impacted organizations to alert them to its findings and actions. That kind of cross-organizational notification is critical in DNS hijack scenarios, because victims may not know that their domains were affected until they see unexpected certificate entries or traffic anomalies.

Restoring CAA Records and the Risk of Cached Validation

Google notes that, while it took steps to identify and block the unauthorized certificates, certain domains might still be affected. That warning reflects the messy reality of DNS and certificate ecosystems. Even after a hijack is stopped, cached validation state, delayed revocation, and incomplete monitoring can leave residual risk. Domain owners are encouraged to monitor CT logs for all their domains, especially for those in .gh, .sl, or .as, and to publish restrictive CAA DNS records to ensure safeguards after DNS control has been restored.

CAA records, or Certification Authority Authorization records, let a domain owner specify which certificate authorities are allowed to issue certificates for that domain. A restrictive CAA policy can limit issuance to specific authorized accounts and validation methods. That matters because CAs are permitted to cache and reuse completed domain control validation checks for subsequent issuance. If an attacker can rely on a cached validation state after a hijack ends, they may be able to mint new certificates even after the DNS records have been restored. A properly configured CAA policy reduces that window and blocks unauthorized issuance paths.

The recommendation to publish CAA records after restoring DNS control is not just a cleanup step. It is a preventive control. It helps ensure that the next certificate request for the domain cannot be fulfilled by an unauthorized CA or through a validation method the organization does not use. For high-value domains, CAA records should be paired with continuous monitoring, alerting, and a documented incident response plan for certificate and DNS abuse.

Broader Impact on Organizations and Global Brands

The fact that global brands and popular online services were caught up in the incident shows how interconnected the domain ecosystem has become. An organization may have strong internal security controls, a mature security operations center, and strict certificate management policies, yet still be affected if a third-party ccTLD registry or DNS provider is compromised. This is a supply chain problem expressed through the domain name system.

For affected organizations, the first signs may appear in Certificate Transparency logs, browser warnings, security vendor notifications, or reports from customers. In some cases, the unauthorized certificates may never be used in an active attack, but their mere existence is a security incident because it proves that an attacker could have intercepted traffic or impersonated the domain. That is why Google's proactive blocking and outreach were significant: they reduced the chance that users would trust a certificate that should never have existed.

Guidance for Domain Owners and Security Teams

Domain owners should treat this incident as a reminder to review their DNS and certificate hygiene. Key steps include monitoring CT logs for every domain and subdomain, especially those under .gh, .sl, and .as. Organizations should also inventory all domains, identify which CAs are authorized to issue certificates, and publish CAA records that reflect that policy. Where possible, they should use multi-factor authentication, registry locks, and registrar-level protections to reduce the risk of unauthorized DNS changes.

Security teams should also prepare for the possibility that a DNS hijack can lead to certificate issuance. That means monitoring for unexpected certificates, watching for changes to authoritative DNS records, and having a process to revoke or block certificates quickly. Coordination with CAs, browser vendors, and other affected parties can shorten the exposure window. Google's response illustrates the value of acting quickly and sharing information, even when the affected domains belong to other organizations.

Why ccTLDs Remain Attractive Targets

Country-code top-level domains are managed by a wide range of registry operators, some with different security maturity levels and governance models. That diversity can create opportunities for attackers. A compromise at the registry or DNS provider level can affect many domains at once, and the resulting certificates may be trusted by browsers because the validation path appeared legitimate at the time of issuance. The .gh, .sl, and .as incidents are a reminder that ccTLD security is not only a concern for the countries involved; it is a global issue because domains are used by organizations and users around the world.

Attackers may also target ccTLDs because they can be overlooked in enterprise domain inventories. Organizations often focus on their primary .com or corporate domains, while regional or promotional domains may receive less monitoring. A hijack of a less-watched ccTLD can still yield certificates for recognizable brand names, which can be used in phishing, traffic interception, or malware distribution. Comprehensive domain visibility is therefore essential.

Monitoring, Detection, and Operational Lessons

Certificate Transparency logs are one of the most useful detection tools available. They provide a public record that security teams can search for unauthorized certificates. Regular monitoring can reveal certificates issued for domains that should not have them, certificates issued by unexpected CAs, or certificates that use validation methods the organization does not employ. When combined with DNS monitoring and registrar alerts, CT log monitoring can give early warning of a hijack or mis-issuance.

Operationally, the incident reinforces the need for fast communication channels with CAs and browser vendors. Revocation alone can be slow, and not all clients check revocation reliably. Browser-level blocking can provide immediate protection, but it requires the browser vendor to know about the problem. Google's decision to block certificates in Chrome and contact impacted organizations shows how a large platform can act as a safety net, but other organizations should not assume that someone else will detect and block unauthorized certificates on their behalf.

Finally, the incident highlights the importance of restoration planning. After DNS control is regained, teams should verify that records are correct, publish restrictive CAA policies, review certificate issuance logs, and monitor for further unauthorized activity. Cached validation state can extend an attacker's reach, so simply restoring DNS may not close the incident. A thorough post-hijack review should include CA communications, revocation confirmation, browser blocklist checks, and user notification if there is any evidence of active exploitation.

Source: SecurityWeek News