Purple Team Tips and Tricks: Revisiting Kerberos Enum
There are different methodologies proposed to define the stages of a Red Team assessment, regardless of the chosen methodology, most agree on the importance of the reconnaissance and enumeration phase, in the initial and internal phases.

By performing the enumeration, we are able to validate collected information or obtain new information that is additional to what we currently have, but also, we are interacting more actively with the target, and if certain precautions are not taken in the process, the target will be able to detect our intentions and the operation might be interrupted without reaching the proposed goals.
Among the different existing enumeration methods, the purpose of this document is to analyze Kerberos enumeration, a process performed in environments that use Active Directory services and allows validation of existing users.
Let’s take a look at Kerberos Protocol itself.
Kerberos is a network authentication protocol that works on the principle of issuing tickets, allowing each user to be identified through them.
Some of the terms commonly encountered when talking about the Kerberos protocol are:
- Client: user who performs authentication via Kerberos to obtain a TGT authentication ticket;
- Ticket Granting Ticket (TGT): It is a ticket assigned to the user and is used for authentication in the AD environment without the need to use the credentials again;
- Key Distribution Center (KDC): In a Kerberos environment, the authentication server is logically separated into three parts: A database (DB), an Authentication Server (AS), and the Ticket Granting Server (TGS). These three parts, in turn, exist in a single server called the Key Distribution Center;
- Authentication Server (AS): The AS performs the desired client authentication. If the authentication happens successfully, the AS issues the client a TGT ticket. This ticket assures the other servers that the client is authenticated;
- Ticket Granting Server (TGS): The TGS is an application server that issues service tickets as a service.

During the authentication process, the client sends an AS-REQ request to the KDC with user information for validation and also requests a TGT ticket creation; this information contains the username and timestamp encrypted using the hash of the user’s password; the KDC validates the credentials, and first checks if the user exists in the database, and if exists, it starts to decrypt the timestamp received with the hash corresponding to the user found.
If it succeeds ( it means that the user and password are valid ), KDC starts to generate the authentication TGT ticket and returns an AS-REP response containing the created TGT ticket.
The entire communication process takes place on the KDC’s TCP 88 service port, which is commonly one of the Domain Controllers in an organization.
Kerberos enumeration takes advantage of the user authentication process, because to interact with the TCP 88 service port, it is not necessary to have any credentials, furthermore, the Kerberos protocol has a predefined configuration of error responses, which allows obtaining information about existing user accounts on the system.
Interesting error types are:
- KDC_ERR_C_PRINCIPAL_UNKNOWN – User not found in the DB;
- KDC_ERR_CLIENT_REVOKED – User found, but blocked;
- KDC_ERR_PREAUTH_FAILED – User found, but incorrect password;
- KDC_ERR_PREAUTH_REQUIRED – User found, but incomplete request.
Over the years, several tools have used error responses to be able to enumerate information in Kerberos environments. More commonly seen brute-force tools being used to enumerate as they take advantage of the KDC_ERR_PREAUTH_FAILED error message, indicating that the user is valid, but the password is incorrect, an example of this is the Rubeus tool and its brute module, which makes use of this error message.
We can use Rubeus as follows:
.\Rubeus.exe brute /password:' ' /users:users.txt /domain:purple /dc:10.194.208.106


Using a blank space as the password, Rubeus works as an enumeration tool, displaying the valid users found in the output.
During a Red Team Operation, it is possible to obtain leaked users lists on the internet or spreadsheets with this information in public shares within the corporate network, validating the information is very important for the operator, as it provides usable material during the assessment and can accelerate the process of compromising the environment. But as we spoke at the beginning, it is important to be careful when performing a validating as such, since it is possible to alert the Blue Team about the intentions in the network.
In the case of using Rubeus, the user validation process generates a known Microsoft Windows Event and is mainly used by SIEM tools to identify and detect threats, this event is WinEvent 4771.
The WinEvent 4771 is generated for several reasons, one of them being the use of the wrong password for authentication, and a considerable increase in these events can alert the Blue Team about the intentions of a Red Team Operator (or attacker) on the network.

There are tools other than Rubeus which can perform this enumeration and do not generate WinEvent 4771. An example of this is nmap (https://nmap.org/) and its NSE script krb5-enum-users (https://nmap.org/nsedoc/scripts/krb5-enum-users.html), which allows validation of users without generating this Microsoft Windows Event.
We can use nmap as follows:
nmap -Pn -n -p88 –script krb5-enum-users –script-args krb5-enum-users.realm=’purple.local’,userdb=’valid.txt’ 10.194.208.106
The following figure shows that the execution did not generate new WinEvents at the time of execution.

From the perspective of a Red Team Operator, we must always minimize noise and avoid being detected by Blue Team Agent. We must always be aware of variations in systems behavior: it is necessary to understand the processes that the data go through when using one or another tool and we always adapt to the needs, whether of a Red Team Operator or a Blue Team Agent.
Keeping this in mind, why does one tool generate logs and the other does not? How do we detect threats when logs are not generated?
We analyzed the packets generated by both tools, verifying the processes carried out, this allowed us to identify the differences between them.
When we see the data transmitted using Wireshark, we identified that the Rubeus generates a communication similar to the normal one performed by any legitimate authentication process via Kerberos, generating all the relevant information for the protocol, especially the data in the PA-DATA field.


On the other hand, when we see the information transmitted by the use of nmap, we can identify the absence of the PA-DATA field, where the data PADATA-ENC-TIMESTAMP is sent, which contains the timestamp encrypted using the hash of the user’s password.

The responses were also analyzed, in the case of the responses of the request made with Rubeus, it does not differ from the requests of a normal Kerberos process, receiving the error KDC_ERR_PREAUTH_FAILED, due to the use of a wrong password.


In the case of the response when using nmap, the error field is different, this being KDC_ERR_PREAUTH_REQUIRED, indicating the missing field in the request. The response indicates what information is missing and what types of encryption are expected.

Going deeper into the lack of generated logs referring to Kerberos, we identified a post from Microsoft about Kerberos Events, https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/enable-kerberos-event-logging. In this article there is information about Kerberos protocol supplemental logs, but Microsoft recommendations are to ignore these as they are often false positives. Unfortunately, this is where we find the log corresponding to the KDC_ERR_PREAUTH_REQUIRED error.

So, from the perspective of a Red Team Operator, we were able to show which of the tools will provide a quieter use, with respect to the Kerberos protocol logs, and based on this analysis, we were able to identify differences between tools being used for the same purpose considering the need to reduce suspicion during the operation.
What about the perspective of a Blue Team Operator?
Well, now that we know what happens during the process of an enumeration and that we know about Microsoft’s recommendation not to generate the necessary logs to identify activities related to user discovery, as these cause many false positives, in this case, it is necessary to take a different approach to get around the problem.
We already know what happens when identifying valid users in an enumeration/validation process, but what about when the user is invalid? Let’s take another look at the tools and see what happens in the Kerberos protocol request and response packets.
We analyzed the packages generated in both tools used, the requests AS-REQ remain the same as the previous ones, but the AS-REP responses have a modification, specifically in the Kerberos error field, regardless of the tool used, the response packages are the same, and contain the same error KDC_ERR_C_PRINCIPAL_UNKNOWN, this error has a linked event that is generated by the system, Microsoft Windows Event 4768.

The WinEvent 4768, has certain information that we can link to the tools used in the request, but these can be modified over time to try to look like requests from windows systems, even so, it’s good to keep an eye on them.
The main information is as follows:
- eventID: Event number, in this case, 4768;
- ticketEncryptionType: Identifier of the encryption used, in this case, 0xFFFFFFFF, as it indicates that the account does not exist and there is no encryption available for it;
- ticketOptions: multiple values, it is important to analyze tools on a recurrent form to map variations in tool implementations.
Using the previous information, it is possible to create effective SIEM rules to identify Kerberos enumeration processes more robustly and completely.
As seen throughout this post, the analysis of the processes to which the data is submitted to generate information is of vital importance to know when or not to use certain tools, in which ways to evade detection processes, as well as to modify the detections and evolve the rules over time, following the evolution of tools and approaches to this end, regardless of whether you are a Blue Team Agent or a Red Team Operator.