Kerberoasting

When starting this Active Directory Exploitation series, we talked about abusing windows features. This post will cover Kerberos (an authentication protocol) and how we can abuse it to gain elevated privileges. The procedure followed for abusing the Kerberos feature is termed Kerberoasting.

Kerberos

Kerberos is a computer network security protocol that authenticates service requests between two or more trusted hosts across an untrusted network, like the internet. It uses secret-key cryptography and a trusted third party (Key Distribution Center; KDC) for authenticating client-server applications and verifying users’ identities.

It was initially developed by MIT in the late 80s. Now, Microsoft Windows uses it as the default authorization mechanism. However, implementations for other OSs exist including Linux, Apple OS, etc.

Three-Headed Dog – History

The protocol derived its name from the three-headed dog Kerberos from Greek myths, the canine guardian to the entrance to the underworld.

But in terms of protocol, the three heads represent the client, the server, and the Key Distribution Center (KDC). KDC acts as the trusted third-party authentication service.

Key Distribution Center (KDC)

KDC is the trusted third party that works as a single process providing 2 functions

• Authentication
• Ticket Granting

Users, machines, and services that use Kerberos rely on KDC alone. Hence, the KDC tickets allow the nodes to authenticate and verify their identity. Also, the authentication process uses a secret cryptography key to protect packets from reading, modifying, and eavesdropping.

Kerberoasting

This is a post-exploitation attack technique that attempts to obtain a password hash of an Active Directory account that has a Service Principal Name (“SPN”).

Kerberoasting – A deep understanding

In this attack, an authenticated domain user requests a Kerberos Ticket (TGS) for an SPN. Also, the received ticket is encrypted with the hash of the service account password affiliated with SPN (an attribute that ties the service to a user account in AD). Finally, the attacker can crack the password hash for further escalation.

The steps followed in Kerberos can be understood through the following image and steps

1. The Domain Controller acts as a KDC. The user authenticates to DC with their credentials (NTLM) and requests for TGT (Ticket Granting Ticket)
2. The DC sends back the TGT encrypted with krbtgt hash (Kerberos Ticket Granting Ticket).
   • This TGT can be used to authenticate to DC for requesting Kerberos Service Tickets
3. Each service has an SPN associated with it. In order to access the service (antivirus, SQL, or any other), a user must get the SPN for that service. The user’s machine automatically does the SPN lookup
4. To access the service, the user must get the TGS Ticket (Ticket Granting Service) to authenticate with the Authentication Server. For this, the user requests the TGS from DC by providing the TGT
5. The DC knows the server’s account hash, encrypts the TGS with it, and sends it back to the user
   • The DC does not know whether the user is allowed to access the service or not
6. The user then authenticates with the Application Server by providing the TGS
7. The Authentication Server replies back with either Yes or No depending on the user’s privilege to access the service

Any-Privilege Attack

For Kerberoasting, we just need a valid user account (username and password). It does not matter whether the account is an admin or a normal user account, we can perform this attack. We just need to request the TGS for the service and in return, we will get the hash of the service account’s password. Then we can crack the hash to gain the plaintext password for the service account.

This is important because most of the time, the service accounts are given admin privileges. This can lead to having admin privileges and much more.

Kerberoasting Attack

For the demonstration, we will use one of the tools from the amazing package impacket. For this attack, we need the following information

Username: fcastle
Password: P@$$w0rd1
DC_IP   : 192.168.37.173

Getting SPNs

We will use GetUserSPNs tool from impacket and pass the credentials along with the domain name to get the SPNs. Use the following command for this

impacket-GetUserSPNs DOMAIN/Username:Password -dc-ip DC_IP

impacket-GetUserSPNs MARVEL.local/fcastle:P@\$\$w0rd -dc-ip 192.168.37.173

Note that to bypass the bash variable indicator, the dollar symbol ($), I have added a backslash to escape it.

The output will show if there are any SPNs as below

From the output, it is clear that we have one SPN (Service Principal Name) with the name SQLService. Just a reminder that we created this SPN while setting up the lab. You can always check it out from here.

Requesting Hash

Now, as we have SPN, we can request TGS by just adding a flag -request in the command as below

impacket-GetUserSPNs MARVEL.local/fcastle:P@\$\$w0rd1 -dc-ip 192.168.37.173 -request

The output will give us the TGS containing the Kerberos hash of the service account’s password

Cracking Hash

Now, as we have the hash, we can try cracking it using either John The Ripper or Hashcat. The first part of the hash tells its type as Kerberos 5 TGS-REP. Save the hash in a file and use the wordlist (I will use rockyou) using the following command for John The Ripper

john --format:FORMAT HASH_FILE --wordlist=PATH_TO_WORDLIST

john --format:krb5tgs hash --wordlist=/usr/share/wordlists/rockyou.txt

The password is cracked as MYPassword123#

Alternatively, you can use the following command to crack using Hashcat

hashcat -m 13100 hash /usr/share/wordlists/rockyou.txt -O

What Next?

We discovered that this SPN is associated with the account SQLService and we cracked the password MYPassword#. Next, we can access the account and see what privileges it has. As mentioned earlier, if the account is given Domain Admin privileges, we can get to Domain Controller and reveal other information for lateral movement. Also, if the SPN account is Domain Admin, we can have vertical privilege escalation and get higher privileges.

Kerberoasting Mitigations

Since Kerberos is a feature, we can’t really mitigate it but rather improve the human factor to make it harder for the attacker to complete the purpose. So, the following are the mitigation strategies

• Use strong passwords
  • Lengthier Passwords
  • Consume alphanumeric values along with special symbols to make it unique and harder to guess
• Least privilege principle
  • Do not make service accounts domain admin