8 Powerful Kerberos attacks (that analysts hate)

Roasting attacks 

There are two main forms of roasting attacks: AS-REQ Roasting & Kerberoasting.

1. AS-REQ Roasting

AS-REQ Roasting is possible when Kerberos pre-authentication is not configured. This allows anyone to request authentication data for a user. In return, the KDC would provide an AS-REP message. 

Since part of that message is encrypted using the user’s password, it is possible to perform an offline brute-force attack to try and retrieve the user's password.

The only information an attacker requires is the username they want to attack, which can also be found using other enumeration techniques.

If an account has pre-authentication disabled, an attacker can obtain an encrypted Ticket Granting Ticket (TGT) for the affected account without any prior authentication. These tickets are vulnerable to offline password attacks using a tool like Hashcat or John the Ripper.

So, in a nutshell, it's possible to obtain the TGT for any account that has the "Do not require Kerberos preauthentication" setting enabled.

2. Kerberoasting

Kerberoasting is an attack against service accounts that allows an attacker to perform an offline password-cracking attack against the Active Directory account associated with the service. 

It is similar to AS-REQ Roasting but does require prior authentication to the domain. In other words, we need a valid domain user account and password (even the lowest privileged) or a SYSTEM (or low privileged domain account) shell on a domain-joined machine to perform the attack.

Delegation attacks

Kerberos Delegation allows a service to impersonate a user to access another resource. Authentication is delegated, and the final resource responds to the service as if it had the first user's rights. 

There are different types of delegation, each with weaknesses that may allow an attacker to impersonate users to leverage other services.

3. Unconstrained delegation

Unconstrained delegation allows a service to impersonate a user when accessing any other service. This is a very dangerous privilege, therefore, not any user can grant it.

For an account to have an unconstrained delegation, on the “Delegation” tab of the account, the “trust this computer for delegation to any service (Kerberos only)” option must be selected.

Only an administrator or a privileged user to whom these privileges have been explicitly given can set this option to other accounts. More specifically, it is necessary to have the SeEnableDelegationPrivilege privilege to perform this action. A service account cannot modify itself to add this option.

👉 Unlock the secrets to fortifying Active Directory with our practical Active Directory hardening checklist. 

4. Constrained delegation

Constrained delegation is a “more restrictive” version of unconstrained delegation. In this case, a service has the right to impersonate a user to a well-defined list of services.

A constrained delegation can be configured in the same place as an unconstrained delegation in the Delegation tab of the service account. The “trust this computer for delegation to specified services only” option should be chosen.

As with unconstrained delegation, this option is not modifiable by default by a service account. When this option is enabled, the list of services allowed for delegation is stored in the msDS-AllowedToDelegateTo attribute of the service account in charge of the delegation.

5. Resource-based constrained delegation

 

Resource-based constrained delegation reverses the responsibilities and shifts delegation management to the final resource. It is no longer at the service level that we list the resources to which we can delegate, but at the resource level, a trust list is established. 

Any account on this trusted list has the right to delegate authentication to access the resource.

Unlike the other two types of delegation, the resource has the right to modify its own trusted list. Therefore, any service account has the right to modify its trusted list to allow one or more accounts to delegate authentication to themselves.

Ticket abuse

The goal of ticket abuse attacks is to steal Ticket Granting Tickets or Ticket Granting Services (TGS’) from a particular user.

There are three main ticket attacks: Golden Ticket, Silver Ticket, and Pass-the-Ticket.

6. Golden Ticket

The Golden Ticket attack enables attackers to forge and sign TGTs using the krbtgt account's password hash. When these tickets get presented to an AD server, the information within them will not be checked at all and will be considered valid due to being signed with krbtgt account's password hash.

By forging a Golden Ticket, you can impersonate a sensitive user, who has privileged access, making it a highly dangerous vulnerability. 

7. Silver Ticket

A Silver Ticket is less powerful than the Golden one as it can only access the single machine it’s performed on. This attack focuses on gaining TGS rather than TGT. 

One issue with the Golden Ticket attack is that when creating a TGT, the attacker needs to approach the Domain Controller to have it generate a TGS ticket before they can access any machines. This creates a unique audit record that can be identified as abnormal. 

When forging a TGS ticket, the attacker can bypass the Domain Controller and go straight to the target, minimizing the number of logs left behind.

8. Pass-the-Ticket

A Pass-the-Ticket attack focuses on lateral movement, stealing the TGT or TGS.