Investigación de BEC en Microsoft 365: guía práctica
Cómo investigar un BEC en Microsoft 365: qué registros exportar, qué buscar en cada uno y cómo vincular cada acción con la sesión del atacante.
En resumen. Un compromiso del correo electrónico empresarial (BEC, business email compromise) en Microsoft 365 se investiga a partir de tres exportaciones: el registro de auditoría unificado de Purview (qué se hizo en el buzón y en los archivos), los registros de inicio de sesión de Entra ID, interactivos y no interactivos (quién inició sesión, desde dónde y con qué sesión), y los registros de auditoría de Entra ID (métodos MFA, consentimientos de aplicaciones, roles). El método es siempre el mismo: encontrar el inicio de sesión del atacante, pivotar sobre su IP, su Session ID y su token, listar todas las acciones que llevan esos identificadores y revisar cada mecanismo de persistencia que haya podido dejar. Restablecer la contraseña, por sí solo, no resuelve nada de eso.
El BEC no es un problema menor. El informe 2024 del IC3 del FBI contabiliza 21.442 denuncias por BEC y unos 2770 millones de dólares en pérdidas declaradas solo en ese año. En los tenants de Microsoft 365, el patrón que más veo no tiene nada de espectacular: un usuario escribe su contraseña en una página de inicio de sesión convincente, a los pocos minutos una regla de bandeja de entrada llamada «.» empieza a mover facturas a RSS Feeds, y una semana después los datos bancarios de un proveedor «cambian». Todo lo necesario para reconstruir esa cadena está en registros que el tenant ya tiene, siempre que se exporten antes de que caduque su retención.
Cómo se ve un BEC en los registros
| Fase | Qué hace el atacante | Dónde aparece | Campos / operaciones clave |
|---|---|---|---|
| Acceso inicial | Difusión de contraseñas, phishing adversary-in-the-middle, phishing con código de dispositivo | Registros de inicio de sesión de Entra | Dirección IP, ASN, Authentication Protocol, códigos de error 50126 / 50074 |
| Robo de sesión | Reutiliza la cookie o el token de actualización robado desde su propia red | Inicios de sesión no interactivos de Entra | Mismo Session ID, IP / país nuevos |
| Persistencia | Registra un método MFA, da consentimiento a una aplicación OAuth, añade secretos de aplicación | Auditoría de Entra (también en el UAL, carga de trabajo AzureActiveDirectory) | User registered security info, Consent to application, Add service principal credentials |
| Ocultación | Reglas que eliminan o mueven las respuestas, reenvío del buzón | Registro de auditoría unificado | New-InboxRule, Set-InboxRule, UpdateInboxRules, Set-Mailbox |
| Recopilación | Lee y sincroniza el correo, busca «factura», descarga archivos | Registro de auditoría unificado | MailItemsAccessed, SearchQueryInitiatedExchange, FileDownloaded |
| Fraude y limpieza | Envía el cambio de datos bancarios falso y lo borra | Registro de auditoría unificado | Send, SoftDelete, HardDelete, MoveToDeletedItems |
MITRE ATT&CK da nombre a la mayoría: Email Hiding Rules (T1564.008), Email Forwarding Rule (T1114.003), Web Session Cookie (T1550.004), Steal Application Access Token (T1528).
Paso 1: recopilar antes de que la retención borre las pruebas
La retención es la primera restricción, no la última. Entra ID conserva los registros de inicio de sesión y de auditoría 7 días en la edición gratuita y 30 días con P1/P2. El registro de auditoría unificado conserva 180 días por defecto con Audit (Standard). Si el incidente se notificó con tres semanas de retraso, en un tenant pequeño los inicios de sesión que lo explican pueden haber desaparecido ya.
Exporte, el primer día:
- El registro de auditoría unificado de todo el tenant (no solo de la víctima) desde al menos 30 días antes del primer correo sospechoso.
- Los inicios de sesión de usuario interactivos y no interactivos desde el centro de administración de Entra. La reutilización de tokens solo aparece en el archivo no interactivo.
- El registro de auditoría de Entra, en JSON si puede: el CSV conserva un número limitado de destinos y propiedades modificadas.
El paso a paso, con los límites de filas y la paginación en PowerShell, está en cómo exportar el registro de auditoría unificado y los inicios de sesión de Entra. No modifique los archivos originales y calcule su hash: le preguntarán qué analizó.
Paso 2: encontrar el inicio de sesión del atacante
Parta de lo que sabe (un correo denunciado, un pago fraudulento, un usuario que «no hizo eso») y retroceda hasta el inicio de sesión. En los registros de inicio de sesión, busque:
- Inicios de sesión correctos desde redes de hosting o VPN (proveedores cloud, VPS). Los kits AiTM y los atacantes rara vez operan desde un proveedor residencial.
- Un mismo Session ID visto desde dos redes. El inicio de sesión interactivo llega desde el proxy de phishing y los no interactivos de la misma sesión llegan desde otro lugar. Es el indicador de reutilización más fiable; consulte detección de phishing AiTM y reutilización de tokens.
- Ráfagas de fallos: difusión de contraseñas (una IP, muchas cuentas, error 50126) o solicitudes MFA rechazadas repetidamente seguidas de un éxito.
- Inicios de sesión con código de dispositivo o con protocolos heredados en usuarios que nunca los usan.
- El viaje imposible, con cautela: las VPN y las redes móviles generan muchos falsos positivos. El análisis de los registros de inicio de sesión de Entra ID explica cómo distinguirlos.
Anote, para cada inicio de sesión sospechoso: hora (UTC), IP, ASN, país, agente de usuario, aplicación, Session ID y Unique token identifier.
Paso 3: pivotar de la sesión a las acciones
Aquí una investigación de BEC pasa de la sospecha a la prueba. Microsoft traslada los identificadores del inicio de sesión a los registros de las cargas de trabajo: en el registro de auditoría unificado, los registros de Exchange y SharePoint incluyen AppAccessContext.AADSessionId y AppAccessContext.UniqueTokenId (Exchange también tiene SessionId). Microsoft los llama identificadores vinculables y documenta la correspondencia en Microsoft Learn.
Filtre el UAL por esos valores y por las IP del atacante y obtendrá las acciones del propio atacante, separadas de la actividad normal del usuario en el mismo buzón. Después léalas en orden: reglas de bandeja de entrada, reenvío, cambios de MFA, consentimientos, búsquedas, lecturas, descargas, envíos, eliminaciones. El artículo investigación del registro de auditoría unificado enumera las operaciones y los campos de AuditData que conviene leer en cada caso.
Dos salvedades. No todos los registros llevan identificador de sesión (algunos registros agregados o de procesos en segundo plano no lo tienen), así que mantenga el pivote por IP como respaldo. Y un pivote solo por IP puede engañar cuando el atacante usa una salida VPN compartida que también utiliza un usuario legítimo; la coincidencia de sesión es más sólida.
Paso 4: revisar cada mecanismo de persistencia
Los atacantes cuentan con que se restablezca la contraseña. Lo que sobrevive a ello:
| Persistencia | Evidencia | Por qué restablecer no sirve |
|---|---|---|
| Sesión / token de actualización robado | Inicios de sesión no interactivos desde la IP del atacante después del restablecimiento | Los tokens siguen siendo válidos hasta que se revocan o caducan |
| Regla de bandeja de entrada que reenvía al exterior | New-InboxRule con ForwardTo / RedirectTo | El correo sigue saliendo sin necesidad de iniciar sesión |
| Reenvío del buzón | Set-Mailbox con ForwardingSmtpAddress | Igual |
| Consentimiento OAuth | Consent to application, Add delegated permission grant | La aplicación tiene sus propios tokens (concesión de consentimiento ilícita) |
| Método MFA del atacante | User registered security info | El atacante supera la MFA con su propio dispositivo |
| Delegación del buzón | Add-MailboxPermission, Add-RecipientPermission | Acceso a través de otra cuenta |
| Rol privilegiado, secreto de aplicación, federación | Add member to role, Add service principal credentials, Set domain authentication | Acceso a nivel de tenant, independiente del usuario |
El artículo reglas de bandeja de entrada maliciosas y reenvío profundiza en la más habitual.
Paso 5: delimitar qué se leyó y qué se envió
La dirección hará dos preguntas: qué leyeron y a quién escribieron. La primera se responde con MailItemsAccessed: los registros Bind listan mensajes individuales por InternetMessageId; los registros Sync significan que un cliente descargó una carpeta entera, que debe considerarse expuesta. La segunda se responde con los registros Send de la sesión del atacante, el seguimiento de mensajes y las carpetas Elementos enviados y Elementos recuperables de la víctima. Las búsquedas por palabra clave (SearchQueryInitiatedExchange) muestran lo que buscaba el atacante, pero solo si ese registro está activado, algo que no ocurre por defecto según la guía de la CISA sobre los registros ampliados.
Paso 6: construir la cronología y el veredicto
Un buen informe de BEC tiene una única cronología en UTC, desde el primer inicio de sesión del atacante hasta la contención, en la que cada línea cita su registro. Expone el veredicto con sus motivos («comprometido: regla que reenvía al exterior creada desde una sesión reutilizada desde otro país»), lo que quedó expuesto y lo que no se pudo comprobar. Las lagunas importan tanto como los hallazgos: sin inicios de sesión no interactivos, sin MailItemsAccessed, retención de inicios de sesión de 7 días. El artículo retención y registros que faltan recoge las habituales.
Hacerlo sin SIEM
Muchas investigaciones de BEC se hacen en tenants pequeños sin área de trabajo de Sentinel ni presupuesto, con exportaciones que no caben en una hoja de cálculo. M365 Forensics ejecuta los pasos anteriores en el navegador: suelte el CSV del UAL y las exportaciones de Entra, y la herramienta analiza las dos capas del UAL (columnas CSV y JSON AuditData), vincula las acciones del buzón con las sesiones de inicio de sesión sospechosas y devuelve un veredicto (sin señales de compromiso, actividad sospechosa o compromiso probable) con las filas de evidencia, una cronología del incidente y una lista de remediación. No se sube nada: el analizador es WebAssembly que se ejecuta en su equipo. El paso a paso muestra cada pantalla, y el incidente ficticio comentado muestra cómo se lee un resultado realista.
No sustituye al criterio. Las heurísticas orientan, no prueban: un inicio de sesión desde un hosting puede ser su propia VPN y una regla de reenvío puede ser legítima. Confírmelo con el titular de la cuenta.
Después de la investigación
Cuando el veredicto es «comprometido», la contención va primero: revocar sesiones, eliminar la persistencia, detener los pagos. El orden importa y se detalla en la primera hora después de un BEC. Las recomendaciones de Microsoft están en Responder a una cuenta de correo comprometida y en las guías de respuesta a incidentes.
Preguntas frecuentes
¿Qué registros necesito para investigar un BEC en Microsoft 365?
Tres fuentes: el registro de auditoría unificado de Purview para las acciones en buzones, archivos y administración; los registros de inicio de sesión de Entra ID (interactivos y no interactivos) para saber quién inició sesión y desde dónde; y los registros de auditoría de Entra ID para métodos MFA, consentimientos de aplicaciones, roles y cambios de federación.
¿Restablecer la contraseña pone fin a un BEC?
No. Las cookies de sesión y los tokens de actualización robados, los consentimientos OAuth, las reglas de bandeja de entrada, el reenvío del buzón y los métodos MFA registrados por el atacante sobreviven a un cambio de contraseña. Hay que revocar las sesiones y eliminar cada elemento de persistencia.
¿Hasta cuándo hay que remontarse en la investigación?
Al menos 30 días antes del primer correo sospechoso, y más si los registros lo permiten. Los atacantes suelen iniciar sesión días o semanas antes de actuar, y el phishing que robó la sesión suele ser muy anterior al fraude.
Para saber más
- Microsoft Learn: Responder a una cuenta de correo comprometida
- Blog de seguridad de Microsoft: From cookie theft to BEC (en inglés)
- Glosario: compromiso del correo empresarial, registro de auditoría unificado, reutilización de tokens
- El mismo enfoque para otros proveedores de identidad: análisis forense de registros de Google Workspace y Okta.