Lion Cipher Lab

Enumerate valid AD usernames and spray a password with Kerbrute — quietly, before you have any creds

• Penetration Testing / Red Team
• Intermediate
• ~60 min
• Free · no account required

Why it matters

Kerbrute is the tool an attacker reaches for FIRST -- earlier than roasting, earlier than any credential -- because it answers the two questions that unlock everything else: which usernames are real, and does anyone share a weak password. It works by abusing an unavoidable property of Kerberos. When a client begins to authenticate it sends an AS-REQ (the first authentication request) to the domain controller acting as the KDC, and pre-authentication is normally required: the KDC will not proceed until the client proves it knows the password. But BEFORE it even gets to that proof, the KDC has…

What you'll learn

• explaining Kerberos user enumeration in plain words: how the AS-REQ / pre-authentication exchange makes the KDC answer with a DIFFERENT error for a valid versus an invalid principal, and why that difference leaks which usernames exist
• reading the two error strings that drive the whole technique: KDC_ERR_PREAUTH_REQUIRED (the account EXISTS and wants pre-auth) versus KDC_ERR_C_PRINCIPAL_UNKNOWN (no such account) -- and knowing that Kerbrute infers 'valid user' from the first
• understanding why `kerbrute userenum` is QUIET: it never submits a password, so it produces no 4625 failed-logon events -- only a Kerberos 4768 pre-auth-required footprint on the DC
• understanding why `kerbrute passwordspray` is NOISY and dangerous: it tries a real credential, so every miss is a 4625 event and enough tries can trip account lockout -- which is why you SPRAY (one password across many users) instead of brute-forcing one account
• running kerbrute against your OWN lab: userenum to turn a list of GUESSED names into a list of CONFIRMED accounts, then passwordspray to test one weak shared password across all confirmed users
• creating a deliberately weak account in your own lab with a common shared password so the spray has something real to find (the BEFORE/AFTER the lab measures)
• pacing a spray under the domain account-lockout policy: reading the observation window and lockout threshold, keeping attempts-per-window safely below it, and understanding fine-grained / smart lockout
• telling this ENUMERATION + SPRAY lab apart from the roasting labs cleanly: this confirms usernames and finds a weak password (cracks nothing), AS-REP roasting is hashcat -m 18200 on the AS-REP, Kerberoasting is -m 13100 on the TGS-REP
• the judgment: WHEN you reach for Kerbrute (earliest, even before any credential, the moment you have candidate names), WHY the quiet half runs freely but the loud half must be paced, and how the confirmed list then FEEDS AS-REP roasting and Kerberoasting
• the honest negative: modern defences (fine-grained lockout, MFA, Azure AD smart lockout, alerting on 4625 spikes and unusual 4768 volume) blunt spraying -- so you enumerate first, spray slowly, and expect a well-run domain to catch or stop you

Steps in this lab

1. First: this is your lab, and enumeration-plus-spray is a real attack
2. The words you need: AS-REQ, pre-auth, and the two errors that leak usernames
3. Install Kerbrute and point it at your lab
4. Build the candidate username list — the input enumeration turns into fact
5. Enumerate valid usernames with `kerbrute userenum` — the quiet half
6. Plant a weak shared password — so the spray has something real to find
7. Spray one password across all users with `kerbrute passwordspray` — the noisy half
8. The honest picture: when to reach for it, why it differs from roasting, and what stops it

Open the full interactive lab →