Active Directory (AD) remains the cornerstone of enterprise identity management in organizations of all sizes. As of 2025, millions of companies still rely on it for authenticating users, managing access, and securing resources across hybrid and on-premises environments. One of the most common initial steps in compromising these networks involves identifying valid usernames, which attackers then target with password spraying, brute-force attempts, or more advanced credential attacks.
Kerbrute, a lightweight, open-source tool written in Go, has established itself as a staple for penetration testers and red teams. It excels at enumerating usernames without requiring any credentials, making it particularly appealing for stealthy reconnaissance. Developed by Ronnie Flathers (@ropnop), the tool leverages the Kerberos protocol’s behavior to distinguish real accounts from non-existent ones.
How Does Kerbrute Enumerate Usernames in Active Directory?
Kerbrute operates by sending unauthenticated Kerberos Authentication Service Requests (AS-REQ) to a domain controller over UDP port 88. It requests Ticket-Granting Tickets (TGTs) for candidate usernames without providing any pre-authentication data.
The domain controller responds differently depending on whether the username exists. For valid accounts, it replies with KRB5KDC_ERR_PREAUTH_REQUIRED (error code 25), indicating pre-authentication is needed. For invalid usernames, it returns KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN (error code 6), signaling the principal does not exist.
Kerbrute parses these responses to classify usernames accurately. This process requires no authentication tokens, generates negligible network overhead, and avoids incrementing bad password counters—making it extremely stealthy compared to traditional brute-force methods.
The Kerberos Authentication Flow in Detail
Kerberos authentication involves multiple steps between the client, the Key Distribution Center (KDC), and service principals. The initial AS-REQ phase is where Kerbrute intervenes.
A client requests a TGT by specifying a user principal name (UPN) or sAMAccountName. The KDC first verifies the existence of the principal before proceeding to encryption challenges.
This existence check serves as an oracle. Attackers exploit it because the KDC must respond honestly to prevent denial-of-service attacks on legitimate users.
Kerbrute automates thousands of these requests in parallel, rapidly building a list of confirmed usernames.
Pre-Authentication Requirement Behavior Explained
By default, Windows Active Directory enforces pre-authentication for all accounts. This setting protects against offline password cracking by requiring clients to prove knowledge of the password via an encrypted timestamp.
When pre-auth is required, a valid username triggers the pre-auth error. An invalid one triggers the principal-unknown error.
Kerbrute relies on these distinct Kerberos error codes (25 vs. 6) to make reliable decisions. It achieves near-perfect accuracy unless the account explicitly disables pre-authentication.
Why This Method Is So Stealthy and Hard to Detect
Unlike LDAP enumeration (which often requires bind credentials) or NTLM-based tools (which trigger logon failures), Kerbrute never completes authentication.
Its traffic resembles benign failed Kerberos attempts, such as those from mobile devices or misconfigured applications. This blending into normal background noise complicates signature-based detection.
Additionally, Kerbrute runs quickly testing thousands of usernames in seconds further reducing the window for detection.
Kerbrute’s Effectiveness in Real-World Active Directory Environments
In 2025, Kerbrute continues to perform exceptionally well against unhardened domains. The tool’s core logic exploits a fundamental Kerberos design choice that Microsoft has not altered across Windows Server versions from 2016 through 2025.
Most organizations retain default settings where pre-authentication is enabled, ensuring Kerbrute’s oracle remains reliable. Penetration testing reports from 2024–2025 consistently show 95%+ accuracy when enumerating usernames.
Only deliberate hardening or architectural restrictions can meaningfully degrade performance.
Factors That Influence Success Rates
- Domain Functional Level: Irrelevant, as the behavior is protocol-level, not OS-specific.
- Account Configuration: Over 99% of accounts have pre-auth enabled by default. Only legacy or special-purpose accounts disable it.
- Network Access: Kerbrute requires direct UDP/88 connectivity to a domain controller. Firewalls, zero-trust policies, or segmented networks block it.
- Scale: With multi-threading (default 10 threads), Kerbrute handles 10,000+ usernames in under a minute.
Comparison with Other Enumeration Tools
| Tool | Requires Credentials | Noise Level | Lockout Risk | Speed | Stealth |
|---|---|---|---|---|---|
| Kerbrute | No | Low | None (userenum) | Very High | High |
| LDAP (ldapsearch) | Often Yes | Medium-High | None | Medium | Medium |
| CrackMapExec | Yes | High | Low | Medium | Low |
| rpcclient/enum4linux | Yes | High | None | Low | Low |
| Impacket GetNPUsers | No | Low | None | High | High |
Kerbrute’s combination of no credentials and low noise gives it a clear advantage for initial reconnaissance.
Real-World Use Cases in Penetration Testing and Red Teaming
Red teams frequently use Kerbrute early in engagements to generate targeted lists for password spraying.
Enumerated usernames feed into subsequent attacks like phishing campaigns, credential stuffing, or lateral movement.
Limitations and Edge Cases of Kerbrute Username Enumeration
Despite its strengths, Kerbrute has limitations. Certain account flags and network configurations can disrupt its logic.
Accounts configured with “Do not require Kerberos preauthentication” (DONT_REQ_PREAUTH) return different responses.
Legacy systems, custom realms, or third-party Kerberos integrations may produce inconsistent behavior.
Accounts Without Pre-Authentication Enabled
When the pre-auth flag is disabled, valid usernames return KRB5KDC_ERR_NONE (success) instead of the pre-auth required error.
Kerbrute interprets this as invalid unless the –safe mode or custom logic is used.
This flag is dangerous and rare in modern environments, but it still exists in legacy migrations.
Network and Firewall Restrictions
Kerbrute cannot reach domain controllers behind strict firewalls or in segmented networks.
Zero-trust architectures, VPN requirements, or cloud-hybrid setups often block UDP/88 from untrusted sources.
External attackers need initial foothold or compromised internal hosts to run Kerbrute effectively.
Detection by Modern Security Tools
EDR platforms like CrowdStrike, Microsoft Defender for Endpoint, and Sentinel increasingly monitor Kerberos traffic patterns.
SIEM rules detect spikes in Event ID 4768 (TGT requests) or 4771 (pre-auth failures).
Advanced analytics flag anomalous sources querying many unique usernames.
How to Detect Kerbrute Activity in Your Active Directory Domain
Effective detection combines Windows event logs, network monitoring, and behavioral analytics.
Domain controllers record Kerberos events in the Security log, providing rich data for correlation.
High-volume, low-variance requests from a single source are strong indicators of enumeration.
Key Event IDs to Monitor
- Event ID 4771: Kerberos pre-authentication failure (most common for invalid attempts).
- Event ID 4768: TGT granted (rare during pure enumeration).
- Event ID 4769: Service ticket request (may follow successful enumeration).
Setting Up Audit Policies
Enable detailed Kerberos auditing via Group Policy: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration.
Configure both success and failure auditing for Kerberos Authentication Service.
Review logs in real-time using tools like Splunk, Elastic, or Microsoft Sentinel.
Network Monitoring for Suspicious Traffic
Monitor UDP/88 for repeated connections from unusual IPs or hosts.
Deploy IDS/IPS signatures targeting Kerberos enumeration patterns (e.g., rapid AS-REQs).
Correlate network flows with AD logs for high-fidelity alerts.
Best Practices to Prevent Username Enumeration in Active Directory
Prevention requires layered defenses: configuration hardening, network controls, and proactive monitoring.
Minimize legacy authentication protocols and enforce strict policies.
Regularly test defenses by simulating enumeration attacks.
Implementing Stronger Authentication Controls
- Place privileged accounts in the Protected Users group to enforce stricter Kerberos settings.
- Enable multi-factor authentication (MFA) everywhere, reducing the value of enumerated usernames.
- Use strong, unique passwords and enforce regular rotation via password vaults.
Reducing Exposure of Domain Controllers
- Implement network segmentation to limit UDP/88 access to trusted subnets.
- Deploy host-based firewalls on DCs to block unnecessary traffic.
- Adopt zero-trust principles, requiring explicit authentication for internal Kerberos requests.
Regular Monitoring and Hardening
- Conduct periodic red team exercises to validate detection rules.
- Patch domain controllers promptly to close known vulnerabilities.
- Train security teams on Kerberos-specific attacks and tools like Kerbrute.
Conclusion
Kerbrute remains one of the most effective tools for detecting valid Active Directory usernames, thanks to its exploitation of the Kerberos protocol’s inherent design. Its unauthenticated, low-noise approach makes it ideal for reconnaissance, but proper logging, monitoring, and configuration hardening can significantly reduce its success rate. By understanding Kerbrute’s mechanics and implementing layered defenses, organizations can protect their environments from this stealthy enumeration technique and strengthen overall security posture.