ADPWD-006: Política de bloqueo de cuentas
- Plataforma
- Active Directory
- Categoría
- AD Password & Lockout Policies
- Severidad
- High
- Pilar de Zero Trust
- Identity (peso 2)
- Fixtures de referencia
- 3
- Cobertura de ramas
- Observada: los fixtures prueban los veredictos que ejercitan
- Procedencia
- baseline
Qué comprueba
Las políticas de bloqueo de cuentas protegen frente a ataques de fuerza bruta en línea y de rociado de contraseñas (password spraying) al bloquear las cuentas tras un umbral de intentos fallidos. Sin bloqueo, los atacantes pueden realizar intentos ilimitados de adivinación de contraseñas contra cualquier cuenta. Sin embargo, un bloqueo demasiado agresivo crea riesgo de denegación de servicio
Por qué importa
Without account lockout, an attacker can issue an unlimited stream of Kerberos AS-REQ or NTLM authentication attempts against the domain controller and never trigger a defensive response beyond log noise. Password spraying tools (Kerbrute, DomainPasswordSpray, MailSniper, TrevorSpray) are explicitly designed for this scenario: one or two guesses per account, rotated across the full user list, repeated daily. With lockoutThreshold = 0 the only thing stopping the attack is the attacker getting bored or the defender noticing the 4625 / 4771 event volume. The blast radius is the entire domain user population, including service accounts and break-glass administrators, because lockout policy is a single, domain-wide setting and applies to every account that does not have an overriding FGPP. The opposite failure mode also matters: a threshold of 3 with a 24 hour duration is trivially weaponized into a denial of service against the workforce, where an attacker who has only an internal foothold and a username list can lock out every account in the domain in minutes (a tactic Mandiant has reported in ransomware staging).
Ruta de ataque
Stage 1, recon: the attacker enumerates valid usernames from a public source (LinkedIn scrape, leaked breach corpus, anonymous LDAP query against a domain controller if 389/TCP is reachable, or a Kerbrute user enumeration that reads KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN versus KRB5KDC_ERR_PREAUTH_REQUIRED responses). Stage 2, policy probe: the attacker either reads the domain password policy with a low-privilege account (Get-ADDefaultDomainPasswordPolicy, or net accounts /domain) or infers the lockoutThreshold empirically by burning one or two known-bad attempts against a throwaway account. Stage 3, spray: the attacker runs Kerbrute passwordspray or DomainPasswordSpray with a curated password list (Season + Year, Company + 1, Welcome + Year) at a rate just below the threshold and outside the observation window, typically one attempt per account every 30 to 60 minutes. With lockoutThreshold = 0, the attacker skips stage 2 and 3 throttling entirely and runs at line speed. Successful credentials are then used for SMB or RDP lateral movement, or for AzureAD / Entra federated authentication if Seamless SSO or PHS is configured (Nestori Syynimaa has documented this exact path against hybrid tenants).
Cómo lo evalúa Guerrilla
Guerrilla queries the domain root object via the existing AD PowerShell session, requesting lockoutThreshold, lockoutDuration, and lockOutObservationWindow. The Interval attributes are converted from Windows FILETIME ticks (negative 100-ns intervals) to TimeSpan and reported in minutes. The check then enumerates Fine-Grained Password Policy objects (objectClass = msDS-PasswordSettings) under CN=Password Settings Container and reads their msDS-LockoutThreshold, msDS-LockoutDuration, msDS-LockoutObservationWindow, and msDS-PSOAppliesTo values to surface any PSO that weakens lockout for a privileged group. Findings are graded as Fail when threshold = 0, Warn when threshold > 10 or duration < 15 minutes, and Pass when all three values fall in the recommended range. Companion telemetry (Event ID 4740 on the PDC Emulator, account lockouts) is referenced in the report so the operator can correlate any current spray activity.
Valor recomendado
Umbral de bloqueo de cuentas: 5-10 intentos. Duración del bloqueo: 15-30 minutos. Restablecer el contador tras: 15-30 minutos
Remediación
Configure el bloqueo de cuentas en la Default Domain Policy: Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout Policy. Establezca el umbral en 5-10 intentos, la duración en 15-30 minutos y la ventana de observación en 15-30 minutos. Supervise los eventos de bloqueo que puedan indicar ataques
Veredictos probados con fixtures
Cada veredicto de esta tabla está probado por un fixture de referencia en la suite de pruebas que valida el módulo. La tabla se deriva de la última ejecución en verde; no puede editarse a mano.
| Escenario | Veredicto esperado |
|---|---|
| clean | PASS |
| known-bad | FAIL |
| throttled | Not Assessed |
Mapeos a marcos de referencia
- NIST SP 800-53
- AC-7
- CIS Benchmark
- 1.2.1, 1.2.2, 1.2.3
- ANSSI
- R35
- CIS AD Benchmark
- 5.3.1
- MITRE ATT&CK
- T1110.001, T1110.003