Hackers hijacked Google domains through country-code registries

Key takeaways

• Attackers compromised three country-code domain registries to issue fake HTTPS certificates for Google sites.
• Registry-level breaches bypass your own domain security because the registry sits above your registrar in the trust chain.
• Certificate transparency monitoring will alert you when unexpected certificates are issued for your domains.
• Registry lock adds a manual approval step that makes DNS hijacking harder even if upstream systems are compromised.
• Smaller country-code domains often have weaker security than established TLDs like .com or .org.

What happened

On October 6, Google disclosed that attackers had compromised three country-code top-level domain (ccTLD) registries (https://thehackernews.com/2026/10/attackers-hijack-gh-sl-and-as.html) and used that access to obtain unauthorized HTTPS certificates for several Google domains. The affected registries operate .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa).

Google's own systems were not breached. Instead, hackers targeted the third-party operators (https://www.bleepingcomputer.com/news/security/hackers-hijack-google-domains-after-breaching-cctld-registries/) that run these country-code domains, modified authoritative DNS records, and used that control to issue fraudulent security certificates. With a valid HTTPS certificate, an attacker can impersonate a legitimate site over an encrypted connection, bypassing the browser warnings that usually signal danger.

Any domain ending in .gh, .sl, or .as was potentially at risk during the compromise. The attack demonstrates how control over domain infrastructure, even for small or obscure country codes, can be leveraged to target the largest companies on the internet.

Why this is an issue

Most business owners think of domain security as something they control directly through their registrar. You pick a strong password, maybe turn on two-factor authentication, and assume you're covered. This attack shows that's only half the picture.

Every domain name depends on a chain of trust. Your registrar sits above you. Above the registrar is the registry operator that manages the entire top-level domain (.com, .org, or a country code like .gh). If an attacker compromises the registry, they can rewrite DNS records for any domain under that TLD, regardless of how well you've secured your own account.

HTTPS certificates are supposed to prove that you're talking to the real website. Certificate authorities issue them only after verifying that the applicant controls the domain in question. But if an attacker can temporarily hijack DNS at the registry level, they can pass that verification check and obtain a certificate that browsers will trust. From there, they can intercept traffic, harvest credentials, or deliver malware while looking completely legitimate.

This is not a theoretical risk. It happened to Google, a company with some of the most sophisticated defenses in the world. If registry-level compromise can affect them, it can affect anyone using those domains.

What you can do about it

First, understand where your domains live. Log in to your registrar and make a list of every domain you own, along with its TLD. If you operate any .gh, .sl, or .as domains, monitor them closely and consider whether the business value justifies the infrastructure risk. Country-code domains can be appealing for branding or local presence, but they are often managed by smaller organizations with fewer resources for security.

Second, enable registry lock (also called registry-level lock or client-lock status) on your most important domains. This is a feature offered by many registrars that prevents changes to your domain's DNS records or transfer settings without an additional manual approval step, often requiring a phone call or signed document. It won't stop a registry breach, but it raises the bar and adds friction for attackers. Ask your registrar if they support it.

Third, implement certificate transparency monitoring. Services like Facebook's Certificate Transparency Monitor (https://developers.facebook.com/tools/ct/) or Cert Spotter (https://sslmate.com/certspotter/) will alert you when a new certificate is issued for your domain. If you get notified about a certificate you didn't request, you'll know something is wrong and can act before damage is done. Many of these tools offer free tiers for small domain portfolios.

Fourth, review your incident response plan. If your domain is hijacked, you need to know who to call at your registrar, your hosting provider, and your certificate authority. You need backups of your DNS records stored somewhere offline. And you need a communication plan to alert customers if your site is compromised. Writing this down now, when you're not in crisis mode, makes all the difference.

Finally, if you're buying or renewing domains, consider the stability and security posture of the registry, not just the price and availability. Larger, well-established TLDs like .com and .org are managed by organizations with mature security programs and regulatory oversight. That's not a guarantee, but it's a meaningful advantage.

Where this is heading

This incident will likely accelerate two trends. First, expect pressure on ICANN (the organization that oversees domain registries) to impose stricter security requirements on ccTLD operators. Many country-code registries are small, under-resourced, and lack the controls that commercial TLDs have adopted. The gap is now visible.

Second, look for more adoption of modern authentication standards that reduce reliance on the traditional certificate authority model. Technologies like DNS-based Authentication of Named Entities (DANE) and Certificate Transparency are already in use, but incidents like this will push them from niche to standard practice.

In the near term, our read is that businesses should treat registry-level risk the same way they treat any other third-party vendor risk. You can't eliminate it, but you can understand it, monitor it, and have a plan for when it fails. The internet's trust model has always depended on layers. This attack is a reminder that the layers below you matter just as much as the ones you control.