161.894 coppie di domini .com visivamente simili erano già delegate nell’ottobre 2026. Non sono tutte truffe: alcune sono registrazioni difensive o siti legittimi in altre lingue. Il numero, però, rende inutile una regola ancora comune nelle PMI: “controlla bene l’indirizzo”. Un dominio può apparire familiare, avere un certificato TLS valido e superare i controlli visivi del browser, pur essendo diverso da quello dell’azienda.

Il problema si chiama typosquatting. La variante più difficile da riconoscere usa caratteri Unicode che assomigliano alle lettere latine. Un attaccante non deve violare WordPress, il provider email o il gestionale: gli basta costruire una copia credibile della pagina di accesso e portare una persona sul dominio sbagliato. Per ridurre il rischio servono controlli sul dominio, sul gateway di posta, sull’autenticazione e sui log. Nessuno dei quattro basta da solo.

Il caso che ha superato Chrome 154

Il 3 ottobre 2026 i ricercatori Ian Muscat e Leanne Briffa hanno documentato un caso concreto. Hanno registrato, per scopi di ricerca, un dominio scritto interamente con caratteri cirillici che a colpo d’occhio ricorda apple.com. Chrome 154 lo mostrava in Unicode nella barra degli indirizzi, con un certificato valido, invece di esporre la forma Punycode che inizia con xn--.

Chromium applica più livelli di controllo. Verifica se un’etichetta mescola alfabeti in modo sospetto, confronta caratteri confondibili e controlla il dominio contro una lista integrata di 8.462 nomi popolari, 836 dei quali ricevono una protezione più forte. Il dominio di prova è passato perché un carattere cirillico specifico non era nella lista dei 29 sosia usata dal controllo “whole-script”. Inoltre il suo skeleton, cioè la rappresentazione normalizzata impiegata per il confronto, restava a due modifiche dal nome latino: oltre la soglia considerata dal controllo di navigazione in quel caso.

Non è una prova che Chrome sia insicuro. È la dimostrazione di un limite strutturale: la somiglianza visiva dipende da carattere, font, alfabeto e contesto. Lo stesso Unicode Technical Standard #39 tratta i confusabili come un problema che richiede dati aggiornabili, profili restrittivi e confronti tramite skeleton; non promette un riconoscimento perfetto. Affidare la decisione a una sola interfaccia significa chiedere al browser di conoscere in anticipo ogni ambiguità possibile.

Perché HTTPS, SPF e DKIM non risolvono il problema

Tre segnali tecnici vengono spesso interpretati come prove di autenticità, ma rispondono a domande diverse.

  • HTTPS protegge la connessione con il dominio visitato. Un certificato valido non certifica che il sito appartenga al marchio che sembra rappresentare.
  • SPF dichiara quali server possono spedire posta per un dominio.
  • DKIM firma il messaggio per consentire al destinatario di verificarne provenienza e integrità.

Se l’attaccante possiede un dominio lookalike, può configurare correttamente TLS, SPF e DKIM per quel dominio. I controlli possono quindi passare senza dire nulla sulla somiglianza con il dominio aziendale. DMARC aggiunge una policy e l’allineamento con il dominio visibile nel campo From, ma continua a proteggere l’identità del dominio autentico: non impedisce a un altro dominio, registrato e configurato correttamente, di assomigliargli.

La ricerca ha testato anche 20 mittenti internazionalizzati. Nelle condizioni descritte dagli autori, Gmail Web li ha mostrati tutti in Unicode, mentre Outlook Web ha mostrato la forma A-label xn--. È un confronto dell’interfaccia, non dei filtri antispam: reputazione, scansione dei link e consegna non erano oggetto del test. La conseguenza operativa è precisa: non si può basare la formazione interna sul fatto che ogni client renda evidente il Punycode.

Lo stesso ragionamento vale per i certificati. CAA e Certificate Transparency aiutano a controllare chi può emettere certificati per il proprio dominio e a rilevare emissioni inattese, ma non bloccano automaticamente un dominio diverso. Ho descritto quel livello in questa guida a CAA e Certificate Transparency. Qui il rischio è l’impersonazione tramite un nome nuovo, non l’emissione abusiva sul dominio originale.

Audit pratico: costruisci la mappa degli asset

La prima difesa non è comprare decine di domini a caso. È stabilire che cosa merita protezione. Per una PMI partirei da un inventario di una pagina, con questi campi:

  • dominio principale e varianti nazionali realmente usate;
  • domini impiegati per email, newsletter, assistenza e fatturazione;
  • sottodomini di login, area clienti, pagamenti e amministrazione WordPress;
  • nomi dei prodotti o servizi che un cliente potrebbe cercare o digitare;
  • fornitori autorizzati a inviare messaggi per conto dell’azienda;
  • responsabile interno e procedura di escalation per ogni asset.

Per ogni dominio protetto genera una lista limitata di varianti plausibili: errori di battitura, trattini, estensioni alternative pertinenti, sostituzioni omografiche e forma Punycode. Il criterio non è “tutto ciò che può esistere”, ma “ciò che può ingannare un cliente in un flusso sensibile”. Login, bonifici, cambio IBAN, recupero password e caricamento documenti hanno priorità più alta di una pagina informativa.

Le registrazioni difensive hanno senso per pochi nomi ad alto impatto, soprattutto se il marchio è corto. La ricerca consiglia attenzione particolare ai nomi di quattro caratteri o meno, perché alcuni controlli di similarità di Chromium richiedono un target più lungo. Comprare ogni combinazione, invece, scala male e non copre i nuovi caratteri o TLD. Dopo il primo perimetro serve monitoraggio: nuove registrazioni xn--, certificati appena emessi, record DNS attivati e domini che iniziano a ospitare contenuti.

Definisci anche la risposta prima dell’incidente: raccolta di screenshot e header, segnalazione al registrar e al provider, blocco su DNS o proxy aziendale, avviso ai clienti e conservazione delle prove. Senza un proprietario del processo, un alert resta una riga in una dashboard.

Configura il gateway email per l’impersonazione

Il controllo più utile non è una blacklist statica, ma una policy che confronti i mittenti esterni con i domini e i nomi protetti dell’organizzazione. Google Workspace e Microsoft 365 offrono strumenti diversi secondo licenza, ma la logica operativa è comune:

  1. attiva la protezione da impersonazione per il dominio aziendale e per le identità più esposte, come amministrazione, direzione e contabilità;
  2. mantieni visibile un banner per i mittenti esterni, senza trasformarlo in rumore su ogni messaggio;
  3. crea una regola di audit per i domini mittente che iniziano con xn--;
  4. metti in quarantena, invece di cancellare subito, i messaggi che combinano dominio simile e richiesta sensibile;
  5. registra le eccezioni con proprietario e scadenza: una allowlist permanente è un debito di sicurezza.

La regola su xn-- non va applicata alla cieca. Un’azienda che lavora con mercati e lingue che usano IDN può ricevere posta legittima. Parti in modalità audit, misura il traffico per due settimane, costruisci una allowlist minima e passa al blocco solo dove il contesto lo permette. Per molte PMI italiane il volume sarà basso, ma va verificato sui propri log.

SPF, DKIM e DMARC restano obbligatori: limitano lo spoofing diretto del dominio autentico e migliorano la capacità di classificare i messaggi. La conclusione corretta non è che “non servono”, ma che risolvono un problema diverso. Il dominio lookalike va trattato con rilevamento di impersonazione, reputazione, contenuto e comportamento.

Le passkey tolgono all’utente la decisione più fragile

Una password può essere digitata su qualsiasi pagina che la richiede. Anche un codice OTP può essere copiato in tempo reale su un sito clone. Una passkey, invece, è legata all’identità del sito o dell’applicazione: browser e sistema operativo verificano il dominio prima di usare la credenziale. Google la definisce resistente al phishing proprio perché una passkey registrata sul sito corretto non viene proposta al dominio lookalike.

Questo cambia il modello di difesa. L’utente può non vedere la differenza tra due caratteri, ma il protocollo confronta l’origine. La protezione è particolarmente utile per:

  • account amministrativi WordPress;
  • caselle email e pannelli del provider;
  • gestionali, CRM e strumenti di fatturazione;
  • registrar, DNS, CDN e piattaforme di pagamento.

Non basta attivare una passkey su un account secondario. Parti dagli amministratori e dagli accessi che permettono di cambiare DNS, creare utenti o reimpostare altre credenziali. Mantieni un metodo di recupero controllato, registra più dispositivi quando la piattaforma lo consente e rimuovi le credenziali non più necessarie. Se il servizio non supporta passkey o chiavi FIDO2, usa almeno un secondo fattore non basato su SMS e limita l’accesso amministrativo.

Per WordPress la priorità è proteggere anche l’email collegata agli amministratori: chi controlla la casella può avviare il recupero password. Il login forte riduce il danno del phishing, mentre hardening, aggiornamenti e permessi minimi riducono ciò che accade dopo l’accesso. È lo stesso principio della difesa degli upload: un singolo controllo non deve trasformarsi nell’unica barriera. Un esempio tecnico è la configurazione che impedisce l’esecuzione di PHP nella cartella uploads di WordPress.

Un piano di 30 giorni per una PMI

Prima settimana: inventario e priorità. Elenca domini, sottodomini sensibili, provider e identità esposte. Verifica SPF, DKIM e DMARC del dominio autentico. Salva una baseline dei record DNS e dei certificati. Assegna un responsabile per gli alert.

Seconda settimana: email. Attiva o rivedi la protezione da impersonazione. Introduci il banner per mittenti esterni dove manca. Metti in audit i mittenti xn-- e le varianti dei domini protetti. Controlla i falsi positivi prima di bloccare.

Terza settimana: autenticazione. Abilita passkey o chiavi FIDO2 su registrar, DNS, posta, WordPress e servizi finanziari compatibili. Verifica i metodi di recupero e revoca gli accessi di ex collaboratori. Per gli strumenti senza supporto FIDO, documenta il controllo compensativo.

Quarta settimana: simulazione da tavolo. Non inviare phishing ai clienti. Usa un dominio e account controllati dall’azienda, senza coinvolgere terzi, per provare la catena di risposta: chi riceve l’alert, chi conserva le prove, chi blocca il dominio, chi prepara la comunicazione e quanto tempo serve. L’obiettivo non è cogliere in fallo le persone, ma trovare passaggi senza proprietario.

Misura quattro indicatori semplici: percentuale degli account critici coperti da passkey o FIDO2; tempo fra rilevamento ed escalation; numero di eccezioni nella allowlist; quota di domini e identità critiche coperte dal monitoraggio. Se un indicatore non cambia dopo 30 giorni, il piano è rimasto un documento.

Il typosquatting Unicode non si risolve chiedendo alle persone di osservare meglio la barra degli indirizzi. La scelta più efficace è spostare il controllo dall’occhio umano ai sistemi: monitoraggio dei domini, policy di impersonazione, passkey vincolate all’origine e log interrogabili.

La mia priorità, con budget limitato, è questa: proteggere prima registrar, DNS, email e amministratori WordPress con passkey o FIDO2; poi attivare la protezione da impersonazione; infine monitorare le varianti ad alto rischio. Le registrazioni difensive vengono dopo e solo per i nomi che potrebbero convincere un cliente a inserire credenziali o autorizzare un pagamento. È una difesa meno vistosa di una campagna di awareness, ma toglie all’utente la decisione nel punto in cui l’interfaccia può mentire meglio.

Fonti