Pentesting en Active Directory: Pass-the-ticket & Mimikatz

En el lado del mal hemos hablado de mucho Ethical Hacking durante años. Hemos hablado de herramientas como Mimikatz, quizá una de las más potentes y utilizadas en el Hacking de redes Windows internamente. Técnicas como, pass-the-hash, pass-the-ticket, golden & silver ticket, que Benjamin Delpy se ha encargado de ir metiendo a su querido Mimikatz. Con Benjamin Delpy coincidimos en la Euskalhack 2018 y fue bastante emocionante poder disfrutar de sus conocimientos en el congreso y en las cenas.

Figura 1: Pentesting en Active Directory: Pass-the-ticket & Mimikatz

Hoy no voy a hablar de algo nuevo que trae Mimikatz, si no que quiero hablar de conceptos de autenticación en el Active Directory, en este caso en Windows Server 2016, y cómo podemos aplicar la técnica Pass-the-ticket. Esta técnica tiene su análoga con pass-the-hash, de la cual ya hemos hablado en el blog en más de una ocasión.

 

Figura 2: Libro de Hacking Windows

Antes de entrar en materia, quiero recordar algunos de los artículos relacionados con Mimikatz que hemos ido haciendo y viendo en su momento. Es una navaja suiza en toda regla, con más de 9 años de desarrollo y sigue dando mucha guerra. Es algo digno de admirar. Recuerdo cuando salió DCShadow y la foto del niño que quería llegar a ser un Domain Controller. Hemos visto cómo poner una Skeleton Key al Domain Controller. Con Mimikatz hemos visto cómo extraer credenciales de memoria haciendo un minidump al proceso lsass.exe. También vimos como Zerologon llegaba a Mimikatz hace unos meses.

Kerberos in a nutshell

Si nos preguntamos qué es Kerberos, lo encontramos muy bien explicado en este post de los compañeros de Tarlogic. Podemos decir que es un protocolo de autenticación utilizado, por ejemplo, en el Active Directory. La idea del protocolo es que se sirvan una serie de tickets (o "vales" en alguna traducción al castellano, en alguna documentación) para poder acceder a ciertos recursos en el dominio. Podemos decir que existen tres roles diferentes dentro del esquema de autenticación en Kerberos:

- Usuario o cliente. Éste será el que pida el ticket y tenga que autenticarse para poder acceder al recurso. 

 

- KDC o Key Distribution Center. Éste es el servicio Kerberos. Se encarga de gestionar y emitir los tickets que serán utilizados por los clientes para acceder a los recursos o servicios. 

 

- AP o servicio de aplicación. Al final es el recurso al que el cliente quiere acceder. Lo hará a través del uso de un ticket que verifique que puede acceder al recurso.

Hay una serie de elementos clave que juegan un papel fundamental en la ecuación. A continuación, os dejo un resumen de las diferentes claves:

- Del usuario: Ésta será un hash (o un derivado más bien) ntlm. 

 

- De la cuenta krbtgt: El hash ntlm de la cuenta del KDC en el Domain Controller. 

 

- Del servicio: El servicio expuesto en el dominio tendrá una cuenta de servicio o de usuario que será el que lo habrá lanzado. 

 

- De sesión: Clave obtenida entre la negociación del KDC y del cliente. 

 

- De sesión de servicio: Clave obtenida para utilizarla entre el cliente y el servicio.

Ahora hablemos de los tickets. El primer ticket que trataremos es el TGT o Ticket Granting Ticket. Lo presentaremos ante el KDC para obtener el TGS o Ticket Granting Service. El TGT será cifrado con la clave del KDC, es decir, la clave derivada de la cuenta del krbtgt. A esto volveremos más adelante. El TGS se obtiene de un TGT enviado al KDC. El TGS lo presentaremos al servicio que tiene el recurso al que queremos acceder. El TGS es cifrado con la clave de servicio.

¿Cuál es el flujo normal de todo esto?

A priori, puede parecer algo complejo, pero no es así. Vamos a intentar simplificar el proceso. Partimos de tres máquinas con las siguientes configuraciones:

- Máquina Windows 10, la llamaremos A, en la que estoy yo.

- Domain Controller, la llamaremos KDC, con Windows Server 2016.

- Máquina Windows Server 2016, la llamaremos R de recurso, que no es Domain Controller o máquina Windows 10 que tiene un servicio al que queremos acceder.

Lo primero es solicitar un ticket TGT. Para ello mi máquina A envía una petición KRB_AS_REQ a la máquina KDC. En este mensaje la máquina A envía información como un timestamp que está cifrado con una clave derivada del hash del usuario, es decir, del hash de mi contraseña de dominio. En esta petición se envía el nombre de usuario, el SPN para la cuenta krbtgt y un nonce.

Cuando el KDC recibe esto, se valida la información cifrada, para ver si la clave de dicho usuario es correcta, es decir, descifra el contenido del timestamp. El KDC va a producir la respuesta KRB_AS_REP. En esta respuesta se envían varias cosas como, por ejemplo, el nombre de usuario, el ticket TGT y unos datos cifrados con la clave del usuario.

Estos datos cifrados con la clave del usuario, al volver a la máquina A podrían ser descifrados. ¿Qué me está devolviendo el KDC? La clave de sesión, que será importante, la fecha de expiración del TGT y un nonce. El ticket suele tener una validez de 10 horas. Esto puede ser alterado, y mucho, en un ataque Golden Ticket o Silver Ticket. ¿Qué encontramos en el TGT? Encontraremos el nombre de usuario, la clave de sesión de nuevo, la fecha de expiración y el PAC. El PAC es una estructura de datos que trae información sobre los privilegios. El TGT está cifrado con la clave de la cuenta krbtgt, es decir, con el KDC.

 

Figura 3: Máxima Seguridad en Windows Gold Edition

Ahora tenemos un ticket TGT en la máquina A. Este ticket nos vale para solicitar un TGS y poder acceder al recurso dentro del Active Directory que me interese y tenga acceso, claro. Desde la máquina A a la máquina KDC enviamos una petición KRB_TGS_REQ. Esta petición contiene lo siguiente:

- El nombre de usuario y timestamp cifrados con la clave de sesión. 

 

- El TGT que nos ha enviado en el paso previo, el cual se encuentra cifrado con la clave de krbtgt, es decir, con el KDC. 

 

- El SPN y un nonce.

Si todo sigue su curso, ¿qué nos devuelve el KDC? La máquina KDC envía una respuesta KRB_TGS_REP a la máquina A. En ella encontraremos:

- El nombre de usuario. 

 

- La clave de sesión, la fecha de expiración del TGS y un nonce cifrados con la clave de sesión. 

 

- La clave de sesión de servicio (esta es importante), nombre de usuario, fecha expiración del TGS y el PAC. Todo ello cifrado con el hash de la cuenta propietaria del servicio.

Ahora tenemos el ticket TGS. Ahora solo debemos enviarlo a la máquina R, la cual es la que tiene el recurso al que queremos acceder. Desde la máquina A se hace una petición KRB_AP_REQ a la máquina R. En esta petición se envía el ticket TGS cifrado con la clave de la cuenta propietaria del servicio.

Figura 4: Esquema de funcionamiento de Kerberos

Luego el nombre de usuario y el timestamp van cifrados con la clave de sesión de servicio. Cuando esta información llega a la máquina R, se valida y se da acceso al recurso. En la imagen del artículo de Tarlogic se detalla muy bien.

Ahora: Pass-the-ticket

Tras explicar el funcionamiento básico del protocolo Kerberos, vamos a ver un ataque llamado Pass-the-ticket y que consiste en hacer algo similar al Pass-the-hash pero en un entorno de Windows Server 2016 con un Active Directory. Es decir, haremos una suplantación de usuario, en vez de utilizando el hash ntlm de la cuenta del usuario, utilizaremos un ticket Kerberos con validez y que pertenezca a dicho usuario.

Figura 5: Libro Windows Server 2016:
Administración, Seguridad y Operaciones

¿Dónde podemos encontrar estos tickets? Al final cualquier máquina de un dominio hace uso de Kerberos, por lo que los tickets se encuentran en cada una de esas máquinas. Al llegar a una máquina de dominio, comprometerla y escalar privilegios, podemos hacer uso de Mimikatz para sacar partido en el Ethical Hacking.

Figura 6: Uso de klist

Con la herramienta klist podemos ver los tickets que se encuentran almacenados en la sesión del usuario. Es decir, los que utilizara cuando quiera acceder a los recursos de una máquina del dominio. Los tickets pueden ser TGT o TGS. En el caso de tener el TGT se hará el proceso para conseguir el TGS y llegar al recurso deseado. Si utilizamos Mimikatz con su módulo sobre Kerberos tenemos muchas opciones:

- La opción ptt. Nos permitirá hacer el Pass-the-ticket. 

 

- La opción list. Nos lista los tickets que tenemos en memoria en nuestra sesión. 

 

- La opción purge. Permite eliminar tickets de memoria en nuestra sesión. 

 

- La opción tgt. Para ver qué ticket estamos usando en memoria. 

 

- La opción golden. Nos permite generar Golden Tickets y Silver Tickets, pero esto lo hablaremos en otro artículo.

Con la instrucción “sekurlsa::tickets” podemos ver los tickets que hay en memoria en la máquina, los nuestros y los de otros usuarios. Esto es bastante poderoso, ya que podemos sacarle mucho juego. Por ejemplo, hacer la suplantación de otro usuario. Con la opción “sekurlsa::tickets /export” exportaremos todos los tickets a disco, con extensión *.kirbi.

Si nos quedamos con los ficheros kirbi que contienen “*Administrador@krbtgt*” tendremos un TGT y viendo la palabra Administrador o Administrator podemos pensar que estamos de suerte. En otras ocasiones, quizá solo nos interesa utilizar otros tickets para poder llegar a ciertos recursos. No todo es ser admin.

Figura 7: Ejecución de kerberos::ptt en Mimikatz

Ahora, nos vamos con los tickets recogidos a otra máquina. Podemos usarlos en máquinas que estén o no estén en el dominio. Es decir, podemos llevárnoslo a nuestra máquina y trabajar tranquilamente. Para hacer el pass-the-ticket ejecutamos "kerberos::ptt [ticket.kirbi]". Con el ticket anterior, intentamos leer el recurso c$ del Domain Controller y obtenemos la respuesta deseada. Tenemos acceso al Domain Controller.

Figura 8: Acceso al Domain Controller conseguido

La idea del artículo es mostrar cómo funciona Kerberos y mostrar un ejemplo de ataque en el Active Directory  a Kerberos. Existen muchas posibilidades y es un mundo interesante que se debe conocer para un pentesting interno en una organización. Sin duda, interesante el mundo Kerberos y sus ataques.

Saludos,

Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters: Gold Edition", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell (2ª Edición)”, "Pentesting con Kali Silver Edition" y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González - Conseguir 100 Tempos Gratis en MyPublicInbox

 Contactar con Pablo González