Proofpoint lleva desde mayo de 2026 siguiendo un grupo de amenazas al que llama UNK_MassTraction, y la campaña es un recordatorio útil de que algunos de los ataques más dañinos que llegan por correo nunca tocan nada de lo que DMARC fue diseñado para verificar. El grupo encadena dos vulnerabilidades en Roundcube, el cliente de correo web de código abierto ampliamente usado por universidades y organizaciones pequeñas para operar su propio correo alojado, para pasar de que una víctima simplemente abra un mensaje a una puerta trasera permanente en el propio servidor de correo. No hace falta hacer clic en ningún enlace. No hace falta teclear ninguna credencial en una página falsa. Y no hace falta suplantar ningún dominio en ningún punto de la cadena.
Cómo Funciona la Cadena de Explotación
El punto de entrada es CVE-2024-42009, un fallo de cross-site scripting en Roundcube que no sanea correctamente ciertos manejadores de eventos de animación HTML, permitiendo que se ejecute JavaScript del atacante en el momento en que se abre un correo manipulado en una bandeja de entrada de Roundcube vulnerable. Los señuelos de Proofpoint eran deliberadamente genéricos, diseñados únicamente para que el objetivo viera el mensaje, ya que ver el mensaje es toda la superficie de ataque que necesita este fallo. El JavaScript que se dispara es un ladrón del lado del navegador construido a medida, al que Proofpoint llamó IceCube, que escapa del sandbox de iframe de Roundcube mediante recorrido del DOM y obtiene acceso completo al DOM de la página y a la sesión autenticada activa de Roundcube de la víctima. A partir de ahí, IceCube despliega lo que Proofpoint llama “helpers” que explotan un segundo fallo, CVE-2025-49113, una vulnerabilidad de deserialización de PHP que abusa de cómo el Crypt_GPG_Engine incorporado de Roundcube analiza la entrada, para instalar una webshell ligera que los investigadores llamaron SquareShell directamente en el servidor de correo. Desde junio de 2026, la cadena también añadió un mecanismo de respaldo: si la instalación de SquareShell falla, se ejecuta un script de shell a través del mismo fallo de deserialización para entregar VShell, una puerta trasera residente en memoria, en lugar de simplemente desistir.
Ambas vulnerabilidades son noticia vieja en términos de parches. Roundcube publicó correcciones para CVE-2024-42009 y CVE-2025-49113 en las versiones 1.5.10 y 1.6.11 a mediados de 2025. UNK_MassTraction no está explotando un día cero; está explotando la brecha entre el momento en que se publica un parche y el momento en que un servidor de correo autoalojado realmente se actualiza, una brecha que en universidades que operan infraestructura de correo con personal de TI limitado puede extenderse durante un año o más.
Quién Está Siendo Objetivo
La focalización es estrecha y deliberada. Proofpoint ha observado directamente a menos de diez universidades afectadas, con una huella real estimada en unas pocas docenas al contar la infraestructura relacionada, concentrada en administradores y profesores de departamentos de física e ingeniería en instituciones importantes de EE. UU. y Canadá, particularmente aquellas con vínculos de seguridad nacional o investigación en astrofísica y física de partículas. Esa especificidad, combinada con una red encubierta de retransmisión compartida con otros grupos alineados con China, el eventual cambio hacia VShell y los artefactos en idioma chino dejados en los propios correos de phishing, es lo que lleva a Proofpoint a evaluar esto como una presunta operación de espionaje alineada con China en lugar de un delito con motivación financiera.
Por Qué DMARC No Tiene Nada Que Decir Aquí
Vale la pena precisar por qué esta campaña queda completamente fuera del alcance de DMARC, porque la razón es distinta de las campañas de toma de cuenta y de intermediario (adversary-in-the-middle) que hemos cubierto antes. DMARC, SPF y DKIM existen para responder una sola pregunta: ¿este mensaje realmente provino de infraestructura que el dominio de envío declarado autorizó? No dicen absolutamente nada sobre lo que contiene el mensaje. CVE-2024-42009 se dispara por un renderizado de HTML malformado dentro del cliente de correo web, no por nada relacionado con la identidad del remitente. Un atacante podría enviar esta misma carga útil a través de un dominio con un registro DMARC perfecto, aplicación estricta y un SPF y DKIM impecables, y el exploit se activaría exactamente igual, porque la vulnerabilidad reside en cómo Roundcube analiza los eventos de animación HTML, no en quién tiene permitido reclamar un dominio.
La segunda mitad de la cadena hace la brecha aún más concreta. Una vez que SquareShell o VShell están instalados en el servidor de correo, el atacante tiene un punto de apoyo en la infraestructura que el propio registro DMARC de la universidad autoriza explícitamente para enviar correo. Cualquier mensaje que ese servidor envíe después se originará desde la IP correcta, podrá firmarse con la clave DKIM real del dominio si el atacante decide abusar de ese acceso, y pasará limpiamente la alineación DMARC en cualquier destinatario que la verifique, porque, hasta donde el protocolo puede saber, es genuinamente el servidor de correo de la universidad enviando correo genuino de la universidad. DMARC se construyó para detectar a alguien que falsifica un dominio desde afuera. No tiene ningún mecanismo para notar que el servidor legítimo detrás de ese dominio ha sido entregado silenciosamente a otra persona.
Qué Deben Hacer los Defensores
Actualizar Roundcube ahora mismo si aún no lo han hecho. Las versiones 1.5.10 y 1.6.11 cierran ambas vulnerabilidades de esta cadena, y llevan disponibles más de un año. Si su organización usa Roundcube y no puede confirmar hoy su nivel de parcheo, trátelo como el elemento más urgente de su lista.
Auditar en busca de compromisos existentes, no solo de exposición futura. Como esta cadena ha estado activa desde mayo de 2026 y los fallos subyacentes son públicos desde hace más de un año, cualquier instancia de Roundcube sin parchear debería revisarse en busca de webshells, tareas cron inesperadas o procesos desconocidos, y no simplemente parchearse asumiendo que está limpia.
Restringir y monitorear la ruta de correo saliente del servidor Roundcube por separado del resto de su infraestructura. Un servidor de correo web que de repente empieza a enviar correo por rutas, volúmenes u horarios que no coinciden con su patrón habitual es una señal más fuerte que cualquier cosa que los reportes agregados de DMARC por sí solos puedan mostrar, ya que el correo en sí se autenticará limpiamente.
Tratar la aplicación de DMARC y el parcheo del webmail como dos controles separados que no se sustituyen entre sí. Bloquear todos los dominios que su organización posee en p=reject sigue siendo correcto y necesario. Eso no reduce la urgencia de mantener actualizado el software que realmente procesa su correo, porque ambos controles protegen contra modos de fallo completamente distintos.
La Conclusión
UNK_MassTraction no es una elusión de DMARC en ningún sentido significativo, porque nunca necesitó acercarse a DMARC en absoluto. Apunta al software que renderiza y almacena el correo, no a las afirmaciones de identidad que verifica la autenticación de correo, y una vez que tiene éxito, hereda la misma ruta de envío confiable y autenticada que DMARC fue diseñado para proteger. Dos parches que llevan más de un año disponibles habrían detenido esta campaña de raíz. Ninguna política DMARC, por estricta que sea, lo habría hecho.
Excello Mail le da visibilidad continua sobre sus reportes agregados de DMARC y sus fuentes de envío, para que pueda detectar patrones inusuales incluso desde infraestructura en la que ya confía. Regístrese gratis en Excello Mail para mantener esa visibilidad en su lugar mientras su equipo mantiene parcheado el resto de la pila de correo.