Microsoft advierte campaña de phishing que usa Unicode Tags para evadir filtros

Microsoft ha advertido sobre una campaña masiva de phishing que aprovecha caracteres Unicode invisibles —concretamente del bloque conocido como Unicode Tags (U+E0000–U+E007F)— para fragmentar palabras clave financieras y así eludir filtros de correo. Según la descripción técnica difundida por el equipo de investigación de seguridad de Microsoft, el método consiste en intercalar puntos de código no visibles dentro de palabras como "funding" para que sigan viéndose normales al usuario, pero dejen de coincidir con cadenas literales o expresiones regulares empleadas por detectores y filtros automáticos.

Hechos confirmados: Microsoft identificó un pico de actividad que comenzó a principios de febrero de 2026, entró en una fase de alto volumen durante aproximadamente tres meses y descendió notablemente tras el 15 de mayo de 2026. Los investigadores estiman volúmenes de envío en días laborables entre 1 y 2,37 millones de correos, con una cadencia semanal marcada (prácticamente inactivos los fines de semana y activos de lunes a viernes). La campaña reutilizó la plataforma de automatización de ActiveCampaign para distribuir miles de correos, y ha sido vinculada —según análisis anteriores del equipo FIRE de Fortra— a intentos de capturar datos de solicitantes de préstamos (SBA) y producir sitios falsos de apariencia convincente. Microsoft y terceros han detectado cientos de dominios emisores descartables con temas financieros y redirecciones de clics a través de dominios de tracking propios de la plataforma (por ejemplo, los dominios de seguimiento de ActiveCampaign).

Cómo funciona técnicamente: el bloque Unicode Tags contiene "copias" de caracteres ASCII que no se renderizan visiblemente en muchas interfaces; originalmente se ideó para etiquetado lingüístico y está mayormente en desuso. Al intercalar estos puntos de código entre letras, la secuencia de bytes ya no contiene la subcadena literal buscada por un filtro (por ejemplo, "funding"), pero al mostrarse al usuario o al normalizarse por algunas tuberías de parseo el resultado vuelve a leerse como la palabra original. Los detectores que basan su lógica en coincidencias exactas o en regex que no contemplan caracteres intercalados fallan en identificar la palabra clave. Adicionalmente, este patrón —a veces denominado "ASCII smuggling"— alimenta un riesgo agregado en contextos donde modelos de lenguaje (LLMs) o sistemas automatizados ingieren el texto sin una limpieza previa: si el contenido malicioso permanece incrustado, puede servir como vector para inyecciones de instrucciones o para que un LLM acepte y ejecute indirectamente comandos encubiertos.

Qué está confirmado y qué permanece incierto: está confirmado que la técnica se usó a escala y que la infraestructura de envío incluyó ActiveCampaign como canal de distribución; también está documentada la reutilización de dominios financiarizados descartables. Es una estimación, basada en telemetría y en los informes de Microsoft, que la campaña alcanzó millones de mensajes diarios y siguió el patrón semanal descrito. Lo que no está públicamente confirmado en los informes disponibles es la identidad del actor o actores detrás de la operación y hasta qué punto la red de dominios está centralizada o fragmentada entre varios grupos. Asimismo, la relación exacta entre las oleadas detectadas en febrero-mayo de 2026 y las campañas anteriores reportadas en 2025 por Fortra se describe como ligada o coherente, pero no necesariamente con atribución probatoria completa.

Impacto real y riesgos: la técnica reduce la eficacia de firmas y reglas estáticas, por lo que permite que tráfico malicioso alcance bandejas de entrada o que mensajes de spear‑phishing altamente personalizados escapen de controles. Para empresas pequeñas y medianas (el blanco declarado según Fortra), esto supone riesgo de pérdidas financieras directas (fraude, adelantos falsos), robo de credenciales y preparación de ataques más dirigidos (ingeniería social posterior). Al apoyarse en una plataforma de marketing con reputación y con IPs autenticadas, además, el envío puede sortear filtros basados en reputación, complicando la detección basada únicamente en origen o en historiales de envío.

Medidas concretas que deberían tomar los lectores y administradores: en primer lugar, para usuarios finales, la protección básica sigue siendo válida y prioritaria: no clicar enlaces en correos sospechosos, verificar remitentes por canales oficiales, y usar MFA en todas las cuentas que manejan dinero o información sensible. Antes de introducir credenciales o datos financieros, confirmar por teléfono o por el portal oficial de la entidad.

Para equipos de seguridad de correo y administradores TI hay acciones técnicas específicas y aplicables de inmediato: normalizar antes de analizar —es decir, eliminar o mapear puntos de código invisibles del bloque Tags— y aplicar esa versión canónica al motor de detección; esto evita la dependencia de patrones literales vulnerables. Como segunda línea, implementar reglas de detección que busquen caracteres no imprimibles intercalados dentro de palabras clave sensibles o patrones de conducta (en lugar de solo coincidencias contiguas). Si su solución de correo permite inspección profunda, añadir una regla para bloquear o marcar mensajes que utilicen masivamente caracteres de la categoría "Tags" o cualquier otro rango de control/invisibles. Paralelamente, monitorizar envíos que utilicen proveedores de marketing legítimos y mantener comunicación con dichos proveedores para detectar abuso de cuentas y flujos automatizados. No sustituya estas defensas por la sola confianza en reputación: configurar DMARC, DKIM y SPF ayuda, pero no evita que campañas aprovechen cuentas de plataformas autorizadas.

Para quienes operan o despliegan modelos de lenguaje, la recomendación práctica es análoga: preprocesar y sanear cualquier texto de entrada para eliminar caracteres de etiquetado invisibles antes de alimentar un LLM, y fijar límites y reglas explícitas que distingan entre instrucciones de usuario y contenido de terceros incorporado. La tokenización y la normalización de Unicode deben emplearse como parte de la canalización de seguridad para minimizar vectores de prompt injection.

Responsabilidad de los proveedores: plataformas de email marketing y automatización deben reforzar detección de abuso en cuentas, supervisar picos de actividad, y evitar que los flujos de tracking legitimen envíos claramente maliciosos. Microsoft y ActiveCampaign ya han mencionado en sus comunicados que los proveedores detectan algunos de estos patrones y tratan la presencia masiva de caracteres invisibles como señal de sospecha; aun así, los equipos de seguridad deben exigir a los proveedores transparencia y mecanismos de bloqueo más automáticos para campañas que violen políticas.

Para profundizar en la naturaleza técnica de los caracteres Unicode y los riesgos asociados, puede consultarse la documentación de Unicode en https://unicode.org/, y los análisis y guías de seguridad y publicaciones de proveedores en https://www.microsoft.com/security/blog/. Estas lecturas ayudan a entender por qué una simple secuencia de bytes puede cambiar radicalmente la eficacia de una regla de detección y por qué la higiene de entrada (normalizar y limpiar) es ahora una defensa crítica.

En resumen: la campaña evidencia que técnicas diseñadas para engañar sistemas automatizados se han adaptado y escalan con infraestructuras legítimas, y que las defensas deben evolucionar desde reglas textuales estáticas a canalizaciones que saneen y normalicen el texto antes del análisis. Para usuarios y organizaciones, la combinación de higiene digital (MFA, verificación de remitentes), saneamiento previo y coordinación con proveedores constituye la respuesta práctica más efectiva frente a esta clase de evasión.