ccTLD .gh, .sl e .as dirottati: certificati Google abusivi

📌 Sviluppi successivi: Node.js: dieci vulnerabilità corrette, quattro ad alto rischio (21 ottobre 2026) · eMudhra: chiavi CA banali, revoche e trust store da aggiornare (20 ottobre 2026)

Il 6 ottobre 2026 il Chrome Secure Web and Networking Team di Google ha reso nota una serie di attacchi contro tre domini di primo livello nazionali (ccTLD): .gh (Ghana), .sl (Sierra Leone) e .as (Samoa Americane). Durante i dirottamenti gli attaccanti hanno modificato i record DNS autorevoli e ottenuto certificati HTTPS non autorizzati per diversi domini di Google e per domini di altre organizzazioni. Google dice di essersene accorta la settimana precedente.

Non ci sono CVE: il problema non è un difetto di un prodotto, ma il controllo della risoluzione dei nomi a monte dei siti colpiti.

Cosa è successo

Secondo Google, i suoi sistemi non sono stati compromessi e, data la natura degli attacchi, non ci sono motivi per ritenere che le autorità di certificazione (CA) che hanno emesso i certificati abbiano sbagliato qualcosa. Google non ha indicato quali domini siano stati colpiti né quanti certificati siano stati ottenuti.

Sul modo in cui gli attaccanti hanno preso il controllo dei DNS, le fonti restano generiche: Infosecurity Magazine e The Hacker News parlano di compromissione dei registri dei tre ccTLD, mentre nelle dichiarazioni di Google riportate dalle testate si parla di dirottamenti con modifica dei record DNS autorevoli, senza dettagli sulla tecnica.

La risposta di Google, secondo Infosecurity Magazine:

• Chrome ha bloccato i certificati non autorizzati per le proprietà di Google tramite i CRLSets, il meccanismo con cui il browser blocca rapidamente certificati in caso di emergenza;
• Google ha lavorato con le CA emittenti per revocare i certificati, così da proteggere anche gli utenti di altri client;
• i log di Certificate Transparency (CT) hanno poi fatto emergere altre organizzazioni colpite, tra cui grandi marchi globali e servizi online molto diffusi: anche quei certificati sono stati bloccati in Chrome e Google ha contattato le organizzazioni, dove possibile.

Dettagli tecnici: perché un DNS dirottato basta

Una CA, prima di emettere un certificato, verifica che il richiedente controlli il dominio. Chi controlla i record DNS autorevoli può interferire con questa verifica e ottenere un certificato valido senza violare i sistemi del sito. Il risultato, come sottolinea The Register, è che l’attaccante dispone sia dell’instradamento del traffico (via DNS) sia della chiave privata del certificato:

1. gli utenti che digitano l’indirizzo corretto possono essere portati su una copia del sito;
2. il browser non mostra avvisi, perché il certificato è emesso da una CA fidata;
3. l’attaccante può intercettare o modificare i dati inviati al sito impersonato e sfruttare il marchio per phishing o distribuzione di malware.

C’è poi un effetto che dura oltre l’attacco. Le CA possono riutilizzare per un certo periodo una verifica del controllo del dominio già superata: secondo Google, anche dopo che il proprietario ha ripreso il controllo dei DNS, l’attaccante potrebbe sfruttare quella validazione in cache per ottenere nuovi certificati.

MITRE ATT&CK (classificazione nostra, le fonti non la indicano): T1584.001 (Compromise Infrastructure: Domains) per il dirottamento e T1588.004 (Obtain Capabilities: Digital Certificates) per i certificati ottenuti.

Impatto per le aziende europee e italiane

Il rischio diretto riguarda chi ha domini sotto .gh, .sl o .as, comprese registrazioni regionali o difensive, spesso parcheggiate e poco sorvegliate. La lezione però è generale: la fiducia in HTTPS dipende dalla sicurezza di tutta la catena DNS, dal registro al fornitore che gestisce la zona, e un dirottamento a monte non lascia tracce nei sistemi del sito impersonato.

Google stessa avverte che l’intervento lato browser non va considerato una protezione: la sua analisi potrebbe non aver individuato tutti i domini colpiti e i blocchi di Chrome non proteggono in modo affidabile chi usa altri client.

Per i soggetti NIS2, registrar e fornitori DNS fanno parte della catena di fornitura da considerare nella gestione del rischio. Un certificato emesso per un proprio dominio senza autorizzazione è un evento da analizzare anche ai fini della notifica allo CSIRT Italia dell’ACN.

Cosa fare subito

1. Fai l’inventario dei domini, compresi quelli parcheggiati e i ccTLD regionali: non si può sorvegliare ciò che non si conosce.
2. Monitora in modo continuo i log CT per tutti i domini: è il modo per sapere quasi in tempo reale quando qualcuno ottiene un certificato a tuo nome.
3. Se hai domini sotto .gh, .sl o .as, controlla subito le voci CT recenti alla ricerca di certificati inattesi.
4. Pubblica record CAA restrittivi, che indicano quali CA possono emettere certificati per il dominio. Google raccomanda di limitarli anche a specifici account ACME e metodi di validazione (estensioni accounturi e validationmethods), per esempio: 0 issue "ca.example; accounturi=https://ca.example/acct/123; validationmethods=dns-01". Durante un dirottamento attivo i CAA non bloccano l’emissione, perché l’attaccante controlla anche quei record; ripristinati dopo, però, impediscono di riutilizzare le validazioni in cache per ottenere nuovi certificati.
5. Non contare sul browser come unica difesa, soprattutto per utenti e applicazioni che non usano Chrome.

Google ha anche annunciato che continuerà a lavorare su modifiche all’intero ecosistema HTTPS, tra cui la riduzione della validità dei certificati e del riutilizzo della verifica del controllo del dominio.

Come aiuta ARXDOME

ARX Expose parte dai domini dichiarati per la tua azienda e ne mostra la superficie d’attacco, compresi nomi e certificati, con una verifica quotidiana; segnala anche i domini simili al tuo registrati da altri, spesso usati per il phishing. Con ARX Horizon puoi interrogare dal portale gli indicatori di compromissione e la reputazione di un indirizzo.

Ultimo aggiornamento: 8 ottobre 2026