Active Directory : lo que debe saber sobre la seguridad de las contraseñas
Table of Contents
I. Presentación
Para muchas organizaciones, Active Directory (AD) es el núcleo de la gestión de identidades en su entorno Windows. Almacena la información de autenticación de los usuarios, incluidas las contraseñas, lo que constituye un activo valioso. Para garantizar su seguridad, Active Directory utiliza mecanismos específicos y funciones hash para evitar almacenar las contraseñas en texto claro.
El objetivo de este artículo es explicar cómo se almacenan las contraseñas en la base de datos AD y cuáles son los riesgos de seguridad. También presentaremos una solución gratuita para identificar los puntos débiles de las contraseñas.
II. ¿Cómo almacena Active Directory las contraseñas?
La base de datos de Active Directory se encuentra en el archivo NTDS.dit
, almacenado por defecto en el C:WindowsntdsNTDS.dit
. Su estructura se basa en un conjunto de tablas diseñadas para almacenar información del Directorio Activo. Algunas de estas tablas almacenan información sobre objetos (usuarios, ordenadores, grupos, etc.), mientras que otras almacenan información sobre los vínculos entre estos objetos, así como los descriptores de seguridad de los objetos, conocidos como ACE (Access Control Entries).
Este famoso NTDS.dit
también almacena datos sensibles: las huellas criptográficas de las contraseñas, es decir, el hash de la contraseña. Esto significa que las contraseñas de los usuarios no se almacenan sin cifrar en Active Directory.
Un algoritmo hash calculará el hash de una contraseña antes de guardarla en la base de datos. Se trata de un mecanismo de "función unidireccional" (OWF) descrito en la documentación de Microsoft de la siguiente manera: " Una "función unidireccional" es un término utilizado para describir una transformación matemática unidireccional de datos. Los datos transformados sólo pueden convertirse mediante cifrado en una dirección y no pueden invertirse. "
Sobre el papel, un hash de contraseña puede parecer indescifrable, pero no es tan sencillo. Si un atacante consigue robar un hash, puede intentar 'crackearlo' para obtener la contraseña en texto claro. Existen varios métodos conocidos, desde el simple ataque de fuerza bruta hasta el método basado en tablas Rainbow. Por eso es importante la elección del algoritmo. Algunos son más robustos que otros. El desarrollo de las máquinas, y la potencia de cálculo asociada, pone en peligro la robustez de ciertos algoritmos (MD4, MD5, LM, por ejemplo).
Active Directory utiliza las dos funciones hash siguientes:
- LM Hash (LAN Manager Hash)
- NT Hash (vinculado a NTLM)
Nota: Las contraseñas de Active Directory no están saladas. El salado consiste en añadir una parte aleatoria a una contraseña antes de enviarla a la función hash. Esto aumenta la resistencia a ciertos ataques, en particular a los ataques de fuerza bruta.
A. El método LM Hash
El formato LM es el más antiguo y se considera obsoleto desde hace casi 20 años. LM Hash es único porque solo admite 14 caracteres. Estas son las principales etapas del mecanismo utilizado:
- Si la contraseña tiene menos de 14 caracteres, una acción de relleno completa la cadena para que sea igual a 14 caracteres (NULL).
- Convierte toda la contraseña a mayúsculas (no distingue mayúsculas de minúsculas)
- Divide la contraseña en dos bloques de 7 caracteres.
- Utiliza DES (Data Encryption Standard) para cifrar cada bloque, que luego se ensamblan.
Nota: si la contraseña tiene más de 15 caracteres, el valor generado estará incompleto y no podrá utilizarse para autenticar al usuario.
Debes saber que la generación de Hash LM está desactivada por defecto desde Windows Vista y Windows Server 2008. Microsoft también ofrece una configuración de directiva de grupo (GPO) para forzar su desactivación. Esto puede ser útil en entornos en los que el historial hace que la configuración siga activa (por motivos de compatibilidad con versiones anteriores).
Puede configurar esta opción desde el Editor de directivas de grupo. Se encuentra en la siguiente ubicación : Configuración del equipo > Directivas > Configuración de Windows> Configuración de seguridad > Directivas locales > Opción de seguridad.

Este parámetro se llama "Seguridad de red: no almacenar valores hash de nivel de LAN Manager en el siguiente cambio de contraseña". Debe definir este parámetro y activarlo. Recuerde que este ya es el comportamiento por defecto con Windows Server 2008 y versiones más recientes.

Tenga en cuenta que esta configuración de directiva de grupo no está disponible en Windows Server 2025. Esto no es ninguna sorpresa, ya que Microsoft ha mejorado la seguridad en esta área en Windows Server 2025. De hecho, esta frase en el sitio de Microsoft sirve de transición para el resto de este artículo: "NTLMv1 ha sido eliminado en Windows Server 2025, todas las demás versiones de NTLM, incluyendo LANMAN y NTLMv2, ya no están bajo desarrollo activo de características y no se recomiendan."
B. El método NT Hash
En los años 90, Microsoft introdujo en Windows un nuevo formato para proteger las contraseñas: NT (New Technology). Esto se remonta a los días de Windows NT, por lo que la elección de este nombre probablemente no sea una coincidencia. Active Directory sigue utilizando este método para almacenar las contraseñas en Active Directory. Por cierto, el hash NT está vinculado a un protocolo de autenticación con el que probablemente estés familiarizado: NTLM, cuya versión 1 está totalmente desaconsejada.
NT Hash se obtiene utilizando el algoritmo MD4, que se utiliza para hash de contraseñas, en lugar del algoritmo DES utilizado por LM. También hay otras diferencias notables:
- Longitud de la contraseña: puede gestionar contraseñas de hasta 256 caracteres, pero hay un límite de 127 caracteres en la consola de administración de AD.
- Distingue entre mayúsculas y minúsculas: a diferencia de LM Hash, NT Hash distingue entre mayúsculas y minúsculas, lo que aumenta la seguridad del hash.
- Hash único: la contraseña se somete a hash en una sola operación, sin dividirla en dos bloques.
El hash NT de una contraseña se almacena en la base de datos de Active Directory y representa datos sensibles.
III. Cifrado reversible de contraseñas
A. La opción "Guardar contraseña mediante cifrado reversible".
Ahora vamos a ver una opción presente en todos los objetos AD pertenecientes a la clase usuario (user), que representa un riesgo para la seguridad.
Las cuentas en riesgo son aquellas en las que la opción "Guardar contraseña utilizando cifrado reversible" está activada en las opciones de la cuenta. Activar esta opción ofrece la posibilidad de recuperar la contraseña en texto claro, lo que no respeta el mecanismo de "función unidireccional" mencionado anteriormente. Sin embargo, si marcas esta opción en una cuenta, el efecto no es inmediato: será la próxima contraseña del usuario en cuestión la que se almacenará de forma reversible.

Nota: esta noción también es accesible al crear una política de contraseñas refinada y se titula "Almacenar la contraseña mediante cifrado reversible". La opción se aplica entonces a todas las cuentas a las que se aplica la política de contraseñas.
Cuando se active esta opción, repercutirá en el atributo ms-DS-User-Encrypted-Text-Password-Allowed
. No tiene sentido buscarlo con el editor de atributos o navegando por el esquema de Active Directory: ¡no lo encontrará! La documentación de Microsoft indica que el estado de este atributo es visible a través del atributo UserAccountControl
.
Por lo tanto, con Active Directory, este atributo no es visible en la lista de atributos del esquema. En cambio, es visible en ADAM (Active Directory Application Mode), una versión de Active Directory diseñada exclusivamente para aplicaciones (para desempeñar únicamente el papel de directorio LDAP, sin la capa de autenticación). Piense en ADAM como un antepasado del rol ADLDS.
Ejecutando un script de PowerShell (que puedes encontrar en el artículo citado anteriormente), puedes 'convertir' el valor de UserAccountControl y mostrar las banderas activas. En el caso del usuario para el que previamente se habilitó la opción, podemos ver la presencia del flag denominado ENCRYPTED_TEXT_PWD_ALLOWED
. Demuestra que la opción ha sido marcada en la configuración de la cuenta y que esto tiene un impacto directo en el valor del atributo. UserAccountControl
.

Usando PowerShell, puedes listar todas las cuentas de Active Directory donde la opción "Guardar contraseña usando encriptación reversible" está marcada:
Get-ADUser -filter {AllowReversiblePasswordEncryption -eq $True} -Properties "AllowReversiblePasswordEncryption"
B. Lectura de una contraseña almacenada en texto claro en AD
Cuando esta opción está marcada, es posible recuperar las contraseñas de AD en texto claro, sin tener que pasar por la etapa de "descifrado de contraseñas" de la que hablaremos más adelante en este artículo. Una técnica consiste en explotar el ataque DCSync utilizando una herramienta como Mimikatz o Impacket.
Puede leer nuestros artículos sobre el ataque DCSync para obtener más información:
- Active Directory: ¿qué es el ataque DCSync?
- Active Directory: ¿cómo detectar la explotación de DCSync dentro de un dominio?
Utilizando Mimikatz como ejemplo, el siguiente comando se puede utilizar para obtener la contraseña en texto claro de un usuario específico.
mimikatz # lsadump::dcsync /domain:it-connect.local /user:florian.burnel
El resultado en imágenes:

Lo mismo se aplica al uso de secretsdump
de Impacket :
impacket-secretsdump -just-dc IT-CONNECT.LOCAL/<VULNERABLE_DCSYNC_ACCOUNT>@192.168.14.201
El resultado en imágenes:

Por último, el cmdlet Get-ADReplAccount
del módulo DSInternals también nos ayudará a lograr nuestro objetivo. Debe tener autorizaciones similares a las del ataque DCSync.
Get-ADReplAccount -SamAccountName florian.burnel -Domain it-connect -Server SRV-ADDS-01
El resultado en imágenes:

Como puede ver, gracias a la opción "Guardar contraseña mediante cifrado reversible", es posible recuperar la contraseña directamente. Sin embargo, hay que tener en cuenta una serie de requisitos previos antes de poder hacerlo, en particular el ataque DCSync, que requiere una serie de requisitos previos.
IV. Extracción de hashes de contraseñas de Active Directory
Advertencia - Lo que sigue sólo tiene fines informativos y educativos, y sólo debe aplicarse en un contexto en el que se disponga de las autorizaciones necesarias.
Existen varias herramientas para extraer los hashes de las contraseñas almacenadas en la base de datos de Active Directory. El primer paso es hacer una copia de la base de datos ntds.dit para extraer la información. El problema es que no se puede simplemente copiar y pegar este archivo en un controlador de dominio en línea, ya que está protegido.
Existen varios métodos más o menos ruidosos, según el contexto. Entre ellos se encuentran las herramientas nativas ntdsutil
, vssadmin
y DiskShadow
(añadiendo el herramienta reg
). También existe una herramienta ofensiva llamada Invoke-NinjaCopy
que es un script de PowerShell.
Por ejemplo, el siguiente comando (que en realidad es una secuencia de comandos) se utiliza para exportar información guardando los datos. La opción ifm
se refiere a la creación de soporte para la instalación de un controlador de dominio desde un medio USB (IFM).
ntdsutil "activate instance ntds" "ifm" "create full C:\Temp\NTDS" quit quit
Además de crear una copia de la base de datos ntds.dit
, también es necesario exportar la colmena del Registro correspondiente a la ruta "C:\Windows\system32\config\SYSTEM
", ya que contiene la clave para descifrar la base de datos del directorio.
En segundo lugar, los hashes de contraseñas pueden leerse utilizando varias herramientas. Un ejemplo es el módulo DSInternals de PowerShell. He aquí un ejemplo:
# Charger la clé
$BootKey = Get-BootKey -SystemHivePath "C:\TEMP\NTDS\registry\SYSTEM"
# Lister les informations sur tous les comptes Active Directory
Get-ADDBAccount -All -DBPath "C:\TEMP\NTDS\Active Directory\ntds.dit" -BootKey $BootKey
A continuación, es posible dirigirse a una cuenta específica, por ejemplo, la cuenta Administrateur
del dominio.
Get-ADDBAccount -DistinguishedName "CN=Administrateur,CN=Users,DC=it-connect,DC=local" -DBPath "c:\temp\NTDS\Active Directory\ntds.dit" -BootKey $BootKey
Si observamos detenidamente la información devuelta por el comando, podemos ver el valor NTHash
: 2b391dfc6690cc38547d74b8bd8a5b49
! El LMHash
está vacío, lo que es coherente con un entorno que ejecuta Windows Server 2025.

También es posible obtener una lista compacta con sólo los nombres de las cuentas y el HashNT
. Así que podemos ver algo interesante (y preocupante en producción): ¡las cuentas Administrateur
y florian.burnel
tienen la misma contraseña! El hash es idéntico entre estas dos cuentas, y en ausencia de salting, necesariamente tenemos el mismo valor.

Este valor puede ser utilizado por otras herramientas para intentar descifrar la contraseña. Esto refuerza la idea de que es esencial utilizar contraseñas seguras, para que sean muy difíciles de descifrar.
Se puede utilizar una herramienta como Hashcat para realizar ataques de fuerza bruta o de diccionario sobre el NTHash obtenido previamente. El ejemplo siguiente se basa en el uso de un diccionario de contraseñas representado por el fichero passwords.txt
mientras que el valor a romper está presente en el archivo llamado hashes.txt
. Cada vez que haya un resultado positivo, se añadirá al archivo de salida cracked.txt
.
hashcat -m 1000 -a 0 -o cracked.txt hashes.txt passwords.txt
La opción -m
se utiliza para especificar el tipo de hash: el valor 1000
corresponde a NTLM. La opción -a 0
se utiliza para especificar que se trata de un ataque basado en un archivo de diccionario. Unos segundos después, Hashcat ha completado su análisis y podemos ver que ¡ha conseguido descifrar la contraseña! Así pues, el administrador del dominio utiliza la contraseña P@ssword!
!
2b391dfc6690cc38547d74b8bd8a5b49:P@ssword!
Este es un caso muy simple con una contraseña inaceptable en producción. No obstante, muestra los riesgos asociados al uso de contraseñas débiles y, potencialmente, al uso de contraseñas comprometidas.
V. Auditoría de contraseñas de Active Directory
Cuando se trata de auditar las contraseñas de Active Directory, hay una herramienta gratuita que viene inmediatamente a la mente: Specops Password Auditor. No es la única herramienta de este tipo, pero tiene la ventaja de ser accesible a través de una interfaz gráfica y, sobre todo, de generar un informe listo para usar en francés.
Este programa analizará en particular los siguientes puntos:
- Cumplimiento de las políticas de contraseñas (ANSSI, CNIL, NIST, BSI, etc.)
- Cuentas con contraseñas vacías
- Cuentas con contraseñas filtradas (contraseñas comprometidas)
- Cuentas con contraseñas idénticas
- Cuentas de administrador de dominio
- Cuentas de administrador no protegidas contra la delegación
- Cuentas de administrador y de usuario inactivas
- Cuentas que no requieren contraseña
- Cuentas cuya contraseña no caduca nunca
- Cuentas cuya contraseña caduca
- Cuentas cuya contraseña ha caducado
- La antigüedad de la contraseña para cada cuenta de usuario/administrador
- Lista de políticas de contraseñas con características clave (incluida la entropía)
- Uso / asignación de políticas de contraseñas
Este software gratuito se basa en una base de datos de contraseñas comprometida localmente que contiene más de 1.000 millones de contraseñas. Para ir más allá en el análisis, es necesario pasar a Specops Password Policy, una solución de pago con más funciones y una base de datos que contiene más de 4.000 millones de contraseñas.

Encontrará nuestro artículo de presentación completo en esta página (y nuestro vídeo en YouTube).
VI. Conclusión
Como hemos visto, Active Directory utiliza varios algoritmos para hacer hash de las contraseñas. El hash NT es el único que encontramos en entornos recientes, pero no está exento de fallos.
Este artículo destaca dos recomendaciones clave:
- No utilice la opción "Guardar contraseña mediante cifrado reversible" en las cuentas de usuario (¡realice auditorías con regularidad!).
- Utilice contraseñas seguras para las cuentas de usuario, para protegerse de los ataques dirigidos a NT Hash (y LM Hash).