Estimados amigos de Inseguros !!!
Los GPP passwords son una de esas historias que demuestran que en ciberseguridad lo viejo no desaparece.
Microsoft corrigió hace años la posibilidad de crear nuevas contraseñas mediante Group Policy Preferences, pero eso no significa que las contraseñas antiguas hayan desaparecido mágicamente de todos los SYSVOL del mundo.
Y ahí está el detalle importante.
SYSVOL es legible por los usuarios autenticados porque las políticas de grupo tienen que poder aplicarse en los equipos del dominio. Eso es normal. El problema aparece cuando dentro de SYSVOL quedan ficheros XML antiguos con atributos de contraseña.
Aunque esas contraseñas aparezcan “cifradas”, el problema histórico es que la clave de descifrado acabó siendo pública. Resultado: un usuario de dominio puede encontrar credenciales antiguas en cuestión de segundos si el entorno sigue arrastrando esos restos.
Y esto sigue saliendo en auditorías de Active Directory.
Qué son los GPP passwords
Group Policy Preferences permitía configurar elementos como usuarios locales, servicios, tareas programadas, unidades de red o fuentes de datos desde políticas de grupo.
Durante años, muchas empresas lo usaron para desplegar contraseñas de cuentas locales o de servicio.
La idea parecía cómoda:
Crear una política.
Configurar una cuenta local.
Definir una contraseña.
Aplicarla a muchos equipos.
Ahorrarse trabajo manual.
El problema es que esa configuración podía acabar guardada en ficheros XML dentro de SYSVOL. Y SYSVOL, por diseño, puede ser leído por usuarios autenticados del dominio.
Así que una mala decisión de administración podía convertirse en una credencial expuesta para cualquiera que tuviera una cuenta de dominio.
Por qué es peligroso encontrar GPP passwords en SYSVOL
El impacto depende de qué contraseña aparezca.
A veces es una cuenta local de administrador reutilizada en cientos de equipos.
A veces es una cuenta de servicio.
A veces es una cuenta antigua que nadie recuerda, pero que todavía funciona.
Y en el peor de los casos, puede ser una cuenta con privilegios más altos de lo que debería.
En cualquier escenario, el atacante gana algo que no debería estar ahí: una credencial reutilizable.
Y una credencial reutilizable en Active Directory siempre es una mala noticia.
Porque puede servir para moverse lateralmente, acceder a servidores, probar reutilización de contraseña, elevar privilegios o continuar una intrusión que empezó con un usuario aparentemente poco importante.
“Eso era de 2014” no significa que tu dominio esté limpio
Este es el error típico.
Muchas empresas creen que este problema ya no les afecta porque es algo antiguo.
Pero los dominios no se reinstalan cada año.
Se actualizan.
Se migran.
Se heredan.
Se arrastran.
Se parchean por encima.
Se mantienen funcionando porque “si lo tocas, se rompe”.
Un SYSVOL puede tener residuos de Windows Server 2008, 2012, 2016 y seguir funcionando hoy dentro de un entorno aparentemente moderno.
Por eso, en una auditoría de Active Directory, no basta con mirar solo lo nuevo. Hay que mirar también lo que se quedó olvidado.
Y los GPP passwords son un ejemplo perfecto.
Cómo revisar si tienes GPP passwords en SYSVOL
La revisión debería formar parte de cualquier auditoría básica de Active Directory.
Hay que buscar referencias como cpassword dentro de SYSVOL y revisar ficheros XML asociados a preferencias de directiva de grupo.
Especialmente en rutas o elementos relacionados con:
Groups.
Services.
ScheduledTasks.
DataSources.
Drives.
Printers.
Configuraciones antiguas de usuarios locales.
Cuentas de servicio desplegadas por GPO.
La idea no es solo encontrar el fichero.
La idea es entender qué credencial aparece, dónde se aplicaba, qué privilegios tenía, si sigue activa y en cuántos sistemas se reutilizó.
Porque borrar el XML no soluciona el problema si la contraseña sigue siendo válida.
La remediación correcta no es borrar y olvidarse
Este punto es clave.
Si encuentras un GPP password en SYSVOL, no basta con eliminar el XML y dar el tema por cerrado.
Primero hay que identificar la credencial afectada.
Después hay que revisar dónde se ha usado.
Luego hay que rotarla.
Y solo después tiene sentido limpiar los restos de SYSVOL.
Porque si alguien ya leyó esa contraseña hace meses, borrar el fichero hoy no cambia nada. La contraseña sigue siendo válida hasta que la cambies.
La remediación correcta pasa por:
Eliminar configuraciones antiguas de Group Policy Preferences.
Rotar todas las credenciales afectadas.
Revisar reutilización de contraseñas.
Comprobar privilegios asociados.
Documentar el cambio.
Sustituir el mecanismo antiguo por una solución segura.
Monitorizar posibles usos posteriores de esas cuentas.
Esto no es solo una limpieza técnica. Es una reducción real de riesgo.
Qué usar en lugar de GPP passwords
Hoy no tiene sentido gestionar contraseñas de esta forma.
Para administradores locales, lo razonable es usar Windows LAPS.
Para cuentas de servicio, conviene valorar gMSA cuando encaje.
Y para secretos más complejos, hay que usar soluciones de gestión de secretos o mecanismos controlados, auditables y rotables.
Lo importante es cambiar la mentalidad.
No se trata de “dónde puedo dejar esta contraseña para que funcione”.
Se trata de “cómo gestiono esta credencial para que no quede expuesta, se pueda rotar y tenga el menor privilegio posible”.
Ahí es donde se nota la diferencia entre administrar Windows y defender Windows.
Monitorización: SYSVOL también cuenta una historia
Leer SYSVOL no es malo por sí mismo.
De hecho, es normal que los equipos y usuarios necesiten acceder a políticas.
Pero hay patrones que pueden ser interesantes desde el punto de vista defensivo.
Por ejemplo:
Lecturas masivas de SYSVOL desde una estación rara.
Búsquedas de XML fuera de horario.
Accesos desde usuarios que no administran nada.
Uso de herramientas conocidas para buscar cpassword.
Actividad anómala justo después de comprometer una cuenta.
Consultas repetidas a rutas de políticas antiguas.
No se trata de generar alertas por todo.
Se trata de entender que SYSVOL también forma parte de la superficie de ataque de Active Directory.
Y si estás montando monitorización o un SOC, este tipo de comportamiento puede darte señales tempranas de reconocimiento interno.
Active Directory acumula historia
Este tipo de fallo me gusta mucho para explicar una idea sencilla: Active Directory no solo se compromete por vulnerabilidades nuevas.
A veces se compromete por historia acumulada.
Una GPO que nadie recuerda.
Una cuenta de servicio creada hace diez años.
Una contraseña reutilizada.
Un servidor antiguo.
Una excepción que nunca se retiró.
Un XML olvidado en SYSVOL.
Y todo eso sigue dentro del dominio.
Por eso una auditoría seria de Active Directory tiene que mirar tanto configuración actual como residuos históricos.
Si solo miras el presente, puedes perderte justo lo que lleva años esperando.
Por qué esto importa a empresas
Para una empresa, GPP passwords puede parecer un fallo antiguo y muy técnico.
Pero la pregunta de fondo es mucho más sencilla:
¿Tenemos contraseñas expuestas dentro del dominio sin saberlo?
Si la respuesta es sí, el problema puede ser serio.
Una credencial encontrada en SYSVOL puede convertirse en acceso a equipos, movimiento lateral, abuso de cuentas locales, compromiso de servicios o escalada hacia sistemas más sensibles.
Y lo peor es que muchas veces la empresa ni siquiera sabe que esa contraseña sigue ahí.
Por eso este tema encaja muy bien dentro de una formación práctica en seguridad Active Directory. No es teoría decorativa. Es algo que se puede revisar, limpiar y corregir.
Formación Microsoft, Active Directory y FUNDAE
En SeguridadSi trabajamos este tipo de casos porque siguen ocurriendo en entornos reales.
GPP passwords, Kerberos, delegación, cuentas privilegiadas, SYSVOL, GPOs, modelo de tiers, Windows Server y monitorización son piezas que cualquier equipo que administre Microsoft debería entender.
Un curso de ciberseguridad Microsoft para empresas no debería quedarse solo en ataques espectaculares. Tiene que enseñar también a revisar, limpiar, documentar y evitar que los errores vuelvan a aparecer.
Y si una compañía quiere formar a su equipo mediante cursos de ciberseguridad para empresas con FUNDAE, este contenido tiene aplicación directa: revisar SYSVOL, detectar credenciales expuestas, rotarlas, sustituir mecanismos antiguos y mejorar la operación diaria.
Puedes ampliar esta línea con el Curso de Ciberseguridad Microsoft para Empresas, centrado en hacking y defensa avanzada de Active Directory y Windows Server.
Conclusión
GPP passwords es una lección humilde.
No todo incidente empieza con una vulnerabilidad nueva.
A veces empieza con una contraseña vieja, abandonada en una carpeta que todo el dominio puede leer.
Por eso conviene revisar SYSVOL, buscar restos históricos, rotar credenciales afectadas y sustituir mecanismos antiguos por soluciones modernas.
Active Directory no se protege solo con parches. También se protege limpiando la historia que nadie quiso mirar.
Gracias por leerme !!!
Preguntas frecuentes sobre GPP passwords en SYSVOL
¿Qué son los GPP passwords en Active Directory?
Los GPP passwords son contraseñas configuradas antiguamente mediante Group Policy Preferences que podían quedar almacenadas en ficheros XML dentro de SYSVOL.
¿Por qué son peligrosos los GPP passwords en SYSVOL?
Son peligrosos porque SYSVOL puede ser leído por usuarios autenticados del dominio. Si quedan ficheros XML con contraseñas antiguas, un atacante podría obtener credenciales reutilizables.
¿Cómo puedo saber si tengo GPP passwords en mi dominio?
Debes revisar SYSVOL buscando atributos como cpassword y analizar XML relacionados con Groups, Services, ScheduledTasks, DataSources y Drives.
¿Basta con borrar el XML que contiene la contraseña?
No. Antes hay que identificar la cuenta afectada y rotar la contraseña. Borrar el XML no cambia la credencial si alguien ya la obtuvo.
¿Qué alternativas existen a GPP passwords?
Para administradores locales se recomienda Windows LAPS. Para cuentas de servicio puede valorarse gMSA. Para otros secretos, deben usarse soluciones modernas de gestión de credenciales y secretos.
