Phishing en Microsoft 365 pese a la MFA: robo de sesiones

El phishing en Microsoft 365 va mucho más allá de los correos mal redactados y las páginas de inicio de sesión falsas. Los ataques comienzan en una cuenta empresarial comprometida, conducen a páginas de Microsoft perfectamente imitadas o legítimas y, pese a la MFA, terminan en el buzón, SharePoint o Teams.

El informe semestral 2026/1 de la Oficina Federal de Ciberseguridad aborda un problema que también afecta a las empresas suizas. Durante el primer semestre de 2026 aumentaron las notificaciones de cuentas de Microsoft 365 comprometidas. Se utilizaron para phishing y fraude. Los atacantes se hicieron pasar por el servicio de asistencia informática o por directivos y sortearon los controles mediante tokens de sesión, Device Code Phishing o reverse proxies.

La MFA sigue siendo imprescindible. No todos los métodos son resistentes al phishing. Una sesión ya confirmada puede convertirse en el objetivo del ataque. Microsoft 365 debe protegerse como plataforma de identidad y no solo como servicio de correo electrónico.

Cómo funciona el phishing en Microsoft 365 pese a la MFA

Después de verificar la contraseña, el segundo factor, el estado del dispositivo y otras condiciones, Entra ID emite tokens o cookies de sesión. Como ocurre con una acreditación de visitante, a partir de ese momento lo que cuenta sobre todo es su validez. Si llegan a otra persona, es posible que esta no tenga que repetir la verificación.

Los tipos de tokens de Microsoft Entra ID varían en función y duración. Lo importante es que un token robado o autorizado para el atacante puede representar una sesión autenticada.

Phishing Adversary-in-the-Middle con reverse proxy

En un ataque Adversary-in-the-Middle (AiTM), la infraestructura de phishing se sitúa entre el navegador y Microsoft y retransmite el inicio de sesión real en tiempo real:

1. Un correo enlaza, por ejemplo, a un documento de SharePoint, un mensaje de voz, una factura o una solicitud de firma.
2. El enlace dirige al usuario a través del reverse proxy del atacante hasta el inicio de sesión de Microsoft.
3. El nombre de usuario, la contraseña y la respuesta de MFA se reenvían a Microsoft.
4. Microsoft acepta el inicio de sesión confirmado y crea la sesión.
5. El proxy intercepta la cookie de sesión o los tokens. El acceso solo termina al caducar, revocarse o bloquearse.

La MFA no ha sido vulnerada. El usuario ha confirmado una sesión interceptada. Los códigos TOTP y las confirmaciones push no impiden por principio este relay. En cambio, las llaves FIDO2, Windows Hello for Business y los passkeys correctamente implementados vinculan criptográficamente el inicio de sesión al servicio legítimo. Aun así, tampoco protegen contra malware en un dispositivo que ya ha iniciado sesión ni contra cualquier forma de robo de sesión.

Device Code Phishing mediante una página legítima de Microsoft

El Device Code Flow está pensado para dispositivos sin un método de entrada cómodo. Un equipo de sala de reuniones o una herramienta de línea de comandos muestra un código que se confirma en Microsoft desde un segundo dispositivo.

Los atacantes inician el proceso y envían el código con un pretexto. Después de introducirlo en la página legítima de Microsoft, los tokens llegan a su sesión. El dominio y el certificado son correctos, pero se está autorizando un inicio de sesión ajeno. Microsoft considera este flujo de alto riesgo y recomienda bloquearlo si no existe una necesidad documentada.

Avalancha de correos, falso soporte técnico y phishing en cadena

Una cadena de ataque puede comenzar con cientos de correos de newsletters, registros y notificaciones. Generan estrés y ocultan las alertas reales. Después, un supuesto técnico de soporte solicita mediante Teams o por teléfono el uso de Quick Assist o de una herramienta de acceso remoto. Esto permite ejecutar comandos, instalar malware, leer datos del navegador y robar credenciales. Se compromete el puesto de trabajo, no el inicio de sesión.

Tras la toma de control, el atacante utiliza conversaciones reales, proveedores conocidos e hilos de correo existentes para manipular facturas, lanzar más campañas de phishing y comprometer nuevas cuentas. SPF, DKIM y DMARC no bastan si el mensaje procede del tenant legítimo de Microsoft 365.

Qué aporta la MFA y dónde están sus límites

La MFA evita muchas tomas de control porque una contraseña ya no es suficiente. Sin embargo, los métodos ofrecen niveles de protección diferentes:

• Contraseña más SMS, llamada o confirmación push sencilla: mejor que una contraseña sola, pero vulnerable a la ingeniería social, SIM swapping, MFA fatigue y phishing en tiempo real.
• TOTP o Authenticator con Number Matching: más resistente frente a confirmaciones accidentales, aunque un código puede retransmitirse directamente desde una página AiTM.
• Autenticación resistente al phishing: FIDO2, Windows Hello for Business, autenticación basada en certificados y passkeys verifican criptográficamente el servicio legítimo y reducen considerablemente los inicios de sesión AiTM.

Persisten otros riesgos: un endpoint infectado puede leer sesiones, una aplicación OAuth puede obtener permisos duraderos y un usuario puede confirmar Device Codes ajenos o accesos remotos. La MFA resistente al phishing es fundamental, pero no constituye por sí sola un concepto de seguridad completo.

Cómo reforzar Microsoft Entra ID de forma eficaz

Conditional Access y Token Protection requieren licencias de Entra adecuadas, mientras que las condiciones de dispositivo exigen una base de dispositivos administrados. Las políticas deben probarse primero en modo Report-only con un grupo piloto.

Priorizar la autenticación resistente al phishing

El primer despliegue debe incluir a administradores, responsables financieros, dirección y helpdesk. Conditional Access Authentication Strengths permite exigir Windows Hello for Business, llaves FIDO2, passkeys o autenticación basada en certificados para estos grupos.

También es necesario un proceso de recuperación con al menos dos métodos registrados, dispositivos de sustitución verificados y cuentas de emergencia supervisadas por separado. La pérdida de una llave no debe provocar una interrupción prolongada ni excepciones del helpdesk fáciles de manipular. Los passkeys también son apropiados para el inicio de sesión en Sophos Central, aunque la recuperación y el cambio de dispositivo también deben planificarse.

Revisar y, si es posible, bloquear el Device Code Flow

Su uso puede inventariarse en los Entra Sign-in Logs mediante Authentication protocol > Device code. Los equipos de salas de reuniones, las herramientas antiguas o las aplicaciones de línea de comandos pueden depender de este flujo. Si no existe una necesidad justificada, se crea una política en Entra ID > Conditional Access > Policies:

1. Seleccionar los usuarios o grupos habituales.
2. Excluir las cuentas de emergencia y las excepciones técnicas justificadas.
3. En Target resources, seleccionar preferiblemente All resources; limitar el ámbito solo si está justificado.
4. En Conditions > Authentication flows, activar Device code flow.
5. En Grant, bloquear el acceso.
6. Utilizar primero Report-only, revisar los registros y activar la política después.

Las excepciones deben ser limitadas, estar documentadas y asignarse a cuentas o recursos concretos.

Vincular el acceso a dispositivos administrados

Conditional Access permite exigir para aplicaciones sensibles un dispositivo conforme o unido a Microsoft Entra. Esto dificulta el uso indebido de tokens en dispositivos desconocidos, pero afecta a BYOD, invitados, dispositivos móviles y clientes especiales. Por eso deben conocerse el inventario de dispositivos, los sistemas operativos y las aplicaciones. Los registros obsoletos, un enrollment débil o las excepciones generosas socavan el control.

Probar Token Protection de forma selectiva

Token Protection vincula criptográficamente los Sign-in Session Tokens compatibles al dispositivo emisor y dificulta su replay en otros sistemas. La función requiere Entra ID P1 y solo cubre determinadas plataformas, aplicaciones y recursos. En Windows protege principalmente las aplicaciones nativas de Microsoft 365 compatibles. Los dispositivos Apple requieren administración y Microsoft Enterprise SSO Plug-in. Las aplicaciones Mail y Calendar de Apple no son compatibles actualmente con Token Protection.

El despliegue comienza con un ámbito reducido en Report-only. Después se revisan en los Sign-in Logs los Token Protection Status Details, los clientes y los recursos. La aplicación obligatoria solo se activa cuando se ha confirmado la compatibilidad. Los navegadores, el software antiguo y los dispositivos especiales se evalúan por separado.

Controlar Teams y el acceso remoto

Debe definirse qué dominios externos o tenants pueden contactar con los usuarios a través de Teams y cómo se identifican los participantes externos. Para el soporte se aplican estas reglas:

• El acceso remoto solo comienza con un ticket o una devolución de llamada verificada a un número conocido.
• No se aceptan sesiones inesperadas de Quick Assist iniciadas desde chats o llamadas.
• Las herramientas de acceso remoto permitidas están documentadas y supervisadas.
• Las herramientas RMM desconocidas se bloquean o generan alertas mediante Application Control, AppLocker, Windows Defender Application Control o controles equivalentes.
• Una avalancha de correos inusual se comunica a TI o al equipo de seguridad y no se trata únicamente como spam.

La concienciación debe reflejar estos procesos. Sophos Phish Threat resulta más eficaz con canales de notificación claros, escenarios de Teams y un runbook realista para el helpdesk.

Qué indicios deben revisar los administradores

Un evento MFA correcto no demuestra que el inicio de sesión sea legítimo. En un ataque AiTM o con Device Code, es posible que el propio usuario haya confirmado el factor. La identidad, el buzón, el endpoint y las comunicaciones deben investigarse conjuntamente.

Microsoft Entra Sign-in Logs

Los registros se encuentran en Entra ID > Monitoring & health > Sign-in logs y pueden consultarse a partir del rol Reports Reader. Según la sospecha, el análisis debe incluir inicios de sesión interactivos y no interactivos, Service Principals y Managed Identities. Los indicios relevantes son:

• dispositivos desconocidos o no conformes, así como IP, regiones, aplicaciones y clientes inusuales,
• Device code como Authentication Protocol,
• nuevas combinaciones de navegador y dispositivo después de un inicio de sesión normal,
• accesos inusuales a Exchange Online, SharePoint o Microsoft Graph,
• el resultado de Conditional Access y los requisitos de autenticación cumplidos, y
• accesos correctos sin la interacción esperada del usuario mediante tokens existentes.

Un único indicio no es suficiente. Una IP suiza puede pertenecer a una red móvil o una VPN, y un inicio de sesión desde el extranjero puede ser legítimo. Lo decisivo es la combinación de usuario, dispositivo, hora, aplicación y actividad posterior.

Exchange Online, auditoría y endpoint

Tras comprometer una cuenta, los atacantes suelen buscar facturas e hilos de correo. Deben revisarse los reenvíos internos y externos, las Inbox Rules visibles y ocultas, las delegaciones y los permisos Send-as, la actividad inusual de búsqueda, lectura, descarga y envío, los nuevos consentimientos OAuth y Enterprise Applications, los métodos de autenticación modificados y todos los mensajes enviados durante el periodo afectado.

En casos de falso soporte técnico, los indicios se encuentran en el endpoint: herramientas de acceso remoto, descargas, PowerShell, MSHTA, tareas programadas, accesos al navegador y procesos sospechosos. La seguridad del correo, Endpoint Protection y XDR o MDR pueden bloquearlos y correlacionarlos si las fuentes de datos están licenciadas, integradas y supervisadas. La estrategia Sophos Fusion facilita esta tarea, pero no sustituye a Conditional Access ni al proceso de respuesta a incidentes.

La retención y el nivel de detalle de los datos de auditoría dependen de la licencia y la configuración. Ambos deben definirse con antelación, ya que los registros activados posteriormente no generan un historial retroactivo.

Plan de emergencia para una cuenta de Microsoft 365 comprometida

Cambiar la contraseña no es suficiente. Las sesiones, los métodos MFA ajenos, los consentimientos OAuth y las reglas del buzón pueden permanecer activos.

1. Utilizar un dispositivo de administración limpio

Si existe la posibilidad de que el endpoint esté comprometido, el cambio de contraseña y la administración se realizan desde otro dispositivo. El sistema afectado se aísla sin eliminar pruebas precipitadamente. Si el ataque sigue activo o la cuenta tiene privilegios, puede ser conveniente deshabilitarla temporalmente.

2. Revocar las sesiones activas

Las sesiones pueden revocarse en Entra Admin Center o mediante Microsoft Graph PowerShell:

Connect-MgGraph -Scopes User.RevokeSessions.All
Revoke-MgUserSignInSession -UserId user@example.com

Debe adaptarse el User Principal Name. Dependiendo de la aplicación, el tipo de token y Continuous Access Evaluation, el acceso puede continuar durante un breve periodo. Por eso es necesario verificar el resultado en los registros y las aplicaciones.

3. Restablecer la contraseña y los métodos de autenticación

La contraseña se cambia en la fuente de identidad principal; en el caso de cuentas sincronizadas o federadas, en el Active Directory local o el Identity Provider. Después se revisan los métodos MFA, passkeys, números de teléfono, dispositivos y Temporary Access Passes, y se eliminan las entradas ajenas. Si se detecta malware o acceso remoto, el endpoint se investiga en paralelo y, si es necesario, se reinstala.

4. Revisar consentimientos OAuth y roles

Los consentimientos de usuario, Enterprise Applications y Service Principals sospechosos pueden permitir un acceso persistente. En cuentas privilegiadas también deben revisarse los roles de Entra, Azure y Microsoft 365.

5. Revisar reenvíos e Inbox Rules

Exchange Online PowerShell muestra la configuración principal del buzón:

Get-Mailbox -Identity user@example.com |
  Format-List Forwarding*Address,DeliverTo*

Get-InboxRule -Mailbox user@example.com -IncludeHidden |
  Format-List Name,Enabled,RedirectTo,Forward*,Identity

Las reglas sospechosas se documentan y eliminan. Las delegaciones, los permisos Send-as y las reglas de transporte administrativas se revisan por separado.

6. Identificar e informar a otras víctimas

Message Trace y los datos de auditoría muestran los mensajes enviados. Se informa a los destinatarios internos y externos antes de que se utilicen enlaces, se realicen pagos o se comprometan más cuentas. Si se han modificado instrucciones de pago, se contacta con el banco, contabilidad y los socios comerciales a través de canales conocidos. El artículo sobre medidas inmediatas ante phishing y hacking incluye más pasos.

7. Determinar la causa y el alcance

Por último, debe aclararse si se utilizaron AiTM, Device Code, una MFA confirmada o acceso remoto; qué archivos de SharePoint u OneDrive se extrajeron; si se registraron otras cuentas, aplicaciones o dispositivos; y si se vieron afectados datos personales o secretos empresariales. Sin un análisis de la causa, la brecha permanece abierta.

Lista práctica para administradores de Microsoft 365

• Priorizar la autenticación resistente al phishing para administradores, finanzas, dirección y helpdesk.
• Mantener las cuentas de emergencia separadas, supervisarlas y probarlas periódicamente.
• Inventariar el uso de Device Code, bloquearlo o documentar las excepciones justificadas.
• Probar Conditional Access en Report-only con un grupo piloto.
• Exigir dispositivos administrados para los recursos sensibles y desplegar Token Protection solo con clientes compatibles.
• Regular de forma vinculante la comunicación externa en Teams, las herramientas de acceso remoto, la devolución de llamadas del helpdesk y la verificación de identidad.
• Generar alertas ante avalanchas de correos, inicios de sesión inusuales, consentimientos OAuth y reenvíos.
• Probar la revocación de sesiones, la limpieza de MFA, las Inbox Rules, el seguimiento de mensajes enviados y el aislamiento de endpoints.
• Definir la retención de auditoría y las responsabilidades antes de un incidente.

Mi recomendación

La MFA sigue siendo obligatoria, pero una contraseña combinada con una aplicación push no tiene suficientemente en cuenta los ataques modernos. Primero deben protegerse con métodos resistentes al phishing las cuentas privilegiadas y financieras. Después deben abordarse el control de Device Code, los dispositivos administrados y Conditional Access. Token Protection necesita un despliegue controlado debido a sus limitaciones. Al mismo tiempo, el helpdesk requiere procesos seguros para contactos inesperados a través de Teams.

La clave está en combinar una identidad sólida, un dispositivo de confianza, una sesión controlada, comunicaciones supervisadas y un plan de emergencia que contemple tokens activos y mecanismos de persistencia ocultos.

FAQ