AdminSDHolder y SDProp: limpieza y supervisión

AdminSDHolder es la ACL plantilla de todas las cuentas privilegiadas de un dominio. Una vez por hora, el proceso SDProp del emulador de PDC la copia en cada miembro de los grupos protegidos. Eso lo convierte en uno de los puntos de persistencia más eficaces de Active Directory. Un atacante que añade una sola ACE a CN=AdminSDHolder,CN=System consigue que ese derecho se vuelva a aplicar a todos los Domain Admins para siempre, incluso después de que los defensores limpien las cuentas una por una. El mismo mecanismo deja además un rastro de cuentas huérfanas con adminCount=1, herencia deshabilitada y ACL privilegiadas obsoletas.

La guía principal sobre ACL explica qué hace SDProp y ofrece una primera consulta para detectar adminCount obsoletos. Esta guía es la continuación operativa. Cubre el conjunto exacto de objetos protegidos, una línea base de la ACL de AdminSDHolder, un procedimiento de limpieza seguro, la ejecución de SDProp a demanda y alertas que detectan manipulaciones.

Qué protege SDProp

En los dominios de Windows Server 2016 y posteriores, SDProp protege estos objetos y los miembros transitivos de estos grupos:

• Grupos: Account Operators, Administrators, Backup Operators, Domain Admins, Domain Controllers, Enterprise Admins, Enterprise Key Admins, Key Admins, Print Operators, Read-only Domain Controllers, Replicator, Schema Admins, Server Operators.
• Usuarios: Administrator (RID 500) y krbtgt.

Cada ejecución de SDProp:

1. Lee el descriptor de seguridad de CN=AdminSDHolder,CN=System,<domain>.
2. Para cada objeto protegido y cada miembro transitivo, compara la ACL y la sobrescribe si difiere. La herencia se deshabilita en el objeto.
3. Establece adminCount=1.

Nunca revierte los pasos 2 y 3 cuando una cuenta sale de un grupo protegido. De forma predeterminada, el emulador de PDC lo ejecuta cada 60 minutos. El intervalo lo define AdminSDProtectFrequency (en segundos) en HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.

El anidamiento importa. Un grupo de seguridad anidado en Domain Admins está protegido, y sus miembros también. Un usuario que es miembro solo por la asignación de grupo principal es un caso límite bien conocido. Compruebe siempre la pertenencia efectiva, no solo el atributo member.

Medir: establecer la línea base de la ACL de AdminSDHolder

Exporte la ACL actual y consérvela como artefacto firmado y fechado:

$dn  = "CN=AdminSDHolder,CN=System," + (Get-ADDomain).DistinguishedName
$acl = Get-Acl -Path "AD:\$dn"
$acl.Sddl | Out-File "C:\Tier0\Baseline\AdminSDHolder-$(Get-Date -f yyyyMMdd).sddl"

$acl.Access | Select-Object IdentityReference, ActiveDirectoryRights, ObjectType,
    InheritedObjectType, AccessControlType, IsInherited |
    Sort-Object IdentityReference | Format-Table -AutoSize
$acl.Owner

Compárela con un dominio de laboratorio recién creado con el mismo nivel funcional y los mismos productos opcionales (Exchange, por ejemplo, añade sus propias ACE). Es normal encontrar ACE para SYSTEM, Administrators, Domain Admins y Enterprise Admins, acceso de lectura para Authenticated Users y Pre-Windows 2000 Compatible Access, Change Password para Everyone y SELF, y derechos de propiedad acotados para Cert Publishers, Windows Authorization Access Group y Terminal Server License Servers. El propietario debe ser Domain Admins.

Compruebe también dos propiedades estructurales. El objeto AdminSDHolder tiene normalmente la herencia deshabilitada, para que las ACE establecidas en el contenedor System o en la raíz del dominio no fluyan hacia él. Si alguien ha activado la herencia, toda delegación amplia en la raíz del dominio pasa a formar parte de la plantilla de sus administradores. Compruebe también el propietario. Un propietario siempre puede reescribir la DACL, así que un propietario no predeterminado es tan grave como una ACE WriteDacl. Registre ambas cosas en la línea base junto al SDDL para que la comparación semanal las cubra.

Todo lo que quede fuera de ese conjunto, en especial GenericAll, GenericWrite, WriteDacl, WriteOwner, WriteProperty sobre member o ResetPassword (00299570-246d-11d0-a768-00aa006e0529), necesita una explicación. Una cuenta de usuario o un grupo desconocido con derechos de escritura sobre AdminSDHolder debe tratarse como un compromiso mientras no se demuestre lo contrario.

Auditar: encontrar las huérfanas

Construya la lista de objetos que SDProp protege actualmente y compárela con todo lo que tenga adminCount=1. La guía principal solo revisa usuarios. Aquí se incluyen grupos y equipos, y los grupos protegidos se resuelven por su SID conocido para que la consulta funcione en cualquier idioma:

$domSid = (Get-ADDomain).DomainSID.Value
$protectedGroupSids = @(
    'S-1-5-32-544','S-1-5-32-548','S-1-5-32-549','S-1-5-32-550','S-1-5-32-551','S-1-5-32-552',
    "$domSid-512","$domSid-516","$domSid-521","$domSid-526"
)
$forestRootSid = (Get-ADDomain (Get-ADForest).RootDomain).DomainSID.Value
$protectedGroupSids += "$forestRootSid-518","$forestRootSid-519","$forestRootSid-527"

$protected = [System.Collections.Generic.HashSet[string]]::new()
foreach ($sid in $protectedGroupSids) {
    $g = Get-ADGroup -Filter "objectSid -eq '$sid'" -ErrorAction SilentlyContinue
    if (-not $g) { continue }
    [void]$protected.Add($g.DistinguishedName)
    Get-ADGroupMember $g -Recursive | ForEach-Object { [void]$protected.Add($_.distinguishedName) }
    # los grupos anidados también están protegidos
    Get-ADGroup -LDAPFilter "(memberOf:1.2.840.113556.1.4.1941:=$($g.DistinguishedName))" |
        ForEach-Object { [void]$protected.Add($_.DistinguishedName) }
}

Get-ADObject -LDAPFilter '(adminCount=1)' -Properties adminCount, objectClass, whenChanged, nTSecurityDescriptor |
    Where-Object { -not $protected.Contains($_.DistinguishedName) -and $_.Name -notin 'Administrator','krbtgt' } |
    Select-Object Name, objectClass, whenChanged,
        @{ n = 'InheritanceBlocked'; e = { $_.nTSecurityDescriptor.AreAccessRulesProtected } },
        DistinguishedName

Enterprise Admins, Schema Admins y Enterprise Key Admins residen en el dominio raíz del bosque, por eso sus SID usan el SID del dominio raíz. En un dominio secundario, los miembros de Enterprise Admins siguen protegidos porque Enterprise Admins es miembro del grupo Administrators del dominio secundario.

Las huérfanas típicas son antiguos administradores que cambiaron de puesto, cuentas de servicio añadidas «temporalmente» a Domain Admins, grupos que se anidaron y luego se quitaron y, en dominios más antiguos, cuentas que estuvieron en Account Operators o Print Operators.

Por qué adminCount no es un inventario fiable de administradores

Es tentador usar adminCount=1 como lista de cuentas privilegiadas. Es un error en ambos sentidos. Incluye huérfanas, como se ha visto. Y también se le escapan privilegios reales. Una cuenta con GenericAll sobre Domain Admins, un usuario con derechos de DCSync, un miembro de un grupo que controla un GPO vinculado a la OU Domain Controllers y la cuenta del conector de Entra Connect pueden tener el control total del dominio sin haber estado nunca en un grupo protegido. SDProp nunca los toca, así que tienen adminCount sin establecer, la herencia activada y las delegaciones que conceda su OU.

Use adminCount para lo que es: un indicio de pertenencia pasada a un grupo protegido y una cola de limpieza. Su inventario real de Tier 0 procede de las relaciones de control, que es lo que mide el análisis de rutas de ataque.

Aplicar: limpiar bien las huérfanas

Para cada huérfana, confirme con su responsable que ya no necesita privilegios. Después, haga tres cosas a la vez, porque hacer solo una deja el problema a medio resolver:

1. Restablezca la ACL explícita al valor predeterminado del esquema para su clase de objeto. Así se eliminan las ACE copiadas de AdminSDHolder.
2. Vuelva a habilitar la herencia, para que se apliquen de nuevo las delegaciones de la OU y las ACL de su modelo de niveles.
3. Borre adminCount.

$dn = (Get-ADUser 'j.smith-old-admin').DistinguishedName

# 1. Copia de seguridad y, después, restablecer el descriptor de seguridad predeterminado del esquema
(Get-Acl "AD:\$dn").Sddl | Out-File "C:\Tier0\Backup\$(Get-Date -f yyyyMMdd)-j.smith.sddl"
dsacls $dn /S

# 2. Asegurarse de que la herencia está activada (dsacls /S normalmente la deja activada; se fuerza igualmente)
$acl = Get-Acl "AD:\$dn"
$acl.SetAccessRuleProtection($false, $false)
Set-Acl "AD:\$dn" -AclObject $acl

# 3. Borrar la marca
Set-ADObject $dn -Clear adminCount

Cambie también la contraseña de la cuenta. Fue privilegiada y sus credenciales pueden haber quedado en caché en sistemas fuera del Tier 0. Plantéese si la cuenta debe seguir existiendo.

Otros dos pasos de hardening reducen las huérfanas futuras:

• Vacíe los grupos de operadores. Account Operators, Server Operators, Print Operators y Backup Operators otorgan derechos amplios en los DC y están protegidos. Sustitúyalos por delegaciones acotadas en las OU. Es mejor que excluirlos de SDProp mediante la máscara de dSHeuristics.
• Deje de usar grupos protegidos para las cuentas de servicio. Conceda en su lugar los derechos concretos necesarios, como se describe en definir el Tier 0.

Ejecutar SDProp a demanda

Tras modificar AdminSDHolder o hacer una limpieza, desencadene una ejecución en el emulador de PDC en lugar de esperar hasta una hora. En Windows Server 2008 R2 y posteriores, escriba el atributo operativo runProtectAdminGroupsTask en el rootDSE:

$pdc = (Get-ADDomain).PDCEmulator
$root = [ADSI]"LDAP://$pdc/RootDSE"
$root.Put('runProtectAdminGroupsTask', 1)
$root.SetInfo()

Requiere derechos de Domain Admin y se ejecuta de forma asíncrona.

Verificar y supervisar

Vuelva a ejecutar la consulta de huérfanas. Solo debería devolver las cuentas que haya aceptado explícitamente. Después, configure la supervisión continua:

• SACL en AdminSDHolder. Añada una entrada de auditoría para Everyone, Success, con Write all properties, Modify permissions y Modify owner sobre el objeto AdminSDHolder. Con Audit Directory Service Changes habilitado en los DC, cada cambio genera el evento 5136 con el atributo nTSecurityDescriptor. Genere una alerta de gravedad alta. Los cambios legítimos deberían ser escasos y estar asociados a un ticket.
• Comparación programada. Un trabajo semanal compara el SDDL activo con el archivo de línea base y abre un ticket ante cualquier diferencia. Así se detectan también los cambios hechos mientras la auditoría estaba desactivada.
• Desviaciones de adminCount. Genere una alerta con el evento 5136 cuando se establezca adminCount en un objeto que no esté en su lista aprobada de Tier 0. Indica que alguien se añadió a un grupo protegido, aunque fuera brevemente, y se complementa con los eventos de cambio de grupo 4728, 4732 y 4756.

Microsoft Defender for Identity y PingCastle también señalan anomalías de AdminSDHolder. Úselos como comprobaciones cruzadas, no como único control.

Qué se rompe

• Restablecimientos de contraseña por el soporte técnico en antiguos administradores. Mientras una cuenta está protegida, SDProp bloquea las delegaciones heredadas de la OU, así que el soporte técnico no puede restablecer su contraseña. Es lo buscado. La limpieza lo invierte: al reactivar la herencia, las delegaciones de la OU vuelven a aplicarse y el soporte técnico puede restablecer la contraseña del antiguo administrador. Compruebe que es lo que desea antes de restablecer la ACL de una cuenta sensible.
• ACE personalizadas colocadas directamente en cuentas de administrador. SDProp ya las había sobrescrito, así que las herramientas que las esperaban ya estaban rotas. El restablecimiento solo lo hace visible.
• Aplicaciones que se concedieron derechos a través de AdminSDHolder, por ejemplo algunos productos antiguos de gestión de identidades o PAM. Quitar de AdminSDHolder las ACE sin explicación retira esos derechos a todos los administradores en la siguiente ejecución de SDProp. Confírmelo antes con el fabricante.
• Cambios en dSHeuristics. Si alguien estableció anteriormente la máscara de exclusión, quitarla vuelve a proteger los grupos de operadores y a sus miembros, y las delegaciones que dependían de la exclusión dejan de funcionar.

Lecturas relacionadas: la guía principal sobre ACL, encontrar derechos de DCSync para la ACL de la raíz del dominio, gestión de rutas de ataque para ver adónde siguen llevando los derechos huérfanos, y la guía principal de Tier 0 para saber cómo deben usarse las cuentas protegidas.