Phishing con Unicode invisible: qué ocurrió realmente

Esto es lo que Microsoft encontró realmente y lo que los titulares simplificaron demasiado.

Qué confirmó Microsoft

El 3 de septiembre de 2026, Microsoft Security Research publicó el análisis de una campaña de phishing financiero que introducía caracteres Unicode no visibles dentro de palabras como funding, capital, loan, advance y credit. El propósito era modificar la representación interna del texto sin cambiar lo que veía la persona que recibía el correo.

La actividad detectada aumentó con fuerza el 9 de febrero de 2026. Un día antes, la firma de búsqueda utilizada por Microsoft había encontrado alrededor de 21,000 mensajes; el 9 de febrero registró más de 1.3 millones. Durante la fase más intensa, el volumen se mantuvo entre uno y 2.37 millones de mensajes por día laborable, con el máximo el 26 de febrero, según la telemetría descrita por Microsoft Security Research.

Ese detalle importa: 2.37 millones no fue una cantidad constante todos los días, sino el pico registrado. La campaña además seguía un patrón semanal muy marcado: operaba intensamente de lunes a viernes y prácticamente se detenía durante los fines de semana.

La fase de gran volumen continuó durante aproximadamente tres meses y cayó de manera pronunciada después del 15 de mayo. Microsoft mantuvo el seguimiento hasta mediados de junio, cuando todavía existía actividad residual. Esas fechas describen únicamente el periodo en el que se utilizaron estos caracteres invisibles; la operación de phishing general había comenzado antes y continuó después con otras técnicas.

Cómo funcionaba el carácter invisible

La campaña utilizó caracteres del bloque Unicode Tags, comprendido entre U+E0000 y U+E007F. En las muestras examinadas, el carácter más relevante fue U+E0020, denominado TAG SPACE.

Un término podía almacenarse así:

funding → fun[U+E0020]ding

La interfaz del correo normalmente no representa ese código, por lo que el destinatario sigue leyendo funding. Para un sistema que busca literalmente esa secuencia, sin embargo, fun[U+E0020]ding ya no es la misma cadena.

El cambio también puede afectar a un tokenizador. En lugar de identificar una palabra conocida, podría dividir el contenido en fun, un token extraño y ding. El resultado concreto depende de si el sistema elimina o normaliza los caracteres invisibles antes de aplicar reglas, expresiones regulares o modelos de clasificación.

Microsoft puntualiza que las muestras no contenían un mensaje completo codificado de forma invisible. Técnicamente, los atacantes insertaron un carácter procedente del bloque asociado con ASCII smuggling para separar palabras. Por eso, en este caso es más preciso hablar de inserción de Unicode invisible para evadir filtros que de contrabando de instrucciones completas.

Lo viral frente a lo comprobado

La distinción más importante está en la cuarta afirmación. De acuerdo con el análisis original de Microsoft Security Research, más del 99 % de los mensajes fue marcado por otras capas de Defender for Office 365: reputación de remitentes, IP, URLs y dominios, comprobaciones de autenticación, detección de suplantación y modelos de spam o phishing.

La cobertura de BleepingComputer también recoge esa tasa y explica que Microsoft agrupó aproximadamente 150 dominios de apariencia financiera. Por tanto, la campaña no demostró que un carácter invisible vuelva inútil toda la seguridad del correo. Demostró que una defensa dependiente de una sola representación textual puede tener un punto ciego.

No era simplemente una lista negra de palabras

La explicación viral suele presentar el filtro como una lista que bloquea palabras como “banco” o “transferencia”. Es una buena simplificación para ilustrar una coincidencia literal, pero no describe por completo un sistema moderno de protección de correo.

Además del contenido visible, una plataforma puede evaluar:

• La reputación y antigüedad del dominio remitente.
• La dirección IP y la infraestructura desde la que se envía el mensaje.
• La autenticación del correo mediante SPF, DKIM y DMARC.
• La reputación y el destino efectivo de los enlaces.
• Patrones de envío masivo y rotación de dominios.
• Similitudes con marcas conocidas y campañas anteriores.
• El contenido visual obtenido mediante renderizado y OCR.

Microsoft señala que Defender puede renderizar el contenido, extraer por OCR el texto que vería una persona y analizar esa versión. Si el código fuente contiene fun[U+E0020]ding pero la imagen renderizada muestra funding, el análisis visual ofrece una señal adicional que no depende de la cadena original.

Aquí también apareció una segunda ventaja para los defensores: los caracteres del bloque Tags son poco frecuentes en correos ordinarios. Una manipulación diseñada para ocultar una palabra puede convertirse en una anomalía de alta confianza. Existen usos legítimos —por ejemplo, algunos componentes de las banderas de Inglaterra, Escocia y Gales—, por lo que una regla seria necesita excepciones y contexto.

La infraestructura detrás de la campaña

Microsoft vinculó los mensajes con cientos de dominios desechables formados mediante combinaciones de términos financieros. En una muestra del 9 de febrero identificó 148 dominios relacionados; ese grupo concentraba aproximadamente el 96 % del volumen detectado por la firma de Unicode invisible.

Los correos fueron transmitidos mediante infraestructura asociada con ActiveCampaign, una plataforma legítima de automatización y marketing por correo. Esto no convierte toda la infraestructura de la empresa en maliciosa. El informe describe el abuso de cuentas o flujos de un servicio con reputación estable, una condición que puede hacer que el tráfico se parezca inicialmente a campañas comerciales legítimas.

ActiveCampaign declaró a Microsoft que sus sistemas asignaban a los mensajes ofuscados el mismo resultado de moderación que a sus equivalentes normales y que el uso intensivo de caracteres invisibles se consideraba una señal sospechosa. BleepingComputer documentó también la respuesta de la plataforma y la recomendación de normalizar el texto antes de analizarlo.

Qué relación tiene con prompt injection

ASCII smuggling se hizo conocido en investigaciones de seguridad de inteligencia artificial antes de aparecer en esta campaña de phishing. El uso contra asistentes funciona de manera diferente:

1. El atacante codifica una instrucción con caracteres Unicode que la interfaz no representa.
2. Una persona abre, copia, resume o autoriza el procesamiento de un correo, documento o página aparentemente normal.
3. El asistente recibe el texto original, incluidos los códigos invisibles.
4. Si el modelo o la aplicación interpreta la instrucción y carece de controles suficientes, puede alterar su respuesta o intentar ejecutar una acción no autorizada.

Esto se conoce como prompt injection indirecta cuando la instrucción procede de contenido externo en lugar de ser escrita directamente por el usuario. Su impacto depende del modelo, de la forma en que la aplicación procesa Unicode, de las herramientas conectadas y de los permisos concedidos al asistente.

La relación con la campaña debe expresarse en el orden correcto: una técnica difundida en investigaciones sobre ataques a sistemas de IA fue reutilizada para la evasión tradicional de correo. No hay evidencia en el informe de que los millones de mensajes analizados incluyeran instrucciones ocultas dirigidas a asistentes.

La guía de prevención de prompt injection de OWASP incluye el contenido invisible, la ofuscación y las variaciones tipográficas entre los patrones que una aplicación debe considerar. También recomienda combinar validación de entradas, separación clara entre instrucciones y datos externos, control de privilegios y confirmación humana para operaciones sensibles.

Qué deberían revisar los desarrolladores

Normalizar antes de comparar

Las reglas basadas en palabras, firmas o expresiones regulares deberían recibir una representación canónica del texto. Microsoft recomienda eliminar o normalizar el bloque U+E0000–U+E007F y otros caracteres no renderizados antes de buscar coincidencias.

Normalizar no significa borrar indiscriminadamente cualquier Unicode. Un sistema debe conservar los idiomas y símbolos que admite, documentar sus transformaciones y separar los caracteres legítimos de los controles invisibles que resulten anómalos en su contexto.

Analizar la versión original y la normalizada

Conservar ambas representaciones permite detectar dos señales:

• El texto normalizado revela la palabra o instrucción que intentaba ocultarse.
• La diferencia con el contenido original revela que hubo una manipulación deliberada o, al menos, inusual.

Si el sistema reemplaza primero los caracteres y descarta el original, pierde información útil para auditoría, investigación y creación de reglas.

No confiar en una sola señal

Una regla que busque funding literalmente puede fallar. Una regla que bloquee cualquier carácter del bloque Tags puede generar falsos positivos. Una defensa sólida combina contenido, comportamiento, identidad del remitente, reputación de infraestructura, URLs y contexto visual.

Ese enfoque por capas explica por qué el intento de evasión no se tradujo en una omisión generalizada para Defender, aunque sí reveló una clase de entrada que otros productos y pipelines deberían probar.

Sanitizar antes de enviar contenido a una IA

Los correos, archivos y páginas recuperadas deben tratarse como datos no confiables antes de entrar en el contexto de un modelo. La normalización de caracteres invisibles reduce esta variante concreta, pero no elimina por sí sola el prompt injection: una instrucción maliciosa también puede estar escrita con texto visible.

Para agentes con herramientas, la aplicación debería limitar permisos, validar argumentos, exigir confirmación en acciones de alto impacto y evitar que el contenido recuperado adquiera la misma autoridad que las instrucciones del sistema.

Veredicto

La base de la noticia es verdadera: Microsoft observó una campaña financiera que llegó a un máximo de 2.37 millones de mensajes en un día y utilizó Unicode invisible para dificultar el análisis automatizado. Lo engañoso es convertir ese máximo en una cifra diaria permanente, describir el objetivo como “burlar antivirus” y afirmar que toda la protección fue superada.

Tampoco debe confundirse el origen de la técnica con el contenido de esta campaña. ASCII smuggling puede ocultar instrucciones destinadas a una IA, pero en los mensajes examinados por Microsoft los caracteres actuaban como separadores dentro de palabras financieras.

Una versión precisa del titular sería:

Microsoft detecta una campaña de phishing que usó Unicode invisible para intentar evadir filtros de correo y alcanzó un pico de 2.37 millones de mensajes en un día.

El hallazgo no demuestra que los filtros modernos sean inútiles. Demuestra algo más útil para desarrolladores: cualquier sistema que compare, clasifique o entregue texto a una IA debe definir cómo normaliza Unicode y comprobar que la representación procesada coincide con la que ve el usuario.