Almacenamiento de hashes LM desactivado en Active Directory

Verificar que el almacenamiento de hashes LM está desactivado en Active Directory plantea dos preguntas distintas: ¿Windows está configurado para dejar de crear hashes LM de las contraseñas y han cambiado las contraseñas pertinentes desde que esa configuración entró en vigor? Una directiva de contraseñas más estricta o un ajuste de red NTLMv2, por sí solos, no pueden responder a ambas preguntas.

Esta guía explica el control de almacenamiento de Microsoft, tres comprobaciones de configuración documentadas y un plan de corrección por etapas. También expone expresamente una limitación del producto: la comprobación de EtcSec llamada ANSSI_R23_LM_HASH_NOT_DISABLED evalúa LmCompatibilityLevel, no NoLMHash. Su resultado no es un inventario de secretos LM almacenados.

Almacenamiento de hashes LM en Active Directory: qué significa desactivarlo

Microsoft distingue dos representaciones de las contraseñas: el antiguo hash LM y el hash NT. Pueden residir en la base de datos local Security Accounts Manager (SAM) o en Active Directory. La representación LM es más débil y más vulnerable a la recuperación de contraseñas sin conexión. La KB 299656 de Microsoft sobre cómo evitar el almacenamiento de hashes LM describe la generación histórica de datos LM para contraseñas de menos de 15 caracteres.

Esa descripción histórica no demuestra que todas las instalaciones actuales de Windows creen hashes LM para contraseñas cortas. La referencia de Microsoft de la directiva de almacenamiento enumera valores predeterminados efectivos habilitados para los roles del sistema en su tabla, mientras que las entradas de las GPO predeterminadas del dominio y de los controladores de dominio no están definidas. Son valores predeterminados documentados, no observaciones de su dominio.

La directiva de almacenamiento actúa cuando cambia una contraseña. Por tanto, una cuenta cuya contraseña es anterior al despliegue efectivo debe incluirse en una lista de revisión. Se trata de una inferencia condicional basada en el momento de aplicación de la directiva: la contraseña antigua podría haber evitado ya datos LM utilizables gracias a su longitud, a una configuración previa o al comportamiento del sistema operativo. La antigüedad de la contraseña no demuestra por sí sola ni su presencia ni su ausencia.

Este artículo se centra en el almacenamiento LM y la renovación. Los demás indicadores de contraseñas y las dependencias de servicios se tratan en Seguridad de contraseñas en Active Directory e higiene de cuentas de servicio. Utilice esa guía para la revisión general de las cuentas; mantenga aquí una decisión de cierre independiente para la cuestión del almacenamiento.

Cómo funciona: los hashes almacenados y las respuestas de red son controles distintos

El procedimiento de almacenamiento de Microsoft documenta NoLMHash como un DWORD establecido en 1 bajo HKLM\SYSTEM\CurrentControlSet\Control\Lsa para Windows XP y Windows Server 2003. Su procedimiento para Windows 2000 SP2 y posteriores utiliza una clave en su lugar. Estos procedimientos históricos del registro requieren reiniciar y difieren en el tratamiento del historial de contraseñas; no generalice sus detalles de purga entre versiones. La KB 299656 también describe que las contraseñas de al menos 15 caracteres producen un valor LM inutilizable para la autenticación. Aumentar la longitud mínima de una directiva no demuestra que se haya renovado una contraseña antigua. Consulte los métodos de Microsoft específicos de cada versión.

El valor independiente LmCompatibilityLevel controla el comportamiento de la autenticación de red. La siguiente tabla parafrasea la referencia de Microsoft del nivel de autenticación de LAN Manager. Aquí, NTLMv1 designa la variante heredada de NTLM en la tabla de Microsoft.

El nivel 3 cambia las respuestas del cliente sin imponer el rechazo del servidor del nivel 5. El nivel 5 sigue permitiendo NTLMv2 y no borra los secretos de las bases de datos. Trate el endurecimiento de red y la supresión del almacenamiento como tareas independientes.

Guía relacionada de ANSSI: Recommandations relatives à l'administration sécurisée des systèmes d'information reposant sur Microsoft Active Directory. El control de almacenamiento LM descrito aquí está documentado por Microsoft.

Detección: recopilar pruebas de configuración y renovación

Los comandos siguientes son ejemplos adaptados de la documentación de Microsoft. No se ejecutaron en un entorno Active Directory de un cliente. Ejecute cada medida por separado en el sistema Windows pertinente y conserve su identidad, marca de tiempo, salida y cualquier error.

1. Examinar el valor del control de almacenamiento

Este comando combina la sintaxis reg query de Microsoft con la ruta y el valor de la KB 299656:

reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v NoLMHash

Busque el valor DWORD documentado 0x1 donde sea aplicable el procedimiento DWORD. La consulta lee la configuración local, no los datos de contraseñas de SAM o AD. Un valor ausente o una consulta fallida requiere interpretación según el sistema operativo y la directiva efectiva. No demuestra que exista un hash LM. Microsoft documenta el código de retorno 0 para una consulta correcta del registro y 1 para un fallo.

2. Examinar por separado el valor del control de red

Este comando utiliza la misma sintaxis de consulta y la ubicación en el registro de la directiva de autenticación:

reg query HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v LmCompatibilityLevel

Regístrelo en un campo distinto de NoLMHash. Un valor de red de 0x5 no demuestra la supresión del almacenamiento ni la renovación de contraseñas. Mantener separadas ambas lecturas también facilita investigar un resultado inesperado del colector.

3. Generar el informe de directivas del equipo

La referencia de Microsoft de gpresult documenta el ámbito de equipo y la salida HTML:

gpresult /scope computer /h lm-policy.html

Examine el informe de directivas del equipo resultante junto con las lecturas del registro. Microsoft documenta un requisito de SysWow64 para los informes HTML en ARM64 y requisitos de firewall para los informes remotos. El ejemplo local anterior evita los parámetros de destino remoto. Un informe de directivas aporta contexto de configuración; no examina hashes almacenados.

Elaborar una lista de candidatos sin exagerar el alcance de la señal

Compare las fechas de renovación de contraseñas de las cuentas con las fechas verificadas de despliegue de la directiva de almacenamiento. Cuando las fechas de despliegue efectivo difieran, conserve esa incertidumbre en lugar de asignar una única fecha conveniente para todo el dominio. Esta comparación es un método de revisión inferido del comportamiento en el siguiente cambio, no un detector directo de LM ni un hallazgo medido en su entorno.

Corrección: desactivar el almacenamiento y renovar las contraseñas pertinentes (Remediation)

1. Identificar dependencias y asignar responsables

Antes de cambiar nada, cree una lista acotada de DC, versiones de Windows aplicables y cuentas que deben revisarse. Añada los sistemas pertinentes de cuentas locales si el almacenamiento SAM local forma parte de la misión. Nombre un responsable para cada cambio de cuenta de servicio y otro para comprobar la distribución de la directiva.

Las referencias de Microsoft sobre almacenamiento y autenticación describen efectos de compatibilidad para clientes antiguos y algunas aplicaciones. Utilice esa advertencia para planificar pruebas de las dependencias reales de su infraestructura. No demuestra que ninguna aplicación concreta siga requiriendo LM. Registre una dependencia solo después de que su responsable la haya identificado; evite convertir una preocupación no probada en una excepción permanente.

2. Habilitar la directiva de almacenamiento de Microsoft

En las opciones de seguridad del equipo, habilite "Network security: Do not store LAN Manager hash value on next password change". Microsoft la sitúa bajo la configuración del equipo, configuración de Windows, configuración de seguridad, directivas locales y opciones de seguridad. La página de la directiva de almacenamiento documenta que esta directiva no requiere reiniciar.

Si se requiere un procedimiento del registro específico de una versión, utilice las instrucciones aplicables de la KB 299656, incluidas sus indicaciones sobre la copia de seguridad del registro. Su secuencia histórica para XP/Server 2003 incluye reiniciar y después cambiar la contraseña. No mezcle esa secuencia con el comportamiento independiente de reinicio de la página de la directiva.

3. Confirmar la distribución efectiva antes de programar el cierre

Repita las tres medidas de detección en cada DC pertinente y sistema aplicable de cuentas locales. Conserve juntos el informe y las lecturas del registro. Para cada sistema, registre una fecha efectiva verificada o márquela como no resuelta.

No utilice la presencia de una única GPO conforme como criterio de aceptación del despliegue. La implementación del colector descrita más adelante puede dar un resultado conforme si cualquier GPO inventariada contiene el nivel de red, sin demostrar cobertura. Por tanto, el registro de corrección debe identificar qué sistemas se comprobaron directamente y cuáles siguen sin verificar.

4. Organizar la renovación de contraseñas con los responsables de los servicios

La guía de Microsoft de la directiva de almacenamiento pide que los usuarios establezcan nuevas contraseñas en su siguiente inicio de sesión en el dominio. Planifique la renovación correspondiente de las cuentas después de que el control de almacenamiento sea efectivo.

Para las cuentas que no inician sesión habitualmente, asigne una tarea deliberada de renovación en lugar de esperar un inicio de sesión ordinario del usuario. Para las cuentas de servicio, coordine los servicios dependientes, las tareas programadas y las aplicaciones a través de sus responsables. La secuencia práctica debe identificar la cuenta, preparar las actualizaciones de dependencias, realizar el cambio aprobado, probar el servicio y conservar el resultado. Es un plan operativo de despliegue, no una afirmación de que se haya realizado una rotación masiva.

Un problema relacionado del ciclo de vida se explica en Fallback Kerberos RC4 y generación de claves AES dependiente de la contraseña. La lección común para la planificación es incluir la renovación de cuentas en los proyectos de configuración. La generación de claves AES y la supresión de LM siguen siendo mecanismos distintos con requisitos de validación diferentes.

5. Tratar el endurecimiento de red como un cambio independiente

Seleccione y pruebe por separado el nivel de red LAN Manager previsto, utilizando las indicaciones de compatibilidad de Microsoft. No considere un despliegue correcto del nivel 5 como el cierre de la limpieza del almacenamiento LM.

Mantenga la negociación NTLMv1, las protecciones contra relay, la exposición de memoria WDigest y las restricciones de NTLM saliente de Tier 0 en sus líneas de trabajo existentes. Repetir esos proyectos aquí ocultaría el entregable que falta: un despliegue documentado de la directiva de almacenamiento seguido de la renovación de cuentas dentro del alcance.

Validación: cerrar la revisión con un registro de pruebas de alcance definido

Utilice un registro de cierre que un segundo administrador pueda entender sin reconstruir el proyecto a partir de conversaciones o capturas de pantalla. Lo siguiente es un formato sugerido de pruebas, no un esquema de salida de Windows ni una certificación de que se hayan examinado secretos.

Describa la conclusión al nivel que las pruebas respaldan. Por ejemplo, un registro puede demostrar que se verificó el ajuste de almacenamiento previsto en los DC enumerados y que las cuentas enumeradas se renovaron después. No debe ampliar esa afirmación a cuentas no revisadas, al historial de contraseñas de todas las versiones de Windows ni a un inventario de todos los secretos almacenados.

Repita las comprobaciones de configuración después del cambio y concilie los sistemas o cuentas pendientes. Mantenga visibles las pruebas incompletas: un DC inaccesible, un servicio no probado o una fecha de renovación desconocida deben tener un responsable y una siguiente acción.

Cómo detecta EtcSec esta situación

El código actual de etc-collector proporciona dos comprobaciones relacionadas de directivas de red. Ninguna lee NoLMHash ni inventaria secretos LM en SAM o AD. El siguiente análisis es una revisión estática del código en el commit del colector b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c; no es el resultado de un análisis de cliente.

ANSSI_R23_LM_HASH_NOT_DISABLED

A pesar de su identificador histórico y su etiqueta de catálogo orientada al almacenamiento, este detector evalúa LmCompatibilityLevel. En internal/audit/detectors/ad/compliance/anssi/anssi-r23-lm-hash-not-disabled.go:17, el bucle de las líneas 30–43 omite las directivas o ajustes nil y marca la condición como satisfecha en cuanto cualquier GPO inventariada tiene un valor definido mayor o igual a 5.

Devuelve Count = 0 cuando se cumple esa condición y Count = 1 en caso contrario, incluso si el conjunto de directivas está vacío o faltan valores. La implementación no calcula la precedencia efectiva de las GPO ni demuestra cobertura de todos los DC u OU. Además, utiliza un umbral numérico en lugar de validar el intervalo 0–5 documentado por Microsoft: un valor recogido de 6 satisfaría la comparación sin convertirse en un nivel documentado de Windows.

La condición decisiva del código es:

if p.RegistrySettings.LmCompatibilityLevel != nil &&
    *p.RegistrySettings.LmCompatibilityLevel >= 5 {
    compliant = true
    break
}

Es un extracto formateado de las líneas 35–38, no un programa independiente. Un recuento cero significa que se encontró esta condición de directiva de red en los datos suministrados. No confirma la supresión del almacenamiento, la renovación de cuentas ni un endurecimiento completo de red; el detector no comprueba los ajustes mínimos de seguridad de sesión NTLM.

NTLMV1_ALLOWED

El detector vecino en internal/audit/detectors/ad/gpo/ntlmv1-allowed.go:22 lee el mismo campo en las líneas 32–34. Las líneas 37–38 establecen Count = 1 cuando el valor seleccionado está ausente o es inferior a 5; de lo contrario, el recuento permanece en cero.

La selección difiere. La función auxiliar internal/audit/helpers/gpo_policy.go:130 busca primero un valor definido en la directiva predeterminada de DC, después en la directiva predeterminada del dominio y luego en otra directiva. Es la regla de selección de la función, no un cálculo completo de la directiva resultante de Windows.

Por tanto, estas comprobaciones pueden discrepar. En una entrada hipotética con una directiva predeterminada de DC en 3 y otra GPO en 5, la comprobación con nombre ANSSI devuelve cero mientras que NTLMV1_ALLOWED devuelve uno. El ejemplo se deriva de la lógica del código; no se observó ninguna configuración de cliente de este tipo.