Cómo investigar un compromiso de Microsoft Entra ID paso a paso

Durante los últimos años, la identidad se ha convertido en el punto de partida de la mayoría de los incidentes de seguridad en Microsoft 365. Antes de que un atacante llegue al correo, a los archivos o a las aplicaciones internas, casi siempre debe pasar primero por Microsoft Entra ID.

Las técnicas más comunes utilizadas contra la identidad incluyen el robo de credenciales, la fatiga de MFA, el robo de tokens de sesión, el abuso de aplicaciones OAuth y los inicios de sesión sospechosos desde ubicaciones, dispositivos o aplicaciones inusuales. En muchos casos, el atacante no necesita malware: le basta con una identidad válida.

Por ese motivo, saber investigar un compromiso de Microsoft Entra ID es una habilidad central para analistas, consultores, MSPs, MSSPs y equipos de seguridad internos. Este artículo describe cómo estructurar ese trabajo de forma metódica.

¿Por dónde empezar?

Cuando llega una alerta o una sospecha sobre una cuenta de Microsoft Entra ID, es fácil caer en la tentación de abrir un único registro y sacar conclusiones. Una investigación sólida empieza definiendo el alcance antes de mirar la evidencia.

El analista debería poder responder, al menos de forma preliminar, a las siguientes preguntas:

• ¿Qué ocurrió exactamente?
• ¿Cuándo ocurrió y durante cuánto tiempo?
• ¿Qué identidad o identidades se vieron afectadas?
• ¿Qué aplicaciones y recursos se accedieron durante ese periodo?
• ¿Existen indicios de que el atacante haya mantenido persistencia?

Estas preguntas no siempre tienen respuesta inmediata. El objetivo en esta primera fase es delimitar el incidente y evitar analizar registros sin contexto.

Evidencias principales en Microsoft Entra ID

Microsoft Entra ID expone un conjunto amplio de evidencias que, correctamente correlacionadas, permiten reconstruir lo ocurrido. Las más relevantes para una investigación de identidad son las siguientes.

Registros de inicio de sesión

• Interactive sign-ins: inicios de sesión iniciados directamente por el usuario, típicamente con contraseña, MFA o passkey.
• Non-interactive sign-ins: inicios de sesión automáticos realizados por clientes, servicios o tokens ya emitidos. Esta categoría se ignora con frecuencia y suele contener actividad crítica tras un compromiso.

Detalles de autenticación

Cada inicio de sesión incluye información detallada sobre el método de autenticación utilizado, si se aplicó MFA, qué factor se usó, si hubo fallos previos y si el usuario recibió y aceptó una solicitud de MFA. Este detalle es esencial para identificar escenarios de fatiga de MFA o de tokens ya emitidos.

Conditional Access

El resultado de Conditional Access indica qué políticas aplicaron, cuáles se cumplieron y cuáles se omitieron. En una investigación es importante revisar no solo lo que se bloqueó, sino también lo que se permitió y por qué. Después del incidente, conviene contrastar los hallazgos con las políticas de Acceso Condicional que deberían estar activas en el tenant.

Identity Protection

• Risky sign-ins: inicios de sesión con señales de riesgo detectadas.
• Risky users: usuarios con un nivel de riesgo elevado en función de eventos acumulados.

Contexto adicional

• Dispositivos utilizados y su estado (registrado, conforme, desconocido).
• Direcciones IP y ubicaciones geográficas.
• Aplicaciones cliente y recursos accedidos.
• User agent del cliente utilizado.
• Correlation IDs y Request IDs para correlacionar eventos entre sistemas.

Ninguna de estas evidencias es concluyente por sí sola. El valor aparece al correlacionarlas.

Cómo construir una línea de tiempo

Una investigación de identidad útil no es un listado de registros: es una narrativa ordenada. La línea de tiempo permite explicar qué ocurrió, en qué orden y con qué consecuencias.

Para construirla, el analista suele correlacionar los siguientes elementos:

• Intentos fallidos de inicio de sesión previos al compromiso.
• Primer inicio de sesión exitoso considerado sospechoso.
• Cambios de ubicación, dispositivo o aplicación cliente.
• Métodos de autenticación utilizados y respuestas de MFA.
• Aplicaciones y recursos accedidos tras el inicio de sesión.
• Actividad en el buzón (Exchange Online) durante el periodo comprometido.
• Decisiones de Conditional Access aplicadas o no aplicadas.
• Detecciones de riesgo generadas por Identity Protection.
• Acciones de contención: revocación de sesiones, restablecimiento de contraseña, bloqueo de la cuenta.

Este mismo enfoque de línea de tiempo se aplica también en investigaciones de correo, como se describe en el artículo sobre investigaciones BEC en Microsoft 365. La identidad es habitualmente el primer eslabón; el buzón, el siguiente.

Preguntas que todo analista debería responder

Antes de cerrar una investigación de Microsoft Entra ID, es recomendable revisar un conjunto mínimo de preguntas. Estas ayudan a evitar conclusiones prematuras:

• ¿Hubo acceso no autorizado a la cuenta?
• ¿Se aplicó MFA y de qué tipo? ¿Se aceptó una solicitud sospechosa?
• ¿Se registró un nuevo dispositivo o método de autenticación durante el periodo del incidente?
• ¿Se creó algún tipo de persistencia: nuevos métodos MFA, nuevas passkeys, delegaciones, reglas en el buzón?
• ¿Se modificaron reglas o permisos del buzón?
• ¿Se utilizaron o consintieron aplicaciones OAuth durante el compromiso?
• ¿Existen indicios de exfiltración: descargas masivas, reenvíos externos, acceso a SharePoint u OneDrive?
• ¿Se revocaron todas las sesiones activas y tokens emitidos tras el evento?

El objetivo no es marcar casillas, sino documentar las respuestas con evidencia. Una investigación bien cerrada es aquella en la que otro analista puede leer las notas y llegar a las mismas conclusiones.

Errores comunes

En investigaciones de identidad se repiten con frecuencia algunos errores que conviene evitar:

• Analizar únicamente un registro o un único inicio de sesión sospechoso, sin ver el contexto anterior y posterior.
• Ignorar la actividad no interactiva, que suele contener el uso de tokens ya emitidos.
• No revisar qué aplicaciones se utilizaron ni qué aplicaciones OAuth fueron consentidas.
• No correlacionar la actividad con Exchange Online, especialmente reglas de bandeja de entrada y reenvíos.
• Olvidar revisar las decisiones de Conditional Access: qué se aplicó, qué se omitió y por qué.
• No documentar las decisiones del analista, lo que dificulta auditar el caso o retomarlo más tarde.

Muchos de estos errores no se deben a falta de conocimiento, sino a la presión de cerrar el incidente rápidamente. Una investigación estructurada reduce este riesgo.

Cómo ayuda CLEVERINA Incident Assistant

CLEVERINA Incident Assistant apoya al analista durante el triage de investigaciones de identidad y de compromiso de cuentas en Microsoft 365. Ayuda a organizar la evidencia exportada de Microsoft 365 en un espacio de investigación estructurado con:

• Hallazgos
• IOCs
• Línea de tiempo
• Notas del analista
• Borradores de informes

La herramienta no sustituye al analista. Las conclusiones finales, la clasificación de la actividad y las recomendaciones permanecen bajo el control del profesional que revisa el caso.

Conclusión

Las investigaciones de Microsoft Entra ID requieren estructura, contexto y documentación. Los registros aislados rara vez cuentan la historia completa: es la correlación entre inicios de sesión, autenticación, Conditional Access, aplicaciones y actividad en el buzón la que permite entender qué ocurrió.

Una línea de tiempo clara, con decisiones documentadas, es más valiosa que cualquier volumen de registros sin contexto. Si necesita un punto de partida operativo, revise este checklist de evidencias para investigar una cuenta comprometida en Microsoft 365. Ese es el estándar que un equipo de seguridad debería aspirar a mantener en cada investigación de identidad.