Ejemplo de BEC: un incidente ficticio en Microsoft 365

Escenario ficticio. Todo en este artículo es inventado: la empresa Meridian Freight (meridianfreight.example), su personal, las direcciones IP (rangos de documentación RFC 5737), las sesiones y los correos. Solo los formatos de registro son reales. Es el conjunto de datos Probar un ejemplo de M365 Forensics, así que puede abrirlo y seguirlo.

En resumen. Una difusión de contraseñas desde un VPS fracasa. A la mañana siguiente, una empleada de cuentas a pagar inicia sesión a través de un proxy de phishing AiTM; siete minutos después, su sesión se reutiliza desde otro país. En 90 minutos el atacante registra una aplicación Authenticator, crea dos reglas de bandeja de entrada llamadas «.» y «..», configura el reenvío del buzón al exterior, sincroniza unos 450 mensajes, busca «facture virement IBAN», da consentimiento a una aplicación de correo, descarga 64 facturas y envía un falso cambio de datos bancarios que después borra. La herramienta devuelve Compromiso probable con 18 hallazgos, tres de ellos críticos. A continuación, cómo aparece cada paso en los registros y dónde los hallazgos necesitan una mirada humana.

Los datos de entrada

Cuatro archivos, en los formatos de las exportaciones reales:

Cobertura: 366 eventos del 2026-09-14 07:02 al 2026-09-15 16:33 UTC, con registros MailItemsAccessed. El conjunto incluye también actividad normal de ocho usuarios (inicios de sesión en la oficina, lectura de correo, acceso a archivos, una regla de bandeja de entrada legítima), así que el ataque hay que encontrarlo, no solo leerlo.

La cronología (UTC)

El hallazgo de correlación crítico, «Acciones realizadas desde la sesión o la IP del atacante», agrupa 103 eventos: todo lo procedente de las dos IP del atacante o de la sesión reutilizada, incluidas las reglas, el reenvío, el registro de MFA, el consentimiento, las lecturas, las descargas, el envío y el borrado. Ese hallazgo, por sí solo, responde a la pregunta «¿fue ella o fueron ellos?».

Por qué el veredicto es «Compromiso probable»

La regla: al menos un hallazgo crítico, o dos hallazgos altos distintos en una misma cuenta. Aquí hay tres críticos (reenvío externo por regla, reenvío externo del buzón, sesión del atacante) y ocho altos en la cuenta de Claire. El apartado Por qué, bajo el veredicto, enlaza con ellos.

Donde quien analiza todavía tiene que pensar

Un informe real no se limita a pegar los hallazgos. Tres ejemplos de este conjunto de datos:

1. El viaje imposible mezcla inicios de sesión legítimos y maliciosos. Sus pruebas muestran los saltos «FR → NL · 694 km en 29 min» y «NL → US · 6245 km en 7 min». El primer salto parte del inicio de sesión real de Claire en la oficina; el atacante está en los lados NL y US. El hallazgo apunta a la cuenta correcta, pero las pruebas hay que separarlas a mano. El hallazgo de sesión es el preciso.
2. Los hallazgos por umbral incluyen la actividad de la propia usuaria. Los hallazgos de volumen del buzón y de descarga masiva listan todos los eventos de su ventana de una hora, incluidas las lecturas de Outlook de Claire y un archivo que abrió desde la oficina (192.0.2.10). La parte del atacante es la que procede de 203.0.113.77, con el cliente REST y el agente de usuario rclone.
3. Un hallazgo medio es un falso positivo. El 14/09 a las 09:05, Sofia Garcia registró información de seguridad desde la IP de la oficina. Se marca como nuevo método MFA (medio), igual que el registro del atacante. Nada más lo vincula con el ataque: una comprobación rápida con Sofia lo cierra.

En cambio, la regla «Newsletters» de Thomas Becker (de un remitente de boletines a una carpeta Newsletters, creada desde la oficina) no genera ningún hallazgo.

Delimitar el alcance

• Leído: los registros MailItemsAccessed desde la IP del atacante usan el cliente REST y llevan la sesión reutilizada. La lista de InternetMessageId da los mensajes que hay que revisar (qué demuestra MailItemsAccessed).
• Reenviado: todo lo del proveedor después de las 08:33 (regla «..») y cada mensaje entrante después de las 08:36 (reenvío del buzón), hasta su eliminación.
• Descargado: 64 archivos de sites/Finance/Shared Documents/Factures 2026.
• Enviado: al menos un correo fraudulento a un cliente; el seguimiento de mensajes mostraría los destinatarios.
• Persistencia que eliminar: el Authenticator registrado a las 08:24, las reglas «.» y «..», el reenvío del buzón, la concesión y la entidad de servicio de «Mail Sync Pro», y la propia sesión.

La lista de remediación

La herramienta ordena los pasos a partir de los hallazgos: revocar las sesiones, restablecer las credenciales y volver a registrar la MFA, evaluar la exposición de datos, eliminar las reglas, eliminar el reenvío y bloquear el reenvío externo automático, bloquear las IP del atacante, pasar a MFA resistente al phishing, avisar a los contactos, revisar los pagos, quitar la aplicación consentida y restringir el consentimiento de los usuarios, revisar los métodos MFA y los registros de aplicaciones. La primera hora después de un BEC explica por qué ese orden.

Lo que este ejemplo no muestra

Los incidentes reales son más desordenados: exportaciones truncadas en 50.000 filas, inicios de sesión ya caducados, atacantes que usan proxies residenciales en lugar de redes de hosting, varias víctimas. Los límites están en retención y registros que faltan. El método sigue siendo el de la guía de investigación: encontrar el inicio de sesión del atacante, seguir la sesión y revisar cada mecanismo de persistencia.

Para saber más

• Analizar el registro de auditoría unificado en el navegador
• Detección de phishing AiTM
• Glosario: adversary-in-the-middle, regla de bandeja de entrada, concesión de consentimiento ilícita