Immagine illustrativa generata con AI
ASCII smuggling, i caratteri Unicode invisibili ora ingannano anche i filtri antispam
L'ASCII smuggling usa tag Unicode invisibili per eludere filtri antispam e antiphishing: come funziona, perché inganna l'AI e i dati Microsoft.
Testo generato da intelligenza artificiale, pubblicato senza revisione umana. Trasparenza IA
Dalla prompt injection alle campagne email
L’ASCII smuggling, già associato agli attacchi di prompt injection contro sistemi di intelligenza artificiale, viene ora impiegato per ridurre l’efficacia dei filtri antispam e antiphishing.
La tecnica inserisce caratteri Unicode normalmente invisibili dentro parole che restano leggibili dal destinatario. Il software di sicurezza, tuttavia, può elaborare una sequenza diversa da quella percepita sullo schermo. Una parola sospetta appare integra a una persona, ma viene spezzata o alterata durante l’analisi automatica.
Microsoft ha osservato questa modalità di evasione in Microsoft Defender for Office. Le rilevazioni associate all’ASCII smuggling sono aumentate rapidamente: in un giorno di inizio febbraio sono passate da circa 21.000 a oltre 1,3 milioni. Quattro giorni dopo avevano raggiunto quota 2,5 milioni.
L’attività è proseguita per mesi, per poi diminuire bruscamente a metà maggio. I dati comprendono anche rilevazioni giornaliere di firme Unicode legate a domini mittente a tema finanziario, monitorate tra il 9 febbraio e il 18 giugno 2026.
Non è stata attribuita la campagna a un gruppo specifico. I responsabili vengono descritti genericamente come spammer, senza indicazioni sulla loro provenienza o sulle infrastrutture utilizzate.
Come funzionano i tag Unicode invisibili
Il metodo sfrutta un blocco composto da 128 caratteri Unicode tag, capace di riprodurre quasi interamente una porzione dell’ASCII, l’American Standard Code for Information Interchange.
Questi caratteri possono essere interpretati dai sistemi informatici, ma sono stati progettati per non essere normalmente visibili agli esseri umani. Per esempio, il codice U+E0041 rappresenta la lettera maiuscola “A”, mentre U+E0061 corrisponde alla “a” minuscola.
Negli attacchi contro applicazioni basate su modelli linguistici, i tag possono occultare istruzioni inserite in email, documenti o altri contenuti non attendibili. L’utente non vede il comando, ma un agente AI potrebbe comunque elaborarlo e agire di conseguenza.
Nello spam il principio viene rovesciato. L’obiettivo non è nascondere un’istruzione a una persona, bensì impedire che il filtro riconosca correttamente una parola che l’utente continua a vedere.
Tra i termini manipolati figurano importi in dollari e parole inglesi ricorrenti nelle offerte finanziarie, come “credit”, “term” e “funding”. Sono espressioni che possono contribuire al punteggio di rischio assegnato a un messaggio.
Inserendo un tag invisibile al centro di “funding”, la parola può apparire normale sullo schermo. Il filtro, invece, potrebbe trattarla come due segmenti separati: “fun” e “ding”.
Un carattere citato in questo contesto è U+E0020. Quando viene collocato all’interno di una stringa, il suo effetto dipende da come il sistema esegue parsing, normalizzazione e tokenizzazione.
Perché anche i classificatori AI possono sbagliare
L’ASCII smuggling non mette in difficoltà soltanto le espressioni regolari o i controlli basati sulla corrispondenza esatta di una stringa. Può interferire anche con i classificatori che utilizzano machine learning, elaborazione del linguaggio naturale e modelli linguistici.
Questi sistemi non analizzano necessariamente una frase come la vede una persona. Il testo viene spesso suddiviso in token o sub-token, cioè unità numeriche utilizzate dal modello per classificare il contenuto.
Un carattere invisibile inserito nel mezzo di una parola può produrre diversi risultati. Il tokenizer potrebbe separare “funding” in “fun”, nel tag Unicode inatteso e in “ding”. Potrebbe anche generare token rari o sconosciuti, che il modello ha incontrato poco durante l’addestramento.
In entrambi i casi viene meno una caratteristica utile alla classificazione. Il modello non riceve più il termine atteso, ma una rappresentazione anomala che potrebbe pesare meno nella valutazione del rischio.
Il risultato cambia se il sistema normalizza il testo prima della tokenizzazione. Rimuovendo il carattere invisibile, il filtro potrebbe ricostruire correttamente “funding”. Una normalizzazione incompleta o applicata nel punto sbagliato della pipeline, però, lascia intatta l’evasione.
Qui si trova il problema centrale: il contenuto visivo e quello sottostante non coincidono.
Una difesa basata esclusivamente sulla stringa Unicode analizza ciò che è codificato nel messaggio. Un destinatario reagisce invece a ciò che viene visualizzato dal client di posta. Per confrontare i due livelli può essere necessario renderizzare il contenuto e sottoporlo a riconoscimento ottico dei caratteri, anziché fidarsi soltanto del testo estratto.
Un’evoluzione di tecniche usate da decenni
L’occultamento di parole nei messaggi indesiderati non è una novità. Da decenni gli spammer inseriscono spazi a larghezza zero, spazi non separabili e altri caratteri speciali per alterare le sequenze esaminate dalle espressioni regolari.
I tag Unicode aggiungono però una variante meno familiare ad alcuni sistemi di difesa. Filtri progettati per intercettare le manipolazioni più comuni potrebbero non trattare questi codici come elementi sospetti o ignorabili.
Il vantaggio non riguarda soltanto le vecchie regole testuali. L’inserimento dei tag può alterare direttamente la rappresentazione fornita ai modelli ML e NLP, spostando il problema dalla ricerca di parole alla robustezza dell’intera pipeline linguistica.
La stessa proprietà aveva già reso l’ASCII smuggling utile nella prompt injection indiretta. Un’applicazione AI può acquisire contenuti da email, siti o documenti e interpretare istruzioni che l’utente non vede. Nell’evasione antispam, invece, il testo è destinato a essere visto, ma non riconosciuto correttamente dalla macchina.
Sono due impieghi differenti della medesima discrepanza.
Impatto e prodotti coinvolti
Microsoft Defender for Office è il prodotto nel quale Microsoft ha rilevato il forte aumento delle firme. La questione, tuttavia, può interessare più in generale piattaforme email, gateway antiphishing, tokenizer, analizzatori testuali e classificatori basati su ML o NLP.
Non sono indicati altri prodotti o produttori specifici. Non sono state rese note versioni interessate, build vulnerabili o particolari configurazioni esposte.
Non si tratta inoltre di una vulnerabilità formalizzata. Non risultano un identificativo CVE, un punteggio CVSS o una classificazione di gravità; di conseguenza non c’è una voce nel catalogo Known Exploited Vulnerabilities della CISA né una scadenza federale di aggiornamento.
L’impatto dipende dal ruolo svolto dai termini offuscati nella classificazione complessiva. L’ASCII smuggling non garantisce da solo che un’email superi tutti i controlli, ma può sottrarre segnali linguistici usati per identificare spam, truffe finanziarie e phishing.
Per i destinatari il rischio è concreto: messaggi fraudolenti potrebbero raggiungere la casella di posta pur contenendo espressioni che, senza offuscamento, avrebbero contribuito al blocco.
Come rendere i filtri più resistenti
Microsoft ha fornito indicazioni di progettazione agli sviluppatori, ma non è noto uno specifico aggiornamento software o workaround per Microsoft Defender for Office.
I filtri dovrebbero innanzitutto identificare i caratteri Unicode tag e gli altri elementi invisibili, registrandone la presenza come possibile segnale di offuscamento. Affidarsi a una lista di parole sospette non basta.
La normalizzazione deve essere controllata e coerente. È utile confrontare il testo originale con quello ottenuto dopo la rimozione o trasformazione dei caratteri invisibili, evitando però che il processo introduca nuove ambiguità.
Va inoltre verificato il comportamento del tokenizer. Un aumento di token sconosciuti, rari o inattesi all’interno di parole comuni può costituire un indicatore utile, soprattutto nei messaggi a tema finanziario.
Nei sistemi a maggiore rischio, il confronto tra testo sottostante e contenuto effettivamente visualizzato può includere rendering e OCR. Questa soluzione richiede più risorse, ma riduce la distanza tra ciò che analizza il filtro e ciò che vede il destinatario.
Infine, le regole non dovrebbero concentrarsi solo sulle singole parole. La presenza ripetuta di tag Unicode, combinata con domini finanziari, richieste di pagamento, link o altri segnali sospetti, offre una base più robusta per rilevare l’abuso.
L’ondata osservata da Microsoft mostra che la tecnica non è più confinata alla sicurezza degli LLM. È diventata uno strumento operativo nelle campagne email, sfruttando lo stesso punto debole: una macchina può leggere un testo diverso da quello mostrato a una persona.
Fonti
Questo articolo è una rielaborazione originale basata sulle fonti seguenti.
