AS-REP Roasting (T1558.004)

AS-REP roasting is an attack on Windows Active Directory accounts with Kerberos pre-authentication turned off. A domain controller will answer a request for such an account, even from someone who has not proven their identity. Part of that reply is protected by a key derived from the account's password. The attacker takes that part away and guesses passwords offline.

Explain It Like I'm 10

Picture a school where the teacher hands out a student's locked lunchbox only after the student proves who they are. A few names on the teacher's list are marked "no need to ask". So anyone can walk up, say one of those names and get that student's lunchbox.

They cannot open it, because the lock opens only with that student's own secret number. They carry it home and try numbers there, where nobody is watching. A short, easy number opens it quickly. A long, odd one may take far longer. If the teacher keeps a notebook, it shows only that a lunchbox was handed out.

How does Kerberos sign-in work, and what does pre-authentication add?

The normal sign-in

Active Directory is the directory that holds a Windows network's user accounts, including their names and passwords. A domain controller is a server that runs it. On each domain controller, a service called the Key Distribution Center (KDC) handles Kerberos, the protocol Windows domains use to verify the identity of a user or computer.

When a user signs in, their computer contacts the KDC to prove the user's identity and obtain a ticket-granting ticket (TGT). The TGT is a credential that lets the computer ask for access to services later without presenting the password again. This first exchange has two messages: the computer's request, called the AS-REQ, and the KDC's reply, called the AS-REP.

The AS-REP carries two separately protected parts:

• The TGT: its encrypted portion is protected by the key of the ticket-granting service, which issues tickets. In Active Directory that is normally the key of the krbtgt account, the built-in account the KDC uses to issue them.
• A separate encrypted portion for the client, the computer signing in: protected by the client's secret key, which for a user is derived from the user's password.

Only someone who knows the password should be able to open the client's portion.

What pre-authentication adds

Pre-authentication is an extra step in front of that reply. The computer's request carries a timestamp encrypted with a secret computed from the user's password, so the domain controller can check that the sender knows the password before it answers. MITRE puts the purpose this way: "Preauthentication offers protection against offline Password Cracking." It is turned on by default.

How does AS-REP roasting work?

What the attacker asks for and what comes back

The attack starts with an account that has pre-authentication turned off. In Active Directory this is an account option, and Microsoft describes it as meaning "This account doesn't require Kerberos pre-authentication for logging on."

An attacker sends the first request of a sign-in for that account but leaves out the encrypted timestamp, which is the proof. The domain controller cannot tell who is asking. The Kerberos specification, a standard published by the IETF, says the server "simply sends a reply without knowing or caring whether they are the same". For an ordinary account the outcome differs: the domain controller answers with an error saying that pre-authentication is required.

Why the reply can be guessed against

Handing out the reply is meant to be safe, because the portion meant for the account is locked with the account's own key, so only the account's owner should be able to use it. The weakness is that the attacker does not need to use it. They can take that portion away and test it. The specification warns that the reply gives an attacker scrambled data that can be used to attack the credentials "by guessing the user's password". The TGT in the same reply is protected by a different key, so guessing the user's password tests the client's portion and does not decrypt the TGT.

What offline guessing means

Offline guessing means trying candidate passwords one after another against data the attacker already holds, and keeping the one that opens the client's portion of the reply. The specification calls this an offline dictionary attack, where a dictionary is a long list of candidate passwords: "repeatedly attempting to decrypt, with successive entries from a dictionary". Because the attacker works on their own copy, the domain controller takes no part in any guess.

The attacker never needs the target's password to get the reply. That portion of the reply is what they use to test passwords. They do need to reach a domain controller and name an account that has the setting off.

Why would an account have pre-authentication turned off?

It is not a Windows oversight. MITRE's audit guidance says that pre-authentication is on by default and that, because older protocols might not support it, it is possible to have the setting disabled. A legacy system that cannot do pre-authentication is therefore one possible reason for an exception.

A first request without pre-authentication is not that reason by itself. Microsoft's documentation says MIT Kerberos clients do not request pre-authentication in their first request, so where it is required a domain controller replies with an error, one that often occurs in UNIX interoperability scenarios. Most of those clients respond by supplying pre-authentication, and the error can then be ignored, though some might not.

Microsoft's event guidance is direct about the risk: all accounts should use pre-authentication, except accounts configured with "Do not require Kerberos preauthentication," which it calls a security risk.

What decides whether the password can be recovered?

Three things matter here:

• The password itself: Kerberos never claimed to solve password guessing. The specification states: "If a user chooses a poor password, it is possible for an attacker to successfully mount an offline dictionary attack". The attack can only succeed if the real password is among the ones the attacker tries.
• The algorithm that protects the client's portion: MITRE says the data in the reply may be encrypted with an insecure algorithm such as RC4, an older algorithm that Windows keeps for compatibility. Microsoft says RC4 "is typically used in Windows environments when accounts or devices don't support stronger encryption types such as AES-SHA1" and that it "is now considered insecure and is being phased out". MITRE lists using AES rather than RC4, where possible, as a mitigation for this technique. AES raises the cost of each guess, because AES keys are derived from the password with a repeated computation that RFC 3962 says appears useful mainly as a multiplier of an attacker's brute-force work. It does not remove the weakness: with pre-authentication off, the reply is still handed out and can still be tested.
• Whether the account holds the stronger kind of key at all: Microsoft explains that a user account created before AES support, whose password was never reset after support was added, would be missing AES-SHA1 keys, and that changing the account password generates them. Without an AES key the older algorithm is not necessarily what is used. Microsoft notes that when RC4 is disabled, authentication might fail for some systems, so what happens depends on the encryption types the environment permits.

What does a recovered password lead to?

A recovered password is a working credential for a real account. MITRE says cracked passwords may enable persistence, privilege escalation and lateral movement through access to valid accounts: in plain terms, the attacker may use the account to keep access, gain wider rights and reach other systems. How far that goes depends on what the account is allowed to do.

A documented intrusion

The technique appears in documented intrusions. The DFIR Report's write-up of a ransomware intrusion that began in December 2023, published on 26 August 2024, records that roughly six hours into the intrusion the attackers "conducted AS-REP Roasting and Kerberoasting attacks against two of the domain controllers". The report calls AS-REP roasting "the first credential access activity performed by the threat actor". Ransomware was deployed fifteen days after the initial access.

The report does not state that any password was recovered, so what the intruders gained from these requests is not known. What the case shows is when and where the technique shows up: early, against domain controllers, in an intrusion that later reached ransomware.

Is AS-REP roasting really silent?

Partly. The guessing is invisible to the domain controller, but the request that comes first is an event it can record.

What the domain controller records

Event 4768 is generated "every time Key Distribution Center issues a Kerberos Ticket Granting Ticket (TGT)", and only on domain controllers. A failed issue appears as a failure, with a result code other than 0x0. A wrong password at the proof step is a different event, 4771, "Kerberos pre-authentication failed". A roast request carries no proof, so nothing fails at that step, and the domain controller issues the reply: it appears as a successful 4768.

That event also records which kind of proof the request carried. Microsoft's table distinguishes two cases that matter here:

• Type 2: "a normal type for standard password authentication".
• Type 0: "Logon without Pre-Authentication".

Microsoft's monitoring advice for type 0 is the same as the warning above: only accounts deliberately configured without pre-authentication should show it. A successful request with type 0 is therefore the signal to start from. It calls for investigation in context (is the account meant to have the setting off, and who asked?), not a conclusion that a password was cracked. In the intrusion above, the report's own detection note points the same way: "Indications of AS-REP roasting can be found by looking for windows eventID 4768 on the target domain controller."

Changing the setting is also recorded. Event 4738 is generated every time a user object is changed, and Microsoft's monitoring table flags "Don't Require Preauth" being enabled as something that "Should not be enabled for user accounts because it weakens security".

What the ticket encryption type field shows

Microsoft defines Ticket Encryption Type as the suite used for the issued TGT. The specification protects the TGT and the client's portion separately, so the field does not necessarily show how the portion being guessed against was protected. An AES value there does not rule out roasting, and RC4 there is not required for it. MITRE's detection strategy also watches for RC4, and that is context, not a verdict.

Where detection stops

Detection has limits:

• Auditing must be on: the event exists only if the domain controller audits Kerberos Authentication Service requests. Microsoft recommends success auditing and says the expected volume on domain controllers is high.
• The request is not the guess: the event shows that an account without pre-authentication was asked for. Nothing in that event tells whether anyone is guessing, or whether a guess succeeded.

So "silent" is true of the guessing and not of the request.

How is AS-REP roasting different from Kerberoasting?

Kerberoasting is a sibling technique. MITRE files both under Steal or Forge Kerberos Tickets, as sub-techniques T1558.003 and T1558.004, in the tactic Credential Access. They differ in which step of Kerberos they start from.

After sign-in, the computer presents its TGT to the KDC and asks for a service ticket, which it then presents to the service it wants to use. Kerberoasting targets that second step.

What reduces the exposure, and where does each control stop?

Each control removes something from the attacker's path, and each has a limit.

• Keep pre-authentication on, and audit the setting: MITRE's audit mitigation is to make sure all accounts have pre-authentication whenever possible and to audit changes to the setting, and it notes that standard Windows administration tools can list the accounts that have it off. This removes the reply to an unproven request. The limit is the legacy case above: where an older system cannot support pre-authentication, the account stays exposed to the guessing described earlier.
• Make passwords hard to guess: MITRE's password mitigation suggests long, complex passwords, ideally 25 or more characters, that expire periodically, and it names accounts that run services in particular. The limit is that this does not stop the reply being handed out. It only makes the real password less likely to be among the guesses.
• Use AES rather than RC4 where possible: this protects the client's portion of the reply with a stronger algorithm, which raises the cost of each guess. It has two limits: it does not stop the reply being handed out when pre-authentication is off, so a weak password can still be found; and it needs AES keys, which an old account whose password was never changed since AES support arrived lacks until the password is changed.
• Use Kerberos armoring: pre-authentication alone leaves a gap. The specification states that "Even with pre-authentication, attackers may try brute force or dictionary attacks against credentials that are observed by eavesdropping on the network". Armoring, defined in the Kerberos pre-authentication framework (RFC 6113), "provides a tool to significantly reduce vulnerability to offline dictionary attacks". Microsoft says armoring fully encrypts Kerberos messages and signs Kerberos errors, which leaves an eavesdropper less to test guesses against. The limits are cost and compatibility: armoring increases processing time, and when a domain controller is set to fail unarmored requests, client computers that do not support armoring cannot authenticate.

No single control covers every case, so detection of the request still matters.

For wider guidance, agencies from the United States, the United Kingdom, Canada, Australia and New Zealand publish a joint guide to mitigating prevalent Active Directory compromises. The Canadian Cyber Centre's page lists AS-REP roasting among the compromises it covers, and CISA's page shows a revision date of 15 September 2026.