Windows Security Primitives — SIDs, Tokens, ACLs

What Windows Security Primitives Are and Why They Matter

Windows enforces every security decision — “can this process open that file?” — through a consistent set of primitives. These primitives are the foundation for authentication, authorization, and auditing across the OS.

• A SID (Security Identifier) uniquely identifies every security principal — user, group, computer, domain, or service.
• An access token represents a user’s identity and privileges on a specific system. Every process and thread has one.
• Integrity levels (Mandatory Integrity Control) classify trust levels — processes at a lower integrity level cannot write to higher-integrity objects.
• ACLs (Access Control Lists) and SACLs (System Access Control Lists) define who can do what to each object and which access attempts get audited.

MITRE ATT&CK maps privilege escalation techniques to T1134 (Access Token Manipulation). Understanding token manipulation is essential for detecting and triaging privilege escalation.

SIDs — Security Identifiers

Every security principal in Windows has a SID. It is the internal name that Windows uses — never the username.

SID Structure

S-R-I-S
│ │ │ └─ Subauthority (RID)
│ │ └─── Identifier Authority
│ └───── Revision
└─────── SID prefix

Example: S-1-5-21-3623811015-3361044348-30300820-500

• S — SID prefix
• 1 — Revision level
• 5 — Identifier Authority (NT Authority)
• 21-3623811015-3361044348-30300820 — Domain-specific identifier
• 500 — Relative ID (RID) — Administrator account

Well-Known SIDs

How to Find SIDs

# Current user SID
whoami /user

# All SIDs for current user and groups
whoami /all

# Well-known SIDs
whoami /groups

# Domain user SID from AD (find RID 500 = admin, 512 = Domain Admins, etc.)
net user username /domain

Forensic value: SIDs appear in logs, registry keys, and file system permissions. Recognizing well-known SIDs lets you identify privilege levels from log output alone.

Access Tokens

An access token is an object that describes a user’s security context on a system. Every process and thread has a primary token that determines what the process can do.

Token Contents

Token Types

Detection — Token Manipulation

SPL query — detect SeDebugPrivilege usage (Event 4672):

index=windows EventCode=4672
| search PrivilegeList IN ("*SeDebugPrivilege*", "*SeTakeOwnershipPrivilege*", "*SeBackupPrivilege*")
| stats count by Account_Name, ComputerName, PrivilegeList
| sort - count

Why it matters: SeDebugPrivilege allows opening any process (including LSASS) for memory read and write — a prerequisite for credential dumping.

Integrity Levels (Mandatory Integrity Control)

Windows Vista and later enforce Mandatory Integrity Control (MIC). Every process and every securable object has an integrity level. A process cannot write to an object with a higher integrity level — even if the DACL permits it.

Integrity Level Hierarchy

Protected Process (S-1-16-20480)
      ↑
  System (S-1-16-16384)
      ↑
   High (S-1-16-12288) — Administrator: elevated
      ↑
Medium Plus (S-1-16-8448)
      ↑
  Medium (S-1-16-8192) — Standard user: running normally
      ↑
    Low (S-1-16-4096) — Internet Explorer in Protected Mode
      ↑
Untrusted (S-1-16-0)

Real-World Integrity Level Implications

Security boundary: The boundary between Medium and High is the most important security boundary on Windows. UAC (User Account Control) enforces this — an admin on Medium cannot write to High objects without elevation.

UIPI (User Interface Privilege Isolation)

A process at a lower integrity level cannot send messages (mouse clicks, keyboard input) to a higher-integrity window. This is why an admin running non-elevated cannot “click OK” on a UAC prompt programmatically — it’s a UI-based security boundary.

ACLs, DACLs, and SACLs

Every securable object (file, registry key, process, service, printer) has a security descriptor that contains:

• Owner SID — who owns the object
• Group SID — primary group
• DACL (Discretionary Access Control List) — who can do what
• SACL (System Access Control List) — which access attempts generate audit logs

DACL — Who Can Access

A DACL contains Access Control Entries (ACEs). Each ACE grants or denies a specific access right to a specific SID.

ACE types:

Common file access rights:

SACL — Audit Configuration

A SACL defines which access attempts are logged in the Security Event Log. This is what powers Event IDs 4663 (access to an object) and 4656 (handle to an object requested).

SACL example — Audit successful write attempts to C:\Secrets\:

- Type: Success
- Principal: Everyone
- Access: Write
- Object: C:\Secrets\*

SPL query — detect object access audit events for sensitive files:

index=windows EventCode=4663
| search ObjectName IN ("*passwords*", "*secrets*", "*credentials*", "*sam*", "*system*")
| stats count by Account_Name, ObjectName, AccessMask, ProcessName
| sort - count

Reading ACLs

# View file ACL
icacls C:\Path\File.txt

# View registry key ACL
icacls HKLM\SYSTEM\CurrentControlSet\Services\* /t

# View process ACL — who can open this process?
icacls \\.\pipe\*

# View all accessible services
sc sdshow ServiceName

ACL output format:

C:\Secrets\data.txt
  BUILTIN\Administrators:(F)       # Full Control
  NT AUTHORITY\SYSTEM:(F)          # Full Control
  BUILTIN\Users:(R)                # Read only
  CONTOSO\Bob:(W)                  # Write allowed

Privileges — What a Token Can Do

Unlike permissions (which apply to specific objects), privileges apply system-wide. A privilege is the right to perform a specific security-relevant operation.

High-Value Privileges for Detection

How Privileges Are Used in Attacks

Putting It Together — A Forensic Walkthrough

When an analyst sees a process running as SYSTEM with SeDebugPrivilege, it can dump LSASS. Here is how the primitives chain together:

1. Who is running? → Check the process token’s User SID → SYSTEM (S-1-5-18) or Administrator (S-1-5-21-*-500)
2. What can they do? → Check token privileges → SeDebugPrivilege present and enabled
3. What trust level? → Check integrity level → High (S-1-16-12288) or System (S-1-16-16384)
4. Can they access the target? → Check target process DACL → Can the process SID open LSASS?
5. Are we auditing it? → Check SACL on LSASS process → Should generate Event 4663 or Sysmon Event 10

This chain of indicators — IoCs, IoAs, and TTPs explains why:

• A standard user (Medium integrity) cannot dump LSASS — no SeDebugPrivilege and cannot open LSASS handle
• An elevated admin (High integrity) can — but logs will show 4672 + Sysmon 10
• SYSTEM can always dump LSASS — but only legitimate SYSTEM services should be doing so

Related

• Credential Theft Incident Response — detection and response for T1558.001, T1003.001, T1134 techniques
• Privilege Escalation Investigation — detection and response for T1068 techniques
• Elastic Security — detection and response for T1654 techniques
• Cloud Security Fundamentals — detection and response for T1525 techniques
• Linux Security Fundamentals — detection and response for T1059, T1546, T1548 techniques

Sources

• Windows Security Model — Microsoft Docs
• Access Tokens — Microsoft Docs
• Mandatory Integrity Control — Microsoft Docs
• MITRE ATT&CK T1134 — Access Token Manipulation
• Well-Known SIDs — Microsoft Docs