BEC: qué hacer en la primera hora (Microsoft 365)
La primera hora tras un BEC en Microsoft 365: frenar el dinero, conservar los registros, revocar sesiones y eliminar la persistencia, en el orden correcto.
En resumen. En la primera hora: (1) si hay un pago de por medio, llame al banco y congele las transferencias pendientes; (2) lance las exportaciones de registros (UAL, inicios de sesión interactivos y no interactivos de Entra, auditoría de Entra) antes de que algo caduque; (3) bloquee la cuenta o restablezca su contraseña desde un dispositivo limpio y revoque las sesiones; (4) registre y después elimine reglas de bandeja de entrada, reenvíos, métodos MFA desconocidos y consentimientos de aplicaciones; (5) avise a las personas a las que escribió el buzón. Restablecer la contraseña por sí solo deja activas las sesiones robadas, las reglas, los reenvíos, los consentimientos y los métodos MFA del atacante.
La primera hora es cuando se produce la mayor parte del daño evitable: sale una segunda transferencia, el atacante se da cuenta y borra sus huellas, o alguien «limpia» el buzón y destruye el único registro de lo que se reenvió. El orden siguiente equilibra frenar el daño y conservar las pruebas.
0–10 minutos: primero el dinero
Si el BEC implica un pago (cambio de datos bancarios, una transferencia «urgente»), la ventana de recuperación es corta.
- Pida a finanzas que detenga las transferencias pendientes y trate como no verificado cualquier cambio de datos bancarios recibido desde el primer evento sospechoso.
- Llame a su banco y solicite la retrocesión de cualquier transferencia ya realizada.
- En Estados Unidos, presente una denuncia ante el IC3 del FBI: su Recovery Asset Team colabora con las entidades financieras para congelar transferencias fraudulentas mediante la Financial Fraud Kill Chain, en su mayoría casos de BEC (informe IC3 2024). En otros países, denuncie ante la policía y el servicio nacional de notificación de ciberdelitos.
- Verifique cualquier cambio de datos bancarios por teléfono, en un número que ya tuviera, nunca en el que aparezca en el correo.
10–20 minutos: conservar las pruebas
Lance ya las exportaciones: tardan y la retención es corta (7 días para los inicios de sesión de Entra en tenants gratuitos).
- Búsqueda de auditoría de Purview de todo el tenant, 30 días o más hacia atrás.
- Inicios de sesión interactivos y no interactivos de Entra y registros de auditoría de Entra.
- Estado actual:
Get-InboxRule -Mailbox <usuario> -IncludeHidden | Format-List *yGet-Mailbox <usuario> | Format-List Forwarding*,DeliverTo*, guardados en archivos.
Detalles en cómo exportar los registros. Calcule los hash de los archivos. Haga el análisis después, sobre copias.
20–40 minutos: cortar el acceso del atacante
En este orden, según la respuesta de Microsoft a cuentas comprometidas:
| # | Acción | Cómo | Por qué |
|---|---|---|---|
| 1 | Deshabilitar la cuenta (preferible) o restablecer la contraseña | Centro de administración de Entra → usuario → Account enabled desactivado; o restablecer desde un dispositivo limpio, sin enviar nunca la contraseña nueva por correo | Bloquea nuevos inicios de sesión |
| 2 | Revocar las sesiones | Centro de administración de Entra → usuario → Revoke sessions, o Revoke-MgUserSignInSession -UserId <UPN> | Invalida los tokens de actualización; restablecer la contraseña no acaba con una sesión robada |
| 3 | Revisar los métodos MFA | Entra → usuario → Authentication methods; eliminar los que el usuario no registró | Los atacantes añaden su propio Authenticator o teléfono |
| 4 | Revisar los consentimientos de aplicaciones | Entra → usuario → Applications; eliminar las aplicaciones desconocidas | Las aplicaciones consentidas conservan sus propios tokens |
| 5 | Revisar los roles de administración | Asignaciones de roles de Entra | Por si la cuenta era privilegiada o se elevó |
| 6 | Eliminar el reenvío | Set-Mailbox <usuario> -ForwardingSmtpAddress $null -ForwardingAddress $null | Detiene la salida de correo |
| 7 | Eliminar las reglas maliciosas | Remove-InboxRule después de registrarlas | Detiene la ocultación y el reenvío |
Dos notas. Los tokens de acceso ya emitidos pueden seguir siendo válidos hasta que caduquen (una hora por defecto), salvo que la aplicación admita la evaluación continua de acceso (Microsoft Learn). Y en cuentas sincronizadas desde Active Directory local, Microsoft recomienda restablecer la contraseña en AD, dos veces.
Si conoce las IP del atacante, añádalas a una ubicación con nombre bloqueada en el acceso condicional y compruebe si tocaron otras cuentas.
40–60 minutos: avisar y delimitar
- Avise a los contactos. El atacante escribe desde el buzón real. Diga a los clientes y proveedores con los que se relacionaba la cuenta (Elementos enviados y los registros
Senddel atacante le dicen quiénes) que cualquier cambio de datos bancarios debe confirmarse por teléfono. - Revise las carpetas de ocultación (RSS Feeds, Archive, Conversation History, Notes, Elementos eliminados) en busca de las respuestas que ocultó el atacante y recupere los elementos eliminados desde Elementos recuperables para ver qué se envió y se borró.
- Busque casos parecidos en el tenant: otros usuarios con inicios de sesión desde las mismas IP, la misma aplicación consentida en otras cuentas, los mismos nombres de regla. Las campañas de BEC envían su siguiente phishing desde el buzón comprometido a sus contactos.
- Empiece la cronología a partir de las exportaciones: M365 Forensics genera el veredicto, los hallazgos y una lista de remediación ordenada por urgencia a partir de los registros, sin subirlos a ningún sitio. La guía de investigación cubre el método completo.
Errores habituales
| Error | Consecuencia |
|---|---|
| Restablecer la contraseña y quedarse ahí | Sesión, reglas, reenvíos, consentimientos y MFA del atacante siguen activos |
| Borrar las reglas antes de registrarlas | Ya no se sabe qué se reenvió u ocultó |
| Exportar solo los inicios de sesión interactivos de la víctima | La reutilización y la difusión de contraseñas son invisibles |
| Enviar la contraseña nueva al buzón del usuario | El atacante todavía puede leerla |
| Esperar a «tener toda la imagen» antes de contener | Sale una segunda transferencia |
| Alertar al atacante (responder desde el buzón) | Acelera o borra sus huellas |
Después de la primera hora
- Terminar la investigación: qué se leyó (MailItemsAccessed), qué se envió y a quién más se atacó.
- Evaluar las obligaciones de notificación si se expusieron datos personales (por ejemplo, la regla de 72 horas del RGPD).
- Reforzar: MFA resistente al phishing, bloquear la autenticación heredada y el flujo de código de dispositivo donde no se necesiten, poner el reenvío automático externo en Off en la directiva de correo no deseado saliente, restringir el consentimiento de los usuarios y conservar los registros de Entra a largo plazo.
Las guías de respuesta a incidentes de Microsoft profundizan en phishing, difusión de contraseñas y concesión de consentimiento de aplicaciones.
Preguntas frecuentes
¿Qué debo hacer primero tras un compromiso del correo empresarial?
Si puede haber dinero en movimiento, llame al banco y pida a finanzas que congele los pagos pendientes. En paralelo, exporte los registros de auditoría e inicio de sesión y después revoque las sesiones de la cuenta, elimine la persistencia del atacante (reglas, reenvíos, métodos MFA, consentimientos de aplicaciones) y restablezca la contraseña.
¿Debo borrar de inmediato la regla de bandeja de entrada maliciosa?
Regístrela primero: exporte los detalles de la regla y su registro de auditoría. Después elimínela. Borrarla primero hace perder los parámetros que dicen qué se reenvió u ocultó.
¿Es mejor deshabilitar la cuenta que restablecer la contraseña?
Microsoft recomienda deshabilitar la cuenta durante la investigación cuando sea posible, junto con la revocación de sesiones. Si no se puede deshabilitar, restablezca la contraseña y revoque las sesiones.