Kerberos TGT issued to an account without preauthentication

Siemphony@siemphonymediumT1558.004unverified

AN0316 names the one property of an AS-REP roast that lands on a single Security 4768 record: the authentication service issued a TGT for an account whose Kerberos preauthentication is disabled (`PreAuthType` 0, meaning the requester never had to prove knowledge of the password). The match is limited to successful issuance (`Status` 0x0) because a failed request hands the requester no crackable material — that also drops the ordinary MIT/Heimdal `kinit` opening exchange, which asks without preauthentication, is refused with KDC_ERR_PREAUTH_REQUIRED and never reaches 0x0. Machine accounts are excluded: a computer account authenticating with its own long random secret is not roastable even when its records look unusual. The analytic also names RC4 (`TicketEncryptionType` 0x17) as an accompanying anomaly, and most public write-ups make it a required conjunct; it is deliberately not required here, because the requester chooses the encryption types it offers, and an AS-REP returned under AES for a preauthentication-disabled account is still crackable offline — only more slowly. Gating on 0x17 would turn the whole rule off for the cost of one flag. The other side of that choice is that on a domain still permitting RC4 broadly the encryption type carries no discrimination anyway, so every bit of selectivity here rests on the preauthentication flag. The rest of the analytic does not fit on one event — the AS-REQ/AS-REP volume test behind MITRE's `TGTRequestThreshold` knob is an aggregation, and the correlation with follow-on 4769 service ticket activity inside MITRE's `TimeWindow` knob is a join; lib/sigma models neither, so this rule fires on the first roastable reply rather than on a burst. It also cannot see the enumeration step that precedes the roast, an LDAP read of accounts carrying the DONT_REQ_PREAUTH flag, which leaves no 4768 record at all. Prerequisite: 4768 is written only by domain controllers and only with Audit Kerberos Authentication Service enabled for Success; it is present in the Microsoft and CIS domain controller baselines but is frequently dropped from forwarding for volume, and a rule against a feed nobody ships returns zero rows that read as quiet when they mean blind. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0113, 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 == 4768 and PreAuthType =~ "0" and Status =~ "0x0") and not (TargetUserName endswith "$"))

Splunk · SPL

Run this as a search.

index=* ((EventID="4768" AND PreAuthType="0" AND Status="0x0") AND NOT (TargetUserName="*$"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((event.code == 4768 AND TO_LOWER(PreAuthType) == "0" AND TO_LOWER(Status) == "0x0") AND NOT (TO_LOWER(TargetUserName) LIKE "*$"))

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="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="EventID" type="pcre2">(?i)^4768$</field>    <field name="PreAuthType" type="pcre2">(?i)^0$</field>    <field name="Status" type="pcre2">(?i)^0x0$</field>    <field name="TargetUserName" negate="yes" type="pcre2">(?i)\$$</field>    <description>Kerberos TGT issued to an account without preauthentication</description>    <mitre>      <id>T1558.004</id>    </mitre>  </rule></group>

At a glance

Logsource: security / windows
Level: medium
Category: kerberos_ticket_abuse
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 3c9d21ca-8f01-411d-9294-343c176250fd

ATT&CKT1558.004

T1558.004AS-REP Roasting

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

AS-REP roasting exploits one directory setting. Normally a Kerberos client proves it knows the password before the KDC will answer; an account with preauthentication disabled skips that step, so anyone who asks gets back an AS-REP containing material encrypted with that account's password hash — free to crack offline. This rule matches the one property of that exchange that lands on a single Security 4768 record: a TGT was issued to an account with PreAuthType 0.

02 · Telemetry you need

Security 4768 from domain controllers, which are the only things that write it. It needs Audit Kerberos Authentication Service enabled for Success. That is present in both the Microsoft and CIS domain controller baselines, so the policy is usually fine — but the event is high volume and frequently dropped from forwarding for cost, and a rule against a feed nobody ships returns zero rows that read as quiet when they mean blind. Confirm arrival first. You need PreAuthType, Status and TargetUserName preserved through normalisation.

03 · How the logic works

Three equality tests in the selection: EventID 4768, PreAuthType 0, and Status 0x0. The status gate is doing real work. A failed request hands the requester no crackable material, and it also drops the ordinary MIT and Heimdal kinit opening exchange, which asks without preauthentication, is refused with KDC_ERR_PREAUTH_REQUIRED, and never reaches 0x0. A filter_machine_accounts block then removes TargetUserName ending in $, because a computer account authenticating with its own long random secret is not roastable however odd its records look. The condition is selection and not filter_machine_accounts. One choice is worth defending. MITRE's analytic names RC4 (TicketEncryptionType 0x17) as an accompanying anomaly and most public write-ups make it a required conjunct — it is deliberately not required here. The requester chooses the encryption types it offers, and an AES AS-REP for a preauth-disabled account is still crackable, only more slowly; gating on 0x17 would turn the rule off for the cost of one flag. The other side of that trade is that every bit of selectivity rests on the preauthentication flag alone. What the rule cannot do: MITRE's TGTRequestThreshold knob is a volume test and its TimeWindow knob correlates with follow-on 4769 activity — an aggregation and a join, neither modelled by Sigma. So this fires on the first roastable reply, not on a burst. It also cannot see the enumeration step that precedes a roast, an LDAP read for accounts carrying DONT_REQ_PREAUTH, which leaves no 4768 record at all.

04 · Common false positives

Not loudly, which is why the level is medium rather than low, but predictably. Accounts deliberately set to "Do not require Kerberos preauthentication" — for MIT/Heimdal interoperability, Java and appliance integrations, or carried over from a realm migration — produce this exact record on every ordinary logon. On a domain that has any of them, they are the dominant match. Defensive deception accounts are configured this way on purpose, as tripwires, and fire on every authorised attack-path assessment. Authorised red team and password-audit runs using Rubeus or Impacket GetNPUsers are indistinguishable except by source address and change ticket. And bulk identity tooling that rewrites userAccountControl can leave the flag set on a batch of ordinary users, after which each of their logons matches until someone clears it.

05 · Detection maturity

tier_1: Lowest tier. Derived from MITRE ATT&CK DET0113 and never executed against a log line. No measured volume, no confirmed true positive, no proof the fields survive your pipeline — medium is an unverified guess until you run it.

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 PreAuthDisabledAccountsBaseline knob is the whole tuning story. Query the directory for userAccountControl with DONT_REQ_PREAUTH set, and treat that list two ways: clear the flag where nothing needs it — the real fix — and exclude by TargetUserName what genuinely does, tagging your tripwire accounts to alert higher instead. Then watch for new names appearing in the baseline; a flag switched on is a stronger signal than any ticket.

Declared by the author

Accounts deliberately configured with 'Do not require Kerberos preauthentication', which is set for compatibility with MIT/Heimdal Kerberos clients, some Java and appliance integrations, and accounts carried over from a realm migration. Every ordinary interactive or service logon by one of those accounts produces exactly this record, so on a domain that has any of them this is the dominant match and the reason the level is not higher; MITRE's PreAuthDisabledAccountsBaseline knob is where a site's own list of them belongs.
Deception accounts created on purpose by defenders as AS-REP roast tripwires, which are configured without preauthentication precisely so that they appear in enumeration, and which also fire on every authorised vulnerability scan or attack-path assessment that touches them.
Authorised credential-hygiene testing and red team exercises using Rubeus, Impacket GetNPUsers or an internal password-audit run, which produce the identical event and are distinguishable only by source address and change ticket.
Bulk identity-management, joiner-mover-leaver or realm-migration tooling that rewrites userAccountControl and leaves DONT_REQ_PREAUTH set on a batch of ordinary user accounts, after which every routine logon by each of them produces this record until someone clears the flag again.

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.004, evaluated against their — events.

Share this rule

/u/siemphony/3c9d21ca-8f01-411d-9294-343c176250fd

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

@nadia-brandt
26 Aug 2026
The machine-account filter earns its place — without it every RODC and every pre-Windows-2000 compatibility account lights this up all day. What we had to add was a second exclusion for our own AS-REP tripwire accounts, which have preauth disabled by design and therefore fire on every scan. That one is site-specific so I do not think it belongs in the shipped rule, but it belongs in a deployment note, because everyone who has tripwires will hit it in week one.

Kerberos TGT issued to an account without preauthentication

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it

1 thread