Reglas de bandeja de entrada de un hacker en Microsoft 365
Cómo usan los atacantes las reglas de bandeja de entrada y el reenvío en un BEC, cómo hallarlas en el UAL y con Get-InboxRule, y cómo distinguirlas.
En resumen. La huella más habitual de un BEC en Microsoft 365 es una regla de bandeja de entrada que el usuario no creó: reenviar a una dirección externa, eliminar, marcar como leído o mover a RSS Feeds, Archive o Conversation History, a menudo filtrando por «factura», «pago» o «banco», a menudo llamada «.». En el registro de auditoría unificado busque New-InboxRule, Set-InboxRule, Enable-InboxRule y UpdateInboxRules, además de Set-Mailbox con ForwardingSmtpAddress. Compruebe la IP y la sesión de las que procede cada regla. Para el estado actual, ejecute Get-InboxRule -Mailbox <usuario> -IncludeHidden.
Las reglas de bandeja de entrada son baratas, silenciosas y eficaces. El atacante que secuestra una conversación con un proveedor necesita que la víctima no vea la respuesta «¿de verdad han cambiado de cuenta bancaria?». Una regla basta. Otra envía una copia de cada mensaje sobre pagos a un buzón externo para seguir leyendo tras el restablecimiento de la contraseña. MITRE las recoge como Email Hiding Rules (T1564.008) y Email Forwarding Rule (T1114.003).
Cómo son las reglas maliciosas
Las publicaciones de Microsoft sobre campañas AiTM que desembocan en BEC describen reglas que mueven el correo de un dominio remitente concreto a la carpeta Archive y lo marcan como leído, y reglas que mueven todo el correo entrante a Archive y lo marcan como leído (julio de 2022, junio de 2023). La guía de Microsoft sobre cuentas comprometidas menciona reglas que reenvían a direcciones desconocidas y reglas que mueven mensajes a Notes, Junk Email o RSS Subscriptions (Microsoft Learn).
| Rasgo | Patrón malicioso | Patrón legítimo |
|---|---|---|
| Nombre | ., .., a, ,,, un espacio | «Boletines», «Facturas de Acme» |
| Acción | ForwardTo / RedirectTo a una dirección externa, DeleteMessage, MarkAsRead, MoveToFolder a RSS Feeds (Fuentes RSS), Archive, Conversation History, Notes | Mover a una carpeta de proyecto con nombre |
| Condición | Asunto/cuerpo con factura, pago, transferencia, banco, IBAN (o phishing, hackeo, seguridad para ocultar avisos); From un proveedor concreto | El remitente de un boletín |
| Detener el procesamiento | StopProcessingRules = True | Normalmente false |
| Origen | IP de hosting / VPN, una sesión reutilizada, minutos después de un inicio de sesión sospechoso | IP de la oficina o de casa, el dispositivo habitual |
Ningún rasgo aislado demuestra nada. Hay usuarios que reenvían correo a una dirección personal y otros que ponen malos nombres a sus reglas. Lo que cuenta es la combinación y, sobre todo, la sesión que creó la regla.
Encontrar la creación de reglas en el registro de auditoría unificado
| Operación | Creada desde | Dónde están los detalles |
|---|---|---|
New-InboxRule | Outlook en la web, PowerShell | AuditData.Parameters: Name, ForwardTo, RedirectTo, ForwardAsAttachmentTo, DeleteMessage, MarkAsRead, MoveToFolder, SubjectOrBodyContainsWords, From, StopProcessingRules |
Set-InboxRule, Enable-InboxRule | Igual | Igual (modificación o reactivación) |
UpdateInboxRules | Cliente de escritorio de Outlook | AuditData.OperationProperties: RuleName, RuleActions, RuleCondition |
Set-Mailbox | Un administrador o el usuario vía PowerShell | ForwardingSmtpAddress (externo), ForwardingAddress (destinatario interno), DeliverToMailboxAndForward |
New-TransportRule, Set-TransportRule | Administrador de Exchange | Para toda la organización: redirecciones, copias CCO |
Una comprobación mínima en PowerShell sobre una exportación ya cargada en $all (consulte la guía de exportación):
$all | Where-Object { $_.Operations -in 'New-InboxRule','Set-InboxRule','UpdateInboxRules','Set-Mailbox' } |
ForEach-Object {
$d = $_.AuditData | ConvertFrom-Json
[pscustomobject]@{
Time = $d.CreationTime; User = $d.UserId; Op = $d.Operation
IP = $d.ClientIP; Session = $d.AppAccessContext.AADSessionId
Params = ($d.Parameters | ForEach-Object { "$($_.Name)=$($_.Value)" }) -join '; '
}
} | Sort-Object Time | Format-Table -Wrap
Después lleve el ClientIP y la sesión de cada regla a los registros de inicio de sesión. Una regla creada desde la IP y el Session ID de una sesión reutilizada no es una regla del usuario; el pivote por sesión explica cómo demostrarlo.
Comprobar el estado actual con Get-InboxRule
El registro de auditoría dice lo que pasó; el buzón dice lo que sigue ahí. Las comprobaciones recomendadas por Microsoft (Microsoft Learn):
Get-Mailbox -Identity user@example.com | Format-List Forwarding*Address,DeliverTo*
Get-InboxRule -Mailbox user@example.com -IncludeHidden |
Format-List Name,Enabled,RedirectTo,Forward*,Identity
Un ForwardingSmtpAddress no vacío indica reenvío SMTP a un destinatario externo; ForwardingAddress, a uno interno. -IncludeHidden devuelve reglas que los clientes normales no muestran. Compare la lista con el historial de auditoría: una regla presente hoy pero sin evento de creación en la exportación se creó antes de la ventana exportada (amplíe la búsqueda) o por una vía que la exportación no cubre.
Revise también los escondites: abra RSS Feeds, Archive, Conversation History, Notes y Deleted Items (Elementos eliminados) en el buzón de la víctima. El correo de advertencia del proveedor suele estar ahí, sin leer.
El reenvío a nivel de tenant
Las directivas de correo no deseado saliente controlan el reenvío automático a destinatarios externos con tres opciones: Automatic – System-controlled (la predeterminada, cuyo comportamiento varía según la organización), On y Off. Microsoft recomienda fijar On u Off explícitamente; cuando está bloqueado, tanto el reenvío por regla como el reenvío del buzón a direcciones externas se detienen con un NDR 5.7.520 (Microsoft Learn). Una regla de reenvío en el registro de auditoría no prueba que el correo saliera realmente: revise esta directiva, la configuración de dominios remotos y el seguimiento de mensajes.
Cómo puntúa M365 Forensics las reglas
El analizador en el navegador tiene una regla por patrón, todas visibles en su rules.json:
| Hallazgo | Gravedad | Se activa con |
|---|---|---|
| Regla de bandeja de entrada que reenvía correo fuera de la organización | Crítica | ForwardTo / RedirectTo / ForwardAsAttachmentTo a un dominio no reconocido como interno, o UpdateInboxRules cuyas acciones reenvían a uno |
| Reenvío del buzón a una dirección externa | Crítica | Set-Mailbox con ForwardingSmtpAddress / ForwardingAddress externo |
| Regla de bandeja de entrada que oculta o elimina el correo entrante | Alta | DeleteMessage, SoftDeleteMessage o MoveToFolder a RSS Feeds, Archive, Conversation History, Junk, Deleted Items, Notes… (nombres en inglés y algunos en francés, alemán y español) |
| Regla de bandeja de entrada dirigida a palabras de pagos o seguridad | Alta | Condiciones que contienen invoice, payment, wire, bank, IBAN, remittance y sus equivalentes en francés, español (factura, pago, transferencia), italiano y alemán, o phish / hack / security |
| Regla de bandeja de entrada con un nombre sin sentido | Media | Nombre de uno o dos caracteres |
| Regla / reenvío del buzón a otro buzón | Baja | Reenvío interno (normalmente una delegación) |
| Regla de flujo de correo (transporte) creada o modificada | Media | New-TransportRule, Set-TransportRule, Enable-TransportRule |
«Interno» se deduce de los dominios de las cuentas del tenant que aparecen en los registros. Si el atacante creó la regla desde una sesión sospechosa, se añade el hallazgo de correlación («Acciones realizadas desde la sesión o la IP del atacante») y el veredicto pasa a Compromiso probable. En el ejemplo ficticio integrado, una regla legítima «Newsletters» creada desde la IP de la oficina no se marca, mientras que las reglas «.» y «..» del atacante activan cada una varios hallazgos (ocultación, palabras clave o reenvío externo, nombre sin sentido, sesión del atacante).
Cuando encuentre una
No se limite a borrar la regla. Es la prueba de que otra persona usó la cuenta y puede ser uno de varios mecanismos de persistencia. Siga la primera hora de respuesta: revocar sesiones, eliminar reglas y reenvíos, quitar los métodos MFA del atacante y las aplicaciones consentidas, restablecer credenciales y después establecer qué se reenvió, se leyó y se envió. Guarde una exportación de la regla (y de su registro de auditoría) antes de eliminarla.
Preguntas frecuentes
¿Cómo veo las reglas de bandeja de entrada ocultas en Microsoft 365?
Ejecute Get-InboxRule -Mailbox <usuario> -IncludeHidden en Exchange Online PowerShell. Outlook y la configuración web no muestran todas las reglas; el registro de auditoría indica cuándo se creó cada regla y desde qué IP.
¿Qué hace sospechosa una regla de bandeja de entrada?
Una regla que el usuario no creó y que reenvía o redirige el correo al exterior, lo elimina, lo marca como leído o lo mueve a una carpeta que nadie lee (RSS Feeds, Archive, Conversation History), a menudo filtrando por palabras como factura, pago o banco, y a menudo con un nombre de un solo carácter.
¿Basta con eliminar la regla?
No. La regla demuestra que otra persona usó la cuenta. Revoque las sesiones, elimine el reenvío, los métodos MFA y los consentimientos de aplicaciones del atacante, restablezca las credenciales y compruebe qué se reenvió y qué se envió.
Para saber más
- Microsoft Learn: Detectar y corregir ataques de reglas de Outlook e inyección de formularios personalizados
- Glosario: regla de bandeja de entrada, compromiso del correo empresarial
- Gmail también tiene filtros y reenvío: googleworkspaceforensics.com.