ccTLD DNS Hijacks: How to Detect & Block Rogue TLS Certificates

Executive Summary

On October 6, 2026, Google’s Chrome Secure Web and Networking Team disclosed a critical infrastructure supply-chain intrusion: threat actors breached multiple third-party country-code top-level domain (ccTLD) registry operators, modifying authoritative DNS records and obtaining unauthorized HTTPS/TLS certificates for regional Google domains and several leading international brands. The confirmed compromises impact the national top-level namespaces of Ghana (`.gh`), Sierra Leone (`.sl`), and American Samoa (`.as`).

The incident highlights a severe asymmetric blindspot in internet trust architecture: while Google’s internal networks and servers remained unbreached, controlling the authoritative top-level registry allowed attackers to modify delegation records (NS, A, and TXT). By injecting automated ACME dns-01 validation records into authoritative zone files, the adversaries induced legitimate, public Certificate Authorities (CAs) to issue cryptographically valid X.509 certificates.

Possessing both authoritative DNS control and valid TLS certificates enabled the attackers to route user traffic to malicious servers and conduct transparent adversary-in-the-middle (AiTM) decryption without triggering standard browser security warnings. Google countered the campaign by deploying emergency CRLSets updates across Chrome to instantly distrust the fraudulent certificates, working with issuing CAs to execute global revocations, and mining Certificate Transparency (CT) logs to alert other impacted multinational organizations.

---

Technical Vulnerability Analysis & Attack Chain

Authoritative DNS hijacking at the registry level bypasses end-user defenses and perimeter firewalls by striking at the root delegation layer of the Domain Name System.

Root-Cause & Exploitation Mechanics

The security failure occurred within third-party ccTLD registry management systems rather than within victim organizations or Certificate Authority protocols:

• ccTLD Registry Administration Compromise: Attackers compromised credentials, administrative portals, or registry-registrar software stacks utilized by regional registry operators managing .gh, .sl, and .as. With root registry authority, the attackers bypassed two-factor authentication and registrar-level protections configured on individual customer domains.
• Authoritative Zone Redirection: The threat actors altered the authoritative nameserver (NS) pointers and root glue records for high-profile domains (including google.com.gh, google.com.sl, and regional services of global enterprises). Inquiries directed to root DNS servers for these ccTLDs were redirected to rogue nameservers operated by the adversary.
• ACME DCV Subversion via DNS-01: Certificate Authorities verify domain ownership prior to issuance through automated Domain Control Validation (DCV). Under the Automated Certificate Management Environment (ACME / RFC 8555) dns-01 challenge, a CA requests that the applicant publish a specific cryptographic token under _acme-challenge.<domain>. Because the adversaries controlled the authoritative DNS responses, they fulfilled the challenge effortlessly, obtaining valid TLS certificates from public CAs that operated strictly according to CA/Browser Forum Baseline Requirements.
• DCV Cache Reuse Window Exploitation: Once a CA verifies domain control, Baseline Requirements permit the CA to cache the validation status for up to 398 days (often configured between 30 and 90 days). Even after legitimate administrators detect an incident and restore proper DNS records, attackers holding a cached validation state can continue to request fresh certificates unless explicit Certification Authority Authorization (CAA) restrictions are deployed.
• Chrome CRLSets Countermeasure: Standard Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) checks introduce significant latency and privacy concerns in modern browsers, leading most engines to omit hard-fail OCSP checking. Google utilized CRLSets—an out-of-band component updater in Chrome that pushes compressed lists of revoked serial numbers directly to clients within minutes—to block the rogue certificates ahead of standard CA revocation propagation.

---

MITRE ATT&CK Tactics, Techniques & Procedures (TTPs)

---

Threat Actor Profile & Campaign Attribution

While Google and incident responders have not publicly attributed the operation to a specific threat actor, the operational methodology strongly resembles sophisticated advanced persistent threat (APT) state-sponsored campaigns historically tracked by intelligence analysts:

• Campaign Ancestry (Sea Turtle & DNSpionage): State-aligned groups (such as the Turkish-nexus Sea Turtle / Teal Kurma and Iranian-nexus DNSpionage clusters) have repeatedly demonstrated capabilities in breaching regional telecommunications authorities, national registrars, and ccTLD operators across the Middle East, North Africa, and Europe to harvest diplomatic, intelligence, and commercial telemetry.
• Target Footprint: Rather than targeting only local organizations, the attackers prioritized multinational technology leaders and global consumer brands holding regional ccTLD assets. By intercepting regional traffic flows at national boundaries, adversaries execute targeted surveillance on domestic citizens, visiting foreign officials, and multinational corporate personnel operating within those jurisdictions.

---

Detection & SOC Mitigation Playbook

1. Concrete Remediation & Workarounds

Enterprise security architecture teams and DNS administrators must enforce defensive controls across all domain registrations:

Step 1: Deploy Strict CAA Records with ACME Account Bindings

Configure Certification Authority Authorization (CAA) DNS records that restrict issuance to authorized Certificate Authorities and bind issuance strictly to your organization's specific ACME account URI and validation method:

; Restrict certificate issuance to authorized CA and specific ACME Account ID
example.com.gh.    IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678; validationmethods=dns-01"
example.com.gh.    IN CAA 0 issue "digicert.com; accounturi=https://api.digicert.com/account/987654"

; Block wildcard certificate issuance completely
example.com.gh.    IN CAA 0 issuewild ";"

; Direct CAs to report unauthorized certificate issuance attempts via iodef
example.com.gh.    IN CAA 0 iodef "mailto:security-cirt@example.com"

Note: While CAA records will be bypassed during the active window of a DNS hijack (because the attacker controls the DNS response), CAA records provide a mandatory firewall immediately after DNS control is recovered, preventing attackers from utilizing cached domain control validation (DCV) to mint subsequent certificates.

Step 2: Implement Registry Lock Protocols

Contact the regional ccTLD registry or enterprise registrar to activate out-of-band Registry Lock status on critical domains:

• serverUpdateProhibited
• serverDeleteProhibited
• serverTransferProhibited

Registry locks prevent automated changes to nameserver delegations, requiring manual out-of-band verification (such as multi-party cryptographic authentication or telephone verification) before root registry zone files can be altered.

Step 3: Implement Automated Certificate Transparency (CT) Ingestion

Deploy automated monitoring of public Certificate Transparency logs for every domain in your organization's portfolio, including parked domains and regional ccTLDs:

# Automated CT monitoring lookup via Certstream or crt.sh API
curl -s "https://crt.sh/?q=%.google.com.gh&output=json" | jq '.[] | {id: .id, issuer: .issuer_name, name: .name_value, not_before: .not_before}'

2. Network & Perimeter Defenses

• Strict DNSSEC Validation: Enforce DNSSEC validation across corporate recursive resolvers. If a hijacked ccTLD breaks cryptographic delegation chains (DS records in the parent zone), validating resolvers will return SERVFAIL rather than routing clients to adversary IP addresses.
• DNS Egress Monitoring: Alert on corporate endpoints resolving regional ccTLD domains to external IP addresses outside documented cloud and CDN provider ASN ranges.

3. Endpoint Detection & Hunting Query

Validated Sigma Rule (YAML)

title: Anomalous Certificate Transparency Issuance for Regional ccTLD Assets
id: 9a2f1c84-3b52-4a01-9c31-7e81b942d512
status: experimental
description: Detects unexpected TLS certificate issuance for corporate ccTLD domain assets (.gh, .sl, .as) from unapproved Certificate Authorities or with suspicious validity periods.
author: CyberNewsAI Threat Research Team
date: 2026/10/07
references:
  - https://blog.google/security/chromes-response-to-recent-cctld-registry-hijacks/
  - https://www.bleepingcomputer.com/news/security/hackers-hijack-google-domains-after-breaching-cctld-registries/
logsource:
  category: certificate
detection:
  selection_cctld:
    subject_common_name|endswith:
      - '.gh'
      - '.sl'
      - '.as'
      - '.com.gh'
      - '.com.sl'
  filter_approved_cas:
    issuer_organization|contains:
      - 'Corporate Internal CA'
      - 'Authorized Enterprise CA'
  condition: selection_cctld and not filter_approved_cas
falsepositives:
  - Authorized certificate rotations executed by regional subsidiaries
level: high
tags:
  - attack.resource_development
  - attack.t1588.004
  - attack.t1195.002

Microsoft Sentinel / Defender KQL Hunting Query

// Microsoft Sentinel: Hunting for Rogue DNS Resolution & Anomaly Lookups in ccTLD Namespaces
// Identifies endpoints querying regional ccTLDs resolving to unapproved IP ranges
let MonitoredCCTLDs = dynamic([".gh", ".sl", ".as", ".com.gh", ".com.sl"]);
let ApprovedCorporateASNs = dynamic([15169, 16509, 13335, 8075]); // Google, AWS, Cloudflare, Microsoft
DnsEvents
| where TimeGenerated >= ago(14d)
| where QueryType == "A"
| extend DomainSuffix = tostring(split(Name, ".")[-1])
| where Name endswith ".gh" or Name endswith ".sl" or Name endswith ".as"
| project TimeGenerated, ClientIP, Name, IPAddresses, SubType
| mv-expand ResolvedIP = split(IPAddresses, ",")
| extend ResolvedIPStr = tostring(trim(" ", ResolvedIP))
| where isnotempty(ResolvedIPStr)
| summarize QueryCount = count(), UniqueClients = make_set(ClientIP), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by Name, ResolvedIPStr
| order by QueryCount desc

Splunk Hunting Query (SPL)

index=* sourcetype IN ("stream:dns", "pan:dns", "bro:dns", "suricata:dns")
| where match(query, ".(gh|sl|as)$")
| stats count values(query) as queried_domains values(answer) as resolved_ips by src_ip, query_type
| eval alert_type="ccTLD Regional Query Anomaly"
| where count > 1
| sort - count

---