Hunting Kerbrute: Analysis, Detection and Mitigation of Kerberos Attacks in Active Directory
Threat Research
Securonix Threat Research Series
Hunting Kerbrute: Analysis, Detection and Mitigation of Kerberos Attacks in Active Directory
By Securonix Threat Research: Den Iuzvyk, Tim Peck
May 1, 2025
Microsoft Active Directory (AD) is the backbone of identity and access management in most enterprise environments. However, its reliance on Kerberos authentication introduces unique attack surfaces that threat actors continuously exploit. One such tool that has gained traction among red teams and adversaries alike is Kerbrute, an open-source utility designed to enumerate valid usernames and conduct password-spraying attacks against domain controllers.
So why kerbrute? It’s a tried and tested tool used by not only red teamers but it’s also been identified as being used in attack campaigns. Some of these include associations with RansomHub ransomware, the FIN12 threat actor group as well as ties to being used by Alloy Taurus.
In this article, we will break down how kerbrute works, the attack scenarios it enables, and most importantly, how to detect and mitigate its impact before it becomes an entry point for a larger breach.
What is Kerberos authentication?
Kerberos is a network authentication protocol designed to provide secure authentication for users and services in an AD environment. Unlike older authentication methods such as NTLM (NT LAN Manager). These older authentication methods rely on challenge-response mechanisms and the sending of hashed credentials that are susceptible to relay and pass-the-hash attacks. Kerberos eliminates the need for credential transmission by using a system of encrypted tickets.
When a user attempts to authenticate, they first request a Ticket Granting Ticket (TGT) from the Key Distribution Center (KDC) from a domain controller. The ticket consists of an Authentication Server (AS) and a Ticket Granting Server (TGS). This TGT, encrypted with a secret key known only to the KDC, allows the user to request access to other services without repeatedly entering their credentials.
Compared to NTLM, Kerberos is considered more secure because of how it enforces mutual authentication and supports more modern encryption standards such as AES.
Despite its advantages, Kerberos still has its weaknesses, especially when pre-authentication is disabled. This allows tools like Kerbrute to enumerate valid usernames, facilitate in password attacks, and the enabling of advanced post-exploitation techniques like Kerberoasting and Pass-the-Ticket attacks.
Preauthentication in Kerberos and why it matters
Kerberos pre-authentication is a security feature designed to prevent unauthorized users from blindly requesting TGTs without proving their identity first. When pre-authentication is enabled (which is the default setting), a user must provide a valid timestamp encrypted with their password before the Key Distribution Center (KDC) will process their authentication request. If the timestamp is incorrect (indicating an invalid password), the request is immediately rejected, making it harder for attackers to enumerate valid usernames or attempt offline brute-force attacks.
However, some organizations disable pre-authentication for specific accounts, usually service accounts or legacy applications to allow them to authenticate in environments where they cannot handle the pre-authentication step correctly. When pre-authentication is disabled, the KDC responds to authentication requests with an encrypted TGT, even if the password is incorrect. This enables attackers to use Kerbrute or tools like GetNPUsers.py to enumerate valid usernames, since the presence of a response confirms that the account exists. Worse, if an account has weak encryption settings (e.g: supports RC4), attackers can capture and attempt to crack the AS-REP response (AS-REP Roasting attack) offline, potentially recovering plaintext credentials.
Figure 1: kerberos preauthentication in user account settings on a domain controller
Organizations should only disable pre-authentication for accounts where absolutely necessary, and they should monitor Event ID 4768 (TGT Requested) and Event ID 4771 (Pre-Authentication Failed) for abnormal patterns around these user accounts that might indicate user enumeration or password spraying attempts.
Administrators or domain admins should regularly audit users with kerberos preauthentication disabled. Running the command below on a domain controller will print a list of affected accounts:
Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth | Select-Object SamAccountName, UserPrincipalName, Enabled
Kerbrute in a nutshell
At its core, Kerbrute is an offensive kerberos tool capable of performing several functions ranging from AD enumeration, brute force attacks and password spraying. It abuses the Kerberos pre-authentication capabilities to confirm whether a username exists without needing a valid password. This makes it a stealthy reconnaissance tool, allowing attackers to identify valid accounts before launching further attacks such as password spraying or ticket-based exploits (eg: Pass-the-Ticket and Kerberoasting).
Unlike traditional brute force attacks that flood login portals and generate excessive failed login attempts, Kerbrute operates directly against the Kerberos service (KDC), often bypassing basic account lockout policies and avoiding detection by traditional security controls.
For security defenders, Kerbrute represents a major visibility challenge. Since it doesn’t generate the typical Event ID 4625 (Failed Logon) seen in NTLM-based attacks, many detection platforms fail to pick up on its activity. Instead, security teams must rely on Event ID 4768 (TGT Requested) and 4771 (Pre-Authentication Failed) to detect anomalies in Kerberos traffic. Without proper logging and monitoring, Kerbrute activity can remain undetected allowing attackers to quietly map out your entire AD environment.
Lab prep and preface
All of the domain names, host names, usernames and IP addresses referenced in this article are not production systems or customer related data. All of our tests were conducted in a lab in a controlled environment. This gives us insight into both red team and blue team aspects of the attack.
With that being said, let’s jump in and see what we can learn!
Domain user enumeration
One of the functionalities of kerbrute is the quick and easy method used for enumeration users. If performing this attack from a machine not joined to the domain, this is useful as determining domain usernames can often be challenging.
If the attacker (in this example) was staging from a domain joined box, this can be skipped or disregarded as obtaining a user list can be done with PowerShell. For the sake of this example we opted to use WMIC using the following command to dump all domain users into a file named usernames.txt:
wmic useraccount where “Domain=’domainName’” get name > usernames.txt
Once we’ve retrieved the list of users, we can confirm their existence by providing kerbrute with the “userenum” command string and other required parameters. This can be seen in the figure below.
Figure 2: kerbrute usernames and output of successful run
From data we were able to gather, usernames that were disabled, locked out or have had their credentials revoked or expired produced an event ID 4768, however active and healthy accounts produced no event id during the enumeration phase. Depending on the size of the organization, this could produce anywhere from a few event IDs to dozens. Because of this, we can’t recommend EVID 4768 being a reliable source for detecting user enumeration in Kerberos.
Password spray
A password spray attack is a technique where an attacker attempts to authenticate multiple user accounts using a single, commonly used password (e.g: Spring2024! or Welcome123). Unlike traditional brute-force attacks that rapidly guess many passwords for a single account risking account lockouts, password spraying spreads attempts across many accounts to avoid triggering user-based security thresholds.
Since many organizations enforce account lockout policies after multiple failed attempts on a single user, attackers use this method to quietly test weak passwords across an entire domain. If even one account is compromised, it can provide an entry point for lateral movement and further attacks within the network.
In this example we’ll use kerbrute to password spray all of the enumerated domain users using the password “Welcome1”. To do this we’ll use the “passwordspray” parameter with other required data:
Figure 3: kerbrute password spray
Of the 1200 gathered usernames, the attack took only six seconds! In the end we gathered 30 users who in this factitious scenario, neglected to change their password after being onboarded.
Let’s dig into what exactly happened in Kerberos when we either succeeded in guessing the user’s password or failed.
Attacking Kerberos: understanding Windows event IDs:
As we mentioned prior, when conducting a password spray attack using Kerbrute, two key Windows Event IDs: 4768 (TGT Requested) and 4771 (Pre-Authentication Failed) provide critical insight into Kerberos authentication attempts. Understanding these event logs is important for security personnel to understand for detecting and defending against Kerbrute-based attacks. Let’s break down each event ID to get a better understanding as to how they can both play a role in building up our detections.
Event ID 4768 – Kerberos Authentication Ticket (TGT) Requested
This event is logged every time an account requests a Ticket Granting Ticket (TGT) from the Key Distribution Center (KDC), which is the first step in Kerberos authentication. A successful authentication will produce a result code of 0x0. According to Microsoft’s documentation, this code simply means NO ERROR, which is what we expect to see on a successful authentication. Any other status could be a result of the account being disabled, networking issues, or a bad password to name a few.
What this means during a Kerbrute password spray attack:
- If the username is valid and the correct password is provided, you will see Event ID 4768 with a result code of “0x0” in the event logs.
- If an incorrect password is used, Event ID 4768 will not be logged because Kerberos pre-authentication will fail first.
How defenders can use this:
- Look for a high volume of TGT requests from a single source (e.g., a machine making repeated authentication attempts).
- Monitor for an unusual number of TGT requests for service accounts or admin users outside of normal working hours.
Event ID 4771 – Kerberos Pre-Authentication Failed
This event is logged when a Kerberos authentication request fails due to an invalid username or incorrect password. This is particularly important when Kerbrute performs password spraying where we would expect to see many errors in relation to successes.
If Kerbrute attempts to authenticate with an invalid password, Event ID 4771 will be logged for each failed attempt.
How defenders can use this:
- Detecting large numbers of failed pre-authentication attempts from the same IP address. This is a strong indicator of Kerbrute password spraying.
- Correlate 4771 failures followed by 4768 successes for the same account. This may indicate a successful password spray.
- Monitor failed logins with 0x18 (wrong password) in rapid succession across multiple accounts.
Below is an example of a password spray attack using kerbrute. As you can see we’ve got a decent mix of event IDs 4788 and 4771. The highlighted event shows the result code as 0x0 indicating a successful password was supplied for the user.
Figure 4: Windows event logs – EVID 4768: Successful password spray example
As we mentioned prior, if the password is guessed incorrectly an event ID 4771 is generated. This would tell kerbrute that the password was incorrect and we can move onto the next user. However, it’s possible that we may successfully guess a password on an account that is unable to authenticate for a various number of reasons. Some of these include the account being disabled or locked out.
This information may still be valuable to an attacker, however may hinder their efforts in moving laterally. By looking for event ID 4768 in Securonix, we’re able to differentiate between the two authentication types in regards to password spraying.
Figure 5: failure codes found in event ID 4768 log messages
Other methods of detecting kerbrute
Assuming that the attacker is staging their attack from a compromised endpoint and provided you’re collecting endpoint logs, this opens the door for even more detection opportunities. We highly recommend deploying advanced logging capabilities like Sysinternals Sysmon or PowerShell logging, especially on endpoint systems. Typically this is where a real-world attack would start in either a phishing or insider threat scenario.
Detection opportunity 1: Rare process communicating over port 88
As the kerberos authentication protocol uses port 88 for its network authentication layer, we can look for any rare process communicating over that port.
In the example below we put together a quick policy violation looking for any process considered rare for the resource group communicating over port 88. This policy ended up detecting the kerbrute.exe process staging out of C:\Users\Public.
Figure 6: detecting kerbrute – rare process over kerberos port (88)
As seen in the figure above, based on our policy name, this detection is also great for detecting other active directory adversarial tools such as Bloodhound or Rubeus.
Aggregated event analytics: large amount of pre-auth failures in a short period of time
Another simple way to catch password spray attacks against kerberos is to look for a large number of kerberos pre-auth failures in a short period of time. If you recall, our password spray attack using kerbrute only took six seconds for 1200 users once we had a valid domain user list. In our tests, we built a policy which used the Securonix “Aggregated Event Analytics” engine to look for 200 pre-auth failures on domain controllers in 1 minute based on the following criteria:
- EventID: 4771
- LogonType: 2
The rest of the criteria can be built based on the details below. Feel free to tweak the numbers based on what would be considered abnormal for the size of your organization.
Figure 7: Policy violation for a large amount of kerberos pre-auth failures
Once created, after re-running a kerbrute password spray we were able to trigger a true positive policy violation:
Figure 8: the newly created policy in action, detecting a kerbrute password spray attempt
The triggered violation provides clear evidence of a Kerbrute password spray attack. As seen in the figure above, each authentication attempt targets a unique user, indicating that a single attacker or source IP systematically tried to log in as multiple users within a short timeframe.
Wrapping Up: Detecting and defending against kerbrute attacks
Kerbrute is a powerful tool that exploits certain functionality in Kerberos authentication to enumerate valid users and perform stealthy password spraying attacks. Because Kerberos does not always generate the same authentication failure events as NTLM, traditional security monitoring solutions can easily overlook its activity. By understanding how Kerbrute interacts with Active Directory, blue team defenders should develop effective detection strategies by monitoring for key Windows Event IDs (4768, 4771) and correlating anomalous patterns such as high volumes of TGT requests or repeated pre-authentication failures.
From an attacker’s perspective, we explored how to generate Kerberos authentication logs in a lab environment, simulating password spraying to understand what activity is visible on the domain controller. This highlights why pre-authentication should not be disabled for users unless absolutely necessary and why organizations should enforce strong password policies, account lockout protections and anomaly based detections.
For defenders, the best way to mitigate the effectiveness of kerbrute is by implementing proactive logging, monitoring failed Kerberos authentication attempts and restricting unnecessary pre-auth exemptions. Security teams should also regularly audit accounts with pre-auth disabled, detect password spraying patterns and configure SIEM policies to flag unusual authentication requests originating especially from non-domain joined systems.
As attackers continue to evolve their methods, understanding Kerberos attack techniques is essential for building strong detections. By thinking like an adversary and testing tools like Kerbrute in a controlled environment we can better prepare their networks against real-world threats.
References:
- Github – ropnop/Kerbrute
https://github.com/ropnop/kerbrute - Microsoft – 4768(S, F): A Kerberos authentication ticket (TGT) was requested
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4768 - #StopRansomware: RansomHub Ransomware
https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-242a - FIN12 GROUP PROFILE: FIN12 PRIORITIZES SPEED TO DEPLOY RANSOMWARE AGAINST HIGH-VALUE TARGETS
https://www.mandiant.com/sites/default/files/2021-10/fin12-group-profile.pdf - Persistent Attempts at Cyberespionage Against Southeast Asian Government Target Have Links to Alloy Taurus
https://unit42.paloaltonetworks.com/alloy-taurus-targets-se-asian-government/
