Kerberos service ticket issued with RC4 encryption

Siemphony@siemphonylowT1558.003unverified

Matches successful Kerberos TGS issuance (Security 4769) where the ticket was encrypted with RC4-HMAC (`TicketEncryptionType` 0x17), the variant Kerberoasting is easiest against — the RC4 portion of the TGS-REP cracks fastest offline. It is not the only variant: a TGS encrypted with AES (`TicketEncryptionType` 0x12) is crackable too, only far more slowly, so an operator roasting an account configured AES-only, or one whose toolkit does not force an RC4 downgrade, produces no match here at all. That is this rule's largest blind spot, and it is not visible in its output. Machine accounts and `krbtgt` are excluded on `ServiceName` because computer SPNs are backed by a 120-character random password and krbtgt requests belong to the AS/TGT path, so neither is a roasting target and both would otherwise dominate the output. The `TicketOptions: 0x40810000` fingerprint quoted in most public write-ups is deliberately not required here: ordinary Windows clients send the same option set, so it adds little precision while excluding toolkits that ask for different flags. MITRE's AN0444 also counts tickets per account inside a window and compares requested SPNs against a per-account baseline; neither a count nor a baseline is expressible in Sigma, so this fires on one RC4 ticket rather than on a burst, and it cannot distinguish a single roast from a sweep. 4769 is written only by domain controllers, under Audit Kerberos Service Ticket Operations (Success) — that subcategory is on in the Default Domain Controllers Policy, but the event is very high volume and is routinely dropped at the forwarder or the SIEM's ingest filter, so confirm the events actually arrive before reading silence as absence of the behaviour. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0157, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 4 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Sentinel · KQL

Run this as a search.

SecurityEvent| where ((EventID == 4769 and TicketEncryptionType =~ "0x17" and Status =~ "0x0") and not ((ServiceName endswith "$" or ServiceName endswith "krbtgt")))

Splunk · SPL

Run this as a search.

index=* ((EventID="4769" AND TicketEncryptionType="0x17" AND Status="0x0") AND NOT ((ServiceName="*$" OR ServiceName="*krbtgt")))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((event.code == 4769 AND TO_LOWER(TicketEncryptionType) == "0x17" AND TO_LOWER(Status) == "0x0") AND NOT ((TO_LOWER(service.name) LIKE "*$" OR TO_LOWER(service.name) LIKE "*krbtgt")))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="5">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="EventID" type="pcre2">(?i)^4769$</field>    <field name="TicketEncryptionType" type="pcre2">(?i)^0x17$</field>    <field name="Status" type="pcre2">(?i)^0x0$</field>    <field name="ServiceName" negate="yes" type="pcre2">(?i)(\$$|krbtgt$)</field>    <description>Kerberos service ticket issued with RC4 encryption</description>    <mitre>      <id>T1558.003</id>    </mitre>  </rule></group>

At a glance

Logsource: security / windows
Level: low
Category: kerberos_ticket_abuse
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 41b12f88-df7b-4512-a6b4-9b20fbc1752f

ATT&CKT1558.003

T1558.003Kerberoasting

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessonkerberos ticket abuse

kerberos ticket abuseAI draft — unreviewed

01 · What this rule detects

Kerberoasting starts with a perfectly ordinary act: asking a domain controller for a service ticket. The ticket comes back encrypted with the service account's password hash, and the requester cracks it offline at leisure. The rule matches successful TGS issuance (Security 4769) where that encryption was RC4-HMAC — the variant that cracks fastest, and the one most toolkits force by downgrade. It fires on the request, not on the cracking, which happens somewhere you cannot see.

02 · Telemetry you need

Security 4769 from domain controllers only; member servers never write it. It requires Audit Kerberos Service Ticket Operations (Success), which is on in the Default Domain Controllers Policy — but 4769 is one of the highest-volume events a DC produces, so it is routinely dropped at the forwarder or the SIEM's ingest filter for cost. Confirm the events actually arrive before reading silence as absence of the behaviour. You need TicketEncryptionType, ServiceName and Status to survive normalisation intact.

03 · How the logic works

The selection is three equality tests: EventID 4769, TicketEncryptionType 0x17 (RC4-HMAC) and Status 0x0, meaning the ticket was actually issued rather than refused. A filter_not_roastable block then removes anything whose ServiceName ends in $ or krbtgt, and the condition is selection and not filter_not_roastable. The exclusions matter: computer SPNs are backed by a 120-character random password nobody is cracking, and krbtgt requests belong to the AS/TGT path rather than to service-ticket issuance — left in, both would drown the output. Two deliberate omissions. The TicketOptions: 0x40810000 fingerprint that appears in most public write-ups is not required, because ordinary Windows clients send the same option set: it buys little precision while excluding any toolkit that asks for different flags. More seriously, an AES ticket (0x12) is crackable too, only far more slowly — so an operator roasting an AES-only account, or one whose tooling does not downgrade, produces no match here at all. That blind spot is invisible in the rule's output. MITRE's AN0444 also counts tickets per account inside a window and compares requested SPNs against a baseline; Sigma expresses neither, so this fires on one ticket and cannot tell a single roast from a sweep.

04 · Common false positives

The dominant match is not an attack at all. Service accounts whose msDS-SupportedEncryptionTypes still permits RC4 — legacy SQL Server, SAP, JBoss and appliance SPNs are the usual suspects — request an RC4 ticket on every client connection, all day. In a domain that has not enforced AES, a handful of accounts can produce the large majority of hits, which is why the level sits at the bottom of the scale. Clients whose own Kerberos encryption policy is unset negotiate RC4 for normal file, print and web SPNs. AD hygiene scanners such as PingCastle and BloodHound collectors enumerate every SPN and request a ticket for each — Kerberoasting in all but intent. Cross-forest trusts configured for RC4 issue RC4 referrals by design.

05 · Detection maturity

tier_1: Lowest tier. Derived from MITRE ATT&CK DET0157 and never run against a log line: no measured volume, no confirmed true positive, no proof the field names survive your pipeline. Treat low as an unverified guess.

Tuning & false positivesexperimental · 4 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

MITRE's AllowedEncryptionTypes knob is exactly where this rule lives; the single value 0x17 is the pipeline's own choice within it, and it stops being selective the moment your domain is RC4-heavy. So do the tuning in the directory first: enumerate SPN-holding accounts, set them AES-only, and let the rule's volume collapse on its own. What remains, exclude by ServiceName against MITRE's ServiceAccountBaselines knob, populated with your own scanner accounts and known legacy SPNs. Then rebuild the per-account count MITRE's TGSRequestThreshold describes as a SIEM correlation over this rule's output — one RC4 ticket is noise, forty in a minute from one requester is not.

Declared by the author

Service accounts whose msDS-SupportedEncryptionTypes still permits RC4 — legacy SQL Server, SAP, JBoss and appliance SPNs are the usual set — request an RC4 ticket on every client connection all day long. In a domain that has not enforced AES these few accounts can account for the large majority of matches, which is exactly what MITRE's AllowedEncryptionTypes knob, set here to the single value 0x17, exists to be tuned against. It is also why the level sits at the bottom of the scale: until RC4 is off, the ordinary case outnumbers the roast by orders of magnitude.
Ordinary user logons from hosts whose client-side Kerberos encryption policy is unset or downgraded, which negotiate RC4 for normal file, print and web SPNs. These recur on every logon and every share access and look identical to a roast of the same SPN.
Attack-surface and AD hygiene scanners — PingCastle, BloodHound collectors, purple-team scripts and some credentialed vulnerability scanners — enumerate every SPN in the domain and request a ticket for each, producing a burst that is Kerberoasting in all but intent. These run on a schedule from a known account, which is where MITRE's ServiceAccountBaselines knob applies.
Cross-forest and legacy-realm trusts configured for RC4 on the trust object itself, so every referral into the other realm issues an RC4 ticket for a perfectly normal user-backed service account.

Noise check0 of 6 fired

Fires on none of the 6 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 6 behaviours, and the next ordinary behaviour nobody wrote down may still match.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1558.003, evaluated against their — events.

Share this rule

/u/siemphony/41b12f88-df7b-4512-a6b4-9b20fbc1752f

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

1 thread

@hana-kobayashi
25 Aug 2026
Low is correct and I wish more published rule sets were this willing to say it. In a domain that has not enforced AES, this is a report, not an alert — a handful of legacy SPNs will produce the overwhelming majority of it every single day. The version worth alerting on is the burst: one account requesting tickets for forty SPNs inside two minutes. That needs an aggregation Sigma cannot express, which the description says outright instead of pretending otherwise.
- @nadia-brandt
  26 Aug 2026
  That is how we run it — the Sigma rule is the filter, and a distinct-count of ServiceName by TargetUserName over a short window sits on top of it in the platform. Splitting the two that way also means the rule stays portable: the aggregation is the part that is specific to whichever SIEM you happen to own this year.

Kerberos service ticket issued with RC4 encryption

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it

1 thread