sIDHistory attribute populated on a domain user account

Siemphony@siemphonymediumT1134.005unverified

AN0383 is a four-stage chain — an API call to DsAddSidHistory, the resulting directory attribute change, a logon whose token carries the injected SID, and follow-on resource access — and only the second stage has a log source in the brief. This rule implements that stage three ways, one per log source given. The first arm matches Security 5136 (a directory object was modified) narrowed to ObjectClass 'user' and AttributeLDAPDisplayName 'sIDHistory': any event meeting both is itself the attribute being written, so no further value check is needed. The second and third arms match 4720 (user account created) and 4738 (user account changed), both of which carry their own SidHistory field populated with the SID(s) added; that field is empty ('-') on the overwhelming majority of 4720/4738 events raised for unrelated changes, so the arm requires it to contain 'S-1-5-21-', the prefix of every domain SID, to separate a real population from the placeholder. The API-call stage (DsAddSidHistory / Mimikatz Kerberos::references) has no log source in the brief and is not attempted. The logon and resource-access stages are absent for the same reason 4624 was left out here: no logsource in the brief carries "this token includes SID-History", and the correlation between the attribute write and the following logon — MITRE's TimeWindow knob, 15-30 minutes — is a cross-event join lib/sigma cannot express, so a match here is evidence the attribute was written, not that the SID was ever exercised. The PrivilegedSIDList and AnomalousSIDCountThreshold knobs (flag only Enterprise/Domain Admin SIDs, or more than two entries) both need to parse and count individual SIDs out of a multivalued field, which none of contains/startswith/endswith/re/all can do; the rule matches on the attribute being touched at all, not on which SID or how many landed in it. Prerequisite: 5136 needs the *Audit Directory Service Changes* subcategory enabled on domain controllers plus an auditing SACL covering the attribute — neither is on by default; 4720/4738 come from *Audit User Account Management*, which the Microsoft and CIS domain-controller baselines do enable, but a hardened or non-baseline DC may still have it off. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0136 (AN0383), 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 == 5136 and ObjectClass =~ "user" and AttributeLDAPDisplayName =~ "sIDHistory") or (EventID == 4720 and SidHistory contains "S-1-5-21-") or (EventID == 4738 and SidHistory contains "S-1-5-21-"))

Splunk · SPL

Run this as a search.

index=* ((EventID="5136" AND ObjectClass="user" AND AttributeLDAPDisplayName="sIDHistory") OR (EventID="4720" AND SidHistory="*S-1-5-21-*") OR (EventID="4738" AND SidHistory="*S-1-5-21-*"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE ((event.code == 5136 AND TO_LOWER(ObjectClass) == "user" AND TO_LOWER(AttributeLDAPDisplayName) == "sidhistory") OR (event.code == 4720 AND TO_LOWER(SidHistory) LIKE "*s-1-5-21-*") OR (event.code == 4738 AND TO_LOWER(SidHistory) LIKE "*s-1-5-21-*"))

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. -->  <!-- 3 rules: the Sigma condition ORs across different fields,       which one rule cannot express. Any one matching is a hit. -->  <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)^5136$</field>    <field name="ObjectClass" type="pcre2">(?i)^user$</field>    <field name="AttributeLDAPDisplayName" type="pcre2">(?i)^sIDHistory$</field>    <description>sIDHistory attribute populated on a domain user account (1/3)</description>    <mitre>      <id>T1134.005</id>    </mitre>  </rule>   <rule id="100001" level="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="EventID" type="pcre2">(?i)^4720$</field>    <field name="SidHistory" type="pcre2">(?i)S-1-5-21-</field>    <description>sIDHistory attribute populated on a domain user account (2/3)</description>    <mitre>      <id>T1134.005</id>    </mitre>  </rule>   <rule id="100002" level="7">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="EventID" type="pcre2">(?i)^4738$</field>    <field name="SidHistory" type="pcre2">(?i)S-1-5-21-</field>    <description>sIDHistory attribute populated on a domain user account (3/3)</description>    <mitre>      <id>T1134.005</id>    </mitre>  </rule></group>

At a glance

Logsource: security / windows
Level: medium
Category: process_injection
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: c783ce3d-0720-4505-880b-5905b38c378b

ATT&CKT1134.005

T1134.005SID-History Injection

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.

Lessonprocess injection

process injectionAI draft — unreviewed

01 · What this rule detects

This rule watches for the Active Directory attribute write that makes SID-History injection possible: a domain user account gaining an entry in its sIDHistory attribute. SID-History lets a token carry SIDs beyond the account's own, and MITRE's AN0383 analytic frames that as stage two of a four-stage chain — an API call to DsAddSidHistory, the attribute write itself, a logon whose token carries the injected SID, and follow-on resource access. Only the attribute write has a log source in the brief, so that is the only stage this rule can see. A match means an sIDHistory value was populated; it is not evidence the SID was ever used to authenticate or access anything.

02 · Telemetry you need

Three Windows Security events, all from the windows/security Sigma logsource. Event 5136 (directory service object modified) needs the Audit Directory Service Changes subcategory enabled on domain controllers, plus an auditing SACL that actually covers the sIDHistory attribute — neither is on by default. Events 4720 (user created) and 4738 (user changed) come from Audit User Account Management, which the Microsoft and CIS domain-controller baselines do enable, but a hardened or non-standard DC may still have it off. If none of the three subcategories are enabled, this rule returns nothing, and that silence reads as "no injection happened" when it actually means "we weren't watching."

03 · How the logic works

Three independent selections, OR'ed together (1 of selection_*). selection_directory_attribute matches 5136 narrowed to ObjectClass: 'user' and AttributeLDAPDisplayName: 'sIDHistory' — any event meeting both conditions is the attribute being written, so no value check is needed on this arm. selection_account_created and selection_account_changed match 4720/4738 respectively, both of which carry their own SidHistory field — but that field is - on the overwhelming majority of account-management events raised for unrelated reasons, so each arm requires SidHistory|contains: 'S-1-5-21-', the prefix shared by every domain SID, to separate a genuine population from the empty placeholder. The rule does not attempt the API-call stage (no logsource for it in the brief), the logon stage, or the resource-access stage: 4624 was left out deliberately because no logsource marks a token as carrying SID-History, and MITRE's TimeWindow knob (15–30 minutes, correlating the write to a following logon) is a cross-event join lib/sigma has no construct for.

04 · Common false positives

The overwhelming source is legitimate AD migration: ADMT or an equivalent domain/forest restructuring tool populates sIDHistory by design so migrated accounts keep access to resources under their old SID. Third-party migration tooling (Quest Migration Manager, BinaryTree and similar) does the same in bulk under one service account, producing a burst of 4738/5136 events during a cutover window. A domain controller restore or bulk provisioning import that recreates historical SID-History values as part of restoring account state will also match here, even though nothing was actually injected.

05 · Detection maturity

tier_1: Lowest tier: authored from MITRE's prose describing AN0383, never executed against a single log line. Treat every match as "an sIDHistory attribute write happened here, go look," not as a confirmed injection or a confirmed benign migration, until the rule has been run against real 5136/4720/4738 traffic in your own environment and its false-positive rate measured.

Tuning & false positivesexperimental · 3 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 AllowedSIDHistoryChanges knob is built for exactly this: allowlist known migration windows or service accounts before running this anywhere near production, or every cutover project will page someone. PrivilegedSIDList (flag only when the value is an Enterprise/Domain Admin SID) and AnomalousSIDCountThreshold (alert past two entries) both need to parse and count individual SIDs out of a multivalued field, which none of contains/startswith/endswith/re/all can do — this rule cannot implement either knob, so it matches on the attribute being touched at all, not on which SID landed or how many. A human triaging a hit needs to pull the actual SID value and check it against a privileged-SID list by hand.

Declared by the author

ADMT (Active Directory Migration Tool) or an equivalent domain/forest migration or restructuring project, which populates sIDHistory by design so migrated accounts keep access to resources under their old SID — this is exactly the scenario MITRE's AllowedSIDHistoryChanges knob exists to allowlist by migration window or service account.
Trust and consolidation projects run by third-party identity tooling (Quest Migration Manager, BinaryTree and similar) that write SID history in bulk during a cutover, producing a burst of 4738/5136 events under one migration service account over a short window.
A domain controller restore or bulk account import from a backup or provisioning system that recreates historical SID-History values as part of restoring account state, rather than injecting a new one.

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

Share this rule

/u/siemphony/c783ce3d-0720-4505-880b-5905b38c378b

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.

No comments yet. Someone who deploys this will have something to say about it.

sIDHistory attribute populated on a domain user account

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it