ccTLD Hijacks and Rogue Certificates: What To Do

On 6 October, Google disclosed that attackers had compromised the operators of three country-code top-level domains: .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa). With control of those zones, they changed authoritative DNS records and obtained trusted HTTPS certificates for Google domains under those suffixes. Google says its own systems weren't breached and the certificate authorities that issued the certificates did nothing wrong. Certificate Transparency logs also showed certificates for other organisations, which Google described as including "several leading global brands and widely used online services."

Most organisations don't own a .gh or .sl domain, so it's tempting to file this under someone else's problem. The bigger lesson is uncomfortable: whoever controls DNS for one of your domains can get a valid certificate for it, read its email and impersonate it convincingly. You may not control every layer that DNS depends on.

What happened

The registries, not the brands, were compromised. Google says the attackers compromised the third-party ccTLD operators. It hasn't said how, or who was responsible.
DNS control was enough to get certificates. Certificate authorities issue a certificate when the requester proves control of the domain, usually through DNS or a web challenge. If the attacker answers for the domain, the attacker passes the check.
Certificate Transparency caught it. Public CT logs record every certificate a trusted CA issues. The Hacker News searched them and found 12 certificates for seven domains, issued between 22 and 27 September. All had been revoked by 7 October. That search covered only a small set of names, so the real total may be higher.
Browser protection is partial. Chrome blocked the certificates through its CRLSets mechanism, and Google worked with the CAs to revoke them. Google was blunt about the limits: "browser-side intervention should not be relied on to protect your users." Other browsers, apps and mail clients don't get Chrome's protection.

Why this matters beyond three ccTLDs

DNS control means more than a certificate

A trusted certificate makes a phishing page look right, but the same DNS control does more damage in a Microsoft 365 estate. Change the MX record and an attacker can receive mail for the domain, including password reset links and supplier invoices. Change Autodiscover and some clients can be pointed elsewhere. Add a TXT record and they may pass domain-control checks with other cloud services. A short hijack can leave long-lived access behind.

Regional and parked domains are the soft spot

Large organisations collect country-code domains: local marketing sites, acquisitions, defensive registrations bought and forgotten. They often sit with different registrars, have no owner and get no monitoring. They also look legitimate to your customers and staff in that country, which makes them the ideal lure.

Your security depends on operators you don't choose

You can harden your registrar account, but you can't audit a national registry. A registry compromise bypasses registrar locks and DNSSEC, because the registry is the party that publishes and signs the delegation. That puts more weight on what you can control: detection and limiting what a hijacker can get.

Who should act

Anyone with domains under .gh, .sl or .as. Review CT logs for those names now.
Organisations with a large or poorly inventoried domain portfolio, especially regional ccTLDs.
Anyone whose Microsoft 365 tenant has custom domains outside their main registrar, since those domains route mail and appear in sign-in names.

Detection: watching for certificates and mail you didn't expect

Monitor Certificate Transparency for every domain you own

CT monitoring is the control that exposed this campaign, and it's cheap. Free search services and commercial monitors will alert you when a certificate is issued for any of your names. Microsoft Defender External Attack Surface Management also inventories certificates it sees for your assets. Whichever you use, feed it the full domain list, including parked and regional names. Then decide who receives the alerts and what they do when they don't recognise an issuer.

Watch for mail that claims to be you and fails DMARC

If an attacker controls a domain's DNS, some mail sent in your name may start passing checks. Mail that fails them is still a useful signal that someone is trying. This query is a starting point for Defender XDR or Sentinel. Replace the domain list with your own and tune it before alerting on it.

let MyDomains = dynamic(["example.co.uk", "example.com.gh", "example.sl"]);
EmailEvents
| where Timestamp > ago(30d)
| where EmailDirection == "Inbound"
| where SenderFromDomain in~ (MyDomains)
| extend Auth = parse_json(AuthenticationDetails)
| where tostring(Auth.DMARC) !in~ ("pass", "bestguesspass")
| summarize Messages = count(), Recipients = dcount(RecipientEmailAddress),
            Subjects = make_set(Subject, 5), SourceIPs = make_set(SenderIPv4, 10)
          by SenderFromDomain, DMARC = tostring(Auth.DMARC)
| order by Messages desc

Check your own DNS from the outside

Periodically resolve the NS, MX and key A and CNAME records for each domain from outside your network, and compare them with what you expect. A change you didn't make is an incident, whatever the record.

Mitigation

Inventory every domain. List the registrar, registry, DNS host, owner and purpose of each. Retire the domains you don't need and move the rest onto as few well-protected registrar accounts as you can.
Publish strict CAA records. A CAA record (RFC 8659) names the CAs allowed to issue for a domain. Go further with the accounturi and validationmethods parameters from RFC 8657, so issuance is tied to your own CA account. Google points out that CAA can't stop issuance during an active hijack, since the attacker controls the records. It does stop the attacker reusing a domain validation that a CA cached during the hijack after you've regained control.
Lock what you can. Use registrar lock and, where offered, registry lock, plus MFA and restricted access on registrar accounts. These won't help against a compromised registry, but they close the far more common route of a hijacked registrar login.
Enforce DMARC. Move every domain, including parked ones that never send mail, to p=reject, and publish null SPF and MX records for domains that don't send or receive.
Have a playbook for an unexpected certificate. Know how to file a certificate problem report with the issuing CA, who confirms whether DNS was changed, and who checks mail flow and sign-in logs for the affected domain.

How a managed SOC helps

Domain and certificate abuse tends to surface as weak signals in places that belong to different teams: a CT alert in a mailbox nobody reads, a DMARC report in a spreadsheet, a spike in phishing reports from one country. Our SOCs are manned 24/7 and bring those signals into one investigation. On the managed service, senior analyst sign-off is the default. Our dark web monitoring watches for your brand and domains being offered or discussed, and a compromise assessment can confirm whether a DNS change you didn't make led anywhere.

If you're not sure how many domains your organisation owns, or who would notice a certificate issued for one of them, talk to our team.

Rogue Certificates For Real Brands: What The ccTLD Registry Hijacks Mean For Your Domains