Tenías MFA y aun así entraron: cómo funciona el robo de sesiones en Microsoft 365 y cómo frenarlo

Entre el 14 de julio y el 22 de septiembre de 2026, un atacante entró a cuentas de Microsoft 365 en 79 organizaciones sin conocer una sola contraseña y sin romper el MFA. No lo necesitó: robó la sesión que Microsoft emite después de que el usuario completa el segundo factor y la reutilizó desde sus propios servidores. Así lo recogió Help Net Security el 23 de octubre.

Las cifras dan la escala: 497 inicios de sesión exitosos, más de 200 000 intentos fallidos, al menos 48 equipos falsos registrados en Entra ID y métodos MFA reemplazados en 19 organizaciones. Con el correo bajo control, el atacante ocultó mensajes con reglas de bandeja y usó al menos un buzón para enviar un correo de nómina a un contador externo: el patrón clásico del fraude por correo corporativo (BEC).

La lección no es que el MFA no sirva. Es que el MFA protege el inicio de sesión, no la sesión que viene después. En este artículo explico cómo funciona el ataque, qué hizo el atacante dentro de las cuentas y qué controles concretos de Entra ID lo habrían detenido.

Qué es el robo de sesión y por qué el MFA no lo detiene

Cuando un usuario completa usuario, contraseña y MFA, Entra ID le entrega artefactos de sesión: una cookie de sesión (ESTSAUTH/ESTSAUTHPERSISTENT en el navegador), un refresh token y access tokens de corta vida para cada recurso (Exchange Online, Graph, SharePoint). Esos artefactos ya llevan el claim de que el MFA se cumplió. Quien los posea no tiene que volver a pasar el segundo factor.

En un ataque adversary-in-the-middle (AiTM) la víctima no inicia sesión en Microsoft, sino en un proxy inverso que se interpone entre ella y Microsoft. El proxy le muestra la página real de inicio de sesión y le reenvía el desafío MFA real; la víctima aprueba la notificación o escribe el código sin notar nada. Cuando Microsoft emite la sesión, el proxy se queda con una copia. Un OTP por SMS, un código TOTP o un push de Authenticator caen igual, porque ninguno está ligado al dominio en el que se escribe.

En esta campaña los tokens llegaron por tres vías:

• Relays AiTM detrás de páginas de inicio de sesión falsas.
• Phishing de device code: se engaña a la víctima para que escriba un código en la página legítima de Microsoft (microsoft.com/devicelogin). Al hacerlo autoriza la sesión del atacante y le entrega directamente un refresh token y un access token válidos.
• Ingeniería social durante un inicio de sesión legítimo.

Luego el atacante reprodujo (replay) esos tokens de forma masiva desde su infraestructura. A esa técnica se le llama token spraying: el mismo patrón que el password spraying, pero disparando tokens robados en lugar de contraseñas adivinadas.

La sesión se roba después del MFA y se reutiliza en minutos

1. VíctimaAprueba el MFA real en el prompt de Microsoft.
2. Relay AiTMProxy que copia la cookie y los tokens de sesión.
3. Microsoft Entra IDEmite la sesión post-MFA. El atacante ya tiene una copia.
4. Host de replayReutiliza el token desde el bloque 193.26.115.0/24, sin pedir MFA.
5. Microsoft 365Acceso a Exchange, Graph y SharePoint con la sesión robada.
6. Persistencia y fraudeEquipo falso en Entra, Authenticator del atacante, reglas ocultas y BEC.

El relay y el host de replay están en proveedores distintos: la captura y el uso de la sesión se defienden por separado.

Anatomía de la campaña

El operador dividió el ataque en dos niveles de infraestructura en proveedores distintos: relays AiTM que capturan la sesión y hosts de replay que la reutilizan. Los hosts de replay estaban en el bloque 193.26.115.0/24 de 1337 Services GmbH (AS210558, Hamburgo), un proveedor legítimo usado bajo el modelo “bring your own IP”. Microsoft Entra ID Protection marcó varias de esas IP como asociadas a actores de amenaza conocidos.

La separación tiene una consecuencia práctica: bloquear el rango de replay no impide que se sigan capturando sesiones, y bloquear un relay no invalida los tokens ya robados. Además, el robo y el uso ocurren en minutos. El 21 de julio pasaron 12 minutos entre que la víctima llegó al prompt MFA y la sesión reapareció desde 1337 Services; el 22 de septiembre, cuatro.

Dos herramientas de replay

El Build A es el más ruidoso y el más fácil de cazar: un user agent node intercambiando tokens con el client ID de Microsoft Office desde un hosting no es tráfico de oficina. El Build B, en cambio, se parece a navegación normal.

Cuatro fases y seis IP

El operador rotó de IP tras periodos de silencio de una a dos semanas. Bloquear una sola dirección habría detenido, como mucho, una fase. Bloquear el /24 habría cubierto los seis hosts principales, aunque también usó otras IP de 1337 Services fuera del rango. Bloquear por IP ayuda, pero no es una estrategia.

Qué hicieron una vez dentro

Un token robado caduca o se revoca. Por eso lo primero que hizo el atacante fue convertir el acceso temporal en acceso persistente, y después preparar el fraude.

Persistencia: equipos falsos y MFA propio

• Equipos registrados en Entra ID. Al menos 48 dispositivos con nombre DESKTOP- más ocho caracteres hexadecimales en mayúscula (por ejemplo, DESKTOP-54521F46). El nombre por defecto de Windows usa siete caracteres alfanuméricos, así que el patrón es una buena señal. Un dispositivo registrado le da al atacante una forma más duradera de pedir tokens y se queda en el directorio hasta que alguien lo borra.
• Métodos MFA reemplazados. En 19 organizaciones se borraron los métodos MFA de la víctima y se registró uno nuevo dentro de las tres horas siguientes al primer acceso. En el caso del 21 de julio, un Authenticator etiquetado “iPhone 13” se activó menos de una hora después del secuestro. Con su propio factor registrado, el atacante puede pasar el MFA cuando quiera, y ese acceso sobrevive a un cambio de contraseña.

Encubrimiento: reglas de bandeja ocultas

Todas las reglas sospechosas se crearon desde VPN o hosting alquilado (ExpressVPN, NordVPN, LeaseWeb, Interserver, entre otros), nunca desde 1337 Services. En cuatro buzones se crearon por la API REST de Outlook, no desde el cliente. Los nombres eran deliberadamente anodinos: ., sss, ss, iT, ,., ........, s, d. Las acciones: marcar como leído y borrar todo el correo, o moverlo a carpetas que nadie abre como RSS Feeds, RSS Subscriptions o Conversation History.

El fraude

En un incidente de la fase 3, el atacante modificó una regla s para atrapar cualquier mensaje que mencionara nómina, depósito directo, banco o bono. Cinco minutos después creó una regla d que ocultaba todo el correo de un contador externo, y desde el buzón comprometido le envió un correo relacionado con nómina. La víctima nunca vería la respuesta. En la fase 1, otro buzón se usó para enviar spam a cientos de destinatarios externos, y en la fase 2 el atacante registró un dominio parecido al de un socio comercial de la víctima.

Cómo frenarlo: controles preventivos

El dato más útil de esta campaña está en la fase 3. La IP 193.26.115.72 acumuló 1052 inicios bloqueados, todos en solo cuatro organizaciones cuyas políticas de Conditional Access rechazaron el acceso. En las 29 organizaciones donde sí entró, nada se lo impidió. Conditional Access bien configurado fue la diferencia.

Estos son los controles que recomiendo, del más urgente al más avanzado. Conditional Access requiere Entra ID P1; las políticas basadas en riesgo, P2.

1. Una política base sin huecos. Exigir MFA (o bloquear) para todos los usuarios, todas las aplicaciones en la nube y todos los tipos de cliente, sin condiciones. Las exclusiones se limitan a cuentas de emergencia (break-glass) monitoreadas.
2. MFA resistente al phishing para quien maneja dinero o administra. Con authentication strengths, exigir FIDO2/passkeys, Windows Hello for Business o autenticación por certificado a finanzas, tesorería, gerencia y administradores. Estas credenciales están ligadas criptográficamente al dominio real: un relay AiTM no puede completar la firma, así que no hay sesión que robar.
3. Exigir dispositivo administrado. Pedir equipo compatible en Intune o unido a Entra híbrido para acceder a correo y archivos. Un token reproducido desde un VPS no viene de un equipo conforme y se rechaza.
4. Bloquear el flujo de device code. Con la condición Authentication flows de Conditional Access, bloquear device code para todos y excluir solo las cuentas de servicio o salas que realmente lo necesiten, con permisos restringidos.
5. Proteger el registro de dispositivos y de métodos MFA. Limitar quién puede unir o registrar equipos en Entra ID y exigir MFA para hacerlo. Proteger la acción Register security information (por ejemplo, solo desde red corporativa o con un Temporary Access Pass), para que un atacante con sesión robada no pueda inscribir su propio Authenticator.
6. Ligar el token al dispositivo y evaluar en continuo. Activar Token protection en Conditional Access donde los clientes lo soporten, para que un token copiado no sirva en otra máquina. Aplicar Continuous Access Evaluation con aplicación estricta de ubicación donde tenga sentido.
7. Políticas por riesgo. Con Entra ID P2, bloquear o forzar reautenticación ante riesgo de inicio de sesión medio o alto. Microsoft ya marcaba varias IP de esta campaña como asociadas a actores de amenaza.
8. Cortar la persistencia por aplicaciones. Deshabilitar el consentimiento de usuarios a aplicaciones nuevas y exigir un flujo de aprobación del administrador.
9. Endurecer Exchange Online. Bloquear el reenvío automático externo y alertar ante la creación de reglas de bandeja, sobre todo las que borran, marcan como leído o mueven a carpetas RSS o Conversation History.

A esto se suma el lado humano y de proceso: ningún cambio de cuenta bancaria o pago de nómina se aprueba solo por correo. Se verifica por un segundo canal, con un número conocido de antemano.

Si sospechas que ya te pasó: contención paso a paso

El error más común es cambiar la contraseña y dar el caso por cerrado. Un cambio de contraseña invalida el refresh token y la cookie de sesión, pero no el access token ya emitido, que sigue vivo hasta que caduca (alrededor de 90 minutos). Y no toca ni los equipos ni los métodos MFA que registró el atacante.

1. Revocar sesiones y restablecer la contraseña, en ese orden y de inmediato. En Entra ID, Revoke sessions sobre el usuario (o Revoke-MgUserSignInSession en Microsoft Graph PowerShell).
2. Auditar los métodos de autenticación. Buscar métodos borrados y vueltos a registrar en minutos, y eliminar cualquier Authenticator que el usuario no reconozca.
3. Auditar los dispositivos de Entra ID. Revisar equipos con nombre DESKTOP-, Device- o Work Pc seguido de ocho caracteres hexadecimales, sobre todo si se registraron desde IP de hosting. El patrón no es exclusivo de esta campaña: confirmar antes de borrar.
4. Revisar reglas de bandeja y reenvíos. Nombres de uno a tres caracteres o solo signos de puntuación, destinos RSS Feeds, RSS Subscriptions o Conversation History, y condiciones con palabras de nómina o banca.
5. Revisar aplicaciones empresariales y consentimientos otorgados durante la ventana del incidente.
6. Revisar el correo enviado y avisar a los contactos externos que pudieron recibir instrucciones de pago fraudulentas.

En resumen

El MFA tradicional sigue siendo obligatorio, pero ya no es la línea de meta. Los atacantes dejaron de pelear contra el segundo factor y pasaron a robar lo que el segundo factor produce: la sesión. La defensa, por lo tanto, tiene que proteger también la sesión: dónde se usa, desde qué equipo y con qué factor se creó.

Si tienes una hora esta semana, revisa esto en tu tenant:

• Hay una política de Conditional Access que exige MFA a todos los usuarios, aplicaciones y tipos de cliente.
• Finanzas, gerencia y administradores usan MFA resistente al phishing (FIDO2, passkeys o Windows Hello).
• El flujo de device code está bloqueado salvo excepciones documentadas.
• Registrar equipos y métodos MFA exige condiciones adicionales.
• Los usuarios no pueden dar consentimiento a aplicaciones nuevas.
• Hay alertas para reglas de bandeja nuevas y para reenvío externo.
• El procedimiento de incidentes revoca sesiones y audita dispositivos y métodos MFA, no solo cambia la contraseña.
• Ningún pago o cambio bancario se aprueba solo por correo.

En GESITEC TECHNOLOGY revisamos configuraciones de Entra ID y Microsoft 365 con este mismo enfoque. Si quieres saber cuántas de estas casillas marca tu organización, conversemos.

• GESITEC Technology: revisión de la configuración de Microsoft 365 y Entra ID (Conditional Access, registro de dispositivos, flujos de autenticación).
• GST Escudo: simulaciones de phishing, pentesting de accesos y apoyo en la respuesta si ya hay una sesión comprometida.
• GST Guía: políticas de acceso, gobierno de identidades y el procedimiento para aprobar pagos y cambios bancarios por un segundo canal.

Fuentes

• Help Net Security — Microsoft 365 accounts compromised at 79 organizations, no passwords needed (23/10/2026)

Imagen de portada: RDNE Stock project en Pexels.