Que cubre la seguridad de contrasenas AD?
La seguridad de contrasenas AD no se limita a la longitud minima del password del dominio. Incluye la politica de contrasenas por defecto, las Fine-Grained Password Policies, los flags inseguros a nivel de cuenta, y varios ajustes del host o del protocolo que hacen mas facil reutilizar, capturar o crackear credenciales. Esa mezcla explica por que muchos dominios siguen siendo vulnerables sin que exista una sola "gran" vulnerabilidad: basta combinar passwords debiles, cuentas que nunca rotan, WDigest habilitado, NTLMv1 permitido o credenciales escritas en atributos de directorio.
Lo importante para un equipo tecnico es distinguir entre problemas de resistencia al cracking, problemas de higiene operativa y problemas de exposicion directa de credenciales. No tienen la misma prioridad ni la misma remediacion.
Seguridad de contrasenas AD: las seis malas configuraciones que importan
1. Politica de contrasenas demasiado debil
Un dominio con minima longitud baja, historial escaso y excepciones heredadas hace mas facil password spraying, cracking offline y reutilizacion entre sistemas. La politica por defecto sigue importando incluso cuando el dominio usa FGPP, porque muchas cuentas quedan fuera de las politicas finas o nadie valida cual es la politica resultante.
2. PasswordNeverExpires
El flag no siempre es un error por si solo, pero en la practica suele marcar cuentas de servicio antiguas, cuentas administrativas olvidadas o usuarios que recibieron una excepcion permanente. Cuanto mas tiempo vive la misma credencial, mas probable es que termine reutilizada, expuesta o crackeada.
3. PASSWD_NOTREQD
Microsoft documenta PASSWD_NOTREQD como un flag de userAccountControl. En entornos sanos deberia ser excepcional. Si aparece en cuentas activas, la organizacion debe justificar inmediatamente por que existe y que control compensatorio la protege.
4. Credenciales en atributos como description
No es teoria. Muchas auditorias encuentran passwords, claves temporales o pistas de credenciales dentro de description, info u otros atributos. El problema no es solo la mala practica: es que esos datos pasan a ser visibles para multiples herramientas de inventario, backup o consulta LDAP.
5. WDigest habilitado
WDigest importa porque puede hacer que credenciales en texto claro reaparezcan en memoria de LSASS en sistemas compatibles con esa configuracion. Microsoft publico el advisory 2871997 precisamente para reducir esa exposicion. Si una organizacion reintroduce UseLogonCredential = 1, debe tratarlo como excepcion de alto riesgo.
6. NTLMv1 permitido
NTLMv1 no deberia seguir en una baseline moderna. Si un dominio o un parque de equipos todavia lo acepta, la organizacion conserva una superficie innecesaria para downgrade, cracking y abuso de autenticacion heredada.
Que debe auditar primero
| Control | Que revisar | Por que importa |
|---|---|---|
| Politica por defecto | longitud minima, historial, edad maxima, complejidad | define la baseline del dominio |
| FGPP | que grupos y usuarios reciben una politica distinta | evita creer que una cuenta fuerte esta cubierta cuando no lo esta |
| Flags de cuenta | PasswordNeverExpires, PASSWD_NOTREQD | revela deuda tecnica con impacto directo |
| Atributos expuestos | description, info y campos operativos similares | evita fuga directa de credenciales |
| Hosts y protocolo | WDigest y NTLMv1 | reduce exposicion de memoria y autenticacion heredada |
Enumeracion operativa
Politica por defecto y FGPP
Get-ADDefaultDomainPasswordPolicy
Get-ADFineGrainedPasswordPolicy -Filter *
Get-ADUserResultantPasswordPolicy -Identity usuario.ejemplo
Cuentas con flags de riesgo
Get-ADUser -Filter {PasswordNeverExpires -eq $true} -Properties PasswordNeverExpires,PasswordLastSet |
Select-Object SamAccountName,PasswordLastSet
Get-ADUser -Filter {PasswordNotRequired -eq $true} -Properties PasswordNotRequired |
Select-Object SamAccountName
Credenciales en atributos
Get-ADUser -Filter * -Properties Description |
Where-Object {$_.Description -match "pass|pwd|contrasena|clave|secret"} |
Select-Object SamAccountName,Description
WDigest y NTLMv1
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" -Name UseLogonCredential
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LmCompatibilityLevel
Deteccion y evidencia util
La telemetria no sustituye al inventario de configuracion, pero ayuda a priorizar.
- 4738 para cambios de cuenta que afectan flags o propiedades relevantes
- 4771 para pre-auth fallida, util en escenarios de password spraying
- 4624 con
LmPackageNameo patrones de autenticacion heredada cuando quiera detectar NTLMv1 o variantes antiguas - cambios de GPO o de registro que reintroducen WDigest o relajan la baseline de LAN Manager
Consulta orientativa
event.code == "4624" and winlog.event_data.LmPackageName == "NTLM V1"
El objetivo no es solo detectar abuso activo. Tambien quiere demostrar que el dominio sigue permitiendo mecanismos que deberian haber desaparecido de la baseline.
Remediacion
1. Cierre primero las exposiciones directas
Quite passwords de atributos como description, retire PASSWD_NOTREQD y deshabilite WDigest donde siga activo. Son cambios con impacto alto y valor inmediato porque eliminan rutas de abuso directas, no solo debilidad teorica.
2. Elimine autenticacion heredada innecesaria
Si todavia existe compatibilidad con NTLMv1, planifique su retirada de forma controlada, pero con fecha. La compatibilidad heredada no puede quedar indefinida ni escondida detras de un equipo antiguo sin owner.
3. Revise cuentas con PasswordNeverExpires
Separe cuentas humanas, cuentas de servicio tradicionales y cuentas que deberian migrar a gMSA u otro modelo mas seguro. El problema no se resuelve marcando todo a la vez; se resuelve sustituyendo excepciones sin owner por un modelo mantenible.
4. Endurezca la politica por defecto y valide FGPP
Set-ADDefaultDomainPasswordPolicy -Identity corp.local `
-MinPasswordLength 14 -ComplexityEnabled $true `
-MaxPasswordAge (New-TimeSpan -Days 90) -PasswordHistoryCount 24
Aplique cambios solo despues de validar la politica resultante sobre cuentas sensibles. Las FGPP mal entendidas crean una falsa sensacion de seguridad.
Casos que requieren tratamiento distinto
No todas las excepciones son iguales. Un equipo tecnico debe separar al menos tres casos:
- cuentas de servicio heredadas que aun dependen de password manual y deberian migrar a gMSA
- cuentas administrativas antiguas con
PasswordNeverExpiresporque nadie quiso romper un proceso de soporte - equipos o aplicaciones legacy que siguen exigiendo NTLMv1 o una politica mas laxa de lo aceptable
En los tres casos la pregunta correcta no es solo "como cierro el hallazgo?" sino "que dependencia operativa estoy sustituyendo y en que fecha?". Si la respuesta es difusa, la excepcion se convierte en permanente.
Validacion tecnica despues del cambio
- confirme que ninguna cuenta activa conserva
PASSWD_NOTREQDsin justificacion fuerte - revise que las cuentas con
PasswordNeverExpirestienen owner y plan de sustitucion o excepcion aprobada - compruebe que
UseLogonCredentialya no reintroduce WDigest - verifique que el nivel LAN Manager ya no acepta NTLMv1
- ejecute de nuevo el inventario de FGPP y compruebe la politica resultante sobre cuentas administrativas y de servicio
- valide que los nuevos procesos de alta de cuentas no vuelven a escribir secretos en
descriptionni en atributos operativos similares
Remediation y siguientes pasos
La remediacion eficaz de seguridad de contrasenas AD no consiste en subir una sola longitud minima y dar el tema por cerrado. El orden correcto empieza por quitar la exposicion directa de credenciales, porque ahi el atacante obtiene beneficio inmediato sin necesidad de cracking costoso. Primero limpie secretos de description y atributos equivalentes, retire PASSWD_NOTREQD, y compruebe si UseLogonCredential ha reintroducido WDigest en estaciones o servidores administrativos. En paralelo, defina una fecha de retirada para NTLMv1 y registre los sistemas o aplicaciones que aun dependan de ese protocolo.
El siguiente paso es reducir la deuda operativa acumulada en torno a PasswordNeverExpires. En lugar de tratar todas las cuentas igual, clasifique cada una en una de tres categorias: cuenta humana, cuenta de servicio heredada o identidad candidata a gMSA. Las cuentas humanas con ese flag suelen indicar excepciones sin revision. Las cuentas de servicio heredadas requieren una hoja de ruta de sustitucion. Y las identidades que pueden migrar a gMSA deben entrar en ese proyecto cuanto antes, porque la rotacion automatica elimina gran parte del riesgo estructural.
Orden de despliegue recomendado
- Exposiciones directas: secretos en atributos, WDigest y
PASSWD_NOTREQD. - Compatibilidad heredada: inventario y retirada de NTLMv1.
- Excepciones de ciclo de vida: cuentas con
PasswordNeverExpires. - Baseline duradera: politica por defecto, FGPP y validacion de politica resultante.
- Sustitucion estructural: migracion de cuentas de servicio a gMSA cuando aplique.
Este orden funciona porque reduce primero lo mas facil de explotar y deja para despues los cambios que requieren coordinacion con aplicaciones o equipos de infraestructura.
Como validar la politica resultante en cuentas criticas
Muchos equipos endurecen la politica por defecto y asumen que el problema esta resuelto. En AD eso es insuficiente si nadie comprueba la politica resultante sobre las cuentas que mas importan. Una cuenta administrativa puede seguir bajo una FGPP distinta, una cuenta de servicio puede quedar fuera de la politica prevista, y una cuenta de emergencia puede conservar una excepcion heredada sin que el equipo de identidad lo detecte.
La validacion minima deberia incluir tres grupos: administradores, cuentas de servicio y cuentas break-glass. Para cada grupo, confirme que la politica resultante coincide con el diseno esperado y que no existe una FGPP antigua asignada a un grupo olvidado. Si el dominio usa varias politicas finas, exporte el inventario completo y revise que cada objeto privilegiado tenga owner, justificacion y fecha de revision.
Get-ADUserResultantPasswordPolicy -Identity admin.ejemplo
Get-ADUserResultantPasswordPolicy -Identity svc.ejemplo
La pregunta tecnica correcta no es solo "que politica configure?" sino "que politica recibe realmente la cuenta que protege un servicio critico o privilegios altos?". Ese paso evita cerrar el hallazgo en papel mientras la excepcion sigue viva en produccion.
Errores comunes al endurecer passwords en AD
El error mas frecuente es subir la longitud minima y la complejidad sin limpiar primero el inventario de cuentas, servicios y dependencias. Eso genera tickets, rompe tareas programadas y termina creando nuevas excepciones permanentes. Otro error habitual es retirar PasswordNeverExpires de golpe sin saber que aplicaciones siguen usando un password manual guardado en scripts, servicios Windows o conectores.
Tambien es comun marcar una migracion a gMSA como "hecha" cuando solo cubre una parte pequena de las cuentas de servicio. Si aun existen servicios con SPN y password manual, la exposicion sigue presente. Lo mismo ocurre con NTLMv1: cambiar la baseline sin validar logs, sistemas legacy y excepciones reales suele provocar rollback rapido y deja al dominio exactamente en el mismo punto.
La forma profesional de cerrar este tipo de hallazgo es combinar hardening con validacion operativa: inventario, responsables, pruebas de servicio, telemetria posterior y revisiones periodicas. Sin ese ciclo, la deuda de passwords en AD vuelve aunque la politica se vea bien en el dashboard.
Referencias primarias
- Microsoft Learn: Fine-grained password policies for Active Directory Domain Services
- Microsoft Learn:
Get-ADDefaultDomainPasswordPolicy - Microsoft Learn:
userAccountControlaccount property flags - Microsoft Security Advisory 2871997
- Microsoft Learn: Enable NTLM 2 authentication and LAN Manager authentication level
- Microsoft Learn: secure group managed service accounts
Lecturas relacionadas
- Kerberoasting: riesgo en cuentas de servicio
- Cuentas obsoletas y sobreprivilegiadas: el riesgo oculto en AD
- Supervision de seguridad AD: los eventos que realmente importan
- Ataques NTLM Relay: deteccion y prevencion
- AS-REP Roasting: hashes sin credenciales
- Anidamiento de grupos AD: rutas ocultas a Domain Admin
Lea este articulo junto con el inventario de cuentas de servicio, FGPP y controles heredados del dominio. En seguridad de contrasenas AD, las peores exposiciones suelen sobrevivir porque nadie las mira como una sola familia de riesgo.
