Triaje AD badPwdCount: calificar contadores antes de un veredicto de ataque

Qué permite establecer el triaje AD badPwdCount

El triaje AD badPwdCount comienza con una pregunta sobre las pruebas: ¿qué controlador de dominio proporcionó el contador de esta cuenta, en qué momento y se completó realmente la recopilación? Una instantánea del directorio puede identificar cuentas que merecen investigarse. Por sí sola, no puede establecer un ataque de diccionario, identificar el origen de los fallos ni demostrar que una contraseña es débil.

El resultado práctico es un expediente de análisis que relaciona el estado del directorio con la actividad de autenticación. Conserve el hallazgo original, recopile vistas comparables de los controladores de dominio pertinentes, compruebe el estado de bloqueo calculado e investigue los registros de la ruta de autenticación implicada. Después, documente si las pruebas respaldan un error del usuario, una aplicación que reintenta con un secreto obsoleto, una actividad sospechosa o un caso sin resolver.

Esta guía utiliza lecturas defensivas del directorio y un ejemplo documentado de desbloqueo dirigido. Los comandos son adaptaciones ilustrativas para un administrador autorizado con el módulo PowerShell ActiveDirectory y los permisos adecuados. No se ejecutaron contra un dominio. No se realizó ninguna prueba de password spraying ni de bloqueo deliberado.

Qué mide realmente el contador LDAP

La referencia de Microsoft sobre atributos de seguridad de usuario describe badPwdCount como un atributo no replicado que se mantiene por separado en cada controlador de dominio. Cuenta los intentos de inicio de sesión con contraseña incorrecta desde la perspectiva de ese controlador; la referencia también indica que cero puede significar un valor desconocido. Recomienda consultar cada DC para obtener una visión de todo el dominio, en lugar de tratar una sola lectura como el total del dominio.

La referencia de esquema Bad-Pwd-Count añade que el atributo se reinicia en un DC concreto cuando el usuario inicia sesión correctamente en ese DC. Por tanto, un contador no es un historial permanente. Un valor menor en una instantánea posterior no demuestra que se hayan investigado todos los fallos anteriores.

Para el triaje, conserve las observaciones separadas de los DC antes de crear un resumen. Un número sin su servidor y hora de recopilación pierde el contexto necesario para compararlo con otra observación. Un resumen de contadores tampoco identifica intentos distintos dentro de un intervalo elegido; utilice los registros de eventos para construir esa cronología.

El bloqueo es una cuestión distinta. Microsoft documenta UF_LOCKOUT, de valor 0x0010, en msDS-User-Account-Control-Computed. Solicite explícitamente ese atributo calculado al revisar el estado actual de AD DS. No suponga que un booleano del colector llamado LockedOut procede necesariamente de él.

Detección: recopilar vistas comparables de cada DC

Identificar la cuenta y el alcance de la recopilación

Comience por el identificador de cuenta del hallazgo y el punto de conexión original del colector. Registre el dominio, el DN o GUID de la cuenta, la versión del colector, la hora de recopilación, los atributos solicitados y los errores de recopilación. Confirme la lista de DC con el inventario del dominio; el ejemplo de dos servidores siguiente no indica que deban omitirse otros DC.

La documentación de Get-ADUser permite seleccionar un usuario por DN, solicitar propiedades adicionales y especificar un servidor de directorio. Estas lecturas adaptadas utilizan un nombre de host de DC explícito en lugar de depender de la selección automática del servidor:

Get-ADUser -Identity 'CN=Alex Smith,OU=Users,DC=contoso,DC=com' -Server 'dc01.contoso.com' -Properties badPwdCount,userAccountControl,msDS-User-Account-Control-Computed,lockoutTime -ErrorAction Stop

Get-ADUser -Identity 'CN=Alex Smith,OU=Users,DC=contoso,DC=com' -Server 'dc02.contoso.com' -Properties badPwdCount,userAccountControl,msDS-User-Account-Control-Computed,lockoutTime -ErrorAction Stop

Sustituya el DN y los nombres de host ilustrativos por valores verificados. Solicitar lockoutTime conserva otro atributo bruto para el análisis; no utilice un valor distinto de cero por sí solo como veredicto de bloqueo actual. Interprete el bit de bloqueo calculado únicamente cuando su valor se haya devuelto correctamente. Un valor ausente es desconocido, no falso.

Para un inventario más amplio y autorizado, Get-ADUser también admite un filtro LDAP. Este ejemplo recupera los objetos de usuario habilitados y los atributos pertinentes de un servidor seleccionado explícitamente. Deliberadamente no limita la población a las cuentas que ya superan el umbral del producto:

Get-ADUser -LDAPFilter '(&(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))' -Server 'dc01.contoso.com' -Properties badPwdCount,userAccountControl,msDS-User-Account-Control-Computed,lockoutTime -ErrorAction Stop

Repita la lectura en los demás DC verificados dentro del alcance aprobado. Evite construir un filtro LDAP concatenando un nombre de cuenta sin escapar. Para un caso individual, las lecturas basadas en identidad evitan por completo esa interpolación.

Conservar la calidad de recopilación junto a los valores

Utilice un registro con una fila por cuenta y DC. Los siguientes campos son una recomendación operativa, no datos que el detector proporcione automáticamente:

Si un DC no está disponible, informe de la carencia y conserve las lecturas correctas. No sustituya la fila ausente por cero ni reduzca silenciosamente el alcance declarado. Si las observaciones difieren, conserve ambas e investigue su momento y procedencia antes de elegir un resumen. El objetivo es una comparación auditable, no que todas las celdas parezcan idénticas.

Detección: relacionar los eventos con la ruta de autenticación

La instantánea LDAP selecciona un objetivo de investigación; la cronología de eventos aporta el contexto de actividad. Verifique la cobertura de auditoría, el reenvío, la retención y los sistemas consultados antes de interpretar un resultado vacío. Elija el intervalo de análisis a partir de la cronología del caso y las pruebas disponibles. El contador no proporciona ese intervalo.

Microsoft asocia estos eventos respectivamente con Audit Logon/Account Lockout, Audit Kerberos Authentication Service y Audit Credential Validation. Una búsqueda limitada a los DC no cubre todas las ubicaciones de 4625. El evento 4771 está ausente para las cuentas configuradas sin exigir preautenticación Kerberos. El evento 4776 cubre tanto validaciones correctas como fallidas e identifica la estación de trabajo de origen, no el servidor de destino ni una dirección IP.

Lea el vocabulario de códigos correspondiente a cada evento. Para 4625, conserve ambos campos de estado en lugar de reducirlos a una etiqueta genérica de fallo. En 4771, 0x18 significa información de preautenticación no válida, con una contraseña incorrecta como causa documentada. En 4776, 0xC000006A indica una contraseña incorrecta o mal escrita, 0xC0000064 un nombre de usuario desconocido y 0xC0000234 una cuenta bloqueada. Un fallo causado por bloqueo constituye una prueba distinta de la actividad con contraseñas incorrectas que lo precedió.

Construya una cronología agrupada por cuenta, origen, ruta de autenticación y sistema emisor. Conserve referencias a los registros originales para que otro analista pueda revisar la conclusión. No sume todas las filas de distintos tipos de eventos para afirmar un número de intentos independientes: determine primero qué registros describen el mismo flujo de autenticación.

Amplíe la investigación más allá de la cuenta seleccionada cuando los orígenes o los tiempos lo justifiquen. El contexto de correlación entre múltiples cuentas y de baja cadencia de nuestra guía de password spraying explica esa investigación más amplia. Aquí, la primera tarea sigue siendo calificar la observación del directorio que abrió el caso.

Corrección: resolver la causa antes de cerrar el hallazgo (Remediation)

Preservar las pruebas y contrastar explicaciones alternativas

Conserve los valores LDAP iniciales y los eventos pertinentes antes de modificar las credenciales o el estado de la cuenta. Identifique al propietario de la cuenta y las aplicaciones que la utilizan. Pregunte por cambios recientes de contraseña, cambios de configuración de servicios, tareas programadas, acceso remoto y la experiencia que comunica el usuario. Utilice esas respuestas para elegir los sistemas que inspeccionar, no como sustituto de sus registros.

La siguiente matriz de decisión propone un método de triaje. Ninguna de estas explicaciones se calcula únicamente a partir de badPwdCount:

Para una carga de trabajo que usa una credencial obsoleta, coordine el cambio de credenciales con todos los consumidores conocidos. Actualizar solo una tarea programada dejando sin resolver otro cliente que reintenta no es una corrección completa. Verifique la configuración de la propia carga de trabajo y los registros de autenticación posteriores antes de atribuirle los fallos de forma concluyente.

Trate los nombres inusuales como una señal distinta. Nuestra revisión de nombres de cuentas distingue un indicador estático de nomenclatura de la actividad de inicio de sesión. Un nombre de cuenta genérico no establece qué contraseña se intentó, quién la envió ni si este caso es malicioso.

Desbloquear únicamente la cuenta revisada cuando corresponda

Si el estado calculado confirma el bloqueo y el administrador responsable ha aprobado restablecer el acceso tras revisar la causa, utilice una operación dirigida. Este ejemplo adapta los parámetros de identidad y servidor documentados para Unlock-ADAccount:

Unlock-ADAccount -Identity 'CN=Alex Smith,OU=Users,DC=contoso,DC=com' -Server 'dc01.contoso.com' -Confirm

Este es un ejemplo que cambia el estado, no un comando ejecutado para este artículo. Confirme la identidad y el servidor antes de usarlo. No canalice todo el inventario a un desbloqueo masivo. Un desbloqueo no corrige un secreto de aplicación obsoleto ni resuelve una actividad sospechosa; utilice las pruebas para elegir la respuesta adecuada.

Cuando la investigación establezca una vulneración o una amenaza persistente, siga el procedimiento de respuesta a incidentes de la organización para la contención, los cambios de credenciales y los sistemas afectados. Un contador de directorio no basta para seleccionar esas acciones automáticamente. Tampoco relaje los controles de bloqueo solo para reducir los hallazgos sin revisar sus consecuencias para la seguridad y la disponibilidad.

Verificar la corrección y documentar la conclusión

Repita las mismas lecturas del directorio con la misma identidad de cuenta y los mismos DC explícitos después del cambio aprobado. Conserve de nuevo las marcas de tiempo y la calidad de recopilación. Revise los registros pertinentes durante un período de observación declarado y pida al propietario que confirme que la aplicación o el flujo de trabajo del usuario afectado funciona según lo previsto.

Cierre el caso con una afirmación respaldada: se corrigió una aplicación identificada que reintentaba; se resolvió un problema de acceso del usuario; se escaló actividad como sospechosa; o la cobertura sigue incompleta. Registre las referencias de eventos que la respaldan, las explicaciones descartadas, las pruebas ausentes, las acciones, el responsable y la fecha de seguimiento. Dejar de superar el umbral del producto aporta contexto útil, pero el cierre debe explicar la causa y las pruebas que fundamentan la decisión.

Cómo detecta EtcSec este caso

La comprobación de etc-collector es PASSWORD_DICT_ATTACK_RISK, categoría Password, severidad Medium. El Detect() revisado se encuentra en public/internal/audit/detectors/ad/password/dict-attack-risk.go:24. Excluye a los usuarios con Disabled=true y selecciona cada usuario restante cuando BadPasswordCount > 3 o LockedOut=true.

Count es el número de usuarios seleccionados, no la suma de intentos fallidos, el número de sistemas de origen ni el número de ataques. Cada usuario contribuye una vez incluso cuando coinciden ambas condiciones. La implementación devuelve el hallazgo incluso con cero; las entidades afectadas se incluyen cuando se solicitan detalles y se selecciona al menos un usuario.

El proveedor de datos determina lo que la comprobación puede ver realmente:

• parser.go:164 lee badPwdCount mediante getIntAttr; esa función auxiliar, en la línea 290, devuelve cero para un valor ausente e ignora los errores de strconv.Atoi.
• client.go:460 recupera usuarios del contexto LDAP elegido. Esta ruta no agrega observaciones de todos los DC.
• parser.go:189 deriva LockedOut del bit 0x0010 de userAccountControl. La lista predeterminada de atributos de usuario no solicita msDS-User-Account-Control-Computed. Aunque se recopila lockoutTime, no se utiliza para calcular este booleano.

Por tanto, esa rama de bloqueo no debe presentarse como una evaluación calculada fiable del bloqueo actual para AD DS moderno. Solicite de forma independiente el atributo calculado al realizar el triaje del hallazgo. Conserve cualquier discrepancia entre el booleano del colector y esa lectura, en lugar de tratar la etiqueta del colector como autoridad.

La comprobación no tiene ventana temporal, origen de autenticación, correlación de eventos, evaluación de la política efectiva de bloqueo ni medición de calidad de contraseña. El umbral es un predicado del producto, no un valor de política de AD DS. Tres fallos registrados o menos no demuestran seguridad, y un recuento positivo no demuestra un ataque.

Existe una razón concreta para investigar los contadores sin suponer su causa. El repositorio público SafeSpray y su código fuente main.go utilizan un filtro LDAP que contiene badPwdCount=0 para seleccionar usuarios antes de intentos de autenticación SMB. Esto demuestra cómo una herramienta pública utiliza los contadores, no que se haya ejecutado en su entorno ni que su afirmación de evitar bloqueos sea fiable. Se leyó el código; no se ejecutó la herramienta.