Windows SIDs, Integrity Levels, and Tokens — Preemptive Cyber Security

Windows authorization does not begin with a username. It begins with a security token: a runtime package of identities, groups, privileges, restrictions, and integrity level. SIDs identify principals; access control lists describe who may act; integrity levels add a second, directional boundary. Together, they explain why a process can access one object and is denied another.

The authorization question Windows asks

When a process requests an object such as a file, registry key, service, or named pipe, Windows evaluates the caller's access token against the object's security descriptor. The token describes who the caller is and what authority it carries. The descriptor describes what the object permits. This model is more reliable than assumptions based on account names, because the same user can run processes with different tokens, group memberships, privileges, or integrity levels.

Figure 1. Windows compares the requester's actual token with the object's access rules and mandatory integrity policy, then grants only the requested rights that survive both checks.

SIDs: durable identities, not display names

A Security Identifier (SID) is a variable-length value that identifies a security principal. A local account SID is scoped to its machine; a domain account SID incorporates the domain identifier plus a relative identifier (RID). Well-known SIDs identify built-in concepts such as Everyone, Authenticated Users, LOCAL SYSTEM, and the built-in Administrators group. Display names can be changed and localized; a SID is the value access checks use.

In an incident, resolve names for readability but preserve raw SIDs in evidence. A local administrator account on two machines may share a name yet be entirely different principals. Conversely, a renamed account retains its SID. SID history, nested groups, and orphaned ACL entries are all reasons to inspect authorization as data rather than as labels.

What is inside a token?

A primary token is attached to a process; an impersonation token can be attached to a thread temporarily when a service performs work on behalf of a client. Important fields include the user SID, enabled and deny-only group SIDs, logon session, privileges, default DACL, restricted SIDs, and integrity SID. Privileges are capabilities such as the ability to back up files or debug processes. They are distinct from normal DACL permissions and should be assigned sparingly.

Safe example: why an administrator can still be denied

With UAC enabled, a member of the local Administrators group typically launches a normal desktop process with a filtered, medium-integrity token. An elevated process receives a high-integrity token with administrative groups and privileges available. The account did not change; the token did. Inspect this safely in a lab with Sysinternals Process Explorer: select a process, open its Security tab, and compare a standard and elevated instance.

Integrity levels and Mandatory Integrity Control

Mandatory Integrity Control (MIC) labels tokens and securable objects with integrity levels, commonly Low, Medium, High, and System. The normal direction is deliberate: a lower-integrity process should not write to a higher-integrity object, even if a discretionary ACL might otherwise allow it. This protects administrative applications from ordinary desktop processes and supports sandboxing. MIC is an additional control, not a replacement for properly designed ACLs or application authorization.

Figure 2. A lower-integrity process cannot normally modify higher-integrity objects. Access checks still depend on both integrity policy and the object's DACL.

UAC and least privilege: design for the medium token

UAC is most effective when applications do not need elevation for ordinary tasks. Design user-facing software to run at medium integrity, isolate truly administrative actions into narrow, auditable elevation points, and avoid instructing users to disable UAC. In enterprise environments, separate standard and administrative accounts for privileged work, use phishing-resistant authentication, and prevent admins from browsing or reading email with privileged tokens.

Vulnerability context: token flaws are boundary failures

CVE-2022-21882 was a Windows Win32k elevation-of-privilege vulnerability exploited in the wild. CVE-2024-30088 was a Windows kernel elevation-of-privilege vulnerability also reported as exploited in the wild. Such flaws matter because they can let a lower-privileged context gain authority that token and integrity policy should have constrained. The defender's response is not to distrust tokens; it is to patch affected systems, retain EDR visibility, and investigate unexpected high-integrity or SYSTEM processes.

Defender workflow: investigate the token, then the path

Start with process context. Record executable path, hash, parent, command line, user SID, integrity level, and logon session.
Inspect group and privilege state. Use Process Explorer or the supported whoami /all command in an authorized session to identify groups, integrity level, and enabled privileges.
Review the object rule. Use icacls for file-system ACLs and appropriate management tools for services and registry keys. Look for broad write permissions on privileged paths.
Correlate elevation. Connect process creation, UAC consent, service creation, scheduled tasks, and logon events. A high-integrity child without an expected elevation path deserves review.
Fix the control plane. Remove unnecessary local-admin membership, reduce privileged group nesting, use LAPS for local accounts, and patch the operating system.

Key takeaways

SIDs are the identifiers Windows authorizes; names are a convenience layer.
Tokens carry the effective identity, groups, privileges, and integrity level of a process or thread.
MIC blocks lower-integrity code from writing upward, while DACLs still govern discretionary access.
Watch for unexplained high-integrity or SYSTEM process creation and preserve token evidence during triage.

#windows-defense#identity#access-control#uac