Hackers compromised third-party operators managing ccTLD registries for Ghana (.GH), American Samoa (.AS), and Sierra Leone (.SL), altered authoritative DNS records, and obtained valid HTTPS certificates for Google and other global brands. Google blocked the unauthorized certificates in Chrome through CRLSets and worked with issuing Certificate Authorities to revoke them. This incident exposed a fundamental weakness: during an active DNS hijack, no standard validation method can reliably distinguish legitimate from fraudulent certificate requests.
What the Incident Revealed
Certificate Authorities followed protocol. The CAs validated domain ownership as designed: they issued a challenge, the requester created the required TXT record, and the CA confirmed it. The issue arose because the attacker controlled the authoritative DNS during validation. This isn't a CA failure; it's a structural limitation when DNS is compromised.
Browser-specific interventions are limited. Google's CRLSets blocked the fraudulent certificates for Chrome users immediately, but this protection didn't extend to other browsers like Firefox, Safari, or Edge. If your customers use these browsers, they remained vulnerable until the certificates were formally revoked through standard channels.
Certificate Transparency logs served as a detection tool. Google identified additional affected organizations by examining CT logs after the initial incident. This reactive use of CT data worked for Google's security team, but most domain owners don't monitor these logs systematically. Many organizations likely didn't know their domains had been hijacked until Google notified them.
Key Findings
DNS control equals certificate authority. Once an attacker modifies authoritative DNS records, they can pass domain validation challenges from any CA. The certificates issued are technically valid because the validation process was completed correctly. Your brand's legitimacy becomes the attacker's credential.
Parked and secondary domains are vulnerable. Google advised domain owners to "monitor CT logs across their entire domain portfolio, including parked domains." Attackers don't need to compromise your primary domain to damage your brand; a forgotten subdomain or parked acquisition can serve malicious content under a valid certificate with your organization's name.
CAA records offer post-incident protection. CAA DNS records "cannot stop certificate issuance during an active DNS hijack, but they prevent obtaining additional certificates using cached domain validation after legitimate DNS control is restored." CAA records limit which CAs can issue certificates for your domain, but if the attacker controls DNS, they control your CAA records too. The protection comes later, when you've regained control but cached validation data might still be exploitable.
Third-party registry operators are single points of failure. The breach targeted third-party operators managing ccTLD registries, not Google or the affected brands directly. Your DNS security depends on vendors you may never have formally assessed, contracted with, or even identified as part of your critical infrastructure.
What This Means for Your Team
If you manage domains for your organization, you're now defending against attacks where the adversary can impersonate your brand with valid cryptographic credentials. The traditional trust model breaks when DNS is compromised.
Your procurement and TPRM functions likely don't include DNS registry operators in vendor risk assessments. These entities sit outside your direct contractual relationships but control infrastructure critical to your brand integrity. Consider a scenario where your organization uses a .IO domain for a customer portal: you have no contract with the entity operating the .IO registry, no right to audit their security controls, and no visibility into their sub-outsourcing arrangements.
The incident also exposes a gap in continuous monitoring architectures. Most security teams monitor for certificate issuance against their primary domains, but comprehensive CT log monitoring across all owned domains, subdomains, and parked properties requires dedicated tooling and processes that many organizations haven't implemented.
Action Items by Priority
Immediate: Implement CT log monitoring for all owned domains. Deploy automated monitoring that alerts when any certificate is issued for domains you own. This includes parked domains, expired marketing campaigns, and subsidiary brands. Services like crt.sh provide searchable CT log data; integrate alerts into your SOC workflow. If you operate at scale, consider tools that aggregate CT feeds and filter for your domain portfolio.
Within 30 days: Publish CAA records for all domains. Create CAA DNS records that specify which Certificate Authorities are authorized to issue certificates for your domains. Include ACME account restrictions where your CA supports them. This won't stop an active hijack, but it prevents attackers from obtaining additional certificates after you regain DNS control and limits the window of exploitation.
Within 90 days: Inventory your DNS supply chain. Document which entities have authoritative control over your DNS records. This includes your primary DNS provider, your domain registrar, and the registry operators for each TLD you use. For ccTLDs, identify whether the registry is operated by a government entity or a third-party contractor. You can't assess risk you haven't identified.
Ongoing: Require DNSSEC where feasible. DNSSEC provides cryptographic validation of DNS responses, making it significantly harder for attackers to modify records even if they compromise a registry operator. Not all TLDs support DNSSEC, and implementation complexity is real, but for critical domains the protection justifies the operational overhead.
Governance layer: Establish cross-browser incident response procedures. Google's CRLSets protected Chrome users immediately, but your customers use multiple browsers. Your incident response plan for domain hijacking must include direct communication with affected CAs for rapid revocation and coordination with browser vendors beyond Chrome. Document notification timelines and escalation paths before you need them.
