Auditar la seguridad de Active Directory: qué revisar primero y cómo demostrar la remediación

Para auditar la seguridad de Active Directory de forma sólida, hay que partir de la evidencia y no de una checklist genérica. Una auditoría de Active Directory defendible debe mostrar qué identidades pueden controlar el directorio, qué permisos pueden replicar secretos o reescribir límites de confianza, qué ajustes de protocolo o certificado siguen creando rutas de ataque cortas y qué evidencia se conservará después para validar la remediación.

Esta guía se mantiene centrada en Active Directory on-prem. Si tus operadores, roles privilegiados o flujos de recuperación también dependen de Microsoft Entra, esta revisión debe ejecutarse en paralelo con una evaluación separada de Entra, en lugar de mezclar ambos ámbitos en un único informe impreciso. El objetivo aquí es más acotado: mostrar qué debe cubrir primero una auditoría AD, qué hallazgos merecen remediación temprana y cómo demostrar que una corrección cambió realmente el plano de control.

Una auditoría AD útil debe producir cinco resultados:

1. un inventario acotado de las superficies del directorio que realmente importan
2. una lista de identidades y permisos que pueden controlar activos privilegiados o replicar secretos
3. una lista más corta de rutas de ataque que requieren remediación inmediata
4. evidencia de que los controles de hardening están realmente aplicados en producción
5. un paquete de validación comparable con el siguiente ciclo de revisión

Auditar la seguridad de Active Directory: ¿qué significa realmente?

Una auditoría de Active Directory no es solo una revisión de la política de contraseñas ni un informe puntual de estado. Es una revisión basada en evidencia de las identidades, permisos, servicios, políticas y telemetría que determinan quién puede controlar el directorio y con qué rapidez ese control podría ser abusado.

Eso significa que el resultado de la auditoría debe responder preguntas concretas:

• ¿Qué usuarios, grupos, cuentas de servicio u ordenadores tienen control sobre todo el dominio o casi todo él?
• ¿Qué derechos pueden replicar datos sensibles del directorio o reescribir límites de confianza?
• ¿Qué configuraciones de protocolo y delegación reducen el coste de ataque para un adversario?
• ¿Qué hallazgos son solo deriva de configuración y cuáles crean rutas directas de escalada?
• ¿Qué exportaciones, logs y snapshots de estado demuestran que una corrección es real?

Si la revisión no puede responder a esas preguntas, sigue siendo una checklist, no una auditoría. Esa diferencia importa porque un entorno puede parecer aceptable en una hoja de control mientras sigue exponiendo rutas cortas hacia Domain Admin a través de derechos de replicación, delegación, cuentas privilegiadas obsoletas o abuso de certificados.

Definir el alcance antes de revisar hallazgos

La forma más rápida de perder tiempo es empezar a revisar hallazgos antes de definir el alcance.

Decisiones obligatorias de alcance

Primero hay que decidir qué superficies del directorio están realmente en juego:

• el dominio o bosque revisado
• los controladores de dominio y los grupos administrativos privilegiados
• los grupos de administración delegada y las cuentas de servicio de alto impacto
• los derechos de replicación, los objetos sensibles desde el punto de vista ACL y los límites de herencia
• la delegación Kerberos y la exposición de service principals
• Group Policy, postura LDAP, Windows LAPS y audit policy
• AD CS, pero solo si existe en el bosque

El alcance debe mantenerse honesto. Si AD CS no está desplegado, hay que decir que queda fuera de alcance y seguir adelante. Si un equipo PKI separado lo administra pero AD CS existe en el bosque, forma parte de la auditoría porque la emisión de certificados puede seguir modificando la exposición privilegiada. La misma regla aplica a la identidad híbrida: si Microsoft Entra afecta a operadores privilegiados, rutas de recuperación o administración de aplicaciones, anota la dependencia, pero no afirmes que una revisión de Entra sustituye a una revisión de AD.

Requisitos de evidencia antes del primer export

Este es también el momento de decidir qué pruebas se conservarán entre ciclos. Si la auditoría deberá demostrar más adelante que un grupo privilegiado se limpió o que se retiró un derecho peligroso, ese requisito debe quedar definido antes de lanzar el primer export.

Revisar primero el acceso privilegiado y el Tier 0

Empieza por el plano de control del directorio, a menudo descrito operativamente como Tier 0. Eso implica revisar las identidades y rutas administrativas que pueden cambiar directamente el dominio, los controladores de dominio, los límites de confianza o los objetos que los protegen.

Qué revisar en la primera pasada

Revisa como mínimo:

• grupos privilegiados integrados y personalizados
• grupos de administración delegada y cadenas de anidamiento
• cuentas privilegiadas obsoletas y antiguas cuentas de excepción
• cuentas de servicio privilegiadas que siguen teniendo acceso permanente
• separación administrativa entre identidades de usuario normales e identidades de administración

Este es el punto de partida correcto porque las malas prácticas administrativas y la segmentación débil son precisamente donde arraigan las compromisiones reales de AD. La guía ANSSI de 2023 sobre administración segura de sistemas basados en AD señala explícitamente que las compromisiones AD proceden de malas prácticas de administración y segmentación insuficiente, y después describe cómo los atacantes usan movimiento lateral y escalada de privilegios para tomar el control completo del directorio.

Qué debe demostrar esta sección

La prueba práctica es sencilla: ¿puedes explicar quién administra el directorio, desde dónde, con qué tipo de cuenta y por qué ese acceso sigue existiendo? Si no es así, la auditoría debe detenerse aquí primero. Un directorio con una política de contraseñas limpia pero con un diseño débil de acceso privilegiado sigue siendo un directorio débil.

Para patrones de deriva relacionados, apóyate en Privileged Access Drift Active Directory: How Admin Rights Creep Back After Audits y Stale Privileged Accounts: Hidden Risk in Active Directory.

Auditar derechos de replicación, abuso de ACL y rutas de ataque cortas

Después de los grupos privilegiados, revisa los permisos que pueden eludirlos silenciosamente. Una auditoría AD seria debe incluir principales con capacidad de replicar secretos y con control amplio sobre objetos sensibles.

Derechos que merecen revisión inmediata

Microsoft documenta DS-Replication-Get-Changes-All como un derecho de control de acceso que permite replicar datos secretos del dominio. Eso basta para convertir los derechos de replicación en un tema de auditoría de primer nivel, no en un edge case avanzado. Si no sabes exactamente qué principales tienen derechos de replicación, la auditoría está incompleta.

Lo mismo aplica al control de objetos. No se trata solo de detectar membresías obvias en grupos admin. Se trata de identificar rutas de escritura, administración de permisos o toma de propiedad sobre objetos de alto valor como:

• la raíz del dominio
• grupos privilegiados
• AdminSDHolder
• OU que alojan administradores sensibles, servidores o GPO
• contenedores vinculados a GPO capaces de cambiar la postura de seguridad a escala

Qué telemetría ayuda a validar cambios

El logging importa aquí, pero debe describirse con precisión. Event 5136 se genera cuando se modifica un objeto del servicio de directorio, pero solo si el objeto tiene la SACL adecuada. Event 4662 registra operaciones realizadas sobre un objeto AD, pero de nuevo solo cuando la SACL apropiada existe y la operación la activa. Ninguno de los dos eventos es un detector mágico. Son puntos de evidencia útiles para validar cambios de alto valor y monitorizar objetos concretos una vez que el alcance está correctamente definido.

Por eso importa pensar en rutas de ataque. La pregunta no es solo si un derecho existe. La pregunta es si ese derecho crea una ruta corta hacia el control del directorio. Para una revisión más profunda, complementa con ACL Abuse and DCSync: The Silent Paths to Domain Admin y Active Directory Attack Paths to Domain Admin.

Revisar Kerberos, delegación y exposición de cuentas de servicio

Kerberos sigue siendo central en la exposición AD, especialmente a través de cuentas de servicio y configuraciones de delegación.

Cuentas y ajustes que revisar primero

Revisa como mínimo:

• cuentas de usuario o servicio con SPN
• cuentas privilegiadas que también exponen SPN
• unconstrained delegation
• constrained delegation y resource-based constrained delegation cuando se utilicen
• cuentas de servicio sin propietario claro, sin revisión reciente o con privilegios excesivos

Por qué la exposición de cuentas de servicio pertenece al núcleo de la auditoría

Las cuentas con SPN forman parte del alcance porque Kerberoasting depende de tickets de servicio solicitados para esos SPN, y por eso MITRE ATT&CK T1558.003 sigue siendo una referencia útil de contexto de detección para una auditoría técnica. La auditoría no necesita un walkthrough de explotación. Lo que sí necesita es mostrar qué cuentas de servicio exponen una oportunidad de cracking offline y si alguna de ellas es además privilegiada.

La delegación exige el mismo nivel de precisión. Microsoft describe la constrained delegation como una forma más restrictiva de delegación que la unconstrained delegation, porque limita los servicios hacia los que un servidor puede actuar en nombre de un usuario. Eso no convierte automáticamente la constrained delegation en segura. Solo significa que debe revisarse en contexto: qué servicios front-end están permitidos, qué servicios back-end confían en ellos y si la necesidad de negocio sigue existiendo.

Si quieres el análisis específico de delegación, usa Kerberos Delegation Attacks: From Unconstrained to RBCD Abuse. En la auditoría, mantén el foco en ownership, privilegio y rutas de abuso alcanzables.

Incluir AD CS si existe en el bosque

Si Active Directory Certificate Services está desplegado en cualquier punto del bosque, debe incluirse. Microsoft documenta AD CS como un rol de Windows Server para emitir y gestionar certificados PKI usados en protocolos de autenticación y comunicación segura. Eso basta para tratarlo como infraestructura de identidad, no como un tema secundario para una futura revisión PKI.

Qué debe cubrir la parte de AD CS

Una auditoría AD útil debería revisar por tanto:

• CAs empresariales que emiten certificados relevantes para autenticación
• templates de certificados publicados
• quién puede inscribirse y quién puede modificar permisos de templates
• si la emisión de certificados amplía la exposición privilegiada
• si las rutas basadas en certificados crean escaladas que eluden el trabajo ya hecho en grupos y delegación

No hay que asumir que todos los entornos AD tienen AD CS. Pero si lo tienen, no debe quedar fuera de la auditoría. La emisión de certificados y los permisos de templates pueden cambiar materialmente quién puede autenticarse y como quién. Para el desglose técnico específico de certificados, consulta ADCS Certificate Attacks: How ESC1 to ESC8 Lead to Domain Admin.

Revisar GPO, LDAP, LAPS y controles de logging

Una vez entendidas las rutas privilegiadas y los mecanismos de escalada, hay que revisar los controles que supuestamente endurecen el entorno y generan la telemetría en la que el equipo confía.

Controles que deben validarse directamente

Para LDAP, Microsoft indica que LDAP signing firma criptográficamente las comunicaciones LDAP para verificar autenticidad e integridad, mientras que channel binding vincula la seguridad de capa de aplicación con la sesión TLS subyacente. En la práctica, la auditoría debe confirmar la policy efectiva en los controladores de dominio, no solo el estándar objetivo. Esto importa aún más ahora porque Microsoft documenta claramente los límites de versión: los nuevos despliegues de Active Directory en Windows Server 2025 requieren LDAP signing por defecto, mientras que los entornos actualizados conservan la policy existente. Eso significa que hay que auditar la postura efectiva, no asumir el default. Para detalles de configuración y validación, usa LDAP Signing Disabled: How Unsigned Binds Expose Active Directory.

Para Windows LAPS, Microsoft documenta que la funcionalidad gestiona automáticamente y respalda las contraseñas del administrador local, y que también puede respaldar la contraseña DSRM de los controladores de dominio de Active Directory. Una auditoría AD debe comprobar no solo si LAPS está presente, sino también si la población prevista está cubierta, dónde se respaldan las contraseñas, quién puede leerlas y si la protección DSRM está configurada donde haga falta. Para el gap operativo, consulta Windows LAPS Not Deployed: Why Shared Local Admin Passwords Still Matter.

El logging que demuestra cambios de control

Para logging, la formulación debe seguir siendo exacta:

• Audit Security Group Management cubre cambios como creación, eliminación y altas o bajas de miembros en grupos.
• Event 5136 ayuda a validar modificaciones de objetos cuando existe la SACL adecuada.
• Event 4662 ayuda a monitorizar operaciones sobre objetos AD sensibles cuando directory service access auditing y las SACL están bien configurados.

Microsoft también indica que advanced audit policy settings pueden gestionarse mediante Group Policy para que las organizaciones modifiquen, prueben y desplieguen un audit más granular sobre los usuarios y grupos que realmente importan. Esa es la postura operativa correcta: probar la policy, confirmar el volumen de eventos y su retención, y verificar que el equipo revisa realmente la evidencia resultante. Para el conjunto de eventos que más importa tras el despliegue, consulta Active Directory Monitoring: Security Event IDs That Matter.

Evidencia que debe conservarse entre ciclos de auditoría

Una auditoría AD útil deja un paquete de evidencia reutilizable, no solo un conjunto de diapositivas.

Paquete mínimo de evidencia

Conserva fecha, alcance, fuente y responsable con cada artefacto. Si la siguiente auditoría no puede comparar exportaciones equivalentes, el equipo perderá tiempo discutiendo si un hallazgo es nuevo en lugar de demostrar que una ruta ha desaparecido.

Priorizar la remediación por impacto sobre la identidad

No hay que remediar en una cola plana. Hay que empezar por lo que cambia más directamente el alcance de un atacante.

Correcciones que suelen ir primero

Las remediaciones de primera prioridad suelen incluir:

• derechos relacionados con replicación que exponen datos secretos del dominio
• rutas ACL o de herencia que crean accesos cortos hacia objetos privilegiados
• unconstrained delegation y cuentas de servicio privilegiadas muy expuestas
• malas configuraciones de AD CS que crean abusos de autenticación o de inscripción

Controles que fortalecen el siguiente ciclo

Después vienen los controles que reducen la libertad del atacante y mejoran la validación futura:

• postura de LDAP signing y channel binding
• cobertura de Windows LAPS e higiene de contraseñas privilegiadas
• brechas de audit policy que dejan objetos de alto valor sin monitorización efectiva

Solo después de eso conviene dedicar esfuerzo a tareas de limpieza que mejoran la gobernanza pero que no acortan de forma material una ruta de ataque por sí mismas. Por eso una revisión repetible importa más que un informe estático. Recurring AD Audit Workflow: Why Annual Audits Drift and How Continuous Posture Monitoring Works cubre el modelo operativo, mientras que Active Directory Security Audit Tools: What to Compare Before You Choose aborda la cuestión de las herramientas.

Validación después de la remediación

Un hallazgo no está cerrado porque un ticket diga que lo está. Hay que validar desde la misma superficie de control que expuso el problema.

Tras una limpieza de acceso privilegiado, vuelve a ejecutar las exportaciones de grupos y administración delegada y confirma que la identidad ya no mantiene la ruta efectiva. Tras limpiar derechos de replicación, confirma que el principal ya no aparece en el conjunto de revisión de replicación. Tras endurecer LDAP, verifica la policy efectiva y valida que los binds sin firma se rechazan como estaba previsto. Tras desplegar Windows LAPS, confirma la aplicación de la policy y el estado del backup de contraseñas sobre la población objetivo. Tras corregir AD CS, verifica que el template arriesgado, el alcance de inscripción o la ruta de permisos han desaparecido realmente.

Qué debe incluir un hallazgo cerrado

La telemetría también debe validarse. Si esperas que futuros cambios sobre objetos sensibles generen evidencia 5136 o 4662, hay que demostrar que el modelo de SACL y la audit policy producen realmente los eventos en los que piensas apoyarte. Si los cambios de grupos son importantes, hay que demostrar que los eventos correspondientes están presentes en la cadena de logging y se conservan durante suficiente tiempo para ser útiles.

El paquete final de cierre debe incluir:

• el estado antes y después
• el responsable del cambio
• el método de validación
• la excepción residual, si existe
• la fecha en la que el hallazgo se volverá a revisar

Eso es lo que convierte una auditoría AD en un control repetible en lugar de un documento que envejece en cuanto llega el siguiente cambio de delegación.

Cómo EtcSec ayuda a estructurar una auditoría AD repetible

EtcSec debe encajar dentro de este workflow, no sustituirlo con lenguaje de marketing. La parte útil es la repetibilidad.

Dónde encaja el producto y dónde no

Una auditoría AD repetible necesita volver a ejecutar los mismos checks sobre las mismas superficies de control para demostrar si una ruta privilegiada es nueva, sigue igual o se ha corregido de verdad. EtcSec ayuda a estructurar ese trabajo manteniendo la revisión anclada en hallazgos concretos como EXCESSIVE_PRIVILEGED_ACCOUNTS, DCSYNC_CAPABLE, KERBEROASTING_RISK, UNCONSTRAINED_DELEGATION, ESC1_VULNERABLE_TEMPLATE, PATH_ACL_TO_DA, LDAP_SIGNING_DISABLED y LAPS_NOT_DEPLOYED.

El modelo actual de despliegue también soporta recogida local en lugar de obligar a que la auditoría empiece como un ejercicio puramente SaaS. Eso importa operativamente porque la evidencia AD es mejor cuando la ruta de recogida permanece estable, cuando los mismos controles se vuelven a medir después de la remediación y cuando los resultados pueden conservarse entre ciclos.

La propuesta de valor práctica es por tanto estrecha y comprobable: estructurar la auditoría, mantener el conjunto de hallazgos medible y hacer más defendibles los reruns. Si tu pregunta trata sobre selección de herramienta y no sobre método de auditoría, usa Active Directory Security Audit Tools: What to Compare Before You Choose.

Referencias primarias

• Audit Security Group Management
• 5136(S): A directory service object was modified
• 4662(S, F): An operation was performed on an object
• DS-Replication-Get-Changes-All extended right
• LDAP signing for Active Directory Domain Services
• Manage LDAP signing using Group Policy for Active Directory Domain Service
• What is Windows LAPS?
• Kerberos Constrained Delegation Overview in Windows Server
• What is Active Directory Certificate Services?
• Advanced Audit Policy Configuration
• Audit Active Directory objects in Windows Server 2003
• Recommandations pour l’administration sécurisée des SI reposant sur AD
• MITRE ATT&CK T1558.003: Kerberoasting