🚨 Hackers Hijack Google Domains After Breaching ccTLD Registries

A recent series of attacks against the .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa) country-code top-level domains shows that domain trust can fail above the individual website. Public reporting says attackers compromised third-party ccTLD operators, modified authoritative DNS records and obtained unauthorized HTTPS certificates covering several Google properties and other organizations.

Google states that its own systems were not compromised. Chrome responded by blocking identified unauthorized certificates through CRLSets, while issuing certificate authorities were engaged for revocation.

The defensible intelligence posture is therefore: domain-infrastructure compromise confirmed by public reporting → downstream impact and victim scope require case-specific validation.

According to Google and BleepingComputer, attackers compromised third-party operators associated with the .gh, .sl and .as namespaces. They changed authoritative DNS records and used the resulting control to obtain unauthorized certificates for Google domains and other organizations.

Google’s Chrome security team says the incidents did not involve a compromise of Google systems. Chrome blocked the identified unauthorized certificates using CRLSets, and the relevant certificate authorities were asked to revoke them.

Think of DNS as the Internet’s address book. Authoritative DNS records tell resolvers where a domain should connect. When an attacker can change those records, traffic for affected names can be directed to infrastructure controlled by the attacker.

Normally, HTTPS gives the browser another trust signal: the server presents a certificate valid for the requested name. In this incident, the attacker’s DNS control could also be used to satisfy automated domain-control validation, creating the dangerous combination of attacker-controlled DNS + an apparently valid certificate.

The following is an analytical reconstruction from the public reporting. It is a model of the trust-chain abuse, not a claim that every downstream step occurred for every affected domain.

Potential downstream impact: traffic redirection, phishing, fraudulent downloads, credential/session theft or brand impersonation. The supplied evidence does not establish that all of these impacts occurred.

HTTPS is still important. The lesson is that TLS and the browser padlock are only one layer of the trust model. A valid certificate tells the browser that the certificate is valid for the requested domain; it does not independently guarantee that the infrastructure behind that domain is currently operated by the intended organization.

• Verify the complete domain name before entering credentials or downloading software.
• Be cautious when a familiar website unexpectedly redirects to a different host or regional namespace.
• Use saved bookmarks or official applications for high-value services instead of links from unsolicited messages.
• Never bypass unexpected certificate warnings for sensitive services.

If an attacker can make a legitimate-looking domain resolve to infrastructure they control, users may have difficulty distinguishing a malicious service from the real one.

• Phishing pages can appear under a legitimate-looking domain.
• Credential prompts may be used to capture passwords, MFA codes or session information when users are deceived.
• Redirected pages could potentially deliver malware or fraudulent downloads.
• Brand impersonation can damage trust even when the brand’s own application or backend was not breached.
• A regional ccTLD compromise can affect multiple unrelated organizations that share the same namespace.

The publicly reported infrastructure scope centers on three ccTLD namespaces. Google additionally reported that Certificate Transparency logs revealed other organizations affected by the same activity.

Organizations should treat domain infrastructure, registry accounts and certificate issuance as security-control surfaces rather than administrative afterthoughts.

• Monitor Certificate Transparency (CT): continuously watch certificates issued for every owned domain, including regional or parked domains.
• Use restrictive CAA records: limit which certificate authorities may issue certificates. CAA is not a complete defense during an active DNS hijack, but it is an important control after DNS authority is restored.
• Harden registry/DNS access: strong MFA, privileged access controls, separation of duties and explicit change approval for registrar/registry/DNS accounts.
• Alert on DNS changes: unexpected nameserver, A/AAAA/CNAME/TXT changes and unusual TTL modifications deserve review.
• Correlate DNS + CT: investigate certificate issuance alongside DNS changes, hosting changes and external reputation signals.
• Maintain complete domain inventory: regional ccTLD properties are easy to overlook until an incident makes them relevant.

Google specifically recommends continuous CT monitoring and restrictive CAA records, and emphasizes that browser-side intervention should not be relied upon as the sole defense.

For normal users, the practical defense is to validate the destination rather than trusting a familiar logo or a green padlock by itself.

• A familiar site suddenly redirects through an unfamiliar host or region.
• The address is almost correct but uses an unexpected spelling, namespace or ccTLD.
• A trusted service unexpectedly asks you to sign in again or download a new program.
• A certificate warning appears unexpectedly — do not bypass it for sensitive services.
• You reached the service through a message, ad or post rather than a saved bookmark or official app.

This incident does not reduce to a single IP/domain IOC list. The useful indicators are infrastructure-state indicators that show whether domain trust may have been manipulated.

The objective is not simply to “block an IOC,” but to detect unauthorized changes in the trust infrastructure controlling where users are sent and which certificates exist for those names.

CyberRakshakLabs Assessment: this is a trust-chain incident, not a story that “HTTPS is broken.” DNS tells a user’s system where to go; TLS helps validate that the endpoint is authorized for the requested domain; Certificate Transparency and DNS governance provide additional visibility into unauthorized change.

The most important defender question is therefore not only “Was the website breached?” It is “Who currently controls the domain infrastructure, and can we prove that control has not been changed?”

The supplied research input and current public reporting support a high-priority infrastructure-security lesson: compromise at the ccTLD/DNS layer can undermine user trust even when a major organization’s own systems remain uncompromised.

The exact intrusion mechanism behind the ccTLD compromises, the complete victim scope and the use of individual redirected sites for phishing, malware or credential theft remain case-specific questions. Defenders should therefore validate registry/DNS integrity, certificate issuance, logs and domain inventories rather than treating the browser padlock as final proof of legitimacy.

Key takeaway: A legitimate-looking URL and a valid certificate are useful trust signals — but they are not a substitute for secure domain governance and continuous monitoring.

This Research #055 is based on the supplied CyberRakshakLabs research document and current public-source verification.

Verification note: public-source access confirms the reported ccTLD and certificate-hijack mechanism. Claims about specific downstream phishing, malware delivery or data theft should be independently validated for each affected domain.