ASCII smuggling: los caracteres Unicode invisibles también engañan ahora a los filtros antispam

De la prompt injection a las campañas de correo electrónico

El ASCII smuggling, ya asociado a los ataques de prompt injection contra sistemas de inteligencia artificial, se utiliza ahora para reducir la eficacia de los filtros antispam y antiphishing.

La técnica inserta caracteres Unicode normalmente invisibles dentro de palabras que siguen siendo legibles para el destinatario. Sin embargo, el software de seguridad puede procesar una secuencia distinta de la que se percibe en pantalla. Una palabra sospechosa parece intacta para una persona, pero puede fragmentarse o alterarse durante el análisis automatizado.

Microsoft observó esta modalidad de evasión en Microsoft Defender for Office. Las detecciones asociadas al ASCII smuggling aumentaron rápidamente: en un día de principios de febrero pasaron de unas 21.000 a más de 1,3 millones. Cuatro días después habían alcanzado los 2,5 millones.

La actividad continuó durante meses y después disminuyó bruscamente a mediados de mayo. Los datos también incluyen detecciones diarias de firmas Unicode vinculadas a dominios de remitentes relacionados con las finanzas, monitorizadas entre el 9 de febrero y el 18 de junio de 2026.

La campaña no se ha atribuido a un grupo específico. Sus responsables se describen genéricamente como spammers, sin indicaciones sobre su procedencia ni sobre las infraestructuras utilizadas.

Cómo funcionan las etiquetas Unicode invisibles

El método aprovecha un bloque compuesto por 128 caracteres Unicode de tipo tag, capaz de reproducir casi por completo una porción de ASCII, el American Standard Code for Information Interchange.

Estos caracteres pueden ser interpretados por los sistemas informáticos, pero fueron diseñados para no ser normalmente visibles para los seres humanos. Por ejemplo, el código U+E0041 representa la letra mayúscula «A», mientras que U+E0061 corresponde a la «a» minúscula.

En los ataques contra aplicaciones basadas en modelos lingüísticos, las etiquetas pueden ocultar instrucciones insertadas en correos electrónicos, documentos u otros contenidos no fiables. El usuario no ve el comando, pero un agente de IA podría procesarlo y actuar en consecuencia.

En el spam, el principio se invierte. El objetivo no es ocultar una instrucción a una persona, sino impedir que el filtro reconozca correctamente una palabra que el usuario sigue viendo.

Entre los términos manipulados figuran importes en dólares y palabras inglesas habituales en las ofertas financieras, como «credit», «term» y «funding». Son expresiones que pueden contribuir a la puntuación de riesgo asignada a un mensaje.

Al insertar una etiqueta invisible en el centro de «funding», la palabra puede parecer normal en pantalla. El filtro, en cambio, podría tratarla como dos segmentos separados: «fun» y «ding».

Un carácter citado en este contexto es U+E0020. Cuando se coloca dentro de una cadena, su efecto depende de cómo el sistema lleva a cabo el parsing, la normalización y la tokenización.

Por qué también pueden equivocarse los clasificadores de IA

El ASCII smuggling no solo dificulta el trabajo de las expresiones regulares o de los controles basados en la coincidencia exacta de una cadena. También puede interferir con clasificadores que utilizan machine learning, procesamiento del lenguaje natural y modelos lingüísticos.

Estos sistemas no analizan necesariamente una frase tal como la ve una persona. El texto suele dividirse en tokens o sub-tokens, es decir, unidades numéricas que el modelo utiliza para clasificar el contenido.

Un carácter invisible insertado en mitad de una palabra puede producir varios resultados. El tokenizer podría separar «funding» en «fun», la etiqueta Unicode inesperada y «ding». También podría generar tokens poco frecuentes o desconocidos con los que el modelo se haya encontrado pocas veces durante el entrenamiento.

En ambos casos se pierde una característica útil para la clasificación. El modelo ya no recibe el término esperado, sino una representación anómala que podría tener menos peso en la evaluación del riesgo.

El resultado cambia si el sistema normaliza el texto antes de la tokenización. Al eliminar el carácter invisible, el filtro podría reconstruir correctamente «funding». Sin embargo, una normalización incompleta o aplicada en el punto equivocado de la pipeline deja intacta la evasión.

Aquí está el problema central: el contenido visual y el subyacente no coinciden.

Una defensa basada exclusivamente en la cadena Unicode analiza lo que está codificado en el mensaje. Un destinatario, en cambio, reacciona a lo que muestra el cliente de correo. Para comparar ambos niveles puede ser necesario renderizar el contenido y someterlo a reconocimiento óptico de caracteres, en lugar de confiar únicamente en el texto extraído.

Una evolución de técnicas utilizadas desde hace décadas

Ocultar palabras en los mensajes no deseados no es ninguna novedad. Desde hace décadas, los spammers insertan espacios de ancho cero, espacios de no separación y otros caracteres especiales para alterar las secuencias que examinan las expresiones regulares.

Sin embargo, las etiquetas Unicode añaden una variante menos familiar para algunos sistemas de defensa. Los filtros diseñados para detectar las manipulaciones más habituales podrían no tratar estos códigos como elementos sospechosos o que deban ignorarse.

La ventaja no se limita a las antiguas reglas textuales. La inserción de etiquetas puede alterar directamente la representación que reciben los modelos ML y NLP, desplazando el problema de la búsqueda de palabras a la robustez de toda la pipeline lingüística.

Esta misma propiedad ya había hecho útil el ASCII smuggling en la prompt injection indirecta. Una aplicación de IA puede adquirir contenidos de correos electrónicos, sitios web o documentos e interpretar instrucciones que el usuario no ve. En la evasión antispam, en cambio, el texto está destinado a ser visto, pero no reconocido correctamente por la máquina.

Son dos usos diferentes de la misma discrepancia.

Impacto y productos afectados

Microsoft Defender for Office es el producto en el que Microsoft detectó el fuerte aumento de las firmas. Sin embargo, el problema puede afectar, de forma más general, a plataformas de correo electrónico, gateways antiphishing, tokenizers, analizadores de texto y clasificadores basados en ML o NLP.

No se han indicado otros productos o fabricantes concretos. Tampoco se han hecho públicas versiones afectadas, builds vulnerables ni configuraciones específicas expuestas.

Además, no se trata de una vulnerabilidad formalizada. No constan un identificador CVE, una puntuación CVSS ni una clasificación de gravedad; por tanto, no existe una entrada en el catálogo Known Exploited Vulnerabilities de la CISA ni un plazo federal de actualización.

El impacto depende del papel que desempeñen los términos ofuscados en la clasificación general. El ASCII smuggling no garantiza por sí solo que un correo electrónico supere todos los controles, pero puede eliminar señales lingüísticas utilizadas para identificar spam, estafas financieras y phishing.

Para los destinatarios, el riesgo es real: los mensajes fraudulentos podrían llegar a la bandeja de entrada aunque contengan expresiones que, sin ofuscación, habrían contribuido a su bloqueo.

Cómo hacer que los filtros sean más resistentes

Microsoft ha proporcionado indicaciones de diseño a los desarrolladores, pero no se conoce ninguna actualización de software específica ni ningún workaround para Microsoft Defender for Office.

En primer lugar, los filtros deberían identificar las etiquetas Unicode y otros elementos invisibles, y registrar su presencia como posible señal de ofuscación. No basta con basarse en una lista de palabras sospechosas.

La normalización debe ser controlada y coherente. Es útil comparar el texto original con el obtenido después de eliminar o transformar los caracteres invisibles, evitando al mismo tiempo que el proceso introduzca nuevas ambigüedades.

También debe comprobarse el comportamiento del tokenizer. Un aumento de tokens desconocidos, poco frecuentes o inesperados dentro de palabras habituales puede ser un indicador útil, sobre todo en los mensajes relacionados con las finanzas.

En los sistemas de mayor riesgo, la comparación entre el texto subyacente y el contenido que se muestra realmente puede incluir renderizado y OCR. Esta solución requiere más recursos, pero reduce la distancia entre lo que analiza el filtro y lo que ve el destinatario.

Por último, las reglas no deberían centrarse únicamente en palabras aisladas. La presencia repetida de etiquetas Unicode, combinada con dominios financieros, solicitudes de pago, enlaces u otras señales sospechosas, ofrece una base más sólida para detectar el abuso.

La oleada observada por Microsoft demuestra que la técnica ya no se limita a la seguridad de los LLM. Se ha convertido en una herramienta operativa en las campañas de correo electrónico, aprovechando el mismo punto débil: una máquina puede leer un texto distinto del que se muestra a una persona.