ASCII smuggling : les caractères Unicode invisibles trompent désormais aussi les filtres antispam

De la prompt injection aux campagnes d’e-mails

L’ASCII smuggling, déjà associé aux attaques de prompt injection contre les systèmes d’intelligence artificielle, est désormais utilisé pour réduire l’efficacité des filtres antispam et antiphishing.

Cette technique consiste à insérer des caractères Unicode normalement invisibles au sein de mots qui restent lisibles par le destinataire. Le logiciel de sécurité peut toutefois traiter une séquence différente de celle qui apparaît à l’écran. Un mot suspect semble intact pour une personne, mais il est fragmenté ou altéré lors de l’analyse automatisée.

Microsoft a observé ce mode de contournement dans Microsoft Defender for Office. Les détections associées à l’ASCII smuggling ont rapidement augmenté : en une seule journée, au début du mois de février, elles sont passées d’environ 21 000 à plus de 1,3 million. Quatre jours plus tard, elles atteignaient 2,5 millions.

L’activité s’est poursuivie pendant plusieurs mois, avant de diminuer brutalement à la mi-mai. Les données comprennent également les détections quotidiennes de signatures Unicode liées à des domaines d’expédition à thème financier, surveillées entre le 9 février et le 18 juin 2026.

La campagne n’a pas été attribuée à un groupe précis. Ses responsables sont décrits de manière générique comme des spammeurs, sans indication sur leur origine ni sur les infrastructures utilisées.

Comment fonctionnent les balises Unicode invisibles

La méthode exploite un bloc composé de 128 caractères Unicode de type tag, capable de reproduire presque intégralement une portion de l’ASCII, l’American Standard Code for Information Interchange.

Ces caractères peuvent être interprétés par les systèmes informatiques, mais ils ont été conçus pour ne pas être normalement visibles par les êtres humains. Par exemple, le code U+E0041 représente la lettre majuscule « A », tandis que U+E0061 correspond au « a » minuscule.

Dans les attaques contre les applications reposant sur des modèles de langage, les balises peuvent dissimuler des instructions insérées dans des e-mails, des documents ou d’autres contenus non fiables. L’utilisateur ne voit pas la commande, mais un agent d’IA peut tout de même la traiter et agir en conséquence.

Dans le spam, le principe est inversé. L’objectif n’est pas de dissimuler une instruction à une personne, mais d’empêcher le filtre de reconnaître correctement un mot que l’utilisateur continue de voir.

Parmi les termes manipulés figurent des montants en dollars et des mots anglais courants dans les offres financières, tels que « credit », « term » et « funding ». Ces expressions peuvent contribuer au score de risque attribué à un message.

En insérant une balise invisible au milieu de « funding », le mot peut sembler normal à l’écran. Le filtre peut, quant à lui, le traiter comme deux segments distincts : « fun » et « ding ».

Un caractère cité dans ce contexte est U+E0020. Lorsqu’il est placé au sein d’une chaîne, son effet dépend de la manière dont le système effectue l’analyse syntaxique, la normalisation et la tokenisation.

Pourquoi les classificateurs d’IA peuvent eux aussi se tromper

L’ASCII smuggling ne met pas uniquement en difficulté les expressions régulières ou les contrôles fondés sur la correspondance exacte d’une chaîne. Il peut également perturber les classificateurs qui utilisent le machine learning, le traitement automatique du langage et les modèles de langage.

Ces systèmes n’analysent pas nécessairement une phrase telle qu’elle apparaît à une personne. Le texte est souvent divisé en tokens ou sous-tokens, c’est-à-dire des unités numériques utilisées par le modèle pour classer le contenu.

Un caractère invisible inséré au milieu d’un mot peut produire plusieurs résultats. Le tokenizer peut séparer « funding » en « fun », en la balise Unicode inattendue et en « ding ». Il peut également générer des tokens rares ou inconnus, que le modèle a peu rencontrés pendant son entraînement.

Dans les deux cas, une caractéristique utile à la classification disparaît. Le modèle ne reçoit plus le terme attendu, mais une représentation anormale susceptible de peser moins dans l’évaluation du risque.

Le résultat est différent si le système normalise le texte avant la tokenisation. En supprimant le caractère invisible, le filtre peut reconstruire correctement « funding ». Une normalisation incomplète ou appliquée au mauvais endroit de la chaîne de traitement laisse toutefois le contournement intact.

C’est là que se trouve le problème central : le contenu visuel et le contenu sous-jacent ne coïncident pas.

Une défense fondée exclusivement sur la chaîne Unicode analyse ce qui est encodé dans le message. Un destinataire réagit en revanche à ce qui est affiché par le client de messagerie. Pour comparer ces deux niveaux, il peut être nécessaire de restituer le contenu et de le soumettre à une reconnaissance optique des caractères, plutôt que de se fier uniquement au texte extrait.

L’évolution de techniques utilisées depuis des décennies

Dissimuler des mots dans des messages indésirables n’a rien de nouveau. Depuis des décennies, les spammeurs insèrent des espaces de largeur nulle, des espaces insécables et d’autres caractères spéciaux pour modifier les séquences examinées par les expressions régulières.

Les balises Unicode ajoutent toutefois une variante moins familière à certains systèmes de défense. Les filtres conçus pour intercepter les manipulations les plus courantes peuvent ne pas traiter ces codes comme des éléments suspects ou ignorables.

L’avantage ne concerne pas uniquement les anciennes règles textuelles. L’insertion de balises peut modifier directement la représentation fournie aux modèles ML et NLP, déplaçant le problème de la recherche de mots vers la robustesse de l’ensemble de la chaîne de traitement linguistique.

Cette même propriété avait déjà rendu l’ASCII smuggling utile dans la prompt injection indirecte. Une application d’IA peut récupérer du contenu depuis des e-mails, des sites ou des documents et interpréter des instructions que l’utilisateur ne voit pas. Dans le contournement des filtres antispam, le texte est au contraire destiné à être vu, mais pas correctement reconnu par la machine.

Il s’agit de deux usages différents d’une même divergence.

Impact et produits concernés

Microsoft Defender for Office est le produit dans lequel Microsoft a détecté la forte augmentation du nombre de signatures. Le problème peut toutefois concerner plus généralement les plateformes de messagerie, les passerelles antiphishing, les tokenizers, les analyseurs de texte et les classificateurs fondés sur le ML ou le NLP.

Aucun autre produit ou fabricant précis n’est cité. Aucune version concernée, build vulnérable ou configuration particulièrement exposée n’a été communiquée.

Il ne s’agit par ailleurs pas d’une vulnérabilité formalisée. Aucun identifiant CVE, score CVSS ou niveau de gravité n’est connu ; il n’existe donc aucune entrée correspondante dans le catalogue Known Exploited Vulnerabilities de la CISA ni aucune échéance fédérale de mise à jour.

L’impact dépend du rôle joué par les termes obfusqués dans la classification globale. L’ASCII smuggling ne garantit pas à lui seul qu’un e-mail franchira tous les contrôles, mais il peut supprimer des signaux linguistiques utilisés pour identifier le spam, les escroqueries financières et le phishing.

Pour les destinataires, le risque est concret : des messages frauduleux peuvent atteindre leur boîte de réception alors qu’ils contiennent des expressions qui, sans obfuscation, auraient contribué à leur blocage.

Comment renforcer la résistance des filtres

Microsoft a fourni des recommandations de conception aux développeurs, mais aucune mise à jour logicielle précise ni solution de contournement spécifique pour Microsoft Defender for Office n’est connue.

Les filtres devraient commencer par identifier les caractères Unicode de type tag et les autres éléments invisibles, et enregistrer leur présence comme un éventuel signal d’obfuscation. Se fier à une liste de mots suspects ne suffit pas.

La normalisation doit être contrôlée et cohérente. Il est utile de comparer le texte original avec celui obtenu après la suppression ou la transformation des caractères invisibles, tout en évitant que le processus n’introduise de nouvelles ambiguïtés.

Le comportement du tokenizer doit également être vérifié. Une augmentation du nombre de tokens inconnus, rares ou inattendus au sein de mots courants peut constituer un indicateur utile, notamment dans les messages à thème financier.

Dans les systèmes présentant les risques les plus élevés, la comparaison entre le texte sous-jacent et le contenu effectivement affiché peut inclure une restitution visuelle et un OCR. Cette solution nécessite davantage de ressources, mais réduit l’écart entre ce qu’analyse le filtre et ce que voit le destinataire.

Enfin, les règles ne devraient pas se concentrer uniquement sur les mots pris individuellement. La présence répétée de balises Unicode, combinée à des domaines financiers, des demandes de paiement, des liens ou d’autres signaux suspects, constitue une base plus robuste pour détecter les abus.

La vague observée par Microsoft montre que cette technique ne se limite plus à la sécurité des LLM. Elle est devenue un outil opérationnel dans les campagnes d’e-mails, en exploitant le même point faible : une machine peut lire un texte différent de celui qui est affiché à une personne.