Ajustes de seguridad GPO Active Directory: cuatro controles

¿Qué son los ajustes de seguridad GPO Active Directory?

Los ajustes de seguridad GPO Active Directory determinan cómo los clientes Windows resuelven nombres locales, confían en los metadatos de actualización, protegen LSASS y autentican el acceso a los recursos compartidos de directivas. Cuatro ajustes merecen una revisión específica: deshabilitar LLMNR, usar HTTPS para los metadatos WSUS, habilitar la protección LSA y exigir autenticación mutua e integridad para SYSVOL y NETLOGON.

Cada uno aborda un requisito previo de ataque distinto. Una conexión de actualización segura no protege la memoria de LSASS; deshabilitar LLMNR no deshabilita la resolución de nombres NetBIOS. Revise el valor de la directiva, los equipos que la reciben y la protección realmente utilizada antes de cerrar un hallazgo.

Nuestra guía de configuraciones incorrectas de GPO examina los permisos de edición delegados, los vínculos de directivas, LAPS y la gobernanza de las directivas de contraseñas. Este recorrido cubre cuatro ajustes concretos que pueden seguir siendo inseguros incluso cuando los permisos administrativos de una GPO son correctos.

Cómo funciona: cuatro directivas y sus valores de registro

Use los siguientes ajustes como objetivos de revisión. Los valores esperados describen una configuración prevista, no los resultados de una auditoría de su entorno.

1. Deshabilitar LLMNR; tratar NBT-NS por separado

Ruta de la directiva: Computer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution.

Clave de registro: HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient; valor: EnableMulticast, REG_DWORD 0. La formulación negativa de la directiva importa: Habilitado desactiva LLMNR. Microsoft documenta la correspondencia de las directivas del cliente DNS; su referencia de la línea base de Windows Server especifica el valor cero.

LLMNR proporciona resolución de nombres locales cuando la resolución DNS convencional no está disponible. Un atacante capaz de influir en ese intercambio local puede redirigir un cliente hacia un destino bajo su control e inducir la autenticación, tal como describe la entrada de MITRE ATT&CK sobre envenenamiento de la resolución de nombres. Las respuestas NTLMv2 capturadas no son contraseñas en texto claro: Microsoft documenta NTLM como un protocolo de desafío y respuesta. Retransmitir la autenticación también depende de las protecciones del servicio de destino.

NBT-NS es una exposición independiente. Microsoft documenta Win32_NetworkAdapterConfiguration.SetTcpipNetbios con TcpipNetbiosOptions=2 para deshabilitar NetBIOS sobre TCP/IP en un adaptador. Trate ese método a nivel de adaptador como una decisión de despliegue separada, con sus propias comprobaciones de compatibilidad. La directiva LLMNR y el control EtcSec correspondiente no establecen la cobertura de NetBIOS.

2. Proteger los metadatos WSUS con HTTPS

Ruta de la directiva: Computer Configuration > Administrative Templates > Windows Components > Windows Update > Specify intranet Microsoft update service location. Las plantillas de directivas de Windows 10/11 la sitúan bajo Manage updates offered from Windows Server Update Service.

Clave de registro: HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate; valores: WUServer y WUStatusServer, ambos REG_SZ. Configure la URL HTTPS del servidor desplegado en ambos campos. El valor asociado HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\UseWUServer es REG_DWORD 1 para el uso de WSUS. Estas correspondencias se documentan en los ajustes de Windows Update.

El procedimiento de configuración de WSUS de Microsoft distingue los metadatos HTTPS de la distribución de archivos por HTTP. Un atacante situado en la ruta del tráfico puede manipular información de actualización sin protección. Evalúe los clientes que realmente usan ese servidor y la ruta que puede interceptarse; no deduzca que todos los equipos unidos al dominio están comprometidos a partir de una sola URL.

3. Habilitar la protección LSA con un valor RunAsPPL compatible

Para Windows 11 22H2 y versiones posteriores, la ruta de la plantilla administrativa documentada por Microsoft es Computer Configuration > Administrative Templates > System > Local Security Authority > Configures LSASS to run as a protected process. La alternativa documentada mediante Preferencias de directiva de grupo es Computer Configuration > Preferences > Windows Settings > Registry.

Clave de registro: HKLM\SYSTEM\CurrentControlSet\Control\Lsa; valor: RunAsPPL, REG_DWORD. 1 selecciona protección con bloqueo UEFI cuando se admita; Microsoft limita la aplicación de 2, sin ese bloqueo, a Windows 11 22H2 y versiones posteriores. En dispositivos x86/x64 sin compatibilidad UEFI o con Secure Boot deshabilitado, la configuración depende del registro y no de un bloqueo del firmware. Reinicie después de la configuración. Siga el procedimiento de protección LSA de Microsoft.

Protected Process Light limita las lecturas de memoria y la inyección de código por procesos no protegidos. La ausencia de protección puede facilitar el robo de credenciales después de que un atacante obtenga el acceso necesario. Un valor de registro por sí solo no establece la protección del proceso en ejecución. Algunos clientes modernos habilitan automáticamente la protección LSA; la ausencia de un valor GPO recopilado requiere investigación, no una afirmación categórica de que LSASS está desprotegido.

4. Exigir autenticación mutua e integridad para los recursos compartidos de directivas

Ruta de la directiva: Computer Configuration > Administrative Templates > Network > Network Provider > Hardened UNC Paths.

Clave de registro: HKLM\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths. Establezca ambos nombres de valores REG_SZ, \\*\SYSVOL y \\*\NETLOGON, en RequireMutualAuthentication=1,RequireIntegrity=1. La correspondencia de las directivas Connectivity establece la ubicación de la directiva y la clave de registro; la referencia de la línea base especifica los atributos necesarios.

La autenticación mutua exige validar la identidad del servidor mediante Kerberos; la integridad exige la firma SMB. Microsoft describe el refuerzo UNC y las defensas contra la interceptación, incluido el refuerzo predeterminado de SYSVOL y NETLOGON a partir de Windows 10 y Windows Server 2016.

Nuestra guía de cPassword en SYSVOL explica por qué los secretos históricos de GPP requieren limpieza y rotación de credenciales, y ya recomienda el refuerzo UNC. Aquí, el foco está en los patrones exactos de recursos compartidos y los requisitos de conexión. Proteger el tránsito no elimina secretos almacenados ni corrige permisos de escritura excesivos.

La cadena de ataque: requisitos distintos, controles distintos

Son cuatro vías independientes, no cuatro etapas obligatorias de una sola explotación. Use esta distinción al delimitar una investigación:

Un hallazgo de configuración respalda el trabajo de refuerzo. No establece que un atacante haya capturado credenciales, alterado una actualización, volcado LSASS o cambiado una directiva en tránsito. Vincule cualquier conclusión de incidente a telemetría independiente.

Detección: medir el equipo de destino

Empiece en un destino Windows de cada ámbito de directiva pertinente. La referencia de gpresult de Microsoft documenta la salida RSoP en el ámbito de equipo:

gpresult /scope computer /r

El resumen ayuda a identificar las GPO aplicadas. Use la salida RSoP detallada al investigar ajustes en conflicto y compárela después con los valores locales y las evidencias en ejecución. Repita las comprobaciones para cada destino cuyo ámbito de directiva esté revisando.

Los siguientes comandos aplican la sintaxis reg query documentada por Microsoft a las claves anteriores respaldadas por Learn. Ejecute cada uno por separado.

Medir la configuración LLMNR

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" /v EnableMulticast

Se espera REG_DWORD 0. Si el valor falta o es distinto, concilie el resultado de directiva del destino antes de decidir que el despliegue ha tenido éxito. Revise los destinos inesperados de resolución de nombres locales como una señal de investigación. La referencia de alertas de Defender for Identity de Microsoft reconoce la familia de técnicas de envenenamiento LLMNR/NBT-NS y retransmisión SMB; no establece un Event ID de Windows universal para este control.

Medir la configuración WSUS

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /s

Revise juntos WUServer, WUStatusServer y la entrada AU\UseWUServer. Compare las URL con el FQDN y el puerto HTTPS previstos, valide la confianza en el certificado y confirme que los clientes buscan actualizaciones correctamente. Una cadena HTTPS por sí sola no valida IIS, la gestión de certificados ni el uso real por los clientes. Las fuentes utilizadas aquí no establecen ningún Event ID específico de ataque WSUS.

Medir la configuración y el inicio de LSA

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v RunAsPPL

Para confirmar el estado en ejecución, inspeccione System / WinInit / Event 12 después del reinicio. Registra el inicio protegido de LSASS. La referencia de wevtutil documenta la consulta de eventos; este ejemplo selecciona registros Event 12 para inspección:

wevtutil qe System /q:"*[System[(EventID=12)]]" /rd:true /f:text /c:10

Confirme que el proveedor sea WinInit y que el mensaje se refiera al inicio protegido de LSASS. El filtro selecciona por ID, por lo que pueden aparecer proveedores sin relación. En CodeIntegrity/Operational, el evento de auditoría 3065 se refiere a los requisitos de secciones compartidas y 3066 a los requisitos del nivel de firma de Microsoft; la imagen sigue pudiendo cargarse en modo auditoría. Bajo protección, 3033 identifica fallos del nivel de firma y 3063 fallos de secciones compartidas. Estos eventos no demuestran un volcado de credenciales exitoso. La ausencia de evidencias de inicio conservadas, por sí sola, no demuestra que la protección esté deshabilitada.

Medir la configuración UNC

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths"

Inspeccione ambos patrones de recursos compartidos y los atributos necesarios. Cuando falten entradas, tenga en cuenta los valores predeterminados del sistema operativo antes de clasificar la exposición. Valide el acceso a los destinos SYSVOL y NETLOGON reales y sus garantías de autenticación e integridad. Aquí no se establece ningún Event ID específico de suplantación UNC.

Corrección: desplegar y verificar cada control (Remediation)

Paso 1: deshabilitar LLMNR en un ámbito piloto

Habilite la directiva del cliente DNS descrita anteriormente. Vuelva a ejecutar la consulta de registro de LLMNR y concilie las directivas aplicadas al equipo. Compruebe que las aplicaciones que usan nombres locales sigan resolviendo los destinos previstos. Si NetBIOS sigue siendo necesario, registre esa dependencia por separado; si puede deshabilitarse, gestione el método documentado del adaptador por separado del ajuste del cliente DNS.

Paso 2: configurar TLS en WSUS antes de cambiar las URL de los clientes

Configure el certificado del servidor, los enlaces IIS y las raíces virtuales que requieren TLS según el procedimiento WSUS de Microsoft. Desde un símbolo del sistema con privilegios elevados en C:\Program Files\Update Services\Tools, el comando documentado es:

wsusutil configuressl <certificate-name>

Sustituya el marcador por el nombre DNS del servidor WSUS. Exija TLS para los servicios de metadatos documentados, incluido ClientWebService; no lo exija para todo el sitio web WSUS. La distribución de archivos sigue usando HTTP, con validación de firmas y hashes. Actualice ambas URL de directiva de los clientes al punto de conexión HTTPS desplegado; https://wsus.contoso.com:8531 es el ejemplo de Microsoft, no un servidor descubierto. Verifique la confianza en el certificado y la búsqueda de actualizaciones antes del despliegue general.

Paso 3: probar la compatibilidad LSA, habilitar la protección y reiniciar

Use la auditoría de compatibilidad del procedimiento LSA antes de aplicar la protección. Resuelva los complementos y controladores incompatibles, seleccione la opción RunAsPPL compatible, reinicie y verifique el inicio protegido. Los eventos de auditoría no se generan cuando Smart App Control está habilitado o cuando un depurador de kernel está conectado y habilitado, por lo que el silencio no es una aprobación automática de compatibilidad. Revise las implicaciones del bloqueo UEFI antes de seleccionarlo: cambiar solo el registro no elimina la variable del firmware. La protección LSA y Credential Guard son controles complementarios.

Paso 4: exigir ambos atributos UNC en ambos recursos compartidos

Configure SYSVOL y NETLOGON explícitamente en la directiva Hardened UNC Paths. Pruebe la recuperación de directivas desde cada ámbito de destino e investigue los fallos de autenticación o acceso antes de ampliar el despliegue. Añada RequirePrivacy solo después de comprobar la compatibilidad del cifrado; los puntos de conexión no compatibles pueden volverse inaccesibles. Revise los permisos de escritura y los secretos reutilizables como tareas separadas, incluso cuando se cumplen los requisitos de transporte.

Mantenga un registro compacto para cada despliegue: sistema operativo y ámbito de destino, GPO aplicadas, salida del registro antes y después, evidencias pertinentes de ejecución o conexión, y cualquier dependencia sin resolver. Repita las mismas mediciones tras los cambios de directiva para que un revisor posterior pueda distinguir un ajuste modificado de una interpretación distinta de los valores predeterminados.

Cómo detecta EtcSec este problema

Las cuatro implementaciones Detect() de etc-collector revisadas para este artículo evalúan los datos de registro GPO recopilados:

Las funciones auxiliares del registro buscan en la directiva predeterminada de los controladores de dominio, luego en la directiva predeterminada del dominio y después en otra GPO disponible. El código agrega valores GPO y no demuestra la configuración efectiva de cada estación de trabajo. No calcula la precedencia de vínculos, el filtrado y la herencia para cada equipo. Por tanto, las GPO contradictorias o fuera de ámbito necesitan confirmación en el destino.

La función auxiliar UNC busca las dos cadenas de atributos necesarias; no es un analizador de directiva efectiva. Un WUServer ausente no activa el control HTTP, pero esa ausencia no valida la estrategia de actualización. Del mismo modo, la ausencia de entradas PPL o UNC puede requerir investigar los valores predeterminados modernos. Use cada hallazgo para abrir una tarea de verificación específica, adjunte las evidencias del destino y ciérrela solo cuando se demuestre la protección prevista para el ámbito afectado.