Cómo atacan los hackers Microsoft 365

Por Kike Gandia · Co-Fundador y CEO, OSCP

Entender cómo se ataca un Microsoft 365 es el primer paso para defenderlo. La mayoría de los compromisos no explotan un fallo de Microsoft, sino la configuración y el comportamiento de la organización. Estos son los vectores que vemos una y otra vez en auditorías y respuestas a incidentes.

Phishing AiTM y robo de tokens

Las campañas modernas de phishing "adversary-in-the-middle" (AiTM) no solo roban la contraseña: capturan la cookie de sesión y el token, lo que les permite saltarse el MFA. Con el token robado, el atacante accede al correo y a los archivos como si fuera el usuario legítimo, sin volver a autenticarse.

Consentimiento ilícito de apps OAuth

En lugar de robar credenciales, el atacante engaña al usuario para que conceda consentimiento a una app OAuth maliciosa con permisos sobre el correo y los archivos. El acceso persiste mediante un token aunque se cambie la contraseña, y esquiva el MFA. Es uno de los vectores más efectivos y peor controlados.

Persistencia en Exchange y abuso de Entra ID

Tras el acceso, el atacante crea reglas de reenvío en Exchange Online para vigilar el correo, y abusa de Entra ID: registra nuevas app registrations con credenciales propias, añade permisos o manipula la federación para mantener el acceso a largo plazo, incluso si se restablece la cuenta original.

Cómo se detiene esto

La defensa combina MFA resistente al phishing (FIDO2/passkeys), acceso condicional que bloquee la autenticación heredada, control estricto del consentimiento de apps, monitorización de reglas de Exchange y de nuevas app registrations, y registros con alertas. Una auditoría periódica verifica que estas defensas funcionan de verdad.

Cómo encaja todo: la secuencia de un compromiso real

Los vectores anteriores rara vez aparecen sueltos. Encadenados, la secuencia típica de un fraude por correo en Microsoft 365 es esta.

Un correo lleva al usuario a una página que hace de intermediaria con el inicio de sesión legítimo de Microsoft. El usuario introduce sus credenciales y supera el MFA sin notar nada raro, porque el formulario que ve es el real, proxificado. El intermediario se queda con la cookie de sesión. El atacante la importa en su propio navegador y entra sin credenciales y sin MFA.

Dentro, crea una regla de bandeja que mueve a una carpeta poco visible los mensajes con palabras como "factura", "IBAN" o "transferencia", y se dedica a leer. Cuando encuentra un hilo de pagos abierto con un proveedor, prepara el fraude. Antes de actuar, registra una aplicación o añade un secreto propio a una existente, para conservar el acceso aunque se cierre la sesión o se restablezca la contraseña. Y entonces responde dentro del hilo legítimo con datos bancarios cambiados.

El detalle que conviene retener: entre el robo de la cookie y el envío del fraude no hay ni una sola autenticación que el MFA pueda bloquear.

Vector, señal y contramedida

Cada paso de esa cadena deja una huella concreta y se corta con un control concreto.

Vector	Señal en los registros	Contramedida
Phishing AiTM	Inicio correcto con MFA desde un proveedor de red no habitual y con un agente de usuario anómalo	MFA resistente al phishing y acceso condicional que exija dispositivo conforme
Robo de cookie de sesión	La misma sesión utilizada desde ubicaciones incompatibles entre sí	Vinculación del token al dispositivo y revocación de sesiones ante la sospecha
Consentimiento ilícito de apps	Evento de concesión de consentimiento a una aplicación no verificada	Consentimiento de usuario restringido y flujo de aprobación del administrador
Reglas de bandeja maliciosas	Creación de reglas de bandeja en el registro unificado	Alerta sobre creación de reglas y revisión obligatoria tras cualquier incidente
Persistencia en Entra ID	Credencial añadida a una aplicación registrada o a una entidad de servicio	Alerta sobre cambios en aplicaciones y revisión periódica de secretos y certificados
Fraude en el hilo de correo	Correo saliente desde el buzón fuera del horario habitual	Verificación de cambios de cuenta bancaria por un canal distinto del correo

FAQ

Si cambio la contraseña, ¿echo al atacante?

No necesariamente. Los tokens de sesión robados, los consentimientos de apps OAuth, las reglas de reenvío y las credenciales añadidas a app registrations pueden mantener el acceso. Tras un incidente hay que revocar tokens y sesiones, revisar consentimientos y reglas, y auditar Entra ID.

¿El MFA me protege de todo?

El MFA resistente al phishing es esencial, pero el phishing AiTM puede robar la sesión y el consentimiento ilícito no requiere la contraseña. Por eso hace falta endurecer el acceso condicional, controlar las apps y auditar el entorno.

¿Cómo sé si esto ya me ha pasado?

Buscando en el registro unificado de auditoría los eventos que deja la cadena: creación de reglas de bandeja, cambios de reenvío en buzones, concesiones de consentimiento a aplicaciones, credenciales añadidas a entidades de servicio y aplicaciones registradas, e inicios de sesión correctos desde ubicaciones no habituales. La mala noticia es que, si el registro no estaba activado, no hay forma de mirar hacia atrás.

¿Qué hago en las primeras horas si sospecho un compromiso?

Revocar las sesiones y los tokens de refresco del usuario, restablecer la credencial, eliminar reglas de bandeja y reenvíos, revisar los consentimientos concedidos y las credenciales añadidas a aplicaciones, y —esto es lo que más dinero salva— avisar a las contrapartes de los hilos de correo afectados antes de que alguien pague a una cuenta cambiada.

¿Sirve de algo el MFA por SMS o por aplicación frente a esto?

Reduce el robo de credenciales simple, pero no detiene un ataque AiTM: el intermediario captura también el código y la cookie resultante. Lo que sí lo detiene es el MFA resistente al phishing (FIDO2 o passkeys), porque la credencial está ligada al dominio legítimo y no se puede reproducir desde una página intermedia.

¿Esto solo le pasa a las empresas grandes?

No. El fraude por correo corporativo es rentable a cualquier tamaño y buena parte de la cadena está automatizada, así que el coste de atacar a una empresa pequeña es prácticamente el mismo. En la práctica, las pymes suelen ser objetivos más cómodos porque el registro de auditoría existe pero nadie lo mira.