Here I would write about security mechanisms in Windows. Since Windows theory is very broad, and to avoid making the theory page bloated, I would write here about the security side of Windows.
Authentication is process of verifying who someone is.
Authorization is process of determining what someone is allowed to do.
Security principals are anything that can be authenticated by the Windows operating system, including user and computer accounts, processes that run in the security context or another user/computer account, or the security groups that these accounts belong to. Every single security principal is identified by a unique Security Identifier (SID). When a security principal is created, it is assigned a SID which remains assigned to that principal for its lifetime.
User Authentication and Access Token Generation. A user logs into the system or attempts to access a resource. The system authenticates the user and generates an access token.
Request to Access a Securable Object. The user attempts to access a securable object. The object has a security descriptor that includes its Access Control List (ACL). The ACL contains Access Control Entries (ACEs), which define which SIDs (users or groups) have specific permissions to access the object.
Comparison of Access Token and Security Descriptor. The system compares the user's access token (SIDs and privileges) with the object's ACEs in the security descriptor. Permissions such as Read, Write, Execute, etc., are checked against the ACEs to determine whether the user has the required access rights.
Access Decision.
The Security Accounts Manager is a database file in the Microsoft Windows operating system that contains usernames and passwords. The SAM is available in different versions of Windows, including XP, Vista, 7, 8.1, 10 and 11. Each user account can be assigned a local area network (LAN) and a password would be hashed and stored in the SAM. The passwords hashes are stored in HKEY_LOCAL_MACHINE\SAM, but the access to it is restricted. HKLM/SAM and SYSTEM privileges are required for accessing it.
Security Identifier (SID) is unique, system-generated identifier for each security principal on a system. Even identical users are distinguished by their SIDs, which determine their permissions. SIDs are stored in the security database and included in access tokens to manage user actions.
A SID consists of the Identifier Authority and the Relative ID (RID). In an Active Directory (AD) domain environment, the SID also includes the domain SID.
(SID)-(revision level)-(identifier-authority)-(subauthority1)-(subauthority2)-(etc)
S-1-5-21-674899381-4069889467-2080702030-1002
Number
Meaning
Description
S
SID
Indicates the string is a SID.
1
Revision Level
Always 1, showing the SID format version.
5
Identifier Authority
Identifies the authority (e.g., computer or network) that created the SID.
21
Subauthority 1
Shows the user's relation or group to the authority that created the SID.
674899381-...
Subauthority 2
Identifies the specific computer or domain that created the SID.
1002
Subauthority 3 (RID)
Differentiates accounts, indicating roles like user, guest, or administrator. (If you enumerated previous value via enum, you can bruteforce RID to get a lot objects SID's)
Local Security Authority Subsystem Service (LSASS) is a collection of many modules and has access to all authentication processes that can be found in %SystemRoot%\System32\Lsass.exe. lsass.exe is the process that is responsible for enforcing the security policy on Windows systems.
When a user successfully logs in, LSASS constructs a full access token that contains the user SID, group SIDs, SIDHistory (if any), assigned privileges, and integrity level. This access token reflects the user’s effective identity and security context, and it gets attached to every process the user runs.
If the user is part of the Administrators group and UAC is enabled, Windows will split the LSASS-issued token into two versions:
Standard Token (medium integrity) with filtered privileges and admin groups marked as deny-only
Elevated Token (high integrity) that retains full admin privileges
This token split ensures users don’t run with full admin rights by default, supporting the principle of least privilege while still allowing elevation when needed.
All events associated with this process (logon/logoff attempts, etc.) are logged within the Windows Security Log. LSASS is an extremely high-value target as several tools exist to extract both cleartext and hashed credentials stored in memory by this process.
LSA Secrets are sensitive data stored by the Local Security Authority (LSA) on Windows systems. Key Types of LSASS Secrets are:
Hashes LSASS stores password hashes for logged-in users. These can be used in attacks like Pass-the-Hash to authenticate without knowing the plain-text password.
Kerberos Tickets LSASS holds Kerberos tickets (TGTs and service tickets) used in Active Directory environments to authenticate users across the network.
Plain-Text Passwords In some cases, LSASS may store plain-text passwords or reversible encryption keys for convenience in single sign-on (SSO) scenarios.
Security Tokens LSASS maintains security tokens that represent a user’s session and define what resources the user can access.
This data is stored in the Windows Registry at HKEY_LOCAL_MACHINE\Security\Policy\Secrets
Full Control
Allows reading, writing, changing, and deleting files/folders.
Modify
Allows reading, writing, and deleting files/folders.
List Folder Contents
Allows viewing and listing folders/subfolders and executing files. Folders inherit this permission.
Read and Execute
Allows viewing, listing files/subfolders, and executing files. Inherited by both files and folders.
Write
Allows adding files to folders and writing to a file.
Read
Allows viewing and listing folders/subfolders and reading file contents.
Traverse Folder
Allows moving through folders to access files, even without permission to list or view folder contents.
Inheritance in NTFS allows permissions to propagate from a parent folder to its subfolders and files. This ensures consistent permissions throughout a directory structure. Modifiers like (CI), (OI), and (IO) define how permissions are inherited by child objects.
CI
Container Inherit
Applies permissions to subfolders (but not files) within the parent folder.
OI
Object Inherit
Applies permissions to files (but not subfolders) within the parent folder.
IO
Inherit Only
Ensures permissions are inherited but not applied directly to the parent.
NP
Do Not Propagate Inherit
Prevents permissions from propagating further to child objects.
I
Permission Inherited from Parent
Indicates that the permission was inherited from a parent container.
F
Full Access
Grants all permissions, including modifying and deleting.
D
Delete Access
Allows deletion of the file or folder.
N
No Access
Denies all access to the file or folder.
M
Modify Access
Allows reading, writing, and deleting content.
RX
Read & Execute
Allows reading and executing files.
R
Read-Only Access
Permits viewing and listing of contents.
W
Write-Only Access
Allows adding new files and data but not reading.
NTLM (NT LAN Manager) is a challenge-response authentication protocol used by Microsoft for securing user credentials during authentication—primarily in older Windows environments or for backwards compatibility.
NTLM uses a 3-step challenge-response mechanism to authenticate a user without transmitting their password over the network:
Client sends a NEGOTIATE_MESSAGE to the server indicating it supports NTLM.
Server replies with a CHALLENGE_MESSAGE containing randomly generated 8-byte nonce (server challenge) and target information (like domain name, server name, etc.).
Client uses the server challenge and its own password-derived hash to calculate a response (using DES/MD4 depending on NTLM version).
Sends an AUTHENTICATE_MESSAGE containing:
The username
Domain
LM/NTLM response
And optionally a session key
Access Control List (ACL) is a list of rules that specifies which users or groups are allowed to access an object, such as a file or folder, and what actions they can perform (e.g., read, write, or execute).
Discretionary Access Control List (DACL) is a type of ACL that defines the permissions for users and groups to access an object. It controls what actions can be performed on the object by each user or group, and the owner of the object can modify the DACL.
System Access Control List (SACL), on the other hand, specifies what events related to an object should be logged for auditing purposes. It helps track access attempts, whether successful or not.
Access Control Entry (ACE) is an individual entry in an ACL that defines which users, groups, or processes have access to a file or to execute a process, for example. Each ACE lists the access rights granted or denied to a principal (user or group).
Each ACE is made up of the following four components:
Security identifier (SID) of the user/group that has access to the object (or principal name graphically).
Flag denoting the type of ACE (access denied, allowed, or system audit ACE).
Set of flags that specify whether or not child containers/objects can inherit the given ACE entry from the primary or parent object.
Access mask which is a 32-bit value that defines the rights granted to an object.
User Account Control (UAC) is a security feature in Windows to prevent malware from running or manipulating processes that could damage the computer or its contents.
Applications and tasks always run under the security context of a non-administrator account unless an administrator explicitly authorizes these applications/tasks to have administrator-level access to the system to run. It is a convenience feature that protects administrators from unintended changes but is not considered a security boundary.
Administrator user is given 2 tokens: a standard user key, to perform regular actions as regular level, and one with the admin privileges.
User can sign into their system using a standard account. When processes run under a standard user token, they operate with the permissions assigned to a regular user. However, certain applications need elevated privileges to function properly, and UAC allows them to receive additional access rights as needed.
The default RID 500 administrator account always operates at the high mandatory level. With Admin Approval Mode (AAM) enabled, any new admin accounts we create will operate at the medium mandatory level by default and be assigned two separate access tokens upon logging in. In the example below, the user account ven17 is in the administrators group, but cmd.exe is currently running in the context of their unprivileged access token.
Permission in Windows controls access to a specific object such as a file, folder, registry key, or service. Permissions are stored inside a Discretionary Access Control List (DACL) attached to the object. Each permission is represented by an Access Control Entry (ACE) that maps a Security Identifier (SID) to a set of allowed or denied actions like Read, Write, Execute, or Delete. Permissions are evaluated every time a user or process attempts to access an object, during what is called the Access Check.
Privilege is a special ability tied to an access token that allows a user or process to perform sensitive system operations, often related to kernel-level functions. Examples include SeDebugPrivilege (debugging other processes), SeBackupPrivilege (reading any file regardless of permissions), or SeImpersonatePrivilege (impersonating another user's security context). Privileges are checked only when a privileged action is requested, not at regular file or resource access.
Right is a system-wide rule that determines whether a user or group is allowed to perform a general action on the system, like logging on locally, logging on over RDP, or shutting down the computer. Rights are managed through security policy (Local Security Policy or Group Policy) and are checked only during the logon phase, when the system validates if a user is permitted to log in in a specific way. Rights are not evaluated when accessing objects like files or registry keys later.
User presents credentials.
LSASS authenticates using Kerberos/NTLM.
If successful → LSASS creates Logon Session and Primary Access Token (SID + Groups + Privileges).
User launches a process.
Primary Access Token is assigned to the new process.
All new child processes inherit the parent’s token unless overridden.
Process requests an operation (read, write, delete, start service, etc.).
Access Check Begins
OS reads process's Access Token.
OS reads object's Security Descriptor (contains DACL/SACL).
Compares process's SIDs to object's ACEs.
Deny ACEs evaluated first.
Allow ACEs evaluated second.
Requested permissions compared to allowed permissions.
If action requires a special Privilege (e.g., SeBackupPrivilege, SeDebugPrivilege),
OS checks if token has it and if it's enabled.
If SID + ACE match and permissions sufficient → Access Granted.
Otherwise → Access Denied.
