As reported by BleepingComputer, attackers breached country-code top-level domain (ccTLD) registry operators for Ghana (.GH), American Samoa (.AS), and Sierra Leone (.SL), modifying authoritative DNS records and obtaining unauthorized TLS certificates for Google domains and other global brands. While Google acted swiftly to block the fraudulent certificates in Chrome via CRLSets, the incident exposes a trust architecture problem that no single browser vendor can fully remediate.

Key Takeaway: As reported by BleepingComputer, attackers breached country-code top-level domain (ccTLD) registry operators for Ghana (.GH), American Samoa (.AS), and Sierra Leone (.SL), modifying authoritative DNS records and obtaining unauthorized TLS certificates for Google domains and other global brands.

Why This Matters Beyond Google

The headline emphasizes Google, but the real story is infrastructure trust. The attackers didn't need to compromise Google's systems, the Certificate Authorities, or even the browser. They targeted the weakest link in the chain: small ccTLD operators with fewer resources and less mature security postures than the organizations whose domains they manage. Once authoritative DNS was manipulated, the ACME validation process used by CAs functioned exactly as designed — it verified DNS control, not organizational identity.

Google's own CT log analysis revealed additional affected organizations, including major brands and online services. This was not a targeted attack on Google; it was a platform attack on the trust infrastructure itself, with Google being one of many potential victims.
The attack exploited the gap between DNS control validation and true organizational identity verification — a gap that Domain-Validated certificates were never designed to close.

The ccTLD Attack Surface

Country-code top-level domains present an attractive target for several reasons:

Why This Matters Beyond Google
Operational variability: Many ccTLDs are managed by small organizations or government entities with limited security budgets and staff
High value targets: Major brands register localized domains (e.g., google.com.gh) for regional presence, creating high-value impersonation opportunities
Trust inheritance: Browsers and operating systems inherently trust these TLDs and their delegated registries
Monitoring gaps: Organizations often lack visibility into DNS record changes at the registry level for their ccTLD holdings

Browser-Centric Remediation Has Limits

Google's CRLSets intervention protected Chrome users, but as Google itself acknowledged, this protection does not extend to other browsers and cannot guarantee complete coverage of all affected domains. This creates a fragmented security posture where your protection depends on your choice of browser — an unacceptable state for enterprise security teams managing diverse endpoint fleets.

More critically, CRLSets are a reactive emergency mechanism, not a sustainable defense. Each future registry compromise would require a new round of emergency blocking. The asymmetry favors attackers: a single DNS record modification can trigger certificate issuance, while defenders must detect, analyze, and block each instance individually.

Shield53 Recommendations

Immediate Actions

  • Audit your ccTLD portfolio: Inventory all domain registrations across ccTLDs and identify which registries manage them. Prioritize monitoring for high-value brands and domains used for user-facing services
  • Enable DNSSEC: If your ccTLD and registrar support it, enable DNSSEC on all domains to add cryptographic integrity verification that resists unauthorized DNS modifications
  • Monitor Certificate Transparency logs: Set up automated CT log monitoring (via services like Cloudflare Merkle or CertSpotter) for all owned domains across all TLDs. Alert on any certificate issuance you did not initiate
  • Enforce CAA records: Configure Certification Authority Authorization (CAA) DNS records to restrict which CAs can issue certificates for your domains. This limits the blast radius even if DNS is temporarily compromised

Strategic Hardening

  • Evaluate EV or OV certificates for critical domains: While more expensive, Organization-Validated certificates require additional verification beyond DNS control, raising the bar for attackers
  • Implement registry lock where available: Request registry-level locks on critical domains to prevent unauthorized DNS delegation changes
  • Diversify browser controls: For organizations relying on Chrome's CRLSets, evaluate additional protections for non-Chrome browsers including local certificate pinning policies and HSTS preload lists
  • Engage your registrars: Confirm what authentication and change-control mechanisms your registrars have in place for DNS modifications, especially for ccTLD domains

This incident should be treated as a warning shot rather than a contained event. The economic incentives for domain hijacking are strong — phishing infrastructure, credential theft, and brand impersonation all benefit from a valid TLS certificate on a legitimate-looking domain. Until ccTLD operators broadly adopt stronger security standards, this attack pattern will persist and likely expand to additional country-code registries.

Security teams should assume that any domain relying on a less-resourced ccTLD registry carries elevated impersonation risk and implement compensating controls accordingly.