When DNS Says the Attacker Is You: Lessons from the Recent ccTLD Hijacks

In late September 2026, attackers compromised infrastructure supporting three country-code top-level domains: .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa). By manipulating authoritative Domain Name System (DNS) records, they passed domain-control validation checks and obtained unauthorized HTTPS certificates for domains belonging to Google and other organizations.

Google disclosed the attacks on October 6, and Ars Technica reported how the attackers exploited the domain registries to obtain certificates. Google’s systems were not compromised, and the issuing certificate authorities (CAs) had followed established validation procedures.

That is what makes this incident troubling. The certificates were technically valid, but their issuance was never authorized by the legitimate domain owners. Even an organization with a complete inventory of its managed certificates could miss a certificate obtained by an attacker through compromised DNS infrastructure.

The attacks raise a question for enterprise security teams: How do you detect certificates issued in your organization’s name when they never passed through your certificate management systems?

How the attack path worked

For a publicly trusted certificate, an applicant must demonstrate control of the requested domain. Automated domain control validation may rely on DNS or other approved methods. If an attacker gains control over authoritative DNS, the attacker may be able to make the validation evidence appear legitimate from the CA’s perspective.

The sequence in this case was straightforward:
1. Attackers compromised infrastructure associated with the country-code top-level domains (ccTLDs).
2. They changed authoritative DNS records or delegations for selected domains.
3. Those changes allowed them to satisfy domain control validation.
4. Publicly trusted CAs issued certificates on the basis of the control they could observe.
5. The certificates became visible in public Certificate Transparency logs.
6. Defenders had to identify, block, revoke, and investigate the unauthorized certificates.

The resulting certificates were not necessarily malformed, cryptographically broken, or issued outside the CA’s prescribed process. They were unauthorized from the domain owner’s perspective because the validation signal itself had been compromised.

This is why the shorthand “fraudulent certificate” can obscure the architectural issue. The stronger question is: Who authorized this issuance, and what evidence can the enterprise use to distinguish its own certificates from certificates obtained during a temporary loss of domain control?

Your certificate inventory and the public record are different views

Traditional certificate discovery answers questions such as:

• Which certificates are deployed across our networks, applications, cloud environments, and endpoints?
• Which certificates are nearing expiration?
• Which use weak algorithms, disallowed key sizes, or unexpected issuers?
• Who owns them, and how will they be renewed or replaced?
• Automated certificate discovery to explain internal discovery and unmanaged certificates

Those questions remain essential. But this incident requires an additional one:

What certificates does the Public Key Infrastructure (PKI) say have been issued for our domains, including certificates that never passed through our systems?

A certificate obtained by an attacker may never appear on an enterprise-managed endpoint. It may not exist in the organization’s CA account, ticketing workflow, or known certificate inventory. Yet once it is logged, Certificate Transparency creates an external signal that defenders can observe.

Google recommends ongoing Certificate Transparency (CT) monitoring across the entire domain portfolio, including parked and regional ccTLD properties. That scope matters. A neglected regional domain can still carry the organization’s name, attract user trust, and become useful to an attacker.

CT, however, does not label a certificate as malicious. It records issuance. The enterprise must determine whether the event was expected.

That determination requires correlation with authoritative context, including:

• approved domains and subject alternative names;
• approved public CAs and CA accounts;
• expected keys or key-generation workflows;
• authorized certificate profiles and validation methods;
• change records, application ownership, and issuance windows;
• current DNS, registrar, and registry state.

The useful alert is not simply “a certificate appeared.” It is “a certificate appeared that cannot be reconciled with an authorized enterprise workflow.”

Certification Authority Authorization (CAA) helps, but it is not a complete answer

CAA records allow a domain holder to specify which CAs may issue certificates for a domain. Extensions defined in RFC 8657 can further bind authorization to a specific Automatic Certificate Management Environment (ACME) account or validation method where supported.

CAA should be part of an enterprise’s preventive controls, but the limitation revealed by this incident is important: CAA is stored in DNS. During an active DNS or registry hijack, an attacker may be able to change the CAA records along with the other authoritative data.

Google therefore makes a more precise recommendation. After legitimate DNS control is restored, organizations should re-establish restrictive CAA records—ideally with authorized ACME account and validation-method bindings—to reduce the risk that an attacker can reuse cached domain-validation state to obtain more certificates.

CAA and CT play different roles:

• CAA constrains issuance when the CA receives authentic policy from DNS.
• CT exposes issuance so that domain owners and monitors can identify unexpected certificates.

Neither replaces strong registrar, registry, DNS, identity, and change-control protections. Defense comes from the controls reinforcing one another.

RFC 8659: Certification Authority Authorization for the technical explanation of CAA records

Build a detect-to-recover operating model

Organizations should treat unauthorized certificate issuance as a coordinated security incident, not only a PKI ticket.

1. Know the complete domain portfolio

Maintain an authoritative inventory of production, regional, defensive, parked, legacy, and acquired domains. Assign ownership and ensure that regional properties are not excluded from monitoring because they receive less traffic.

2. Monitor external issuance continuously

Watch CT for all covered domains and relevant subdomains. Compare each observed certificate with approved issuers, accounts, profiles, names, keys, and change records. Tune the process to distinguish expected automation from unexplained issuance without suppressing meaningful anomalies.

3. Protect the validation plane

Harden registrar and DNS administration with phishing-resistant authentication, least privilege, separation of duties, protected recovery procedures, and alerts for changes to nameservers, delegations, DNS records, and CAA policy. Use DNSSEC where it is operationally appropriate, while recognizing that no single control removes every registry-level risk.

4. Prepare a cross-team response

Define how PKI, DNS, SOC, application, legal, communications, and vendor-management teams will coordinate. A response playbook should cover certificate identification, CA contact, revocation requests, browser or platform escalation where appropriate, DNS restoration, credential rotation, traffic review, and impact assessment.

5. Verify recovery rather than assuming it

Restoring DNS is necessary, but it does not prove that the incident is over. Recheck delegations and CAA, confirm certificate revocation status, inspect CT for follow-on issuance, determine whether cached validation could be reused, and continue heightened monitoring through the relevant risk window.

Where certificate lifecycle management fits

Certificate lifecycle management provides the operating foundation for this model: discovery, centralized inventory, ownership, policy, issuer visibility, lifecycle workflows, audit records, and remediation at scale. A CA-agnostic view is especially important when an incident spans certificates issued outside the organization’s normal CA relationship.

But the lesson is broader than maintaining a clean internal inventory. Enterprises need to reconcile three views of trust:

1. What the organization authorized through policy and workflow.
2. What is deployed across applications, services, and infrastructure.
3. What the public Web PKI issued for the organization’s domains.

Gaps between those views are security signals.

AppViewX CLM continuously discovers certificates published in Certificate Transparency (CT) logs, giving security teams visibility into certificates issued for their domains, including those outside normal issuance workflows. Organizations can correlate this discovery data with approved certificate inventories, issuance policies, and change records to identify potentially unauthorized certificates, investigate suspicious activity, and coordinate remediation.

Certificate lifecycle management when introducing AppViewX capabilities
CA agility when discussing replacement and remediation across certificate authorities

The control plane must see beyond the certificate

The ccTLD hijacks did not break certificate cryptography. They compromised a signal the issuance process was designed to trust.

That is precisely why organizations need independent visibility. A certificate can be publicly trusted, correctly signed, transparently logged, and still be unauthorized by the enterprise whose identity it represents.

The practical response is not to abandon automated issuance. It is to make automation accountable: know every domain, monitor public issuance, constrain CAs and accounts, correlate certificates with approved workflows, and prepare to revoke and recover quickly when those views diverge.

In modern PKI operations, the question is no longer only, “What certificates do we manage?” It is also, “What certificates exist in our name and can we prove that we authorized them?”

Know which certificates your organization has authorized.

AppViewX CLM gives security teams centralized certificate visibility, policy-backed governance, and automated lifecycle management across public and private certificate authorities.

See how AppViewX CLM works or request a demo to learn how to strengthen certificate visibility and control.

Sources

1. Security Blog, “Chrome’s Response to Recent ccTLD Registry Hijacks,” October 6, 2026.
2. Certificate Transparency project, Certificate Transparency overview.
3. IETF, RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record.
4. IETF, RFC 8657: CAA Record Extensions for Account URI and ACME Method Binding.
5. AppViewX, Certificate Lifecycle Management.
6. AppViewX, CA Agility.