Secretos cPassword GPO SYSVOL Active Directory: por qué un parche de 2014 no lo solucionó

Secretos cPassword GPO SYSVOL Active Directory: qué son

Los secretos cPassword GPO SYSVOL Active Directory están entre las configuraciones incorrectas más antiguas que se niegan a desaparecer — y una de las configuraciones incorrectas de Active Directory más comunes que todavía se encuentran hoy en auditorías de producción. Provienen de las Group Policy Preferences (GPP), una función que Microsoft añadió en Windows Server 2008 que permitía a los administradores desplegar mediante Directiva de grupo cuentas de usuario locales, unidades asignadas, tareas programadas, servicios y orígenes de datos — incluyendo, para varios de estos tipos de preferencia, un nombre de usuario y una contraseña que aplicar en las máquinas de destino.

Esas credenciales se almacenaban en el atributo cpassword del archivo XML de la preferencia (Groups.xml, Services.xml, ScheduledTasks.xml, Printers.xml, Drives.xml, DataSources.xml), cifradas con AES-256, y escritas en el recurso compartido SYSVOL del dominio — el mismo recurso que replica cada controlador de dominio y que puede leer cualquier usuario autenticado (y, por defecto, los usuarios de cualquier dominio de confianza) para que los equipos cliente obtengan sus objetos de directiva de grupo (GPO).

El problema: Microsoft publicó en su propia documentación de protocolo la clave AES privada usada para cifrar cada valor cpassword, porque las GPP necesitaban una forma de descifrar el valor en el lado del cliente durante el procesamiento de la directiva. Cualquier usuario de dominio autenticado que pueda leer SYSVOL — es decir, por diseño, todos ellos — puede encontrar la cadena cifrada y descifrarla en segundos con herramientas disponibles públicamente. La exposición se documentó públicamente por primera vez en 2012 por el investigador de seguridad Chris Campbell (obscuresec), que publicó una prueba de concepto en PowerShell para localizar y descifrar estos valores mucho antes de que Microsoft publicara una corrección.

Por qué esto sigue reapareciendo una década después

Si MS14-025 se publicó en 2014, ¿por qué las auditorías todavía encuentran entradas cpassword activas hoy? Varios patrones recurrentes lo explican:

• Migraciones de dominio y adquisiciones. Las GPO se migran con frecuencia en bloque desde un dominio antiguo, incluyendo cualquier preferencia configurada antes de que el entorno adquirido fuera parcheado o revisado.
• Copias de seguridad de GPO restauradas. Las copias de seguridad de GPO realizadas antes de 2014 y restauradas años después reintroducen exactamente el XML que el parche pretendía evitar en adelante — el parche protege el editor, no una operación de restauración.
• Entornos gestionados por MSP y proveedores. Un proveedor de servicios gestionados que reutiliza una plantilla de GPO estándar en varios clientes puede propagar la misma credencial de administrador local expuesta a todos los entornos que toca esa plantilla.
• Falta de revisión periódica de SYSVOL. A diferencia de un servicio activo, el contenido de SYSVOL no caduca ni se marca mediante el parcheo rutinario — nada obliga a un nuevo análisis a menos que alguien lo ejecute deliberadamente.

Ninguno de estos casos requiere que un sistema mal configurado se haya saltado el parche de 2014. Solo requieren que un valor cpassword haya existido en algún momento en SYSVOL a lo largo de la historia del dominio y nunca se haya buscado y eliminado activamente — precisamente por eso el escaneo proactivo, y no el cumplimiento de parches, es el control que realmente cierra esta brecha.

Cómo funciona

Microsoft abordó parte de este problema con MS14-025 (CVE-2014-1812), publicado el 13 de mayo de 2014, y distribuido como la actualización KB2962486. El parche eliminó los campos de «Contraseña» del editor de Group Policy Preferences en la consola de administración de directivas de grupo (GPMC) y en las Remote Server Administration Tools (RSAT), de modo que los administradores ya no pueden crear nuevas entradas GPP que contengan una contraseña (Microsoft Support: MS14-025).

Lo que KB2962486 no hace es eliminar retroactivamente los valores cpassword que ya se escribieron en SYSVOL antes de instalar el parche, y tampoco impide que un atacante descifre lo que aún queda ahí. La guía de la ANSSI sobre la administración segura de AD señala precisamente esta carencia: el parche cambia lo que el editor permite escribir a un administrador en adelante, pero los objetos GPP históricos creados antes de instalar el parche deben localizarse y limpiarse manualmente (ANSSI-PA-099).

La propia clave AES no es un secreto que el atacante deba robar: es la misma clave estática de 32 bytes para todos los dominios de Active Directory del planeta, documentada por Microsoft y reflejada en la investigación de seguridad desde aquella divulgación original de 2012, e integrada más tarde directamente en herramientas ofensivas como PowerSploit y CrackMapExec (adsecurity.org: Finding Passwords in SYSVOL & Exploiting Group Policy Preferences).

La cadena de ataque

Explotar un cpassword olvidado no requiere acceso elevado ni ningún exploit — es una técnica posterior a la autenticación disponible para cualquier usuario de dominio, y a menudo también para cualquier usuario de un bosque de confianza.

Paso 1 — Enumerar SYSVOL en busca de cpassword

Un atacante con cualquier credencial de dominio válida (o un punto de apoyo con pocos privilegios) busca en el recurso compartido SYSVOL archivos XML que contengan el atributo cpassword:

# Linux, con credenciales de dominio válidas
crackmapexec smb <dc-ip> -u 'user' -p 'password' -M gpp_password

# Windows, PowerSploit
Import-Module .\Get-GPPPassword.ps1
Get-GPPPassword -Verbose

Paso 2 — Descifrar con la clave AES publicada

Get-GPPPassword y herramientas equivalentes (Get-DecryptedCpassword, gpp-decrypt) aplican la clave AES públicamente conocida al valor cpassword decodificado en Base64 y devuelven el texto en claro al instante — no hay fuerza bruta ni paso de cracking, solo una rutina de descifrado fija.

Paso 3 — Reutilizar la credencial

Como las GPP se usaban con frecuencia para estandarizar una cuenta de administrador local en muchas máquinas, o para ejecutar una tarea programada o un servicio con una cuenta de servicio de dominio, la contraseña recuperada suele ser directamente reutilizable para movimiento lateral o escalada de privilegios, sin necesidad de ninguna técnica adicional. Una sola entrada en Groups.xml que estableciera una contraseña de administrador local común en todo el dominio basta para comprometer cada estación de trabajo a la que se aplique esa GPO.

Detección

Para confirmar directamente la exposición en lugar de esperar señales de registro, la guía de la ANSSI sobre administración segura de AD (ANSSI-PA-099) ofrece una comprobación proactiva de una línea que los auditores pueden ejecutar desde un sistema unido al dominio:

:: Reemplace <FQDN> por el nombre de dominio completo del dominio AD.
findstr /S /I cpassword \\<FQDN>\sysvol\<FQDN>\policies\*.xml

Cualquier coincidencia significa que un valor cpassword — herramienta parcheada o no — todavía está hoy en SYSVOL (ANSSI-PA-099, Recomendación R31, Listado 3). Como esta comprobación lee contenido de archivo estático en lugar de telemetría en vivo, es la forma más rápida para un auditor de obtener una respuesta definitiva sin esperar a la retención de registros. El mismo principio se aplica a otras fugas de credenciales persistentes que conviene revisar en la misma pasada, como las contraseñas dejadas en los campos de descripción de AD. Para un repaso más amplio de qué priorizar en una revisión completa, consulte nuestra guía sobre cómo auditar la seguridad de Active Directory.

Remediación

1. Confirme que KB2962486 está desplegado en todo sistema que aún se use para editar directivas de grupo mediante la consola nativa GPMC/MMC (versiones anteriores a Windows Server 2016) o mediante herramientas RSAT más antiguas (versiones anteriores a Windows 10). Esto solo impide que se introduzcan nuevas contraseñas en las GPP en adelante.
2. Ejecute el escaneo de SYSVOL (comando findstr anterior, o una búsqueda recursiva equivalente) y enumere cada archivo Groups.xml, Services.xml, ScheduledTasks.xml, Printers.xml, Drives.xml y DataSources.xml de cada GPO en busca de un atributo cpassword — incluyendo las GPO deshabilitadas y no vinculadas, que suelen omitirse en las revisiones manuales.
3. Rote de inmediato cada credencial encontrada. Eliminar la entrada XML no invalida una contraseña que ya era descifrable; asuma que se ha leído y actúe en consecuencia.
4. Elimine la configuración GPP en lugar de dejar un campo de contraseña vacío — según la recomendación R32 de la ANSSI, nunca debe volver a registrarse una contraseña en una preferencia de directiva de grupo (ANSSI-PA-099, Recomendación R32, p.49). Nuestra guía práctica de las recomendaciones de AD de la ANSSI explica cómo convertir una recomendación como esta en un plan de despliegue.
5. Reemplace las cuentas de administrador local gestionadas por GPP con Windows LAPS, que rota una contraseña única y aleatoria por máquina y la almacena como un atributo protegido de AD en lugar de en un archivo XML estático.
6. Extienda el mismo escrutinio a los scripts de inicio/cierre de sesión almacenados en SYSVOL o NETLOGON — la recomendación R31 de la ANSSI aplica el mismo principio de secreto reutilizable a cualquier script legible por cuentas con menos privilegios, no solo al XML de las GPP. Un script que asigna una unidad con una contraseña de cuenta de servicio incrustada está exactamente tan expuesto como un campo cpassword.
7. Endurezca el acceso de lectura cuando sea posible. SYSVOL y NETLOGON deben seguir siendo legibles para el procesamiento de directivas, pero revise las desviaciones de permisos de SYSVOL/NETLOGON más allá de la configuración predeterminada, y habilite el endurecimiento UNC en estos recursos compartidos para que los clientes validen la integridad y la autenticación mutua al leerlos.
8. Vuelva a ejecutar el escaneo tras cada restauración de copia de seguridad de GPO o migración de dominio, no solo una vez. Como estas son las dos formas más comunes en que reaparecen las entradas cpassword antiguas, convierta el reescaneo de SYSVOL en un paso permanente de cualquier plan de migración en lugar de una limpieza puntual, y asígnele un responsable para que no dependa de que alguien lo recuerde.

Cómo detecta esto EtcSec

La auditoría de Active Directory de EtcSec marca esta exposición como GPO_PASSWORD_IN_SYSVOL, una comprobación de severidad crítica que analiza el XML de preferencias de cada GPO en busca de un atributo cpassword con valor — incluyendo las GPO deshabilitadas o no vinculadas, que las revisiones manuales suelen pasar por alto. Se combina con SYSVOL_NETLOGON_PERMISSIONS, que revisa los permisos de lectura/escritura en los recursos compartidos SYSVOL y NETLOGON en busca de desviaciones respecto a la línea base esperada. Juntas, ambas comprobaciones cubren tanto la exposición histórica de GPP como la higiene de permisos continua necesaria para evitar que SYSVOL vuelva a convertirse en un vertedero de secretos reutilizables.