Windows Security Check Process

pash4stud2

7 min read

·

May 12, 2026

--

Listen

Share

Windows implements various security checks at different levels and only when all relevant security layers are satisfied can an operation complete successfully. This post gives details on what and how the checks are implemented.

DACL

At the beginning there is what is known as ACL(Access Control List) which is part of the object’s security descriptor. Objects can be files, folders, Groups, registry keys, services, processes, events, pipes etc. Specifically for files and folders, these permissions are commonly exposed in the UI as NTFS permissions and this typically has Read, Write, Modify, Read and Execute, Full Control,List Folder Contents, Traverse Folder.

But underneath this is actually translated and implemented with more granular permission flags which can be seen using the “Integrity Control Access Control Lists (icacls)” utility which exposes the underlying ACL entries and integrity labels used by Windows security as seen below

icacls.exe C:\Users\
C:\Users\ NT AUTHORITY\SYSTEM:(OI)(CI)(F)
          BUILTIN\Administrators:(OI)(CI)(F)
          BUILTIN\Users:(RX)
          BUILTIN\Users:(OI)(CI)(IO)(GR,GE)
          Everyone:(RX)
          Everyone:(OI)(CI)(IO)(GR,GE)

The above output shows the resource access level for each user. Notice that the output above contains more granular flags than what we saw from the UI such as OI, CI, RX,RE,F etc. This will be covered in more depth in a separate post dedicated for ACL.

Once the Windows system checks and confirmed that the DACL(part of ACL) allows for an action the next thing that happens is Privilege Check

ACL is part of what is called as security descriptor and it defines who can access the object and how.

Security Descriptor

A security descriptor is attached to a securable object such as:

• files
• folders
• registry keys
• processes
• threads
• named pipes
• services
• kernel objects

It defines who can access the object and how.

A security descriptor typically contains:

1. Owner SID

• The Security Identifier (SID) of the owner of the object.
• The owner can usually modify permissions even if denied access otherwise.
• Example: S-1–5–21-…-1001

2. Group SID (mostly legacy/POSIX compatibility)

• Originally for POSIX subsystems.
• Rarely important in modern Windows security.

3. DACL (Discretionary Access Control List)

This is the most important part. The DACL contains ACEs (Access Control Entries) that specify:

• who is allowed
• who is denied
• what permissions they have

Example:

• User A → Read
• Administrators → Full Control
• Guest → Denied Write

If a DACL is:

• missing (NULL DACL) → disables discretionary access checks and effectively grants unrestricted access.
• empty → nobody gets access

4. SACL (System Access Control List)

Used for auditing and defines: which accesses should generate security audit logs.

Example:

• log every failed delete attempt
• audit successful writes

Requires special privilege to modify/view.

5. Control Flags

Metadata about the descriptor:

• inheritance rules
• whether ACLs are protected
• self-relative format
• etc.

Privileges

These are not the same as the NTFS/DACL permissions we saw previously and instead privileges are special system-level abilities stored in the token
Example: SeDebug , SeBackup. SeImpersonate

These privileges can bypass some DACL checks but only in specific operations and never universally override the integrity level(MIC) which we will talk next.

Example 1: SEBackupPrivilege
You can read files even if DACL denies it, BUT MIC still applied in many write/control scenarios and do not give full “ignore everything power”. So privileges can help bypass ACLs in special kernel-defined paths but they do not universally ignore integrity rules

Example 2: SeRestorePrivilege
Say DACL denies Alice to write to folder as part of restore operation but having SeRestorePrivilege overrides this behaviour but if the operation is happening from a process with low IL to high IL then this operation will fail.

Mandatory Integrity Control

Mandatory Integrity Control (MIC) introduces Integrity Levels: Low, Medium,High and SYSTEM. This ensures that a process at low IL is not allowed to specifically write or make changes to process or objects at high IL even if the logged in user is same and privileged user.

For example, we do not want a browser renderer process to write to or modify files inside the C:\Windows directory.

Historically, older browsers or browser components sometimes ran more directly with the user’s privileges, meaning that if the logged-in user had permission through the DACL, the browser process could potentially modify sensitive locations. To reduce this risk, Microsoft introduced Mandatory Integrity Control (MIC) in Windows Vista, where Internet-facing processes such as browser renderers could run at Low Integrity Level (Low IL).

With Low IL, even if the user’s account and the DACL technically allowed access to C:\Windows , the low-integrity browser process would still be prevented from modifying higher-integrity objects such as files and folders labeled with Medium or High IL. This added an additional security boundary beyond normal discretionary permissions.

Modern browsers use a more advanced sandboxing architecture. Today, browsers such as Google Chrome and Microsoft Edge typically run:

• the main browser/UI process at Medium Integrity Level
• sandboxed child processes (such as renderer processes handling untrusted web content) at Low IL and/or inside an AppContainer

This distinction matters because the entire browser is no longer uniformly restricted. Instead, modern sandboxing isolates the most exposed and untrusted components while allowing the main browser process to retain the privileges necessary for normal functionality.

As a result, even if an attacker successfully exploits a renderer process through malicious web content, the sandbox is designed to prevent that compromised process from modifying protected operating system locations such as C:\Windows, despite what the user's DACL permissions might otherwise allow.

Note that MIC allows read operations to resources at high IL(provided DACL allows this) but primarily restricts write and certain control operations from lower integrity processes to higher integrity objects.. This prevents malware's running at low IL making changes to resources,services, processes running at high IL

Integrity levels are enforced through:
1. Security tokens
2. Object labels
3. Mandatory policy ACEs

MIC primarily enforces:

1. No Write up(NW), preventing lower integrity processes from modifying higher integrity objects.
2. some objects may additionally use NoReadUp or NoExecuteUp policies but this mostly uncommon in standard desktop scenarios

Security tokens

A security token represents a user/session/process identity. It is created when a user logs in. Processes and threads carry tokens of the user under the context of the user that has logged in. This is A.K.A Security Context of a user.

A token contains things like:

• User SID
• Group SIDs
• Privileges (SeDebugPrivilege, etc.)
• Integrity level
• Logon session ID
• Default DACL
• Token type (primary/impersonation)
• Restricted SIDs

Relationship Between Security Descriptor and Security Token

When a process tries to access an object:

1. The process presents its security token
2. Windows checks the object’s security descriptor
3. The access check compares:

• token SIDs/groups/privileges
• against DACL ACEs

4. Access is granted or denied

Example

Suppose the token says: User = Alice, Group = Developers
File Security Descriptor says: Developers → Read, Admins → Full Control
Result: Alice gets Read access.

Summary so far

Security descriptor defines who can access the object and how using DACL part.

At the next level we have “System-level” privileges that can override the DACL decision only for certain operations

MIC enforces no write up and some execute restrictions on low IL process over high IL objects/processes

To write, All the following must be true in a normal operation:

1. DACL allows write
2. IL is equal or higher
3. Privileges (if required) can override ACL only is specific system calls like backup/restore operations, take ownership, debug operations

Mental Model

1. Does DACL allow access?
2. Does MIC(IL) allow write-up?
3. Does token have required privilege?
4. Is operation restricted by UAC/elevation, In othetrwords,
   "Is the process running with an elevated token?"

Lets now combine all that we have learnt with a couple of scenarios

Scenario 1

Alice(non-admin user) logs in and Windows creates a standard user access token through the Local Security Authority Subsystem Service (LSASS) and wants to access a file in C:\Windows to modify a file. Even though an entry within DACL allows Alice to do this, but say if MIC fails because the application/process that alice using to access is running at low IL then this operation will be restricted.

Alice wants to perform a backup operations but the entry inside the DACL of the object does not grant this permission. However Alice was granted the SeBackup privilege by an administrator and if the backup operation is being done from a application/process running at an integrity level equal to or higher than the target object’s integrity level, Alice will then be able to perform the backup.

Scenario 2

Bob who is an administrator , logs in and gets split tokens standard and elevated(needs UAC to use the elevated token). By default, most applications run using the filtered standard user token at Medium Integrity Level.

Say Bob wants to run tshark command on the network interface to capture the packets. The standard medium-integrity token does not possess the required administrative privileges to access the packet capture driver restricting Bob. However, the same operation can be performed by Bob without any issues by launching the cmd prompt as administrator using the “run as administrator command”.

That elevation prompt is part of User Account Control (UAC), which separates standard and elevated administrator tokens.

I have used my artistic license while explaining access-check order to get a strong conceptual understanding. However the exact access-check order would be somewhat as follows

• Mandatory Integrity Control (mandatory policy)
• DACL evaluation
• Privilege-based overrides for specific operations
• Additional object-specific checks
• UAC/UIPI/elevation restrictions (depending on operation)

Note: Most Windows access checks are ultimately enforced by the Security Reference Monitor (SRM) in kernel mode through routines such as SeAccessCheck

Simplified Windows Access Check Flow

1. The process/thread presents its security token.
2. Windows evaluates Mandatory Integrity Control (MIC).
3. Windows evaluates the object’s DACL against the token SIDs.
4. Certain privileges may override parts of the access check for specific operations.
5. Additional protections may apply:

• UAC elevation state
• UIPI
• Protected Process Light (PPL)
• AppContainer restrictions
• Object-specific security callbacks

Hopefully this makes you better positioned next time when you are thinking security between users/accounts and objects. In upcoming post we will try to dig more into each of these individual topics like DACL, UAC.