Una campaña de phishing de dos meses de duración camufló código JavaScript malicioso como archivos adjuntos inofensivos de mensajes de voz, etiquetando erróneamente los archivos como «texto sin formato» para eludir los escáneres de archivos adjuntos. INKY detectó y señaló los 26 589 mensajes.

Entre el 1 de junio y el 4 de agosto de 2026, INKY rastreó y detectó una campaña de phishing prolongada que utilizaba un señuelo aparentemente sencillo —una notificación de mensaje de voz no escuchado— para distribuir código malicioso oculto en un archivo de imagen. La campaña afectó a 5.527 organizaciones y generó 26.589 correos electrónicos detectados.

Todos los correos electrónicos fueron interceptados y marcados como peligrosos. El arma elegida por los atacantes fue un formato de archivo que la mayoría de la gente, y muchos filtros de correo electrónico, consideran inofensivo: la imagen SVG.

En este blog se explica qué son los archivos SVG, por qué los atacantes los han adoptado como mecanismo de distribución de malware en 2026 y cómo funcionaba exactamente esta campaña. También analizamos el código JavaScript ofuscado oculto en el archivo adjunto, el truco que utilizaron los atacantes para camuflar el archivo como texto sin formato y cómo INKY lo detectó en todas las organizaciones afectadas.

¿Qué es un archivo SVG y por qué les encanta a los atacantes?

SVG (Scalable Vector Graphics) es un formato de imagen, pero, a diferencia del JPEG o el PNG, no está compuesto por píxeles. Un archivo SVG es un archivo de texto escrito en XML que describe formas, líneas y texto de forma matemática, por lo que la imagen puede ampliarse o reducirse a cualquier tamaño sin perder calidad. Los logotipos, iconos y gráficos que aparecen en la web suelen estar en formato SVG.

Pero hay una diferencia fundamental entre un SVG y una imagen normal: un SVG puede contener código. La especificación SVG permite incrustar scripts, incluido JavaScript, directamente en el archivo, de modo que los gráficos puedan ser interactivos. Cuando se abre un SVG en un navegador web, ese JavaScript incrustado se ejecuta. Un PNG nunca puede hacer esto. Un SVG sí puede.

Esa única característica es la que aprovechan los atacantes. Para una persona, y para muchas herramientas de seguridad, un archivo SVG parece una imagen. Para un navegador, puede ser un medio para distribuir un programa. Esta discrepancia entre cómo se percibe el archivo y lo que realmente puede hacer constituye la base de la técnica conocida como «contrabando de SVG».

Por qué los archivos SVG logran burlar las defensas Las puertas de enlace de seguridad del correo electrónico llevan años aprendiendo a bloquear tipos de archivos adjuntos peligrosos, como archivos ejecutables, scripts, documentos con macros activadas y archivos comprimidos. Históricamente, los archivos SVG se consideraban imágenes inofensivas y se permitía su paso. Los atacantes se dieron cuenta de ello. Al envolver su código JavaScript en una envoltura SVG, introducen código activo dentro de un tipo de archivo que muchos filtros nunca se configuraron para examinar.

Una amenaza cada vez mayor para 2026

Los ataques basados en SVG no son nada nuevo. Los investigadores llevan documentando archivos adjuntos SVG maliciosos desde aproximadamente 2017, pero su uso se disparó en 2026. Hubo dos cambios: la magnitud de las campañas y el grado de sofisticación del cifrado.

• Un aumento de cincuenta veces. Según el Informe sobre tendencias de phishing de 2026 de Hoxhunt, los archivos adjuntos SVG maliciosos se multiplicaron por cincuenta en 2025 con respecto a 2024, y ahora ocupan el tercer puesto entre los tipos de archivos adjuntos maliciosos más comunes en el correo electrónico, solo por detrás de los PDF y los HTML.
• Campañas individuales a gran escala. En una campaña de febrero de 2026 analizada por Microsoft, se enviaron aproximadamente 1,2 millones de mensajes de phishing basados en SVG a más de 53 000 organizaciones de 23 países. El SANS Internet Storm Center documentó cómo esta misma técnica inundaba los buzones de correo en junio de 2026.
• Cargas útiles sin contenido. Al analizar muestras recientes, los investigadores encontraron archivos SVG que no contenían ningún tipo de contenido gráfico. El archivo existe únicamente para transmitir código JavaScript ofuscado al navegador de la víctima, al tiempo que el servidor de correo electrónico lo clasifica como una imagen.
• Señuelos en forma de mensajes de voz. Varios proveedores, entre ellos Sublime Security y ReversingLabs, han documentado archivos adjuntos SVG camuflados como notificaciones de mensajes de voz o de llamadas perdidas, que es precisamente el señuelo utilizado en la campaña que aquí se describe.

La campaña INKY sigue este patrón al pie de la letra y añade una capa adicional de evasión al etiquetar erróneamente el tipo de archivo SVG como «texto sin formato».

Resumen de la campaña

Todos los mensajes de esta campaña seguían la misma plantilla: un correo electrónico interno falsificado que fingía ser una notificación de mensaje de voz y que incluía uno o varios archivos adjuntos SVG que, en realidad, eran código JavaScript ofuscado. Las estadísticas que se muestran a continuación proceden directamente de la telemetría de INKY durante el periodo analizado.

Métrico	Valor
Total de correos electrónicos detectados	26,589
Organizaciones afectadas	5,527
Se ha observado el periodo de campaña	1 de junio – 4 de agosto de 2026 (en curso)
Resolución de amenazas	100 % detectado
Tema «Lure»	Notificación de mensajes de voz o llamadas perdidas
Carga útil	Archivo adjunto SVG que contiene código JavaScript ofuscado
Señales de evasión	Archivo adjunto SVG declarado como «text/plain»
Principales señales de detección	Contenido de phishing (100 %), remitente interno falsificado (95 %)
Personalización	El 99,5 % de los asuntos incluían el nombre de correo electrónico del propio destinatario.

Tabla 1: Resumen de la campaña según los datos de telemetría de PhishFence de INKY , del 1 de junio al 4 de agosto de 2026.

Figura 1: Volumen diario de correos electrónicos detectados a lo largo de la campaña. La actividad se desarrolló por oleadas, alcanzando su punto álgido el 3 de junio (2.432 correos electrónicos en 1.149 organizaciones) y registrando un marcado repunte a finales de julio. Se observan descensos durante los fines de semana, cuando la campaña se interrumpía.

Una pulverización general, no un ataque selectivo

La distribución de los correos electrónicos entre las organizaciones pone de manifiesto que se trata de una campaña amplia y oportunista, más que de una operación de precisión. De las 5.527 organizaciones analizadas, la mediana recibió solo dos correos electrónicos, y el 32 % recibió únicamente uno. Las diez organizaciones más afectadas representan, en conjunto, apenas el 6 % del volumen total. No se observa una concentración en un pequeño conjunto de objetivos de alto valor, lo cual es el sello distintivo de una campaña de difusión masiva diseñada para la recopilación generalizada de credenciales, en lugar de un ataque de spear-phishing personalizado.

Figura 2: Distribución de los correos electrónicos por organización. La inmensa mayoría de las organizaciones recibió solo unos pocos mensajes, con un grupo muy reducido de organizaciones que se vieron más afectadas, lo que confirma que se trató de un envío masivo y no de un envío dirigido.

Adaptado a la semana laboral

El ritmo de envío de la campaña refuerza la imagen de una operación diseñada para parecer verosímil. El volumen se concentró de lunes a jueves y alcanzó su punto álgido el miércoles, sin que se enviara prácticamente nada durante los fines de semana. Esto concuerda con una estrategia de captación diseñada para que los mensajes lleguen mientras los destinatarios están trabajando activamente y la notificación de una llamada perdida resulte algo habitual.

Figura 3: Volumen de la campaña por día de la semana. Los envíos se concentran de lunes a jueves y prácticamente cesan durante el fin de semana.

Personalizado a partir de la propia dirección del destinatario

En el 99,5 % de los mensajes, el nombre que aparecía en el asunto era una copia exacta de la cadena que precedía al símbolo @ en la propia dirección de correo electrónico del destinatario. Un destinatario con la dirección jsmith@… vería un asunto que decía «mCaller dejó Jsmith, vista previa de 34 s…». Los atacantes no necesitaron una lista de contactos robada. Generaron la personalización para cada destinatario de forma automática a partir de la propia dirección. El indicio de que se trata de un mensaje generado por una máquina, y no por un humano, es que los buzones basados en roles se dirigían por sus nombres literales (por ejemplo, «mCaller dejó Cuentas por pagar»), algo que ninguna persona real escribiría jamás.

Análisis de un correo electrónico de phishing

El correo electrónico en sí es deliberadamente escueto. Se presenta como una notificación automática de un mensaje de voz con muy poco texto en el cuerpo del mensaje, un asunto que hace referencia a una llamada perdida y uno o varios archivos adjuntos diseñados para que parezcan el archivo del mensaje de voz. A continuación se muestra un ejemplo censurado de la campaña.

Figura 4: Ejemplo de un correo electrónico de la campaña en el que se han ocultado algunos datos. El mensaje simula ser una notificación interna de un mensaje de voz e incluye dos archivos adjuntos cuyos nombres están diseñados para parecerse al del archivo del mensaje de voz. Fíjate en la extensión .svg…​.txt. Se han ocultado los datos identificativos del destinatario y del remitente.

Dos niveles de engaño

Antes incluso de que se ejecute una sola línea de código, el mensaje ya recurre a dos formas de engaño a nivel de la envoltura:

• Remitente interno falsificado. El correo electrónico aparenta proceder del propio dominio del destinatario, pero procede de una fuente externa y el remitente nunca fue autenticado por el servidor de correo de la organización. Está diseñado para parecer una notificación interna del sistema.
• El archivo adjunto está mal etiquetado. Aunque los archivos tienen la extensión .svg y contienen código SVG/XML, en el mensaje se declaran con un tipo de contenido «text/plain» en lugar de «image/svg+xml». Un escáner de archivos adjuntos que se basa en el tipo declarado detecta un archivo de texto inofensivo, no contenido activo.

En el archivo adjunto: Qué hace realmente el código

Al abrir el archivo adjunto en un editor de texto, en lugar de en un navegador, se comprueba que el «mensaje de voz» no es en absoluto una imagen. Se trata de un documento XML que contiene código JavaScript ofuscado. La captura de pantalla que aparece a continuación muestra el contenido sin procesar de un ejemplo.

Figura 5: El contenido sin procesar del archivo adjunto SVG. Bajo una fina capa SVG (un título y dos rectángulos) se encuentra código JavaScript ofuscado dentro de un `foreignObject` y un bloque CDATA de script. Se ha ocultado el bloque que contiene la URL de la llamada de retorno activa.

La estructura

En esencia, el archivo consta de tres partes:

• Una carcasa SVG minimalista. Un <svg> raíz con un <title> y un par de <rect> elementos. Esta es la única parte que se mostraría como una «imagen» y, en esencia, es una portada decorativa.
• Un atributo de datos oculto. El elemento raíz contiene un atributo personalizado (por ejemplo, data-strand-key-tk=”…”) que alberga un valor codificado que el script lee en tiempo de ejecución. Dividir la configuración en atributos poco evidentes mantiene los valores maliciosos fuera de la ruta de ejecución obvia.
• Dos cargas útiles de script. A <foreignObject> que contenga un HTML <script type="application/json"> bloque, y un segundo

Cómo funciona la ofuscación

El código está diseñado para burlar tanto a los analistas humanos como a los escáneres automáticos que buscan patrones maliciosos reconocibles. Se combinan varias técnicas en diferentes niveles:

• Nombres de funciones y variables sin sentido. Todos los identificadores se ocultan tras nombres sin sentido, de carácter pseudocientífico y con referencias a la biología, como intronGap91, riboUnit30, vectorArm37, codonBuf13Go o primerSet56. Estos nombres carecen de significado y solo existen para que el código resulte ilegible y para que varíen de una muestra a otra, de modo que no haya dos archivos idénticos.
• Creación de cadenas a partir de códigos de caracteres. Las cadenas sensibles nunca se escriben en texto sin formato. En su lugar, se construyen en tiempo de ejecución a partir de códigos numéricos de caracteres mediante String.fromCharCode(…). Un escáner estático que lea el archivo verá una lista de números, no las palabras que estos forman.
• Inyección de scripts en tiempo de ejecución. En lugar de llamar directamente a funciones peligrosas, el código crea un nuevo elemento de script mediante `document.createElementNS(…)`, le asigna una fuente a partir de un valor generado en tiempo de ejecución y lo añade al documento. Se trata de una forma habitual de eludir el análisis estático, ya que el destino malicioso no existe como cadena literal en el archivo.
• Ejecución diferida. La ejecución se programa mediante requestIdleCallback / setTimeout, por lo que la carga útil se activa poco después de la carga, en lugar de hacerlo inmediatamente, lo que le permite eludir las herramientas que solo detectan el momento en que se abre un archivo.

Lo que realmente hace

Una vez descifrado, el código ofuscado se vuelve claro. Las secuencias de códigos de caracteres de la muestra se traducen en cadenas cortas que el script utiliza para construir el nombre del punto final remoto con el que se conecta. Un escáner estático que lea el archivo solo ve la lista de números que aparece a continuación, nunca las palabras que forman:

String.fromCharCode(104,116,116,112,115) -> «https» String.fromCharCode(46,112,104,112) -> «.php» (los códigos numéricos forman el punto final en tiempo de ejecución)

El código lee su atributo de datos oculto, genera el nombre del punto final a partir de estos códigos y, a continuación, utiliza window.fetch(…) para conectarse a un servidor controlado por el atacante y recuperar la siguiente fase del ataque. El propio archivo SVG no contiene la página de phishing; se trata de un lanzador que obtiene su carga útil de un servidor remoto en tiempo de ejecución.

La siguiente etapa suele seguir un patrón bien documentado, según el comportamiento habitual de este tipo de campañas.

El contenido obtenido suele ser una página destinada a sustraer credenciales que se hace pasar por un servicio de inicio de sesión muy utilizado, como Microsoft 365, Google Workspace o Adobe. En muchas campañas, se transmite la propia dirección de correo electrónico de la víctima y se utiliza para rellenar automáticamente el formulario de inicio de sesión falso, lo que hace que parezca personalizado y legítimo.

Cada vez más, estas páginas no son simples clones, sino portales de tipo «adversario en el medio» (AiTM): transmiten en tiempo real lo que la víctima escribe al servicio de inicio de sesión real, capturan el token de sesión resultante y, de este modo, burlan la autenticación multifactorial. Esta técnica se ha relacionado con kits de «phishing como servicio» (phishing-as-a-service) como Tycoon2FA, Mamba2FA y Sneaky2FA. Alojar la carga útil de forma remota también permite al atacante actualizar o sustituir la página de phishing en cualquier momento sin tener que modificar nunca el archivo SVG que se envió.

La idea clave El SVG no es la carga útil. Es el **contenedor de contrabando**. Su única función es hacer pasar código JavaScript ejecutable a través de la pasarela de correo electrónico dentro de un tipo de archivo que se trata como una imagen (y que, en este caso, está erróneamente etiquetado como texto), para luego entregar ese código al navegador, que podría ejecutarlo. El archivo adjunto que parece un mensaje de voz es, en realidad, un pequeño programa cuya primera acción es «llamar a casa».

Por qué esta campaña elude las defensas convencionales

• Tipo de archivo de confianza. Los archivos SVG suelen considerarse imágenes inofensivas. Históricamente, muchas pasarelas de pago no los analizaban como contenido activo.
• Etiquetado MIME incorrecto. Declarar el archivo adjunto como «text/plain» burla a los escáneres que deciden si realizar una inspección basándose en el tipo de contenido indicado.
• No hay una firma estática. Los identificadores aleatorios, la construcción de cadenas de códigos de caracteres y la variación por muestra hacen que no haya una cadena ni un hash fijos con los que realizar la comparación a lo largo de toda la campaña. Cada archivo tiene un aspecto diferente.
• Carga útil que solo se ejecuta en tiempo de ejecución. El destino malicioso se crea y se recupera únicamente cuando el archivo se ejecuta en un navegador. No aparece como texto legible que un escáner estático pueda detectar.
• Identidad interna falsificada. El mensaje se hace pasar por una notificación interna, aprovechando la confianza que los usuarios depositan en los correos que parecen proceder de su propia organización.

Correlación con el marco MITRE ATT&CK

Las técnicas observadas en esta campaña se corresponden con las siguientes tácticas y técnicas del marco MITRE ATT&CK.

Táctica	Técnica (ID)	Cómo se presenta en esta campaña
Acceso inicial	Phishing: Archivo adjunto de spearphishing (T1566.001)	Archivo SVG malicioso enviado como archivo adjunto de un correo electrónico camuflado como un archivo de mensaje de voz
Ejecución	Ejecución por parte del usuario: archivo malicioso (T1204.002)	El ataque se basa en que el destinatario abra el archivo SVG, lo que hace que se ejecute el código JavaScript incrustado en el navegador.
Evasión de la defensa	Disfraces (T1036)	Archivo adjunto SVG etiquetado erróneamente como «text/plain» y camuflado como una notificación de mensaje de voz
Evasión de la defensa	Archivos o información ofuscados (T1027)	Los identificadores de basura, la construcción de cadenas de códigos de caracteres y la variación por muestra ocultan la intención
Evasión de la defensa	Desofuscar o descodificar archivos o información (T1140)	El script reconstruye las cadenas y su destino en tiempo de ejecución mediante String.fromCharCode
Evasión de la defensa	Alertas de seguridad falsas / Suplantación de identidad (T1656)	El mensaje se hace pasar por un remitente interno del sistema perteneciente al propio dominio del destinatario
Mando y control	Protocolo de la capa de aplicación: Protocolos web (T1071.001)	El script incrustado realiza una solicitud web a un punto final controlado por el atacante para recuperar la siguiente fase
Acceso mediante credenciales	Captura de entradas (T1056)	La fase posterior suele consistir en una página destinada a robar credenciales que se hace pasar por una página de inicio de sesión conocida.

Tabla 3: Correspondencia con el modelo MITRE ATT&CK para la campaña de contrabando de mensajes de voz SVG. La fase de acceso a credenciales se deduce a partir de la característica de la carga útil posterior obtenida, propia de esta clase de campaña.

Cómo lo detectó « INKY »

INKY No se basa en suposiciones sobre el tipo de archivo ni en firmas estáticas. Evalúa el contexto completo y el comportamiento de cada mensaje. De los 26.589 correos electrónicos analizados, INKY detectó la campaña y marcó todos los mensajes con la calificación de «Peligro ». La detección se basó en una señal universal, reforzada por una segunda:

• El contenido de phishing detectó el 100 % de la campaña. Todos y cada uno de los mensajes se clasificaron como phishing basándose en múltiples indicadores sospechosos, entre ellos el hecho de que incluyeran un archivo adjunto con contenido sospechoso y se asemejaran a una notificación falsa de mensaje de voz. Esta es la señal que detectó toda la campaña, en todas las organizaciones, sin excepción.
• La categoría «Remitente interno falsificado» lo detectó en el 95 % de la campaña. Como señal adicional, « INKY » reconoció que el mensaje afirmaba proceder del propio dominio del destinatario, pero procedía de una fuente externa, con un remitente que no se había autenticado en el servidor de correo de la organización. Esta categoría se activó en el 95 % de la campaña; los mensajes restantes, en organizaciones en las que esta categoría concreta no estaba activa, fueron detectados en su totalidad por «Phishing Content».

La pancarta « INKY » que se entregó a los destinatarios dejaba muy claro por qué el mensaje era peligroso:

Figura 6: El banner de advertencia « INKY » que aparece en un mensaje de campaña, en el que se explican ambas categorías de amenazas en un lenguaje sencillo. Se ha ocultado el dominio del destinatario.

Cada mensaje se evaluó en función de todas las categorías de amenazas de INKY . El contenido de phishing bastó por sí solo para marcar todos los mensajes de la campaña como peligrosos, y la categoría «Remitente interno falsificado» aportó una segunda señal que lo corroboraba en la mayoría de ellos.

Categoría de amenaza	Cobertura	Papel en la detección
Contenido de phishing	100%	Señal universal: ha captado todos los mensajes
Remitente interno falsificado	95%	Señal de confirmación en la mayoría de los mensajes

Tabla 2: Categorías de amenazas de « INKY » que se detectaron a lo largo de la campaña. El contenido de phishing marcó todos los mensajes; la suplantación de remitentes internos se corroboró en la mayoría de ellos.

Lo que detectó el filtro nativo de Microsoft

La diferencia entre el veredicto de INKYy el filtrado nativo del correo electrónico es muy marcada en esta campaña.

Microsoft asigna a cada mensaje un nivel de confianza de spam (SCL), en el que una puntuación de 0 o 1 significa que el mensaje no se ha considerado spam y se entrega normalmente en la bandeja de entrada, mientras que una puntuación de 5 lo marca como spam. A lo largo de esta campaña, 19 994 de los 26 589 mensajes (el 75 %) tenían un SCL de Microsoft de 0 o 1, y solo 4 777 (el 18 %) recibieron una puntuación SCL de 5.

En otras palabras, el filtro antispam nativo de Microsoft clasificó tres de cada cuatro de estos mensajes de phishing como correo no spam, destinado a la bandeja de entrada, mientras que INKY los marcó de forma independiente a todos como peligrosos.

Figura 7: Comparación entre la puntuación de spam de Microsoft y el veredicto de INKY a lo largo de la campaña. Microsoft clasificó el 75 % de los mensajes como «no spam» (SCL 0 o 1) y solo el 18 % como «spam» (SCL 5), mientras que INKY emitió un veredicto de «peligroso» para los 26.589 mensajes.

Lo que resulta sorprendente es que la campaña se creó a partir de una única plantilla. La misma estructura del mensaje, el mismo reclamo y el mismo archivo adjunto provocaron reacciones totalmente diferentes en los filtros nativos, dependiendo del buzón de correo receptor: considerado «limpio» en la mayoría de los casos y «spam» en algunos.

INKY, por el contrario, arrojó el mismo veredicto de riesgo en los 26.589 mensajes. Este es el argumento fundamental a favor de la detección basada en el comportamiento: un mensaje que, desde el punto de vista del spam, se considera «limpio», puede seguir siendo un ataque de suplantación de identidad para obtener credenciales, y solo un enfoque que evalúe el contexto completo de forma fiable permite detectarlo.

Indicadores de compromiso

Los siguientes indicadores están relacionados con esta campaña. Dado que la carga útil varía según la muestra, los indicadores de comportamiento y de patrones son más fiables que el hash de cualquier archivo concreto.

Indicador	Valor / Patrón	Notas
Tema «Lure»	Notificación de mensajes de voz o llamadas perdidas	Pretexto de ingeniería social
Patrón temático	mCaller left <name> - 34s Preview vHC- <date> <number>	<name> = recipient's email local-part
Nombre del archivo adjunto	PLAY_Voice-….svg	Nombre de archivo SVG al estilo de un mensaje de buzón de voz
Tipo MIME declarado	text/plain	SVG etiquetado erróneamente para eludir los escáneres
Comportamiento de la carga útil	SVG → JS ofuscado → solicitud a un punto final remoto	Inyección de scripts en tiempo de ejecución / callback
Ofuscación	String.fromCharCode, identificadores basura	Elimina las firmas estáticas

Tabla 4: Indicadores de compromiso de la campaña de contrabando de mensajes de voz SVG.

Recomendaciones

Para los equipos de seguridad

1. Trata los archivos SVG como contenido activo. Configura las pasarelas de correo electrónico y web para que analicen los archivos adjuntos SVG como posibles portadores de scripts, y no como imágenes inofensivas, y no te bases en el tipo MIME declarado para decidir si se deben analizar.
2. Considera la posibilidad de bloquear o poner en cuarentena los archivos adjuntos SVG entrantes. En el correo electrónico empresarial legítimo rara vez es necesario enviar archivos SVG directamente a los usuarios finales. Bloquear o aislar en un entorno de pruebas los archivos SVG entrantes elimina una superficie de ataque cada vez mayor con una interrupción mínima.
3. No confíes en las firmas basadas en hash de archivos. La ofuscación por muestra hace que los hash cambien constantemente. Da prioridad a la detección basada en el comportamiento y en el contenido, que evalúa lo que hace un archivo, no con qué coincide.
4. Refuerza los controles contra la suplantación interna. Asegúrate de que tu sistema de seguridad de correo electrónico pueda detectar los mensajes que aparentan proceder de tu propio dominio, pero que en realidad llegan desde fuera y sin autenticar, que es precisamente el «truco del sobre» en el que se basaba esta campaña.
5. Informa a los usuarios sobre los mensajes de voz e imágenes adjuntas inesperados. Recalca que un correo electrónico sobre una llamada perdida o un mensaje de voz con un archivo adjunto para «reproducir» el mensaje es un pretexto habitual de phishing, y que los archivos de imagen pueden contener código.

Para los destinatarios del correo electrónico

• Desconfía de las notificaciones de mensajes de voz o llamadas perdidas que te lleguen por correo electrónico con un archivo adjunto que debas abrir, sobre todo si no las esperabas.
• Nunca abras un archivo adjunto con extensión .svg que no esperaras recibir. A diferencia de las imágenes normales, los archivos SVG pueden ejecutar código al abrirse en un navegador.
• Considera como no fiable cualquier página de inicio de sesión a la que se acceda al abrir un archivo adjunto. Accede a los servicios directamente, en lugar de hacerlo a través de enlaces o archivos incluidos en los correos electrónicos.
• Recuerda que un correo electrónico que parezca proceder de tu propia organización puede ser, aun así, falso. Una notificación del «sistema» que parezca interna no es prueba de su legitimidad.

Conclusión

Esta campaña es un ejemplo clásico de una técnica que definirá las amenazas por correo electrónico en 2026: ocultar código ejecutable dentro de un tipo de archivo que todo el mundo considera una imagen inofensiva. Al envolver código JavaScript ofuscado en un archivo SVG, camuflar ese SVG como texto sin formato, suplantar la identidad de un remitente interno y disfrazar todo el conjunto como un mensaje de voz rutinario, los atacantes crearon un señuelo diseñado para eludir tanto los filtros automáticos como el criterio humano, a una escala de decenas de miles de mensajes en miles de organizaciones.

No funcionó. « INKY » detectó y marcó los 26 589 mensajes, utilizando señales de comportamiento que evalúan qué es y qué hace un mensaje, en lugar de fiarse de lo que este afirma ser. Esa distinción es importante: el filtrado nativo de spam clasificó tres cuartas partes de esta campaña como correo limpio, destinado a la bandeja de entrada. A medida que los atacantes siguen utilizando como arma formatos de archivo de confianza, un enfoque basado en el comportamiento —y no en firmas ni en suposiciones sobre el tipo de archivo— es lo que marca la diferencia entre la detección y la entrega.

Etiquetas: contrabando de SVG, phishing con SVG, archivos adjuntos SVG maliciosos, contrabando de JavaScript, phishing en el buzón de voz, evasión del tipo MIME, remitente interno falsificado, seguridad del correo electrónico en 2026, INKY PhishFence, inteligencia sobre amenazas