decrypted · 8 october 2026 · vulnerabilities and patching · supply chain · digital sovereignty

Hijacked country registries mint real Google certificates: the trust chain nobody audits

Last week, attackers took over the registries behind three country-code domains: .gh for Ghana, .sl for Sierra Leone and .as for American Samoa. According to the Chrome team's account, published on 6 October, they then used that control to obtain genuine HTTPS certificates for Google domains and other organisations. Google says its own systems were not breached. The weakness sat a level below the website, in the address book that the whole certificate system quietly trusts.

A notary who phones the number in the directory

Before a certificate authority issues a certificate, it checks that the applicant controls the domain. Usually that check reads the domain's DNS records, the public directory that says where a name lives. Imagine a notary asked to certify that a stranger owns a house. The notary rings the number listed in the town hall directory. If someone has rewritten the directory, the notary calls the burglar, hears the right answers and stamps the paperwork.

The attackers changed authoritative DNS records at the registries, which let them pass the automated validation checks. The certificates were real, and the browser padlock would have appeared. The certificate authorities followed their rules; the input they trusted had been poisoned.

What a defender could see

Every certificate that Chrome trusts by default must be disclosed in public Certificate Transparency logs, and analysis of those logs is how the unauthorised certificates were found. Chrome then blocked them through CRLSets, its emergency revocation list, and Google contacted the issuing authorities to arrange formal revocation, so protection extends beyond Chrome.

Google was candid about the limits. It said it cannot guarantee that its analysis found every affected domain, and that Chrome's interventions do not reliably protect people using other browsers.

The Secure by Design lesson

Certificate issuance rested on a single chain: registry, then DNS, then proof of control. Compromise one link and the checks downstream pass honestly. Two controls from Google's guidance fit that gap, and neither is expensive.

Watch Certificate Transparency for every domain you own. Include the defensive registrations, the overseas ones and the forgotten ones. Someone must read the alerts.
Publish restrictive CAA records bound to your own ACME account. Google is honest that CAA cannot stop issuance during an active DNS hijack. Its value is afterwards: it stops attackers reusing validation once you regain control.

The structural fix is slower. Google says it is working through the Chrome Root Program on shorter certificate lifetimes and less reuse of domain validation, which shrinks the window in which a moment of stolen DNS control stays useful.

For UK organisations, the reporting names no UK registry. The question is dependency. Many firms hold names under foreign country codes for brand protection or overseas trading, and many suppliers run services on them. Your control over your own identity online includes the registries and DNS hosts you never chose and rarely audit.

Two questions for this week's risk meeting:

Which registries and DNS providers sit beneath our domains, including those held for defensive reasons?
If a name were hijacked for a day, what could be issued in our name, and how fast could we revoke it?

Opinion, not advice: a padlock proves a check was passed, not that it was sound.

Also this week

FortiBleed is still being used against firewalls. BleepingComputer reports that the FBI warned on 7 October that attacks on exposed FortiGate firewalls and SSL VPN gateways are ongoing, with intruders creating new administrator accounts and deleting legitimate ones. The FBI said the chain has been seen as an initial entry point for ransomware affiliates. The leak itself dates from June, when Singapore's Cyber Security Agency advised that credentials for over 70,000 devices had been exposed after brute-force and credential-stuffing attempts against internet-facing portals. Its advice: multi-factor authentication, restricted external management access, and FortiOS 7.4, 7.6 or 8.0 for stronger password hashing. A management interface open to the world is a design choice, not an accident.

A ransomware recovery boss is charged. US prosecutors say Zohar Pinhasi, owner of MonsterCloud, was arraigned in Brooklyn on 7 October on one count of wire fraud conspiracy and two of wire fraud. They allege that between June 2018 and June 2023 the firm claimed proprietary decryption while actually paying the criminals, charging clients more than $19 million against more than $8 million in ransoms. In one example, about $8,200 was paid and about $150,000 charged. An indictment is an allegation, and he is presumed innocent. The practical question for any UK board: does our recovery supplier pay ransoms, and would we be told first?

Outlook will block MSIX attachments. Microsoft's message centre says that from early November, completing by mid-November, Outlook on the web and new Outlook for Windows will block .msix and .msixbundle files by default, added to the BlockedFileTypes list in every OWA mailbox policy, custom ones included. Microsoft expects few organisations to be affected. If you do exchange these packages, allow them deliberately beforehand. A safe default with a conscious exception is Secure by Design working as intended.

Sources