Access Controls

Permissions

In AD, permissions are assigned to objects through Access Control Entries (ACEs), which form an Access Control List (ACL). When a user attempts to access an AD object, the object checks the ACL to verify if the user has the necessary permissions. For example, when a domain user tries to access a domain share (an AD object), the object checks the user's permissions through its ACL, which is a two-step process:

1. The user sends an access token containing their identity and permissions.

2. The object compares the token against its ACL to determine if access should be granted or denied.

If the ACL allows access, the user is granted permission to access the share; otherwise, the request is denied. The main permissions of interest to attackers include: GenericAll (full access), GenericWrite (edit attributes), WriteOwner (change ownership), WriteDACL (edit ACE's applied), AllExtendedRights (change/reset password), ForceChangePassword (password change), and Self (add ourselves to a group).

ACEs can be enumerated with PowerView.

SIDs

A Security Identifier (SID) is a unique value assigned to each entity, or principal, that can be authenticated by Windows, such as users and groups. The SID is unmutable and is generated when the user or group is created.

• The SID for local accounts and groups is generated by the Local Security Authority (LSA)

• The SID for domain users and domain groups, it's generated on a Domain Controller (DC)

SIDs have the following format: S-R-X-Y.

• S: Indicates it's a SID.

• R (Revision): Always 1.

• X (Identifier Authority): Specifies the authority that issued the SID (e.g., 5 for NT Authority).

• Y (Sub Authorities): Includes the domain/machine identifier and the Relative Identifier (RID), which uniquely identifies users or groups. For example, for S-1-5-21-1336799502-1441772794-948155058-1001, the RID 1001 suggests it's the second local user on the system, since local RIDs start at 1000.

Some SIDs have RIDs under 1000 (well-known SIDs) representing built-in users and groups:

• S-1-0-0 → Nobody

• S-1-1-0 → Everybody

• S-1-5-11 → Authenticated Users

• S-1-5-18 → Local System

• S-1-5-domainidentifier-500 → Administrator

Access Tokens

Once a user logs in, Windows creates an access token to determine what actions they can perform. This token contains important security details, forming the security context of the user. An access token consists of:

• The SID of the user as well as the SIDs of groups the user belongs to

• Privileges assigned to the user and groups

• Additional info defining the token's scope

There are different types of tokens:

1. Primary Token: assigned to a process when a user starts it and defines what actions the process can take based on the user’s permissions.

2. Impersonation Token: used by a thread to temporarily act as another user (provide a different security context than the process that owns the thread) and lets a process perform actions with different security privileges.

Mandatory Integrity Control

Windows uses MIC to restrict access between processes based on their integrity levels. This prevents lower-trust processes from modifying higher-trust objects, even if they have the right permissions. Processes and objects inherit the integrity level of the user who creates them, unless the executable has a low integrity level, in which case any process it starts will also have a low level. Lower-integrity processes cannot modify higher-integrity objects. From Windows Vista onwards, there are five integrity levels:

1. System: Used by kernel-mode processes with SYSTEM privileges

2. High: Assigned to processes with admin privileges

3. Medium: The default for standard user processes

4. Low: Used for sandboxed processes (e.g., web browsers)

5. Untrusted: The most restricted level, assigned to risky processes

Integrity levels can be checked using Process Explorer (process integrity), via the whoami /groups command (user integrity), and via the icalcs command (file integrity).

User Account Control

UAC is a security feature that prevents unauthorized privilege escalation by restricting applications to standard user privileges, even if the user is an Administrator. When an Administrator logs in, Windows creates two access tokens:

1. Standard User Token (default, used for regular tasks)

2. Administrator Token (activated only when elevated privileges are required)

To use admin privileges, the user must confirm a UAC prompt.

UAC ensures applications run at the right privilege level, protects system files and registry keys from accidental or malicious changes, and prevents malware from gaining full control of the system without user approval. Processes run at four different integrity levels:

1. System: Kernel-mode processes with SYSTEM privileges

2. High: Used for administrative tasks

3. Medium: Default level for standard user applications

4. Low: Used for sandboxed processes (e.g., web browsers)

Being an Administrator does not mean all processes run with high integrity by default. UAC ensures privilege separation, requiring explicit approval for elevated actions. Attackers and penetration testers often seek to bypass UAC to execute processes at high integrity, allowing unrestricted access to system resources.