SIDHistory Injection: Well-Known SID Privilege Escalation to Domain Admin

What Is SIDHistory Injection? Well-Known SID Privilege Escalation Explained

SIDHistory injection with a well-known SID is an Active Directory persistence and privilege-escalation technique in which an attacker writes a well-known privileged SID — such as the RID 512 (Domain Admins) or RID 519 (Enterprise Admins) suffix on the domain SID — into the sIDHistory attribute of an unprivileged account. MITRE ATT&CK catalogues this as sub-technique T1134.005 — Access Token Manipulation: SID-History Injection.

Because every SID stored in sIDHistory is copied into the account's Kerberos PAC (Privilege Attribute Certificate) and, in turn, into its access token at logon, the low-privileged account effectively inherits Domain Admin rights without ever being added to the Domain Admins group. Group membership audits, nested-group reviews, and net group /domain checks all come back clean — the escalation is invisible to anything that only inspects group membership.

How It Works: sIDHistory and Well-Known SIDs

sIDHistory is a legitimate Active Directory attribute designed for inter-domain and inter-forest migrations: when an account moves to a new domain, its old SID is preserved in sIDHistory so it keeps access to resources it was already authorized for, without an administrator having to rewrite every ACL by hand. Microsoft's DsAddSidHistory function and the EnableSIDHistory trust setting exist specifically to support this migration scenario.

The problem is that Windows makes no distinction between a SID added during a legitimate migration and one added by an attacker. At logon, the Domain Controller builds the user's PAC from every SID associated with the account — primary group, all group memberships, and the full contents of sIDHistory — and that PAC becomes the access token every downstream service trusts. This is a fundamentally different persistence surface than dangerous group nesting, where the privilege is at least visible in a group's member list — here, no group membership ever changes.

Normal domain accounts and even most administrative tooling cannot simply Set-ADUser -Replace @{sidHistory=...} over LDAP; sIDHistory is a constructed/protected attribute. In practice, attackers reach it through:

• Mimikatz's sid::patch and sid::add modules, run directly on a Domain Controller with privilege::debug — this requires Domain Admin/SYSTEM-equivalent access on the DC itself, and sid::patch no longer works on Windows Server 2016 and later.
• DSInternals' Add-ADDBSidHistory edited the ntds.dit database offline and required stopping the NTDS service — used against a DC's database directly rather than through the normal replication API. As of this writing, the cmdlet has been removed from the current DSInternals PowerShell module (its documentation is kept for reference only); the maintained equivalent is Add-ADReplSidHistory, which performs the injection online over the MS-DRSR replication protocol and still requires DC-equivalent replication rights.
• The legitimate DsAddSidHistory API, intended for cross-forest migration, which some tooling abuses in unintended ways when the attacker already controls DC-equivalent privileges.

In every case, the attacker already needs replication-level or Domain Controller-level access to write to sIDHistory — this is a post-compromise persistence and stealth technique, not an initial-access vector. What makes it worth a dedicated detection is what happens after: the injected privilege is not visible in group membership, survives password resets, and is unaffected by removing the account from any group (because it was never a member of one).

The Attack Chain

Step 1 — Obtain DC-level or replication-equivalent access

The attacker first needs privileges equivalent to Domain Admin, or direct access to a Domain Controller — for example through a prior DCSync compromise, direct DC console/RDP access, or an exfiltrated ntds.dit copy. This step is the same prerequisite as a DCSync attack or a forged Golden Ticket.

Step 2 — Identify the target account and the well-known SID

The attacker picks a low-privilege, low-visibility account (a service account, an old contractor account, or a newly created one) and the domain SID with the well-known RID they want to inject:

Step 3 — Inject the SID into sIDHistory

On a compromised DC, using Mimikatz:

privilege::debug
sid::patch
sid::add /sam:lowpriv-svc /new:S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-512

Historically, offline against a copied ntds.dit, using DSInternals:

Add-ADDBSidHistory -SamAccountName lowpriv-svc -SidHistory S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-512 -DatabasePath .\ntds.dit

Step 4 — Authenticate as the low-privilege account

At the next logon, the DC builds a PAC for lowpriv-svc that includes the injected Domain Admins SID. Every service that trusts Kerberos authorization data now grants the account Domain Admin-equivalent access — while its actual group membership still shows nothing unusual.

🚨 Danger: Because the injected SID lives on the account object itself rather than in a forged ticket, it persists across every future logon until someone specifically inspects and clears sIDHistory — unlike a Golden Ticket, which expires or is invalidated by a KRBTGT rotation.

Detection

sIDHistory changes are rare in a healthy environment outside of an active migration window, which makes them a high-signal detection surface — but only if the right audit policy is enabled and the right RIDs are checked.

Event IDs 4765/4766 require the "Audit User Account Management" advanced audit subcategory to be enabled — it is not on by default in many environments, so verify audit policy before assuming coverage.

Enumerate existing accounts for populated sIDHistory and specifically filter for well-known privileged RIDs, not just any historical value:

$domainSid = (Get-ADDomain).DomainSID.Value
$privilegedRids = @(512, 516, 518, 519)

Get-ADUser -Filter { SIDHistory -like '*' } -Properties SIDHistory |
    ForEach-Object {
        foreach ($sid in $_.SIDHistory) {
            $rid = ($sid.Value -split '-')[-1]
            if ($sid.Value -like "$domainSid-*" -and $privilegedRids -contains [int]$rid) {
                [PSCustomObject]@{
                    Account = $_.SamAccountName
                    InjectedSid = $sid.Value
                    RID = $rid
                }
            }
        }
    }

Microsoft Defender for Identity ships a security posture assessment for accounts carrying an sIDHistory value and includes behavioral detection logic tuned to flag unexpected SID-History attribute changes outside migration activity — it is a useful compensating control where advanced audit policy has gaps.

Remediation

1. Enable advanced audit policy for account management. Turn on "Audit User Account Management" so Event IDs 4765/4766 actually fire, and forward them to your SIEM with alerting on any hit outside a known migration change window.
2. Restrict and monitor DC-level and replication-equivalent access. Since injecting sIDHistory requires Domain Admin/SYSTEM access on a DC or a copy of ntds.dit, the highest-leverage control is the same one that stops DCSync and Golden Ticket attacks: minimize and audit accounts holding DS-Replication-Get-Changes-All and restrict interactive/RDP logon to Domain Controllers.
3. Audit sIDHistory across the domain on a recurring schedule, not just after a known migration. Any populated value containing a well-known privileged RID that isn't tied to a documented, time-boxed migration project should be treated as a critical incident.
4. Clean up sIDHistory after migrations complete. Once ACLs have been remediated to the new SIDs, clear the legacy sIDHistory values — a smaller attack surface with no leftover values is easier to monitor than one where "some SID history is expected."
5. Deploy an Identity Threat Detection and Response (ITDR) tool, such as Microsoft Defender for Identity, to add behavioral coverage for sIDHistory changes that complements static audit-log rules.

# Remove all sIDHistory values from an account once migration/remediation is complete
Set-ADUser -Identity lowpriv-svc -Clear sIDHistory

How EtcSec Detects This

EtcSec's Active Directory audit specifically distinguishes SID-History hygiene issues from active privilege-escalation indicators:

• SIDHISTORY_WELLKNOWN_SIDS (Critical) — flags any account whose sIDHistory attribute contains a well-known privileged RID (Domain Admins, Enterprise Admins, Schema Admins, Domain Controllers) matching the domain's own SID — the specific pattern described in this article, not generic SID History presence.
• SID_HISTORY (High) — flags any account with a populated sIDHistory, so legitimate post-migration cleanup work can be tracked and completed.
• SIDHISTORY_RECENT_CHANGES (Info) — surfaces objects where sIDHistory changed recently, to correlate against documented migration windows.
• DCSYNC_CAPABLE — flags the entry-point privilege (non-DC accounts holding replication rights) that is the typical prerequisite for reaching a DC and performing the injection in the first place.

Review Priorities

SIDHistory injection with well-known SIDs should be treated as a domain-dominance-level finding, not a routine hygiene gap. Start by enumerating every account with a non-empty sIDHistory, then separate documented migration artifacts from unexplained values — especially any matching a well-known privileged RID on the current domain's own SID. Confirm which Domain Controllers were reachable by which administrators and service accounts during the suspected window, since the technique requires DC-level or replication-equivalent access to execute. Because the injected privilege bypasses group-membership review entirely, any remediation plan that only audits group membership will miss it — the attribute itself has to be the source of truth.

Adjacent Controls to Review

SIDHistory injection rarely stands alone: the DC-level access it requires is the same access that enables DCSync credential extraction, Golden Ticket forgery, and direct ntds.dit theft. When investigating a suspected injection, review who held replication rights and DC logon access during the exposure window, whether KRBTGT was rotated recently, and whether any other privileged accounts show signs of tampering. A fix that clears one account's sIDHistory without closing the underlying DC-access path leaves the attacker free to inject it again — or into a different account entirely.

Related Reading

Review this topic together with Golden Ticket Attack: The Keys to Your Kingdom, ACL Abuse and DCSync: The Silent Paths to Domain Admin, Active Directory Trust Attacks: From Child Domain to Forest Root, Active Directory Privileged Accounts: Protected Users, Delegation, and Service Account Gaps, Dangerous Group Nesting in Active Directory, and Active Directory Monitoring: Security Event IDs That Matter.

• Golden Ticket Attack: The Keys to Your Kingdom
• ACL Abuse and DCSync: The Silent Paths to Domain Admin
• Active Directory Trust Attacks: From Child Domain to Forest Root
• Active Directory Privileged Accounts: Protected Users, Delegation, and Service Account Gaps
• Dangerous Group Nesting in Active Directory
• Active Directory Monitoring: Security Event IDs That Matter

Validation Checklist

Before closing the review, rerun the well-known-RID sIDHistory enumeration against production and confirm zero unexplained hits remain. Verify advanced audit policy is enabled on every Domain Controller so Event IDs 4765/4766 are actually generated, not just theoretically available. Confirm replication rights and DC logon access have been tightened to the accounts that genuinely need them, and record the evidence — the enumeration output and the audit policy state — as the baseline for the next recurring audit.