How to Stop the Kerberos Pre-Authentication Attack in Active Directory

Here’s a look at how to safeguard your Active Directory from the known roasting attack on Kerberos Pre-Authentication.

As part of the Kerberos authentication process in Active Directory, there is an initial request to authenticate without a password. This is an artifact left over from Kerberos versions earlier than Kerberos 5. In these earlier versions, Kerberos would allow authentication without a password.

Now, in Kerberos 5, a password is required, which is called “Pre-Authentication.” When looking at the Kerberos exchanges during log-on, you will initially see an AS-REQ (Authentication Server Request) followed by a Kerberos error, which will state that pre-auth is required.

This is where the attack is initiated. But it does require that the user account setting is toggled to negate the need for Kerberos Pre-Authentication. You can see the setting here in Figure 1.

Figure 1. User account configured to not require Kerberos Pre-Authentication.

The attack is referred to as an AS-REP roasting attack. To understand how it works, let’s look at the normal Pre-Authentication process. The encryption key for the AS-REQ process is a timestamp encrypted with the user’s password hash. If the timestamp of the AS-REP (Authentication Server Reply) is determined to be within a few minutes of the KDC’s (Key Distribution Center) time, the KDC will issue the TGT (ticket-granting ticket) via AS-REP. 

However, if Pre-Authentication is not required, the attacker can simply send a fake AS-REQ, to which the KDC will immediately send the TGT because there is no password required. The AS-REP will include the TGT, along with some additional data that is encrypted with the user’s key (aka, the password hash), which can be obtained from the data and cracked offline. 

Ideally, you don’t want user accounts to bypass this Pre-Authentication, so be sure to look for any users that have this set. You have many options, but the main two are:

1) PowerShell

Get-DomainUser -PreauthNotRequired

2) LDAP (Saved Query)

(&(&(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=4194304))))

Of course, Tenable.ad will also flag any user that has this insecure setting, as clearly it opens up an attack pathway into Active Directory, as shown in Figure 2.

Figure 2. Tenable.ad flags user accounts that don’t require Kerberos Pre-Authentication.

Although this is a known attack, which is why Microsoft added the preauthorization control in Kerberos 5, the setting might still be misconfigured for some users in Active Directory.

For more information on this topic and strategies for strengthening your Active Directory security, visit our Tenable.ad product page.

This blog post originally appeared on the Alsid website on July 14, 2020.