AS-REP Roasting

Also calledAS-REP roast, DONT_REQ_PREAUTH, Pre-authentication not required

Asks for a TGT for an account that skips pre-authentication, then guesses offline.

Needs
Domain AccountorNetwork
Gives
Password

How the Attack Works

Pre-authentication makes a client prove it knows the password, with a timestamp sealed with its key, before the DC answers. An account set not to require it (DONT_REQ_PREAUTH in its userAccountControl) is answered for anyone who asks, and part of that answer is sealed with the account's own key. That part can be guessed offline like a Kerberoasted ticket, and no failed sign-in is ever logged.

Read first Kerberos Keys and Encryption Types, AS Request and Pre-Authentication, AS Reply: The TGT

How It Plays Out

The attack step by step. Each step shows which machines take part, what travels, the keys and tickets each side now holds, what is logged and what a defender can see.

A foothold on srv-app-01, the web app server, asks dc-01 for a TGT for dana, whose account was set not to require pre-authentication.Step through it

srv-app-01 Foothold

dc-01 Domain controller

  • dana's key
  • krbtgt key

Offline

  1. Step 1 of 4, Account Search, srv-app-01 to dc-01
  2. Step 2 of 4, AS Request, No Proof, srv-app-01 to dc-01
  3. Step 3 of 4, AS Reply, dc-01 to srv-app-01
  4. Step 4 of 4, Offline Guessing, on Offline

  1. Step 1 of 4: Account Search

    srv-app-01 Foothold to dc-01 Domain controller

    Search for accounts that skip the proof LDAP SearchRequest LDAP, port 389

    SRV-APP-01$ asks dc-01 over LDAP for the accounts whose userAccountControl has DONT_REQ_PREAUTH set.

    What Defenders See

    Where its sensor reads dc-01, Defender for Identity raises its LDAP reconnaissance alerts. By default, dc-01 writes no event for the search to its Security log.

  2. Step 2 of 4: AS Request, No Proof

    srv-app-01 Foothold to dc-01 Domain controller

    Request for a TGT with no proof KRB_AS_REQ Kerberos, port 88

    srv-app-01 asks dc-01 for a TGT for dana with no pre-authentication timestamp, offering only RC4.

    What Defenders See

    Nothing shows yet, because dc-01 writes the request to its Security log as event 4768 when it answers it.

    Hooks into Kerberos AS Request

  3. Step 3 of 4: AS Reply

    dc-01 Domain controller to srv-app-01 Foothold

    Reply with the TGT KRB_AS_REP Kerberos, port 88

    dc-01 answers as dana's account allows, with a TGT and a part sealed with dana's key that holds its session key.

    What Defenders See

    The Security log on dc-01 shows event 4768 for dana with Pre-Authentication Type 0 and only RC4 in the advertised encryption types. The request came from 192.0.2.25, where she never signs in.

    Hooks into Kerberos AS Reply

  4. Step 4 of 4: Offline Guessing

    Offline, away from the network

    The part sealed with dana's key is guessed against offline. A guess that opens it is her password.

    Keys

    • Offline now holds dana's key (new at this step)

    What Defenders See

    No log on any machine in the domain records this step, because it happens offline.

Needs First

What the attacker must already hold for this attack to be possible.

  • A Domain Account or Network AccessA domain account to find exposed accounts, or, with a name already known, network access alone.

Comes From

Gives the Attacker

What running it hands the attacker to use next.

  • A PasswordThe exposed account's password, and with it whatever that account can reach.

Leads To

What Defenders See

What this attack leaves for a defender to find, and what to read in each. None of it is proof on its own, so treat each as a lead and confirm it against the rest.

Event and LogWritten OnLook ForSwitch It On
4768 A Kerberos authentication ticket (TGT) was requested (opens in a new tab) Security logDomain controllersPre-Authentication Type 0, only RC4 in the advertised encryption types, from an address that does not normally use the account.AS Reply: The TGT explains how to read it.Audit Kerberos Authentication Service
4738 A user account was changed (opens in a new tab) Security logDomain controllers for domain accounts, the computer itself for local ones'Don't Require Preauth' enabled, showing when, and by whom, an account was opened up, an exposure to fix first.Audit User Account Management

What It Looks Like

One event from the worked example, decoded field by field, so you can see what to read in it and what each value means.

4768 A Kerberos authentication ticket (TGT) was requested

In the Security log on dc-01,

A TGT for dana, issued with no proof of her password, to a machine she never signs in from.

  • The exposed account, which someone set not to require pre-authentication.

    As Windows writes it: Account Name dana

  • srv-app-01, a machine dana never signs in from.

    As Windows writes it: Client Address ::ffff:192.0.2.25

  • The DC answered, so a TGT, and a part sealed with dana's key, went back.

    As Windows writes it: Result Code 0x0

  • Logon without pre-authentication. No proof of her password was asked for, because her account does not require it.

    As Windows writes it: Pre-Authentication Type 0

  • The TGT's own type, sealed with the krbtgt key, which the request does not choose. Read Session Encryption Type instead.

    As Windows writes it: Ticket Encryption Type 0x12

  • RC4, the only type the request offered, so the part sealed with dana's key is RC4 as well.

    As Windows writes it: Session Encryption Type 0x17

Defender for Identity Alerts

Where Defender for Identity runs, its sensors raise these from what they read on the servers they are installed on, domain controllers above all. Each names what it flags, which is a lead to confirm, not proof on its own.

Blind Spots

Where this attack leaves little or nothing to see, so a quiet log is not read as an all-clear.

  • No failed sign-in is logged, because the DC answers without asking for proof, so 4768 with type 0 is the only Kerberos trace.
  • Any account that legitimately has pre-authentication off writes the same 4768, so fix the setting rather than tune the alert.

Look for It on a Machine

The Registry keys on an endpoint that hold a trace of this, each opening its own page.

Hunt It

The query to run in each tool, and how well each one sees this attack. Pick the tool you use, and the others load their query when you open them.

Sees It DirectlyAlertEvidence (documentation, opens in a new tab)

Needs Defender for Identity sensors on every DC. An alert shows requests that fit AS-REP roasting, not that a password fell. The posture assessment for unsecure account attributes lists the exposed accounts before anyone asks.

KQLDefender XDR, Advanced hunting
// AS-REP roasting alerts from Defender for Identity, with the accounts and addresses involvedAlertEvidence| where Timestamp > ago(30d)| where Title in~ ("AS-REP roasting", "Possible AS-REP roasting attack", "Suspected AS-REP Roasting attack")| project Timestamp, Title, EntityType, EvidenceRole, AccountName, DeviceName, RemoteIP| order by Timestamp desc

How to Prevent It

The controls that break this attack, each with how it helps here and, where the Registry topic has it, where to check it on a machine.

Attacks tied to this one that its needs and gives do not already name, such as another form of it or its reverse, each with how the two connect.

  • Kerberoasting

    The same offline guessing, against service tickets to accounts that hold an SPN.

  • Active Directory Reconnaissance

    The directory search that usually comes first, listing the accounts that do not require pre-authentication.

Sources