Delegación de Kerberos

La delegación permite que un servicio actúe en nombre de un usuario contra otro servicio: el clásico front-end web que necesita acceder a una base de datos “como” el usuario que se conectó. Es una funcionalidad legítima y necesaria, pero sus tres variantes —no restringida, restringida y basada en recursos— tienen, mal configuradas, caminos directos a la suplantación de cualquier usuario, incluido Domain Admin. Es una de las vías de escalada más explotadas en AD moderno.

sequenceDiagram
    participant A as Cuenta con delegación
    participant KDC as KDC
    participant S as Servicio objetivo
    A->>KDC: S4U2self (pide un TGS a sí misma como Administrador)
    KDC-->>A: TGS reenviable como Administrador
    A->>KDC: S4U2proxy (pide un TGS al servicio objetivo)
    KDC-->>A: TGS para el servicio como Administrador
    A->>S: acceso como Administrador

Modelo de amenaza

El riesgo es la impersonación: si un servicio puede pedir tickets “como” otro usuario, comprometer ese servicio (o la cuenta/equipo que lo aloja) permite impersonar a cualquiera que lo use o, en algunos casos, a cualquier usuario del dominio. La función S4U (Service-for-User) de Kerberos es la pieza que los atacantes abusan para forjar esa impersonación.

Las tres variantes

Unconstrained Delegation (no restringida)

El equipo/cuenta con esta marca recibe, cuando un usuario se le conecta, una copia del TGT del usuario en su memoria. Si comprometes ese host, extraes los TGT de todos los que se conectaron, incluidos admins.

# localizar equipos con unconstrained
Get-DomainComputer -Unconstrained
# en el host comprometido, volcar TGTs
Rubeus.exe monitor /interval:5     # o sekurlsa::tickets

La jugada letal: coaccionar a un DC (PrinterBug/PetitPotam) para que se conecte a tu host con unconstrained → capturas el TGT del DC → DCSync → dominio.

Constrained Delegation (restringida)

La cuenta puede delegar solo hacia SPNs concretos (msDS-AllowedToDelegateTo). Con S4U2Self + S4U2Proxy puede pedir un ticket “como cualquier usuario” hacia esos servicios. Si controlas una cuenta con constrained delegation, impersonas a quien quieras (p. ej. Administrator) contra el servicio permitido.

getST.py -spn cifs/target -impersonate Administrator dominio/svc:pass
# o Rubeus s4u /user:svc /rc4:hash /impersonateuser:Administrator /msdsspn:cifs/target /ptt

Detalle clave: protocol transition (TrustedToAuthForDelegation) permite impersonar sin que el usuario se autentique primero; y el SPN de destino puede manipularse (cambiar la parte del servicio) para saltar a otros servicios del mismo host.

Resource-Based Constrained Delegation (RBCD)

Aquí el control está en el recurso destino: su atributo msDS-AllowedToActOnBehalfOfOtherIdentity lista quién puede delegar hacia él. Si tienes permiso de escritura sobre un equipo (GenericAll/GenericWrite/WriteProperty), configuras RBCD a una cuenta que controles → impersonas cualquier usuario contra ese equipo.

# 1) crear/usar una cuenta de máquina que controlas (MachineAccountQuota por defecto 10)
addcomputer.py -computer-name ATK$ -computer-pass Pass123 dominio/user:pass
# 2) escribir RBCD en el objetivo
rbcd.py -delegate-from 'ATK$' -delegate-to 'VICTIM$' -action write dominio/user:pass
# 3) S4U para impersonar al admin contra el objetivo
getST.py -spn cifs/victim.dominio -impersonate Administrator -hashes :hash 'dominio/ATK$'

RBCD es el destino favorito del NTLM relay a LDAP (NTLM Relay): relayas una cuenta de máquina al DC y le escribes RBCD → impersonación.

Herramientas

Rubeus (s4u, monitor, tgtdeleg) — delegación desde Windows.
impacket (getST.py, rbcd.py, findDelegation.py, addcomputer.py).
PowerView (Get-DomainComputer -Unconstrained, Get-DomainUser -TrustedToAuth).
BloodHound — marca delegaciones y rutas que las usan.

Impacto

Suplantación de cualquier usuario (incluido DA), y en unconstrained + coerción de DC, compromiso total del dominio. RBCD vía relay o vía ACL es uno de los caminos a DA más fiables hoy.

Blue Team

Detección

4769 (TGS) con flags de S4U inusuales; tickets S4U2Self/S4U2Proxy desde cuentas que no deberían delegar.
Escrituras en msDS-AllowedToActOnBehalfOfOtherIdentity (RBCD) y msDS-AllowedToDelegateTo inesperadas (auditoría de cambios de atributo).
Creación de cuentas de máquina nuevas (MachineAccountQuota) por usuarios normales; coerción hacia hosts con unconstrained.

Telemetría

Audita cambios en los atributos de delegación en el DC, creación de equipos (4741), y correlaciona S4U anómalo. BloodHound periódico para inventariar delegaciones.

Hardening

Elimina unconstrained delegation; donde haga falta, usa constrained o RBCD acotado.
Marca las cuentas sensibles (DA/Tier 0) como “Account is sensitive and cannot be delegated” y mételas en Protected Users → no delegables.
Pon MachineAccountQuota = 0 (evita que usuarios creen cuentas de máquina para RBCD).
Fuerza LDAP signing + channel binding (corta el relay a LDAP que habilita RBCD).
Audita y minimiza quién tiene escritura sobre objetos de equipo (BloodHound).

Respuesta

Revierte las escrituras RBCD/constrained maliciosas, resetea cuentas que delegaban, elimina cuentas de máquina creadas por el atacante, y si se impersonó a DA/krbtgt, trata el dominio como comprometido (rota krbtgt ×2).

CVEs y casos reales

Unconstrained + PrinterBug (SpoolSample) → captura del TGT de un DC: cadena pública a DA muy usada.
Bronze Bit (CVE-2020-17049) — bypass de protecciones de delegación en S4U2Self.
RBCD vía NTLM relay a LDAP (Elad Shamir, “Wagging the Dog”) — técnica de referencia.
MITRE T1558.003 y abusos de delegación documentados en informes de red team y ransomware.

Checklist de prueba

Equipos con unconstrained delegation (Get-DomainComputer -Unconstrained)
¿Coerción de un DC hacia un host unconstrained? (TGT de DC)
Cuentas con constrained delegation (msDS-AllowedToDelegateTo)
S4U2Self/S4U2Proxy para impersonar Administrator
¿Escritura sobre objetos de equipo? → RBCD
MachineAccountQuota > 0 (crear cuenta para RBCD)
RBCD vía relay NTLM a LDAP
Blue: ¿Protected Users y “cannot be delegated” en Tier 0?