Principe du smuggling ASCII

Le smuggling ASCII repose sur un jeu de 128 caractères Unicode situés dans la plage U+E0040–U+E00BF. Chaque balise représente un octet du jeu de caractères ASCII classique : par exemple 

U+E0041
est interprété comme la lettre A, tandis que 
U+E0061
correspond à a. Ces balises sont invisibles à l’œil humain parce qu’elles n’ont aucune forme graphique, mais les moteurs de traitement de texte et les modèles de langage les lisent comme des caractères valides. Initialement, la technique a servi à dissimuler des instructions malveillantes dans des prompts d’injection ciblant les grands modèles de langage (LLM), rendant la chaîne d’injection indétectable pour les humains tout en restant exploitable par le modèle.

Le mécanisme exploite la différence entre le niveau de rendu (humain) et le niveau de traitement (logiciel). Les filtres anti‑spam traditionnels analysent le texte affiché, tandis que les LLM tokenisent chaque point de code, y compris les balises invisibles. Ainsi, un texte contenant U+E0041U+E0042U+E0043 sera perçu par le modèle comme « ABC », alors que l’utilisateur ne voit aucun caractère.

Adoption par les spammeurs et données de détection

Microsoft Defender for Office a observé une hausse brutale du nombre de signatures de smuggling ASCII dès le début février 2026. Les détections quotidiennes sont passées d’environ 21 000 à plus de 1,3 million en une journée, puis ont atteint 2,5 million en quatre jours. Cette vague a duré plusieurs mois avant de chuter de façon aiguë à la mi‑mai. Les chiffres confirment que les spammeurs ont inversé l’intention du procédé : au lieu de masquer des instructions pour un LLM, ils masquent des mots‑clés (ex. « unsubscribe », « click ») afin d’échapper aux filtres de détection basés sur des listes noires.

Le changement de cible implique une adaptation du pipeline de filtrage. Les signatures utilisées par Microsoft reposent sur la reconnaissance exacte des séquences de balises Unicode. Cette approche est efficace tant que les spammeurs n’introduisent pas de variations (par ex. insertion de caractères de remplissage ou de combinaisons de balises non standard). La persistance du phénomène pendant plusieurs mois indique que les contre‑mesures automatisées n’ont pas été déployées rapidement ou que les spammeurs ont continuellement rafraîchi leurs listes de balises.

Analyse technique des limites de détection

Le principal défi réside dans la capacité des filtres à analyser le texte à la fois au niveau de rendu et au niveau de code point. Les moteurs de détection qui ne normalisent pas les caractères Unicode avant l’analyse laissent passer les balises invisibles. Une normalisation stricte (NFKC/NFKD) transformerait les balises en leurs équivalents ASCII, mais cela risque de corrompre les contenus légitimes qui utilisent réellement ces points de code pour d’autres usages (ex. langues rares). De plus, la mise en œuvre de la normalisation augmente la charge de traitement, ce qui peut ralentir le filtrage en temps réel.

Une autre contrainte est la taille du jeu de balises : 128 caractères couvrent l’ensemble du tableau ASCII, ce qui permet de reconstituer n’importe quel texte. Pour contrer cela, les filtres pourraient recourir à l’analyse de la densité de points de code non imprimables dans un message. Un taux anormalement élevé (par ex. plus de 5 % de caractères invisibles) serait un indicateur de smuggling. Cependant, les spammeurs peuvent diluer les balises avec du texte visible, réduisant ainsi la détection basée sur la densité. En l’absence de signatures précises, la lutte contre le smuggling ASCII repose sur une combinaison de normalisation, d’analyse statistique et de mise à jour continue des signatures.