Kerberoasting: attack & detect
- MITRE T1558.003
- Event ID 4769
- documented
A service account with an SPN is set up on purpose. I request its ticket from Kali, then hunt for that request in the domain controller's Security log. On Server 2025 the DC only issues AES tickets, which changes how the detection has to work.
- Red
Register an SPN on a service account, then request its TGS from Kali.
- Blue
Catch the request as Event 4769 on the DC. On this AES-only domain the ticket is 0x12, not the classic RC4 0x17.
- Purple
Tune out machine accounts and krbtgt, then harden the account: long random password or gMSA, AES only.
# Hunt: RC4 service tickets requested for user accounts
$xpath = "*[System[EventID=4769] and EventData[Data[@Name='TicketEncryptionType']='0x17']]"
Get-WinEvent -LogName Security -FilterXPath $xpath |
Where-Object { $_.Properties[2].Value -notmatch '\$$|^krbtgt$' } |
Select-Object TimeCreated,
@{n='Account'; e={$_.Properties[0].Value}},
@{n='Service'; e={$_.Properties[2].Value}},
@{n='Client'; e={$_.Properties[6].Value}}
# 0x17 = RC4-HMAC, the classic Kerberoasting telltitle: Kerberoasting - RC4 service ticket requested
status: experimental
description: TGS requested with RC4-HMAC for a user (non-machine) service account
tags:
- attack.credential-access
- attack.t1558.003
logsource:
product: windows
service: security
detection:
selection:
EventID: 4769
TicketEncryptionType: '0x17'
Status: '0x0'
filter_machine:
ServiceName|endswith: '$'
filter_krbtgt:
ServiceName: 'krbtgt'
condition: selection and not 1 of filter_*
falsepositives:
- Legacy apps that still require RC4
level: mediumThe catch: the rule below hunts RC4 (0x17), the classic tell. But my Server 2025 DC refuses RC4, so my attack came back as AES (0x12) and this rule never fires. The real detection here is behavioural: baseline which accounts normally request service tickets and alert on the unusual ones.
read the lab notes on GitHub ↗
