Skip to content

Siemphony is in beta and still being built. How a rule earns its badge.

Siemphonybeta
Siemphony’s repertoire

sIDHistory attribute populated on a domain user account

Siemphony@siemphonymediumT1134.005unverifiedPlaybook · Privilege escalation
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 detection

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

title: sIDHistory attribute populated on a domain user accountid: c783ce3d-0720-4505-880b-5905b38c378bstatus: experimentaldescription: |  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.references:  - https://attack.mitre.org/techniques/T1134/005  - https://attack.mitre.org/detectionstrategies/DET0136author: Siemphony pipeline (machine-derived from MITRE ATT&CK v19.2)date: 2026-08-16tags:  - attack.defense-evasion  - attack.privilege-escalation  - attack.t1134.005logsource:  product: windows  service: securitydetection:  selection_directory_attribute:    EventID: 5136    ObjectClass: 'user'    AttributeLDAPDisplayName: 'sIDHistory'  selection_account_created:    EventID: 4720    SidHistory|contains: 'S-1-5-21-'  selection_account_changed:    EventID: 4738    SidHistory|contains: 'S-1-5-21-'  condition: 1 of selection_*falsepositives:  - "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."level: medium

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(winlog.event_data.ObjectClass) == "user" AND TO_LOWER(winlog.event_data.AttributeLDAPDisplayName) == "sidhistory") OR (event.code == 4720 AND TO_LOWER(winlog.event_data.SidHistory) LIKE "*s-1-5-21-*") OR (event.code == 4738 AND TO_LOWER(winlog.event_data.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>

Verdicts · reactions · comments

Community

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

Log in to react
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.

Log in to report a verdict.

Log in to join the discussion.

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