Kerbrute: Active Directory User Enumeration Explained

Kerbrute is a tool for quietly attacking Active Directory through Kerberos, the protocol Windows uses to authenticate. It does two things exceptionally well: it works out which usernames are valid without triggering account lockouts, and it tests passwords against those users in a way that is quieter than any normal login attempt. Both exploit a design property of Kerberos itself, which is why it is a fixture of internal testing.

Here is what it does and, if it appears in a report against your domain, what the finding actually means.

A note on currency, as of September 2026: Kerbrute’s last tagged release is v1.0.3, published in December 2019, and it still works unchanged. That is not neglect showing; it is the point. The tool relies on how Kerberos is designed, not on a bug that a patch could close, so its age says nothing about whether your domain is exposed.

The Kerberos quirk it abuses

When a client begins Kerberos authentication, it sends an initial request (an AS-REQ). The domain controller’s response reveals something before any password is checked: if the username does not exist, the error differs from the error when the username exists but the pre-authentication is wrong.

That difference is the whole trick. It means an attacker can distinguish valid usernames from invalid ones without ever submitting a password, and therefore without incrementing the failed-login counter that drives account lockout. Kerbrute automates this at speed.

The two things it does

Username enumeration. Given a wordlist of likely usernames, derived from the company’s email format (jsmith, john.smith), employee names from LinkedIn, or common patterns, Kerbrute confirms which correspond to real accounts. The output is a validated list of real domain users. This is reconnaissance, and because no password is ever sent, it is close to invisible to defenders watching for failed logins.

Password spraying. The counterpart to enumeration. Instead of trying many passwords against one account (which locks it), spraying tries one common password (Winter2026!, Companyname1) against many accounts. In a domain of any size, someone is using the season-and-year password. Each account sees only one attempt per sprayed password, which keeps a careful spray under typical lockout thresholds. It is not risk-free: every wrong password still counts as a failed logon, and Kerbrute’s own documentation warns that spraying increments the failed-login count and can lock accounts out. Its --safe option stops the whole run as soon as any account comes back locked. Kerbrute performs this over Kerberos, which is quieter than authenticating against SMB or a web portal.

What its findings mean

If Kerbrute appears in a report, the findings tend to be:

• Usernames were enumerable: the domain leaks valid accounts through the Kerberos pre-authentication behavior. This is hard to eliminate entirely but can be monitored.
• A password spray succeeded: one or more accounts used a weak, guessable password. This is the serious one: it is a valid credential, and it usually leads directly to the next stage, where a tool like NetExec maps everywhere that credential reaches.
• AS-REP roastable accounts were found: accounts with Kerberos pre-authentication disabled, whose password hashes can be requested and cracked offline. That is a specific misconfiguration with a specific fix.

The through-line is that Active Directory’s own authentication design gives an attacker a quiet way to find users and test passwords, and weak passwords remain the most reliable way into a Windows network.

How defenders detect and stop it

Kerbrute is quiet, but not silent: its activity has a signature if you are watching the right events. The two things it does leave two different traces, and they need different alerts:

Activity	Watch for	What it looks like
Username enumeration	Event ID 4768 failures, result code 0x6 (client principal unknown), with Kerberos authentication auditing enabled	many ticket requests for many distinct usernames from one source host, with no password ever submitted
Password spraying	Event ID 4771, pre-authentication failure, result code 0x18 (bad password)	one failure per account across many accounts from one source in a short window

Group both by source host. Standard failed-logon monitoring (Event ID 4625) may miss them, which is exactly why Kerbrute uses the Kerberos path, and enumeration never trips a lockout because no password is sent.

Detection matters, but prevention matters more, and it is straightforward:

1. Enforce strong password policy: length over complexity, and screen against breached-password and seasonal-pattern lists. This defeats spraying directly.
2. Multi-factor authentication: even a valid sprayed password fails at the second factor.
3. Alert on 4771 patterns, not only on lockouts. Spraying is specifically designed to stay under the lockout threshold.
4. Fix AS-REP roastable accounts: enable pre-authentication everywhere it is not deliberately disabled.
5. Smart lockout / risk-based policies that recognize distributed spraying rather than counting per-account failures.

How we use it in an engagement

Kerbrute operates at the transition from reconnaissance to initial access in internal network penetration testing and red team assessments. It turns a list of likely names into validated accounts and then into working credentials: the foothold from which lateral movement begins. A successful spray is frequently the moment an external or assumed-breach test becomes an internal compromise.

In our engagements, password testing of any kind happens only inside the written rules of engagement: we agree your lockout limits in writing before testing starts, keep every attempt below them, and raise anything critical with your contact immediately rather than waiting for the report. The report then names which accounts accepted a guessable password and how the account list was confirmed, with proof and a fix for each, so the remediation is specific rather than “improve password policy.” The detection table above tells your team which events should have alerted while it ran. For where that foothold leads next, see how an Active Directory pentest works; the domain-only assessment starts at $6,000, the same starting price as the full internal test on the internal network testing price page.

The short version

Kerbrute exploits a property of Kerberos to enumerate valid Active Directory usernames without sending passwords, then sprays common passwords across those accounts while staying under the lockout threshold. Its findings are almost always weak passwords and enumerable users, and a successful spray typically becomes the foothold for everything that follows. The defenses are unglamorous and effective: strong screened passwords, MFA, and alerting on Kerberos pre-auth failures rather than only on lockouts.

Would a common password get an attacker into your domain? A spray against your own users, done safely, is a standard part of every internal penetration test we run. Scope one here.