Las 5 configuraciones de Active Directory que encontramos rotas en casi todas nuestras auditorías internas

En casi todas las auditorías internas que hacemos, el dominio acaba cayendo. Y casi nunca es por un fallo sofisticado ni por un día cero exótico. Es por un puñado de configuraciones que se repiten empresa tras empresa, que se fueron acumulando durante años y que nadie volvió a mirar.

Son errores de configuración, no de software, así que no aparecen en ningún boletín de parches. Pero un atacante con una posición inicial sin privilegios los encuentra en cuestión de minutos. Estos son los cinco que más veces nos abren la puerta.

Cuentas de servicio que se pueden kerberoastear

En Active Directory, cualquier usuario autenticado puede pedir un ticket de servicio para una cuenta que tenga un SPN asociado. Ese ticket va cifrado con la contraseña de la cuenta de servicio, así que quien lo pide puede llevárselo a casa e intentar romperlo offline, sin hacer ruido y sin bloqueos de cuenta.

El problema es que muchas cuentas de servicio se crearon hace años con contraseñas cortas o reutilizadas y muchas veces tienen privilegios altos. Un atacante sin privilegios pide el ticket, lo crackea en su propio equipo y aparece con una cuenta de servicio que a menudo es administradora de algo importante.

La corrección pasa por usar cuentas de servicio administradas (gMSA), que rotan la contraseña de forma automática con longitudes imposibles de crackear. Donde no se pueda, usad contraseñas largas y aleatorias de más de 25 caracteres. Conviene además revisar qué cuentas mantienen un SPN que ya no se usa.

Cuentas sin preautenticación de Kerberos

Hay una opción en las cuentas de usuario que se llama “no requerir preautenticación Kerberos”. Cuando está activada, cualquiera puede pedir al controlador de dominio un dato cifrado con la contraseña de esa cuenta, otra vez para crackearlo tranquilamente fuera.

Suele estar puesta en cuentas antiguas, en integraciones con sistemas Unix o en aplicaciones que en su día la necesitaron y nadie revirtió. Cada una de esas cuentas es una contraseña que un atacante puede atacar offline desde el primer minuto, sin ni siquiera tener credenciales válidas.

La corrección es directa. Revisad qué cuentas tienen activada esa opción y desactivadla en todas las que no la necesiten de verdad, que suelen ser casi todas. A las pocas que deban conservarla, ponedles una contraseña larga y aleatoria.

Contraseñas en texto claro donde no deberían estar

Este es de los que más nos sorprende seguir encontrando. Aparece casi siempre.

Por un lado, el campo de descripción o de notas de las cuentas de usuario, donde alguien apuntó la contraseña “para acordarse” hace años. Cualquier usuario del dominio puede leer esos campos. Por otro, las preferencias de directiva de grupo (GPP) que guardaban contraseñas en el recurso SYSVOL cifradas con una clave que Microsoft publicó hace más de una década, así que descifrarlas es trivial. SYSVOL lo lee cualquiera que esté autenticado.

La corrección es buscar y borrar. Hay herramientas que recorren las descripciones de todo el dominio y el SYSVOL en busca de estos restos. Lo que aparezca se elimina, se rota la contraseña afectada y se establece como norma que las credenciales no viven en atributos ni en scripts.

Permisos excesivos sobre objetos privilegiados

El control de un dominio no siempre se gana siendo administrador. A veces basta con tener permisos peligrosos sobre las cuentas o los grupos correctos.

En casi todos los dominios que auditamos hay cuentas normales, sin pinta de privilegiadas, que sin embargo pueden cambiar la contraseña de un administrador, modificar quién pertenece a un grupo privilegiado o reescribir los permisos de un objeto crítico. Son permisos como GenericAll o WriteDACL que se delegaron mal en algún momento o que se heredaron sin que nadie lo planificara. Para un atacante son una autopista, porque encadenando dos o tres de esos permisos llega a administrador del dominio sin explotar ninguna vulnerabilidad.

La corrección es la más laboriosa de la lista. Hay que mapear quién tiene permisos sobre qué, sobre todo en las cuentas y los grupos privilegiados, para recortar después todo lo que no esté justificado. Las herramientas que dibujan estas relaciones ayudan a ver los caminos que un atacante seguiría.

Delegación sin restricciones

La delegación en Kerberos permite que un servicio actúe en nombre de un usuario para acceder a otro servicio. Es útil y a veces necesaria, pero tiene una variante peligrosa que llamamos delegación sin restricciones.

Cuando un servidor tiene activada la delegación sin restricciones, guarda en memoria los tickets de cualquier usuario que se conecte a él, incluidos los de un administrador del dominio. Si un atacante controla ese servidor, o consigue que un administrador se conecte, se queda con un ticket que le da el dominio entero. Y este tipo de delegación se sigue encontrando activado en servidores que nunca la necesitaron.

La corrección es eliminar la delegación sin restricciones allí donde no haga falta, que es casi siempre. Donde la delegación sea necesaria de verdad, se usa la variante restringida, que limita a qué servicios concretos se puede delegar. Las cuentas más sensibles, además, se marcan como que no se pueden delegar nunca.

Lo que tienen en común estas cinco

Ninguna de estas cinco cosas es una vulnerabilidad en el sentido clásico. No hay un parche que las cierre, no salen en un escáner automático de los que puntúan con colores y casi siempre conviven con un cumplimiento perfectamente en regla. Son configuraciones, decisiones que alguien tomó hace años y que el tiempo convirtió en agujeros.

Por eso las encontramos una y otra vez. Y por eso un escaneo automático casi nunca las ve. Hace falta que alguien mire el dominio como lo mira un atacante, encadenando permisos y relaciones en lugar de revisar una lista. Es justamente la diferencia que contábamos en por qué pasar una auditoría de cumplimiento no significa estar seguro.

Si hace tiempo que nadie mira vuestro Active Directory con esos ojos, lo más probable es que al menos dos o tres de estas cinco estén esperando.

---

Si queréis que auditemos vuestro Active Directory desde la posición de un atacante interno, escribidnos a [email protected].