Delegación restringida y RBCD de forma segura en AD

Una vez eliminada la delegación sin restricciones, la delegación que queda es la acotada: la delegación restringida de Kerberos (KCD) y la delegación restringida basada en recursos (RBCD). Ambas son legítimas y a menudo necesarias. Ambas se convierten también en primitivas de suplantación cuando se configuran de forma laxa o cuando las personas equivocadas pueden modificarlas. Los atacantes usan herramientas como Rubeus e Impacket para solicitar tickets S4U; esta guía se centra en el lado defensivo, es decir, en las decisiones de configuración y las auditorías que determinan si esas solicitudes obtienen algo útil.

Se asume que ya conoce los tres modelos de la guía principal sobre delegación. Aquí profundizamos en las extensiones de Kerberos que hay detrás, en las configuraciones que hacen arriesgado cada modelo y en una auditoría repetible de quién puede escribir RBCD en sus objetos de equipo.

Cómo hace funcionar S4U la delegación

Ambos modelos acotados se basan en dos extensiones de Kerberos, denominadas en conjunto Service for User (S4U):

• S4U2Self permite a un servicio solicitar un ticket para sí mismo en nombre de cualquier usuario, sin las credenciales de ese usuario. Existe para que un servicio pueda conocer la pertenencia a grupos de un usuario.
• S4U2Proxy permite a un servicio tomar un ticket que tiene para un usuario (el ticket de «evidencia») e intercambiarlo por un ticket para un servicio distinto, siempre como ese usuario.

El KDC comprueba S4U2Proxy frente a la configuración de delegación: msDS-AllowedToDelegateTo en el front-end para KCD, o msDS-AllowedToActOnBehalfOfOtherIdentity en el back-end para RBCD. Dos detalles determinan lo peligrosa que es una configuración concreta.

Transición de protocolo

Con KCD «Kerberos only», S4U2Proxy solo tiene éxito si el ticket de evidencia es reenviable, lo que en la práctica significa que el usuario se autenticó realmente ante el front-end con Kerberos. Con «Use any authentication protocol» (el indicador TRUSTED_TO_AUTH_FOR_DELEGATION, 0x1000000), el front-end puede obtener un ticket reenviable para cualquier usuario únicamente mediante S4U2Self. El usuario no tiene por qué aparecer nunca.

Eso significa que cualquiera que controle una cuenta de front-end con transición de protocolo puede suplantar a cualquier usuario no protegido, incluidos los Domain Admins, ante todos los SPN de su lista de permitidos, en cualquier momento. La transición de protocolo es necesaria para la autenticación por formularios, el inicio de sesión con certificado o tarjeta inteligente gestionado por la aplicación y algunas pasarelas SSO. No es necesaria para un sitio de intranet que use la autenticación integrada de Windows.

RBCD y tickets reenviables

En RBCD, el KDC acepta un ticket de evidencia no reenviable siempre que el back-end confíe en el front-end. Así, un atacante que controle cualquier cuenta con un SPN (basta con una cuenta de equipo que haya creado) y pueda escribir RBCD en un equipo de destino puede suplantar a usuarios ante ese destino. Por eso la higiene de RBCD tiene que ver sobre todo con los permisos de escritura, y por eso ms-DS-MachineAccountQuota importa tanto aquí.

Sustitución del nombre de servicio

El SPN de un ticket de servicio no está protegido por el cifrado del ticket. Un ticket emitido para cifs/fs01 es igual de válido para host/fs01, http/fs01 o ldap/fs01 si esos servicios se ejecutan con la misma cuenta, y en una cuenta de equipo todos lo hacen. Acote en consecuencia: una entrada que apunta a cualquier servicio de un controlador de dominio equivale en la práctica a delegación sobre todo el DC.

Medir: inventariar la delegación acotada

Recopile ambos modelos en todos los dominios, incluido el indicador de transición de protocolo.

Import-Module ActiveDirectory

# KCD: cuentas de front-end con msDS-AllowedToDelegateTo
Get-ADObject -LDAPFilter '(msDS-AllowedToDelegateTo=*)' `
    -Properties samAccountName, objectClass, msDS-AllowedToDelegateTo, userAccountControl |
    Select-Object samAccountName, objectClass,
        @{n='ProtocolTransition';e={[bool]($_.userAccountControl -band 0x1000000)}},
        @{n='Targets';e={$_.'msDS-AllowedToDelegateTo' -join '; '}}

# RBCD: recursos de back-end y quién puede delegar en ellos
Get-ADComputer -LDAPFilter '(msDS-AllowedToActOnBehalfOfOtherIdentity=*)' `
    -Properties PrincipalsAllowedToDelegateToAccount |
    Select-Object Name,
        @{n='AllowedFrom';e={$_.PrincipalsAllowedToDelegateToAccount -join '; '}}

PrincipalsAllowedToDelegateToAccount es la vista legible que ofrece el módulo ActiveDirectory del descriptor de seguridad msDS-AllowedToActOnBehalfOfOtherIdentity, así que no tiene que analizarlo a mano. RBCD también puede configurarse en cuentas de usuario y de servicio; si quiere una cobertura completa, ejecute el mismo filtro con Get-ADObject.

Marque como críticos:

• Cualquier destino de KCD o recurso RBCD que sea un controlador de dominio, un servidor AD CS u otro activo Tier 0.
• Cualquier front-end con transición de protocolo cuya necesidad no esté documentada.
• Cualquier entrada RBCD que apunte a una cuenta de equipo creada por un usuario normal (compruebe mS-DS-CreatorSID en el front-end).
• Cualquier delegación configurada en una cuenta de usuario con contraseña estática.

Auditar: quién puede escribir RBCD

Una entrada RBCD que conoce es solo la mitad del panorama. La otra mitad es quién podría añadir una mañana. Busque estos derechos en los objetos de equipo, especialmente en servidores y equipos Tier 0:

• GenericAll, GenericWrite, WriteDacl o WriteOwner sobre el objeto, o la propiedad del mismo.
• WriteProperty sobre todas las propiedades o sobre el atributo msDS-AllowedToActOnBehalfOfOtherIdentity (schemaIDGUID 3f78c3e5-f79a-46bd-a0b8-9d18116ddc79).
• WriteProperty sobre el conjunto de propiedades Account Restrictions (4c164200-20c0-11d0-a768-00aa006e0529), que se concede habitualmente a la cuenta que unió un equipo al dominio e incluye este atributo.

$rbcdAttr   = [guid]'3f78c3e5-f79a-46bd-a0b8-9d18116ddc79'
$acctRestr  = [guid]'4c164200-20c0-11d0-a768-00aa006e0529'
$expected   = 'NT AUTHORITY\\SYSTEM|\\Domain Admins$|\\Enterprise Admins$|BUILTIN\\Administrators|\\Key Admins$|\\Enterprise Key Admins$|NT AUTHORITY\\SELF'

Get-ADComputer -Filter * -SearchBase 'OU=Servers,DC=corp,DC=example,DC=com' |
    ForEach-Object {
        $dn  = $_.DistinguishedName
        $acl = Get-Acl -Path "AD:\$dn"
        $acl.Access | Where-Object {
            $_.AccessControlType -eq 'Allow' -and
            $_.IdentityReference -notmatch $expected -and (
                $_.ActiveDirectoryRights -match 'GenericAll|GenericWrite|WriteDacl|WriteOwner' -or
                ($_.ActiveDirectoryRights -match 'WriteProperty' -and
                 $_.ObjectType -in @([guid]::Empty, $rbcdAttr, $acctRestr))
            )
        } | Select-Object @{n='Computer';e={$dn}}, IdentityReference, ActiveDirectoryRights, ObjectType, IsInherited
    } | Export-Csv .\rbcd-writers.csv -NoTypeInformation

Revise también $acl.Owner de cada objeto: un propietario siempre puede reescribir la DACL. Las ACE heredadas apuntan a una delegación a nivel de OU demasiado amplia; corríjalas en la OU en lugar de objeto por objeto. Para una vista en grafo de todo el dominio, la guía de gestión de rutas de ataque muestra cómo consultar las mismas relaciones en BloodHound.

Fíjese en la exclusión de SELF anterior. Una cuenta de equipo puede escribir RBCD en su propio objeto con la configuración predeterminada, lo cual es inofensivo por sí solo, pero es exactamente lo que explotan cadenas de relay como KrbRelayUp: retransmiten la autenticación del equipo hacia LDAP y escriben RBCD como el equipo. La solución no es un cambio de ACL, sino la firma LDAP y el enlace de canal en todos los DC.

Aplicar: configurar la delegación acotada de forma segura

KCD solo Kerberos

Cuando los usuarios lleguen al front-end con Kerberos, use KCD sin transición de protocolo, con la lista de SPN más corta que funcione.

Set-ADComputer -Identity WEB01 -Replace @{
    'msDS-AllowedToDelegateTo' = @('MSSQLSvc/sql01.corp.example.com:1433','MSSQLSvc/sql01.corp.example.com')
}
Set-ADAccountControl -Identity (Get-ADComputer WEB01) -TrustedToAuthForDelegation $false

Si la transición de protocolo es realmente necesaria, ejecute el front-end con una gMSA, manténgalo en un nivel dedicado, restrinja la administración local de sus hosts y asegúrese de que la lista de SPN no contenga ningún DC, servidor AD CS ni servidor de administración.

RBCD

Configure RBCD con el parámetro dedicado para que el descriptor de seguridad esté bien formado, y prefiera un grupo cuando varios front-ends necesiten acceso, para que los cambios se hagan en la pertenencia y no en el descriptor.

$front = Get-ADGroup 'GG-SQL01-Delegation-Frontends'
Set-ADComputer -Identity SQL01 -PrincipalsAllowedToDelegateToAccount $front

Elimine las entradas obsoletas con Set-ADComputer -Identity <name> -PrincipalsAllowedToDelegateToAccount $null.

Proteger las identidades que nunca deben suplantarse

Todas las cuentas Tier 0 deben estar en Protected Users o marcadas como "Account is sensitive and cannot be delegated". Ambas opciones hacen que el KDC rechace los tickets S4U para esos usuarios, lo que neutraliza la mayor parte del abuso de delegación incluso cuando un front-end está comprometido. Active también el indicador NOT_DELEGATED, incluido en el Administrator integrado y en las cuentas de emergencia (break-glass) que quizá no estén en Protected Users: el KDC lo aplica independientemente de la pertenencia a grupos y sobrevive a una limpieza accidental de grupos. Mantenga los DC parcheados frente a CVE-2020-17049 (el problema Bronze Bit), que permitía a un front-end comprometido eludir ambas protecciones manipulando el indicador de reenviable.

Verificar

• Vuelva a ejecutar el inventario. Cada entrada KCD y RBCD corresponde a un registro de cambio y a un responsable; ninguna entrada apunta a un host Tier 0.

• Vuelva a ejecutar la auditoría de escritores en las OU de servidores y Tier 0. Los únicos escritores no predeterminados son grupos de aprovisionamiento documentados.

• Confirme que las cuentas privilegiadas tienen NOT_DELEGATED o pertenecen a Protected Users. Esta consulta no debe devolver nada:

  PowerShell

  # Protected Users tiene el RID 525; los miembros anidados también cuentan
  $protected = (Get-ADGroupMember -Identity "$((Get-ADDomain).DomainSID)-525" -Recursive).SID.Value
  Get-ADUser -Filter 'AccountNotDelegated -eq $false' -SearchBase '<admin OU>' |
      Where-Object { $_.SID.Value -notin $protected }

• Habilite una SACL para las escrituras en msDS-AllowedToActOnBehalfOfOtherIdentity y msDS-AllowedToDelegateTo en la raíz del dominio (auditoría de Directory Service Changes) y genere alertas sobre el evento 5136 para cualquiera de los dos atributos.

• En los DC, el evento 4769 incluye un campo Transited Services que se rellena en las solicitudes S4U2Proxy. Establezca una línea base de qué front-ends aparecen ahí; uno nuevo merece una investigación. La referencia de ID de eventos enumera los demás campos que vale la pena recopilar.

Qué rompe

• Eliminar la transición de protocolo rompe las aplicaciones que autentican a los usuarios con formularios, certificados de cliente gestionados en la aplicación o notificaciones de un IdP externo y que después llaman a un back-end Kerberos. Fallan en el segundo salto con errores de inicio de sesión anónimo o de acceso denegado.
• Recortar las listas de SPN rompe el acceso a través de alias: si los usuarios acceden a sql01 por su nombre corto y solo figura el SPN con el FQDN, la delegación falla. Incluya ambas formas cuando los clientes usen las dos.
• Añadir administradores a Protected Users o NOT_DELEGATED significa que esos administradores ya no pueden usar como ellos mismos las aplicaciones que delegan, como las consolas web que consultan back-ends con la identidad del usuario. Deben usar una cuenta estándar para esas herramientas.
• Restringir la delegación sobre las OU elimina la capacidad de las cuentas del service desk o de despliegue de modificar atributos de equipo que antes tocaban, lo que puede romper los scripts de reinstalación de imágenes que restablecen o reescriben objetos de equipo.

Lecturas relacionadas: el tema Delegación, la entrada del glosario sobre la delegación restringida basada en recursos y auditar las ACL de Active Directory para la revisión más amplia de permisos de la que forma parte esta auditoría.