Kerberoasting
Introduction
Kerberoasting is a post-exploitation attack in which an attacker requests a Ticket Granting Service (TGS) ticket for a service account. Since the TGS is encrypted using the password hash of the requested service account, the attacker can attempt to crack it using brute force or a dictionary attack.
If the attacker successfully decrypts the TGS, it means they have discovered the correct password for the service account. However, for this attack to work, the target account must have a Service Principal Name (SPN)
For more information, we can check these two links to gain a better understanding of the Kerberoasting attack:
Setup Environment
To reproduce this attack, we will need to set up an account with an SPN. To do this, I followed the instructions from the 27:57-minute mark in this video. How to Build an Active Directory Hacking Lab. I will show a quick summary below:
In the DC1, we copy the Administrator account and enter the details like image below:
Then, set up an insecure password. In this case, I chose MYpassword123, and checked the "Password never expires" box.
Open the Command Prompt as Administrator and then run the following command to attach the accounts to the SPN:
setspn -a DC1/SQLService.homelab.local:60111 homelab\SQLService
Attack Path
Let's assume we have obtained the credentials jstone:dragon for Workstation 1 (this could be achieved through social engineering or by using a tool like CrackMapExec). This is a low-privilege user account, but we can use these credentials to perform a Kerberoasting attack to identify any user accounts with an SPN and higher privileges.
On our attacker machine, we need to configure the hosts file and DNS resolution to recognize the homelab.local domain. First, let's fix the /etc/hosts file, add the DC1's IP address and the domain's name
sudo nano /etc/hosts
Then, we need to change our default gateway's IP address to the DC1's IP address ( 192.168.126.2 -> 192.168.126.144 ).
sudo nano /etc/resolv.conf
After configuring the network, we will use GetUserSPNs.py from Impacket to identify any user accounts with a Service Principal Name (SPN) in the target Active Directory environment.
impacket-GetUserSPNs homelab.local/jstone:dragon
As we can see, the result returns a user account named SQLService that has an SPN. Now that we have identified a service account with an SPN, we can request a Ticket Granting Service (TGS) ticket from the server by running the following command:
impacket-GetUserSPNs homelab.local/jstone:dragon -request
The server will return a TGS ticket, which we will save to a file and attempt to crack. Using hashcat with a password list, we will perform a dictionary attack against the encrypted ticket.
As mentioned earlier, the password that can decrypt this ticket is the service account's password. If successfully cracked, we will gain access to the service account credentials. Run the command line below:
hashcat -m 13100 <path_to_TGS_file> <path_to_wordlist>
Detection
Win Event Log
To detect Kerberoasting activity, we need to monitor Windows Event ID 4769. This event is logged whenever a TGS (Ticket Granting Service ticket) is requested.
However, in a real-world environment, many normal user activities require accessing services, leading to a large number of TGS requests and generating massive amounts of Event ID 4769 logs. This makes detecting Kerberoasting attacks challenging.
To narrow down potential attacks, we can focus on TGS requests using RC4 encryption. By default, TGS tickets use AES encryption, but attackers may downgrade the encryption to RC4 for easier brute-force attacks. If we detect a TGS request with RC4 encryption, it could be a strong indicator of a Kerberoasting attack.
The image below shows an example of a log entry related to Kerberoasting activity.
The log show that a TGS was requested by jstone for accessing SQLService. The ticket options is 0x40810010 and the encryption type is 0x17 (RC4)
Wazuh rule
We can create a local rule in Wazuh to detect Kerberoasting. To do this, navigate to the Server Management tab and click on Rules. Then, search for the keyword "local_rule" and click on local_rules.xml.
In local_rules.xml we will add this rule:
<group name="security_event, windows,">
<rule id="110002" level="12">
<if_sid>60103</if_sid>
<field name="win.system.eventID">^4769$</field>
<field name="win.eventdata.TicketOptions" type="pcre2">^(0x40810000||0x40810010||0x60810010)$</field>
<field name="win.eventdata.TicketEncryptionType" type="pcre2">0x17</field>
<options>no_full_log</options>
<description>Possible Keberoasting attack</description>
</rule>
</group>Once the rule is saved, it will be triggered each time a Kerberoasting attack occurs.
Prevention
Since this attack technique relies on the strength of the account password, mitigating it requires the use of long and complex passwords. Implementing Group Managed Service Accounts (gMSA) is also a best practice, as it ensures that service accounts are both long and complex while also automatically managing password rotation, further enhancing security.
References
Last updated