Entra ID Risk Protection: Credenciales Filtradas, Usuarios de Riesgo No Remediados

Entra ID Risk Protection: Credenciales Filtradas, Usuarios de Riesgo No Remediados

Entra ID Risk Protection no tiene ningún problema para encontrar cuentas comprometidas. El problema es lo que ocurre después. En un gran número de tenants se repite el mismo patrón — Entra ID Risk Protection detecta credenciales filtradas y usuarios de riesgo que no se remedian durante semanas o meses — porque la detección se dispara, aterriza en un informe y se queda ahí. Este artículo trata sobre esa brecha: no la ingeniería de detección, que Microsoft ya resuelve por ti, sino el flujo de respuesta que casi nadie llega a operacionalizar.

Todo usuario de riesgo en Entra ID lleva asociado un estado de riesgo. Microsoft Graph documenta los valores posibles como none, confirmedSafe, remediated, dismissed, atRisk y confirmedCompromised (además del centinela unknownFutureValue). Solo tres de ellos sacan a una cuenta marcada de la cola — remediated, dismissed y confirmedSafe, que corresponden a las acciones manuales que expone Microsoft: descartar, confirmar como segura, confirmar como comprometida. Tanto atRisk como confirmedCompromised dejan al usuario dentro del informe de usuarios de riesgo. atRisk significa que la cuenta sigue marcada y que no se ha hecho nada con ella. confirmedCompromised es el estado que suele sorprender: un administrador revisó la cuenta, coincidió en que estaba comprometida, y el estado por sí solo sigue sin significar que alguien la haya asegurado.

Confirmar el compromiso es una acción de etiquetado, no de contención. Lo mismo ocurre con el descarte.

El backlog tampoco caduca por sí solo. Las detecciones y usuarios de riesgo bajo "persisten en el producto durante seis meses, tras los cuales se eliminan automáticamente por antigüedad" — pero los niveles de riesgo medio y alto persisten hasta que se remedian o se descartan. Una detección de credenciales filtradas de riesgo alto generada hace dos años sigue hoy en el informe de usuarios de riesgo, a menos que una persona o una política la haya cerrado.

Cómo Funciona la Detección de Credenciales Filtradas

Credenciales filtradas es una de las pocas detecciones de riesgo que no presenta ninguna ambigüedad.

Microsoft describe el pipeline detrás de esta detección: un servicio de escaneo de credenciales a gran escala que monitoriza continuamente foros de la dark web, repositorios de volcados de brechas, sitios de paste, datos de incautaciones de las fuerzas del orden y otras fuentes, a través del Microsoft Threat Intelligence Center (MSTIC), la Microsoft Digital Crimes Unit (DCU) y socios del sector. Cuando se descubren credenciales, el servicio valida el material de credenciales real contra los hashes de contraseñas válidos actuales del tenant, y se emite una detección solo cuando se encuentra una coincidencia confirmada. En palabras de la propia Microsoft, la detección "es siempre de riesgo alto porque representa una exposición de credenciales verificada, no una señal heurística."

De ahí se derivan dos consecuencias operativas.

Primero, esto no es una puntuación de probabilidad. Un viaje atípico podría deberse a un usuario de vacaciones. Una detección de credenciales filtradas significa que una contraseña que actualmente funciona en tu tenant está en manos de otra persona. Merece un incidente, no una cola de triaje.

Segundo, te enteras tarde. Credenciales filtradas se calcula sin conexión, y Microsoft documenta que "las detecciones activadas en tiempo real tardan de 5 a 10 minutos en mostrar detalles en los informes. Las detecciones sin conexión tardan hasta 48 horas en aparecer en los informes." La ventana entre la exposición y tu primera oportunidad de actuar se mide en días, que es precisamente por qué la respuesta debe ser rápida una vez que llega la señal.

La sincronización de hash de contraseñas importa aquí más de lo que la mayoría de los equipos se imagina. Un restablecimiento de contraseña basado en la nube a través de Microsoft Entra remedia el riesgo de usuario para esta detección tanto para contraseñas en la nube como on-premises — pero solo "siempre que la sincronización de hash de contraseñas (PHS) esté habilitada para las contraseñas on-premises."

Por Qué el Backlog de Usuarios de Riesgo Nunca Se Vacía

Los tenants con los peores backlogs raramente son los que ignoraron el producto. Son aquellos en los que se acumulan varias brechas pequeñas.

Las alertas no llegan a nadie. El correo "Se detectaron usuarios en riesgo" tiene por defecto un umbral de riesgo de usuario alto. Por defecto, los usuarios asignados activamente a los roles de Administrador Global, Administrador de Seguridad o Lector de Seguridad se añaden a la lista de destinatarios, y deben tener configurado un Correo electrónico o un Correo electrónico alternativo. Dos advertencias documentadas rompen esto silenciosamente: un usuario que se eleva a uno de esos roles mediante Privileged Identity Management "solo recibe correos si está elevado en el momento en que se envía el correo," y "no se admite el envío de correos a usuarios en roles asignados por grupo." Un tenant que concede Lector de Seguridad mediante un grupo y eleva a los administradores bajo demanda mediante PIM puede recibir exactamente cero notificaciones mientras su panel se va llenando.

Los umbrales de política están fijados por encima de la mayor parte de la cola. La configuración recomendada por Microsoft es una política de riesgo de usuario en Alto y una política de riesgo de inicio de sesión en Medio y Alto. Es una recomendación sensata, pero significa que cada detección de riesgo de usuario medio y riesgo bajo queda para una persona, y los riesgos medios persisten hasta que alguien los cierra.

La autorremediación en realidad no está disponible. Microsoft advierte que "los usuarios deben registrarse para la autenticación multifactor de Microsoft Entra antes de enfrentarse a una situación que requiera remediación. Para usuarios híbridos sincronizados desde on-premises, debe estar habilitada la escritura diferida de contraseñas (password writeback). Los usuarios no registrados quedan bloqueados y requieren la intervención de un administrador." Los usuarios híbridos también necesitan PHS más la opción de activación Permitir que el cambio de contraseña on-premises restablezca el riesgo del usuario antes de que un cambio de contraseña on-premises limpie su riesgo. Cuando faltan esos prerrequisitos, la política no vacía la cola — convierte a los usuarios de riesgo en usuarios bloqueados y traslada el trabajo a la mesa de ayuda.

Algunas detecciones dejaron de autorremediarse. Microsoft ya no remedia automáticamente las sesiones que llevan reclamaciones de MFA cuando se dispara una detección relacionada con el robo de tokens o la detección de IP de actor de amenaza verificado. Las detecciones afectadas son Microsoft Entra threat intelligence, Token anómalo, Attacker in the Middle, IP de actor de amenaza verificado y Anomalía del emisor del token. Cuando una de estas afecta a un usuario, limpiar el riesgo requiere un cambio de contraseña seguro y una reautenticación con MFA. Si tu modelo mental sigue siendo "el MFA lo limpia todo," estos casos se van acumulando.

Los usuarios eliminados quedan atrapados para siempre. "Si un usuario que tenía un riesgo presente fue eliminado del directorio, ese usuario sigue apareciendo en el informe de riesgo aunque la cuenta haya sido eliminada. Los administradores no pueden descartar el riesgo de usuarios que fueron eliminados del directorio." Eliminarlos requiere abrir un caso de soporte con Microsoft. Cada usuario de riesgo dado de baja infla permanentemente el recuento, lo que entrena al equipo a dejar de confiar en la cifra.

La automatización heredada tiene fecha de caducidad. La indicación de Microsoft es explícita: "Las políticas de riesgo heredadas configuradas en Microsoft Entra ID Protection se retirarán el 1 de octubre de 2026." Los tenants cuya única respuesta automatizada sea una política de riesgo heredada de ID Protection — en lugar de una política de acceso condicional — la perderán, y un backlog que se estaba vaciando automáticamente empezará a crecer de nuevo.

Detección: Mide Tu Propio Backlog de Remediación

Los informes del portal te dicen quién está en riesgo. No te dicen cuánto tiempo permanece alguien en riesgo, que es el dato que realmente importa. Para eso necesitas los datos de riesgo en Log Analytics.

Configura la configuración de diagnóstico en Entra ID > Monitoring & health > Diagnostic settings y exporta las categorías RiskyUsers y UserRiskEvents (Microsoft también expone RiskyServicePrincipals, ServicePrincipalRiskEvents, RiskyAgents y AgentRiskEvents). Aterrizan en las tablas AADRiskyUsers y AADUserRiskEvents.

Qué vigilar

Detecciones de credenciales filtradas abiertas

AADUserRiskEvents
| where TimeGenerated > ago(90d)
| where RiskEventType == "leakedCredentials"
| where RiskState == "atRisk"
| project DetectedDateTime, UserPrincipalName, RiskLevel, RiskState, RiskDetail, DetectionTimingType
| order by DetectedDateTime asc

Cada fila es una cuenta cuya contraseña se sabe expuesta y que nadie ha tocado. Ordenado de más antiguo a más reciente, la parte superior de esta lista es tu peor exposición.

Cuán antiguo es el backlog en riesgo

AADRiskyUsers
| summarize arg_max(TimeGenerated, RiskState, RiskLevel, RiskDetail, RiskLastUpdatedDateTime)
    by UserPrincipalName
| where RiskState == "atRisk"
| where RiskLevel in ("high", "medium")
| extend DaysAtRisk = datetime_diff('day', now(), RiskLastUpdatedDateTime)
| project UserPrincipalName, RiskLevel, RiskDetail, RiskLastUpdatedDateTime, DaysAtRisk
| order by DaysAtRisk desc

AADRiskyUsers recibe un registro cada vez que cambia el estado de riesgo de un usuario, así que arg_max colapsa el flujo hasta el último estado conocido por usuario antes de calcular la antigüedad.

Auditar el botón de descartar

AADRiskyUsers
| where TimeGenerated > ago(90d)
| where RiskState == "dismissed" and RiskDetail == "adminDismissedAllRiskForUser"
| project TimeGenerated, UserPrincipalName, RiskLevel, RiskDetail
| order by TimeGenerated desc

El descarte es un resultado legítimo tras una investigación. También es la forma más rápida de hacer que un panel parezca saludable. Contrasta esta lista con tu sistema de tickets: un descarte sin un registro de investigación correspondiente es una decisión que nadie podrá defender más adelante.

Tiempo de cierre, por tipo de detección

AADUserRiskEvents
| where TimeGenerated > ago(90d)
| where RiskLevel == "high"
| where RiskState in ("remediated", "dismissed", "confirmedCompromised")
| extend HoursToClose = datetime_diff('hour', LastUpdatedDateTime, DetectedDateTime)
| summarize Detections = count(),
            MedianHours = percentile(HoursToClose, 50),
            P90Hours = percentile(HoursToClose, 90)
    by RiskEventType
| order by Detections desc

Esta es la métrica que hay que poner delante de la dirección. "Tenemos 40 usuarios de riesgo" invita a un encogimiento de hombros; "nuestro tiempo mediano para cerrar una credencial filtrada confirmada es de 26 días" no.

Consultar los mismos datos desde Microsoft Graph

La API riskyUsers requiere una licencia Microsoft Entra ID P2 (o Microsoft Entra Suite). Leerla necesita el permiso IdentityRiskyUser.Read.All, y para el acceso delegado el usuario que inicia sesión debe tener el rol de Lector Global, Operador de Seguridad, Lector de Seguridad o Administrador de Seguridad.

GET https://graph.microsoft.com/v1.0/identityProtection/riskyUsers?$filter=riskState eq 'atRisk' and riskLevel eq 'high'

El endpoint admite $filter y $select, con un tamaño de página máximo de 500 objetos mediante $top. La misma consulta a través del Graph PowerShell SDK:

Import-Module Microsoft.Graph.Identity.SignIns

Get-MgRiskyUser -Filter "riskState eq 'atRisk' and riskLevel eq 'high'" -All |
    Select-Object UserPrincipalName, RiskLevel, RiskState, RiskDetail, RiskLastUpdatedDateTime

Ejecútala de forma programada y genera una alerta sobre el recuento, no sobre eventos individuales. Un backlog que crece semana tras semana es el hallazgo.

Remediación: Vacía la Cola y Mantenla Vacía

1. Saber qué hace realmente cada acción

Antes de automatizar nada, asegúrate de que el equipo esté de acuerdo en lo que significa cada botón. Microsoft documenta el estado y el detalle resultantes para cada vía:

La nomenclatura resulta genuinamente confusa, y Microsoft lo señala: el detalle de riesgo "El usuario realizó un restablecimiento de contraseña seguro" es una etiqueta reportada por el sistema que indica que el usuario completó un cambio de contraseña seguro (MFA seguido de un cambio de contraseña), no un flujo de restablecimiento de contraseña autoservicio.

Nótese también la división de roles — Operador de Seguridad es el rol con menos privilegios que permite descartar el riesgo de usuario, mientras que Administrador de Usuarios es necesario para restablecer contraseñas. Restablecer una contraseña desde ID Protection requiere ambos.

2. Trabaja el backlog de credenciales filtradas una vez, a mano

Los pasos de investigación de Microsoft para esta detección son específicos, y son el runbook adecuado para vaciar la cola existente:

1. Evalúa el alcance de la exposición — revisa el historial de riesgo del usuario y los registros de inicio de sesión en busca de riesgo de inicio de sesión correlacionado (ubicaciones desconocidas, direcciones IP anónimas, viajes atípicos).
2. Comprueba si la contraseña ya se cambió tras detectarse la filtración; si es así, el riesgo puede que ya esté autorremediado.
3. Bloquea el acceso si un atacante está activo — bloquea al usuario, restablece la contraseña y revoca todos los tokens de actualización cuando los registros muestren acceso no autorizado.
4. Revisa si hay movimiento lateral — escalada de privilegios, nuevos registros de aplicaciones, cambios en reglas de buzón, acceso a recursos sensibles.
5. Verifica cuentas conectadas — si el usuario reutiliza contraseñas, trata la credencial como comprometida más allá de tu tenant.

3. Haz que "confirmar comprometido" dispare la contención

Confirmar el compromiso fija el nivel de riesgo en alto y alimenta los modelos de Microsoft, pero Microsoft enumera las acciones de contención por separado: solicitar un cambio de contraseña, bloquear al usuario si el atacante puede restablecer la contraseña o realizar MFA, revocar los tokens de actualización, deshabilitar cualquier dispositivo considerado comprometido y revocar todos los tokens de acceso si utilizas evaluación de acceso continua.

Automatiza el etiquetado para que el tiempo humano se dedique a la contención:

POST https://graph.microsoft.com/v1.0/identityProtection/riskyUsers/confirmCompromised
Content-Type: application/json

{
  "userIds": [
    "29f270bb-4d23-4f68-8a57-dc73dc0d4caf",
    "20f91ec9-d140-4d90-9cd9-f618587a1471"
  ]
}

Esta acción requiere IdentityRiskyUser.ReadWrite.All, con Administrador de Seguridad como el rol soportado con menos privilegios, y devuelve 204 No Content en caso de éxito.

4. Automatiza el estado estable con Acceso Condicional

El vaciado manual no escala. Dos políticas de acceso condicional basadas en riesgo mantienen la cola cerca de cero, y Microsoft es explícito en que deben mantenerse separadas — "no combines las condiciones de riesgo de inicio de sesión y riesgo de usuario en la misma política de acceso condicional."

• Política de riesgo de usuario: selecciona Exigir remediación de riesgo cuando el riesgo de usuario sea Alto. Elegir esta opción aplica automáticamente Exigir fortaleza de autenticación como control de concesión y Frecuencia de inicio de sesión – Cada vez como control de sesión.
• Política de riesgo de inicio de sesión: exige autenticación multifactor cuando el riesgo de inicio de sesión sea Medio o Alto, con la frecuencia de inicio de sesión configurada en cada vez.

Excluye las cuentas de acceso de emergencia y las entidades de servicio, empieza en modo solo informe y confirma el impacto antes de pasar a Activado. El recorrido completo de configuración está en Azure Identity Protection: Politicas de Riesgo — y el modo solo informe es una etapa del despliegue, no un destino, una trampa que se cubre en Acceso condicional modo solo informe, exclusiones obsoletas: qué significa realmente «aplicado». Ajusta primero correctamente la lista de exclusiones, siguiendo la guía en Cuentas de Acceso de Emergencia Break Glass Entra ID: Ausentes, Sin Supervisar, Sin Excluir, y revisa el conjunto de políticas en su totalidad frente a Brechas acceso condicional Entra ID: que errores dejan una exposicion real.

5. Corrige los prerrequisitos que bloquean la autorremediación

• Confirma que los usuarios estén registrados para MFA antes de activar la política; los usuarios no registrados quedan bloqueados en lugar de remediados. La cobertura del registro es solo la mitad de la historia — consulta Identidad Azure: MFA, metodos y Security Defaults.
• Para identidades híbridas, habilita la sincronización de hash de contraseñas y activa Permitir que el cambio de contraseña on-premises restablezca el riesgo del usuario en Protection > Identity Protection > Settings. Microsoft señala que esta opción es únicamente de activación voluntaria y recomienda asegurar el proceso de cambio de contraseña on-premises — por ejemplo, exigiendo MFA antes de un cambio on-premises.

6. Dirige las notificaciones a alguien que las lea

Verifica que los destinatarios de la alerta Se detectaron usuarios en riesgo tengan un correo electrónico o correo electrónico alternativo válido, que no dependan de roles asignados por grupo, y ten en cuenta el momento de elevación de PIM. Considera reducir el umbral de alerta por debajo del valor alto predeterminado si tu equipo tiene capacidad, y activa el resumen semanal para tener visibilidad de las tendencias.

7. Migra fuera de las políticas de riesgo heredadas

Si la aplicación de riesgo todavía vive en las políticas heredadas de ID Protection en lugar de en Acceso Condicional, migra antes del 1 de octubre de 2026: construye las políticas de acceso condicional equivalentes en modo solo informe, valídalas, actívalas y luego deshabilita las políticas antiguas en ID Protection > Dashboard.

Cómo lo Detecta EtcSec

EtcSec audita la ruta de respuesta, no solo la capa de detección.

Las comprobaciones de Risk Protection marcan RISK_LEAKED_CREDENTIALS (Credenciales Filtradas No Bloqueadas) cuando las cuentas con credenciales comprometidas confirmadas siguen activas y sin bloquear, y RISK_USERS_NOT_REMEDIATED (Usuarios de Riesgo No Remediados) cuando las cuentas marcadas como de riesgo nunca fueron remediadas ni descartadas. Ambas se califican como Críticas, porque las dos describen una cuenta que un atacante puede usar en este momento.

Junto a ellas, RISK_HIGH_RISK_USERS_ACTIVE muestra usuarios de alto riesgo cuyas cuentas permanecen habilitadas, RISK_SIGNINS_NOT_INVESTIGATED detecta inicios de sesión de riesgo sin seguimiento, y RISK_NO_AUTOMATED_RESPONSE identifica tenants donde el riesgo es visible pero no existe ninguna contención automatizada.

Para la revisión más amplia del tenant en la que se enmarcan estas comprobaciones, consulta Cómo auditar la seguridad de Microsoft Entra ID (Azure AD): guía práctica. Para las detecciones del lado del inicio de sesión que alimentan el riesgo de usuario, consulta Entra ID AiTM Token Replay: Detección de Viajes Imposibles y Fatiga MFA y Password Spraying: detección y prevención en Active Directory y Entra ID.

Referencias Principales

• What are risk detections? — Microsoft Entra ID Protection
• Risk detection types and levels
• Remediate risks and unblock users
• Investigate risk with Microsoft Entra ID Protection
• Risk policies — Microsoft Entra ID Protection
• Configure Microsoft Entra ID Protection notifications
• Export and use Microsoft Entra ID Protection data
• What is Microsoft Entra ID Protection?
• riskyUser resource type — Microsoft Graph v1.0
• riskyUser: confirmCompromised — Microsoft Graph v1.0
• List riskyUsers — Microsoft Graph v1.0
• Azure Monitor Logs reference — AADRiskyUsers
• Azure Monitor Logs reference — AADUserRiskEvents