Lion Cipher Lab
AS-REP roast the accounts that skipped Kerberos pre-auth — and crack the tickets in your own AD lab
- Penetration Testing / Red Team
- Intermediate
- ~60 min
- Free · no account required
Why it matters
AS-REP Roasting is one of the quietest ways an attacker turns a list of usernames into a cracked domain password, and it is dangerous precisely because it can happen BEFORE the attacker has any credentials at all. Kerberos normally makes you prove you know your password up front: when you start to authenticate, your client encrypts a current timestamp with a key derived from your password and sends it in the first request (the AS-REQ). That step is called PRE-AUTHENTICATION, and it is on by default. But Active Directory has a per-account flag, 'Do not require Kerberos pre-authentication,'…
What you'll learn
- explaining Kerberos pre-authentication in plain words: what an AS-REQ and an AS-REP are, why pre-auth exists, and what the account flag 'Do not require Kerberos pre-authentication' (UserAccountControl DONT_REQ_PREAUTH) actually turns off
- understanding why an account with pre-auth DISABLED lets the KDC hand out an AS-REP whose encrypted portion is derived from that account's PASSWORD -- to a requester who never proved they know the password -- which is what makes it crackable offline
- telling AS-REP Roasting apart from Kerberoasting cleanly: pre-auth-disabled USER accounts via the AS-REP (hashcat -m 18200, $krb5asrep$) versus SPN SERVICE accounts via the TGS-REP (hashcat -m 13100, $krb5tgs$)
- seeing that AS-REP roasting needs valid USERNAMES first, so it is paired with user enumeration -- and that in its purest form it needs no domain credentials at all
- creating a user in your OWN lab, DELIBERATELY ticking 'Do not require Kerberos pre-authentication' and giving it a weak password so you have something crackable to attack
- dumping $krb5asrep$ hashes with impacket's GetNPUsers.py two ways -- unauthenticated against a username list (-usersfile ... -no-pass), and authenticated with -request to let it find every pre-auth-disabled account for you -- and reading the hash format
- cracking the exported hash offline with hashcat -m 18200 against rockyou.txt and measuring how fast a weak password falls (the BEFORE)
- the judgment: WHEN you reach for AS-REP roasting (early, even pre-credential, once you have usernames), WHY it works, when it does NOT apply, and how a pro enumerates users and stays quiet
- hardening for real: UN-tick pre-auth so the account requires it again (which stops THIS attack outright), set a long random password, prefer AES over RC4, and monitor events 4768/4769 -- then re-run the SAME request and crack to prove it no longer falls
- the honest negative that FLIPS from Kerberoasting: unlike Kerberoasting, you cannot AS-REP roast an account that requires pre-auth at all, so re-enabling pre-authentication is a real fix that closes the attack -- there is a setting here that works
Steps in this lab
- First: this is your lab, and AS-REP roasting is a real domain attack
- The words you need: pre-authentication, AS-REQ, AS-REP and the DONT_REQ_PREAUTH flag
- Why this needs no password but DOES need usernames — and how it differs from Kerberoasting
- Set up the target: a user with pre-auth DISABLED and a DELIBERATELY weak password
- Get usernames first — the enumeration AS-REP roasting depends on
- Request and export the AS-REPs with impacket GetNPUsers.py
- Crack it offline with hashcat -m 18200 — and measure how fast weak falls
- Fix and re-measure: RE-ENABLE pre-auth (the real off switch), strong password, AES, watch 4768/4769
- The honest positive, when to reach for it, and how a pro does it better