Kerberoasting

What is

Kerberoasting is an attack against Active Directory that targets accounts associated with Service Principal Names (SPNs).

An SPN identifies a service instance running under a particular account. When a service is configured to use a domain account, an SPN may be registered for that account in Active Directory.

Kerberos allows an authenticated domain user to request a Ticket Granting Service (TGS) ticket for a service identified by an SPN. The service ticket is encrypted using a key derived from the password of the account associated with that SPN.

Kerberoasting takes advantage of this behaviour by requesting service tickets for accounts with SPNs and extracting the relevant ticket material. The resulting data can then be attacked offline, for example with tools such as Hashcat.

The attack is particularly interesting when service accounts use weak or otherwise crackable passwords.

Requirements

For a typical Kerberoasting attack, the following conditions should be met:

• A valid Active Directory account.
• An account with an SPN configured in Active Directory.
• Network connectivity to the Domain Controller.
• The attacker must be able to authenticate to the domain and request Kerberos service tickets.

Unlike some other Active Directory attacks, the authenticated user does not necessarily need administrative privileges to request a service ticket for an SPN.

How to

Summary

The basic workflow is:

impacket-GetUserSPNs <DOMAIN>/<USER>:<PASSWORD> -dc-ip <DC_IP>

impacket-GetUserSPNs <DOMAIN>/<USER>:<PASSWORD> -dc-ip <DC_IP> -request

Detailed

1. Enumerate SPNs

The first step is to identify domain accounts that have SPNs associated with them.

For this purpose, we can use GetUserSPNs from the Impacket suite.

The tool can be invoked with:

impacket-GetUserSPNs

We can then authenticate to the domain and query the Domain Controller:

impacket-GetUserSPNs <DOMAIN>/<USER>:<PASSWORD> -dc-ip <DC_IP>

An example output might look like:

ServicePrincipalName                  Name        MemberOf
------------------------------------  ----------  ----------------------------
MSSQLSvc/sql01.marvel.local:1433      sqlservice  CN=Domain Admins,CN=Users,...
HTTP/web.marvel.local                 webservice  CN=Users,...

The important information is the ServicePrincipalName and the associated account.

At this point, we have identified accounts that may be suitable targets for Kerberoasting.

2. Request TGS tickets

We can request service tickets for the discovered SPNs by adding the -request parameter:

impacket-GetUserSPNs <DOMAIN>/<USER>:<PASSWORD> -dc-ip <DC_IP> -request

The tool will query Active Directory for accounts with SPNs and request the corresponding service tickets.

A successful request may produce output similar to:

$krb5tgs$23$*sqlservice$MARVEL.LOCAL$MSSQLSvc/sql01.marvel.local:1433*$...

The returned value is not the plaintext password.

It is Kerberos service-ticket material that can be used for an offline password attack.

3. Crack the ticket

The captured ticket can be saved to a file and processed using a password-cracking tool such as Hashcat.

For example:

hashcat -m 13100 hashes.txt <wordlist>

Hashcat mode 13100 corresponds to Kerberos 5 TGS-REP etype 23, commonly encountered when Kerberoasting accounts using RC4-HMAC.

The exact hash type depends on the encryption type used by the service account.

The important characteristic of this step is that the attack is performed offline.

The attacker does not need to continue communicating with the Domain Controller while testing password guesses.

Understanding the attack

Kerberoasting is easier to understand by following the normal Kerberos authentication flow.

1. Obtaining a TGT

After a user authenticates to the domain, the client obtains a Ticket Granting Ticket (TGT) from the Key Distribution Center (KDC).

The KDC is normally provided by the Domain Controller.

The TGT allows the user to request service tickets without repeatedly sending their password to individual services.

The simplified flow is:

User
 |
 | Authentication
 v
KDC / Domain Controller
 |
 | TGT
 v
User

2. Requesting a TGS

When the user wants to access a service, the client requests a Ticket Granting Service (TGS) ticket for the SPN associated with that service.

For example:

MSSQLSvc/sql01.marvel.local:1433

The client sends a request to the KDC containing the SPN it wants to access.

The KDC looks up the account associated with that SPN and generates a service ticket.

User
 |
 | TGS request for SPN
 v
KDC / Domain Controller
 |
 | TGS
 v
User

3. The important part for Kerberoasting

The service ticket contains information encrypted using a key derived from the password of the account associated with the SPN.

Conceptually:

                    SPN
                     |
                     v
              Service Account
                     |
                     | password-derived key
                     v
User ------------> KDC
 |                  |
 | TGS request      |
 |----------------->|
 |                  |
 |<-----------------|
       TGS

A user who is allowed to request the service ticket can therefore obtain ticket material associated with another account without knowing that account’s password.

Kerberoasting takes this legitimate Kerberos functionality and turns it into an offline password-cracking opportunity.

4. Offline password attack

The attacker can take the obtained TGS material and test password candidates locally.

TGS
 |
 v
Extract ticket material
 |
 v
Offline password guessing
 |
 +---- Wrong password ---> Try next candidate
 |
 +---- Correct password -> Service account credentials

The effectiveness of this attack therefore depends heavily on the password protecting the service account.

Common problems

No SPNs are found

If GetUserSPNs does not return any accounts, verify that:

• The supplied domain credentials are valid.

• The correct Domain Controller IP is being used.

• The account can communicate with the Domain Controller.

• The domain actually contains accounts with registered SPNs.

Not every domain account has an SPN, so an empty result does not necessarily indicate a problem with the tool.

SPNs are found but no ticket is returned

If SPNs are discovered but a TGS cannot be requested, verify:

• Kerberos connectivity to the Domain Controller.

• DNS resolution of the Active Directory domain.

• The supplied credentials.

• That the SPN is valid and associated with an active account.

The returned ticket cannot be cracked

A successfully obtained ticket does not guarantee that the password can be recovered.

The account may use a strong password that is not