SID, RID and Windows Identity: The Foundational Mental Model

Core DFIR Mental Model

Inside the Windows security kernel and authorization protocols, username strings do not exist.

The Security Reference Monitor (SRM) exclusively evaluates and compares binary SIDs. Two accounts with the same display name possess different SIDs. A renamed account preserves its original SID. If an account is deleted and recreated with the exact same name, it receives a new SID and loses all prior object permissions.

Concept

A Security Identifier (SID) is a variable-length binary data structure utilized by Windows to definitively identify security principals:

• Users (human operators and service accounts).
• Security Groups (local, domain global, domain local, universal).
• Computers (COMPUTER$ domain machine accounts).
• Built-in contexts and special authorities (Well-Known SIDs).

The Relative Identifier (RID) is the terminal numerical sub-authority segment of the SID. It is assigned sequentially by the issuing authority (either the local host SAM or the Active Directory RID Master FSMO role holder).

---

Why This Matters in DFIR

For digital forensics and incident response analysts, SID fluency is essential to avoid catastrophic misattributions:

1. Account Recreation Traps: An adversary creates svc_temp, performs actions, and deletes it. A system administrator later legitimately creates an account with the same name. Log records contain the original SID (e.g., RID 1142), definitively proving the current account (RID 1185) did not author the historic malicious activity.
2. Offline Disk Triage: When analyzing disk images without live Domain Controller connectivity, Windows cannot resolve SIDs to text strings. Analysts must decompose raw SIDs to determine privileges.
3. Persistence via sIDHistory: Threat actors using Mimikatz can inject high-privileged SIDs (such as Domain Admins RID 512) into the sIDHistory attribute of a standard user. The account appears unprivileged in LDAP inspection, yet its logon access token contains administrative authority (see Doc 18: Cross-Domain Group Membership and Foreign Security Principals).

---

How It Works

1. Structural Anatomy of a SID

Consider the following SID string: S-1-5-21-3623811015-3361044348-30300820-1013

S - 1 - 5 - 21 - 3623811015 - 3361044348 - 30300820 - 1013
│   │   │   │   └──────────────────────────────────┘   └── RID (Relative Identifier)
│   │   │   │            Domain Identifier (Sub-Authority)
│   │   │   └── Non-unique Sub-Authority specifier (NT Authority)
│   │   └────── Top-Level Authority (5 = SECURITY_NT_AUTHORITY)
│   └────────── Revision Level (always 1 in current Windows)
└────────────── String Literal Prefix

• S: Standard string prefix identifying a SID.
• 1: Specification revision level.
• 5: Security Authority (SECURITY_NT_AUTHORITY).
• 21: Specifies that the subsequent authority identifies an Active Directory domain or local host SAM.
• 3623811015-3361044348-30300820: The Domain SID. A 96-bit random integer set assigned during OS setup or AD domain promotion. Every account belonging to this authority shares this identical prefix.
• 1013: The RID. Monotonically increasing identifier uniquely indexing the object within this domain or SAM.

2. Reserved RIDs & Well-Known SIDs

Certain RIDs and SIDs are universal across every Windows machine and Active Directory installation:

SID / RID	Representation	Authority & Scope
RID 500	Built-in Administrator	...-500 exists on every SAM host and AD domain.
RID 501	Built-in Guest	Disabled by default.
RID 502	krbtgt Service Account	Key distribution center service account in Active Directory.
RID 512	Domain Admins	Domain-wide administrative group.
RID 513	Domain Users	Standard domain user baseline group.
RID 516	Domain Controllers	Computer accounts of all DCs in the domain.
RID 519	Enterprise Admins	Forest-root administrative group.
S-1-5-18	NT AUTHORITY\SYSTEM	Operating system kernel identity (LocalSystem).
S-1-5-19	NT AUTHORITY\LOCAL SERVICE	Restricted local service context.
S-1-5-20	NT AUTHORITY\NETWORK SERVICE	Local service presenting host machine identity (COMPUTER$) on the network.
S-1-5-32-544	BUILTIN\Administrators	Local machine administrative group present on every Windows OS.

---

What Is Possible

• Renaming Without Altering Identity: Renaming Administrator to Guest_Support does not alter its RID 500. It retains full administrative powers.
• Determining Authority by Inspection: Comparing the 3 sub-authority blocks immediately demonstrates whether two log entries share the same domain authority or belong to separate SAMs.
• Tracking Orphaned ACLs: When an NTFS permission displays S-1-5-21-...-1045 rather than a name, it proves the principal was deleted from the directory or originates from an unreachable foreign domain.

---

What Is Not Possible

• Inheriting Permissions via Recreation: Deleting CORP\alice (RID 1105) and recreating CORP\alice yields RID 1106. The new object inherits none of the direct ACL permissions granted to RID 1105.
• Duplicate RIDs Within a Single Authority: The RID Master guarantees strict monotonicity and uniqueness within the issuing domain.
• Unprivileged SID Forgery: Standard users cannot modify or forge SIDs inside an active logon token; this requires kernel-level or LocalSystem privileges (SeTcbPrivilege).

---

Forensic Traps

Common Pitfalls

1. Confusing S-1-5-32-544 with S-1-5-21-...-512: S-1-5-32-544 is the local BUILTIN\Administrators group. S-1-5-21-...-512 is the domain Domain Admins group. By default, Domain Admins is added as a member of BUILTIN\Administrators on domain-joined machines, but they are separate entities.
2. Assuming Name Resolution Always Works: Forensic tools analyzing offline EVTX files without access to the live domain controller will display raw SIDs. These are the authoritative records.

---

Concrete DFIR Scenario: SIDHistory Abuse

In a forest with two domains (CHILD.CORP and ROOT.CORP), an adversary compromises CHILD.CORP and seeks persistent, undetected control over ROOT.CORP:

1. The attacker selects standard user CHILD\jdoe (SID: S-1-5-21-222-333-444-1102).
2. Using Mimikatz (misc::addsid), the attacker writes the SID of ROOT.CORP’s Domain Admins group (S-1-5-21-999-888-777-512) into jdoe’s sIDHistory attribute.
3. When jdoe authenticates, the KDC includes both the primary SID and all sIDHistory SIDs in the Kerberos authorization data (PAC).
4. When accessing services in ROOT.CORP, the target host inspects the token, locates S-1-5-21-999-888-777-512, and grants complete administrative control, despite ADUC showing jdoe as a standard user.

This mechanism is analyzed further in Doc 18: Cross-Domain Group Membership and Foreign Security Principals and Doc 24: Lateral Movement Across Active Directory Domains.

---

Forensic Artifacts

EventID: 4720 # User Account Created
TargetUserName: attacker_backup
TargetSid: S-1-5-21-3623811015-3361044348-30300820-1185   <-- Note assigned RID
SubjectUserSid: S-1-5-21-3623811015-3361044348-30300820-500

EventID: 4765 # SID History Added (Critical Alert)
TargetUserName: jdoe
TargetSid: S-1-5-21-222-333-444-1102
SidHistoryValue: S-1-5-21-999-888-777-512                   <-- Domain Admins injected

---

Investigation Methods

1. Detect Accounts with sIDHistory via PowerShell:

   Get-ADUser -Filter 'sidhistory -like "*"' -Properties sidhistory |
     Select-Object Name, SID, @{Name="sIDHistory";Expression={$_.sidhistory}}

2. Translate SID to Account Offline / Scripting:

   $objSID = New-Object System.Security.Principal.SecurityIdentifier("S-1-5-21-3623811015-3361044348-30300820-500")
   $objUser = $objSID.Translate([System.Security.Principal.NTAccount])
   $objUser.Value

---

Key Takeaways

1. The SID is the only identity validated by the Windows security engine.
2. The RID distinguishes unique objects within the same issuing domain or SAM.
3. RID 500 is permanently the built-in Administrator, regardless of language or renamed strings.
4. Deleting and recreating a user creates an entirely new SID and invalidates prior ACL rights.
5. sIDHistory allows an account to carry authorizations across domains.

---

Cross References

• Doc 01: Windows Identities: Local Accounts vs Domain Accounts
• Doc 06: Windows Access Tokens and Security Context
• Doc 18: Cross-Domain Group Membership and Foreign Security Principals