Kerberos Attacks

Kerberos is the predominately used one Authentication protocol in Microsoft Active Directory and has largely replaced the New Technology LAN Manager (NTLM) in everyday use. Kerberos has the great advantage that it is much more secure than NTLM. However, there are a few things you should keep in mind when using Kerberos in order to create a secure AD environment.

In this article we therefore present some essential ones Kerberos Attacks before. A good understanding of these vulnerabilities requires a basic understanding of the protocol, which we already covered in this articles treated. The most important thing in brief: Kerberos uses so-called Tickets, which domain users can use to authenticate 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 Brute force attacks against this protocol. 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, just a connection to the KDC.


When sending an authentication request (AS-REQ), an attacker can use the response from the KDC to determine whether a user exists or not. This allows attackers to username effectively brute force by using word lists. Here, it is advantageous for the attacker 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 circumstance reduces the probability that an attack will be noticed.

It is also possible to use the Kerberos User Enumeration to determine 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 suspended. Therefore, the attackers should be careful with this Kerberos attack.

ProSec Kerberos Attacks
Kerberos user enumeration via Kerberos

Attackers use the enumeration of usernames via the following Kerberos error codes out:

user statusKerberos error
Present/EnabledKDC_ERR_PREAUTH_REQUIRED - Additional preauthentication required
Locked/DisabledKDC_ERR_CLIENT_REVOKED - The client's credentials have been revoked
Does not existKDC_ERR_C_PRINCIPAL_UNKNOWN - Client not found in Kerberos database


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

In order to log these events in the event log at all, you first have to Default setting for monitoring account logins adjusted. For this you adapt the group guidelines under the path

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

to: Set the guidelines

  • Check credentials monitor
  • Monitor Kerberos Authentication Service
  • Monitor Kerberos service ticket operations

 each to the value "success and failure', so that failed logins are also logged. After that you can view the event log after the EventID 4768 and the one contained therein string "0x6" search.

Why isn't searching for EventID4768 enough?

The event 4768 is created when a TGT is requested or granted – 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". You can only assume a Kerberos enumeration if you find this error code and these events accumulate noticeably in a short period of time.

What other attacks can you detect through these settings in the event log?

Kerberos Attacks affecting the Kerberos service for Password spraying abuse, you can also see the event log. In this case, too, you must configure event logging using the group policies described above so that the relevant events are logged. After that, you can check the event log for the occurrence of the EventID 4771 Monitor (“Kerberos pre-authentication failure”). 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 use other tools and ideally a SIEM to permanently monitor the Active Directory and be able to react immediately to attacks.

Do you keep an eye on the activities in your network?
Test the reaction of your IT to hacking attacks with a penetration test!
For the penetration test

Kerberos Attack 2: AS-REP Roasting

AS-REP Roasting is a Kerberos attack in which attackers encrypt parts of a AS_REP message steal from user accounts in order to then crack them offline. The prerequisite for this is that the account in question has the Kerberos pre-authentication is disabled. If so, 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 encrypted with the user's NTLM hash. This encrypted part of the AS_REP can then be used for cracking the password be exploited.
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 preauthentication
Attention: Image is for explanation only - deactivation represents a security risk!


When pre-authentication is enabled, a user who needs access to a resource starts the Kerberos authentication process by sending 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's 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 by this user. The AS-REP message also contains information 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 attempting to crack the krb5asrep with appropriate inputs. If it is possible to decrypt the AS_REP into meaningful plain text, the key used corresponds to the user's password.
Advantageous for attackers: No domain account is required for this Kerberos attack, only a connection to the KDC. However, if the attackers have a domain user, they can use an LDAP query to find users in the domain without Kerberos pre-authentication. Otherwise the usernames have to be guessed. However, the combination with Kerberos attacks such as the Kerberos user enumeration makes this much easier.
ProSec Kerberos Attacks
AS-REP roasting attack via Crackmapexec


How can you protect your network from this Kerberos attack?
First, make sure all accounts in your domain have the Kerberos pre-authentication enabled have. (This has been the default setting since Kerberos v5.) To check which users within a domain have set this setting incorrectly, you can perform the corresponding LDAP query.
In addition, enforcement is more effective Password Policy essential for Active Directory to ensure your environment is not vulnerable to AS-REP roasting. If a strong password is used on a vulnerable account, it is virtually impossible to "break" the encryption by guessing the password. A secure, enforceable, and therefore effective, password policy also helps ensure users use strong passwords elsewhere. These are then also not easy to guess or otherwise vulnerable to brute force or other common password attacks.

Kerberos Attack 3: Kerberos rusting

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

Only one domain account is required to perform Kerberoasting, the Service Principle Names (SPNs) can request – which anyone can do as no special rights 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 TGS request specifying one SPN is provided and this SPN is registered in Active Directory, the domain controller provides a ticket. This ticket is with the secret key of the account running the service. With this information, an attacker can now attempt to use the ticket offline brute force attacks to crack and thus obtain the user's plain text password.

ProSec Kerberos Attacks
Kerberoasting attack via Impacket-GetUserSPNs


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

There are a few prerequisites to using 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 later (if using the gMSAs for SQL Server)
The following guide will guide you through all the necessary steps:

Step 1 - Install Active Directory PowerShell Module DC

If not already installed, you must 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 the root key for the Key Distribution Service exists and create it if necessary

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

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

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

ProSec Kerberos Attacks
KDS root key check - error message if root key does not exist
ProSec Kerberos Attacks
KDS root key check - "True" message if root key is present

If there is no root key yet, you must generate it on the DC using the following command in PowerShell.

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

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

Add-KdsRootKey -EffectiveImmediately

Step 3 - Creation of a new security group

You need a new security group to manage and allocate the computer accounts of servers that should use the gMSA. You can create this using PowerShell:

New-ADGroup -Name GROUPNAME -Description “THIS IS A DESCRIPTION OF THE GROUP, EG: 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 using a specific gMSA.


With this you add the computers on which the gMSA should be used to the previously created group (using the appropriate group name). Computer accounts always end with a $ sign.

Get-ADGroupMember -Identity GROUPNAME

You can use this to check whether the computer accounts were added successfully.

DANGER! So that the gMSA can be installed on the affected servers in the further 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 throughout the command. For GROUP NAME, enter the name of the security group that you created previously. 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 can only work if you have restarted the server after being assigned 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 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 the point “SQL Server” (SQLSERVERNAME) under SQL Server Services and then right-click on the item “Properties”.

Under the “Sign in” 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!

DANGER! 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)

Once you've followed these steps, the corresponding SQL server is no longer associated with a user account SPN. The account can therefore no longer be attacked unless it is also 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! The request from the TGS will therefore continue to be possible. To prevent this exploitation, this account must be associated with a secure password be provided.

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

The account should not be used on too many servers to create a lateral movement to complicate. 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 absolutely necessary rights.

It is also possible to monitor possible attempts at Kerberoasting. 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 of which are requested by the same user, you can thus recognize the request via Impacket described above.

Increase the security of your IT system now!
You will receive detailed advice from us!
Contact us now
Newsletter Form

Become a Cyber ​​Security Insider

Get early access and exclusive content!

By signing up, you agree to receive occasional marketing emails from us.
Please accept the cookies at the bottom of this page to be able to submit the form!

Table of Contents

NewsLetter Form Pop Up New

Become a Cyber ​​Security Insider

Subscribe to our knowledge base and get:

Early access to new blog posts
Exclusive content
Regular updates on industry trends and best practices

By signing up, you agree to receive occasional marketing emails from us.
Please accept the cookies at the bottom of this page to be able to submit the form!