Detección de Ráfaga de Inicios de Sesión Fallidos en Entra ID: Por Qué Identity Protection No la Detecta

Detección de Ráfaga de Inicios de Sesión Fallidos en Entra ID: Qué Es

La cobertura de detección de ráfaga de inicios de sesión fallidos en Entra ID es deliberadamente escasa: Microsoft Entra ID Identity Protection no incluye ninguna detección de riesgo nativa diseñada para detectar una ráfaga de inicios de sesión fallidos contra una misma cuenta, aunque la señal en bruto — docenas de intentos de contraseña inválida contra una cuenta en una ventana corta de tiempo — está directamente en tus registros de inicio de sesión. Este artículo explica por qué las propias detecciones de Identity Protection no se activan ante una racha pura de fallos, y cómo cerrar esa brecha con una consulta KQL, un ajuste de Smart Lockout, y una alerta que avise antes del décimo intento, no después del primero exitoso.

Una contraseña incorrecta contra Entra ID llega a SigninLogs con el código de error AADSTS50126, y la propia referencia de Microsoft para ese código es directa sobre por qué una sola ocurrencia no significa nada: InvalidUserNameOrPassword — «Error al validar las credenciales debido a un nombre de usuario o contraseña inválidos. El usuario no introdujo las credenciales correctas. Es normal ver cierto número de estos errores en tus registros debido a errores de los usuarios.» No es el único código de fallo de credenciales que documenta Microsoft — AADSTS50056 es «Contraseña inválida o nula: la contraseña no existe en el directorio para este usuario» — y una detección que solo vigila uno de ellos ve solo parte de la ráfaga. Una errata es ruido. Veinte de ellas contra la misma cuenta en cinco minutos, o la misma contraseña probada contra cincuenta cuentas en cinco minutos, no lo es: eso es fuerza bruta dirigida en el primer caso y password spraying en el segundo, y ambos patrones se manifiestan como la misma señal en bruto: una ráfaga de 50126.

Esa distinción importa para saber a qué enlaza este artículo. Si buscas el manual de juego del atacante — enumeración de objetivos, listas de contraseñas comunes, por qué el spraying evita los bloqueos por cuenta — eso es Password Spraying: Detección y Prevención para Active Directory y Entra ID. Este artículo es la otra mitad: la ingeniería de detección sobre telemetría en bruto que tiene que existir porque el propio motor de riesgo de Identity Protection deja esta señal específica sin marcar.

Por Qué Identity Protection No la Marca

Microsoft documenta todas las detecciones de riesgo de inicio de sesión y de usuario que ofrece Identity Protection, y ninguna es «inicios de sesión fallidos repetidos contra una misma cuenta». Los candidatos más cercanos fallan todos en captar esta señal por una razón específica y documentada:

El resultado práctico: una campaña de fuerza bruta dirigida o una oleada de spraying sin éxito puede transcurrir enteramente dentro de SigninLogs — visible, con marca de tiempo, atribuible a una IP y a un conjunto de cuentas — sin tocar jamás RiskState, RiskLevelAggregated, ni una sola fila en el informe de usuarios de riesgo. Si tu monitorización se detiene en el panel de Identity Protection, este patrón es invisible hasta que tiene éxito.

Detección: Construye Tú Mismo la Consulta

Como no existe ningún riskEventType para este patrón, la detección debe construirse directamente contra SigninLogs, la tabla de Log Analytics a la que se transmiten los eventos de inicio de sesión de Entra ID una vez habilitada la exportación de diagnóstico. Las columnas que importan:

Antes de elegir un umbral, establece la línea base de tu propio tenant. Las consultas de ejemplo de SigninLogs publicadas por Microsoft incluyen un punto de partida para esto — «Failed Signin reasons» — adaptado aquí para separar los códigos de fallo de credenciales que importan:

SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType in ("50126", "50056", "50053")
| summarize Count = count() by ResultType, ResultDescription
| order by Count desc

Ejecútala primero. Si el ruido ordinario de 50126 por erratas ya se cuenta por cientos al día, un umbral de ráfaga de un solo dígito generará alertas por nada. Con una línea base en mano, dos consultas cubren las dos variantes de la misma carencia del catálogo — fuerza bruta dirigida contra una identidad, y spraying lento y sigiloso contra muchas:

Ráfaga contra una sola cuenta:

SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType in ("50126", "50056", "50053")
| summarize FailureCount = count(),
            SourceIPs = dcount(IPAddress),
            LastFailure = max(TimeGenerated)
    by UserPrincipalName, bin(TimeGenerated, 15m)
| where FailureCount >= 10
| order by FailureCount desc

Ráfaga repartida entre muchas cuentas desde una sola fuente:

SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType in ("50126", "50056", "50053")
| summarize FailureCount = count(),
            TargetedAccounts = dcount(UserPrincipalName),
            Accounts = make_set(UserPrincipalName, 20)
    by IPAddress, bin(TimeGenerated, 15m)
| where FailureCount >= 10 or TargetedAccounts >= 5
| order by FailureCount desc

Ambas consultas usan solo columnas documentadas de SigninLogs; los umbrales 10 y 5 son puntos de partida ilustrativos, no valores predeterminados de Microsoft — dimensiónalos según la línea base anterior, y luego ajústalos a medida que bajen los falsos positivos. Conecta cualquiera de las dos consultas a una regla analítica programada de Microsoft Sentinel (o a una alerta de log de Azure Monitor normal si no usas Sentinel) para que una ráfaga genere un incidente en lugar de esperar a ser descubierta en una revisión manual de registros.

Remediation / Remediación

1. Ajusta Smart Lockout en lugar de asumir que el valor predeterminado es suficiente

Smart Lockout está activado para todos los tenants, pero sus valores predeterminados están ajustados para la usabilidad general, no para la detección:

• El umbral de bloqueo predeterminado es de 10 intentos fallidos (tenants de Azure Public; 3 para Azure US Government), tras lo cual la cuenta se bloquea durante 60 segundos iniciales, aumentando con bloqueos repetidos.
• Smart Lockout «usa la ubicación familiar frente a la no familiar para diferenciar entre un actor malicioso y el usuario genuino», y «tanto las ubicaciones familiares como las no familiares tienen contadores de bloqueo separados» — así que un atacante que inicia sesión desde una ubicación que el usuario real nunca ha usado consume su propio contador, rastreado independientemente de los errores del propio usuario.
• Smart Lockout también «rastrea los últimos tres hashes de contraseña incorrectos para evitar incrementar el contador de bloqueo por la misma contraseña». Un spraying que repite una misma contraseña común contra una cuenta nunca la acerca al bloqueo por tanto — que es precisamente el caso que tu propia consulta tiene que detectar. Microsoft señala que este rastreo de hashes «no está disponible para clientes con autenticación de paso directo (pass-through) habilitada».
• Personalizar el umbral y la duración por debajo del valor predeterminado requiere Microsoft Entra ID P1 o superior, configurado en Entra ID > Métodos de autenticación > Protección de contraseñas.

Un umbral más bajo cambia algo de fricción para el usuario por cortar una campaña de fuerza bruta bien antes de que se cierre tu ventana de detección de 15 minutos. Coordina el cambio con cualquier política de bloqueo de AD DS híbrida. Para la autenticación de paso directo (pass-through authentication), Microsoft es explícito: el umbral de bloqueo de Entra «debe ser menor que el umbral de bloqueo de cuenta de AD DS», configurado «de forma que el umbral de bloqueo de cuenta de AD DS sea al menos dos o tres veces mayor que el umbral de bloqueo de Microsoft Entra» — así el bloqueo en la nube absorbe el ataque antes de que llegue al entorno local.

2. Convierte la consulta KQL en una alerta permanente

Una consulta que solo se ejecuta cuando alguien recuerda pegarla en Log Analytics no es una detección. Guárdala como una regla analítica programada de Microsoft Sentinel (o una alerta de log de Azure Monitor) con una cadencia de 15 minutos que coincida con la ventana bin(), y enrútala a quien gestione los incidentes de identidad. Este es el control que realmente cierra la brecha del catálogo — Identity Protection permanece en silencio ante una ráfaga de fallos pura, así que nada más te avisará.

3. Añade una política de Acceso Condicional basada en riesgo de inicio de sesión para los casos que sí tienen éxito

Nada de esto sustituye al Acceso Condicional basado en riesgo — lo complementa. Si una ráfaga acaba produciendo un intento exitoso, una política de riesgo de inicio de sesión es lo que impide que esa sesión haga algo. La guía completa para construir una está en Azure Identity Protection: Bloqueo de Credenciales Filtradas; si tu base de Acceso Condicional tiene otras brechas más allá del riesgo de inicio de sesión, revísala con Brechas de Acceso Condicional en Azure.

4. Activa la exportación de registros de inicio de sesión antes de necesitarla

SigninLogs solo se llena una vez habilitada la exportación de diagnóstico a Log Analytics — como cualquier flujo de Azure Monitor, captura eventos hacia adelante, no retroactivamente. Activa esa exportación en Entra ID > Supervisión y estado > Configuración de diagnóstico ahora, para que el historial esté disponible la próxima vez que necesites ejecutar estas consultas contra un incidente que ya tiene una semana.

Cómo Detecta Esto EtcSec

Los controles de Risk Protection de EtcSec incluyen exactamente esta correlación de telemetría en bruto — rastreada internamente como RISK_FAILED_SIGNIN_BURST, calificada como crítica y mapeada a MITRE ATT&CK T1110.003 — porque el propio motor de riesgo de Identity Protection, como se documenta arriba, no tiene ninguna detección vinculada al volumen de fallos contra una sola cuenta. El control ejecuta las dos mismas formas que las consultas anteriores, sobre una ventana fija de 10 minutos: más de 50 fallos de credenciales contra un usuario, o más de 50 desde una IP a través de más de 10 usuarios distintos. Esos son umbrales de auditoría, fijados lo bastante altos como para que un hallazgo sea un incidente y no un punto de partida — que es precisamente por qué el KQL anterior empieza más bajo y te pide establecer primero una línea base. Se sitúa junto a los controles que auditan qué ocurre una vez que Identity Protection sí levanta una alerta: RISK_SIGNINS_NOT_INVESTIGATED (inicios de sesión de riesgo sin seguimiento) y RISK_NO_AUTOMATED_RESPONSE (riesgo visible, sin respuesta automatizada configurada), y alimenta directamente si CA_NO_RISK_BASED_SIGNIN (sin política de Acceso Condicional basada en riesgo de inicio de sesión) importa en tu entorno.

Para los detectores hermanos de la misma familia de telemetría en bruto, consulta Detección de Anomalías de Inicio de Sesión de Service Principal en Entra , Entra ID AiTM Token Replay, Detección de Viajes Imposibles y MFA Fatigue: Detección y Prevención en Microsoft Entra ID. Para la brecha del lado de la respuesta una vez que Identity Protection sí se activa, consulta Entra ID Risk Protection: Credenciales Filtradas, Usuarios de Riesgo No Remediados.

Referencias Principales

• Microsoft Learn: What are risk detections? (Entra ID Protection)
• Microsoft Learn: Prevent attacks using Smart Lockout (Microsoft Entra ID)
• Microsoft Learn: Microsoft Entra authentication & authorization error codes
• Microsoft Learn: Azure Monitor Logs reference — SigninLogs
• Microsoft Learn: Example log table queries for SigninLogs
• Microsoft Learn: Learn about the monitoring and health activity log schemas (Microsoft Entra ID)