Deep Dive into Kerberoasting Attack

In this article, we will discuss kerberoasting attacks and other multiple methods of abusing Kerberos authentication. But before that, you need to understand how Kerberos authentication works between client-server communication.

“Kerberos is for authentication not for authorization, this lacuna allows kerberoasting”

Table of Content

SECTION A: Kerberos Authentication Flow

  • Kerberos & its Major Components
  • Kerberos Workflow using Messages

SECTION B: Service Principle Name SPN

  • Service Principle Name SPN
  • Important Points
  • The SPN syntax has four elements
  • Type of SPN

SECTION C: Kerberoasting Attack Walkthrough

  • What is Kerberoasting
  • Kerberoasting Major Steps
  • PART 1: OLD Kerberoasting Procedure on Host System
    • Powershell Script
    • Mimikatz
  • PART 2: NEW Kerberoasting Procedure on Host System
    • Rubeus.exe
    • ps1 Powershell Script
  • PART 3: OLD Kerberoasting Procedure on Remote System
    • Powershell Empire
    • Metasploit
  • PART 4: NEW Kerberoasting Procedure on Remote System
    • PowerShell Empire
    • Metasploit
    • Impacket
    • Pypykatz

SECTION A: Kerberos Authentication Flow         

Table of Content

  • Kerberos & its major Components
  • Kerberos Workflow using Messages

KERBEROS & its Major Components

The Kerberos protocol defines how clients interact with a network authentication service. Clients obtain tickets from the Kerberos Key Distribution Center (KDC), and they submit these tickets to application servers when connections are established. It uses UDP port 88 by default and depends on the process of symmetric key cryptography.

“Kerberos uses tickets to authenticate a user and completely avoids sending passwords across the network”.

There are some key components in Kerberos authentication that play a crucial role in the entire authentication process.

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.

The image below shows that the major role played by KDC in establishing a secure connection between the server & client and the entire process uses some special components as defined in the table above.

As mentioned above, Kerberos uses symmetric cryptography for encryption and decryption. Let us get into more details and try to understand how encrypted messages are sent to each other. Here we use three colours to distinguish Hashes:

  • BLUE _KEY: User NTLM HASH
  • YELLOW_KEY: Krbtgt NTLM HASH
  • RED_KEY: Service NTLM HASH

Step 1: By sending the request message to KDC, client initializes communication as:

  1. KRB_AS_REQ contains the following:
  • Username of the client to be authenticated.
  • The service SPN (SERVICE PRINCIPAL NAME) linked with Krbtgt account
  • An encrypted timestamp (Locked with User Hash: Blue Key)

The entire message is encrypted using the User NTLM hash (Locked with BLUE KEY) to authenticate the user and prevent replay attacks.

Step 2: The KDC uses a database consisting of Users/Krbtgt/Services hashes to decrypt a message (Unlock with BLUE KEY) that authenticates user identification.

Then KDC will generate TGT (Ticket Granting Ticket) for a client that is encrypted using Krbtgt hash (Locked with Yellow Key) & some Encrypted Message using User Hash.

  1. KRB_AS_REP contains the following:
  • Username
  • Some encrypted data, (Locked with User Hash: Blue Key) that contains:
    • Session key
    • The expiration date of TGT
  • TGT, (Locked with Krbtgt Hash: Yellow Key) which contains:
    • Username
    • Session key
    • The expiration date of TGT
    • PAC with user privileges, signed by KDC

Step 3: The KRB_TGT will be stored in the Kerberos tray (Memory) of the client machine, as the user already has the KRB_TGT, which is used to identify himself for the TGS request. The client sent a copy of the TGT with the encrypted data to KDC.

  1. KRB_TGS_REQ contains:
  • Encrypted data with the session key
    • Username
    • Timestamp
  • TGT
  • SPN of requested service e.g. SQL service

Step 4: The KDC receives the KRB_TGS_REQ message and decrypts the message using Krbtgt hash to verify TGT (Unlock using Yellow key), then KDC returns a TGS as KRB_TGS_REP which is encrypted using requested service hash (Locked with Red Key) & Some Encrypted Message using User Hash.

  1. KRB_TGS_REP contains:
  • Username
  • Encrypted data with the session key:
    • Service session key
  • The expiration date of TGS
  • TGS, (Service Hash: RED Key) which contains:
    • Service session key
    • Username
    • The expiration date of TGS
    • PAC with user privileges, signed by KDC

 

Step 5: The user sent the copy of TGS to the Application Server,

  1. KRB_AP_REQ contains:
  • TGS
  • Encrypted data with the service session key:
    • Username
    • Timestamp, to avoid replay attacks

Step 6: The application attempts to decrypt the message using its NTLM hash and to verify the PAC from KDC to identify user Privilege which is an optional case.

Step 7:  KDC verifies PAC (Optional)

Step 8:  Allow the user to access the service for a specific time.

SECTION B: Service Principle Name SPN

Table of Content

  • Service Principle Name SPN
  • Important Points
  • The SPN syntax has four elements
  • Type of SPN

Service Principle Name 

The Service Principal Name (SPN) is a unique identifier for a service instance. Active Directory Domain Services and Windows provide support for Service Principal Names (SPNs), which are key components of the Kerberos mechanism through which a client authenticates a service.

Important Points

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

The SPN syntax has four elements 

Type of SPN:

  • 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.

Section C: Kerberoasting Attack Walkthrough

Table of Content

  • What is Kerberoasting?
  • Kerberoasting Major Steps
  • PART 1: OLD Kerberoasting Procedure on Host System
    • Powershell Script
    • Mimikatz
  • PART 2: NEW Kerberoasting Procedure on Host System
    • Rubesus.exe
    • ps1 Powershell Script
  • PART 3: OLD Kerberoasting Procedure on Remote System
  • Powershell Empire
  • Metasploit
  • PART 4: NEW Kerberoasting Procedure on Remote System
    • PowerShell Empire
    • Metasploit
    • Impacket

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.

As explained above, the 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.

Kerberoasting Major Steps

This attack is multiple steps process as given below:

Step 0: Access the Client system of the domain network by Hook or Crook.

Step 1: Discover or scan the registered SPN.

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

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

Step 4: Convert the .kirbi or ccache file into a crackable format

Step 5: Use a dictionary for the brute force attack.

We have attack categories such as OLD or NEW kerberoasting on the Host or Remote system.

OLD Procedure: These are techniques where multiple kerberoasting steps are performed.

NEW Procedure: These are single-step techniques used for kerberoasting.

PART 1: OLD  Kerberoasting Procedure on Host System

Method 1: Powershell Script

Step 1: SPN Discover

Download “Find-PotentiallyCrackableAccounts.ps1” & “Export-PotentiallyCrackableAccounts.ps1” from here  on the host machine. These scripts will discover the SPN and save the output in CSV format.

Another powershell script “GetUserSPns .ps1” Download it from here it will Query the domain to discover the SPNs that use User accounts as you can observe that we have found SPN name with the help of followed command.

Import the module in the powershell run the said command here I have enumerated SPN for SQL Service.

Step 2: Extract & Dump TGS_ticket & Obtain Hash

Here, I try to extract the KRB_TGS from inside the host memory with the help of another PowerShell script called “TGSCipher.ps1” which you can download from here and simultaneously convert the request output it into John format.

As a result, we obtain the HASH string for the SQL Service.

Step 3: Brute Force HASH

Now, this is the last and desired phase where we have used a dictionary for brute-forcing the HASH, thus we saved above-enumerated hash in a text file and run the following command.

Boom! Boom!!! And we’ve made a successful kerberoasting attack by obtaining a password for the SQL service.

Method 2: Mimikatz

Similarly, you can use mimikatz for the entire attack which means it can be used for SPN discovery and dumping the TGS ticket.

Step 1: SPN Discovery

Download and execute the mimikatz & run Kerberos::list command for SPN discovery.

Step 2: Dump TGS ticket

Run the export command for extracting the ticket named contains .kirbi extension.

Step 3: Convert the Kirbi to Hash & Brute Force Hash

I renamed the obtain file name as “1-40a5000…..kirbi” into “raj.kirbi” and again convert raj.kirbi into john crackable format with the help of kirbi2john.py (possible at /usr/share/john/) named as “kirbihash”; then use john for brute force as done in 1st Method.

PART 2: NEW Kerberoasting Procedure on Host System

Method 1: Rubeus.exe

Step 1: SPN Discover, Dump TGS, obtain HASH (All-in-one)

Rebeus.exe is a terrific tool as it comes with a kerberoast module that discovers SPN, extracts TGS, and dump service Hash, which can be done with the help of the following command.

Step 2: Brute Force Hash

So, we have saved the service hash in the text file “hash.txt” and use a dictionary to brute force the hash and extract the service password using hashcat tool.

As a result, you can observe that we have extracted the password of the service.

Method 2: Kerberoast PowerShell Script

Step 1: SPN Discover, Dump TGS, obtain HASH (All-in-one)

Kerberoast.ps1 is a PowerShell script which is as similar above module, you can download it from here, it discovers the SPN, extract TGS and dump service Hash, this can be done with the help of the following command.

Once you get the service hash, follow the above method to brute force the password.

Step 2: Brute Force Hash

Again, repeat the same procedure to brute force the hashes.

PART 3: OLD Kerberoasting Procedure on Remote System

Method 1: Metasploit

  1. PowerShell script via meterpreter
    • ps1- SPN Discovery script
    • SetSPN Utility
    • ps1
  2. Mimikatz via Metasploit

1. PowerShell script via meterpreter

Step1:  SPN Discovery

Download “Find-PotentiallyCrackableAccounts.ps1” & “Export-PotentiallyCrackableAccounts.ps1” from here in your local machine and upload it on the host machine through meterpreter session, then invoke PowerShell to execute the script remotely.

These scripts will discover the SPN and save the output in CSV format.

Download the Report.csv in your local machine.

The report.csv file will list the SPNs available in the host system.

Setspn – SPN Discovery Utility

Another method, obtain the meterpreter session by compromising the host machine and load PowerShell. Use setspn utility to list all SPNs in the domain.

As you can observe that again we have discovered the SPN for SQL service

Step 2: Extract & Dump TGS_ticket & Obtain Hash

Upload the PowerShell script “TGSCipher.ps1” and simultaneously convert the request output it into John format.

As a result, we obtain the HASH string for the SQL Service.

Step 3: Brute Force Hash

Again, repeat the same procedure to brute force the hashes.

2. Mimikatz via Metasploit

Once you have the meterpreter session of the host system then you can try to upload mimikatz.exe and then perform all steps discussed in Part 1 of section C.

Step 1: SPN Discovery

Download and execute the mimikatz & run Kerberos::list command for SPN discovery

Step 2: Dump TGS ticket

Run the export command for extracting the ticket named with .kirbi extension.

Download the kirbi file in your local machine to convert it into the crackable format.

Step 3: Convert the Kirbi to Hash & Brute Force Hash

Again, I renamed the obtain file name as “2-40a5000…..kirbi” into “raj.kirbi” and again convert local.kirbi into john crackable format with the help of kirbi2john.py (possible at /usr/share/john/) named as “localhash”; then use john for brute force as done above.

Method 2: PowerShell Empire

Step 1: SPN Discovery use setspn follow above method (Optional in this module)

Step 2: Extract & Dump TGS_ticket & Obtain Hash

Once you have empire agent, execute the below module which will extract and dumb .kirbi  format file for TGS ticket.

Step 3: Convert kirbi to hash & then Brute force

You can also tgscrack.py which a dedicated python script that converts kirbi format into the crackable format and then brute force the hashes to extract the password. Download it from here then run the following commands

PART 4: NEW Kerberoasting Procedure on Remote System

Method 1: PowerShell Empire

Step 1: SPN Discover, Dump TGS, obtain HASH (All-in-one)

Once you have Empire/agent then load invoke_kerberoast module, it is a cool module as it discovered the SPN, extracts the ticket, and dump the service hash from inside the TGS cipher.

As you can observe that it has dumped the service hash within a second of time.

Step 2: Brute Force Hash

Again, repeat the same procedure to brute force the hashes.

Method 2:  Metasploit

Step 1: SPN Discover, Dump TGS, obtain HASH (All-in-one)

If you are Metasploit interface lover then after obtaining a meterpreter session you can load the PowerShell and upload kerberoast.ps1 script, download it from here, it discovered the SPN, extract the TGS ticket then dump the service hash from inside the TGS cipher.

Step 2: Brute Force Hash

Again, repeat the same procedure to brute force the hashes.

Method 3: Impacket

Step 1: SPN Discover, Dump TGS, obtain HASH (All-in-one)

Use Impacket inbuilt module “GetUSerSPNs.py”, it is a python script that it discovers SPN, extract TGS and dump service Hash, this can be done with the help of the following command:

It will dump the service hash and with the help of the dictionary, you can brute force it for extracting service passwords.

Step 2: Brute Force Hash

Again, repeat the same procedure to brute force the hashes.

Pypykatz

In order to conduct kerberoasting attack, we need to import DMP file in our local machine (Kali Linux) through Client machine and to do this execute the following command through meterpreter session.

Why we need Lsass.Dmp file?

Because of LSASS.DMP stores the TGT & TGS ticket in the kirbi format for some period of time and using this DMP file we can obtain the following:

  • NTLM HASH of User
  • KRB5_TGT ticket
  • KRB5_TGS ticket
  • NTLM HASH for Service

Once you have dumped the lsass.dmp, download it on your local machine for extracting kirbi files.

Download and install pypykatz for extracting stored Kerberos tickets in Kirbi format from inside the lsass.DMP file by executing the following commands

As you can observe we have obtained all Kerberos ticket in kirbi format as well as the NTLM HASH for user Yashika.

As we said with the help of stored KRB5_TGS, we can extract the NTLM hashes for Service Server.

Now as you can see in the highlight image we’ve outlined the KRB5_TGS for SQL Server in kirbi format and converted it to john crackable format with the help of kirbi2john.py (possible at /usr/ share/john/) called “TGS hash;” then use john for brute force password.

Booom!!!! We found the password for SQL service server.

Reference: Microsoft Service Principal Names

https://www.tarlogic.com/en/blog/how-kerberos-works/

6 Comments Deep Dive into Kerberoasting Attack

  1. Elliot Alderson

    Thanks for this article but I am on doubt about the process of handshake in between client and AD. Its mentioned that entire message is encrypted with NTLM HASH, but in reality, Hashing does not work to encrypt anything. HASH always use for message integrity purpose and not for confidentiality, This need correction.

    Reply
    1. Raj Chandel

      Hello Alderson,
      Kerberos does not use NTLM hash for encryption, it uses NTLM hashes as key for encryption or decryption of the message. Please refer to the table mention in the article.

      Reply
  2. Elliot Alderson

    Hi Raj,

    Thanks for checking and approving my post. My comment is not to prove something right or wrong.

    Its to share the right information within our community. I did not read much but below is confusing stating encryption and decryption using HASH.

    “The entire message is encrypted using the User NTLM hash (Locked with BLUE KEY) to authenticate the user and prevent replay attacks.

    Step 2: The KDC uses a database consisting of Users/Krbtgt/Services hashes to decrypt a message (Unlock with BLUE KEY) that authenticates user identification.

    Then KDC will generate TGT (Ticket Granting Ticket) for a client that is encrypted using Krbtgt hash (Locked with Yellow Key) & some Encrypted Message using User Hash.”

    Reply
    1. pavandeep singh

      Hi Elliot,
      Thank you for valuable suggestion regarding the usability of hashes. It is our mission as well to spread the knowledge in the community and we are happy to see some suggestions. Thanks once again!

      Reply
    1. pavandeep singh

      Not Every Encryption is crackable. The crackablity of a hash depends on lots of different scenarios which include weak security policies implemented on the Domain Controller.

      Reply

Leave a Reply

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