AS-REP Roasting (T1558.004)

AS-REP roasting is a Kerberos attack against Active Directory accounts configured with "Do not require Kerberos preauthentication". Because the account is exempt, a domain controller returns an AS-REP containing material encrypted with the account's own key, which an attacker cracks offline. MITRE ATT&CK tracks it as T1558.004, under Credential Access.

Search for this technique and you will meet two statements on the same screen. The first says the attack is silent, generating no failed logons on the domain controller. The second tells you to watch Event ID `4768` for a pre-authentication type of `0`. Only one of those can be the whole story.

This page resolves that. It covers what the exchange actually produces, what has to be switched on before any of it reaches your logs, and why the single indicator most guidance recommends is tied to a Windows default that Microsoft has been retiring through 2026. MITRE's entry for T1558.004 is at version 1.2, last modified 24 October 2025, and its tactic is Credential Access.

Explain It Like I'm 10

Think of a doorman who normally asks you to prove who you are before handing you a pass for the building. A few names on his list are marked "let this one through without asking". Someone can walk up, give one of those names, and get an envelope back. They cannot open it, because only that person's key fits. So they take the envelope home and spend the week trying keys on it, where the doorman cannot see them. That is roughly the shape of the attack.

How the request and the reply actually work

Kerberos pre-authentication exists to stop exactly this. MITRE's own description is direct: "Preauthentication offers protection against offline Password Cracking." In the normal flow, a client sends an Authentication Server Request, or AS-REQ, carrying a timestamp encrypted with the hash of the user's password. The domain controller issues the Authentication Server Response, the AS-REP, only if it can decrypt that timestamp.

Set the exempt flag and the first half of that exchange disappears. The AS-REQ arrives without the encrypted timestamp, and the domain controller answers anyway, returning an AS-REP whose ticket data, in MITRE's wording, "may be encrypted with an insecure algorithm such as RC4". Nothing is broken. The directory is doing what it was configured to do.

That is also where the attacker's real prerequisite sits, and most explainers overstate it. The request itself carries no credential, but it needs a valid account name to ask about. MITRE notes that listing the eligible accounts cheaply requires an account registered to the domain; without one, the attacker is working from names obtained some other way.

Why the setting exists at all

The flag is not an oversight, and an administrator who has it set is usually inheriting a decision rather than making a mistake. MITRE's audit mitigation states that "Kerberos preauthentication is enabled by default" and that "older protocols might not support preauthentication". Microsoft is more specific. In its documentation of result code `0x19`, `KDC_ERR_PREAUTH_REQUIRED`, it explains that the error "often occurs in UNIX interoperability scenarios. MIT-Kerberos clients do not request pre-authentication when they send a KRB_AS_REQ message."

Two primaries, one reason. On the account object the setting appears as the userAccountControl bit `DONT_REQ_PREAUTH`, hexadecimal `0x400000`, which Microsoft's protocol specification defines as meaning the account "is not required to present valid preauthentication data".

Does AS-REP roasting really leave no trace?

This claim shapes how teams triage the finding, so it is the one to check. Google's AI Overview states that the attack "generates zero failed login logs on the domain controllers", and the third organic result is titled "How AS-REP Roasting Steals Passwords Without a Trace".

The first statement is true. The second does not survive contact with Microsoft's own event documentation.

Event 4768 "generates every time Key Distribution Center issues a Kerberos Ticket Granting Ticket (TGT)", and it "generates only on domain controllers". Microsoft adds that "if TGT issue fails then you will see Failure event with Result Code field not equal to `0x0`". Read those together and the correction writes itself. A roast is not a failed logon, because nothing failed. The attacker asked a question the directory is configured to answer, and the domain controller answered it. The event is recorded as a success.

So the split is not between visible and invisible. It is between two halves of the attack:

• The request is recorded. Every AS-REP issued for one of these exempt accounts produces an event with the pre-authentication type field set to `0`, which Microsoft's own table defines as "Logon without Pre-Authentication".
• The cracking is not. It happens on hardware you do not own, against a file you cannot see, with no clock and no event anywhere in your estate.

The prerequisite nobody states

None of that reaches your logs by itself. Those events come from the Audit Kerberos Authentication Service subcategory, which "determines whether to generate audit events for Kerberos authentication ticket-granting ticket (TGT) requests", and Microsoft's recommendation for domain controllers is Success auditing, with the honest note attached: "Event volume: High on Kerberos Key Distribution Center servers."

A team auditing only Failure for this subcategory will see nothing at all, and a team hunting failed authentications for evidence of AS-REP roasting is hunting in the wrong stream.

How to detect AS-REP roasting

MITRE publishes a detection strategy for this technique, `DET0113`, with a single analytic, `AN0316`. Read it for what it actually observes, because that is not always a given: here the analytic watches the layer the attack happens on. It describes monitoring "Kerberos AS-REQ/AS-REP authentication patterns where preauthentication is disabled (Event ID 4768 with Pre-Auth Type 0)", correlating those requests with service ticket activity in Event ID `4769`, and flagging "requests using weak RC4 encryption (etype 0x17)".

Nothing on the first page of either major search engine names that strategy or that analytic.

The flag is not only inherited

That last row is the one most guidance omits, and it changes the shape of the problem. This is not purely a legacy misconfiguration you clean up once. Event 4738 fires whenever a user object changes, and Microsoft lists the pre-authentication flag among the account modifications worth monitoring. Elastic's published detection rule states the adversary case directly: an attacker "with GenericWrite/GenericAll rights over the account can maliciously modify these settings to perform offline password cracking attacks such as AS-REP roasting".

One more idea deserves credit rather than a footnote. Netwrix's guide suggests decoy accounts with the flag deliberately set, monitored for AS-REP requests. It works because nothing legitimate should ever ask for them. Give such an account a long random password, no privileges and no group memberships, and its only function is to be asked about.

Check what your rules are reading

Since the cumulative update of 14 January 2025, Event `4768` on Windows Server 2016 and later carries additional fields, including the account's supported encryption types and its available keys. A rule written before that date is parsing a smaller event than the one your domain controllers are logging now.

The indicator everybody recommends is being retired

Ask the field how to spot this with high confidence and the answer is encryption type `0x17`. Semperis, the most detailed competitor on the term, recommends exactly that combination, and Bing's generated answer repeats it.

That indicator is losing its edge, on a published schedule.

• 8 November 2022: in response to CVE-2022-37966, Windows updates changed the default Kerberos encryption type "to use Advanced Encryption Standard (AES)-SHA1 instead of RC4 for accounts where an encryption type wasn't explicitly set".
• Windows Server 2025: domain controllers "don't issue RC4 Ticket Granting Tickets".
• 14 April 2026: updates change the KDC default for `DefaultDomainSupportedEncTypes` to "AES-SHA1 only: `0x18`".
• July 2026: Windows updates "programmatically enable Enforcement Phase", and audit mode is removed.

The 2026 phases sit under CVE-2026-20833, which Microsoft is addressing as a phased rollout rather than a single patch: an initial deployment phase from January 2026, then enforcement.

NVD records it as CWE-327, base score 5.5, vector `AV:L`, described as allowing "an authorized attacker to disclose information locally". That is not a remote unauthenticated flaw, and it should not be described as one.

Nothing you have built has stopped working

The scope of that change matters as much as the dates. Microsoft's change alters the assumed supported encryption types for accounts that have no explicit `msDS-SupportedEncryptionTypes` value, and the rollout document frames it around service account ticket issuance. It does not end AS-REP roasting, and it does not convert every reply to AES.

For detection, the practical read is narrow. A rule keyed on pre-authentication type `0` is unaffected, because that field describes the account's configuration, not its cryptography. What decays is the confidence weight of the RC4 clause: as an estate moves to AES, `0x17` appears less often, so its absence stops being evidence that nothing happened. Treat that as a forward-looking inference from Microsoft's published schedule rather than a measured observation, and re-check the assumption in your own environment.

What decides whether a captured AS-REP matters

Two variables separate a finding from an incident, and both are checkable this afternoon.

Variable one: the encryption type

`msDS-SupportedEncryptionTypes` is the Active Directory attribute that "denotes the encryption types the account supports", and where it is not defined the KDC falls back to the domain default. MITRE's mitigation for this technique is to "enable AES Kerberos encryption (or another stronger encryption algorithm), rather than RC4, where possible", which is the same lever expressed as a control.

An uncomfortable interaction sits behind that number, and it is inference rather than fact. Microsoft documents that AES keys "are generated during password sets and password changes", and are available where the domain functional level is 2008 or greater "and accounts have had at least one password rotation". The accounts most likely to carry a legacy interoperability flag are often the accounts least likely to have rotated a password since it was set. Verify it per account rather than assuming it.

Variable two: the password

MITRE's guidance is specific: "Ensure strong password length (ideally 25+ characters) and complexity for service accounts and that these passwords periodically expire", and it points to Group Managed Service Accounts as the better answer where they fit.

Neither variable makes the account safe. Both change the cost of the offline half, which is the only half you cannot observe.

Is enabling pre-authentication enough?

The standard advice is right, and it is much older than the tooling. RFC 4120, the Kerberos V5 specification published in July 2005, describes this attack in its security considerations. Without required pre-authentication, it says, "the availability of the response encrypted in the client's secret key provides the attacker with ciphertext that may be used to mount brute force or dictionary attacks to decrypt the credentials, by guessing the user's password". Its conclusion is the advice the explainers repeat: "it is strongly encouraged that Kerberos realms require the use of pre-authentication."

Then comes the next sentence, which nobody quotes:

"Even with pre-authentication, attackers may try brute force or dictionary attacks against credentials that are observed by eavesdropping on the network."

The 2011 follow-up is blunter still. RFC 6113, co-authored by a Microsoft engineer, grades encrypted-timestamp pre-authentication as a mechanism that "ameliorates the situation somewhat by requiring that an attacker observe a successful authentication", and then defines what it considers the stronger answer: Kerberos FAST, which "provides a tool to significantly reduce vulnerability to offline dictionary attacks".

FAST, armoring, and what it costs

Windows implements FAST as Kerberos armoring, and it is already in your event schema. Pre-authentication type `138`, `PA-ENCRYPTED-CHALLENGE`, is defined by Microsoft as "logon using Kerberos Armoring (FAST)", and its 4768 monitoring guidance already tells administrators to watch for values other than `138` where armoring is meant to be universal.

The strict setting has teeth and a bill. In the KDC policy, the option "Fail unarmored authentication requests" causes the domain controller to reject "unarmored Kerberos messages". Three costs come with it, all documented by Microsoft in the same place:

• Unarmored clients stop working. "Client computers which don't support Kerberos armoring will fail to authenticate to the domain controller."
• The strict options need Windows Server 2012 domain functional level. Below that, domain controllers behave as though the permissive option were selected.
• Both ends must be configured, and it is not free. The client-side policy has to be enabled too, and armoring adds processing on the domain controller.

An AS-REQ that must be armored is an AS-REQ an unarmored requester cannot make. That reading follows from Microsoft's wording rather than from a Microsoft claim about this technique, and it is not a switch to flip on a Friday. It is the control to evaluate when the standard fix has already been applied and the exposure remains.

AS-REP roasting vs kerberoasting

Both appear in the same reports and both end in offline cracking, so they get conflated constantly. They differ on three axes.

The family resemblance is real: both are sub-techniques of T1558, both sit under Credential Access, and MITRE revised both pages on the same day, 24 October 2025. But the entry conditions are different enough that covering one says nothing about your coverage of the other. Kerberoasting deserves its own page, and it will get one.

What we do not know

Two gaps matter here, and the confident pages on this term name neither.

There is no published prevalence figure. No measured share of directories carrying at least one account with pre-authentication disabled exists in citable form, with a sample size and a method attached. Anyone quoting one is quoting a vendor's impression. If your risk narrative needs a number, use your own count from your own audit.

There is a government primary this article does not draw on. Six agencies, led by the Australian Signals Directorate and including CISA and the NSA, published "Detecting and Mitigating Active Directory Compromises" on 25 September 2024, covering "the 17 most common techniques used by adversaries and malicious actors to compromise Active Directory". The document itself was not retrievable from where this research was carried out, so nothing here is taken from it. Read it directly.

The detection limits stated above belong in the same list: the audit subcategory has to be recording Success, the RC4 clause weakens as estates move to AES, and the offline half of the attack is unobservable by design.

Frequently asked questions

Is AS-REP roasting the same as password spraying? No. Password spraying tests guesses against the directory, which produces failed authentications and can trigger lockouts. Here nothing is guessed against the directory at all. The single request succeeds, and every guess after that happens offline, against captured material, where no policy applies.

Does the attacker need to be inside the network? They need to reach a domain controller and know a valid account name. The AS-REQ itself carries no credential, which is what makes the technique cheap, but enumerating eligible accounts efficiently does require an account in the domain.

If I only have historical logs, can I check whether this already happened? Yes, if Success auditing was enabled for the Kerberos authentication service at the time. Look for `4768` events with pre-authentication type `0`, particularly clusters covering several accounts from one source. If the subcategory was not auditing Success, the evidence was never written.

Can I just delete the accounts that have the flag set? Sometimes, but find out why the flag is there first. It is often set for interoperability with clients that do not send pre-authentication, so the sequence is audit, ask why, then decide. Removing the flag is the goal; removing it blindly is how a working integration breaks.

Does moving to AES fix this? It raises the cost of the offline half considerably, which is worth doing. It does not stop the domain controller issuing the reply, and it does not remove the exemption. The account is still answering questions from anyone who knows its name.

What to check this week

Four checks, in order, each drawn from the sources above rather than from general advice.

1. Audit the directory for accounts with pre-authentication disabled. MITRE's own mitigation notes that standard Windows tooling finds them, and the attribute to look for is `DONT_REQ_PREAUTH`.
2. Confirm the audit subcategory is recording Success, not Failure alone, on the domain controllers. Without it, the rest of this page is theory.
3. On accounts that must keep the flag, check `msDS-SupportedEncryptionTypes` and the password position, including whether a Group Managed Service Account can replace a static one.
4. Alert on the flag being switched on, using Event `4738`, so a manufactured target announces itself.

For accounts that genuinely cannot change, the remaining controls are the ones this page has sourced: the encryption type, the password or a managed account, armoring where it fits, and monitoring. It is a short list, which is precisely why the severity question deserves an answer rather than a checkbox. The protocol's own designers wrote the risk down in 2005 and named a stronger answer in 2011. Two decades later, the least you can do is know which half of the attack your logs would have caught.