Kerberos Attacks

Kerberos is the predominantly used authentication protocol in Microsoft Active Directory and has largely replaced the New Technology LAN Manager (NTLM) in everyday use there. Kerberos has the big advantage that it is much more secure than NTLM. Nevertheless, even when using Kerberos, you should keep a few things in mind to create a secure AD environment.

In this article, we therefore present some key Kerberos attacks. A prerequisite for a good understanding of these vulnerabilities is a basic understanding of the protocol, which we have already covered in this article. The most important things in a nutshell: Kerberos uses so-called tickets for authentication, through which domain users can perform authentications against the Key Distribution Center (KDC) and the Authentication Service (AS). The Kerberos service (KDC & AS) is usually found on the domain controllers of a domain.

Table of contents

Kerberos Attack 1: Kerberos User Enumeration

Since Kerberos is an authentication protocol, it is possible to perform brute force attacks against it. A brute-force attack on Kerberos has a distinct advantage over attacks on other authentication methods: No domain account is required to perform the attack, only a connection to the KDC.


An attacker can determine whether a user exists or not by looking at the KDC's response when sending an authentication request (AS-REQ). This allows attackers to effectively bruteforce usernames by using word lists. It is advantageous to the attacker here that Kerberos pre-authentication failures in Active Directory are not logged with a normal logon failure event (4625), but with the specific event ID 4771 (Kerberos pre-authentication failed). This fact reduces the likelihood that an attack will be noticed.

Using Kerberos User Enumeration, it is also possible to discover user accounts without pre-authentication. This can be useful for an AS-REP roasting attack, which we will discuss in the second section of this article.

However, performing a brute force attack may result in user accounts being locked out. Therefore, attackers must be careful with this Kerberos attack.

ProSec Kerberos Attacks
Kerberos User Enumeration via Kerbrute

The enumeration of usernames is exploited by attackers via the following Kerberos error codes:

User statusKerberos Error
Available/ActivatedKDC_ERR_PREAUTH_REQUIRED - Additional pre-authentication required
Locked/DisabledKDC_ERR_CLIENT_REVOKED - Client credentials have been revoked
Does not existKDC_ERR_C_PRINCIPAL_UNKNOWN - Client not found in Kerberos database


Kerberos user enumeration can be difficult to troubleshoot because it depends on good Kerberos monitoring. This monitoring must be able to detect unrealistic sets of AS-REQ requests without follow-up requests.

To log these events in the event log at all, you must first adjust the default setting for monitoring account logins . To do this, adjust the group policies under the path

Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies\Account Logon

an: Set the guidelines

  • Monitor credentials verification
  • Monitor Kerberos authentication service
  • Monitor ticket operations of the Kerberos service

 to the value "success and error", so that also failed logins are logged. After that you can search the event log for the EventID 4768 and the string "0x6" contained in it.

Why is it not enough to search for EventID4768?

Event 4768 is created when a TGT is requested or issued - i.e. also for legitimate requests. Therefore, monitoring this event alone is not sufficient. The string "0x6" stands for the error code: "KDC_ERR_C_PRINCIPAL_UNKNOWN". Only if you find this error code and these events accumulate conspicuously in a short period of time, you can assume a Kerberos enumeration.

What other attacks can you see in the event log from these settings?

Kerberos attacks that abuse the Kerberos service for password spraying can also be detected via the event log. In this case, too, you have to configure event logging via the group policies described above so that the corresponding events are logged. Then you can monitor the event log for the occurrence of EventID 4771 ("Kerberos pre-authentication error"). Again, you should react if an unusually large number of these events are registered in a short period of time.

To monitor the event log, you should rely on additional tools and ideally a SIEM to permanently monitor the Active Directory and immediately respond to attacks.

Are you keeping track of activity in your network?
Test your IT's response to hacking attacks with a penetration test now!
To the penetration test

Kerberos Attack 2: AS-REP Roasting

AS-REP roasting is a Kerberos attack in which attackers steal encrypted parts of an AS_REP message from user accounts in order to crack them offline. This requires that Kerberos pre-authentication is disabled on the account in question. If this is the case, anyone can send an AS_REQ request to the KDC on behalf of that user and receive an AS_REP message. This AS_REP contains information that is encrypted with the user's NTLM hash. This encrypted part of the AS_REP can then be exploited to crack the password.
By default, pre-authentication is enabled in Active Directory. However, it can be disabled for a user account with the following setting:
ProSec Kerberos Attacks
Windows account options that disable Kerberos pre-authentication
Attention: Figure is for explanation only - disabling it is a security risk!


When pre-authentication is enabled, a user who needs access to a resource begins the Kerberos authentication process as follows: He sends an authentication server request (AS-REQ) message to the domain controller (DC). The timestamp in this message is encrypted with the hash of the user password. If the DC can match this timestamp with its own record of the user's password hash, it sends back an Authentication Server Response (AS-REP) message. This AS-REP message contains the TGT that will be used for future access requests from this user. In addition, the AS-REP message also contains information that is hashed with the user's password.

However, if pre-authentication is disabled, an attacker can request authentication credentials for any user and receive an AS-REP message from the DC in response. This message contains the hashed information encrypted with the user's password. The attacker can then attempt to crack the user's password offline by trying to crack the krb5asrep with appropriate inputs. If the attacker succeeds in decrypting the AS_REP into meaningful plaintext, the key used corresponds to the user's password.
Advantageous for attackers: This Kerberos attack does not require a domain account, but only a connection to the KDC. However, if the attackers have a domain user, they can find users in the domain without Kerberos pre-authentication using LDAP queries. Otherwise, the usernames must be guessed. However, combining this with Kerberos attacks such as Kerberos User Enumeration greatly simplifies this.
ProSec Kerberos Attacks
AS-REP Roasting attack via Crackmapexec


How can you protect your network from this Kerberos attack?
First, make sure that all accounts in your domain have Kerberos pre-authentication enabled. (This is already the default setting since Kerberos v5.) To check which users within a domain still have this setting incorrect, you can run the appropriate LDAP query.
Additionally, enforcing effective password policies for Active Directory is essential to ensure that your environment is not vulnerable to AS-REP roasting. If a strong password is used on a vulnerable account, it is virtually impossible to "crack" the encryption by guessing the password. A secure, enforceable, and therefore effective password policy also helps ensure that users use secure passwords in other places. These are then also not easily guessed or otherwise vulnerable to brute force or other common password attacks.

Kerberos Attack 3: Kerberosting

The goal of Kerberoasting is to obtain TGS tickets for services running on behalf of user accounts in AD, not computer accounts. Why is this useful? Some of these TGS tickets are encrypted with keys derived from user passwords. This means that attackers could decrypt the credentials in question offline using brute force attacks.

Kerberoasting requires only a domain account that can request Service Principle Names (SPNs) - which anyone can do, since no special privileges are required.


In a Kerberoasting attack, an attacker requests the TGS tickets (one or all) that contain a user's encrypted password. A TGS request can be made by specifying any SPN.

What are SPNs?

SPNs are used by Kerberos authentication to associate a service instance with a user account. This allows a client application to ask the service to authenticate an account, even if the client does not know the account name.

When a TSG request is made specifying an SPN and this SPN is registered in Active Directory, the domain controller provides a ticket. This ticket is encrypted with the secret key of the account running the service. With this information, an attacker can now try to crack the ticket offline with brute force attacks and thus obtain the user's plaintext password.

ProSec Kerberos Attacks
Kerberoasting attack via Impacket-GetUserSPNs


To protect against this type of Kerberos attack, SPNs on user accounts must be avoided in favor of machine accounts. If necessary, Microsoft'sGroup Managed Service Accounts (gMSA)feature should be used. This ensures that the account password is robust and changed regularly and automatically.

There are some prerequisites necessary to use gMSA:

  • Domain Functional Level 2012 or higher
  • Windows Server 2012 R2 Os or higher
  • Installation of the Active Directory PowerShell module on a DC and the corresponding servers on which the gMSAs are to be used.
  • SQL Server 2014 or higher (if the gMSAs are to be used for SQL Server)
The following instructions will guide you through all the necessary steps:

Step 1 - Install Active Directory PowerShell Module DC

If not already installed, you need to install the AD PowerShell module on the DC. To do this, use the following command in PowerShell:

Install-WindowsFeature -Name RSAT-AD-POWERSHELL

Step 2 - Check if root key for Key Distribution Service is available and create if necessary.

The creation of gMSAs requires the root key. If this is not available, the creation will abort with an error message.Use the following command in Powershell to check if a root key has already been created:

Test-KdsRootKey -KeyId (Get-KdsRootKey).KeyId

If the root key is not present, you will get an error. If the root key is present, the message True is displayed:

ProSec Kerberos Attacks
Check KDS Root Key - Error message if root key does not exist
ProSec Kerberos Attacks
Check KDS Root Key - message "True" if root key is present

If there is no root key yet, you need to create it on the DC using the following command in PowerShell.

ATTENTION! The generation or replication of the key can take up to 10 hours.

So if there was no key yet, a gMSA can only be created after about 10h.

Add-KdsRootKey -EffectiveImmediately

Step 3 - Create new Security Group

To manage and assign the computer accounts of servers that should use the gMSA, you need a new Security Group. You can create this via the PowerShell:

New-ADGroup -Name GROUPNAME -Description "THIS IS A DESCRIPTION OF THE GROUP, Ex: Security group for gMSA01 computers" -GroupCategory Security -GroupScope Global

You should give the group a descriptive name and indicate in the description that it is a group for the use of a specific gMSA.


Here you add the computers on which the gMSA is to be used to the previously created group (using the corresponding group name). Computer accounts always end with a $ sign.

Get-ADGroupMember -Identity GROUP NAME

Here you can check if the computer accounts were added successfully.

CAUTION: In order to install the gMSA on the affected servers in the next steps, they must be restarted after being added to the Security Group!

ProSec Kerberos Attacks
Creation of a new Security Group

Step 4 - Creation of the gMSA

Create the gMSA with the following command in PowerShell:

New-ADServiceAccount -Name NAME -PrincipalsAllowedToRetrieveManagedPassword GROUPNAME -Enabled:$true -DNSHostName NAME.DOMAIN -SamAccountName NAME -ManagedPasswordIntervalInDays 30

The NAME value determines the name of the account and should be consistent within the command. For GROUP NAME, you specify the name of the security group that you created earlier. The ManagedPasswordIntervalInDays value specifies the password change interval. The AD changes the password automatically.

ProSec Kerberos Attacks
Creation of a Group Managed Service Account (1)
ProSec Kerberos Attacks
Creation of a Group Managed Service Account (2)

Step 5 - Install gMSA on server

To install the gMSA on a server, the Active Directory PowerShell module must also be installed here (see step 1)

Install-WindowsFeature -Name RSAT-AD-POWERSHELL

After that you can install the account. However, the installation cannot work until you restart the server after assigning it to the security group created above.

Install-ADServiceAccount -Identity NAME
Test-ADServiceAccount -Identity NAME
ProSec Kerberos Attacks
Installation of the Group Managed Service account on the server

Step 6 - Using gMSA on Server

After the installation you can use the gMSA as a new service account for the SQL Server. In the example shown here we change the account via the SQL Server Configuration Manager. To do this, select "SQL Server" (SQLSERVERNAME) under SQL Server Services and then right-click on "Properties".

Under the "Login" tab, select "This account". Here you can enter the gMSA or find it via "Browse". If you want to search for the account, you must first select the entire domain under "Paths..." and then select "Service accounts" under "Object types". When you have selected the desired account, you can confirm with "OK". A password is not specified!

ATTENTION! The SQL server will restart after the change.

ProSec Kerberos Attacks
Example Use of a Group Managed Service Account (1)
ProSec Kerberos Attacks
Example Use of a Group Managed Service Account (2)

If you have followed these steps, the corresponding SQL server is no longer linked to a user account SPN. The account is therefore no longer vulnerable unless it is additionally linked to other instances.

Alternative solution

If no gMSA can be used, a normal domain user can be used. This will then be reported as kerberoastable during validation! So the request of the TGS will still be possible. To prevent that this can be exploited, this account must be provided with a secure password.

The password should be changed regularly (e.g. once a year).

The account should not be used on too many servers to make lateral movement difficult. The account should definitely not be used on systems of a different tier level. Different accounts should be used here. In addition, such service accounts should only be provided with the mandatory rights.

It is also possible to monitor for possible kerberoasting attempts. When a TGS is requested, an event with the EventID 4769 is written to the event log. By monitoring for the occurrence of a large number of such events in a short period of time, all requested by the same user, you can thus detect the above request via Impacket.

Increase the Security of your IT System Now!
You will receive detailed advice from us!
Contact Now

Table of contents

Do you want to be part of our team?