ccTLD Registry Breach: Hackers Hijack Google Domains in Ghana, American Samoa, and Sierra Leone — DNS and Certificate Defense Guide

When attackers compromise the registry operator for an entire country-code top-level domain, every organization registered under that TLD inherits the breach. That's exactly what happened here: threat actors breached third-party operators of the ccTLDs for Ghana (.gh), American Samoa (.as), and Sierra Leone (.sl), modified authoritative DNS records, hijacked Google domains under those TLDs, and — critically — obtained unauthorized, publicly trusted HTTPS certificates for the hijacked domains. This is not a Google vulnerability. It is a supply-chain compromise of the DNS trust hierarchy itself, and it has direct implications for any organization whose domains live under a ccTLD operated by a third party.

Introduction

The DNS ecosystem runs on delegated trust. Your registrar trusts the TLD registry; the TLD registry trusts its operators; browsers trust certificate authorities that validate domain control — often via DNS. This attack chain exploited every one of those trust relationships. By gaining access to the registry operators' systems, the attackers were able to alter authoritative nameserver or glue records for targeted domains, redirect traffic to infrastructure they controlled, and then pass domain control validation (DCV) to have a certificate authority issue legitimate-looking TLS certificates for domains they did not own.

The result: users visiting what appeared to be valid Google properties under these ccTLDs could be served attacker-controlled content over a connection their browser reported as secure — valid padlock, valid certificate, wrong destination. That combination neutralizes the two most common user-facing security signals (HTTPS and the lock icon) and enables credential harvesting, malware delivery, and traffic interception at scale.

There is no CVE for this campaign — this is an operational compromise of registry infrastructure, not a software bug. The defensive lessons, however, are concrete and immediately actionable.

Technical Analysis

Affected Scope

• Targeted domains: Multiple Google domains registered under the .gh (Ghana), .as (American Samoa), and .sl (Sierra Leone) ccTLDs.
• Compromised layer: Third-party operators of the ccTLD registries — the entities that maintain the authoritative zone data for the entire TLD. This is above the registrar and above any individual domain owner in the trust chain.
• Attack surface: Any domain registered under a ccTLD whose registry operations are outsourced to a third-party operator. Many smaller ccTLDs are run by contracted technical providers, sometimes a single company operating dozens of TLDs.

How the Attack Works

From a defender's perspective, the attack chain breaks down as follows:

1. Initial compromise of the registry operator. The attackers breached the systems used to manage the ccTLD zone — the administrative panels or EPP (Extensible Provisioning Protocol) infrastructure that controls nameserver delegations.
2. Modification of authoritative DNS records. With registry-level access, the attackers changed the delegation for targeted domains, pointing them at attacker-controlled nameservers. At this point, all DNS resolution for the victim domains flows through attacker infrastructure.
3. Certificate issuance via DNS-based DCV. With control of DNS, the attackers satisfied domain control validation at a certificate authority (most ACME-style flows — e.g., DNS-01 or HTTP-01 challenges — become trivially passable once you control the zone). A publicly trusted TLS certificate was issued for the hijacked domains.
4. Traffic interception with valid TLS. Attacker infrastructure served content for the hijacked domains over connections that passed browser certificate validation. From the user's perspective, nothing looked wrong.

Why This Defeats Conventional Controls

• The certificate is real. It was issued by a trusted CA through a legitimate validation path. It will not trigger certificate warnings.
• DNSSEC at the domain level may not help if the registry itself is compromised and controls the DS records in the parent zone — though registry-level DNSSEC with monitoring of DS record changes raises the bar significantly.
• Endpoint controls see nothing anomalous. The connection is to an IP serving a valid cert for the requested hostname. Detection has to happen at the DNS resolution and network telemetry layer, or through external monitoring of your DNS and certificate posture.

Exploitation Status

This is confirmed active exploitation in the wild — the hijacks occurred, DNS records were modified, and unauthorized certificates were issued. This is not a theoretical attack path. Registry and registrar compromises are a recurring, proven technique (historically used by groups like Sea Turtle and in numerous Middle East–focused campaigns), and this incident demonstrates the technique remains viable in 2026.

Detection & Response

Detection for registry-level DNS hijacking lives in three places: DNS resolution telemetry (are your domains resolving to expected infrastructure?), network telemetry (are your users connecting to your domains at unexpected IPs/ASNs?), and external monitoring (certificate transparency logs and zone-file change detection). The rules below target the first two.

---
title: High-Value Domain Resolving to Unexpected IP Range
description: Detects DNS responses where corporate or high-value domains resolve to IP addresses outside known-good netblocks, indicating possible DNS hijacking at the registry, registrar, or resolver level. Baseline the expected netblocks for your monitored domains before deployment.
references:
  - https://attack.mitre.org/techniques/T1557/002/
  - https://www.bleepingcomputer.com/news/security/hackers-hijack-google-domains-after-breaching-cctld-registries/
author: Security Arsenal
status: experimental
date: 2026/04/06
tags:
  - attack.t1557.002
  - attack.collection
logsource:
  category: dns
detection:
  selection_domains:
    query|contains:
      - '.gh'
      - '.as'
      - '.sl'
  filter_expected:
    answer|cidr:
      - '142.250.0.0/15'
      - '172.217.0.0/16'
      - '172.253.0.0/16'
      - '216.58.192.0/19'
      - '74.125.0.0/16'
      - '34.0.0.0/9'
  condition: selection_domains and not filter_expected
falsepositives:
  - Google-operated IPs change over time; maintain the expected netblock list against current Google ASN 15169 prefixes
  - CDN-fronted domains not served from Google address space
level: high
---
title: TLS Certificate With Recent Issuance on Non-Standard Server for Monitored Domain
description: Detects network connections to monitored high-value domains where the TLS certificate issuer or server characteristics diverge from the known-good baseline, a potential indicator of a rogue certificate issued after DNS hijacking. Requires TLS inspection or JA3/JA4-capable network monitoring.
references:
  - https://attack.mitre.org/techniques/T1557/
  - https://www.bleepingcomputer.com/news/security/hackers-hijack-google-domains-after-breaching-cctld-registries/
author: Security Arsenal
status: experimental
date: 2026/04/06
tags:
  - attack.t1557
  - attack.t1071.001
logsource:
  category: network_connection
detection:
  selection:
    DestinationHostname|endswith:
      - '.gh'
      - '.as'
      - '.sl'
  filter_known_issuer:
    TlsIssuer|contains:
      - 'Google Trust Services'
      - 'GTS CA'
  condition: selection and not filter_known_issuer
falsepositives:
  - Legitimate certificate authority migrations by the domain owner
  - Third-party services hosted on ccTLD domains using other CAs
level: medium

For environments ingesting firewall, proxy, or EDR network telemetry into Microsoft Sentinel, the following KQL hunts for connections to Google ccTLD properties that resolve outside Google's address space — the clearest internal signal of a delegation hijack.

// Hunt: Connections to Google ccTLD domains resolving outside Google ASN 15169 space
// Google publishes its IP ranges at https://www.gstatic.com/ipranges/goog.json — update the list accordingly
let GooglePrefixes = dynamic(["8.8.4.0/24","8.8.8.0/24","34.0.0.0/9","74.125.0.0/16","142.250.0.0/15","172.217.0.0/16","172.253.0.0/16","216.58.192.0/19","216.239.32.0/19"]);
let SuspiciousTLDs = dynamic([".gh",".as",".sl"]);
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| extend RemoteUrlLower = tolower(RemoteUrl)
| where RemoteUrlLower has_any (SuspiciousTLDs)
| extend IsGoogleIp = tostring(GooglePrefixes) // evaluate against prefix list
| where not(ipv4_is_in_any_range(RemoteIP, "142.250.0.0/15", "172.217.0.0/16", "172.253.0.0/16", "216.58.192.0/19", "74.125.0.0/16", "8.8.8.0/24", "8.8.4.0/24"))
| summarize ConnectionCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), Devices = dcount(DeviceName)
  by RemoteUrl, RemoteIP, InitiatingProcessFileName
| order by ConnectionCount desc

// Hunt: Proxy/firewall syslog for DNS answers pointing Google ccTLD domains at non-Google infrastructure
// For environments shipping Zeek/Suricata/firewall logs via CEF or Syslog connectors
Syslog
| where TimeGenerated > ago(7d)
| where SyslogMessage has_all ("google", "answer")
| where SyslogMessage has_any (".google.com.gh", ".google.com.as", ".google.sl")
| extend ParsedAnswer = extract(@"answer[\s:=]+([0-9]{1,3}(\.[0-9]{1,3}){3})", 1, SyslogMessage)
| where isnotempty(ParsedAnswer)
| where not(ipv4_is_in_any_range(ParsedAnswer, "142.250.0.0/15", "172.217.0.0/16", "216.58.192.0/19", "74.125.0.0/16"))
| summarize AnswerCount = count(), DistinctResolvers = dcount(HostIP)
  by ParsedAnswer, Computer
| order by AnswerCount desc

For endpoint-side forensics — validating whether hosts on your network recently resolved or connected to hijacked infrastructure — Velociraptor can enumerate active connections and cross-reference them against your known-good netblocks.

-- Hunt for established connections to ccTLD-hijacked domain destinations
-- Flag connections to Google-related hostnames terminating outside Google address space
SELECT Pid, Name, Exe, Username,
       netstat().RemoteIP AS RemoteIP,
       netstat().RemotePort AS RemotePort,
       netstat().Status AS ConnStatus
FROM pslist()
WHERE ConnStatus =~ 'ESTABLISHED'
  AND Name =~ '(?i)(chrome|firefox|msedge|iexplore|brave|opera|curl|wget|powershell)'
  AND NOT RemoteIP =~ '^(142\.250\.|142\.251\.|172\.217\.|172\.253\.|216\.58\.|74\.125\.|8\.8\.[48]\.|34\.)'

-- Pull DNS cache on endpoints to identify recently resolved ccTLD Google domains
-- and check whether cached answers point outside expected netblocks (Windows endpoints)
SELECT * FROM execve(argv=['powershell.exe', '-NoProfile', '-Command',
  "Get-DnsClientCache | Where-Object {\$_.Entry -match 'google.*\\.(gh|as|sl)'} | Select-Object Entry, Data, TimeToLive | ConvertTo-Csv -NoTypeInformation"])

Remediation and Hardening

You cannot patch a trust chain — but you can instrument it, constrain it, and shrink the blast radius. The following steps are ordered by defensive impact.

1. Audit Your ccTLD Exposure

Enumerate every domain your organization owns under ccTLDs. For each, identify the registry operator and its security posture. Domains under ccTLDs operated by small third-party technical providers carry registry-compromise risk you do not control. Where business need does not mandate the ccTLD presence, consolidate to gTLDs with stronger registry controls, or accept and monitor the risk explicitly.

2. Deploy Certificate Transparency Monitoring — This Is the Highest-Value Control

Every publicly trusted certificate is logged to CT logs. A rogue certificate for your domain will appear there, typically within hours. Monitor CT logs for all domains you own:

#!/bin/bash
# ct-monitor.sh — Query crt.sh for recently issued certificates for your domains
# Run daily via cron; alert on any new issuance from an unexpected CA

DOMAINS=("yourdomain.com" "yourdomain.co.gh" "yourdomain.as")
EXPECTED_ISSUERS="Google Trust Services|Let's Encrypt|DigiCert|Sectigo|Amazon"
OUTPUT_DIR="/var/log/ct-monitor"
mkdir -p "$OUTPUT_DIR"

for DOMAIN in "${DOMAINS[@]}"; do
  TODAY=$(date +%F)
  CURRENT="$OUTPUT_DIR/${DOMAIN//./_}_${TODAY}.json"
  curl -s "https://crt.sh/?q=%25.${DOMAIN}&output=json" -o "$CURRENT"

  # Extract issuers seen in the last 7 days
  UNEXPECTED=$(jq -r '.[] | select(.not_before > "'$(date -d '7 days ago' +%F)'") | .issuer_name' "$CURRENT" 2>/dev/null | sort -u | grep -Ev "$EXPECTED_ISSUERS")

  if [ -n "$UNEXPECTED" ]; then
    echo "[ALERT] Unexpected CA issued certificates for ${DOMAIN} in the last 7 days:"
    echo "$UNEXPECTED"
    # Pipe to your alerting pipeline (mail, webhook, SIEM forwarder)
  fi
done

3. Enforce CAA Records

A Certification Authority Authorization (CAA) DNS record restricts which CAs are permitted to issue certificates for your domain. It would not have stopped a registry-level compromise outright (an attacker controlling the zone can modify CAA), but it adds friction, creates another tamperable record to monitor, and stops rogue issuance in scenarios where the attacker controls web content but not DNS.

# Check current CAA posture for your domains
dig CAA yourdomain.com +short
dig CAA yourdomain.co.gh +short

# Example: restrict issuance to specific CAs and enable incident reporting
# Add these records at your DNS provider:
# yourdomain.com.  CAA 0 issue "pki.goog"
# yourdomain.com.  CAA 0 issue "letsencrypt.org"
# yourdomain.com.  CAA 0 iodef "mailto:security@yourdomain.com"

4. Monitor Authoritative DNS for Unauthorized Changes

Registry compromise manifests as a change to your delegation records (NS, DS, glue). Alert on any change.

#!/bin/bash
# ns-watch.sh — Detect unauthorized changes to authoritative nameserver delegations

DOMAINS=("yourdomain.co.gh" "yourdomain.as")
STATE_DIR="/var/lib/ns-watch"
mkdir -p "$STATE_DIR"

for DOMAIN in "${DOMAINS[@]}"; do
  STATE_FILE="$STATE_DIR/${DOMAIN//./_}.ns"
  CURRENT=$(dig NS "$DOMAIN" +short | sort)

  if [ -f "$STATE_FILE" ]; then
    if ! diff <(cat "$STATE_FILE") <(echo "$CURRENT") > /dev/null; then
      echo "[CRITICAL] Nameserver delegation changed for ${DOMAIN}"
      echo "Previous: $(cat "$STATE_FILE" | tr '\n' ' ')"
      echo "Current:  $(echo "$CURRENT" | tr '\n' ' ')"
      # This is a P1 event — page the IR team. A delegation change you did not
      # authorize means assume registry or registrar compromise.
    fi
  fi
  echo "$CURRENT" > "$STATE_FILE"
done

# Also monitor DS records (DNSSEC chain of trust) at the parent zone:
# dig DS yourdomain.co.gh +short — a change here means the DNSSEC trust anchor was altered

5. Registry Lock and Registrar Hardening

• Enable registry lock (not just registrar lock) on all high-value domains. Registry lock requires out-of-band, manual verification with the registry before any delegation change — it directly counters this attack class.
• Enforce MFA on registrar and DNS provider accounts, with hardware keys where supported.
• Review which accounts can modify DNS and prune aggressively. Apply change-control to DNS the same way you do to production code.

6. Enable and Validate DNSSEC

Sign your zones and verify the DS records at the parent. DNSSEC does not fully protect against a compromised registry (which can alter DS records), but it protects against every resolver-level and man-in-the-middle variant of this attack, and DS record changes are a high-fidelity compromise indicator.

7. HSTS Preloading for High-Value Domains

HSTS preload ensures browsers refuse non-HTTPS connections, and combined with CT monitoring, it narrows the window in which a rogue certificate is useful to an attacker. For internal-facing domains, consider certificate pinning at the application layer for mobile apps and API clients — pinning would have caused hard failures against the rogue certificates in this campaign.

8. Incident Response: If You Suspect Your Domain Was Hijacked

1. Verify current delegation: dig NS yourdomain +trace and compare against your authorized nameservers.
2. Pull CT logs immediately (crt.sh/?q=%.yourdomain) and identify any certificates you did not request.
3. Report unauthorized certificates to the issuing CA for revocation — CAs are required by CA/Browser Forum Baseline Requirements to revoke mis-issued certificates within defined timelines (24 hours to 5 days depending on severity).
4. Contact the registry and registrar through out-of-band channels; assume their ticketing/communication systems may also be compromised.
5. Rotate any credentials or sessions that may have transited the hijacked domain during the exposure window.
6. File reports with CISA (report@cisa.gov) and your national CERT — registry-level compromises affect every registrant under the TLD, not just you.

Key Takeaways

• The padlock lied. This campaign produced valid, publicly trusted certificates for hijacked domains. Certificate warnings alone cannot be your tripwire — CT log monitoring can.
• Your ccTLD domains inherit the security posture of their registry operator. Audit that posture; you are exposed to it whether you assessed it or not.
• Registry lock + CAA + DNSSEC + CT monitoring + delegation change alerting is the defense-in-depth stack for this attack class. Each layer covers gaps in the others.
• Detect at the resolution layer. Internally, the most reliable signal is a high-value domain resolving outside its expected netblocks. Build that baseline now, before you need it.

Registry and registrar compromises are a mature, repeatedly proven attack path. If your organization's domain portfolio includes ccTLDs — and especially if those domains carry brand or authentication trust — treat this incident as your tabletop scenario for next quarter.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub