🏢Active DirectoryPasswordAccountsConfig

Seguridad de contrasenas AD: malas configuraciones que siguen abriendo el dominio

La seguridad de contrasenas AD se rompe por decisiones viejas pero muy explotables: politicas flojas, flags inseguros, credenciales expuestas y protocolos heredados.

Younes AZABARPor Younes AZABAR9 min de lectura
Seguridad de contrasenas AD: malas configuraciones que siguen abriendo el dominio

¿Qué es la seguridad de contraseñas en Active Directory?

La seguridad de contraseñas en Active Directory abarca las políticas, los flags de cuenta y los ajustes de autenticación heredados que determinan cómo se crean, almacenan y reutilizan las credenciales en el dominio. Cuando estos controles son débiles, el atacante no necesita una cadena de exploits para empezar. Una contraseña débil, una cuenta de administrador que nunca expira, o una contraseña copiada en un atributo pueden ser suficientes.

Estos problemas suelen pasar desapercibidos en el día a día. Las cuentas con PasswordNeverExpires o PasswordNotRequired pueden permanecer en producción durante meses, las contraseñas copiadas en los campos de descripción son fáciles de pasar por alto, y ajustes heredados como WDigest o NTLMv1 facilitan mucho la reutilización de credenciales recuperadas.

Este artículo se centra en seis configuraciones erróneas de contraseñas de alto impacto en Active Directory y en cómo validar que las correcciones realmente eliminaron la exposición.


Cómo funciona

Active Directory aplica los controles de contraseña mediante dos mecanismos principales:

  • Default Domain Password Policy, aplicada a todo el dominio mediante Group Policy
  • Fine-Grained Password Policies (FGPP), aplicadas a usuarios o grupos específicos mediante Password Settings Objects

Las Fine-Grained Password Policies se implementan como Password Settings Objects (PSO), y su precedencia se define mediante el atributo msDS-PasswordSettingsPrecedence: un valor más bajo significa un PSO de mayor prioridad. Un PSO vinculado directamente a un usuario siempre gana; cuando se aplican varios PSO por pertenencia a un grupo, el que tiene el valor de precedencia más bajo se convierte en la política resultante, y la Default Domain Password Policy solo se aplica si ningún PSO coincide en absoluto. En la práctica, las cuentas de nivel 0 y las cuentas de servicio deberían estar bajo un PSO con un valor de precedencia bajo y una base considerablemente más estricta que la del dominio por defecto.

Si ninguna de las dos se revisa con regularidad, el resultado es previsible: contraseñas débiles o con demasiada vida útil, cuentas exentas de los controles normales y ajustes de autenticación heredados que facilitan el abuso de credenciales una vez que un atacante logra un punto de apoyo.


La cadena de ataque

Paso 1 - Enumerar cuentas débiles

Cualquier usuario autenticado del dominio puede consultar AD para encontrar cuentas con ajustes de contraseña débiles:

# Cuentas con contraseñas que nunca expiran
Get-ADUser -Filter {PasswordNeverExpires -eq $true} -Properties PasswordNeverExpires, PasswordLastSet |
    Select-Object SamAccountName, PasswordLastSet | Sort-Object PasswordLastSet

# Cuentas donde no se requiere contraseña
Get-ADUser -Filter {PasswordNotRequired -eq $true} -Properties PasswordNotRequired |
    Select-Object SamAccountName

# Cuentas con contraseña en el campo de descripción
Get-ADUser -Filter * -Properties Description |
    Where-Object {$_.Description -match "pass|pwd|mdp|mot de passe|contraseña"} |
    Select-Object SamAccountName, Description

Paso 2 - Comprobar la exposición a protocolos heredados

# Comprobar si WDigest está habilitado
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest -Name UseLogonCredential

# Comprobar el nivel de compatibilidad NTLM
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LmCompatibilityLevel
# Los valores 0-2 permiten NTLMv1; el valor 5 impone solo NTLMv2

Paso 3 - Capturar y crackear

Con WDigest habilitado, un compromiso local que alcance LSASS puede exponer directamente credenciales en texto claro:

# Ejemplo con Mimikatz cuando WDigest está habilitado
sekurlsa::wdigest

Para contraseñas débiles o con demasiada vida útil, los atacantes también pueden crackear material NTLM offline tras un volcado de hashes:

hashcat -m 1000 ntlm_hashes.txt /usr/share/wordlists/rockyou.txt

Paso 4 - Persistir mediante una higiene de contraseñas deficiente

Las cuentas con PasswordNeverExpires son objetivos de persistencia duraderos. Si la cuenta es sensible y la contraseña nunca se rota, el atacante conserva una vía de autenticación válida hasta que un administrador la restablezca explícitamente.


Detección

Event IDs de Windows

Event IDOrigenQué buscar
4723DC - SeguridadIntentos de cambio de contraseña self-service en cuentas sensibles; en cuentas de dominio, una contraseña anterior incorrecta no se registra aquí — aparece en su lugar como 4771
4724DC - SeguridadRestablecimientos administrativos de contraseña en cuentas privilegiadas
4738DC - SeguridadCambios de cuenta de usuario, como la activación de PasswordNeverExpires
4771DC - SeguridadFallos de preautenticación Kerberos que pueden indicar spraying

Señales de comportamiento

  • Cuentas con contraseñas más antiguas que su ventana de rotación aprobada
  • Cuentas habilitadas con PasswordNeverExpires o PasswordNotRequired
  • Campos de descripción que contienen cadenas similares a credenciales
  • WDigest habilitado en endpoints o servidores donde no es explícitamente necesario
  • NTLMv1 todavía negociado en entornos que deberían ser exclusivamente NTLMv2

Consulta de detección SIEM (Elastic KQL)

event.code: "4624" AND
winlog.event_data.LmPackageName: "NTLM V1"

Remediation

💡

💡 Victoria rápida: Audite primero todas las cuentas habilitadas con PasswordNeverExpires y PasswordNotRequired. Estos dos flags suelen ser la limpieza de mayor valor y más rápida de completar.

1. Aplicar una política de contraseñas de dominio robusta

Set-ADDefaultDomainPasswordPolicy -Identity corp.local `
    -MinPasswordLength 14 `
    -ComplexityEnabled $true `
    -MaxPasswordAge (New-TimeSpan -Days 90) `
    -MinPasswordAge (New-TimeSpan -Days 1) `
    -PasswordHistoryCount 24

2. Corregir las contraseñas que no expiran

Get-ADUser -Filter {PasswordNeverExpires -eq $true -and Enabled -eq $true} |
    Set-ADUser -PasswordNeverExpires $false
⚠️

⚠️ Advertencia: Revise las cuentas de servicio antes de forzar la rotación. Si la contraseña está embebida en un servicio o una tarea programada, corrija primero la dependencia o migre la carga de trabajo a una gMSA.

3. Corregir las cuentas sin contraseña requerida

Get-ADUser -Filter {PasswordNotRequired -eq $true} | ForEach-Object {
    Set-ADAccountControl -Identity $_ -PasswordNotRequired $false
}

4. Eliminar las contraseñas de los campos de descripción

Get-ADUser -Filter * -Properties Description |
    Where-Object {$_.Description -match "pass|pwd|mdp"} | ForEach-Object {
        Set-ADUser -Identity $_ -Description ""
        Write-Host "Descripción borrada para: $($_.SamAccountName)"
    }

5. Deshabilitar WDigest

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" `
    -Name UseLogonCredential -Value 0

Despliegue mediante GPO cuando sea posible: Computer Configuration > Administrative Templates > MS Security Guide > WDigest Authentication = Disabled

6. Forzar solo NTLMv2

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
    -Name LmCompatibilityLevel -Value 5

O mediante directiva: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network security: LAN Manager authentication level = Send NTLMv2 response only. Refuse LM & NTLM

7. Desplegar Microsoft Entra Password Protection (entornos híbridos)

Para dominios sincronizados con Microsoft Entra ID, Microsoft Entra Password Protection on-premises bloquea contraseñas débiles en el controlador de dominio durante los cambios y restablecimientos de contraseña — cerrando una brecha que la política de complejidad integrada no cubre: palabras de diccionario, patrones de teclado y términos propios de la organización que técnicamente cumplen las reglas de complejidad pero son fácilmente adivinables.

El despliegue tiene dos componentes: un servicio Password Protection Proxy que obtiene las listas de contraseñas prohibidas globales y personalizadas desde Microsoft Entra ID, y un DC Agent instalado en cada controlador de dominio que aplica localmente la política en caché durante los eventos de cambio y restablecimiento de contraseña. El DC Agent sigue aplicando la política desde su copia en caché incluso si se pierde temporalmente la conectividad con el proxy.

# Confirmar que el DC Agent está instalado y registrando eventos de aplicación
Get-EventLog -LogName "Microsoft-AADPasswordProtection-DCAgent/Admin" -Newest 20

Empiece en modo auditoría para establecer una línea base de cuántas contraseñas existentes se rechazarían antes de pasar a modo forzado, y añada términos propios de la organización — nombres de marca, nombres de producto, nombres en clave de proyectos internos — a la lista personalizada prohibida; la lista global por sí sola no los detectará.


Cómo detecta esto EtcSec

EtcSec audita los controles de identidad relacionados con contraseñas en cada escaneo de AD.

PASSWORD_NEVER_EXPIRES marca las cuentas habilitadas con contraseñas que no expiran y ayuda a priorizar las identidades de mayor riesgo.

PASSWORD_POLICY_WEAK evalúa la Default Domain Password Policy frente a la línea base elegida en cuanto a longitud, complejidad, historial y antigüedad.

PASSWORD_NOT_REQUIRED identifica cuentas donde el flag PASSWD_NOTREQD sigue activo.

PASSWORD_IN_DESCRIPTION analiza las descripciones del directorio en busca de cadenas similares a credenciales.

WDIGEST_ENABLED comprueba el almacenamiento en caché de credenciales en texto claro por WDigest.

NTLMV1_ALLOWED destaca entornos que todavía permiten la negociación NTLMv1.

ℹ️

ℹ️ Nota: EtcSec comprueba todo esto en cada auditoría de AD, para que pueda verificar la higiene de contraseñas y la exposición por autenticación heredada en la misma revisión.

Cuentas que requieren un tratamiento especial

No aplique la misma remediación sin distinción a todas las clases de cuentas.

  • Las cuentas de servicio a menudo se rompen si restablece una contraseña sin actualizar el servicio, la tarea programada o el pool de aplicaciones que depende de ella.
  • Las cuentas de nivel 0 o break-glass no deben conservar credenciales débiles o compartidas solo porque se usan poco; requieren un manejo más estricto, un almacenamiento más estricto y una supervisión explícita.
  • Las identidades administrativas compartidas deben eliminarse en lugar de simplemente rotarse. La rotación no resuelve el problema de rendición de cuentas.
  • Las aplicaciones heredadas que aún dependen de NTLMv1 o de un manejo débil de contraseñas necesitan una excepción con plazo definido y un plan de migración, no una exención permanente.

Cómo debería verse una buena evidencia

Una revisión de fortalecimiento de contraseñas es mucho más fácil de defender cuando el equipo conserva la evidencia exacta que demostró que la limpieza ocurrió. Entre los artefactos útiles están la exportación antes/después de las cuentas con PasswordNeverExpires, la lista de cuentas que antes tenían PasswordNotRequired, la confirmación de que WDigest está deshabilitado en sistemas representativos, y la nota de propietario o de migración para cualquier cuenta de servicio que aún necesite una excepción temporal. Esa evidencia importa porque la higiene de contraseñas tiende a degradarse mediante excepciones urgentes y atajos de aplicaciones.

Validación tras la remediación

Cierre el hallazgo solo después de volver a ejecutar los mismos pasos de descubrimiento que usaría un atacante:

  • vuelva a ejecutar los informes de PasswordNeverExpires y PasswordNotRequired y confirme que las excepciones restantes son intencionadas
  • verifique que las excepciones de cuentas de servicio están documentadas, tienen propietario y están vinculadas a un plan de migración como la adopción de gMSA
  • compruebe puntualmente sistemas representativos para confirmar que UseLogonCredential es 0 donde WDigest debería estar deshabilitado
  • valide que LmCompatibilityLevel coincide con su plan de despliegue exclusivo de NTLMv2 y que los sistemas heredados se trataron explícitamente
  • vuelva a ejecutar la búsqueda en el campo de descripción y confirme que las credenciales se eliminaron en lugar de simplemente ocultarse en otro atributo

Controles relacionados

La mala higiene de contraseñas se vuelve mucho más peligrosa cuando se combina con Kerberoasting: cómo los atacantes crackean las contraseñas de cuentas de servicio, Cuentas privilegiadas obsoletas: un riesgo oculto en Active Directory, Supervisión de Active Directory: los Event IDs de seguridad que importan, o Ataques NTLM Relay: secuestro de la autenticación en AD. Revise esos controles en la misma ventana de remediación para eliminar la vía de ataque en lugar de un solo síntoma.

Explore las páginas de identidad que apoyan este tema