AdminSDHolder SDProp Backdoor Active Directory: el proceso horario para un acceso privilegiado permanente

Qué son AdminSDHolder y SDProp

AdminSDHolder SDProp backdoor Active Directory persistence es la técnica que esta guía explica en profundidad: cómo los atacantes implantan un acceso privilegiado permanente, cómo lo detectan los defensores y cómo remediarlo antes de que se convierta en un riesgo permanente. AdminSDHolder es un objeto contenedor que reside en CN=AdminSDHolder,CN=System,DC=<dominio>,DC=<tld> en cada dominio de AD, y SDProp — el Security Descriptor Propagator — es el proceso en segundo plano que copia su ACL en cada objeto que protege, por defecto una vez por hora (Microsoft Learn — Appendix C: Protected Accounts and Groups in Active Directory).

SDProp se ejecuta cada 60 minutos (por defecto) en el controlador de dominio que ostenta el rol de PDC Emulator (PDCE). Compara los permisos de AdminSDHolder con los permisos de las cuentas y grupos protegidos del dominio — y donde difieren, sobrescribe la ACL del objeto para que coincida exactamente con la de AdminSDHolder. El intervalo se controla mediante el valor DWORD AdminSDProtectFrequency bajo HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters en el PDCE, válido de 60 a 7200 segundos; la mayoría de los entornos nunca lo tocan y simplemente funcionan con el valor por defecto de 60 minutos.

Los siguientes grupos y cuentas integrados están protegidos por AdminSDHolder/SDProp en todos los dominios de AD:

Dos efectos secundarios marcan a todo objeto protegido: el atributo adminCount se establece en 1, y la herencia de ACL desde la OU padre se desactiva de forma permanente — hasta que algo la borre explícitamente. Microsoft diseñó SDProp para evitar que las cuentas privilegiadas hereden silenciosamente permisos más débiles si alguien las mueve dentro del directorio. Es el mismo mecanismo subyacente que los atacantes ya explotan para el abuso de ACL y DCSync en objetos individuales — este backdoor simplemente traslada el abuso un nivel más arriba, al objeto plantilla que alimenta a la vez a cada cuenta protegida.

AdminSDHolder SDProp Backdoor Active Directory, Paso a Paso

La técnica no es nueva — Sean Metcalf la documentó en 2015 — y hoy sigue funcionando exactamente como se describió entonces, porque abusa de un mecanismo intencional en lugar de un bug (AD Security — Sneaky Active Directory Persistence #15). A diferencia de otras rutas de ataque de Active Directory que encadenan varias configuraciones erróneas para llegar a Domain Admin, esta solo necesita una única escritura sobre un único objeto.

Paso 1 — Añadir una ACE Maliciosa a AdminSDHolder

Un atacante que ya puede escribir en CN=AdminSDHolder,CN=System,DC=... — típicamente porque es Domain Admin/Enterprise Admin, o porque obtuvo WriteDacl/GenericWrite sobre él mediante un abuso de ACL previo — otorga a una cuenta de bajo privilegio o desechable Full Control (o GenericAll) directamente sobre el objeto AdminSDHolder. En el artículo original de Metcalf, a una cuenta de usuario ordinaria se le otorga control total sobre el propio AdminSDHolder. Nada cambia respecto a esa cuenta — sigue sin ser miembro de ningún grupo privilegiado, y sigue pareciendo normal en una revisión rutinaria de membresías de grupo.

Paso 2 — Esperar (o Forzar) a que SDProp la Propague

En su siguiente ciclo — hasta 60 minutos después — SDProp copia la ACL de AdminSDHolder, ACE maliciosa incluida, en cada cuenta y grupo con adminCount=1: Domain Admins, Enterprise Admins, el objeto de usuario de cada miembro existente, y cualquier cuenta añadida a esos grupos posteriormente. La cuenta desechable nunca necesita unirse a Domain Admins; solo necesita derechos de modificación sobre los objetos que importan. El ciclo también puede forzarse de inmediato — por un administrador que prueba un cambio, o por un atacante impaciente por confirmar que el backdoor funcionó — mediante Ldp.exe, estableciendo el atributo RunProtectAdminGroupsTask en 1 en el rootDSE (Microsoft Learn — Appendix C).

Paso 3 — Seguir Usando Derechos que Nunca Aparecen como Membresía de Grupo

Como la ACE reside en el objeto plantilla en lugar de en una única cuenta, vuelve a aparecer cada vez que se ejecuta SDProp — incluso después de que un defensor detecte el permiso malicioso en el objeto de usuario de un Domain Admin y lo elimine allí. A menos que el arreglo se aplique al propio AdminSDHolder, el siguiente ciclo de SDProp lo reaplica silenciosamente en todas partes. Eso es lo que convierte esto en persistencia y no en una escalada de privilegios puntual: las rotaciones de contraseña, la desactivación de cuentas o la eliminación de la cuenta del atacante de Domain Admins no sirven de nada, porque esa cuenta nunca fue miembro — obtuvo derechos a través de la plantilla de ACL. Esto también es lo que la distingue del anidamiento peligroso de grupos habitual: el anidamiento se esconde en la membresía de grupo, esta técnica se esconde en una única ACL que la mayoría de los administradores nunca piensa en revisar.

Los defensores pueden inventariar objetivos candidatos y artefactos residuales de esta técnica con una única consulta LDAP:

Get-ADObject -LDAPFilter "(&(admincount=1)(|(objectcategory=person)(objectcategory=group)))" -Properties MemberOf,Created,Modified,AdminCount

Cualquier resultado cuyo MemberOf ya no incluya un grupo protegido, o cuyos permisos efectivos parezcan no guardar relación con su función real, merece ser investigado antes de asumir que se trata de deuda de limpieza legítima.

Detección

El mecanismo solo afecta a un objeto, por lo que la detección es estrecha pero fiable — siempre que ya existan la política de auditoría y la SACL adecuadas.

Dos condiciones deben cumplirse antes de que el evento 5136 se dispare: la subcategoría Política de auditoría avanzada → DS Access → Auditar cambios del servicio de directorio debe estar habilitada, y debe existir una SACL que cubra el descriptor de seguridad (o "Write All Properties") en el propio objeto AdminSDHolder. Ninguna de las dos está habilitada por defecto en la mayoría de los entornos. La regla de detección publicada por Elastic para esta técnica exacta depende de que ambas estén configuradas antes de poder dispararse — su consulta es event.code:5136 and host.os.type:"windows" and winlog.event_data.ObjectDN:CN=AdminSDHolder,CN=System*, mapeada a MITRE ATT&CK T1098 (Account Manipulation) y T1078.002 (Valid Accounts: Domain Accounts), con severidad alta (Elastic — AdminSDHolder Backdoor detection rule). La regla equivalente de Splunk Security Content confirma la misma lógica 5136/nTSecurityDescriptor y el mismo requisito de SACL (Splunk Security Content — Windows AD AdminSDHolder ACL Modified).

Auditar la ACL Directamente

Los registros de eventos solo ayudan una vez que la auditoría está activada — una revisión puntual de la ACL funciona independientemente de la política de auditoría y es una primera comprobación razonable en un entorno que nunca ha habilitado la auditoría de cambios del servicio de directorio:

Get-Acl -Path "AD:\CN=AdminSDHolder,CN=System,DC=corp,DC=local" | Select-Object -ExpandProperty Access

Revise cada entrada del resultado comparándola con la línea base conocida de la sección de remediación más abajo. Cualquier entrada que no sea un principal integrado conocido merece ser escalada de inmediato, independientemente de si el registro ya está en marcha.

Remediación

Respuesta Inmediata

1. Audite la ACL de AdminSDHolder ahora mismo. Compare sus trustees con una línea base conocida (Domain Admins, Enterprise Admins, Administrators, SYSTEM, y cualquier cuenta de servicio delegada explícitamente) y elimine cualquier elemento inesperado — como dijo Metcalf, "estos deberían mantenerse en su valor por defecto".
2. Fuerce a SDProp a ejecutarse de inmediato tras la remediación, mediante Ldp.exe → RunProtectAdminGroupsTask=1 en el rootDSE, en lugar de esperar hasta 60 minutos para confirmar que el arreglo se propagó (Microsoft Learn — Appendix C).

Fortalecimiento Continuo

3. Habilite la auditoría de cambios del servicio de directorio y establezca una SACL en AdminSDHolder para que las futuras modificaciones generen el evento 5136, según la sección de detección anterior.
4. Inventaríe cada objeto con adminCount=1 con la consulta LDAP mostrada anteriormente y concíliela con la membresía actual de grupos protegidos. Para las cuentas confirmadas como ya no pertenecientes a un grupo protegido, borre adminCount y reactive la herencia solo después de confirmar que la membresía del grupo ya ha desaparecido — borrarlo primero permitiría que SDProp revierta el arreglo en su siguiente ejecución. Estas cuentas huérfanas son la misma deuda de limpieza cubierta en Cuentas Obsoletas y Sobreprivilegiadas.
5. Restrinja quién puede escribir en AdminSDHolder. Por defecto solo Domain Admins, Enterprise Admins y Administrators pueden modificarlo o tomar posesión de él — mantenga esto así. Cualquier GenericWrite o WriteDacl delegado sobre el contenedor System, o sobre AdminSDHolder específicamente, es un riesgo permanente y debe tratarse como Tier 0.

Cómo Detecta Esto EtcSec

La auditoría de Active Directory de EtcSec comprueba ADMIN_SD_HOLDER_MODIFIED para trustees inesperados o derechos peligrosos (Full Control, GenericAll, WriteDacl, WriteOwner) en la ACL del objeto AdminSDHolder, ADMINSDHOLDER_BACKDOOR para el patrón específico de un principal no privilegiado con esos derechos, y ADMIN_COUNT_ORPHANED para cuentas que siguen marcadas como adminCount=1 tras abandonar un grupo protegido — deuda de limpieza que a la vez oculta backdoors genuinos e infla su recuento de cuentas privilegiadas. Este backdoor rara vez aparece solo: se encuentra con frecuencia junto a una deriva más amplia del acceso privilegiado, por lo que ambas comprobaciones merecen ejecutarse juntas como parte de una auditoría rutinaria en lugar de tratarse como hallazgos aislados.