Phishing invisibile: i caratteri Unicode nascondono le esche ai controlli

Microsoft scopre una campagna di phishing da milioni di email che inserisce caratteri Unicode invisibili nelle parole per confondere alcuni filtri. La difesa passa da normalizzazione, segnali multipli e analisi OCR.

Una parola può apparire perfettamente normale sullo schermo e, allo stesso tempo, risultare diversa per il software che la analizza. È proprio su questa differenza che fa leva una campagna di phishing osservata da Microsoft: gli aggressori inseriscono caratteri Unicode invisibili all’interno dei termini utilizzati con l’obiettivo di confondere alcuni sistemi di filtraggio della posta elettronica.

L’uso di caratteri non visibili, spazi a larghezza zero e simboli simili tra loro rappresenta da tempo un metodo di evasione contro filtri antispam e controlli basati su corrispondenze testuali. La novità riguarda soprattutto la famiglia di caratteri scelta, la scala dell’operazione e il legame con una tecnica diventata nota nel campo della sicurezza dell’intelligenza artificiale: ASCII smuggling.

I ricercatori Microsoft hanno rilevato un aumento improvviso dell’attività il 9 febbraio 2026. Il giorno precedente i sistemi di ricerca avevano contato circa 21.000 messaggi compatibili con la firma utilizzata; il 9 febbraio il dato è salito oltre 1,3 milioni. Nelle settimane successive la campagna ha raggiunto picchi compresi tra 1 e 2,37 milioni di messaggi al giorno. L’attività ad alto volume è poi proseguita per mesi.

Come funziona il trucco dei caratteri Unicode invisibili

Il meccanismo è più semplice di quanto possa sembrare. Prendiamo una parola italiana come prestito. Un aggressore può inserire tra pre e stito il carattere U+E0020, denominato TAG SPACE. Il destinatario continua a leggere visivamente prestito, perché quel codice Unicode normalmente non produce alcun glifo sullo schermo. Per un programma che confronta invece la sequenza di caratteri ricevuta con la stringa letterale prestito, invece, le due rappresentazioni non coincidono più.

Lo stesso vale per termini come credito, finanziamento, mutuo o offerta. A video possono apparire del tutto normali, mentre nel codice sottostante contengono uno o più caratteri aggiuntivi. Il filtro che cerca una parola esatta potrebbe quindi non riconoscerla, anche se per l’utente non cambia assolutamente nulla.

La differenza diventa ancora più evidente considerando che U+E0020 appartiene al blocco Unicode Tags, compreso tra U+E0000 e U+E007F. Unicode definisce in quest’area una serie di caratteri speciali collegati a rappresentazioni basate sui simboli ASCII. Furono introdotti inizialmente per inserire informazioni di tagging direttamente nel testo; l’uso per identificare la lingua è stato successivamente abbandonato e oggi alcuni tag trovano ancora applicazione nelle sequenze emoji.

L’aggressore non deve modificare graficamente il messaggio, ricorrere a immagini o creare parole palesemente deformate. Basta inserire un carattere che l’utente non vede ma che rimane presente nei dati elaborati dal sistema di posta.

Il legame con gli attacchi contro gli assistenti AI

I caratteri del blocco Tags hanno attirato molta attenzione nel 2025 soprattutto per gli attacchi di prompt injection.

L’idea, in quel caso, consisteva nel nascondere istruzioni nel contenuto di una pagina web, di un documento o di un messaggio: una persona non vede nulla di particolare, mentre un modello linguistico che riceve la rappresentazione completa del testo può elaborare anche i caratteri nascosti.

Il principio è curioso perché nella campagna di phishing Microsoft l’obiettivo si ribalta. Negli attacchi contro l’AI si tenta di mostrare qualcosa al software nascondendolo all’essere umano; nelle email analizzate si cerca invece di mantenere una parola leggibile per la persona alterandone la rappresentazione interna così da ridurre l’efficacia di alcuni controlli automatici.

È anche per questo motivo che Microsoft ha scoperto l’attività quasi per caso: la logica di ricerca che ha evidenziato il picco di phishing basato su ASCII smuggling era nata per individuare possibili tentativi di prompt injection nelle email destinate ai sistemi AI. I ricercatori si aspettavano istruzioni nascoste per modelli linguistici; hanno trovato invece messaggi finanziari che sfruttavano gli stessi caratteri per evitare i filtri.

Normalizzare il testo prima di cercare parole sospette

La mitigazione principale indicata da Microsoft parte da un principio abbastanza semplice: normalizzazione Unicode prima dell’applicazione di firme, espressioni regolari e controlli basati sulle parole.

Un sistema di filtraggio dovrebbe identificare e rimuovere, oppure gestire in modo esplicito, i caratteri invisibili che non hanno una funzione lecita nel testo analizzato. Solo dopo questa operazione di pulizia conviene eseguire la ricerca delle parole chiave. In tal modo una stringa come pre[U+E0020]stito torna logicamente equivalente a “prestito” e il separatore invisibile perde la sua funzione evasiva.

È utile anche conservare il segnale originario. Se il filtro cancella semplicemente il carattere prima dell’analisi, perde infatti un’indicazione che potrebbe risultare preziosa: incontrare TAG SPACE nel mezzo di una comune parola italiana costituisce un comportamento decisamente insolito. Meglio quindi normalizzare una copia destinata all’analisi testuale e, parallelamente, attribuire un punteggio di rischio alla presenza del codice anomalo.

Lo stesso trattamento dovrebbe precedere l’invio di email, documenti o pagine Web verso assistenti AI. In pratica, sanificare il testo una sola volta a monte permette di ridurre sia il rischio di evasione dei filtri antiphishing sia quello di prompt injection basata su contenuti invisibili.

OCR come seconda rappresentazione del messaggio

Microsoft cita un’altra difesa interessante utilizzata da Defender: la generazione di una rappresentazione visiva del contenuto e la successiva analisi tramite OCR. È un approccio concettualmente diverso dalla normale lettura del codice HTML.

Se un utente vede la parola prestito, anche l’OCR applicato alla versione renderizzata tenderà a ricostruire prestito, ignorando il carattere invisibile che altera la sequenza originale. Il confronto tra testo sorgente e testo visibile può quindi rivelare discrepanze sospette.

Naturalmente si tratta di una tecnica più costosa rispetto a una semplice ricerca testuale: renderizzare milioni di messaggi e sottoporli a riconoscimento ottico richiede risorse, quindi non tutti i gateway di posta implementano controlli di questo tipo allo stesso livello.

Ti consigliamo anche

Link copiato negli appunti