Security
Last updated
Last updated
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.
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 attempts to log on to the system, this process verifies their log on attempt and creates access tokens based on the user's permission levels. LSASS is also responsible for user account password changes.
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
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).
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.
When UAC is enabled, 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.
With UAC enabled, a 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.
When UAC is in place, an administrator user is given 2 tokens: a standard user key, to perform regular actions as regular level, and one with the admin privileges.
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.
Access tokens in Windows define the security context of a process or thread, including a user’s identity and privileges. When a user logs in, they are assigned an access token after successful authentication. This token is used to determine the user’s permissions whenever they interact with processes or resources.
