Resource-based Constrained Delegation
Last updated
Last updated
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
Esto es similar a la Delegación Constrain básica pero en lugar de dar permisos a un objeto para suplantar a cualquier usuario contra un servicio. La Delegación Constrain Basada en Recursos establece en el objeto quién puede suplantar a cualquier usuario contra él.
En este caso, el objeto restringido tendrá un atributo llamado msDS-AllowedToActOnBehalfOfOtherIdentity con el nombre del usuario que puede suplantar a cualquier otro usuario contra él.
Otra diferencia importante de esta Delegación Constrain a las otras delegaciones es que cualquier usuario con permisos de escritura sobre una cuenta de máquina (GenericAll/GenericWrite/WriteDacl/WriteProperty/etc) puede establecer el msDS-AllowedToActOnBehalfOfOtherIdentity (En las otras formas de Delegación necesitabas privilegios de administrador de dominio).
En la Delegación Constrain se mencionó que el TrustedToAuthForDelegation flag dentro del valor userAccountControl del usuario es necesario para realizar un S4U2Self. Pero eso no es completamente cierto.
La realidad es que incluso sin ese valor, puedes realizar un S4U2Self contra cualquier usuario si eres un servicio (tienes un SPN) pero, si tienes TrustedToAuthForDelegation el TGS devuelto será Forwardable y si no tienes ese flag el TGS devuelto no será Forwardable.
Sin embargo, si el TGS utilizado en S4U2Proxy NO es Forwardable intentar abusar de una delegación Constrain básica no funcionará. Pero si estás tratando de explotar una delegación Constrain basada en recursos, funcionará (esto no es una vulnerabilidad, es una característica, aparentemente).
Si tienes privilegios de escritura equivalentes sobre una cuenta de Computadora puedes obtener acceso privilegiado en esa máquina.
Supongamos que el atacante ya tiene privilegios de escritura equivalentes sobre la computadora víctima.
El atacante compromete una cuenta que tiene un SPN o crea uno (“Servicio A”). Ten en cuenta que cualquier Usuario Administrador sin ningún otro privilegio especial puede crear hasta 10 objetos de Computadora (MachineAccountQuota) y establecerles un SPN. Así que el atacante puede simplemente crear un objeto de Computadora y establecer un SPN.
El atacante abusa de su privilegio de ESCRITURA sobre la computadora víctima (ServicioB) para configurar delegación basada en recursos para permitir que ServicioA suplantar a cualquier usuario contra esa computadora víctima (ServicioB).
El atacante utiliza Rubeus para realizar un ataque S4U completo (S4U2Self y S4U2Proxy) desde Servicio A a Servicio B para un usuario con acceso privilegiado a Servicio B.
S4U2Self (desde la cuenta SPN comprometida/creada): Pide un TGS de Administrador para mí (No Forwardable).
S4U2Proxy: Usa el TGS no Forwardable del paso anterior para pedir un TGS de Administrador para el host víctima.
Incluso si estás usando un TGS no Forwardable, como estás explotando la delegación basada en recursos, funcionará.
El atacante puede pasar el ticket y suplantar al usuario para obtener acceso al ServicioB víctima.
Para verificar el MachineAccountQuota del dominio puedes usar:
Puedes crear un objeto de computadora dentro del dominio usando powermad:
Usando el módulo de PowerShell de activedirectory
Usando powerview
Primero que nada, creamos el nuevo objeto de Computadora con la contraseña 123456, así que necesitamos el hash de esa contraseña:
Esto imprimirá los hashes RC4 y AES para esa cuenta. Ahora, se puede realizar el ataque:
Puedes generar más tickets pidiendo una vez usando el parámetro /altservice de Rubeus:
Tenga en cuenta que los usuarios tienen un atributo llamado "No se puede delegar". Si un usuario tiene este atributo en Verdadero, no podrá impersonarlo. Esta propiedad se puede ver dentro de BloodHound.
La última línea de comando realizará el ataque S4U completo e inyectará el TGS desde el Administrador al host víctima en memoria. En este ejemplo, se solicitó un TGS para el servicio CIFS desde el Administrador, por lo que podrá acceder a C$:
Aprende sobre los tickets de servicio disponibles aquí.
KDC_ERR_ETYPE_NOTSUPP: Esto significa que kerberos está configurado para no usar DES o RC4 y solo estás proporcionando el hash RC4. Proporciona a Rubeus al menos el hash AES256 (o simplemente proporciónale los hashes rc4, aes128 y aes256). Ejemplo: [Rubeus.Program]::MainString("s4u /user:FAKECOMPUTER /aes256:CC648CF0F809EE1AA25C52E963AC0487E87AC32B1F71ACC5304C73BF566268DA /aes128:5FC3D06ED6E8EA2C9BB9CC301EA37AD4 /rc4:EF266C6B963C0BB683941032008AD47F /impersonateuser:Administrator /msdsspn:CIFS/M3DC.M3C.LOCAL /ptt".split())
KRB_AP_ERR_SKEW: Esto significa que la hora de la computadora actual es diferente de la del DC y kerberos no está funcionando correctamente.
preauth_failed: Esto significa que el nombre de usuario dado + hashes no están funcionando para iniciar sesión. Puede que hayas olvidado poner el "$" dentro del nombre de usuario al generar los hashes (.\Rubeus.exe hash /password:123456 /user:FAKECOMPUTER$ /domain:domain.local)
KDC_ERR_BADOPTION: Esto puede significar:
El usuario que intentas suplantar no puede acceder al servicio deseado (porque no puedes suplantarlo o porque no tiene suficientes privilegios)
El servicio solicitado no existe (si pides un ticket para winrm pero winrm no está en ejecución)
La computadora falsa creada ha perdido sus privilegios sobre el servidor vulnerable y necesitas devolvérselos.
Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)
