Kerberoasting
Credential Access
Last updated
Credential Access
Last updated
This lab explores the Kerberoasting attack - it allows any domain user to request kerberos tickets from TGS that are encrypted with NTLM hash of the plaintext password of a domain user account that is used as a service account (i.e account used for running an IIS service) and crack them offline avoiding AD account lockouts.
Note the vulnerable domain member - a user account with servicePrincipalName attribute set, which is very important piece for kerberoasting - only user accounts with that property set are most likely susceptible to kerberoasting:
Attacker setting up an nc listener to receive a hash for cracking:
Attacker enumerating user accounts with serverPrincipalName attribute set:
Using only built-in powershell, we can extract the susceptible accounts with:
It would have been better to use the following command provided by Sean Metcalf purely because of the -filter usage (quicker than select-object), but it did not work for me:
Another alternative working on Linux using bloodyAD:
Additionally, user accounts with SPN set could be extracted with a native windows binary:
Attacker requesting a kerberos ticket (TGS) for a user account with servicePrincipalName set to HTTP/dc-mantvydas.offense.local- it gets stored in the memory:
Using mimikatz, the attacker extracts kerberos ticket from the memory and exports it to a file for cracking:
Attacker sends the exported service ticket to attacking machine for offline cracking:
Attacker brute forces the password of the service ticket:
Below is a security log 4769 showing service access being requested:
If you see Add-event -AssemblyName SystemIdentityModel (from advanced Powershell logging) followed by a windows security event 4769 immediately after that, you may be looking at an old school Kerberoasting, especially if ticket encryption type has a value 0x17 (23 decimal, meaning it's RC4 encrypted):
Below is the screenshot showing a request being sent to the Ticket Granting Service (TGS) for the service with a servicePrincipalName HTTP/dc-mantvydas.offense.local :
Below is the response from the TGS for the user spotless (we initiated this attack from offense\spotless) which contains the encrypted (RC4) kerberos ticket (server part) to access the HTTP/dc-mantvydas.offense.local service. It is the same ticket we cracked earlier with tgsrepcrack.py:
Out of curiosity, let's decrypt the kerberos ticket since we have the password the ticket was encrypted with.
Creating a kerberos keytab file for use in wireshark:
Adding the keytab to wireshark:
Note how the ticket's previously encrypted piece is now in plain text and we can see information pertinent to the requested ticket for a service HTTP/dc-mantvydas.offense.local :
Looking inside the code and adding a couple of print statements in key areas of the script, we can see that the password from the dictionary (Passw0rd) initially gets converted into an NTLM (K0) hash, then another key K1 is derived from the initial hash and a message type, yet another key K2 is derived from K1 and an MD5 digest of the encrypted data. Key K2 is the actual key used to decrypt the encrypted ticket data:
I did not have to, but I also used an online RC4 decryptor tool to confirm the above findings:
Tim Medin - Attacking Kerberos: Kicking the Guard Dog of Hades
