Nella prima settimana di ottobre 2026 qualcuno ha preso il controllo del DNS di tre registri di domini nazionali, .gh (Ghana), .sl (Sierra Leone) e .as (Samoa Americane), e lo ha usato per farsi emettere certificati HTTPS validi per diversi domini di Google e di altre organizzazioni. Non è stata violata Google, e non è stata ingannata nessuna autorità di certificazione: è stato aggirato l'anello più debole della catena, cioè la prova di «possedere» un dominio.

Cosa è successo

Secondo il Chrome Secure Web and Networking Team di Google, che ha pubblicato la propria analisi il 6 ottobre, gli attaccanti hanno compromesso gli operatori di terze parti che gestiscono questi tre ccTLD e hanno modificato i record DNS autorevoli. Chi controlla il DNS autorevole di un dominio può superare la domain control validation (DCV), il controllo con cui una CA verifica che chi chiede il certificato governi davvero il dominio. Il risultato è un certificato tecnicamente legittimo, emesso da una CA regolare, ma richiesto da chi non doveva averlo.

I dettagli confermati da Google e ripresi da SecurityWeek, Help Net Security e Infosecurity Magazine sono questi:

  • i certificati non autorizzati riguardano diversi domini Google e domini di altre organizzazioni, tra cui, scrive Google, «diversi grandi marchi globali e servizi online molto diffusi»;
  • Google afferma che i propri sistemi non sono stati compromessi e di non avere motivo di ritenere che le CA emittenti abbiano commesso errori;
  • Chrome ha bloccato i certificati tramite CRLSet e Google ha lavorato con le CA per revocarli, così da proteggere anche client diversi da Chrome;
  • l'analisi dei log di Certificate Transparency ha permesso di individuare le altre organizzazioni coinvolte, che Google ha contattato quando possibile;
  • Google ammette di non poter garantire di aver individuato tutti i domini interessati.

Restano non noti, almeno nelle fonti pubbliche che abbiamo potuto verificare: l'identità degli attaccanti, le date esatte dell'intrusione, il numero di certificati emessi, l'elenco completo delle organizzazioni colpite e il modo in cui i tre operatori sono stati compromessi. Segnaliamo esplicitamente questi vuoti perché la cronaca delle prime ore tende a riempirli con ipotesi.

Perché è un attacco diverso dal solito

Un certificato falso emesso da una CA compromessa è un incidente classico, e il sistema ha anticorpi collaudati. Qui il meccanismo è più insidioso: il certificato è vero, la CA ha seguito le regole, e la falla sta nel fatto che la fiducia nel DNS è a monte di tutto. Con certificato valido e DNS dirottato, un attaccante può in teoria impersonare un sito in un attacco man-in-the-middle senza far comparire alcun avviso nel browser.

Due considerazioni che sono nostra analisi e non dichiarazioni di Google:

  1. DNSSEC non basta a risolvere il problema quando a essere compromesso è il registro stesso, perché chi gestisce la zona può cambiare anche i record DS di delegazione. Per questo la difesa efficace è la combinazione di trasparenza (CT) e vincoli di emissione (CAA), non una singola tecnologia.
  2. Il blocco lato browser è una rete di sicurezza, non una difesa. Google stessa avverte che non bisogna affidarsi solo a quello: Chrome copre i propri utenti, mentre applicazioni, librerie, client API e altri browser possono accettare il certificato finché non è revocato e la revoca viene effettivamente controllata.

Google annuncia come risposta di lungo periodo la riduzione della validità dei certificati e del riuso delle validazioni DCV già completate, attraverso il Chrome Root Program. Il riuso è esattamente il punto che rende questo tipo di attacco più duraturo: una validazione ottenuta durante il dirottamento può essere sfruttata anche dopo che il DNS è stato ripristinato.

Cosa significa per le aziende italiane

Nessuna fonte indica che domini italiani (.it) siano stati toccati, e non è questo il punto. Il rischio concreto per un'organizzazione italiana riguarda tre scenari.

Portafoglio di domini dimenticati. Molte aziende registrano decine di domini difensivi, regionali o di campagna con suffissi esotici, oggi spesso nelle mani di agenzie o reparti marketing e non censiti dall'IT. Un dominio «a effetto» sotto un ccTLD (i cosiddetti domain hack, come i brand che usano .as o simili) è proprio il tipo di asset che nessuno monitora. Se uno di questi è stato colpito, l'impatto può essere phishing con certificato valido sul vostro marchio.

Dipendenza da terzi che non controllate. L'incidente mostra che la sicurezza del vostro dominio dipende anche dal registro che lo ospita, un soggetto con cui non avete alcun contratto diretto. Per i soggetti NIS2 questo è un caso di scuola della gestione del rischio della catena di approvvigionamento prevista dal D.Lgs. 138/2024: l'inventario delle dipendenze deve includere registrar, registri, provider DNS e CA, non solo i fornitori software.

Rilevamento. Pochissime PMI e molte realtà medie non monitorano i log CT. Senza questo controllo, un certificato emesso abusivamente per il vostro dominio resta invisibile finché non lo usa un attaccante.

Sul piano normativo, se un certificato abusivo viene effettivamente usato per intercettare traffico che contiene dati personali, si configura potenzialmente una violazione di sicurezza da valutare ai sensi degli artt. 33-34 GDPR (notifica al Garante entro 72 ore se il rischio è probabile); per i soggetti NIS2 si valuta la notifica di incidente significativo al CSIRT Italia secondo i tempi previsti dal decreto. Il consulente consiglia di documentare comunque la valutazione, anche quando la conclusione è «nessuna notifica».

Cosa fare subito

  • Censire tutti i domini di proprietà dell'azienda, inclusi quelli parcheggiati, regionali e di campagne passate, e verificare in particolare quelli sotto .gh, .sl e .as.
  • Attivare il monitoraggio dei log di Certificate Transparency per l'intero portafoglio (servizi gratuiti e strumenti open source consentono di ricevere un avviso a ogni nuova emissione) e rivedere le emissioni recenti per domini sotto i tre ccTLD.
  • Pubblicare record CAA restrittivi, limitando le CA autorizzate e, dove la CA lo supporta, vincolando l'emissione a specifici account ACME e metodi di validazione. Google chiarisce che la CAA non impedisce l'emissione durante un dirottamento in corso, ma impedisce di riusare validazioni in cache dopo il ripristino.
  • Non delegare la difesa al browser: prevedere per le app e i client critici il controllo effettivo della revoca e, dove possibile, il certificate pinning.
  • Aggiornare il piano di risposta agli incidenti con lo scenario «certificato emesso abusivamente»: chi contatta la CA per la revoca, chi comunica ai clienti, chi valuta la notifica.
  • Rivedere i contratti e l'inventario dei fornitori critici (registrar e provider DNS inclusi) in ottica NIS2.