Kerberoasting remains one of the most reliable ways an attacker converts a foothold into domain credentials without touching LSASS. The technique is MITRE ATT&CK T1558.003: request a Kerberos service ticket (TGS) for any account with a Service Principal Name (SPN), extract the encrypted blob from memory, and crack it offline. Microsoft documented the risk in its Defender for Identity security assessment guidance and has shipped mitigations in Windows since 2022. This article shows how to build high-fidelity detections in Splunk and the Elastic Stack using Windows Security Event 4769, and how to reduce false positives from legitimate RC4 service traffic.
Background: what Kerberoasting actually looks like on the wire
Kerberos service tickets are encrypted with a key derived from the service account's password. When a domain user requests a ticket for an SPN, the domain controller (DC) returns a TGS-REP encrypted with the service account's long-term key. If the service account is configured for RC4-HMAC (etype 0x17), the ticket is encrypted with the NT hash, which is fast to brute-force. If AES (etype 0x12) is used, cracking is significantly slower but still feasible for weak passwords.
The attack was popularized in 2016 by Tim Medin's DerbyCon talk and is now a standard step in red-team playbooks and ransomware intrusions. Microsoft's guidance notes that any authenticated user can request a service ticket for any SPN-enabled account, so the DC will happily log a 4769 event for the request regardless of whether the account is privileged. That is the signal we detect.
Two field values matter most in the 4769 record:
TicketEncryptionType—0x17indicates RC4-HMAC, the crackable path;0x12indicates AES256.ServiceName— the SPN target. Accounts with SPNs that are also members of Domain Admins are the highest-value targets.
Microsoft's own documentation confirms that the 4769 event is generated whenever a service ticket is requested, and that RC4 tickets should be treated as anomalous on modern domains that enforce AES. See Microsoft Learn: Event 4769.
Affected versions and configuration prerequisites
Kerberoasting is not a CVE — it is a design property of Kerberos. Every supported Windows Server version that can act as a KDC is in scope: Windows Server 2012 R2 through Windows Server 2025. The exposure depends on account configuration, not patch level.
Before you can detect anything, audit policy on the DCs must log Kerberos service ticket operations. On modern Windows Server, this is configured via Group Policy under Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → Account Logon → Audit Kerberos Service Ticket Operations. Microsoft documents the required settings in Audit Kerberos Service Ticket Operations.
You also need to know which service accounts still permit RC4. Microsoft added the msDS-SupportedEncryptionTypes attribute to control this, and documented the migration path in Kerberos encryption types. Accounts with msDS-SupportedEncryptionTypes unset or set to a value that includes RC4 are the ones that will produce crackable tickets.
Attacker TTPs mapped to MITRE ATT&CK
Kerberoasting is rarely a single step. In public incident reports and red-team write-ups, it appears in this sequence:
- T1078 — Valid Accounts: attacker obtains any low-privilege domain user (phishing, password spray, or a compromised workstation).
- T1558.003 — Steal or Forge Kerberos Tickets: Kerberoasting: enumerate SPNs (often via LDAP query for
servicePrincipalName=*) and request RC4 TGS tickets. - T1110 — Brute Force: Password Cracking: offline cracking of the extracted TGS blob using Hashcat mode 13100 or John the Ripper's
krb5tgsformat. - T1078 — Valid Accounts (again): the cracked service account password is used to authenticate, often to a server where that account has local admin or DCSync rights.
The detection opportunity is narrow but reliable: the RC4 TGS request from a non-service-account user, especially in bursts across many SPNs.
Detection engineering: Splunk SPL
Assume you are ingesting Windows Security events via the Splunk Universal Forwarder or a Windows Event Forwarding (WEF) collector, with sourcetype=WinEventLog:Security and EventCode=4769. The base search below flags RC4 service ticket requests and enriches with account context.
index=wineventlog sourcetype=WinEventLog:Security EventCode=4769
| eval enc=lower(TicketEncryptionType)
| where enc="0x17" OR enc="rc4_hmac"
| eval svc=lower(ServiceName)
| eval user=lower(Account_Name)
| where svc != "krbtgt" AND NOT match(svc, "^[a-z0-9_-]+\\$$")
| stats count values(svc) as targets dc(ServiceName) as distinct_spns by user, ComputerName
| where distinct_spns >= 5 OR count >= 20
| sort - distinct_spnsTwo thresholds matter. distinct_spns >= 5 catches enumeration-then-request patterns; count >= 20 within the search window catches burst requests. Tune both against your baseline — a legitimate backup service may request the same SPN repeatedly, which is why we count distinct SPNs, not raw events.
For a higher-fidelity alert, join against an asset lookup that flags Domain Admin or high-value accounts:
index=wineventlog sourcetype=WinEventLog:Security EventCode=4769 TicketEncryptionType="0x17"
| lookup privileged_accounts sAMAccountName AS ServiceName OUTPUT is_privileged
| where is_privileged="true"
| table _time, Account_Name, ServiceName, Client_Address, ComputerNameDetection engineering: Elastic (EQL and KQL)
In Elastic Security, the cleanest implementation is an EQL sequence that correlates a 4769 RC4 request with a subsequent 4624 logon by the same service account from an unusual source. The rule below uses the Elastic Common Schema (ECS) fields populated by the Windows integration.
sequence by winlog.event_data.ServiceName with maxspan=15m
[any where event.code == "4769" and
winlog.event_data.TicketEncryptionType in ("0x17", "0x17") and
winlog.event_data.ServiceName != "krbtgt"]
[any where event.code == "4624" and
winlog.event_data.LogonType in ("3", "10")]For a simpler KQL rule that runs on every 4769 event:
event.code : "4769" and
winlog.event_data.TicketEncryptionType : "0x17" and
not winlog.event_data.ServiceName : "krbtgt" and
not winlog.event_data.Account_Name : *$
Pair this with a threshold rule of 10 events per 5 minutes grouped by winlog.event_data.Account_Name. Elastic's prebuilt Kerberoasting rule exists in the detection-rules repository and is documented at Elastic Security: Kerberos traffic from unusual account.
Sigma rule for cross-SIEM portability
If you maintain a Sigma pipeline, the following rule compiles cleanly with sigma convert -t splunk or -t lucene. It targets the same 4769 signal and is intentionally conservative to reduce noise.
title: Kerberoasting RC4 Service Ticket Request
id: 6f8a2c1e-4b3d-4f7a-9c2e-1a2b3c4d5e6f
status: experimental
description: Detects RC4-HMAC TGS requests for SPN accounts, a common Kerberoasting signal.
author: CybernytronX
logsource:
product: windows
service: security
detection:
selection:
EventID: 4769
TicketEncryptionType:
- '0x17'
ServiceName|endswith: '$'
filter_krbtgt:
ServiceName: 'krbtgt'
condition: selection and not filter_krbtgt
falsepositives:
- Legacy applications that require RC4
level: mediumNote the ServiceName|endswith: '$' filter — this excludes machine accounts, which legitimately request RC4 tickets on older domains. If your environment is fully AES-enforced, remove the filter for higher sensitivity.
Mitigation: reducing the attack surface
Detection is the second line. The first is removing RC4 from the domain. Microsoft's guidance in Kerberos encryption types recommends setting msDS-SupportedEncryptionTypes to 0x18 (AES128 + AES256) on service accounts and auditing the Kerberos-User and Kerberos-Service event channels for RC4 fallback before enforcing.
Additional controls:
- Replace user-account SPNs with Group Managed Service Accounts (gMSA), which use 240-character random passwords rotated automatically.
- Enforce a 25+ character password policy for any remaining service accounts, per Microsoft's password policy guidance.
- Remove SPNs from accounts that are members of Domain Admins, Enterprise Admins, or Schema Admins. There is no legitimate reason for a DA account to hold an SPN.
- Enable Microsoft Defender for Identity, which ships a built-in Kerberoasting detection and correlates it with reconnaissance activity.
Why this matters for defenders
Kerberoasting is attractive to attackers because it is quiet, requires no elevated privilege, and survives password resets of the compromised user — the cracked credential is the service account, not the initial foothold. In ransomware intrusions documented by Microsoft and Mandiant, Kerberoasting frequently appears between initial access and lateral movement, giving defenders a narrow but real window to intervene.
The detection problem is not signal availability; 4769 events are generated on every DC for every service ticket. The problem is baseline. A domain with 200 legacy service accounts using RC4 will drown a naive rule. The engineering work is in asset inventory: know which accounts have SPNs, which permit RC4, and which are privileged. Once that lookup exists, the Splunk and Elastic rules above become high-fidelity. Without it, they are noise generators.
Treat Kerberoasting detection as a data-quality program, not a rule deployment. The rule is the easy part.
Sources
- MITRE ATT&CK T1558.003 — Steal or Forge Kerberos Tickets: Kerberoasting — defines the technique and its procedure examples.
- Microsoft Learn: Event 4769 — A Kerberos service ticket was requested — confirms the fields used in the detection rules.
- Microsoft Learn: Kerberos encryption types — documents
msDS-SupportedEncryptionTypesand RC4 deprecation. - Microsoft Defender for Identity: Kerberoasting security assessment — vendor guidance on detection and remediation.
- Elastic Security: Kerberos traffic from unusual account — prebuilt rule referenced in the ELK section.
- Microsoft Learn: Group Managed Service Accounts overview — mitigation path for SPN accounts.
Frequently Asked Questions
Does Kerberoasting require Domain Admin to start?
No. Any authenticated domain user can request a service ticket for any SPN-enabled account. That is why the technique is so common after initial access — a single phished standard user is enough to begin enumeration.
Why focus on RC4 (0x17) instead of all 4769 events?
RC4 tickets are encrypted with the service account's NT hash, which is crackable at billions of guesses per second on modern GPUs. AES tickets are far slower to crack. Filtering to 0x17 gives you the highest-signal subset without losing the technique.
Will enforcing AES-only break my environment?
Possibly. Legacy applications and older NAS devices may still require RC4. Microsoft recommends auditing the Kerberos-User and Kerberos-Service event channels for RC4 fallback before enforcing AES-only via msDS-SupportedEncryptionTypes. Stage the change per-account, not domain-wide.
What is the difference between Kerberoasting and AS-REP Roasting?
Kerberoasting targets accounts with SPNs and requests a TGS. AS-REP Roasting targets accounts with Do not require Kerberos preauthentication set and requests an AS-REP without any prior authentication. Both are covered under ATT&CK T1558, but the event IDs differ: 4769 for TGS, 4768 for AS-REQ. Detect both.
How many 4769 events per minute should trigger an alert?
There is no universal number. Baseline your environment for two weeks, then alert on statistical outliers — typically more than three standard deviations above the per-user mean, or any burst of distinct SPNs from a single account within five minutes.
Does Microsoft Defender for Identity replace custom SIEM rules?
No. Defender for Identity provides strong out-of-the-box coverage, but it only sees domain controllers where sensors are deployed. SIEM rules on 4769 events extend coverage to any DC forwarding logs, including read-only domain controllers and branch offices.
Need expert help with this?
CybernytronX builds and tunes Active Directory detection programs for security teams — from Splunk and Elastic rule development to full SOC build-out and purple-team validation of Kerberoasting, AS-REP Roasting, and DCSync paths. Our Ethereon AI layer correlates Kerberos anomalies with lateral-movement signals to cut alert noise. If you need a second opinion on your 4769 baseline or want a tabletop exercise against your domain, talk to our team or explore Ethereon.