🏢Active DirectoryIdentityPrivileged AccessAttack Paths

Auditar la seguridad de Active Directory: checklist práctica

Una checklist práctica de auditoría de seguridad de Active Directory que cubre grupos privilegiados, Kerberos, delegación, ADCS, política de contraseñas y prioridades de remediación.

ES
EtcSec Security Team
9 min read
Auditar la seguridad de Active Directory: checklist práctica

Una auditoría de seguridad de Active Directory debe hacer algo más que enumerar malas configuraciones. Debe ayudar a su equipo a responder tres preguntas prácticas:

  1. ¿Qué hallazgos exponen Tier 0 o identidades privilegiadas?
  2. ¿Qué rutas pueden abusarse de forma realista a continuación?
  3. ¿Qué pasos de remediación deben abordarse primero?

Si quiere la ruta corta, empiece con un workflow dedicado de Active Directory security audit y ejecute el colector localmente mediante ETC Collector. Si primero quiere la checklist completa, use la guía siguiente.

1. Empezar por las identidades privilegiadas y Tier 0

Muchos programas de auditoría AD pierden tiempo porque empiezan por la higiene general en lugar de la exposición privilegiada. La primera pasada debe centrarse en:

  • Domain Admins, Enterprise Admins, Schema Admins y otros grupos privilegiados integrados
  • rutas de administración delegada
  • cuentas con derechos de replicación
  • cuentas privilegiadas con contraseñas antiguas o protecciones débiles
  • anomalías de adminCount y protecciones huérfanas

En esta fase del análisis necesita saber qué identidades pueden cambiar los límites de confianza del dominio, no solo qué ajustes parecen desordenados.

2. Revisar Kerberos y las rutas de abuso de delegación

Las debilidades de Kerberos siguen impulsando muchos hallazgos AD de alto impacto. Una auditoría práctica debe buscar:

  • cuentas kerberoastables
  • cuentas vulnerables a AS-REP Roasting
  • delegación no restringida
  • delegación restringida con destinos de riesgo
  • abuso de delegación restringida basada en recursos
  • cuentas privilegiadas con SPN
  • cuentas que todavía dependen de cifrados débiles

Estas comprobaciones importan porque se conectan directamente con robo de credenciales, movimiento lateral y escalada de privilegios.

3. Revisar la política de contraseñas y la higiene de cuentas

La revisión de políticas de contraseña sigue siendo útil, pero debe ligarse a la exposición y al impacto de la remediación. Céntrese en:

  • password never expires
  • password not required
  • reversible encryption
  • cuentas privilegiadas obsoletas
  • cuentas deshabilitadas dentro de grupos administrativos
  • cobertura débil de las fine-grained password policies

Si su entorno todavía contiene excepciones, documente si están justificadas, si son temporales y quién es el owner.

4. Auditar ADCS y las rutas de abuso de certificados

ADCS suele omitirse en revisiones internas aunque puede crear rutas directas de escalada. Su auditoría debe cubrir:

  • plantillas de certificados vulnerables
  • ACL peligrosas en templates
  • abuso de enrollment agent
  • certificate mapping débil
  • flags de CA y configuraciones RPC arriesgadas

Si su proceso actual no evalúa rutas de abuso de certificados de estilo ESC, la auditoría está incompleta para una defensa AD moderna.

5. Inspeccionar ACL, derechos de replicación y attack paths

La revisión bruta de ACL no basta. Necesita entender qué permisos pueden encadenarse en abusos significativos. Una auditoría sólida debe sacar a la luz:

  • abuso de GenericAll, WriteDacl, WriteOwner y derechos extendidos
  • derechos de replicación y principals capaces de DCSync
  • permisos peligrosos sobre OU, GPO y AdminSDHolder
  • attack paths que llegan a activos de alcance de dominio en uno o dos saltos

Aquí es donde un análisis profundo se diferencia de una simple revisión de postura.

6. Incluir GPO, logging y hardening

Group Policy y el hardening del plano de control siguen generando mejoras valiosas. Revise:

  • política de contraseñas débil en la Default Domain Policy
  • falta de LDAP signing o channel binding
  • ausencia de PowerShell logging
  • UNC path hardening insuficiente
  • scripts de inicio de sesión peligrosos
  • exposición débil de SMB y TLS en domain controllers

Estos hallazgos pueden parecer operativos, pero son exactamente los controles que cambian el coste del ataque en la práctica.

7. Priorizar la remediación por impacto sobre la identidad

No remedie en una cola plana. Agrupe la salida por impacto:

  • crítico: exposición privilegiada directa, atajos de attack path, abuso de certificados, capacidad DCSync
  • alto: abuso de delegación, cuentas privilegiadas roastables, ACL de riesgo, legacy auth o protocolos débiles
  • medio: deriva de higiene y política que aumenta la superficie de ataque
  • bajo: limpieza informativa con valor de explotación limitado

Si necesita un workflow basado en este modelo, la página Active Directory security audit muestra cómo estructurarlo, y EtcSec pricing explica cuándo la capa SaaS de seguimiento resulta útil sobre ETC Collector.

8. Repetir la revisión después de cambios

Una auditoría AD no debe convertirse en un artefacto anual. Repita las mismas comprobaciones después de:

  • cambios de roles
  • actualizaciones de GPO
  • cambios en certificate services
  • cambios en la administración delegada
  • fusiones, nuevos sitios o nuevos dominios

Por eso los equipos empiezan a evaluar una PingCastle alternative: el problema real no suele ser el primer informe, sino la falta de un ciclo de revisión repetible después.

Conclusión

Una auditoría de seguridad AD efectiva es una revisión repetible de exposición privilegiada, no solo un informe de salud. Empiece por Tier 0, Kerberos, delegación, ADCS y rutas de abuso de ACL. Después priorice la remediación según lo que realmente cambia el alcance de un atacante.

Si quiere un workflow dedicado, empiece por la página Active Directory security audit o revise cómo ETC Collector ejecuta la recolección técnica localmente.

9. Cree un paquete de evidencias para cada ciclo de revisión

Una auditoría de AD útil se vuelve más rápida y consistente cuando el equipo acuerda un paquete de evidencias repetible. En lugar de ejecutar comprobaciones ad hoc cada vez que cambia un administrador, conviene definir por adelantado qué exportaciones, capturas y snapshots del directorio se recogerán en cada revisión. Eso facilita comparar un ciclo con el siguiente, defender las prioridades de remediación y explicar por qué un hallazgo sigue abierto.

Área de revisiónEvidencia a recopilarPor qué importa
Acceso privilegiadoMiembros de Domain Admins, Enterprise Admins, grupos operadores y grupos de administración delegadaMuestra las rutas más cortas hacia Tier 0 y resalta accesos demasiado amplios
Kerberos y delegaciónCuentas con SPN, cuentas AS-REP roastable, delegación no restringida y delegaciones restringidas riesgosasRelaciona la mala configuración con robo de credenciales y movimiento lateral
Replicación y abuso de ACLPrincipales capaces de DCSync y ACL peligrosas sobre OU, GPO, AdminSDHolder y grupos claveSaca a la luz rutas de abuso que no siempre parecen privilegiadas al principio
ADCSCA habilitadas, plantillas publicadas, permisos riesgosos en plantillas y exposición de enrollment agentsCubre escaladas basadas en certificados que muchos equipos internos pasan por alto
Hardening y loggingLDAP signing, channel binding, logging de PowerShell, configuración SMB y exposición de scriptsVerifica si los controles compensatorios reducen de verdad la libertad del atacante

La idea de este paquete de evidencias no es generar burocracia, sino consistencia. Cuando se exportan los mismos datos en cada ciclo, la revisión se vuelve comparable. El equipo puede demostrar si una ruta privilegiada es nueva, sigue igual o se ha remediado parcialmente, en lugar de discutir de memoria. También ayuda a separar los problemas que exigen cambios de arquitectura de los que solo requieren limpieza y ownership.

También conviene usar una convención de nombres simple. Guarde las exportaciones por fecha de revisión, dominio y área de control para que el siguiente analista pueda comparar resultados rápidamente. Si participan varios equipos, deje claro quién recopila, quién valida los hallazgos y quién aprueba las excepciones. Así la auditoría se convierte en un proceso operativo repetible y no en un ejercicio técnico aislado.

FAQ

¿Con qué frecuencia debe ejecutarse una auditoría de seguridad de AD?

La mayoría de los equipos internos deberían repetir la revisión central al menos cada trimestre y después de cambios de identidad importantes. Eso incluye fusiones, reestructuraciones de dominios, cambios en servicios de certificados, nuevos modelos de administración delegada o rediseños importantes de GPO. Si el entorno cambia rápido o intervienen muchos administradores, los controles mensuales sobre exposición Tier 0 y grupos privilegiados suelen estar justificados.

¿Qué debe corregirse primero después de la auditoría?

Empiece por los hallazgos que dan a un atacante acceso privilegiado directo o casi directo. Membresías excesivas en grupos privilegiados, cuentas con capacidad de DCSync, delegación no restringida, plantillas de certificados peligrosas y attack paths muy cortos deben ir antes que la higiene general. Los problemas de antigüedad de contraseña, cuentas obsoletas y lagunas de logging siguen importando, pero rara vez merecen la primera posición si ya existe una vía de escalada a nivel de dominio.

¿Quién debe ser responsable de la remediación?

El equipo de seguridad normalmente debe marcar la prioridad y validar los cambios, pero el owner de la remediación debe ser el equipo que realmente puede modificar la configuración de riesgo. Puede ser el equipo de AD, de endpoint management, los owners de PKI o equipos de aplicación que dependan de cuentas de servicio. La auditoría es mucho más útil cuando cada hallazgo importante tiene un owner nombrado, una fecha objetivo y una decisión explícita si el riesgo no puede eliminarse de inmediato.

¿ADCS debe estar siempre dentro del alcance?

Si ADCS existe en cualquier parte del bosque, debe estar dentro del alcance. Las rutas de escalada por certificados pueden anular un trabajo por lo demás sólido en grupos privilegiados, política de contraseñas o hardening de delegación. Los equipos internos suelen dejar ADCS para una revisión PKI separada, pero esa separación crea puntos ciegos. Una auditoría AD es más fuerte cuando trata plantillas, derechos de inscripción y configuración de CA como parte de la misma exposición privilegiada.

¿Qué evidencias deben conservarse entre ciclos de auditoría?

Conserve suficientes elementos para demostrar qué cambió, qué sigue abierto y qué se aceptó como excepción. En la práctica suele significar los datasets exportados utilizados en la revisión, la lista final de hallazgos, el tracker de remediación y el registro de excepciones con owners y fechas de revisión. Guardar solo el informe final no basta, porque hace más lenta la siguiente revisión y debilita la capacidad de demostrar progreso.

¿Cuándo conviene combinar la auditoría de AD con una revisión de Entra ID?

Si administradores privilegiados también se autentican en servicios cloud, si la sincronización híbrida o la gestión de aplicaciones afecta identidades críticas, o si los procesos de recuperación dependen de roles cloud, la revisión de AD debe combinarse con una revisión de Entra. Muchos equipos descubren que la postura on-prem parece más limpia que el plano de control de identidad general. Combinar la vista de Active Directory security audit con la vista de Microsoft Entra ID security audit ayuda a evitar esos puntos ciegos.

EtcSec

© 2026 EtcSec. All rights reserved.

78, Avenue des Champs-Élysées, Bureau 326, 75008 Paris

Auditar la seguridad de Active Directory | EtcSec — EtcSec Blog | EtcSec