Forense en Microsoft 365:

Unified Audit Log, MailItemsAccessed y sign-ins

Blue Team y Forense Digital  |  unfantasmaenelsistema.com

Cuando un phishing acaba en una cuenta de Microsoft 365 comprometida, la investigación no está en un disco: está en los registros de la nube. Y esos registros tienen sus propias reglas: distintas retenciones según la licencia, varios logs que cuentan partes distintas de la misma historia, y un reloj que corre -pasadas unas semanas, lo que no se haya exportado desaparece.

Este artículo explica qué registra Microsoft 365, cómo se extrae, y qué señales delatan una cuenta comprometida: reglas de bandeja de entrada, reenvío automático, consentimientos OAuth abusivos, accesos a correo (MailItemsAccessed) e inicios de sesión imposibles. Cierra el círculo de los artículos de phishing, ataques de intermediario (AiTM) y Entra ID con la parte de investigación posterior al compromiso.

1. Qué registra Microsoft 365

Hay varias fuentes de registro y conviene no confundirlas:

La consecuencia práctica: exportar cuanto antes. Ante un incidente, lo primero es sacar el UAL y los sign-in logs del periodo relevante a ficheros propios, porque el reloj de retención no se detiene. Y verificar que la auditoría estaba activada: en tenants nuevos viene por defecto, pero conviene comprobar Get-AdminAuditLogConfig y UnifiedAuditLogIngestionEnabled.

2. Cómo se extrae

Tres vías, de menos a más potente:

• Portal de Microsoft Purview > Audit: búsqueda interactiva por fechas, usuarios y actividades. Bien para una consulta rápida; limitado para volúmenes grandes
• Exchange Online PowerShell (Search-UnifiedAuditLog): la vía habitual. Devuelve como máximo 50.000 registros por consulta, así que hay que trocear por franjas horarias y paginar con SessionId
• Microsoft Graph API: para sign-in y audit logs de Entra a escala, y con auditLogQuery para el UAL en tenants con la licencia adecuada

# --- Exchange Online: exportar el UAL de una cuenta (solo LECTURA) ---
Connect-ExchangeOnline
 
$start = (Get-Date).AddDays(-30)
$end   = (Get-Date)
$user  = 'victima@contoso.com'
 
$all = @()
do {
  $batch = Search-UnifiedAuditLog -StartDate $start -EndDate $end \
           -UserIds $user -ResultSize 5000 -SessionId 'ir1' -SessionCommand ReturnLargeSet
  $all += $batch
} while ($batch.Count -ne 0)
$all | Export-Csv .\ual_$user.csv -NoTypeInformation
 
# reglas de bandeja de entrada actuales de la cuenta
Get-InboxRule -Mailbox $user | Format-List Name,Enabled,ForwardTo,RedirectTo,DeleteMessage,MoveToFolder
 
# reenvio a nivel de buzon
Get-Mailbox $user | Format-List ForwardingAddress,ForwardingSmtpAddress,DeliverToMailboxAndForward

# --- Microsoft Graph: sign-ins y consentimientos (solo LECTURA) ---
Connect-MgGraph -Scopes 'AuditLog.Read.All','Directory.Read.All'
 
# inicios de sesion de la cuenta en los ultimos 14 dias
Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'victima@contoso.com'" -Top 500 |
  Select-Object createdDateTime,appDisplayName,ipAddress,
    @{n='city';e={$_.location.city}}, @{n='mfa';e={$_.authenticationRequirement}},
    @{n='status';e={$_.status.errorCode}}
 
# concesiones de permisos OAuth (consent grants) recientes
Get-MgOauth2PermissionGrant -All | Select-Object ClientId,ConsentType,Scope,PrincipalId

3. Señales de cuenta comprometida en el correo

El patrón clásico tras robar una sesión: el atacante quiere leer el correo sin ser visto y mantener el acceso. Las operaciones del UAL a buscar:

MailItemsAccessed merece una explicación. Es la operación que permite responder a la pregunta del RGPD: ¿accedieron a datos personales y a cuáles? Registra los accesos (sincronización o binario) con los identificadores de los mensajes. Solo está disponible con licencias E5 o el complemento de auditoría avanzada; si el tenant no la tiene, hay que asumir el peor caso para el alcance. Cuando aparece un registro con IsThrottled = true, Microsoft dejó de registrar por volumen durante 24 h: se considera que todo el buzón pudo ser accedido en esa ventana.

4. Consentimientos OAuth: el acceso que sobrevive

Cambiar la contraseña y revocar sesiones no expulsa a un atacante que consiguió que la víctima (o un administrador) autorizara una aplicación. Ese token de aplicación sigue funcionando hasta que se retira el consentimiento. Es el mecanismo del «illicit consent grant».

• En el UAL: Consent to application, Add app role assignment grant to user, Add OAuth2PermissionGrant, Add service principal
• Señales de abuso: aplicación con nombre genérico o que imita a una conocida, editor no verificado, permisos amplios sobre el correo (Mail.Read, Mail.ReadWrite, MailboxSettings, offline_access), consentimientos masivos de varios usuarios en poco tiempo
• Revisar en Entra ID > Aplicaciones empresariales y con Get-MgOauth2PermissionGrant
• Contención: revocar el consentimiento (Remove-MgOauth2PermissionGrant / deshabilitar el service principal) además de rotar credenciales y revocar sesiones

5. Sign-in logs de Entra: leer un inicio de sesión

Los registros de inicio de sesión de Entra son la fuente para distinguir un acceso legítimo de uno del atacante. Qué mirar en cada evento:

• IP y ASN: una IP de un proveedor de hosting (Azure, AWS, OVH, DigitalOcean) o de un servicio VPN comercial para una cuenta que siempre entra desde la oficina o desde una IP residencial es una bandera roja
• Viaje imposible: dos inicios de sesión correctos desde ubicaciones geográficas incompatibles con el tiempo transcurrido. Entra ID Protection lo marca como riesgo, pero también se ve a ojo en el CSV
• Autenticación: en un ataque de intermediario (AiTM) el atacante roba la cookie de sesión, así que el sign-in aparece con MFA satisfecho pero sin interacción real del usuario; revisar el detalle de métodos y el campo de token/PRT
• Aplicación y user agent: clientes de correo raros, IMAP/POP o «Other clients» (autenticación heredada) cuando el usuario usa Outlook moderno
• Correlación: el sign-in sospechoso debe cuadrar en el tiempo con la creación de la regla de reenvío o el consentimiento OAuth en el UAL

6. Herramientas y contención

Para no hacerlo a mano hay proyectos que automatizan la recogida y el triaje:

Pasos de contención una vez confirmado el compromiso:

• Restablecer la contraseña y revocar todas las sesiones y tokens de actualización (Revoke-MgUserSignInSession); el cambio de contraseña por sí solo no cierra las sesiones activas
• Retirar los consentimientos OAuth abusivos y deshabilitar los service principals creados
• Eliminar reglas de bandeja de entrada, reenvíos y delegaciones no legítimas
• Revisar y revocar dispositivos y métodos MFA que el atacante haya registrado (un método MFA nuevo es persistencia)
• Forzar re-registro de MFA si hay duda; aplicar acceso condicional que bloquee autenticación heredada y ubicaciones/plataformas no confiables
• Determinar el alcance de datos (MailItemsAccessed, Content Search) para la evaluación de brecha

Conclusión

El forense de Microsoft 365 es una carrera contra la retención. La prioridad, en cuanto se sospecha un compromiso, es exportar el Unified Audit Log y los registros de inicio de sesión del periodo relevante a ficheros propios, antes de que el sistema los borre.

Con esos datos, el análisis se centra en tres frentes: el correo (reglas de bandeja de entrada, reenvíos, MailItemsAccessed, Send As), los consentimientos OAuth (el acceso que sobrevive al cambio de contraseña) y los inicios de sesión de Entra (IP de hosting, viaje imposible, MFA satisfecho sin interacción). La contención no termina en resetear la contraseña: hay que revocar sesiones y tokens, retirar consentimientos y métodos MFA, y limpiar reglas y delegaciones. Y todo correlacionado en UTC para que la línea de tiempo aguante.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)