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 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
- 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.
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
- The Domain Controller acts as a KDC. The user authenticates to DC with their credentials (NTLM) and requests for TGT (Ticket Granting Ticket)
- 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
- 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
- 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
- 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
- The user then authenticates with the Application Server by providing the TGS
- The Authentication Server replies back with either Yes or No depending on the user’s privilege to access the service
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.
For the demonstration, we will use one of the tools from the amazing package
impacket. For this attack, we need the following information
DC_IP : 192.168.37.173
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.
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
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
Alternatively, you can use the following command to crack using
hashcat -m 13100 hash /usr/share/wordlists/rockyou.txt -O
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.
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