Kerberoasting has been a staple of Active Directory attack chains since Tim Medin demonstrated it at DerbyCon 2014. Twelve years later, it remains one of the most reliable offline credential attacks in use — because service accounts with weak passwords and SPNs still exist in almost every enterprise AD environment, and the TGS ticket request that enables the attack is a legitimate, logged Kerberos operation. The challenge is distinguishing malicious enumeration from the noise of normal authentication.
This guide covers both Kerberoasting (T1558.003) and its companion technique AS-REP Roasting (T1558.004), with detection logic you can deploy today.
Kerberoasting: The Attack Chain
When an attacker requests a Kerberos service ticket for an account with a Service Principal Name (SPN), the Domain Controller returns a ticket encrypted with the service account’s NTLM hash. That ticket can be taken offline and cracked without any further interaction with the DC.
The full chain:
- Attacker enumerates accounts with SPNs (common:
GetUserSPNs.py, PowerView’sGet-DomainUser -SPN, or direct LDAP query) - Requests TGS tickets for each SPN-bearing account
- Extracts the encrypted ticket portion
- Runs offline cracking (Hashcat mode 13100) against a wordlist
What Windows logs: Event ID 4769 (Kerberos Service Ticket Operations) with Ticket Encryption Type: 0x17 (RC4-HMAC). AES-encrypted tickets (0x12) are rarely targeted because they’re computationally harder to crack.
Kerberoasting Sigma Rule
title: Kerberoasting Activity - RC4 TGS Requests
id: 8c9f2e4b-1a3d-4f8c-b7e6-2d5a9c0f1b3e
status: experimental
description: Detects potential Kerberoasting via multiple RC4-HMAC TGS requests from a single source
references:
- https://attack.mitre.org/techniques/T1558/003/
author: SOC Analyst Hub
date: 2026/05/23
tags:
- attack.credential_access
- attack.t1558.003
logsource:
product: windows
service: security
detection:
selection:
EventID: 4769
TicketEncryptionType: '0x17'
ServiceName|endswith:
- '$'
filter_computer_accounts:
ServiceName|endswith: '$'
filter_known_services:
ServiceName:
- 'krbtgt'
- 'ANONYMOUS LOGON'
condition: selection and not filter_known_services
timeframe: 5m
condition_count: selection | count() > 5 by SubjectUserName
falsepositives:
- Legacy applications that require RC4 Kerberos
- Kerberos pre-authentication testing in lab environments
level: medium
For single-account targeting (quieter attacks), reduce the threshold or alert on any RC4 TGS request for high-value service accounts:
title: Kerberoasting - High-Value Service Account TGS Request
id: 3e7a1c5d-8b2f-4d9a-c6e0-5f8b2d4c7a1e
detection:
selection:
EventID: 4769
TicketEncryptionType: '0x17'
ServiceName|contains:
- 'svc_'
- 'sql'
- 'backup'
- 'admin'
condition: selection
level: high
Kerberoasting KQL (Microsoft Sentinel)
// Detect RC4 TGS requests at volume -- potential Kerberoasting
SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17"
| where ServiceName !endswith "$"
| where ServiceName !in ("krbtgt", "ANONYMOUS LOGON")
| summarize
RequestCount = count(),
TargetAccounts = make_set(ServiceName),
SourceIPs = make_set(IpAddress)
by Account, bin(TimeGenerated, 5m)
| where RequestCount > 3
| project TimeGenerated, Account, RequestCount, TargetAccounts, SourceIPs
| order by RequestCount desc
AS-REP Roasting: The Pre-Auth Variant
AS-REP Roasting targets accounts with Kerberos pre-authentication disabled (DONT_REQ_PREAUTH flag). An attacker can request an AS-REP for any such account without knowing the password — the DC returns an AS-REP encrypted with the account’s key, which can be cracked offline (Hashcat mode 18200).
This is detectable via Event ID 4768 with Pre-Authentication Type: 0 and Result Code: 0x0. Normal accounts require pre-authentication (Pre-Auth Type: 2); a successful AS-REP for a Type 0 account is anomalous.
title: AS-REP Roasting - Pre-Authentication Disabled Account Request
id: 6d2b8f1a-4c7e-3b9d-a5f2-8e1c4d7b2a6f
status: experimental
description: Detects AS-REP requests where Kerberos pre-authentication is disabled, indicating a potential AS-REP Roasting attempt
references:
- https://attack.mitre.org/techniques/T1558/004/
author: SOC Analyst Hub
date: 2026/05/23
tags:
- attack.credential_access
- attack.t1558.004
logsource:
product: windows
service: security
detection:
selection:
EventID: 4768
PreAuthType: '0'
Status: '0x0'
filter_expected:
TargetUserName|endswith: '$'
condition: selection and not filter_expected
falsepositives:
- Accounts legitimately configured without pre-authentication (document these)
- Service accounts configured this way by legacy applications
level: high
Hunting: Enumerating Before the Requests
Attackers typically enumerate SPNs before requesting tickets. This shows up as LDAP queries against the DC — specifically searches for servicePrincipalName=*.
If you have AD object access logging enabled (via audit policy or Microsoft Defender for Identity), hunt for:
// MDI: SPN enumeration via LDAP
IdentityQueryEvents
| where ActionType == "LDAP query"
| where QueryTarget contains "servicePrincipalName"
| where QueryTarget !startswith "CN=krbtgt"
| summarize QueryCount = count(), Targets = make_set(QueryTarget, 20)
by DeviceName, AccountName, bin(Timestamp, 10m)
| where QueryCount > 10
Proactive Hardening
Detection is reactive. The better control is reducing the attack surface:
- Audit SPN-bearing accounts:
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName | Select Name, ServicePrincipalName— minimise this list. - Enforce AES-only Kerberos on service accounts: set
msDS-SupportedEncryptionTypes = 0x18(AES128 + AES256). RC4 tickets are then not issued. - Managed Service Accounts (gMSA): gMSAs automatically rotate 120-character random passwords, making offline cracking computationally infeasible even if a ticket is obtained.
- Alert on
DONT_REQ_PREAUTH: every account with this flag is AS-REP-Roastable. There should be none unless there’s a specific documented need.
Baselining and Tuning
Both detections generate false positives in environments with legacy applications requiring RC4. Build an allow-list of known service accounts that legitimately produce RC4 TGS events — any account not on that list triggering RC4 TGS requests warrants investigation. Run the KQL query weekly in hunting mode to spot new additions before they become incidents.