I spent a long time reducing Kerberoasting detection to a single criterion: if I see encryption type 0x17 (RC4) in event ID 4769, I get suspicious; if I see 0x12 (AES256), I relax. When I ran Rubeus with the /rc4opsec flag in my own test cluster against accounts supporting AES, I saw that assumption collapse. Below is what each variant leaves behind in telemetry and what it doesn't.
1. Catch classic RC4-based Kerberoasting. On SPN accounts where msds-supportedencryptiontypes is not set, TGS-REQ requests RC4 by default. Filter event ID 4769 on your Domain Controller and pull records where the Ticket Encryption Type field is 0x17. To verify, create an SPN in your own lab AD with setspn -a HTTP/testsvc.lab.local svc_test, run Rubeus kerberoast, then search for 4769 in the Security log.
2. Handle the AES-forced (opsec) variant separately. When /rc4opsec or /aes flags are used, the request arrives in AES256 and encryption type is no longer a discriminator. Instead, look at TGS-REQ frequency and multiple requests for different SPNs from the same source in a short time:
index=wineventlog EventCode=4769 | stats count by Account_Name, Service_Name | where count > 5
3. Pre-map which accounts in your environment can fall back to RC4. You can query the distribution of encryption types in 4769 records over your local Elasticsearch:
curl -i -X GET "http://192.168.1.50:9200/winlogbeat-*/_search" \
-H 'Content-Type: application/json' \
-d '{"query":{"match":{"event.code":"4769"}},"aggs":{"enc":{"terms":{"field":"winlog.event_data.TicketEncryptionType"}}}}'
The response comes back as HTTP/1.1 200 OK, and in the aggregation block you see "key":"0x17" and "key":"0x12" counts. A high RC4 share indicates the presence of unpatched legacy accounts.
4. Bury SPN scanning in your CI pipeline. Manual checks get forgotten; automation doesn't. A weekly job in GitLab CI:
ad-spn-audit:
stage: audit
script:
- python3 check_spn_enctype.py --domain lab.local --output report.json
rules:
- if: '$CI_PIPELINE_SOURCE == "schedule"'
report.json contains a list of accounts where msds-supportedencryptiontypes is empty or RC4-supporting; if the list is empty, you have an opsec-compliant environment.
5. Track silver ticket generation separately. Kerberoasting doesn't end with cracking the TGS; silver tickets generated from the cracked hash can access services without producing 4769. The only reliable trace for this is abnormal session timestamps on the target service; it doesn't appear in DC logs.
6. Fix msds-supportedencryptiontypes in bulk. Use Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties msds-supportedencryptiontypes to list RC4-exposed accounts, then force the value to 24 (AES-only). This narrows the blind spot in your detection rule, though it doesn't eliminate it.