Delegación Kerberos

La delegación permite que un servicio actúe en nombre de otro usuario contra un tercer servicio (por ejemplo, una web que accede a una base de datos como el usuario que la visita). Mal configurada, es una de las vías de escalada más potentes en AD. Hay tres tipos.

Unconstrained

El equipo guarda en memoria el TGT completo de cualquiera que se autentique contra él. Si tengo administrador local en ese equipo, espero (o fuerzo) a que se conecte un usuario con privilegios y robo su TGT.

beacon> ldapsearch (userAccountControl:1.2.840.113556.1.4.803:=524288) --attributes samaccountname
beacon> execute-assembly C:\Tools\Rubeus\Rubeus.exe monitor /nowrap     // capturo TGTs entrantes

Para forzar que el DC se conecte se usa un coerce (por ejemplo, el "printer bug").

Constrained

El equipo puede pedir tickets en nombre de otros, pero solo para los servicios de su lista (msDS-AllowedToDelegateTo). Con su TGT uso S4U para obtener un ticket como Administrator hacia ese servicio.

Truco: el ticket no fija el nombre del servicio, así que con /altservice puedo cambiar time/ por cifs/ y pasar de un servicio inofensivo a acceso a disco.

beacon> execute-assembly C:\Tools\Rubeus\Rubeus.exe s4u /user:ws01$ /msdsspn:time/dc01 /altservice:cifs /ticket:<TGT> /impersonateuser:Administrator /nowrap

Resource-Based (RBCD)

Aquí la regla vive en el destino: el atributo msDS-AllowedToActOnBehalfOfOtherIdentity dice quién puede delegar hacia él. Si puedo escribir ese atributo en un equipo (porque tengo GenericWrite sobre él), añado una cuenta que yo controle y hago S4U hacia ese equipo como cualquier usuario.

Cómo se defiende

• No usar Unconstrained. Si existe, marcar las cuentas sensibles como "Account is sensitive and cannot be delegated" y meterlas en Protected Users.
• Revisar quién tiene msDS-AllowedToDelegateTo y permisos de escritura sobre objetos de equipo.
• Poner los DCs y cuentas críticas fuera del alcance de cualquier delegación.