Attackers compromised infrastructure associated with three country-code top-level domain registries and used that control to hijack domains belonging to Google and other major organizations, demonstrating how weaknesses deep inside the Domain Name System can undermine both DNS and HTTPS simultaneously. The affected namespaces were .gh for Ghana, .sl for Sierra Leone and .as for American Samoa. Google stresses that its own infrastructure was not compromised. Instead, attackers gained sufficient control over the third-party ccTLD environments to modify authoritative DNS records for selected domains within those namespaces.

That distinction is critical. A normal domain hijack might involve stealing credentials for one registrar account or changing DNS for one organization. A compromise at the registry level sits higher in the hierarchy. A registry manages the authoritative records that determine which nameservers control domains across an entire top-level namespace. If attackers can manipulate that layer, potentially every organization using the affected country-code domain enters the blast radius.

The attack chain can be summarized as: ccTLD operator compromised → authoritative DNS data modified → Google or another organization’s regional domain redirected → attacker demonstrates domain control to a Certificate Authority → valid HTTPS certificate issued → attacker can potentially host an impostor service with a browser-trusted certificate.

This is what makes the incident particularly significant.

DNS tells the user where a domain is located.

TLS tells the user whether the server at that location is authorized to represent the domain.

In this attack, the adversary was able to interfere with the mechanism used to establish both.

Normally, obtaining an HTTPS certificate for somebody else’s domain should be impossible because Certificate Authorities require proof that the requester controls the domain. Automated Certificate Management Environment, or ACME, validation commonly performs that proof using DNS records or HTTP resources. If the requester can correctly place the required random validation token into the domain’s authoritative DNS, the CA has good reason to conclude that the requester controls the domain.

That assumption normally works extremely well.

The problem is that the attackers had compromised the infrastructure responsible for answering that question.

By changing authoritative DNS records, the adversary could make a CA see exactly the validation response required to prove domain ownership. From the CA’s perspective, the validation process worked correctly. Google explicitly says it has no reason to believe the issuing Certificate Authorities behaved improperly.

This is an important technical distinction because it would be misleading to describe the certificates as being issued because of a CA vulnerability.

The Certificate Authorities were presented with apparently valid evidence of domain control.

The trust failure occurred further upstream.

Certificate Transparency records reviewed after the incident showed at least 12 unauthorized certificates covering seven Google and YouTube domains under the affected country-code namespaces. The observed certificates included names such as google.com.gh, google.sl, google.com.sl, google.as, youtube.com.gh, youtube.sl and youtube.as. Eleven of the identified certificates were issued by Let's Encrypt and one by ZeroSSL.

The certificates appeared over several days rather than in one isolated event. Certificate Transparency records show activity involving .gh on September 22, .sl on September 25 and .as on September 27. That sequencing suggests the attackers moved between ccTLD environments instead of compromising all three namespaces in a single obvious burst.

The ability to obtain a valid TLS certificate dramatically increases the credibility of a DNS hijack. Without one, redirecting users from a legitimate HTTPS domain to an attacker-controlled server would normally produce a certificate warning. Modern browsers have trained users, with varying degrees of success because humans remain inventive, to distrust those warnings.

A valid certificate removes that warning.

The attacker can potentially redirect the domain and present a certificate that the browser trusts.

The connection still shows HTTPS.

The lock indicator still appears.

The certificate chain is valid.

The domain name in the browser is correct.

Yet the server behind it may belong to the attacker.

This is why HTTPS should not be interpreted as proof that a website is benign. HTTPS proves that the connection is encrypted and that the server possesses a certificate valid for the requested hostname. It does not independently establish that the legitimate organization still controls the DNS path leading to that server.

If both DNS and certificate validation are compromised through the same control point, the attacker can satisfy both signals.

Google responded by using Chrome CRLSets, its emergency certificate-blocking mechanism, to reject the unauthorized certificates associated with Google properties. It also coordinated with the issuing Certificate Authorities so the certificates could be formally revoked, protecting users of other browsers and applications that honor those revocations.

After the initial investigation, Google examined Certificate Transparency logs and discovered certificates associated with additional organizations, including what it described as leading global brands and widely used online services. It proactively blocked those certificates in Chrome and attempted to contact affected organizations.

That secondary discovery is important because it indicates the operation was not simply a targeted effort against Google.

Google may have been the organization large enough to notice and investigate the pattern.

The underlying registry compromise potentially placed every domain under .gh, .sl and .as at risk, depending on what access the attackers actually obtained and which records they chose to modify.

The full scope remains unknown.

Google has warned that it cannot guarantee every affected domain was identified.

That uncertainty is one of the most concerning parts of registry-level compromise. An organization may monitor its own authoritative DNS provider carefully and see nothing suspicious because the malicious change occurred further upstream. The company’s internal DNS configuration may remain perfectly intact while the registry delegates users somewhere else.

This creates an important distinction between registrar security, DNS provider security and registry security.

A registrant controls its own domain account.

A registrar manages the customer relationship and submits changes to the registry.

The registry maintains authoritative data for the top-level domain.

Security controls at one layer cannot automatically compensate for compromise at another.

An organization could use strong MFA on its registrar account, DNSSEC, hardened DNS hosting and carefully controlled administrator credentials and still face a serious incident if the registry above it is compromised.

This is why domain infrastructure should be considered part of the global digital supply chain.

Companies do not directly control every organization involved in delivering their domain to a user.

They depend upon registrars, registries, DNS providers, Certificate Authorities, recursive resolvers, network providers and browsers.

Trust is distributed.

So is risk.

The attack also highlights the value of Certificate Transparency monitoring. CT logs publicly record trusted TLS certificates issued by participating Certificate Authorities. Organizations can therefore detect when a certificate is issued for one of their domains even if they did not request it.

Google recommends that organizations monitor CT activity across their entire domain portfolio, not merely their primary .com property. Regional domains, marketing domains, legacy hostnames and even parked domains matter because attackers frequently target the assets receiving the least administrative attention.

The lesson is especially relevant to multinational companies.

A security team may closely monitor company.com while barely remembering that company.com.gh, company.sl or another regional property exists.

Attackers tend to remember.

Regional domains can still carry the company’s brand, receive user trust and participate in authentication or redirects even when they are not central to normal operations.

Google is also recommending restrictive CAA, or Certification Authority Authorization, records. CAA allows a domain owner to specify which Certificate Authorities are permitted to issue certificates for a domain.

However, this incident demonstrates an important limitation.

CAA itself is stored in DNS.

An attacker with active control over authoritative DNS may be able to change or remove the CAA record while the hijack is ongoing.

CAA therefore cannot magically solve a registry compromise.

Its value becomes particularly important after control is restored.

Certificate Authorities are permitted under industry rules to reuse previously completed domain-control validation for some period of time. An attacker who successfully validated the domain during the hijack might otherwise be able to request additional certificates later using cached validation state.

Google recommends restrictive CAA policies tied, where supported, to specific ACME accounts and validation methods so that an attacker cannot continue minting certificates after legitimate DNS control has been restored.

This detail reveals a less obvious incident-response problem.

Recovering DNS does not necessarily end the attack.

The adversary may have created artifacts that remain useful after the DNS compromise itself has been closed.

Those artifacts can include:

valid certificates;

cached certificate-validation state;

malicious DNS records cached by resolvers;

session tokens captured while traffic was redirected;

credentials collected through impersonated services;

or trust relationships established during the compromise.

The response therefore has to extend beyond simply putting the DNS records back.

Domain owners affected by a registry hijack should review all recent certificate issuance, revoke unauthorized certificates, restore restrictive CAA policies, inspect DNS history, examine authentication logs for suspicious activity during the exposure window and determine whether users could have been redirected to attacker infrastructure.

If authentication services were involved, credential and session rotation may also be necessary.

The investigation should ask not only:

“When did we regain control of DNS?”

but:

“What could the attacker have obtained while they controlled it?”

That is the question that determines the real impact.

Another important boundary is that the existence of an unauthorized certificate does not automatically prove that the attacker successfully intercepted user traffic. Google has not publicly said whether the certificates were actually used to impersonate Google services or steal user information.

Certificate issuance proves the attacker had enough control to satisfy domain validation.

It demonstrates capability.

It does not by itself establish every downstream action.

This distinction matters because security reporting tends to compress the sequence:

certificate obtained → users intercepted

when the second step still requires evidence.

At the same time, the capability is serious enough that defenders cannot dismiss it merely because confirmed interception has not yet been disclosed.

An attacker who simultaneously controls DNS and a valid certificate possesses nearly everything necessary to convincingly impersonate a website.

The campaign also challenges the traditional hierarchy of security priorities for internet-facing services.

Organizations spend enormous amounts securing web servers, application code, WAFs, identity providers and endpoint systems.

Those controls do very little if a user requesting the organization’s hostname is silently directed somewhere else before reaching any of them.

DNS therefore deserves treatment as identity infrastructure, not plumbing.

A domain name is effectively the public identity of an internet service.

Control of that identity influences websites, APIs, email, certificate issuance and authentication.

Compromising DNS can therefore bypass security mechanisms without exploiting the underlying application at all.

The same principle applies to Certificate Authorities.

TLS certificates are not merely encryption objects.

They are delegated statements of identity.

A CA says, in effect:

“The entity presenting this certificate demonstrated control over this domain.”

If the domain-control evidence is manipulated because DNS itself has been hijacked, the certificate can be cryptographically valid while the underlying identity claim is operationally false.

The cryptography has not failed.

The trust assumption has.

That distinction is one of the most important lessons from this incident.

Modern security systems increasingly rely on strong cryptography, but cryptography only protects the assertions fed into it.

A perfectly signed certificate cannot tell whether an attacker manipulated the DNS system used to prove ownership beforehand.

The event therefore demonstrates the difference between cryptographic trust and administrative trust.

The cryptography did exactly what it was designed to do.

The administrative infrastructure establishing domain ownership had been compromised.

Registry operators themselves consequently deserve security controls comparable to other critical internet infrastructure. Administrative access should require phishing-resistant MFA, strict role separation, privileged-access monitoring, strong change approval, immutable audit logs and rapid detection of high-impact delegation or nameserver changes.

Registry changes involving major global domains should be exceptionally rare and therefore exceptionally visible.

Behavioral monitoring should be able to detect anomalies such as sudden nameserver changes across unrelated high-profile domains, unexpected modifications from new administrative identities or bursts of certificate issuance shortly after DNS changes.

There is also a strong argument for correlating DNS-change telemetry with Certificate Transparency telemetry.

A domain suddenly changing delegation and then receiving a certificate from an unfamiliar CA within minutes is substantially more suspicious than either event alone.

This is a recurring security lesson: individual events often appear legitimate.

The sequence reveals the attack.

The attack can currently be represented as:

attacker compromises ccTLD operator → modifies authoritative DNS or domain delegation → redirects selected Google and third-party domains → completes automated domain-control validation → trusted CA issues legitimate HTTPS certificate → attacker possesses capability to impersonate affected service → CT logs expose unauthorized issuance → Google blocks certificates through Chrome CRLSets → issuing CAs revoke certificates → affected organizations begin remediation.

The unanswered questions remain substantial.

Google has not identified the attackers. The exact compromise method used against the three ccTLD operators has not been disclosed. The number of affected organizations remains unknown. It is also not yet established publicly whether attackers used the certificates to intercept credentials or user data. Those uncertainties should remain explicit rather than being filled with speculation.

What is already clear, however, is that this was not merely a certificate incident and not merely a DNS incident.

It was a trust-chain incident.

The attackers compromised an infrastructure layer used to answer the question:

“Who controls this domain?”

They then used that answer to satisfy another infrastructure layer that asks:

“Who should receive a trusted HTTPS certificate?”

Each system behaved rationally based on the information available to it. The attacker controlled the information connecting them. That is what makes registry-level compromise particularly dangerous. Sometimes the attacker does not need to break the locks. They compromise the authority responsible for deciding who owns the door.

Hackers obtained unauthorized HTTPS certificates for several Google domains and hijacked domains in the country-code top-level domains (ccTLDs) for Ghana, American Samoa, and Sierra Leone after compromising third-party operators and modifying authoritative DNS records. [...]

Source: Hackers hijack Google domains after breaching ccTLD registries via Bleeping Computer — published 07 Oct 2026.