AS-REQroasting, AS-REProasting and TGS-REProasting (Kerberoasting) – Kerberos

deephacking.tech/as-reqroasting-as-reproasting-y-tgs-reproasting-kerberoasting-kerberos

December 19, 2022

In this blog we have already talked about kerberos, and, if you have at least a vague idea of ​how it works, you will know that in certain
steps of an authentication of this protocol, certain information is encrypted with the hash of the user's password.

What's up with this? If we are able to intercept one of these communications where something encrypted with the hash of the user's
password travels, we can try to crack this information, so that, if we manage to decrypt it, we will have found out the user's password.

The authentication steps of this protocol that include information encrypted with the hash of a user's password are:

AS-REQ (1st step)

AS-REP (2nd step)
TGS-REP (4th step)

We are going to see each step and how we can exploit each one of them. If you want to read and know how kerberos works before
continuing with this post, see the following article:

Humble attempt to explain Kerberos

AS-REQroasting
In the kerberos authentication process, in the step called AS-REQ, the user sends the following information through the network:

The user sends a timestamp encrypted with the hash of his password. Therefore, if we intercept this packet, we can try to crack it so that, if
we manage to decrypt it, it will be because we have found out the password.

You may wonder how we intercepted this packet, and the answer is simple, sniffing the network.

Being connected to the same network as an active directory, as an attacker we can listen in a totally passive way to collect all the packets
that move on the network, with the idea that one of them is an AS-REQ.

There are multiple tools that allow us to sniff the network in order to capture credentials and authentication, or in turn, pass a PCAP file
that we have as input (since many times, especially when we are not doing the audit in person, we will have to use another machine to
snort the traffic, and in these cases we will generate a PCAP and bring it to our machine):

1/13
 PCredz
apt install python3-pip && sudo apt-get install libpcap-dev && pip3 install Cython && pip3 install python-libpcap
In the case of a libpcap not installed error, we can make use of the Docker version:
PCredz Docker
alias pcredz='sudo docker run –rm -it –network host -v ~/.pcredz:/home/<USER>/.pcredz snovvcrash/pcredz'

Net Creds
credslayer

I consider PCredz to be the most complete, or at least the most up-to-date. However, it is true that it is the one that can cause the most
problems in the installation and execution. In any case, it is important to know alternatives to these tools like the ones I mentioned above.

When it comes to capturing AS-REQ requests, it is true that I have had problems and in my local active directory I have not been able to
detect them with these tools. However, this does not mean that it cannot be done. The most manual way to do it is using wireshark itself to
be able to see all the packets in RAW:

The fields of an AS-REQ packet necessary to generate the string that we will later pass to John or Hashcat are:

Username
Domain – Example: DEEPHACKING.LOCAL (Important, DEEPHACKING asecas would not work, the full domain is required)
Cipher

With wireshark we can find all this data in a simple way by analyzing each packet:

2/13
 https://www.wireshark.org/docs/dfref/k/kerberos.html

With this data, we form a string with the following structure:

$krb5pa$18$<username>$<domain>$<cipher>

So, in this case it would look like this:

$krb5pa$18$rosa.melano$DEEPHACKING.LOCAL$740eb5f92bf6d5dfa18fd860ceae7d99ce1e3f7fb7a7d2f8a0c776c316f80aefc4fe91155

The manual way through wireshark that we just saw is easily automatable in bash using tshark :

#!/bin/bash

# Usamos tshark para filtrar los paquetes AS-REQ y mostrar los campos CNameString, realm y cipher

filter=$(tshark -r $1 -Y "kerberos.msg_type == 10 && kerberos.cipher && kerberos.realm && kerberos.CNameString" -T fields -e

kerberos.CNameString -e kerberos.realm -e kerberos.cipher -E separator=$ )

for i in $(echo $filter | tr ' ' '\n') ; do

echo "\$krb5pa\$18\$$i"

done

Thus, if we pass this script a PCAP file, it will parse for AS-REQ packets, and return it in hashcat format:

3/13
With this, we proceed to pass it to hashcat with the following command:

hashcat -m 19900 <hashed file> <dictionary>

It never hurts to confirm the format of the hash we have using the hashlist of hashcat examples .

And ready. We get the passwords which the user has used to try to authenticate. Since the AS-REQ is the first step of kerberos, we may
detect correct or incorrect passwords, as is the case above, where we detect multiple passwords for the same user. With the same
wireshark, based on the AS-REP, we will be able to determine which is the correct one :).

And basically this is AS-REQroasting, sniffing this type of packet on the network in order to later try to crack it offline.

AS-RE Proasting
Ya hemos visto un paso donde se envían datos cifrados usando el hash de la contraseña del usuario, pero no es el único. Justamente la
respuesta a la petición del AS-REQ, es decir, el AS-REP, también contiene datos cifrados de la forma mencionada:

4/13
El KDC envía la clave de sesión cifrada con el hash de la contraseña del usuario con el fin de que el usuario, cuando reciba el mensaje,
pueda leer la clave de sesión.

El AS-REProasting es un poco distinto al AS-REQroasting, porque en este último, dependemos completamente del sniffing para obtener
un paquete de este tipo. Sin embargo, el AS-REProasting, se puede “forzar” si se dan ciertas condiciones.

Una de estas condiciones es que un usuario del dominio tenga habilitado el atributo DONT_REQ_PREAUTH :

Este atributo hace que el primer paso de una autenticación de kerberos, no sea necesaria, es decir, cualquier persona puede generar un
respuesta AS-REP para el usuario que tenga este atributo habilitado. Esto quiere decir, que cualquier persona puede obtener un dato
cifrado con el hash de la contraseña del usuario.

Por ejemplo, vamos a simular el escenario en el que tenemos un usuario del dominio. Nosotros como tal, no sabemos si algún usuario del
dominio tiene habilitado el atributo DONT_REQ_PREAUTH , es algo que tenemos que comprobar, por lo que, primero de todo, usando
las credenciales de la cuenta de dominio que ya tenemos, enumeramos todos los usuarios del dominio:

impacket-GetADUsers -all <dominio>/<usuario>:<contraseña> -dc-ip <ip dc>

5/13
De la salida del comando, creamos un archivo con los usuarios del dominio:

Y ahora, teniendo una lista de todos los usuarios del dominio, si tenemos suerte, puede que alguno tenga el atributo
DONT_REQ_PREAUTH habilitado. Lo comprobaremos de la siguiente manera:

impacket-GetNPUsers <dominio>/ -usersfile <archivo con listado de usuarios> -no-pass -format john -dc-ip <ip dc>

En este caso, tanto el usuario Administrator como el usuario lola.mento lo tienen habilitado, por lo que obtenemos datos cifrados que
podemos intentar crackear de forma offline para obtener la contraseña de los usuarios en cuestión.

Agregando el parámetro -format hashcat , podemos decir que nos lo muestre en formato hashcat en vez de john. También, podemos especificar el
parámetro -outputfile cipherdata.txt para que nos exporte directamente los datos a un archivo.

Teniendo estos datos, podemos intentar crackearlos, ya sea con john o hashcat:

6/13
De esta forma, se consiguen obtener las contraseñas de los usuarios.

El comando para crackear con hashcat sería:

.\hashcat.exe -O -m 18200 -a 0 <archivo> <diccionario>

Todo este proceso que hemos realizado también se puede hacer desde Windows.

Pongámonos en la situación, en la que, estamos conectados por VPN a la red donde se encuentra el directorio activo (si estuviésemos
conectados presencialmente, pues por supuesto que también funcionaría). Nosotros estamos con nuestro equipo corporativo con
Windows, en el cual se ejecuta la VPN, y dentro del Windows, pues está nuestro kali con por ejemplo NAT, esto último es un poco
indiferente, pero es por detallar una situación bastante común, si no la que más.

Bien, con todo esto, desde tu Windows, aunque no pertenezca al directorio activo que vas a auditar, puedes abrir una consola en el
contexto del directorio activo objetivo usando RunAs :

runas /netonly /user:<FQDN del dominio>\<usuario> cmd.exe

Importante, este comando te abre la consola sin importar que la contraseña que hayas puesto sea correcta o no, es decir, cuando introduces la
contraseña no hace la verificación, para que en caso de que sea correcta abrirte la consola, y de lo contrario no hacerlo.

Por lo que hay que tener mucho cuidado, y asegurarse al 100% de que has introducido la contraseña bien, sino, nada funcionará, e incluso,
puedes llegar a bloquear el usuario del dominio si tiras alguna herramienta y hace múltiples peticiones con contraseña incorrecta.

Otra cuestión es que en la situación que hemos propuesto, al estar conectados por VPN, el DNS automáticamente se configurará para el DC. En
caso de que no fuera así, tendremos que configurar en nuestro equipo la IP del DC como DNS.

Ahora, usando la consola que tenemos en el contexto del usuario del directorio activo, podemos usar la herramienta que queramos para
realizar el AS-REProasting. En este caso, usaré Rubeus:

Rubeus.exe asreproast

7/13
 Rubeus admite especificar el formato del hash para su posterior crackeo con los siguientes argumentos:

/format:hashcat
/format:john

¡Y listo! Acabamos de hacer un AS-REProasting desde un Windows que NO pertenece al dominio, usando una consola en el contexto de
un usuario del dominio ajeno. Este uso de RunAs es muy útil, ya que hará que cualquier herramienta de Windows funcione para auditar el
dominio objetivo.

Otra herramienta para realizar el AS-REProasting en Windows es:

ASREPRoast.ps1

De forma adicional, desde Windows, podemos enumerar los usuarios que tengan el DONT_REQ_PREAUTH de las siguientes maneras:

Usando PowerView
Get-DomainUser -PreauthNotRequired -Properties SamAccountName
Usando el módulo de ActiveDirectory de Microsoft
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $True} -Properties DoesNotRequirePreAuth

Desde linux, además de la forma que hemos visto, también podríamos hacerlo usando otras herramientas:

ldapdomaindump
ldapper
Módulo de CrackMapExec

La segunda condición por la cual es posible forzar un AS-REProasting es a través de los ACL (Access Control List). Si tenemos privilegios
de WriteProperty , GenericWrite o GenericAll sobre un usuario del dominio, podemos forzar a habilitarle el DONT_REQ_PREAUTH .

Para hacer esto, seguiríamos el siguiente proceso:

8/13
 1. Enumeraríamos los ACL de un grupo al que pertenezcamos para ver si tenemos algún permiso interesante sobre algún objeto, esto lo
podemos hacer usando PowerView:
Find-InterestingDomainAcl -ResolveGUIDs | ?{$_.IdentityReferenceName -match “<nombre grupo>”}
2. Una vez ya sabemos que tenemos alguno de los permisos mencionados sobre un usuario, le habilitaríamos el
DONT_REQ_PREAUTH con el siguiente comando también de PowerView:
Set-DomainObject -Identity <nombre usuario> -XOR @{useraccountcontrol=4194304} –Verbose

De esta manera, si volviésemos a enumerar los usuarios con la característica habilitada, nos saldría el usuario que acabamos de forzar y ya
sería cuestión de crackear el hash para obtener su contraseña.

Entonces, como conclusión, el AS-REProasting tiene tres vertientes:

Una es que estemos esnifando la red y logremos pillar paquetes AS-REP. Ya hemos visto herramientas que nos pueden servir para
pillar este tipo de peticiones.
Que un usuario del dominio tenga el atributo DONT_REQ_PREAUTH , y, por tanto, podamos generar un AS-REP.
Que tengamos permisos sobre un usuario del dominio y que nosotros mismos generemos la vulnerabilidad.

En cualquiera de las tres situaciones, una vez tengamos un paquete AS-REP, es hora de crackear, como hemos hecho al principio.

TGS-REProasting (Kerberoasting)
Por último, el famoso Kerberoasting. Este ataque se origina en el KRB_TGS_REP, este paso, también contiene unos datos cifrados que
interesan de cara a intentar crackearlos y obtener la contraseña de un usuario del dominio:

En este paso, el KDC envía:

El TGS (aka. Service Ticket (ST)) cifrado con el hash de la contraseña del usuario que corre el servicio
Una nueva clave de sesión para las comunicaciones

Y todo esto, cifrado con la primera clave de sesión, la recibida en el KRB_AS_REP.

Bien, sabiendo esto, debemos saber que cualquier usuario del dominio, puede pedirle al DC un TGS para cualquier servicio, el hecho de
que pueda o no acceder ese usuario en cuestión, dependerá del propio servicio y no es trabajo del DC validarlo. El único trabajo del DC, es
proporcionar el PAC (información de seguridad relacionada con el usuario) cuando le piden un TGS.

Entonces, de cara a pedir un TGS, lo único que hace falta es especificar el SPN (Service Principal Name). El SPN es la manera de
identificar un servicio en un entorno de directorio activo, y se estructura en:

<clase de servicio>/<hostname o FQDN de la máquina>

En un directorio activo un mismo servicio se puede ejecutar múltiples veces, de la misma forma, una misma máquina, puede ejecutar múltiples
servicios. Es por ello, que para concretar a qué servicio nos queremos referir siempre, se debe de seguir la estructura mencionada.

Una “clase de servicio” es un nombre genérico para un servicio. Por ejemplo, todos los servidores web se agrupan bajo la clase de servicio
con nombre “www”.

Lista de SPN en la documentación oficial de Microsoft (no están todos)

En el caso de que un servicio se ejecute en un puerto distinto al original, la siguiente estructura para referirse a él, es válida:

<clase de servicio>/<hostname o FQDN de la máquina:<puerto>

Como dato, también es posible nombrar con un nombre personalizado a un SPN:

<clase de servicio>/<hostname o FQDN de la máquina>:<puerto>/<nombre que queramos asignarle>

Ejemplo de un SPN siguiendo esta última estructura:

9/13
 cifs/fileserver.deephacking.local:9090/Server_donde_tengo_mis_cositas

Todo esto no es que deba de saberse para la parte práctica que vamos a llevar a cabo. Sin embargo, si es importante conocer estos detalles
para entender mejor como funciona y se estructura un directorio activo. Dicho esto, vamos a volver al Kerberoasting.

Normalmente, un servicio, se ejecutará con una cuenta de máquina. Las cuentas de máquinas poseen por defecto contraseñas aleatorias y
fuertes, por lo que si se consiguiese un dato cifrado con esta contraseña e intentásemos su crackeo no sería útil porque no conseguiríamos
nada.

El caso es, que puede ocurrir que un servicio, esté siendo ejecutado por una cuenta de un usuario normal del dominio, al ser un usuario
normal, puede que su contraseña no sea fuerte, por lo que las posibilidades de crackearla aumentan mucho. Estos casos son los que de
verdad interesan y la fuente que da sentido a que exista el Kerberoasting.

Entonces, técnicamente, podemos conseguir un TGS para todos los SPN, pero, solo nos interesan los SPN de servicios que estén siendo
ejecutados por cuentas de usuario del dominio, porque sus contraseñas puede que sean débiles.

Bien, ya sabemos toda la parte teórica del kerberoasting, por lo que vayamos a la parte práctica.

Para enumerar desde Linux los SPN que corren en cuentas de usuarios normales, podemos hacer uso de impacket:

impacket-GetUserSPNs <fqdn del dominio>/<usuario>:<contraseña> -dc-ip <ip del dc>

En este caso, con el comando de arriba estaremos enumerando los SPN de usuarios normales, pero no estaremos pidiendo los respectivos
TGS, para pedirlos tenemos que agregar el argumento -request :

impacket-GetUserSPNs -request <fqdn del dominio>/<usuario>:<contraseña> -dc-ip <ip del dc>

Una vez tenemos el hash para crackear, se lo pasamos por ejemplo a hashcat:

.\hashcat.exe -O -m 13100 -a 0 <archivo> <diccionario>

10/13
De esta manera, conseguimos la contraseña del usuario.

Y, al igual que con el AS-REProasting, lo mismo se puede hacer desde Windows, abrimos una cmd en el contexto del usuario del dominio
como hemos hecho antes y usamos de nuevo rubeus (o cualquier otra herramienta que haga un kerberoasting):

Rubeus.exe kerberoast
Otros posibles argumentos a añadir a este comando:
/user:<SPN> –> especificar el SPN del cual queremos obtener un TGS (para que no lo haga con todos).
/outfile:<nombre archivo> –> especificar archivo donde se guardará la salida del comando.
/format:<formato hash> –> Lo que hemos visto en el AS-REP, el formato para su posterior crackeo

11/13
Otra alternativa a Rubeus para realizar este proceso sería Invoke-Kerberoast.ps1.

Para enumerar las cuentas kerberoasteables desde Windows, podemos hacer uso de alguna de las siguientes herramientas:

PowerView
Get-DomainUser –SPN
Get-NetUser | Where-Object {$_.servicePrincipalName} | fl
Active Directory Module
Get-ADUser -Filter {ServicePrincipalName -ne “$null”} -Properties ServicePrincipalName
Usando un binario nativo de Windows
setspn -T <dominio> -Q */*

Con este último comando es posible que se deba hacer un filtrado, más información aquí:

Setspn

Aparte de todo lo visto, es importante saber que un TGS también se puede obtener dumpeandolo de la memoria, el siguiente artículo de
Netwrix explica bastante bien este caso concreto:

Extracting Service Account Passwords with Kerberoasting

Además, al igual que ocurre en el AS-REP, si tenemos privilegios de WriteProperty , GenericWrite o GenericAll sobre un usuario del
dominio, podemos añadir un SPN a ese usuario para que sea vulnerable a kerberoasting. La siguiente fuente lo explica bastante bien:

12/13
 Targeted Kerberoasting
Sobre lo de tener privilegios, recuerda que puede ocurrir que nosotros directamente no tengamos, pero que un grupo al que
pertenecemos si los tenga (o un grupo al que pertenezca el grupo al que pertenecemos… xD), por lo que también es importante
enumerar las ACLs de los usuarios que tengamos. Recordemos que esto último se puede hacer usando PowerView:
Find-InterestingDomainAcl -ResolveGUIDs | ?{$_.IdentityReferenceName -match “<nombre del grupo>”}

Para concluir con el kerberoasting, es importante resaltar que si conseguimos crackear alguna cuenta, no solo habremos obtenido otra
cuenta del dominio, y, por tanto, tendremos que realizar todas las comprobaciones que se hacen siempre que se consigue una cuenta
nueva: ver si es local admin en alguna máquina, que privilegios tiene, etc, etc…

Lo verdaderamente interesante, es que hemos crackeado la cuenta de un usuario propietario de un servicio.

¿Qué quiere decir esto?

Puedes mirar un recordatorio al paso KRB_TGS_REP en Humilde intento de explicar Kerberos. Pero básicamente, tenemos la contraseña
que se usa para cifrar los TGS (Service Ticket (ST)) que se envían siempre para otorgar acceso a un usuario al servicio en cuestión. Por
tanto, tenemos la clave necesaria para impersonar a cualquier usuario en ese servicio porque podemos crear Service Tickets (ST/TGS).
Esto es básicamente lo que se hace cuando se realiza un Silver Ticket.

De forma práctica, si por ejemplo, a través de kerberoasting conseguimos crackear la contraseña de un usuario que ejecuta un servidor de
correo. Podremos generar TGS para cualquier usuario existente en ese servicio, con el fin de, en este caso concreto, leer sus correos.

Con el kerberoasting tampoco olvidemos la importancia de hacer sniffing

Conclusión
Poniendo en conjunto todo lo que hemos visto en este artículo, una posible vía de explotación para aprovecharnos de todo lo visto, sería:

1. Obtener una cuenta del dominio a través de AS-REQ o AS-REP .

2. Enumeración y obtención de tickets de servicio a través de TGS-REP usando la cuenta de dominio conseguida.
3. Si conseguimos crackear algún ST obtenido, podremos acceder al servicio cuya contraseña de usuario que lo ejecuta hemos
crackeado, impersonando a los distintos usuarios y accediendo a toda la información disponible.

Por último, recalcar la importancia de hacer sniffing en una red o comprobar los ACL, estas dos cosas pueden determinar que consigamos
o no comprometer el dominio ^^.

13/13