Cybercriminals have hijacked three country-code top-level domains to generate unauthorized HTTPS certificates for several major online services, including Google properties, placing thousands of websites and their visitors at risk.
According to disclosures from Google, the attack compromised the registry infrastructure for three national domain extensions: .gh representing Ghana, .sl representing Sierra Leone, and .as representing American Samoa. By gaining control over these country-code top-level domains (ccTLDs), the attackers altered authoritative Domain Name System (DNS) records to request and secure valid cryptographic certificates from trusted Certificate Authorities.
DNS Tampering and Traffic Redirection Risks
The unauthorized modifications allowed the threat actors to target any organization operating under the three hijacked country codes. By manipulating authoritative DNS records, the attackers established the ability to secretly reroute web traffic away from legitimate platforms and toward malicious infrastructure under their direct control.
Because the attackers obtained genuine HTTPS certificates, redirected web traffic would display standard browser security indicators, such as the familiar padlock icon. This level of deception significantly increases the likelihood of successful phishing and data harvesting operations. Visitors attempting to access legitimate portals could enter account credentials, personal information, or payment details directly into attacker-controlled systems without receiving security warnings, and they could potentially be exposed to malicious software downloads depending on the circumstances.
Google emphasized that the issuing entities were not at fault for the fraudulent certificates. The company stated that, given the specific nature of the compromises at the authoritative DNS layer, it has no reason to believe the Certificate Authorities that issued the impacted certificates acted improperly or failed in their responsibilities.
Scope of the Intrusion and Mitigation Actions
Google stressed that the danger posed by the intrusion was not merely theoretical. The company confirmed that several leading global brands and widely used online services suffered exposure during the campaign. While Google stated that thousands of websites were placed at risk, the company did not specify the exact number of impacted organizations, nor did it disclose the names of the victim companies or clarify which specific Google properties were targeted.
In response to the discovery, Google initiated its standard incident response procedures to shield web users. The company deployed CRLSets in its Chrome browser to immediately block the use of the fraudulent certificates across Google services. Additionally, Google coordinated directly with the relevant Certificate Authorities to revoke the unauthorized certificates entirely, extending protection to users accessing the web through non-Chrome browsers.
Despite these interventions, Google warned that its defensive actions might not have identified every single affected domain or completely protected users across all alternative browsers. Where contact details were available, Google reached out directly to alert affected organizations regarding its findings and the mitigations enacted.
Guidance for Domain Administrators
Google confirmed that everyday Chrome users do not need to take any manual steps to safeguard themselves against the revoked certificates. However, the company highlighted specific measures that domain administrators must implement to shield their web properties from similar registry-level attacks.
Security teams and domain owners are advised to conduct ongoing monitoring of Certificate Transparency logs for every domain they operate. Google also recommended that organizations publish restrictive Certification Authority Authorization (CAA) records configured with Automated Certificate Management Environment (ACME) account bindings. These configurations restrict which Certificate Authorities are authorized to generate certificates for a given domain and bind issuance to specific automated accounts, limiting the blast radius if DNS records are temporarily modified.
A History of High-Profile Certificate Compromises
The hijacking of registry-level infrastructure highlights persistent vulnerabilities within the broader web security ecosystem. Similar breaches have disrupted the public key infrastructure in previous years, resulting in severe consequences for trusted certificate providers and technology vendors.
In 2011, cybercriminals compromised Dutch Certificate Authority DigiNotar, producing 531 fraudulent certificates covering prominent platforms operated by Google, Microsoft, Mozilla, and Skype, among others. A number of those counterfeit certificates were allegedly deployed to intercept encrypted communications belonging to Iranian internet users. The scale of the intrusion led major browser vendors to permanently revoke trust in DigiNotar, ultimately forcing the organization into bankruptcy.
Earlier that same year, attackers compromised an account linked to a registration authority partnered with Comodo, successfully issuing nine fraudulent digital certificates for domains managed by Google, Microsoft, Yahoo, and other internet providers.
Infrastructure issues have also stemmed from internal operational errors. In 2015, Google identified that Symantec’s Thawte-branded Certificate Authority had improperly issued an unauthorized certificate covering Google domains during internal software testing. While that incident was determined to be an internal operational failure rather than an external cyberattack, subsequent inquiries revealed that numerous additional certificates had been improperly issued.
Future Safeguards for the HTTPS Ecosystem
Google noted that it will continue collaborating with the broader web community to mitigate the impact of temporary DNS and routing compromises on global web safety.
To build resilience against future tampering, the company underscored its long-term strategic commitments within the HTTPS ecosystem. These initiatives include pushing for shorter certificate validity periods and restricting Domain Control Validation (DCV) reuse through the Chrome Root Program and the recently introduced Chrome Quantum-resistant Root Program.














