Kerberoasting
Credential Access
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.
Execution
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:
Extracting the Ticket
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:
Cracking the Ticket
Attacker brute forces the password of the service ticket:
Observations
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):
Traffic
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
:
tgsrepcrack.py
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:
References
Tim Medin - Attacking Kerberos: Kicking the Guard Dog of Hades
Last updated