{ "id": "63a91ad2-b473-4d29-a05e-6d9813c214dd", "created_at": "2026-04-06T00:06:37.813505Z", "updated_at": "2026-04-10T13:12:43.164062Z", "deleted_at": null, "sha1_hash": "592dedf3160adb74108c9d99c88ddf77245896d5", "title": "Sneaky Active Directory Persistence #14: SID History", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 299647, "plain_text": "Sneaky Active Directory Persistence #14: SID History\r\nBy Sean Metcalf\r\nPublished: 2015-09-19 · Archived: 2026-04-05 17:27:33 UTC\r\nThe content in this post describes a method by which an attacker could persist administrative access to Active\r\nDirectory after having Domain Admin level rights for 5 minutes.\r\nI presented on this AD persistence method in Las Vegas at DEF CON 23 (2015).\r\nComplete list of Sneaky Active Directory Persistence Tricks posts\r\nSID History is an attribute that supports migration scenarios. Every user account has an associated Security\r\nIDentifier (SID) which is used to track the security principal and the access the account has when connecting to\r\nresources. SID History enables access for another account to effectively be cloned to another. This is extremely\r\nuseful to ensure users retain access when moved (migrated) from one domain to another. Since the user’s SID\r\nchanges when the new account is created, the old SID needs to map to the new one. When a user in Domain A is\r\nmigrated to Domain B, a new user account is created in DomainB and DomainA user’s SID is added to\r\nDomainB’s user account’s SID History attribute. This ensures that DomainB user can still access resources in\r\nDomainA.\r\nThe interesting part of this is that SID History works for SIDs in the same domain as it does across domains in the\r\nsame forest, which means that a regular user account in DomainA can contain DomainA SIDs and if the DomainA\r\nSIDs are for privileged accounts or groups, a regular user account can be granted Domain Admin rights without\r\nbeing a member of Domain Admins.\r\nNote: A regular user in a domain can contain the Enterprise Admin SID in its SID History from another domain in\r\nthe Active Directory forest, thus “elevating” access for the user account to effective Domain Admin in all domains\r\nin the forest. if you have a forest trust without SID Filtering enabled (also called Quarantine), it’s possible to inject\r\na SID from another forest and it will be added to the user token when authenticated and used for access\r\nevaluations.\r\nMimikatz enables SID History injection to any user account (requires Domain Admin or equivalent rights). In this\r\nscenario, the attacker creates the user account “bobafett” and adds the default administrator account for the\r\ndomain, “ADSAdministrator” (RID 500), to the account’s SID History attribute.\r\nhttps://adsecurity.org/?p=1772\r\nPage 1 of 5\n\nWhen the bobafett account logs on, all of the SIDs associated with the account are added to the user’s token which\r\nis used to determine access to resources. The SIDs associated with the account is the user’s SID, the group SIDs in\r\nwhich the user is a member (including groups that those groups are a member of), and SIDs contained in SID\r\nHistory.\r\nUsing the PowerShell Active Directory cmdlet “Get-ADUser”, we can see there is no group membership assigned\r\nto the bobafett account, though it does have a SID in SIDHistory (the ADSAdministrator account).\r\nWhen bobafett logs on, the SIDs associated with the account are evaluated and access determined based on these\r\nSIDs. Since the bobafett account is associated with the ADSAdmnistrator account (RID 500), the bobafett account\r\nhas all access the ADSAdministrator account has, including Domain Admin rights.\r\nLeveraging the bobafett user account and the rights granted to it through SID History, it is possible to use\r\nPowerShell remoting to pull the KRBTGT account password data from a Domain Controller.\r\nhttps://adsecurity.org/?p=1772\r\nPage 2 of 5\n\nDetection\r\nThe best way to detect SID History account escalation is to enumerate all users with data in the SID History\r\nattribute and flag the ones which include SIDs in the same domain*. If users haven’t been migrated, you can\r\nsimply search for all users with data in the SIDHistory attribute. This is why it’s important to clean up SID History\r\nafter a migration is complete (and the user is added to the correct groups for required resource access).\r\nThe PowerShell AD Cmdlet “Get-ADUser” is most useful for detecting “Same Domain SID History”:\r\n# Detect Same Domain SID History\r\nImport-Module ActiveDirectory\r\n[string]$DomainSID = ( (Get-ADDomain).DomainSID.Value )\r\nGet-ADUser -Filter “SIDHistory -Like ‘*'” -Properties SIDHistory | `\r\nWhere { $_.SIDHistory -Like “$DomainSID-*” }\r\nThis graphic shows the result of running the “Same Domain SIDHistory” Detection PowerShell Script. Note that\r\nthe SID in the user’s SIDHistory ends with “500” which is the default domain Administrator account which is a\r\nhttps://adsecurity.org/?p=1772\r\nPage 3 of 5\n\nmember of Administrators, Domain Admins, Schema Admins, and Enterprise Admins by default.\r\n*Note: In multi-domain forests, it is recommended to look for admin group SIDs (and member account SIDs) in\r\nevery domain in the forest as well as trusted domains/forests.\r\nDetection via Domain Controller Events\r\nDetection of successful modification or failed attempt to modify the SIDHistory attribute is possible with the\r\nfollowing logging:\r\nConfigure sub-category auditing under Account Management,  “Audit User Account Management” (success) on\r\nDomain Controllers for the following event ids:\r\n4765: SID History was added to an account.\r\n4766: An attempt to add SID History to an account failed.\r\nhttps://adsecurity.org/?p=1772\r\nPage 4 of 5\n\n(Visited 76,237 times, 3 visits today)\r\nSource: https://adsecurity.org/?p=1772\r\nhttps://adsecurity.org/?p=1772\r\nPage 5 of 5", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "origins": [ "web" ], "references": [ "https://adsecurity.org/?p=1772" ], "report_names": [ "?p=1772" ], "threat_actors": [], "ts_created_at": 1775433997, "ts_updated_at": 1775826763, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/592dedf3160adb74108c9d99c88ddf77245896d5.pdf", "text": "https://archive.orkl.eu/592dedf3160adb74108c9d99c88ddf77245896d5.txt", "img": "https://archive.orkl.eu/592dedf3160adb74108c9d99c88ddf77245896d5.jpg" } }