Auditoría ACE peligrosas SID huérfanos entre dominios Active Directory: el abuso de ACL que la mayoría de las herramientas ni siquiera puede resolver

Una auditoría de ACE peligrosas en SID huérfanos y entre dominios en Active Directory plantea una pregunta a la que una revisión de ACL estándar nunca llega: ¿qué concesiones de su directorio están en manos de titulares (trustees) que nadie puede identificar? Cada entrada de control de acceso (ACE) en una DACL de AD identifica a su trustee (titular) mediante un identificador de seguridad (SID), y las herramientas de revisión casi siempre resuelven ese SID a un nombre legible antes de mostrárselo. Pero ¿qué ocurre cuando el SID no resuelve a nada en absoluto — y la ACE en la que se encuentra otorga control total?

Esa es una pregunta distinta de la que plantea una revisión normal. Una revisión normal pregunta: «¿qué cuentas activas tienen GenericAll sobre el Tier 0?». Esta pregunta: «¿qué concesiones están en manos de titulares que mi directorio no puede identificar?». Ambas producen hallazgos completamente distintos, y la segunda se omite habitualmente: una entrada cuyo titular no resuelve es fácil de representar en un informe como una fila en blanco, una cadena en bruto, o directamente nada.

Qué verifica una auditoría de ACE peligrosas en SID huérfanos y entre dominios en Active Directory

Un SID no es un nombre. La referencia de Microsoft sobre identificadores de seguridad describe la estructura con precisión: para una cuenta de dominio, «el SID de un principal de seguridad se crea concatenando el SID del dominio con un identificador relativo (RID) para la cuenta». Todo lo que precede al segmento final -RID es el identificador de dominio; el último segmento identifica al principal dentro de ese dominio.

Esa estructura es lo que hace clasificable una referencia rota. Tome un SID de titular que no resuelve a ningún usuario, grupo, equipo, unidad organizativa o principal conocido, y compare su prefijo de dominio con el SID de su propio dominio:

La distinción importa por una garantía que Microsoft expresa explícitamente en la misma referencia: «Los SID siempre permanecen únicos. Las autoridades de seguridad nunca emiten el mismo SID dos veces, y nunca reutilizan SID de cuentas eliminadas». Por lo tanto, un SID local huérfano no puede recuperarse creando una nueva cuenta con el mismo nombre — la nueva cuenta obtiene un RID nuevo. Esto es genuinamente tranquilizador, y es la razón por la que este caso no es una alarma de máxima urgencia.

El caso entre dominios no tiene esa garantía, porque el principal simplemente puede existir en algún lugar que usted no puede ver. Una concesión legítima entre dominios normalmente se materializa en su directorio como un objeto Foreign-Security-Principal — «el principal de seguridad procedente de un origen externo». Si no existe un foreignSecurityPrincipal correspondiente, se está ante una concesión intencional cuyo objeto complementario nunca se creó, o ante un resto de una relación de confianza que desde entonces se ha eliminado o reconfigurado.

Los derechos que hacen peligroso a un titular no resoluble

No todas las ACE con un titular roto son relevantes. Las que importan son las que otorgan derechos que permiten a su titular tomar el control del objeto. La referencia de Microsoft ADS_RIGHTS_ENUM especifica los bits exactos:

Hay una trampa aquí que arruina silenciosamente los scripts de auditoría caseros. Los bits genéricos anteriores son los valores en bruto de ADSI. La enumeración ActiveDirectoryRights de .NET que expone PowerShell utiliza en su lugar los valores mapeados del servicio de directorio: GenericAll es 983551 (0xF01FF), no 0x10000000. Y 0xF01FF es un compuesto que incluye ReadProperty (16) y ListChildren (4).

Por lo tanto, un script que escriba $ace.ActiveDirectoryRights -band 'GenericAll' y trate un resultado distinto de cero como control total marcará esencialmente todas las ACE de lectura del directorio. La prueba correcta es una comparación de igualdad contra la máscara completa, junto con comprobaciones separadas de los bits genéricos en bruto y de los derechos de escritura estándar:

$mask = [int]$ace.ActiveDirectoryRights
$isDangerous =
    (($mask -band 0x10000000) -ne 0) -or          <# ADS_RIGHT_GENERIC_ALL   #>
    (($mask -band 0x40000000) -ne 0) -or          <# ADS_RIGHT_GENERIC_WRITE #>
    (($mask -band 0x000F01FF) -eq 0x000F01FF) -or <# control total (mapeado) #>
    (($mask -band 0x00040000) -ne 0) -or          <# WRITE_DAC               #>
    (($mask -band 0x00080000) -ne 0)              <# WRITE_OWNER             #>

Microsoft distribuyó uno de estos casos ella misma

La evidencia más convincente de que las referencias de SID rotas son una condición sistémica y no una curiosidad proviene de la propia documentación de Microsoft sobre lo que adprep /domainprep hace a su directorio.

La referencia Active Directory domain-wide schema updates enumera las operaciones que se realizan al preparar un controlador de dominio con Windows Server 2016. La operación 85 se describe como una modificación del contexto de nomenclatura del dominio «para permitir que domain\Key Admins y rootdomain\Enterprise Key Admins modifiquen el atributo msds-KeyCredentialLink». La columna de permisos registra a continuación lo que realmente ocurrió:

(OA;CI;RPWP;5b47d60f-6090-40b2-9f37-2a4de88f3063;;Key Admins)
(OA;CI;RPWP;5b47d60f-6090-40b2-9f37-2a4de88f3063;;Enterprise Key Admins in root
 domain, but in nonroot domains resulted in a bogus domain-relative ACE with a
 nonresolvable -527 SID)

Lea de nuevo esa última cláusula. Microsoft documenta que, en cada dominio no raíz de un bosque multidominio, esta operación dejó una ACE cuyo titular es un SID no resoluble. Enterprise Key Admins es un grupo de nivel de bosque que reside en la raíz del bosque; la operación construyó el SID en relación con el dominio local, produciendo una referencia -527 a un principal que ese dominio no tiene.

Otras dos operaciones lo corrigen después — y no se distribuyen juntas, lo que determina si su dominio recibió una corrección o ambas. La operación 87 se encuentra en la misma tabla de Windows Server 2016 (operaciones 82-88, tras las cuales el atributo revision de CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System se establece en 15); elimina «la ACE que otorga Control total al grupo Enterprise Key Admins relativo al dominio incorrecto» y añade una correcta. La operación 89 aparece en una tabla distinta — las actualizaciones a nivel de bosque de Windows Server (canal semestral), que llevan ese mismo atributo revision a 16 — y va más allá: elimina la entrada amplia (A;CI;RPWPCRLCLOCCDCRCWDWOSDDTSW;;;Enterprise Key Admins) y la sustituye por (OA;CI;RPWP;5b47d60f-6090-40b2-9f37-2a4de88f3063;;Enterprise Key Admins) — control total sobre todo el contexto de nomenclatura, reducido a acceso de escritura sobre un único atributo. Ese valor de revision es lo que indica cuál de las dos correcciones recibió realmente su dominio.

Esas cadenas SDDL se descodifican con la referencia ACE Strings de Microsoft: A es una ACE de tipo access-allowed, OA es una específica de objeto, CI la marca como heredable por contenedores (container-inheritable), y RPWPCRLCLOCCDCRCWDWOSDDTSW concatena read property, write property, control access, list children, list object, create child, delete child, read control, write DAC, write owner, delete, delete tree y self-write. Eso es control total con otro nombre — incluidos los dos derechos que permiten a su titular reescribir la DACL y apoderarse de la propiedad (ownership).

🚨 Peligro: Si su bosque se preparó con los medios originales de Windows Server 2016 y las operaciones de corrección posteriores nunca se ejecutaron, una ACE -527 que otorga derechos amplios sobre todo un contexto de nomenclatura de dominio puede seguir presente en un dominio hijo, apuntando a nada.

Por qué los dos casos tienen un peso distinto

Un SID local huérfano y un SID entre dominios se ven idénticos en una DACL — un titular no resoluble — pero merecen prioridades distintas.

SID local huérfano. Nadie puede ejercer esta concesión mediante un inicio de sesión normal. Como AD no recicla los RID, recuperar el SID exacto requeriría inyectarlo en el sIDHistory de una cuenta, y eso presupone el acceso privilegiado que un atacante estaría intentando obtener precisamente mediante esa concesión. Es un elemento de limpieza y un problema de rastro de auditoría, no una vía activa. Si se deja tal cual, sobrevivirá al incidente que lo creó, ampliando silenciosamente el radio de impacto de cualquier migración futura.

SID entre dominios. Este caso está vivo si el dominio referenciado llega a ser alcanzable en algún momento. La guía de filtrado de SID de Microsoft expone el mecanismo con claridad: «en algunas circunstancias es posible que atacantes o administradores deshonestos que hayan comprometido un controlador de dominio en un dominio de confianza utilicen el atributo de historial de SID (sIDHistory) para asociar SID con nuevas cuentas de usuario, concediéndose derechos no autorizados». La evaluación de la postura de cuentas de Microsoft Defender for Identity reformula la versión a nivel de bosque: «Si tiene una relación de confianza de bosque sin el filtrado de SID habilitado (también llamado cuarentena), es posible inyectar un SID de otro bosque, y este se añadirá al token del usuario al autenticarse, y se usará en las evaluaciones de acceso».

Combine ambas cosas y una ACE entre dominios obsoleta se convierte en una concesión pre-posicionada. Un atacante que controle — o más adelante restablezca — el dominio referenciado no necesita modificar su DACL en absoluto. El permiso ya está escrito. Solo necesita un token que porte ese SID. Es el mismo razonamiento sobre límites de confianza que se trata en ataques de confianza en Active Directory y en la auditoría de filtrado de SID y autenticación selectiva en relaciones de confianza; la diferencia es que aquí la concesión sobrevive a la eliminación de la relación de confianza, porque eliminar una relación de confianza no limpia las ACL.

Otros dos derechos en el mismo punto ciego

Las referencias de SID rotas comparten un punto ciego con otros dos patrones de permisos que las revisiones estándar omiten por una razón distinta: no son GenericAll, por lo que las auditorías basadas en palabras clave nunca los detectan.

Automembresía (self-membership) en grupos. La escritura validada Self-Membership, GUID bf9679c0-0de6-11d0-a285-00aa003049e2, está documentada como «permiso de escritura validada para permitir actualizar la membresía de un grupo en términos de añadir/quitar la propia cuenta». Su nombre visible en el editor de ACL es Add/Remove self as member (añadir/quitar autopertenencia), y se aplica únicamente a la clase Group. Concedido sobre un grupo privilegiado, es una escalada de un solo paso que nunca implica que un tercero escriba member — el propio principal se añade a sí mismo. La referencia Dsacls de Microsoft confirma el alcance: el permiso WS «solo tiene sentido en objetos de grupo y cuando {ObjectType | Property} es 'member'». Esta es la familia de derechos que hace que el anidamiento peligroso de grupos sea peor de lo que parece.

Enterprise Key Admins sobre msDS-KeyCredentialLink. Según Active Directory security groups, Enterprise Key Admins tiene el RID conocido 527, es un grupo Global en CN=Users, no tiene miembros predeterminados, y está protegido por AdminSDHolder. El atributo que gobierna, msDS-KeyCredentialLink (schemaIdGuid 5b47d60f-6090-40b2-9f37-2a4de88f3063), «contiene material de claves e información de uso» y se «implementó por primera vez en Windows Server 2016».

El acceso de escritura a ese atributo es todo lo que necesita el ataque Shadow Credentials. En la investigación original de Elad Shamir sobre Shadow Credentials: «si puede escribir en la propiedad msDS-KeyCredentialLink de un usuario, puede obtener un TGT para ese usuario» y «puede recuperar el hash NT de ese usuario». Los requisitos previos son un controlador de dominio con Windows Server 2016, un certificado de Server Authentication en él, y un nivel funcional de Windows Server 2016 — y la credencial implantada «persistiría incluso si el usuario o el equipo cambiara su contraseña». Cubrimos la técnica en sí en Shadow Credentials: abusando de msDS-KeyCredentialLink.

La pregunta de auditoría es más acotada que el ataque en sí. Enterprise Key Admins se distribuye vacío. Lo que se está comprobando es si la ACE del grupo sobre el contexto de nomenclatura de su dominio es el RPWP acotado sobre 5b47d60f-… que instala la operación 89, o la entrada de control total sin acotar que dejó la preparación original — y si el titular realmente resuelve.

Detección

Auditar esto requiere dos pasadas: un barrido puntual de las DACL existentes, y una auditoría de cambios para detectar nuevas referencias rotas a medida que aparecen.

Barrer las DACL existentes en busca de titulares peligrosos no resolubles

Solicite los SID en bruto en lugar de los nombres de cuenta. Pedir a .NET objetos NTAccount directamente lanza una excepción precisamente en las entradas que está buscando: SecurityIdentifier.Translate genera IdentityNotMappedException cuando «algunas o todas las referencias de identidad no se pudieron traducir».

Import-Module ActiveDirectory

$domainSid = (Get-ADDomain).DomainSID.Value
$root      = (Get-ADRootDSE).defaultNamingContext

Get-ADObject -SearchBase $root -LDAPFilter '(objectClass=*)' -Properties nTSecurityDescriptor |
  ForEach-Object {
    $dn = $_.DistinguishedName
    $_.nTSecurityDescriptor.GetAccessRules(
        $true, $true, [System.Security.Principal.SecurityIdentifier]) |
      Where-Object { $_.AccessControlType -eq 'Allow' } |
      ForEach-Object {
        $mask = [int]$_.ActiveDirectoryRights
        $dangerous =
            (($mask -band 0x10000000) -ne 0) -or
            (($mask -band 0x40000000) -ne 0) -or
            (($mask -band 0x000F01FF) -eq 0x000F01FF) -or
            (($mask -band 0x00040000) -ne 0) -or
            (($mask -band 0x00080000) -ne 0)
        if (-not $dangerous) { return }

        $sid = $_.IdentityReference
        try {
            $null = $sid.Translate([System.Security.Principal.NTAccount])
            return
        } catch [System.Security.Principal.IdentityNotMappedException] { }

        $scope = if ($sid.Value.StartsWith("$domainSid-")) {
                     'Orphaned local SID'
                 } else {
                     'Cross-domain SID'
                 }

        [pscustomobject]@{
            ObjectDN = $dn
            Trustee  = $sid.Value
            Rights   = $_.ActiveDirectoryRights
            Scope    = $scope
        }
      }
  } | Sort-Object Scope, ObjectDN | Format-Table -AutoSize

Ejecute esto primero contra una sola OU. Un barrido completo del contexto de nomenclatura lee todos los descriptores de seguridad del dominio y no es algo que deba lanzarse contra un DC de producción en horario laboral.

Comprobar los dos patrones específicos

Ambas consultas siguientes solicitan titulares SecurityIdentifier por la misma razón que el barrido: la propiedad .Access traduce a NTAccount y lanza IdentityNotMappedException precisamente en las ACE de las que trata este artículo.

$root    = (Get-ADRootDSE).defaultNamingContext
$sidType = [System.Security.Principal.SecurityIdentifier]

<# Key Admins (-526) y Enterprise Key Admins (-527) sobre el NC de dominio:
   ¿acotado o control total? Compare por el RID, no por el nombre — en un
   dominio no raíz, el titular incorrecto es precisamente el que no resolverá
   a "Key Admins", por lo que un filtro por nombre pasa por alto el hallazgo
   silenciosamente. #>
(Get-ADObject $root -Properties nTSecurityDescriptor).nTSecurityDescriptor.GetAccessRules(
    $true, $true, $sidType) |
  Where-Object { $_.IdentityReference.Value -match '-52[67]$' } |
  Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

<# Concesiones de automembresía en grupos: la escritura validada, o un DS_SELF sin acotar #>
$selfMembership = [guid]'bf9679c0-0de6-11d0-a285-00aa003049e2'
Get-ADGroup -Filter * -Properties nTSecurityDescriptor | ForEach-Object {
    $g = $_
    $g.nTSecurityDescriptor.GetAccessRules($true, $true, $sidType) |
      Where-Object {
        $_.AccessControlType -eq 'Allow' -and (
          $_.ObjectType -eq $selfMembership -or
          ($_.ObjectType -eq [guid]::Empty -and
           ([int]$_.ActiveDirectoryRights -band 0x8) -ne 0)
        )
      } |
      Select-Object @{n='Group';e={$g.DistinguishedName}},
                    IdentityReference, ActiveDirectoryRights
}

Un ObjectType igual a 5b47d60f-6090-40b2-9f37-2a4de88f3063 en la primera consulta es la forma acotada y esperada. Un ObjectType vacío con una máscara de control total es la entrada sin acotar que debería haberse sustituido — y un titular -527 que no se puede hacer coincidir con un grupo Enterprise Key Admins activo es el propio caso no resoluble.

Detectar los nuevos casos a medida que aparecen

La referencia del evento 5136 de Microsoft expone los requisitos previos y las reglas de lectura. El evento pertenece a la subcategoría Audit Directory Service Changes, y «para generar este evento, el objeto modificado debe tener una entrada apropiada en la SACL: la auditoría de la acción 'Write' para atributos específicos» — habilitar la subcategoría por sí sola no basta, la SACL debe existir en los objetos que le interesan.

Espere pares, no eventos aislados: «para una operación de cambio, normalmente verá dos eventos 5136 para una misma acción, con campos Operation Type distintos: 'Value Deleted' y luego 'Value Added'». La propia recomendación de Microsoft es generar la alerta sobre el evento Value Added y usar el Correlation ID para obtener el valor anterior de su evento pareja.

Un detalle de la misma página funciona también como diagnóstico para todo este artículo: «el Visor de eventos intenta automáticamente resolver los SID y mostrar el nombre de la cuenta. Si el SID no se puede resolver, verá los datos de origen en el evento». Un SID en bruto donde se esperaba un nombre es la señal reveladora — tanto en un evento como en un informe de ACL.

Remediación

1. Confirme que la limpieza de adprep se ejecutó. En cada dominio no raíz, inspeccione la DACL del NC de dominio en busca de ACE cuyo titular termine en -527. Si encuentra una entrada de control total — especialmente una que no resuelve — está ante el estado previo a las operaciones 87/89. El atributo revision de CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System indica hasta dónde llegó la preparación: 15 significa que se completaron las operaciones 82-88, 16 significa que también se ejecutó la operación 89.

2. Clasifique antes de eliminar. Para cada titular no resoluble, compare el prefijo de dominio con el SID de su propio dominio y con los SID de cada dominio con el que tiene una relación de confianza. Un SID entre dominios que coincide con un socio de confianza actual es probablemente una concesión intencional a la que le falta su objeto foreignSecurityPrincipal, y eliminarla romperá algo. Uno que no coincide con ninguna relación de confianza actual es una referencia obsoleta.

3. Elimine por SID, no por nombre. Aquí es donde las herramientas juegan en su contra. La referencia Dsacls de Microsoft documenta que /R toma un titular especificado «como User@Domain o como Domain\User» — una forma de nombre que, por definición, no existe para un SID que no resuelve. Use PowerShell y entregue a la API un SecurityIdentifier directamente:

$dn  = 'DC=child,DC=corp,DC=local'
$sid = [System.Security.Principal.SecurityIdentifier]'S-1-5-21-1004336348-1177238915-682003330-527'

$acl = Get-Acl -Path "AD:\$dn"
$acl.GetAccessRules($true, $false, [System.Security.Principal.SecurityIdentifier]) |
  Where-Object { $_.IdentityReference -eq $sid } |
  ForEach-Object { $null = $acl.RemoveAccessRuleSpecific($_) }

Set-Acl -Path "AD:\$dn" -AclObject $acl

Observe el $false para las reglas heredadas: una ACE heredada no se puede eliminar en el objeto hijo, solo en el objeto que la define. Corrija el objeto padre y deje que la herencia se propague.

4. Restaure el alcance previsto, no se limite a eliminar. Cuando la entrada era Enterprise Key Admins sobre el NC de dominio, el estado objetivo está documentado: una ACE de objeto que otorga RPWP acotado a 5b47d60f-6090-40b2-9f37-2a4de88f3063, heredable por contenedores. Eliminar sin sustituir quita un permiso que el aprovisionamiento de Windows Hello for Business espera encontrar.

5. Mantenga activado el filtrado de SID — y no lo confunda con la cuarentena. Una ACE entre dominios solo es explotable si un SID externo puede llegar a su token de acceso, y el filtrado de SID es lo que lo impide. En una relación de confianza de bosque, el filtrado es estructural, no opcional: MS-PAC especifica que una relación de confianza entre bosques «no permite que los SID locales de su propio bosque atraviesen una relación de confianza entre bosques», y que los SID ForestSpecific «se filtran para los límites de confianza QuarantinedWithinForest, CrossForest, External y QuarantinedExternal». Defender for Identity, citado anteriormente, trata la ausencia de ese filtrado como el hallazgo. La cuarentena de filtrado de SID es un modo distinto y más estricto, y las advertencias de Microsoft se aplican únicamente a ella: no aplique la cuarentena «a relaciones de confianza dentro de un bosque que no utilice el nivel funcional de bosque de Windows Server 2003, porque hacerlo elimina SID que son necesarios para la replicación de Active Directory», y «no debe aplicarse a relaciones de confianza entre bosques». Interprete esto como una instrucción sobre el indicador de cuarentena — nunca como una licencia para desactivar el filtrado de SID.

6. Coloque una SACL en los objetos que le importan. El evento 5136 la necesita. Como mínimo: el objeto NC de dominio, CN=AdminSDHolder,CN=System, CN=Keys, y todos los grupos y OU de Tier 0. Auditar las escrituras en nTSecurityDescriptor y msDS-KeyCredentialLink convierte la próxima ocurrencia en una alerta en lugar de un hallazgo detectado un año después. El artículo la puerta trasera AdminSDHolder SDProp explica por qué ese contenedor en particular merece una vigilancia permanente.

7. Incorpórelo a la revisión recurrente. Los titulares huérfanos se acumulan por operaciones ordinarias — cuentas de servicio dadas de baja, adquisiciones cerradas, relaciones de confianza retiradas. Trate el barrido como parte de la auditoría de seguridad de Active Directory permanente, no como un proyecto de remediación puntual.

Cómo lo detecta EtcSec

EtcSec divide el problema de las referencias rotas en dos comprobaciones, precisamente porque los dos casos conllevan un riesgo distinto. ORPHANED_SID_DANGEROUS_ACE informa de ACE de concesión que otorgan GenericAll, control total, WriteDACL, WriteOwner o GenericWrite a un titular cuyo prefijo de dominio coincide con el dominio auditado pero que no resuelve a ningún principal activo — el caso probable de cuenta eliminada, calificado como Alto (High). CROSS_DOMAIN_SID_DANGEROUS_ACE informa de los mismos derechos en manos de un titular de un dominio completamente distinto, calificado como Crítico (Critical), porque esa referencia se vuelve explotable en el momento en que el dominio referenciado vuelve a ser alcanzable. Ambas comprobaciones excluyen deliberadamente a los titulares administrativos integrados y las ACE de denegación, de modo que el resultado refleje la exposición real y no la forma habitual del directorio.

Junto a ellas, ACL_SELF_MEMBERSHIP señala la escritura validada Add/Remove-self-as-member en objetos de grupo — acotada exclusivamente a grupos, y excluyendo deliberadamente el control total para no limitarse a repetir lo que ya detecta ACL_GENERICALL. ENTERPRISE_KEY_ADMINS_FULL_ACCESS señala al titular -527 que posee control total sin acotar o acceso de escritura a msDS-KeyCredentialLink en objetos de dominio, la condición que las operaciones 87 y 89 existen para corregir. ACL_WRITEDACL y ACL_WRITEOWNER cubren esos mismos dos derechos cuando el titular sí resuelve, y TRUST_SID_FILTERING_DISABLED cubre el control del lado de la relación de confianza que decide si una referencia entre dominios puede llegar alguna vez a un token.

Junto con las comprobaciones más amplias de abuso de ACL y DCSync y la auditoría de permisos de DPAPI, tombstone y esquema, estas comprobaciones cierran la brecha entre «quién tiene derechos peligrosos» y «qué derechos peligrosos están en manos de principales que nadie puede identificar».