Kerberos Attacks Explained
What is Kerberos?
When it comes to authentication mechanism in a Windows-based environment, we generally speak about two protocols - NTLM and Kerberos
While NTLM authentication works through a principle of challenge and response, Windows-based Kerberos authentication uses a ticketing system.
At a very high level, Kerberos authentication to a service in an Active Directory environment involves the use of a domain controller as a Key Distribution Center (KDC).
How does Kerberos Work?
The Kerberos authentication can be summarized in a diagram below -
1a) The user logs on to the domain join computer using his/her credentials. After this, the initial Authentication Server Request (AS_REQ) containing a timestamp encrypted using a hash derived from the current user’s username and password is sent to Domain Controller.
1b) When the domain controller receives the request, it attempts to decrypt the timestamp using the password hash associated with that user . If the decryption is successful, the authentication is considered successful.
2) The domain controller then replies to the computer/client with an Authentication Server Reply (AS_REP), which contains a session key and a Ticket Granting Ticket (TGT). The session key is encrypted using the user’s password hash, which the computer/client can decrypt and reuse. The TGT contains user information (including group memberships), the domain, a timestamp, the IP address of the client, and also the session key. To avoid tampering, the TGT is also encrypted by a secret key known only to the domain controller. By default, the TGT will be valid for 10 hours.
3a) When the user attempts to access domain resources, such as an application with a registered Service Principal Name (SPN), the domain controller is contacted again.
The client/computers creates a Ticket Granting Service Request (TGS_REQ) packet that consists of the current user and a timestamp (encrypted using the session key), the SPN of the resource, and the encrypted TGT.
3b) Once the domain controller receives the TGS_REQ, the TGT is decrypted using the secret key known only to the domain controller. The session key is then extracted from the decrypted TGT, and this key is used to decrypt the username and timestamp of the request. If the TGT has a valid timestamp, the TGT and session key usernames match, the request is accepted and the authorization is successful.
4) Further, the ticket granting service responds to the computer/client with a Ticket Granting Server Reply (TGS_REP). This contains three parts:
The SPN of the application to which access has been authorized which is encrypted with session key created in step Step 2
A session key to be used between the client and the application which is encrypted with session key created in step Step 2
A service ticket containing the username and group memberships along with the newly created session key which is encrypted with the password hash of the service account registered with the target SPN
5) Next, the client sends an Application Request (AP_REQ), which contains the username and a timestamp encrypted with the session key (created in Step 4b) along with the service ticket (4c).
6) The application service decrypts the service ticket using its own password hash, extracts the session key from it, and decrypts the supplied username. If the decryption is successful and the usernames match, the access is granted. The service also validates the group memberships in the service ticket and assigns appropriate permissions to the user.
With this authentication flow in our mind, let's dive into common Kerberos attacks.
AS-REP roasting
With respect to the Kerberos authentication mentioned above, the very first step is pre-authentication which uses the user's password to encrypt a timestamp.
However, here is a scope for potential misconfiguration in case pre-authentication is disabled.
If the pre-authentication is disabled for a user, an attacker (typically any user in the domain) can request authentication data for that user, and the domain controller will reply with an encrypted ticket-granting ticket (TGT).
If the user’s password is weak, the encrypted TGT can be brute-forced to derive the password.
Let’s look at where and how exactly this “pre-authentication” can be disabled -
Go to Active Directory Administrative Center.
Go to Users.
Select the user and navigate to “Account” settings. Tick the “Do not require Kerberos pre-authentication” option as shown below -
Let’s try to perform AS-REP Roast attack. My absolute favorite tool to perform this attack is Rubeus
We can download Rubeus from here - https://github.com/r3motecontrol/Ghostpack-CompiledBinaries
We can invoke AS-REP Roasting using below command -
.\Rubeus.exe asreproast
This would dump hash for all the users for which pre-authentication setting is disabled as shown above.
I usually prefer dumping the hashes in a hashcat compatile format in a file.
.\Rubeus.exe asreproast /format:hashcat /file:hashes.txt
Once we have the hashes file, we can use hashcat to perform bruteforce attack as shown below.
hashcat -m 18200 -a 0 hashes.txt /usr/share/wordlists/SecLists/Passwords/Common-Credentials/top-passwords-shortlist.txt
In above command,
-m 18200 - tells hashcat that the hash mode is Kerberos AS-REP.
-a 0 - attack mode is dictionary based attack
The attack was successful and we were able to derive password for tom.
Kerberoasting
Jumping onto next common Kerberos attack, let’s talk about Kerberoasting.
In an active directory environment, any authenticated user is allowed to request a ticket-granting service (TGS) ticket for any service having a registered SPN (service principal name) in a domain.
We know that a TGS ticket is encrypted with service account’s password hash.
This means that if we get a TGS ticket, we can bruteforce the ticket to derive service account’s password in cleartext if it is weak in strength.
Let’s talk about SPNs now.
The Service Principal Name (SPN) is basically a unique identifier for a service account in domain and has below format:
serviceclass/host:port
Eg: For a service account associated with a web server, an SPN would look like - HTTP/aurordc.auror.local
Before the Kerberos authentication service can use an SPN to authenticate a service, the SPN must be registered on the account.
Let’s quickly register an SPN with a service account. I created a service account with “web_svc” username.
Go to Active Directory Administrative Center.
Go to Users.
Select the user and navigate to “Account” settings.
Go to Extensions
Select the “Attribute Editor” tab and enter a valid SPN value for this user as shown below -
Now that we have a service account with registered SPN, let’s perform kerberoasting using Rubeus.
.\Rubeus.exe kerberoast /outfile:kerberoast_hashes.txt /format:hashcat
Above command will find all Kerberoastable accounts in the active directory and dump their hashes to kerberoast_hashes.txt file.
Next, let’s use hashcat to crack the hashes.
hashcat -m 13100 -a 0 kerberoast_hashes.txt /usr/share/wordlists/SecLists/Passwords/Common-Credentials/top-passwords-shortlist.txt
In above command,
-m 18200 - tells hashcat that the hash mode is Kerberos TGS-REP.
-a 0 - attack mode is dictionary based attack
The attack was successful and we were successfully able to derive password for web_svc service account.
Golden Ticket Attack
At this point, I want you to recall the Kerberos authentication flow. Remember in Step 2 of “How does Kerberos work?”, I mentioned that the TGT of user is encrypted with a secret key only know to Domain controller?
That secret key is basically the password hash of KRBTGT account.
Essentially, the domain controller trusts any TGT that is encrypted with KRBTGT’s password hash.
Basically, if an attacker succeeds in getting the password hash of KRBTGT account, it’s a game over! An attacker literally owns the entire domain in that case.
There are two common ways in which an attacker can steal the KRBTGT account’s password hash.
If an attacker is somehow able to compromise the domain controller, he can get the NTDS.dit file sitting in C:\Windows\NTDS\ folder. This file contains the password hashes for all the domain accounts including the KRBTGT account.
If an attacker compromises a domain administrator account or a domain computer account which by default have domain replication rights
For demonstration purposes, let’s assume that we compromise a user account capable of running domain replication.
We can perform DCSync attack to abuse these domain replication rights and retrieve password hash of KRBTGT account. This attack works in two phases -
Discovers Domain Controllers in domain.
Requests the Domain Controllers to replicate the user credentials through GetNCChanges (using Directory Replication Service (DRS) Remote Protocol)
Let’s assign the domain replication rights to vagrant user. To do this -
Go to Active Directory Administrative Center.
Go to Domain Properties.
Go to Extensions
Go to Security Tab
Add vagrant user and tick box these three permissions and select OK
Now that vagrant user has domain replication rights, let’s think of an attack scenario where we managed to compromise a domain computer as a vagrant user (through any foothold techniques) and this user has local administrator rights on the computer.
To perform DCSync we launch mimikatz and run below command to retrieve password hash of KRTBGT account -
lsadump::dcsync /domain:auror.local /user:krbtgt
Looks like the attack was successful!
Since we have password hash of KRBTGT account, we can now forge a TGT that belongs to any group.
Our obvious target would be forging a TGT for a user with “Domain Admins” group membership.
kerberos::golden /user:eviladmin /domain:auror.local /sid:S-1-5-21-1605841321-1367402421-3280016589 /krbtgt:417898553dcf5d2a775667da7a0dd3ce /id:500 /pttWe use above command to create a forget TGT for a fake user “Eviladmin”.
In above command,
/sid - is the domain SID
/id:500 - is group membership ID for “Domain Admins”
/krbtgt - is the password hash for KRBTGT account
/ptt - stands for pass the ticket, which injects the ticket in the memory.
Once the ticket is injected into memory, we use misc::cmd to launch command prompt in current session
With the new command prompt launched, we use PsExec.exe to launch command prompt on domain controller -
With this, we got access to domain controller as Domain Administrator.
This completes our Golden Ticket attack.
With this, I conclude this post. I hope you found this helpful ! Thanks for reading. Please feel free to reach out to me for any feedback.