March 28, 2023
If you're concerned with IT security, you can't miss the OWASP Top 10. The non-profit organization Open Web Application Security
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.
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.
The enumeration of usernames is exploited by attackers via the following Kerberos error codes:
| User status | Kerberos Error |
| Available/Activated | KDC_ERR_PREAUTH_REQUIRED - Additional pre-authentication required |
| Locked/Disabled | KDC_ERR_CLIENT_REVOKED - Client credentials have been revoked |
| Does not exist | KDC_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
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.
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.
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:
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
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:
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
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.
Add-ADGroupMember -Identity GROUP NAME -Members SERVERCOMPUTERACCOUNT1$, SERVERCOMPUTERACCOUNT2$
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!
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.
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
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.
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.
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.
If you're concerned with IT security, you can't miss the OWASP Top 10. The non-profit organization Open Web Application Security
Burp Suite by Portswigger and OWASP ZAP are both programs with a proxy server that run on your local device. With
Our co-founder Immanuel was a guest at Radio Bonn/ Rhein-Sieg and told the presenter team Nico Jansen and Jasmin Lenz and