06 ago 20266 minutos de lectura
Kiara SaloojeeDMARC EnthusiastDentro de la plataforma PhaaS de VENOM: cómo el robo de credenciales elude la MFA

Resumen de la plataforma PhaaS de VENOM:
- VENOM es una plataforma PhaaS de acceso cerrado que evadió la detección durante más de nueve meses.
- Derrota la MFA explotando credenciales reales y códigos de dispositivo.
- DMARC y BIMI no detienen el ataque dirigido a ejecutivos, porque usa cuentas comprometidas, no la suplantación del dominio.
- Las mismas tácticas llegan a los clientes mediante avisos de entrega falsos y estafas de reembolso, que DMARC y BIMI sí detienen.
- Los dominios lookalike necesitan cobertura aparte, porque quedan fuera de lo que protegen DMARC y BIMI.
Una campaña de robo de credenciales de cinco meses dirigida a ejecutivos C-suite ha expuesto una plataforma de phishing como servicio (PhaaS) antes no documentada llamada VENOM. El equipo de Abnormal AI identificó la operación, que se desarrolló de noviembre de 2025 a marzo de 2026.
El hallazgo muestra cómo una sola plataforma PhaaS puede neutralizar la autenticación multifactor (MFA) sin explotar un fallo de protocolo. Este tipo de robo de credenciales no necesita un exploit técnico, solo paciencia y una plataforma PhaaS bien gestionada.
Esta publicación explica qué es la plataforma PhaaS de VENOM, cómo sus correos evaden la detección y por qué funcionan estas técnicas de robo de credenciales.
¿Qué es la plataforma PhaaS de VENOM?
VENOM es una plataforma PhaaS de acceso cerrado. Estuvo operativa al menos nueve meses antes de que los investigadores de Abnormal la descubrieran y, durante ese periodo, no apareció en ninguna base pública de inteligencia de amenazas ni en un mercado clandestino.
La plataforma incluye un modelo de licencia y activación, una interfaz completa de gestión de campañas y almacenamiento estructurado de tokens. Quienes ejecutan campañas en VENOM no necesitan construir su propia infraestructura. Activan el acceso bajo el modelo de licencia de VENOM y dirigen las campañas a través de ella.
Durante la campaña de cinco meses, los operadores de VENOM atacaron a ejecutivos C-suite, vicepresidentes y presidentes nombrados en más de 20 sectores; el 60% de los destinatarios objetivo tenía esos cargos.
No fue una campaña de disparar a ciegas. Los objetivos se eligieron por nombre, lo que apunta a un reconocimiento previo y confirma que la intención de esta operación de robo de credenciales era el acceso persistente a cuentas de alto valor, no el fraude oportunista.
Cómo el correo evade la detección
Cada campaña de VENOM comienza con un correo que suplanta una notificación de SharePoint sobre el uso compartido de documentos. La dirección del remitente se genera de forma dinámica para coincidir con el dominio del objetivo, mientras que el correo se entrega a través de un grupo rotativo de cuentas empresariales comprometidas.
El correo no contiene un enlace clicable. En su lugar, incrusta un código QR, que traslada la interacción fuera de la red corporativa y al dispositivo personal del objetivo. También hay elementos HTML aleatorizados, incluidas clases CSS falsas y comentarios pensados para confundir a los escáneres automatizados.
Una vez escaneado, el código QR lleva a una página de destino que filtra a los visitantes antes de servir la página de robo de credenciales. La dirección de correo del objetivo va codificada en Base64 doble en el fragmento de la URL, que nunca se transmite en las peticiones HTTP. Los investigadores de seguridad y los sandboxes que sondean el enlace son redirigidos a sitios benignos.
Solo los objetivos genuinos llegan al harvester, donde toma el control uno de dos modos de robo de credenciales. Ese filtrado es probablemente lo que permitió a la plataforma PhaaS de VENOM operar tanto tiempo sin ser detectada.
Dos tipos de robo de credenciales: AiTM y código de dispositivo
Cuando un objetivo llega a la página de recolección, VENOM ofrece a sus operadores dos métodos distintos de robo de credenciales.
El primero es el modo de adversario en el medio (AiTM). El recolector presenta el proveedor de identidad (IdP) real del objetivo, con la marca real de la organización, la dirección de correo precargada y, si la cuenta está federada, la pantalla de inicio de sesión genuina. Las credenciales y los códigos MFA se retransmiten a los sistemas propios de Microsoft.
VENOM registra en silencio un segundo dispositivo MFA en la cuenta, lo que da al atacante acceso permanente aunque el autenticador original siga intacto.
El segundo método se centra en el código de dispositivo. En lugar de mostrar un formulario de inicio de sesión, la página indica al objetivo que introduzca un código y apruebe lo que Microsoft presenta como una solicitud de inicio de sesión. El objetivo se autentica directamente con Microsoft. Los tokens se entregan al backend del atacante.
Ambos caminos logran el mismo resultado: acceso persistente antes de que pueda empezar la remediación. Ya sea por AiTM o por código de dispositivo, el resultado es un evento de robo de credenciales que, desde fuera, parece un inicio de sesión normal.
Por qué la MFA no detiene esta plataforma PhaaS
La MFA está diseñada para detener el robo de credenciales que se basa solo en una contraseña robada. La plataforma PhaaS de VENOM la derrota por otra vía. Ningún método explota un fallo del protocolo MFA en sí. La MFA se vuelve ineficaz no por romper el protocolo, sino por operar dentro de él.
En el modo AiTM, las credenciales y los códigos MFA se retransmiten a la API en vivo de Microsoft en tiempo real, y el registro silencioso de un segundo dispositivo MFA por parte del atacante significa que la cuenta ahora confía en dos autenticadores: el dispositivo original del objetivo y el del atacante.
En el modo de código de dispositivo, que no requiere ningún relay AiTM, no hay formulario de credenciales que detectar ni MFA que interceptar. El objetivo se autentica directamente con Microsoft y aprueba lo que parece un inicio de sesión rutinario de un dispositivo, y esa aprobación sola entrega al atacante acceso persistente.
Ya sea por el relay AiTM o por el flujo de código de dispositivo, la MFA y esta forma de robo de credenciales coexisten porque el atacante obtiene acceso a través del propio sistema de autenticación.
Esta es la lección central de la plataforma PhaaS de VENOM. Las organizaciones que tratan la MFA como una barrera final quedan expuestas exactamente a este tipo de ataque AiTM y a su equivalente de código de dispositivo.
La segunda bandeja: cuando los clientes enfrentan las mismas tácticas
La campaña de cinco meses de VENOM apuntó a ejecutivos, pero las mismas tácticas de fondo —marca creíble, urgencia y un pretexto plausible— aparecen igual de a menudo en una segunda bandeja: la del cliente. Las marcas de Retail y comercio electrónico ven las mismas técnicas usadas contra sus clientes mediante avisos de entrega falsos y estafas de reembolso que suplantan el propio dominio de la marca.
Este riesgo es distinto del robo de credenciales dirigido a ejecutivos descrito arriba. Es una amenaza a la reputación de la marca más que a la cuenta de un solo ejecutivo, y llega a cada cliente que confía en un mensaje con el nombre de la marca.
Un cliente que recibe un correo fraudulento de reembolso pendiente que parece provenir de un minorista de confianza no tiene forma de distinguirlo de un mensaje legítimo, a menos que el dominio del minorista esté protegido en la capa de autenticación.
La aplicación completa de DMARC bloquea el uso no autenticado del propio dominio de una empresa, lo que impide que los atacantes envíen correos que parezcan originarse en ese dominio. Conviene ser precisos sobre el alcance. La aplicación de DMARC no detiene los correos de VENOM dirigidos a ejecutivos, porque esos se originan en cuentas comprometidas.
p=reject bloquea el uso no autorizado de tu dominio. No hace nada ante una cuenta ejecutiva comprometida, porque ese correo está autenticado.
Una vez que p=reject está activo, BIMI refuerza el correo legítimo de la marca con un logo verificado en la bandeja del destinatario, dando a los clientes una señal visual de que el mensaje es genuinamente de la marca. Juntos, la aplicación de DMARC y BIMI abordan el riesgo que acompaña, y es distinto, al robo de credenciales dirigido a ejecutivos descrito arriba.
Defensa frente al robo de credenciales al estilo VENOM
La plataforma PhaaS de VENOM demuestra que la MFA sola no basta contra este estilo de robo de credenciales, y la defensa exige una respuesta en capas.
Los equipos de seguridad deben revocar sesiones activas y concesiones de tokens en Entra ID para cualquier cuenta sospechosa de compromiso. Restablecer la contraseña sola no invalida los refresh tokens de código de dispositivo, así que la revocación explícita es necesaria para cerrar el acceso que establece este método de robo de credenciales.
Los equipos también deben monitorizar registros inesperados de dispositivos MFA y alertar cuando se añade un dispositivo fuera de un flujo gestionado por TI. Este es el indicador más claro de que ha habido actividad AiTM en una cuenta.
Y porque la plataforma PhaaS de VENOM se construyó específicamente para derrotar herramientas basadas en firmas y coincidencia de patrones, la detección conductual que señala anomalías en el comportamiento de envío y la actividad de la cuenta captura lo que las reglas estáticas pasan por alto.
En el lado del dominio, desplegar la aplicación completa de DMARC y BIMI reduce el uso no autorizado del propio dominio de la empresa. Los dominios lookalike, los que imitan la marca sin usar su dominio exacto, quedan fuera de lo que cubren DMARC y BIMI y requieren monitorización aparte, como Lookalike Domain Defense de Sendmarc.
Mira cómo DMARC Management y Lookalike Domain Defense cierran la brecha del lado del dominio.


