Fatiga de MFA y consentimiento malicioso — del rastro a la regla

La técnica T1621 de MITRE ATT&CK, generación de solicitudes de autenticación multifactor, es enviar avisos de aprobación hasta que la persona cansada acepta uno. En el registro, cada aviso que la persona no supera es una fila con el código 50074: se exigió el segundo factor y no se pasó. Lo que delata el ataque no es un rechazo, sino una racha de rechazos seguida de una aprobación, desde un origen que no es el habitual.

Una persona que tarda en contestar o que se equivoca un par de veces desde la oficina también genera rechazos, y por eso la regla combina tres condiciones: cuántos en una ventana, desde dónde y si termina en acierto.

La primera consulta cuenta los rechazos del segundo factor por cuenta. Hay tres cuentas con rechazos y solo una con una racha larga. Mira la segunda cuenta de la lista: tiene varios rechazos, pero desde la oficina y terminó aprobando en minutos; esa es la forma de ruido normal, y una regla que la alerte irá contra el equipo de soporte, no contra un atacante. La segunda consulta lista esos rechazos que salieron de Colombia.

SigninLogs | where ResultType == "50074" | summarize rechazos = count() by UserPrincipalName | order by rechazos desc

SigninLogs | where Location == "CO" and ResultType == "50074" | order by TimeGenerated asc

Para fijar el umbral hay que medir la racha completa. Mira todo lo que se registró desde fuera de Colombia: una noche con rechazos del segundo factor y al final una aprobación. Cuenta cuántas veces se rechazó el segundo factor antes de que se aprobara. Ese número, comparado con el de la cuenta que simplemente tardó en contestar, es el que decide si el umbral está en cinco, en cuatro o en tres.

SigninLogs | where Location != "CO" | order by TimeGenerated asc

Si la persona aprueba, el atacante entra. Lo que hace después, en el caso que importa aquí, es conseguir que la cuenta dé permisos a una aplicación suya: la técnica T1528 incluye ese consentimiento a una aplicación maliciosa. Un consentimiento no depende de la contraseña ni de la sesión; cambiar la contraseña de la víctima no lo retira.

Ese rastro no está en el registro de inicios de sesión sino en el de auditoría del directorio, con la operación Consent to application. Mira los permisos que concede cada una y si el publicador de la aplicación está verificado.

AuditLogs | where OperationName == "Consent to application"

Hay tres consentimientos en la muestra y solo uno es sospechoso. Alertar todos los consentimientos haría la regla inservible; ignorarlos dejaría sin ver una vía de persistencia. La regla útil combina el permiso, el publicador y la cuenta: permisos que permiten leer o enviar correo, publicador sin verificar y, de ser posible, una cuenta que acaba de pasar por una racha de rechazos.

La consulta de abajo filtra por el permiso de envío de correo y es el primer paso de esa regla.

AuditLogs | where OperationName == "Consent to application" and Permisos has "Mail.Send"