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.
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.
Attackers use the enumeration of usernames via the following Kerberos error codes out:
| user status | Kerberos error |
| Present/Enabled | KDC_ERR_PREAUTH_REQUIRED - Additional preauthentication required |
| Locked/Disabled | KDC_ERR_CLIENT_REVOKED - The client's credentials have been revoked |
| Does not exist | KDC_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
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.
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.
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:
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
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:
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
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.
Add-ADGroupMember -Identity GROUPNAME -Members SERVERCOMPUTERACCOUNT1$, SERVERCOMPUTERACCOUNT2$
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!
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.
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
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.
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.
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.
The cyberattack on the crypto exchange Coinbase has shown that insiders can pose the greatest threat to companies. It's not just technical vulnerabilities, but especially human vulnerabilities that enable cybercrime. This article explains why insider threats pose a particular risk and what measures companies can take.
The recent cyberattack on the Federal Employment Agency demonstrates that even small vulnerabilities can lead to massive damage. The incident raises important questions regarding corporate strategies for preventing such scenarios.
A Microsoft security update has unexpectedly created a new security vulnerability that puts businesses at risk. This undocumented side effect could block users' Windows updates and cut off systems from future security updates. A potential nightmare for IT security and business management.
