Encontrar y eliminar derechos de DCSync en Active Directory

DCSync no es un exploit. Es el protocolo de replicación del directorio (MS-DRSR) haciendo aquello para lo que se diseñó, a petición de alguien que no debería pedirlo. Cualquier entidad de seguridad que tenga dos derechos extendidos sobre el contexto de nomenclatura del dominio puede solicitar a un DC, a través de la red, los datos de contraseña de todas las cuentas, incluida krbtgt. Herramientas como Mimikatz y secretsdump de Impacket lo convierten en una operación de una sola línea, y no deja ningún archivo en el DC.

Por eso, saber quién tiene esos derechos es una de las preguntas sobre ACL más importantes en cualquier dominio, y una de las menos comprobadas. La guía principal sobre ACL muestra la consulta básica. Esta guía cubre la auditoría completa: todos los derechos equivalentes a DCSync, los valores predeterminados que cabe esperar, cómo eliminar el resto con seguridad y cómo detectar el uso de los derechos que deben mantenerse.

Los derechos que suman DCSync

Los permisos de replicación son derechos extendidos (derechos de control de acceso) concedidos sobre la cabecera del contexto de nomenclatura, que es el propio objeto de dominio (por ejemplo DC=corp,DC=example,DC=com):

El DCSync de secretos requiere Get-Changes más Get-Changes-All. Pero también hay que contar los derechos que pueden concederlos o implicarlos:

• GenericAll sobre el objeto de dominio incluye todos los derechos extendidos.
• AllExtendedRights, una ACE ExtendedRight con ObjectType vacío, abarca todos los derechos de control de acceso.
• WriteDACL o WriteOwner sobre el objeto de dominio permiten a su titular concederse los dos derechos en cualquier momento.
• La pertenencia a cualquier grupo que tenga lo anterior, incluida la pertenencia anidada.

Una auditoría que solo busca los dos GUID pasa por alto los cuatro últimos. Las herramientas de rutas de ataque modelan todos ellos como una única arista DCSync.

Medir: enumerar todas las entidades capaces de replicar

Los valores de rightsGuid son idénticos en todos los bosques, así que pueden codificarse de forma fija. Marque toda ACE que conceda DCSync o que permita crearlo:

Import-Module ActiveDirectory
$domainDN = (Get-ADDomain).DistinguishedName
$acl      = Get-Acl -Path "AD:\$domainDN"

$getChanges    = [guid]'1131f6aa-9c07-11d1-f79f-00c04fc2dcd2'
$getChangesAll = [guid]'1131f6ad-9c07-11d1-f79f-00c04fc2dcd2'
$filteredSet   = [guid]'89e95b76-444d-4c62-991a-0facbeda640c'
$empty         = [guid]::Empty

$findings = foreach ($ace in ($acl.Access | Where-Object { $_.AccessControlType -eq 'Allow' })) {
    $r = $ace.ActiveDirectoryRights
    $why = switch ($true) {
        { $r.HasFlag([System.DirectoryServices.ActiveDirectoryRights]::GenericAll) } { 'GenericAll'; break }
        { $r.HasFlag([System.DirectoryServices.ActiveDirectoryRights]::WriteDacl) }  { 'WriteDACL'; break }
        { $r.HasFlag([System.DirectoryServices.ActiveDirectoryRights]::WriteOwner) } { 'WriteOwner'; break }
        { $r.HasFlag([System.DirectoryServices.ActiveDirectoryRights]::ExtendedRight) -and $ace.ObjectType -eq $empty } { 'AllExtendedRights'; break }
        { $ace.ObjectType -eq $getChangesAll } { 'Get-Changes-All'; break }
        { $ace.ObjectType -eq $getChanges }    { 'Get-Changes'; break }
        { $ace.ObjectType -eq $filteredSet }   { 'Get-Changes-In-Filtered-Set'; break }
    }
    if ($why) { [PSCustomObject]@{ Principal = $ace.IdentityReference.Value; Right = $why; Inherited = $ace.IsInherited } }
}
$findings | Sort-Object Principal, Right | Format-Table -AutoSize

Después, expanda las entidades de tipo grupo a sus miembros efectivos, porque una ACE para «IT-Sync-Operators» solo es tan segura como la pertenencia a ese grupo:

$findings.Principal | Sort-Object -Unique | Where-Object { $_ -notmatch '^(NT AUTHORITY|BUILTIN)\\' } |
    ForEach-Object {
        $name = $_.Split('\')[-1]
        $obj = Get-ADObject -Filter "sAMAccountName -eq '$name'" -Properties objectClass
        if ($obj.objectClass -eq 'group') {
            Get-ADGroupMember $obj -Recursive | Select-Object @{n='ViaGroup';e={$name}}, SamAccountName, objectClass
        }
    }

Ejecute la misma consulta en cada dominio del bosque. Cada dominio tiene su propio contexto de nomenclatura y su propia ACL.

Auditar: comparar con el conjunto esperado

En un dominio predeterminado, las entidades que acaban teniendo derechos de replicación sobre el objeto de dominio son:

• Domain Controllers y Enterprise Domain Controllers: los propios DC.
• Enterprise Read-only Domain Controllers: solo Get-Changes. Los RODC no reciben Get-Changes-All.
• Administrators (integrado), que es la vía por la que lo obtienen Domain Admins y Enterprise Admins, además de los amplios derechos predeterminados que esos grupos tienen sobre el objeto de dominio.
• SYSTEM.

Todo lo demás necesita un responsable y un motivo. Hallazgos habituales y qué hacer con ellos:

Otros contextos de nomenclatura, dominios y bosques

El contexto de nomenclatura del dominio es donde residen los secretos de contraseña, así que es donde más importa DCSync. Las particiones de configuración y de esquema también tienen sus propias ACL de replicación. Nada de ellas contiene hashes de contraseña, pero los derechos de escritura sobre la configuración pueden afectar a todos los dominios del bosque (sitios, objetos de AD CS, configuración de Exchange). Ejecute la misma consulta contra (Get-ADRootDSE).configurationNamingContext y revise todo lo que no sea un grupo de administración integrado o un DC.

En un bosque con varios dominios, repita la auditoría en cada dominio. Una concesión en un dominio secundario expone las cuentas de ese dominio, y los Enterprise Admins de la raíz pueden llegar a todo de todas formas. A través de las confianzas de bosque, los derechos de replicación no cruzan el límite a menos que alguien haya concedido explícitamente una ACE a una entidad de seguridad externa. Una concesión así aparece en el resultado como un SID sin resolver o una entidad de seguridad externa, y siempre debe investigarse.

Revise whenChanged en el objeto de dominio y su histórico de eventos 5136 para saber cuándo apareció una ACE inesperada. Una concesión de replicación no predeterminada sin registro de cambio es una técnica de persistencia clásica.

Aplicar: eliminar lo que no tiene responsable

Elimine ACE concretas, no entidades completas, para no quitar otros derechos por accidente. Haga antes una copia de seguridad del descriptor de seguridad completo:

$domainDN = (Get-ADDomain).DistinguishedName
(Get-Acl "AD:\$domainDN").Sddl | Out-File "C:\Tier0\Backup\domain-root-$(Get-Date -f yyyyMMdd).sddl"

$acl    = Get-Acl "AD:\$domainDN"
$target = 'CORP\svc-oldaudit'
$acl.Access | Where-Object {
    $_.IdentityReference.Value -eq $target -and -not $_.IsInherited -and
    $_.ObjectType -in @([guid]'1131f6aa-9c07-11d1-f79f-00c04fc2dcd2', [guid]'1131f6ad-9c07-11d1-f79f-00c04fc2dcd2')
} | ForEach-Object { [void]$acl.RemoveAccessRule($_) }
Set-Acl -Path "AD:\$domainDN" -AclObject $acl

Si encuentra una concesión que nadie sabe explicar, sobre todo si se añadió recientemente o la tiene un usuario con pocos privilegios, no se limite a borrarla y pasar a otra cosa. Trátela como un posible compromiso. Conserve las pruebas (la copia de seguridad del SDDL, los eventos 5136 y 4662, el historial de inicios de sesión de la cuenta), asuma que todos los hashes del dominio pueden haberse copiado y planifique el restablecimiento de credenciales de arriba abajo: krbtgt dos veces con replicación entre medias, cuentas de Tier 0, cuentas de servicio y, después, todos los demás. Eliminar la ACE impide el uso futuro. No hace nada con los hashes que ya se hayan llevado.

Para las cuentas que deben conservar los derechos:

• Inclúyalas en el modelo de administración de Tier 0. Solo inician sesión en sistemas de Tier 0, tienen contraseñas largas y aleatorias o administradas, y están excluidas de la delegación.
• Si el producto lo admite, conceda solo Get-Changes y compruebe si la función que depende de los secretos se usa realmente.
• Es preferible un grupo dedicado por producto (por ejemplo T0-Repl-EntraConnect) que tenga la ACE, para que los cambios de pertenencia aparezcan en la auditoría de cambios de grupo.

Verificar y detectar

Vuelva a ejecutar el script de medición y compárelo con su lista aprobada. El resultado debería coincidir ahora exactamente con el conjunto esperado. Programe el script semanalmente y genere una alerta ante cualquier diferencia.

Para la detección, habilite Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > DS Access > Audit Directory Service Access (Success) en los DC y confirme que el objeto de dominio tiene una SACL que audita a Everyone para los derechos de control de acceso de replicación. Después, genere alertas con:

• El evento 4662 cuando el objeto sea el objeto de dominio, la máscara de acceso sea 0x100 (Control Access), las propiedades contengan {1131f6ad-9c07-11d1-f79f-00c04fc2dcd2} o {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} y el sujeto no sea una cuenta de equipo de DC. Incluya en la lista de permitidos la cuenta de Entra Connect por su nombre y solo desde su servidor.
• El evento 5136 sobre el objeto de dominio cuando se modifique nTSecurityDescriptor. Cualquiera que añada derechos de replicación aparece aquí. La referencia de ID de eventos detalla los campos de ambos eventos.

Pruebe la alerta en un laboratorio: conceda los dos derechos de replicación a una cuenta de prueba dedicada, úsela para solicitar la replicación de los secretos de un único usuario de laboratorio (por ejemplo, con una herramienta de DCSync autorizada como Impacket secretsdump) y confirme que se dispara una alerta 4662 que identifica la cuenta de prueba. La replicación normal entre DC durante ese mismo periodo no debe generar alertas. Después, retire de nuevo la concesión.

Qué se rompe

• La sincronización de hash de contraseñas se detiene si quita los derechos a la cuenta del conector de Entra Connect. Mantenga esos derechos y bastione la cuenta.
• Las herramientas de auditoría de contraseñas e ITDR que comparan hashes con listas de filtraciones necesitan Get-Changes-All. Quitarlo deshabilita esa función. Decida conscientemente si el beneficio compensa tener otra credencial de Tier 0.
• La preparación de Exchange heredada puede volver a añadir WriteDACL si alguien vuelve a ejecutar un /PrepareAD antiguo. Documente la corrección en su runbook de Exchange.
• Los scripts de sincronización personalizados basados en controles DirSync necesitan Get-Changes. Quitarlo hace que fallen con acceso denegado. Páselos a lecturas LDAP acotadas siempre que sea posible.

Lecturas relacionadas: la guía principal sobre ACL, limpieza de AdminSDHolder y SDProp para la otra ACL que controla los objetos privilegiados, y rotación de krbtgt si una concesión de DCSync sin explicación sugiere que los hashes ya han salido de casa.