Kerberoasting

Also calledKerberoast, SPN roasting

Asks for service tickets, then guesses the service account's password offline.

Needs
Domain Account
Gives
PasswordandService Key

How the Attack Works

Any domain account may ask for a service ticket to any service principal name, and the DC seals the ticket with the key of the account that holds the SPN, without checking that the requester may use the service. Where that is a user account with a password a person chose, the sealed part can be guessed offline, away from every log. In RC4 that key is simply the account's NT hash, quicker to guess against than an AES key, so requests for RC4 tickets are the classic sign.

Read first Password Hashes and Kerberos Keys, Kerberos Keys and Encryption Types, TGS Reply: The Service Ticket

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 ws-042, running as its computer account, asks dc-01 for service tickets it never uses.Step through it

ws-042 Foothold

  • TGT
  • TGT session key

dc-01 Domain controller

  • krbtgt key
  • svc-backup key

Offline

  1. Step 1 of 4, SPN Search, ws-042 to dc-01
  2. Step 2 of 4, TGS Requests, ws-042 to dc-01
  3. Step 3 of 4, Service Tickets, dc-01 to ws-042
  4. Step 4 of 4, Offline Guessing, on Offline

  1. Step 1 of 4: SPN Search

    ws-042 Foothold to dc-01 Domain controller

    Search for accounts with an SPN LDAP SearchRequest LDAP, port 389

    WS-042$ asks dc-01 over LDAP for the user accounts that have a service principal name, a search any account may make.

    What Defenders See

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

  2. Step 2 of 4: TGS Requests

    ws-042 Foothold to dc-01 Domain controller

    Requests for service tickets KRB_TGS_REQ Kerberos, port 88

    WS-042$ sends its own TGT and asks for a ticket to each SPN found, svc-backup's among them, offering only RC4.

    What Defenders See

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

    Hooks into Kerberos TGS Request

  3. Step 3 of 4: Service Tickets

    dc-01 Domain controller to ws-042 Foothold

    Replies with the service tickets KRB_TGS_REP Kerberos, port 88

    dc-01 issues each ticket as it would for anyone, sealed with the key of the account that holds the SPN.

    Keys and Tickets

    • ws-042 now holds service ticket (new at this step) service session key (new at this step)

    What Defenders See

    The Security log on dc-01 shows event 4769 for svc-backup with Ticket Encryption Type 0x17, though its Available Keys include AES, among many SPNs asked for by WS-042$.

    Hooks into Kerberos TGS Reply

  4. Step 4 of 4: Offline Guessing

    Offline, away from the network

    The part of svc-backup's ticket sealed with its key is guessed against offline. A guess that opens it is the password.

    Keys

    • Offline now holds svc-backup 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 AccountAny domain account, or code running as SYSTEM on a domain-joined machine.

Comes From

Gives the Attacker

What running it hands the attacker to use next.

  • A PasswordThe service account's password, and with it whatever that account can reach.
  • A Service's KeyThe service account's keys, which seal every ticket to its services.

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
4769 A Kerberos service ticket was requested (opens in a new tab) Security logDomain controllersTicket Encryption Type 0x17 for a user account whose Available Keys include AES, or one account asking for many SPNs at once.TGS Reply: The Service Ticket explains how to read it.Audit Kerberos Service Ticket Operations
201 to 209 The Key Distribution Center detected <Cipher Name> usage that will be unsupported in enforcement phase (opens in a new tab) System logDomain controllersSince April 2026, 203 marks a refused request offering only RC4 to an account with no encryption types set, though svc-backup, set to allow RC4, raises none.Domain controllers with the January 2026 or later updates (KB5073381)

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.

4769 A Kerberos service ticket was requested

In the Security log on dc-01,

WS-042$ asks for a ticket to svc-backup's service at 22:03 on 14 Oct, five minutes after PowerShell ran on ws-042.

  • The requester, ws-042's computer account, the identity SYSTEM and network services use there. A workstation asking for a user account's service ticket is unusual.

    As Windows writes it: Account Name WS-042$@CORP.EXAMPLE

  • The account that holds the SPN backup/srv-fin-01.corp.example, a user account whose password a person set, and whose key seals this ticket.

    As Windows writes it: Service Name svc-backup

  • ws-042, the foothold. BAM there shows PowerShell last ran at 21:58.

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

  • RC4, so the ticket is sealed with svc-backup's NT hash, the quickest form to guess against.

    As Windows writes it: Ticket Encryption Type 0x17

  • AES keys exist, so the ticket could have been AES. RC4 means the request asked for it and svc-backup still allows it.

    As Windows writes it: Available Keys AES-SHA1, RC4

  • The ticket was issued.

    As Windows writes it: Failure Code 0x0

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.

  • The guessing happens offline, so nothing is logged while the password falls, and a request in AES leaves no RC4 sign at all.
  • Volume alone misses a quiet Kerberoast, so alert on RC4 tickets, decoy SPNs and SPN searches too.

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 or searches that fit Kerberoasting, not that a password fell, and each ticket's encryption type is only in 4769, which this table does not hold.

KQLDefender XDR, Advanced hunting
// Kerberoasting and SPN search alerts from Defender for Identity, with the accounts, devices and addresses involvedAlertEvidence| where Timestamp > ago(30d)| where Title has "Kerberoasting" or Title in~ ("Suspected Kerberos SPN exposure", "Suspicious Kerberos SPN request", "Possible SPN enumeration via LDAP", "Possible SPN enumeration via ADWS")| 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.

Sources