5 min de lectura Por Excello Mail Team

La Página de Inicio de Sesión Era Genuinamente de Microsoft. A DMARC Ya No le Quedaba Nada que Verificar.

Investigadores de Check Point documentaron una campaña que abandona por completo las páginas de inicio de sesión falsas: un señuelo con temática de Teams lleva a las víctimas a una pantalla real de autorización OAuth de Microsoft y las engaña para que aprueben una aplicación controlada por el atacante. Ningún dominio se suplanta, ninguna contraseña se roba, y todo el paso de robo de acceso ocurre en una página que DMARC nunca podría haber señalado.

Investigadores de Check Point documentaron una campaña de phishing que se salta la parte en la que los equipos de seguridad más tiempo invierten entrenando a las personas para detectar. Activa desde finales de junio hasta la segunda semana de julio, la campaña envió más de 200 correos a cerca de 120 organizaciones en una variedad de industrias y países, cada uno disfrazado como una notificación de actividad de Microsoft Teams que afirmaba que RR. HH. había asignado una tarea al destinatario. Hacer clic en el enlace no llevaba a ningún sitio falso. Llevaba a una página de inicio de sesión genuina de Microsoft, en el propio dominio de Microsoft, pidiendo a la víctima que aprobara permisos para una aplicación. Nada en la página era falsificado, porque nada necesitaba serlo.

El Ataque en Términos Simples

El señuelo en sí es ordinario: una notificación con estilo Teams que afirma nueva actividad de RR. HH., diseñada para conseguir un clic sin mucha reflexión. Lo que sucede después no es ordinario. En lugar de un formulario de inicio de sesión clonado en infraestructura del atacante, el enlace pasa por una URL de autorización OAuth genuina de Microsoft. A una víctima que inicia sesión no se le pide que entregue una contraseña en una página falsa, se le pide que apruebe permisos para una aplicación de terceros, con un mensaje que dice algo cercano a “Aceptar en nombre de tu organización”. Aprobarlo no roba ninguna credencial en absoluto. Emite a la aplicación registrada del atacante un token de acceso válido, con permiso delegado para leer correo, archivos, mensajes de Teams, SharePoint, OneDrive y datos de calendario, mientras esa concesión permanezca activa. Ninguna contraseña cambia de manos. Ningún aviso de autenticación multifactor es derrotado, porque la víctima lo completa ella misma, de forma real, en su propio nombre.

Por Qué DMARC Nunca Entra en Juego

Vale la pena detenerse en esto más tiempo que en la historia habitual de dominios similares. DMARC, SPF y DKIM existen para responder una pregunta: ¿es el dominio remitente de este mensaje quien dice ser? Esa pregunta importa enormemente para el correo de notificación inicial, y una organización con DMARC aplicado estrictamente y usuarios atentos aún puede detectar un remitente falsificado en esa etapa. Pero la parte de este ataque que realmente le cuesta a una víctima el acceso a su cuenta ocurre después del clic, en una página que no está suplantada, ni clonada, ni mintiendo sobre su dominio de ninguna manera, porque es simplemente la infraestructura real de Microsoft haciendo exactamente lo que fue construida para hacer: procesar una solicitud de consentimiento OAuth. La autenticación de correo electrónico no tiene jurisdicción sobre lo que un usuario decide aprobar con clic una vez que sale de la bandeja de entrada. Ese es un límite de confianza completamente distinto, gobernado por la política de consentimiento de aplicaciones, no por nada que DMARC evalúe.

El Punto Ciego Que Esto Expone

Los equipos de seguridad han pasado años entrenando defensas y usuarios en torno a un patrón específico: revisar el remitente, revisar el dominio, revisar la URL en busca de un error tipográfico. Esta campaña fue diseñada por investigadores que entendían ese patrón y la construyeron alrededor de él. Check Point señala que la técnica ya se ha comercializado como un servicio de phishing de alquiler, lo que significa que el volumen de campañas que la usen probablemente crecerá mucho más allá de esta única divulgación. Cada capa de autenticación de correo puede estar funcionando exactamente como se pretendía y este ataque aun así tiene éxito, porque el compromiso ocurre una capa más arriba, en el flujo de consentimiento de aplicaciones de Entra ID, una superficie de control que la mayoría de las organizaciones nunca ha configurado más allá de su estado predeterminado.

La solución práctica no vive en el DNS. Vive en restringir qué puede llegar a aprobar un usuario: exigir consentimiento del administrador para cualquier aplicación que solicite acceso más allá de un conjunto reducido y preaprobado de permisos, en lugar de dejar esa decisión en manos de cualquier empleado que reciba una notificación de Teams lo bastante convincente en una tarde ocupada.

Lo Que Esto Significa para tu Programa

Revisa y restringe la configuración de consentimiento de usuario en Microsoft Entra ID ahora, no después de un incidente. Las configuraciones predeterminadas en muchos tenants todavía permiten que cualquier usuario otorgue permisos delegados amplios a aplicaciones de terceros no verificadas, que es precisamente la brecha que explota esta campaña.

Trata las concesiones de aplicaciones OAuth como un activo monitoreado, de la misma forma en que monitoreas los reportes agregados de DMARC. La mayoría de las organizaciones tiene visibilidad sobre quién envía correo como su dominio y casi ninguna sobre qué aplicaciones de terceros mantienen actualmente acceso permanente a los buzones y archivos de sus usuarios.

Extiende la capacitación en concienciación de phishing más allá de “revisa la URL”. Una URL que apunta a un dominio genuino de Microsoft pasará cada verificación que un usuario capacitado haya aprendido a hacer, lo que hace que “¿esta solicitud de aplicación tiene sentido?” sea una pregunta más útil que “¿esta página se ve real?”.

Mantén la aplicación de DMARC en su lugar de todos modos, ya que aún cierra la puerta a dominios remitentes abiertamente suplantados. Esta campaña es un recordatorio de que la autenticación es necesaria pero no suficiente, no un argumento para omitirla.

La Conclusión

DMARC nunca estuvo en posición de fallar aquí porque la parte de este ataque que valía la pena detener ocurre completamente fuera de lo que DMARC evalúa. Un propietario de dominio puede aplicar una política estricta, mantener cada reporte limpio, y aun así ver a un atacante guiar a una víctima a través de una pantalla de inicio de sesión de Microsoft completamente genuina hacia la entrega de acceso permanente a su cuenta. Cerrar esa brecha requiere gobernanza de consentimiento de aplicaciones junto a la autenticación de correo, no en su lugar.


Excello Mail te da visibilidad continua sobre la aplicación de tu DMARC y sobre cada fuente autorizada para enviar correo bajo tu dominio, para que siempre sepas qué protege realmente tu autenticación y dónde están sus límites. Regístrate gratis en Excello Mail y mira exactamente quién envía correo como tú, en todo momento.