Key takeaways
- An account flagged not to require Kerberos pre-authentication will return an AS-REP whose encrypted part is derived from the account password, and that part cracks offline.
- The attack can run with no valid credential at all: a list of likely usernames sent to the domain controller is enough to collect hashes.
- Nothing on the domain sees a failed logon, because the guessing happens offline against the attacker's own hardware, not against the KDC.
- The fix is to remove the flag, enforce a password long enough to survive offline cracking, and alert on Kerberos TGT requests that carry no pre-authentication.
What Kerberos pre-authentication actually checks
When a user signs in with Kerberos, the client encrypts the current time with a key derived from the user's password and sends that inside the initial request, the AS-REQ. This field is PA-ENC-TIMESTAMP. The key distribution centre decrypts it, checks the timestamp is recent, and only then hands back a ticket. That single step is what stops a stranger asking for material that is tied to a password they do not hold.
An account can be told to skip it. The userAccountControl attribute carries a bit named DONT_REQ_PREAUTH, hex 0x400000, decimal 4194304. Set that bit and the domain controller will answer an AS-REQ for the account even though no proof of the password was offered. It usually gets set for legacy Unix and Kerberos interoperability, or for an old application that could not perform pre-authentication, and it is the kind of leftover an internal infrastructure pentest is there to find, because it tends to be set once and never reviewed.
Finding the accounts that skip it
With any authenticated domain account you can read userAccountControl over LDAP and filter for the flag directly. The bitwise matching rule 1.2.840.113556.1.4.803 lets you ask for exactly the accounts that carry it, so a single query returns your target list.
The dangerous path needs no account at all. Because the request itself demands no proof of identity, a list of likely usernames sent to the controller is enough: for each name that exists and carries the flag, you get a reply, and for the rest you get an error you can ignore. Impacket's GetNPUsers.py runs both modes. The username list can come from open sources or from an earlier foothold, such as the one described in our write-up of LLMNR poisoning and SMB relay.
# With any domain account: accounts flagged DONT_REQ_PREAUTH (0x400000)
(&(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=4194304))
# With no credential at all: try a username list against the KDC
GetNPUsers.py corp.example/ -no-pass -usersfile users.txt \
-dc-ip 10.0.0.10 -format hashcatThe reply is a crackable hash
It is worth being precise about what cracks, because the name is misleading. With pre-authentication disabled there is no encrypted timestamp in play at all, so nothing about a timestamp is recovered. What comes back is the AS-REP, and part of that reply is encrypted with a key derived from the account's password. By default the attacker asks for RC4 encryption, which is fast to test. That encrypted part is saved in the $krb5asrep$23$ format and cracked offline. MITRE catalogues the technique as T1558.004.
The guessing then happens on the attacker's own hardware, at whatever speed it can manage, with no further contact with the network. That is the quiet part: the domain controller logged one ordinary ticket request and never sees a wrong password tried. This offline character is why the technique shows up so often in an assumed breach exercise, where the operator starts inside and is looking for the cheapest path to a real credential.
[email protected]:9f2b...c41d$7a3e... (truncated)
$ hashcat -m 18200 asrep.hash rockyou.txt
...
[email protected]:...:Summer2023!
Session..........: hashcat
Status...........: Cracked
AS-REP roasting and Kerberoasting are not the same attack
Both attacks end in an offline crack and both abuse Kerberos, so they are easy to confuse. The trigger is what separates them. Kerberoasting needs a valid domain account to request a service ticket for a service principal name, and the crack recovers the service account's password. AS-REP roasting can need no credential, only an account left with pre-authentication disabled. If you have read our piece on Kerberoasting, the shape will be familiar: the difference is where the crackable material comes from, and whether you needed to be inside to get it.
The recovered password matters because weak requirements are what make the offline crack pay off. The underlying weakness is CWE-521, weak password requirements: a short or common password falls in a wordlist run, a long random one does not.
| AS-REP roasting | Kerberoasting | |
|---|---|---|
| Credential needed | Often none, a username list is enough | A valid domain account |
| What is misconfigured | DONT_REQ_PREAUTH on the account | A service principal name on the account |
| What cracks | The AS-REP encrypted part | The service ticket (TGS) encrypted part |
| hashcat mode | 18200 | 13100 |
| Primary fix | Remove the flag, strong password | Managed or strong service password, AES |
Where it sits in the kill chain
On the Unified Kill Chain, AS-REP roasting is an early credential-access move. It belongs in the In stage: reconnaissance finds a domain controller reachable on port 88, and the roast turns that into a password. It rarely needs anything before it, which is why it is often the first real credential an operator holds.
What that credential buys depends on the account. A forgotten service account with the flag can still hold rights across many hosts, so the password feeds privilege escalation and lateral movement in the Through stage. From there other AD weaknesses take over, such as the certificate-template path in our write-up of AD CS ESC1.
In
Reconnaissance
A domain controller reachable on port 88
Credential access
Roast a flagged account, crack it offline
Through
Privilege escalation
The account's standing rights
Lateral movement
Reuse the password across hosts
Out
Objective
Data reached, evidence collected, reported
Closing the gap
Four controls break the chain, in descending order of how completely they end it. Remove DONT_REQ_PREAUTH from every account that does not truly need it, which means auditing userAccountControl rather than trusting that nobody set it. Make the passwords long enough to survive an offline run, following the length-first guidance in NIST SP 800-63B. Prefer AES over RC4 so the encrypted part is slower to test. And alert on the one signal the attack cannot hide: a Kerberos TGT request, event 4768, that carries no pre-authentication.
The order matters because the first control removes the target and the last only catches the attempt. If you are deciding how much internal testing to buy to surface flags like this across a whole estate, our guide to buying an infrastructure pentest covers external against internal scope and depth.
| Control | What it does | Reference |
|---|---|---|
| Remove DONT_REQ_PREAUTH | No account answers an AS-REQ without pre-auth | userAccountControl audit |
| Strong password policy | A recovered hash does not crack in a useful window | NIST SP 800-63B, CWE-521 |
| Prefer AES over RC4 | The encrypted part is far slower to test offline | Kerberos configuration |
| Alert on 4768 with no pre-auth | The roast surfaces as a TGT request with pre-auth type 0 | SIEM detection rule |
What this means for Active Directory in the UAE
Almost every enterprise in Abu Dhabi and Dubai runs Active Directory, and a flagged account is the same latent risk whether the domain sits in a bank, a government supplier or a hospital group. The UAE regulators that name security testing all expect the internal weaknesses that lead to credential theft to be found and fixed, not just the perimeter. CBUAE-regulated banks, Dubai government entities and their suppliers under DESC, Abu Dhabi healthcare providers under ADHICS, and federal entities under the NESA-published Information Assurance Standards are each accountable for the state of their internal identity systems.
For a free-zone or mainland entity in either emirate, an AS-REP roastable account is exactly the kind of finding an internal test is expected to surface and evidence, because it turns a quiet configuration slip into domain credentials without tripping a single failed-logon alert. These flags accumulate over years of mergers, migrations and legacy integrations, so the practical control is a recurring internal review rather than a one-time clean-up, in both Abu Dhabi and Dubai.
Frequently asked questions
What is AS-REP roasting?
AS-REP roasting is a Kerberos credential-access attack against accounts that are flagged not to require pre-authentication. The domain controller answers an authentication request for such an account with an AS-REP whose encrypted part is derived from the account's password. That part is saved as a hash and cracked offline, recovering the password if it is weak.
How does AS-REP roasting differ from Kerberoasting?
Both end in an offline password crack, but the trigger differs. Kerberoasting needs a valid domain account to request a service ticket for a service principal name. AS-REP roasting can need no credential at all, only an account left with Kerberos pre-authentication disabled, and it recovers that account's own password rather than a service account's.
Do you need credentials to AS-REP roast an account?
Often not. Because the initial Kerberos request demands no proof of identity, a list of likely usernames sent to the domain controller is enough to collect hashes for any flagged account. Reading the flag over LDAP to build a precise target list does require an authenticated account, but the username-list path does not.
How do accounts end up without Kerberos pre-authentication?
The DONT_REQ_PREAUTH flag is usually set for legacy Unix or Kerberos interoperability, or for older applications that could not perform pre-authentication. It is also sometimes copied from an account template and forgotten. Because it is rarely reviewed after it is set, it tends to persist for years.
What is the DONT_REQ_PREAUTH flag?
It is a bit in the userAccountControl attribute of an Active Directory account, hex 0x400000 or decimal 4194304. When it is set, the domain controller will issue an AS-REP for the account without first verifying that the requester knows the password, which is the condition AS-REP roasting depends on.
Which hashcat mode cracks AS-REP hashes?
Mode 18200 cracks the RC4 form of the AS-REP hash, the $krb5asrep$23$ format that tools request by default. It is distinct from mode 13100, which cracks the RC4 service tickets recovered by Kerberoasting. Both run the same way: a wordlist or mask tested offline against the encrypted part.
How do you detect AS-REP roasting?
Watch for Kerberos TGT requests, Windows event 4768, that carry a pre-authentication type of 0, which means no pre-authentication was performed. A burst of these across several accounts, or any for accounts that should not be flagged, is the signal. The offline cracking that follows is invisible, so the request is the only chance to catch it.
How do you prevent AS-REP roasting?
Remove the DONT_REQ_PREAUTH flag from any account that does not strictly need it, and audit userAccountControl regularly rather than assuming it is clean. Enforce passwords long enough to survive offline cracking, prefer AES over RC4 encryption, and alert on TGT requests that carry no pre-authentication.
