La consulta deriva acceso privilegiado active directory describe una brecha concreta: la diferencia entre el modelo de privilegios que una organización cree tener y los derechos efectivos que existen realmente en el directorio hoy. La deriva puede empezar con una pertenencia temporal a un grupo, una delegación de helpdesk para resolver una operación, una cuenta de servicio añadida durante una incidencia o una ACL que nadie revisa cuando termina un proyecto. Con el tiempo, esos cambios pequeños pueden recrear rutas de ataque que una auditoría anterior ya había eliminado.
Este artículo se limita a Active Directory on-premises. No trata Microsoft Entra Privileged Identity Management como control sustituto y no reduce la deriva a cuentas administradoras obsoletas. En AD, el privilegio puede reaparecer mediante grupos anidados, ACL del directorio, derechos de replicación, cambios en AdminSDHolder, reutilización de la cuenta Administrator integrada, cuentas de servicio y excepciones de emergencia. Detectarlo exige correlacionar la línea base esperada, los derechos efectivos actuales, los cambios recientes y la telemetría de seguridad.
Deriva acceso privilegiado active directory: qué cubre
La deriva del acceso privilegiado es la acumulación de derechos administrativos efectivos que ya no coinciden con el modelo previsto para el dominio. Una revisión de acceso puede concluir que solo grupos administrativos nominados controlan los activos Tier 0. Unas semanas después, un operador puede añadir un miembro temporal a Domain Admins, anidar un grupo de soporte en un grupo privilegiado, delegar WriteDACL sobre una OU o conceder derechos de replicación a una cuenta de migración. Si el cambio no se elimina y no se vuelve a medir, el resultado de la revisión queda obsoleto.
El punto clave es que el privilegio en Active Directory no se almacena en un único sitio. La pertenencia a grupos es la capa visible, pero solo forma parte del plano de control. Un principal puede volverse peligroso porque es miembro directo de un grupo privilegiado, porque llega a él por anidamiento, porque puede modificar la pertenencia del grupo, porque puede reescribir el descriptor de seguridad de un objeto, porque tiene derechos de replicación compatibles con DCSync o porque puede influir en cuentas protegidas por AdminSDHolder. Por eso un artículo sobre cuentas obsoletas y sobreprivilegiadas es útil, pero no basta para cubrir toda la deriva de acceso privilegiado.
Una revisión de deriva debe hacer una pregunta precisa: ¿quién puede afectar a identidades privilegiadas, grupos privilegiados, controladores de dominio, permisos en la raíz del dominio, Group Policy, servicios de certificados y otras superficies de control Tier 0 ahora mismo? La respuesta debe incluir administradores directos, administradores indirectos, operadores delegados, cuentas de servicio y principals con rutas ACL peligrosas.
Por qué las revisiones anuales no ven la deriva AD
Las revisiones anuales o trimestrales son fotografías puntuales. Son útiles para gobierno, pero débiles para detectar un directorio que cambia cada semana. Los cambios de pertenencia a grupos de Active Directory son auditables, y Microsoft documenta eventos de gestión de grupos de seguridad, incluidos eventos de miembros añadidos y eliminados en grupos globales, locales y universales. Los cambios de objetos de directorio también pueden auditarse mediante eventos de cambios del servicio de directorio, y el acceso a objetos puede exponer operaciones sensibles cuando la auditoría y las SACL están configuradas. Esos logs muestran que AD no es estático.
El problema práctico es que muchas revisiones siguen trabajando con exportaciones. Una hoja de cálculo de Domain Admins del mes pasado no muestra que ayer se añadió un grupo anidado. Una lista de usuarios privilegiados no muestra que un grupo de helpdesk puede modificar la pertenencia de un grupo admin. Una revisión manual de cuentas deshabilitadas no muestra que una cuenta de servicio aún conserva DS-Replication-Get-Changes y DS-Replication-Get-Changes-All sobre el contexto de nombres del dominio.
Por eso también importan los flujos de auditoría recurrente de Active Directory. Si los mismos controles se ejecutan una vez al año, la organización sabe qué estaba mal en la fecha de la auditoría. Si los controles se vuelven a ejecutar tras cambios y remediaciones, la organización puede ver si el modelo privilegiado sigue limpio o vuelve a derivar.
Cómo aparece la deriva del acceso privilegiado
La pertenencia temporal se vuelve permanente
La respuesta a incidentes, las migraciones, la configuración de copias de seguridad y el soporte urgente de aplicaciones pueden requerir derechos elevados. El riesgo no es la excepción en sí; el riesgo es una excepción sin propietario, sin caducidad y sin revalidación. Active Directory seguirá respetando esa pertenencia hasta que alguien la elimine.
El anidamiento de grupos oculta el privilegio efectivo
Un grupo puede parecer inofensivo de forma aislada y volverse privilegiado cuando se anida en Account Operators, Backup Operators, Domain Admins, Enterprise Admins u otro grupo sensible. El acceso anidado también complica las revisiones porque los miembros efectivos no aparecen en la primera pantalla del grupo. Un grupo privilegiado debe revisarse por pertenencia efectiva, no solo por miembros directos.
La deriva de ACL crea rutas de control
La autorización de Active Directory depende en gran medida de discretionary access control lists. GenericAll, WriteDACL, WriteOwner, AddMember, Self-Membership y derechos similares pueden convertir un principal no administrador en administrador práctico sobre objetos concretos. En una revisión de rutas de ataque, la pregunta no es solo quién está en Domain Admins. Es quién puede cambiar un principal, un grupo, una GPO, un equipo, una OU o una ACL que lleva a Tier 0. La misma lógica aplica al revisar abuso de ACL y rutas DCSync.
Los derechos de replicación amplían la exposición de credenciales
MITRE documenta DCSync dentro de OS Credential Dumping porque un adversario con derechos suficientes de replicación de directorio puede imitar el comportamiento de replicación de un controlador de dominio para obtener material de credenciales. Los defensores deben revisar principals con DS-Replication-Get-Changes y DS-Replication-Get-Changes-All, además de cualquier derecho de replicación específico del entorno que aplique a secretos protegidos.
Los cambios en AdminSDHolder son sensibles para persistencia
Microsoft Open Specifications describe AdminSDHolder como el objeto usado por el sistema para gestionar descriptores de seguridad de objetos administrativos protegidos. Si se modifica el descriptor de seguridad de AdminSDHolder, el impacto puede propagarse a cuentas y grupos protegidos mediante el mecanismo SDProp. Eso convierte AdminSDHolder en un objeto sensible para persistencia, no en un contenedor administrativo normal.
Las cuentas de servicio y la cuenta integrada añaden riesgo duradero
Una cuenta de servicio en un grupo privilegiado puede ser más difícil de rotar, más difícil de vincular a un propietario humano y más fácil de olvidar. La cuenta Administrator integrada con RID 500 no debería convertirse en la identidad administrativa de uso diario. Si se ha usado recientemente, trátalo como una excepción que necesita explicación, no como prueba de compromiso por sí sola.
Rutas de ataque creadas por la deriva de privilegios
La deriva de privilegios importa porque crea rutas, no solo listas de acceso desordenadas. Una cuenta admin adicional es un objetivo de credenciales. Un grupo de soporte anidado puede convertirse en una ruta oculta hacia Domain Admins. Un permiso WriteDACL puede permitir que un principal se otorgue derechos más fuertes. Un permiso WriteOwner puede permitir que un principal tome propiedad y luego cambie la ACL. Derechos AddMember sobre un grupo privilegiado pueden bastar para añadir una cuenta controlada a ese grupo.
La deriva compatible con DCSync es especialmente sensible. Si un principal que no es controlador de dominio tiene derechos de replicación que permiten comportamiento DCSync, restablecer contraseñas de usuarios individuales no basta. La organización debe eliminar los derechos de replicación, investigar si se expuso material de credenciales y rotar los secretos afectados según el alcance de respuesta a incidentes.
La delegación y la infraestructura de identidad pueden ampliar el efecto. Una cuenta de equipo privilegiada, una cuenta de servicio sobredelgada o una ruta de delegación Kerberos mal gestionada puede conectar la deriva de privilegios con movimiento lateral. Por eso el análisis de deriva debe correlacionarse con riesgos de delegación Kerberos, gestión de contraseñas de administrador local como Windows LAPS y rutas de ataque AD CS cuando los servicios de certificados están en alcance.
| Superficie de deriva | Pregunta práctica | Evidencia de validación |
|---|---|---|
| Grupos privilegiados | ¿Quién es miembro directo o anidado efectivo? | Propietario aprobado, ticket, caducidad y pertenencia efectiva actual |
| ACL de directorio | ¿Quién puede modificar objetos privilegiados o sus descriptores de seguridad? | Diff de ACL, revisión del trustee, fuente de herencia y propietario de negocio |
| Derechos de replicación | ¿Quién puede realizar operaciones de replicación del dominio? | Solo DC esperados y principals de replicación aprobados |
| AdminSDHolder | ¿Quién puede influir en objetos administrativos protegidos? | Descriptor de seguridad esperado y ausencia de ACE no autorizadas |
Detección
Ningún evento Windows individual prueba la deriva de acceso privilegiado. La detección debe combinar una línea base de acceso privilegiado esperado, el estado actual del directorio, análisis de ACL y telemetría de cambios recientes.
Inventariar primero el privilegio efectivo
Empieza con un inventario efectivo de acceso privilegiado. Enumera pertenencia directa y anidada de grupos privilegiados. Incluye grupos privilegiados integrados, grupos administrativos del dominio, grupos que administran controladores de dominio, grupos de operaciones de backup o servidores que pueden afectar activos Tier 0 y cualquier grupo admin propio de la organización. Compara el resultado con una línea base aprobada con propietarios nominados.
Revisar permisos fuera de la pertenencia a grupos
Después inspecciona permisos, no solo pertenencias. Revisa ACL en la raíz del dominio, AdminSDHolder, controladores de dominio, grupos privilegiados, usuarios privilegiados, OU sensibles, GPO y cuentas de servicio de alto impacto. Presta atención a derechos que permiten modificar pertenencias o descriptores de seguridad, incluidos GenericAll, WriteDACL, WriteOwner, AddMember, Self-Membership, Write Property y Control Access. Para replicación, revisa DS-Replication-Get-Changes y DS-Replication-Get-Changes-All en el contexto de nombres del dominio.
Correlacionar eventos sin sobreafirmar
Microsoft documenta la categoría Audit Security Group Management y los eventos individuales usados para altas y bajas de miembros. Los eventos 4728 y 4729 cubren cambios de miembros en grupos globales de seguridad, 4732 y 4733 cubren grupos locales de seguridad, y 4756 y 4757 cubren grupos universales de seguridad. Estos eventos son útiles cuando el grupo privilegiado o anidado está en alcance.
Para cambios de directorio, el evento 5136 registra modificaciones de objetos del servicio de directorio cuando la auditoría adecuada está habilitada. Puede ayudar a identificar atributos modificados, como pertenencia de grupo o descriptores de seguridad, según lo auditado. El evento 4662 puede ayudar con acceso auditado a objetos y operaciones sensibles de directorio, incluidos contextos Write Property, Control Access, WRITE_DAC y WRITE_OWNER cuando las SACL están configuradas. Trata estos eventos como evidencia de correlación, no como veredictos autónomos.
Finalmente, conecta la telemetría con la intención. Un cambio de grupo privilegiado realizado por una solicitud de acceso documentada puede ser esperado. El mismo cambio fuera de ventana de mantenimiento, realizado por un operador inusual o seguido de nueva actividad de autenticación en controladores de dominio merece investigación. Para un mapeo más amplio, usa una guía de monitorización como eventos clave de seguridad AD para mantener explícitos los nombres, alcances y límites de los eventos.
Remediation y remediación operativa
La remediación debe eliminar la ruta y corregir el proceso que permitió que volviera.
Eliminar rutas de grupos y documentar excepciones
Para deriva de pertenencia a grupos, elimina miembros directos no aprobados y deshaz anidamientos peligrosos. Hazlo contra la pertenencia efectiva, no solo la directa. Si un grupo anidado sigue siendo necesario, documenta propietario, propósito, ruta de aprobación y cadencia de revisión. Evita dejar principals amplios como Authenticated Users o grupos operativos demasiado grandes dentro de grupos privilegiados.
Eliminar ACL peligrosas con cuidado
Para deriva de ACL, no borres permisos a ciegas. Primero identifica objeto, trustee, derecho, fuente de herencia y propietario de negocio. Después elimina derechos que crean control administrativo sin propósito documentado. Prioriza GenericAll, WriteDACL, WriteOwner, AddMember, Self-Membership, derechos Write Property excesivos y derechos Control Access sobre objetos Tier 0. Tras eliminarlos, verifica que la delegación operativa aún funciona para tareas legítimas.
Revocar rutas de replicación y persistencia
Para principals compatibles con DCSync, elimina derechos de replicación de cualquier cuenta o grupo que no esté explícitamente aprobado para ese rol. Los controladores de dominio necesitan replicación. Algunos escenarios de identidad, migración o backup pueden requerir derechos cuidadosamente acotados, pero esas excepciones deben ser raras, tener propietario, estar monitorizadas y revisarse. Si existía capacidad DCSync sospechosa, trata la limpieza como una cuestión de exposición de credenciales, no solo como limpieza de ACL.
Para deriva de AdminSDHolder, compara el descriptor de seguridad con la línea base esperada e investiga cómo cambió. Como AdminSDHolder afecta a objetos administrativos protegidos, trata permisos inesperados como sensibles para persistencia. Elimina entradas no autorizadas y luego valida permisos de cuentas protegidas después de que SDProp haya tenido tiempo de reaplicar el descriptor previsto.
Reducir exposición de identidades privilegiadas permanentes
Para identidades privilegiadas, reduce el acceso permanente. Separa cuentas de usuario diarias de cuentas administrativas. Revisa cuentas de servicio privilegiadas y elimínalas de grupos admin cuando sea posible. Reserva la cuenta Administrator RID 500 para escenarios break-glass o de emergencia e investiga su uso rutinario reciente. Considera el grupo Protected Users para cuentas humanas privilegiadas adecuadas, pero prueba compatibilidad primero porque Microsoft documenta cambios y restricciones de comportamiento de autenticación para sus miembros.
Para deriva de proceso, exige caducidad y propiedad para excepciones. Un AD limpio tras remediación volverá a derivar si el acceso temporal no tiene mecanismo de retirada. El control debe responder quién aprobó el privilegio, por qué existe, cuándo caduca y qué evidencia demuestra que se eliminó.
Validación después de la limpieza
La validación es donde fallan muchos esfuerzos de remediación. Eliminar un miembro visible de Domain Admins no basta si permanece un grupo anidado, una ACL o un derecho de replicación.
Recalcular la pertenencia efectiva
Después de limpiar, vuelve a ejecutar el inventario de pertenencia efectiva. Confirma que los grupos privilegiados solo tienen miembros directos e indirectos aprobados. Confirma que ningún principal amplio está presente en un grupo privilegiado. Confirma que cuentas privilegiadas creadas recientemente y cambios recientes de grupos privilegiados coinciden con tickets o registros de incidente aprobados.
Revisar de nuevo ACL y rutas de replicación
Después repite la revisión de ACL. Confirma que GenericAll, WriteDACL, WriteOwner, AddMember, Self-Membership y derechos de replicación eliminados no reaparecieron por herencia, anidamiento de grupos o proceso de plantilla. Confirma que AdminSDHolder ya no contiene entradas inesperadas y que los objetos protegidos reflejan el descriptor de seguridad previsto.
Validar telemetría tras la remediación
Finalmente, valida la telemetría. Busca nuevos cambios de pertenencia a grupos después de la limpieza. Revisa modificaciones de objetos de directorio sobre objetos sensibles. Confirma que cualquier excepción permitida tiene propietario y fecha de revisión. El objetivo no es probar que ningún cambio futuro pueda ocurrir. El objetivo es probar que los derechos efectivos actuales coinciden con la línea base y que los cambios futuros serán visibles.
Si estás creando un programa de auditoría más amplio, alinea esta validación con cómo auditar la seguridad de Active Directory para medir la deriva privilegiada junto con autenticación, delegación, AD CS, GPO, contraseñas y controles de monitorización.
Cómo EtcSec detecta la deriva de acceso privilegiado
EtcSec identifica y vuelve a medir condiciones de deriva de acceso privilegiado en la postura AD actual. Los controles relevantes del catálogo cubren cuentas privilegiadas, grupos, ACL, derechos de replicación y AdminSDHolder en lugar de tratar la deriva como un único síntoma.
Para deriva de cuentas y uso, EtcSec comprueba condiciones como PRIVILEGED_ACCOUNT_STALE, ADMIN_NATIVE_RECENT_LOGON, EXCESSIVE_PRIVILEGED_ACCOUNTS y RECENT_PRIVILEGED_CREATION. Umbrales como 90 días para cuentas privilegiadas inactivas, 30 días para uso reciente de la cuenta Administrator integrada, 10 días para cuentas privilegiadas creadas recientemente o 7 días para cambios recientes en grupos privilegiados son umbrales de política del catálogo. No deben describirse como estándares de Microsoft.
Para deriva de grupos, EtcSec comprueba GROUP_EVERYONE_IN_PRIVILEGED, GROUP_AUTHENTICATED_USERS_PRIVILEGED, DANGEROUS_GROUP_NESTING y PRIVILEGED_GROUP_MEMBER_CHANGES. Estos findings ayudan a distinguir una lista de miembros directos aparentemente limpia de una ruta de privilegio efectiva creada por principals amplios o grupos anidados.
Para deriva de ACL y replicación, EtcSec comprueba DCSYNC_CAPABLE, ACL_GENERICALL, ACL_WRITEDACL, ACL_WRITEOWNER, ACL_SELF_MEMBERSHIP, ACL_ADD_MEMBER, ADMIN_SD_HOLDER_MODIFIED y ADMINSDHOLDER_BACKDOOR. Estos findings mapean las superficies de control que los defensores deben volver a medir tras limpiar: derechos de replicación, derechos de modificación de grupos, control de descriptores de seguridad y persistencia sobre administradores protegidos.
EtcSec no sustituye la investigación SIEM ni la respuesta a incidentes. Su papel en este flujo es la medición de postura: identificar la condición riesgosa, explicar por qué importa, seguir la remediación y medir si la condición vuelve tras el siguiente cambio del directorio.
Controles relacionados
La deriva de acceso privilegiado es más fácil de controlar cuando se trata como un problema recurrente de postura. Una revisión de acceso puntual puede eliminar cuentas admin obvias; un flujo recurrente puede detectar cuándo vuelven los mismos derechos.
Usa higiene de cuentas privilegiadas para reducir el número de identidades que pueden convertirse en objetivos de credenciales de alto valor. Usa revisión de ACL y DCSync para detectar rutas que no aparecen en informes de pertenencia a grupos. Usa eventos de monitorización para validar cuándo ocurrieron los cambios y quién los realizó. Usa controles de contraseñas de administrador local como Windows LAPS para reducir el impacto de credenciales admin locales reutilizadas mientras trabajas en las rutas de privilegio de dominio.
El objetivo operativo es simple: cada ruta privilegiada debe ser intencional, tener propietario, ser mínima y revalidarse. Todo lo demás es deriva.
Referencias primarias
- Microsoft Learn: Audit Security Group Management
- Microsoft Learn: Event 4728 - A member was added to a security-enabled global group
- Microsoft Learn: Event 4729 - A member was removed from a security-enabled global group
- Microsoft Learn: Event 4732 - A member was added to a security-enabled local group
- Microsoft Learn: Event 4733 - A member was removed from a security-enabled local group
- Microsoft Learn: Event 4756 - A member was added to a security-enabled universal group
- Microsoft Learn: Event 4757 - A member was removed from a security-enabled universal group
- Microsoft Learn: Event 5136 - A directory service object was modified
- Microsoft Learn: Event 4662 - An operation was performed on an object
- Microsoft Open Specifications: AdminSDHolder
- Microsoft Learn: Protected Users security group
- MITRE ATT&CK: Account Manipulation T1098
- MITRE ATT&CK: DCSync T1003.006
- Catálogo local EtcSec: Active Directory vulnerability catalogue - docs/vulnerabilities/active-directory/AD_VULNERABILITY_CATALOG.md
Continue Reading
Auditoría recurrente de Active Directory: por qué las auditorías anuales se vuelven obsoletas y cómo monitorizar la postura de forma continua
Guía ANSSI Active Directory: cómo aplicar las recomendaciones de seguridad en la práctica
