Ariovis

Active Directory attack path · Kerberos · MITRE ATT&CK T1558.004

AS-REP Roasting: when a Kerberos misconfiguration becomes an Active Directory attack path

AS-REP Roasting abuses one specific configuration: an Active Directory account that is not required to perform Kerberos pre-authentication. The domain controller can then return a Kerberos response containing data protected by the account secret, without the user having first proven that they know that secret.

An attacker can take that data away and attempt offline password cracking. The real question then becomes: what can this identity reach if the secret falls?

Back to the use case: secure Active Directory and reduce attack paths
MITRE ATT&CK
T1558.004
Tactic
Credential Access
Component
Kerberos / KDC
Condition
Kerberos pre-authentication disabled
AD object
userAccountControl
Flag
DONT_REQ_PREAUTH
Value
0x400000 / 4194304
Key Windows signal
Event ID 4768 · Pre-Authentication Type = 0

The attack path, step by step

Two different entry points lead to the same exploitable material. What happens next, however, depends entirely on what the identity actually allows inside the directory.

Branch A · Domain access

  1. 01Authenticated access to the domain
  2. 02Enumeration of directory accounts
  3. 03Identification of an account without pre-authentication

Branch B · Known user name

  1. 01Plausible or already known account name
  2. 02Targeted AS-REQ request for that identity

Convergence · Obtaining the secret

  1. 01Account carrying the DONT_REQ_PREAUTH flag
  2. 02AS-REQ without prior proof of the secret
  3. 03AS-REP response issued by the KDC
  4. 04Collection of the encrypted data
  5. 05Offline cracking attempt
  6. 06User secret recovered if the password is weak enough
Break: obtaining the secret ≠ reaching a critical resource

Real impact inside the directory

  1. 01Authentication with a valid account
  2. 02Exploration of groups, delegations and reachable resources
  3. 03Possible path towards a critical asset

The roast is not the whole path. The danger depends on what the compromised identity controls.

What Kerberos pre-authentication changes

In a standard Kerberos exchange, the client receives nothing exploitable before proving that it holds the account secret.

  1. 01The client prepares, among other things, proof encrypted with a key derived from its secret.
  2. 02The KDC verifies that the requester really holds that key.
  3. 03The KDC then issues the TGT if verification succeeds.

The point is simple: the KDC does not hand out, to any requester, the material needed for an offline cracking attempt.

With DONT_REQ_PREAUTH, that prior verification step disappears for the account concerned. The server can therefore return an AS-REP response without having obtained that proof first.

Part of the response contains data encrypted with a key derived from the account secret. Offensive security tooling can convert that data into a format suitable for testing password candidates offline.

People commonly say “AS-REP hash”. It is a useful operational shorthand between teams, but the AS-REP contains neither the password nor its hash as such.

DONT_REQ_PREAUTH: a single bit is enough to create the exposure

The exposure does not come from a software vulnerability but from an attribute on the account object in the directory.

Attribute
userAccountControl
Flag
DONT_REQ_PREAUTH
Hexadecimal
0x400000
Decimal
4194304
Meaning
the account is not required to present the expected Kerberos pre-authentication data.
  • historical compatibility with a third-party component;
  • older applications with limited Kerberos behaviour;
  • migrations and directory transitions;
  • temporary exceptions that were never removed;
  • inherited manual configuration, duplicated when copying an account.

Not every occurrence comes from a legacy system. An account can carry this flag because of a duplicated creation template, an administration script or a one-off decision that was never reassessed. The cause must be established account by account.

Kerberos is not the problem. The permanent exception is.

A roastable account is not necessarily critical. Its environment can be.

This is what separates an attack-path reading from a plain misconfiguration finding. An account exempted from pre-authentication can be many different things.

  • an ordinary user account;
  • a former application account;
  • a legacy service account;
  • an account indirectly holding sensitive group membership;
  • an identity controlling a resource that itself enables further progress.

The usual question

How many accounts are roastable?

The right question

What do these accounts allow someone to control?

Conceptual progression example

  1. 01User
  2. 02Member of an application group
  3. 03Group holding a delegation
  4. 04Write rights on a server
  5. 05Administrative session present
  6. 06Path towards a privileged identity

This is the control-relationship logic described by ANSSI in its security recommendations for Active Directory: an isolated weakness becomes critical when it lets an attacker progress towards trusted resources.

Prioritising an AD fix purely on the theoretical severity of the weakness misses part of the problem. What matters is the set of paths it opens or shortens.

AS-REP Roasting and Kerberoasting: two different phases of the same protocol

Both techniques aim to recover offline a secret protecting Kerberos data, but they target neither the same accounts nor the same exchange.

CriterionAS-REP RoastingKerberoasting
TargetAccounts that do not require Kerberos pre-authentication.Accounts associated with one or more services identified by an SPN.
Kerberos exchangeAS-REQ / AS-REP, at TGT request time.Service ticket request, TGS exchange.
Specific conditionDONT_REQ_PREAUTH flag set on the account.An exploitable SPN associated with the targeted account.
Secret attacked offlineYes: the attacker tries to recover the secret protecting the Kerberos data.Yes: same objective, from material tied to the service ticket.
Privileges requiredA domain account makes enumeration easier, but a plausible user name can be enough to test a request.An identity already authenticated in the domain is generally required.
ImpactDepends on the privileges and paths available to the identity whose secret is recovered.Same logic: impact is measured by the rights of the compromised account.
Compare with Kerberoasting

What the domain controller can show

Detection starts with domain controller logs, provided they are collected and interpreted together with the context of the identity involved.

Event ID 4768 — A Kerberos authentication ticket (TGT) was requested

  • The event is generated on domain controllers.
  • A Pre-Authentication Type of 0 means no pre-authentication was used.
  • Microsoft considers accounts configured this way to be a security risk.
  • A 4768 event with Pre-Authentication Type 0 is therefore a strong signal to analyse.
A 4768 event with PreAuthType 0 does not prove an attack. It shows an authentication without pre-authentication. You then have to determine whether the account, the source, the frequency and the context match legitimate usage.

What to look at in and around the event

  • TargetUserName
  • Client IP address
  • PreAuthType
  • Ticket encryption type
  • Request frequency
  • Number of distinct accounts queried
  • Subsequent behaviour of the identity
  • Event ID 4769 where relevant

Correlations recommended by MITRE

  • Event 4768 with Pre-Authentication Type 0;
  • subsequent service ticket activity, Event 4769;
  • possible use of RC4, etype 0x17;
  • abnormal enumeration of accounts configured without pre-authentication.

Microsoft changed the information available in event 4768 on Windows Server 2016 and later updated with the January 2025 security updates and beyond. A SIEM rule must therefore not blindly depend on a legacy parsing assumption: the format and available fields have to be verified on the estate actually deployed.

Detecting AS-REP Roasting is not just looking for an Event ID. It is connecting the Kerberos request to the identity, to its source and to what it does next.

The best AS-REP Roasting is the one with nothing to roast

Inventory comes before detection: know which accounts carry the flag, then understand what they would allow someone to reach.

Configuration control

Listing accounts whose DoesNotRequirePreAuth attribute is set is a simple, read-only control available through the Active Directory PowerShell module.

Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' -Properties DoesNotRequirePreAuth |
  Select-Object SamAccountName, Enabled, DoesNotRequirePreAuth

This command is an example of a point-in-time control, not exhaustive coverage of an Active Directory audit: it covers neither disabled accounts to review, nor other object classes, nor the other domains in the forest.

A script tells you which accounts carry the flag. It does not necessarily tell you which of them create the most critical attack path.

01

Inventory

List the accounts concerned and their enabled state.

02

Risk analysis

Qualify each account: real usage, owner, secret strength, dependencies.

03

Path mapping

Connect these accounts to the groups, delegations, ACLs and resources they can reach.

04

Prioritised remediation

Start with the accounts whose compromise most shortens a path to Tier 0.

Breaking the attack path

Remediation follows the order of effect: remove the exception where possible, understand why it existed, then reduce what the secret would grant.

  1. Priority 1

    Re-enable Kerberos pre-authentication

    Everywhere no technical dependency forbids it. The Microsoft cmdlet Set-ADAccountControl exposes the -DoesNotRequirePreAuth parameter; the defensive target is DoesNotRequirePreAuth = False. A bulk change in production should never be recommended without first qualifying possible legacy dependencies.

  2. Priority 2

    Identify why the exception existed

    Legacy application, migration, old technical account, configuration that became pointless: without that answer, the flag will reappear sooner or later.

  3. Priority 3

    Strengthen secrets for accounts that must keep the exception

    MITRE recommends in particular strong passwords and modern Kerberos encryption, AES rather than RC4 where possible. Strengthening the password or moving to AES reduces the cracking risk: it does not make keeping DONT_REQ_PREAUTH desirable.

  4. Priority 4

    Analyse the account's rights

    What the secret would actually grant can be read in the directory.

    • group memberships, direct and nested;
    • Kerberos and administrative delegations;
    • ACLs set on sensitive objects;
    • administrative rights on servers;
    • sensitive application access;
    • paths towards Tier 0.
  5. Priority 5

    Monitor any future re-enabling of the flag

    The fix must not be a one-off: an account created by copy, an operations script or an exception granted under pressure can recreate exactly the same risk.

Zero Standing Privileges limits the impact, not the roast

Removing standing privileges does not fix DONT_REQ_PREAUTH and does not prevent an AS-REP Roasting attempt.

However, if a compromised identity holds no permanent sensitive privilege and must obtain elevated capabilities in a controlled, time-bound way, the operational value of the stolen secret drops sharply.

Kerberos prevention and privilege reduction therefore act at two different points of the same attack path.

Least privilege: definition and operational limits

What an assessment should really look for

Detecting DONT_REQ_PREAUTH is relatively simple. Deciding what to fix first is much less so.

A useful Active Directory assessment connects account configuration with privileges, delegations, groups, reachable assets and paths towards sensitive resources.

The goal is therefore not simply to produce a list of misconfigurations, but to separate isolated weaknesses from genuinely exploitable paths and to build a prioritised remediation plan.

Ariovis helps identify, prioritise, fix and monitor the conditions that make this path exploitable. It is one contribution to your hardening roadmap, alongside your other internal controls.

  • Active Directory security audit;
  • privileged account analysis;
  • analysis of delegations, groups and sensitive rights;
  • review of identity-related attack paths;
  • hardening recommendations;
  • prioritised remediation plan;
  • monitoring and detection;
  • improved traceability;
  • support during remediation.
Discover the Identity and Active Directory security serviceAssess my Active DirectoryTest how exploitable my identity paths really are

Frequently asked questions

What is the difference between AS-REP Roasting and Kerberoasting?
AS-REP Roasting targets accounts for which Kerberos pre-authentication is not required: the KDC's AS-REP response then contains data protected by the account secret. Kerberoasting targets accounts associated with an SPN and relies on a service ticket request, on the TGS side. Both then attempt to recover a secret offline, but they abuse neither the same protocol phase nor the same bad practice.
Do you already need a compromised Active Directory account?
No, not necessarily. A known account name can be enough to test an AS-REQ request. Holding a domain account does, however, make LDAP enumeration of misconfigured accounts far easier, and therefore targeting too.
Does Event ID 4768 with PreAuthType 0 prove an attack?
No. It shows that a TGT request was processed without pre-authentication. The context, the source, the frequency and the identity's subsequent activity must be analysed before concluding.
Is a strong password enough?
It considerably raises the cost of offline cracking, but it does not fix the misconfiguration. Pre-authentication should be re-enabled wherever possible.
Does MFA block AS-REP Roasting?
MFA used on a separate application or access journey does not fix the account's Kerberos configuration in Active Directory. The primary treatment remains removing the pre-authentication exception; other controls can then reduce what the compromised secret can be used for.
Does AES remove the risk?
Modern encryption is preferable to RC4 and makes some attacks more expensive, but deliberately leaving pre-authentication disabled remains a weakness to address.

Sources and references

First-hand sources used for this technical page.

Go further

Ariovis content that directly extends this topic.

Discuss the attack paths in my directory