Detecting Kerberoasting

Kerberoasting is an effective method for privilege escalation, pivoting, and even persistence. Let’s take a look at ways to detect (and prevent) this attack.

Jump to the portion of this post you are looking for:

• Background
• Authentication Process
• Attack
• Detection

Background

In Greek mythology, Kerberos (Cerberus) was the three headed dog that guarded the gates of Hades to prevent the dead from leaving. In the Microsoft authentication world, those three heads are representative of:

• Domain Controller (DC) – This physical system runs a number of logical roles used for authentication. For Kerberos, the critical piece is the Key Distribution Server (KDC) role. Per Microsoft, “The Kerberos Key Distribution Center (KDC) is integrated with other Windows Server security services that run on the domain controller. The KDC uses the domain’s Active Directory Domain Services database as its security account database. Active Directory Domain Services is required for default Kerberos implementations within the domain or forest.” Note: Since the KDC is a logical role on a DC and cannot be separated, the terms are essentially interchangeable.
• Client – The client attempting to access a service in the domain
• Member Server – The server the client is attempting to access

Authentication Process

Before we can talk detection, we need to understand a little bit about how Kerberos works and how the Kerberoast attack works. The authentication process is split into 3 parts (with an optional 4th).

• Authentication Service (AS) – Authenticate the user and receive a Ticket Granting Ticket (TGT)
• Ticket Granting Service (TGS) – Use the TGT to request a Ticket Granting Service (TGS) ticket for the member server
• Authentication Protocol (AP) – Present the TGS to request access to the target server
• (Optional) PAC Validation – Target server asks the KDC to verify the PAC, which contains information about the user attempting to authenticate

Let’s briefly walk through each of these steps

Authentication Service (AS) – Client Authenticates to Domain

The client needs to perform an initial authentication so it can obtain a Ticket Granting Ticket (TGT). The client presents the following information in the AS REQ (Authentication Service Request) to the [K]DC.

• Client name in clear text
• Timestamp in clear text
• Encrypted timestamp using the client’s NT password hash as the key

The KDC then looks up the user’s NT password hash in its database and attempts to decrypt the encrypted blob using the hash as akey. If successful, the user has successfully authenticated and the KDC will send a Ticket Granting Ticket (TGT) to the client in an AS REP (Authentication Service Response).

At this point, the client has authenticated to the domain and has a TGT, but has not accessed or authenticated to any other services.

Ticket Granting Service (TGS) – Client uses TGT to request a Service Ticket (ST)

The client makes a Ticket Granting Service Request (TGS REQ) to the KDC and presents its TGT and requests a ticket for a specific service. The KDC then uses the TGT to build the Service Ticket (ST). The ST is then sent to the client in a Ticket Granting Service Response (TGS REP).

The client now has a service ticket. The service ticket has two parts, one for the client and another for target services. Let’s take a look at the two pieces.

• Client – The client portion is encrypted using a key in the TGT (randomly generated by the KDC). It contains the validity period, the name of the service, and an encryption key to be used with the service
• Service – This portion is encrypted using the password hash of the target service. The use of the hash to encrypt the ticket is key to Kerberoasting as any client can request a ticket which contains password hash material. This contains the validity period and information on the user in the Privilege Attribute Certificate (PAC). The PAC contains information on the user, including the name, ID, and group memberships.

Authentication Protocol – Client presents ST to server to request access

The client then includes the ST in its authentication request to the server in an Authentication Protocol Request (AP REQ). The server decrypts the ticket using its password hash and then uses the PAC to determine if the client has access, and to what level the client has access. The response is an Authentication Protocol Response (AP REP).

Note: The target server decides on access, NOT the KDC/DC. If the KDC/DC were to make the decision, then it would have to know all of the permission settings on every object in the domain, and it is infeasible and inefficient for the DC to make this decision.

Requesting a Service Ticket

The client requests a ticket and KDC uses the presented TGT to build the ticket. Remember, the KDC does not decide if the client should have the ticket since the target service decides if the client has access and to what level.

The client requests the ticket and tells the KDC the name of the service for which it is requesting a ticket. The Service Principle Name (SPN) is a unique identifier for a particular service. A typical SPN is formated as SERVICE_CLASS/HOST, such as MSSQLSvc/sql01.medin.local (the name can have a port and/or instance name, but that is less common).

When a client makes a request for MSSQLSvc/sql01.medin.local, the DC will lookup the account mapped to the name. The account can be of one of two types:

• Machine account – tied to the machine on which the service is run
• User account – tied to a manually created account (this will be the target of our Kerberoast attack)

The Kerberoast Attack

The crux of the Kerberoast attack is due to the way the Service Ticket is created. As mentioned above, the ticket is encrypted using the password hash of the target service. Also as stated above, the KDC does not decide if the client should have the ticket since the target service decides if the client has access and to what level. This means that any user can request a ticket for any service.

The attacker can request a ticket for any SPN in the organization. Since the ticket is encrypted using the password hash of the target service, the attacker can then extract that ticket, and perform offline cracking. The attacker will guess a password, hash, and attempt to decrypt the ticket. If successful, the attacker has not determined the password for the service. If unsuccessful, the attacker can guess again.

The key piece of the vulnerability is the service account having a crackable password. The is the fault of an administrator selecting an insecure password for the account. As mentioned above, there are two types of accounts that could be tied to an SPN, a user account or a machine account. A machine account password is randomly generated, and for all intents and purposes, is uncrackable. A user account password is only as secure as the administrator who created the password. It could be very secure, it could be very weak, or somewhere in-between. It all depends on how determined the attacker is since this is an offline attack (and service account passwords are often not rotated).

Defense

The simple answer: use strong passwords for service accounts.

Another option is to use Group Managed Service Accounts. It offers “automatic password management”, meaning random password and rotation.

Detection

There are multiple ways we can detect Kerberoasting.

Honey SPN

Here we create an account and SPN (using setpspn) for an account that isn’t actually used in the organization. No legitimate client should ever request a ticket for this service. This account should look a lot like a good SPN account in the organization. Ideally, copy an exiting account and then change the group memberships.

You’ll want the group memberships to look intriguing to an attacker. There are two schools of thought here:

• Use the privileged groups – leave this account in (or add it to) privileged groups. If you do this, make sure the password is very, very secure. Since no-one will be using the account, randomly generate a long (30 chars) password.
• Create a deceptive group – The groups need to look interesting, but don’t need access to any thing sensitive. Just make sure it looks interesting.

Regardless of the method you use, this account needs to look real. You may even want to make have this account login so the LastLogonTimeStamp isn’t old.

Configure Windows Event Log to Detect Kerberoasting

Use Group Policy to enable logging to Kerberos TGS requests. Under “Account Logon” enable “Audit Kerberos Service Ticket Operations”. The key is Event ID 4769. This event will be trigger a lot, likely dozens of times per day for each user. There are a few key items to look for.

RC4 Encryption

Attackers prefer RC4 encryption for tickets since cracking is significantly faster. The event will contain the following details. Ideally, your environment is AES for most tickets, so RC4 tickets should be rare (but not non-existent). Set a filter in your SIEM to look for this in the log:

• Ticket Options: 0x40810000
• Ticket Encryption: 0x17

  Note, just because RC4 is detected, it doesn’t 100% mean that a Kerberoast attack is underway. There are times with Windows will still use RC4. That said, this is a decent indicator. Look at the blog post from Sean Metcalf for a detailed configuration. Even better, set a threshold for tickets.

Baselining and Setting a Ticket Request Threshold

When a user first logs in they will likely request a number of SPNs in short succession. Look at your logs and identify how many are requested by your users and how quickly. Then, add a margin and set you SIEM to alert if a user requests too many TGS tickets in a short period of time.

For example, if your top requester asks for 10 TGS tickets when they login, set a threshold of 13 tickets. If more than 13 tickets are requests in a short period of time, then trigger an alert.

Also, it is likely, that “good” clients are requesting AES tickets, so you can likely set a lower threshold for RC4 tickets (maybe as low as two).

Detecting SPN Query

I’ve seen EDR tools running on the DC detect the query for SPN accounts. I don’t know of an out of the box tool to do this, or a native way to extract this day. That said, it is a great approach that moves the detection even earlier in the attack chain.

Wrap-Up

If you want a in-depth discussion of Kerberoas and a look into other attacks, check out the video here: redsiege.com/kerb101

Additional Reading:

• Our friends at TrustedSec have a great write-up on configuring this type of logging with Elk
• Sean Metcalf has another blog on the subject
• Our friends across the pond have a good write-up too