El 17 de junio de 2026, el equipo de seguridad Red Team de Barracuda Networks publicó una simulación que rastreó un ataque de correo electrónico impulsado por inteligencia artificial desde el primer mensaje de phishing hasta el compromiso total del endpoint y el acceso persistente del atacante. Toda la cadena tomó menos de cinco minutos.
La simulación no fue un caso extremo fabricado. Utilizó herramientas disponibles comercialmente y técnicas de ataque realistas observadas en campañas activas. El entorno objetivo ejecutaba defensas empresariales estándar. El resultado fue una cadena de ataque de tres etapas que eludió la autenticación multifactor, estableció persistencia a largo plazo en el endpoint, y lo hizo partiendo de un correo electrónico que no generaría alertas visuales ni para un usuario experimentado.
DMARC no aparece en la lista de fallos. El ataque pasó la autenticación en cada etapa.
La Cadena de Ataque de Tres Etapas
Primera etapa: phishing generado por IA
El ataque comenzó con un correo elaborado por un modelo de lenguaje de gran escala para imitar una notificación legítima de compartición de archivos de Microsoft SharePoint. El mensaje no contenía errores ortográficos, formato inusual ni ninguna dirección de remitente que generara sospechas visuales. El enlace apuntaba a una página con el estilo de una vista previa de documentos de SharePoint.
Este es el efecto práctico de la IA en el phishing en 2026. Las señales gramaticales en las que los usuarios capacitados aprendieron a fijarse – capitalización inconsistente, fraseología extraña, spoofing evidente de dominio – han desaparecido en gran medida de las campañas dirigidas. Los modelos de lenguaje de gran escala generan texto de señuelo limpio y contextualmente apropiado a escala, y el contenido supera la revisión humana casual así como muchos filtros automáticos de contenido. El registro DMARC del dominio remitente era válido. La alineación SPF era correcta. DKIM pasó.
El correo estaba autenticado. También era malicioso.
Segunda etapa: adversario en el medio y bypass de MFA
Cuando el objetivo hizo clic en el enlace, encontró un proxy de retransmisión en tiempo real. Los ataques de adversario en el medio (AitM) colocan este retransmisor entre la víctima y el servicio de inicio de sesión genuino. La víctima completa la autenticación normalmente, incluyendo la introducción de su código MFA. El retransmisor captura tanto las credenciales como el token de sesión que el servicio legítimo emite tras el inicio de sesión exitoso.
El código MFA es inútil para el atacante. El token de sesión – que no requiere el factor MFA para reutilizarse – es todo lo que necesita. Con un token de sesión válido en su poder, el atacante tiene acceso autenticado a la cuenta objetivo sin conocer nunca la contraseña ni el factor MFA. El requisito de autenticación fue satisfecho por el servicio legítimo en nombre de la víctima. El atacante llega con una credencial válida.
Tercera etapa: ClickFix y persistencia en el endpoint
La tercera etapa presentó a la víctima un aviso falso de resolución de problemas que parecía provenir de un sitio de aspecto legítimo. El aviso instruía al usuario a abrir su terminal o cuadro de diálogo Ejecutar y pegar un comando. El comando estaba precargado en el portapapeles. Un clic de confirmación lo ejecutó.
ClickFix funciona porque delega la ejecución en la víctima. El atacante no entrega un binario malicioso ni activa una firma de detección en el endpoint. El usuario ejecuta el comando él mismo, y ese comando establece la persistencia del atacante en la máquina.
Tiempo total transcurrido en la simulación de Barracuda: menos de cinco minutos desde el correo inicial hasta el acceso persistente al endpoint.
Qué Protege DMARC y Qué No
DMARC resuelve un problema específico y bien definido. Verifica que el dominio en el encabezado From de un correo electrónico está alineado con el dominio que autenticó el mensaje mediante SPF o DKIM. Esto impide que terceros externos envíen correo que afirme falsamente originarse en su dominio. Si su organización tiene un registro DMARC en p=reject, ningún atacante puede enviar correos que afirmen ser de su dominio a destinatarios cuyos proveedores respetan la aplicación de DMARC.
Esta es una protección extremadamente valiosa. Cierra la puerta a la suplantación directa de dominio, que es el mecanismo más común en la falsificación de marca y los ataques de compromiso de correo electrónico empresarial lanzados desde infraestructura externa.
Lo que DMARC no aborda es lo que ocurre después de que un mensaje es entregado. Un correo que pasa DMARC ha sido autenticado en la capa de transporte. El contenido de ese correo – el enlace que contiene, la página que carga ese enlace, cada instrucción que el destinatario sigue tras el evento de entrega – está completamente fuera del alcance de DMARC.
La simulación de Barracuda explotó exactamente este límite. El correo de phishing era auténtico a nivel del remitente. DMARC vio un dominio correctamente configurado, SPF válido y una firma DKIM aprobada. El ataque vivió en lo que vino después del evento de entrega: la página de retransmisión AitM, la captura de credenciales, el robo del token de sesión, el aviso ClickFix.
Ninguna de esas etapas es visible para DMARC. Todas tuvieron éxito.
La Escala de la Brecha de Autenticación en 2026
La simulación de Barracuda apareció en un contexto de fallos de autenticación persistentes en el ecosistema general del correo electrónico. El Informe de Amenazas 2026 de Cloudflare, elaborado a partir del análisis de 450 millones de correos electrónicos, encontró que el 43% falló en las verificaciones SPF, el 44% carecía de firmas DKIM válidas, y el 46% falló completamente en la validación DMARC.
Estos números representan dos problemas distintos que operan simultáneamente. La gran parte de los correos que fallan en la autenticación son remitentes que no han implementado correctamente los fundamentos – correos que no deberían pasar las puertas de autenticación y frecuentemente no lo hacen. Esa población es el objetivo principal de la aplicación de DMARC.
Pero dentro del correo que sí pasa la autenticación – el correo que DMARC, SPF y DKIM validan – hay un subconjunto creciente de phishing elaborado con IA diseñado específicamente para pasar esas verificaciones mientras ejecuta ataques de múltiples etapas contra los destinatarios. El mismo informe de Cloudflare documentó más de 123 millones de dólares en intentos de robo financiero BEC interceptados en 2025, con un intento promedio calibrado en 49.225 dólares, una cifra establecida deliberadamente justo por debajo de los umbrales de aprobación de pagos ejecutivos típicos.
Lo Que la Simulación Significa para la Seguridad de su Correo
La aplicación de DMARC en p=reject sigue siendo el punto de partida no negociable. La simulación de Barracuda no es un argumento en contra de DMARC. Es un argumento para entender lo que cubre DMARC, de modo que no lo trate como una solución completa. Sin DMARC en aplicación, terceros externos pueden suplantar directamente su dominio. Si su organización aún no está en p=reject, esa sigue siendo la primera prioridad.
La protección post-entrega cubre la brecha que DMARC no puede alcanzar. La cadena de ataque de cinco minutos tuvo éxito en la capa que existe después de la entrega. La seguridad de correo post-entrega – capacidades que pueden retirar mensajes después de que lleguen, detectar infraestructura de retransmisión AitM y señalar comportamiento anómalo de sesión – opera precisamente en la capa que DMARC no alcanza.
Los ataques con IA requieren respuesta automatizada a la misma velocidad. Una cadena de ataque que logra acceso persistente al endpoint en cinco minutos no deja tiempo para que un analista humano detecte, investigue y responda. La detección y respuesta deben operar a velocidad de automatización.
El MFA estándar no detiene AitM. La simulación eludió el MFA capturando el token de sesión después de que la autenticación legítima se completó. Esta es una limitación bien conocida del MFA basado en TOTP y SMS cuando la infraestructura AitM está en el camino. La autenticación vinculada al hardware, como las llaves de acceso FIDO2 y las credenciales de sesión vinculadas al dispositivo, resiste AitM porque la credencial no puede reproducirse desde una máquina diferente.
Los Fundamentos de Autenticación Importan – y Solos No Son Suficientes
La adopción de DMARC entre los 1,8 millones de dominios más importantes alcanzó el 52,1% en 2026, frente al 47,7% el año anterior y el 27,2% hace tres años. Google, Yahoo y Microsoft exigen DMARC para los remitentes masivos y aplican penalizaciones de entrega al correo que no cumple. La trayectoria es clara, y el piso de autenticación está subiendo.
Esa base vale la pena construirla bien. Cada organización que avanza de p=none a p=reject cierra la superficie de ataque de suplantación directa que DMARC fue diseñado para eliminar. Eso importa.
Lo que demuestra la simulación de Barracuda es que la superficie de ataque no termina en la puerta de autenticación. Un correo puede estar completamente autenticado, entregarse con éxito, pasar todos los filtros en la capa de transporte, y aun así iniciar una cadena de ataque que alcanza el endpoint en menos de cinco minutos. Las organizaciones que comprenden esta distinción están construyendo una postura por capas – DMARC en aplicación, protección post-entrega, autenticación resistente a AitM y controles de endpoint – en lugar de tratar cualquier capa individual como la respuesta completa.
Excello Mail le ofrece visibilidad completa sobre su configuración de DMARC, SPF y DKIM en todos sus dominios de envío, para que pueda cerrar la brecha de autenticación antes de que los atacantes la exploten. Regístrese gratis en Excello Mail y asegúrese de que su base de autenticación de correo electrónico sea sólida.