2 - Windows Permissions

Topics

1. Introduction to the Windows Shells

2. Windows Permissions

3. Reverse Shells in Windows

4. SeImpersonatePrivilege Exploitation

5. On Cross Compilation

6. Windows Services

7. Weak Service Permissions

8. Unquoted Service Path

9. DLL Hijacking

10. Always Install Elevated

11. Files with Sensitive Data

12. Windows Hashes

13. Stored Credentials and the Windows Vault

14. Scheduled Task

15. Critical Registry Paths

16. Useful Tools

17. AMSI Bypass

Authentication, Authorization and Session Management

Authentication

Authentication is the process of verifying the identity of a user or entity attempting to access a system. Windows supports several authentication mechanisms, including:

• Password-Based Authentication: Verifies user credentials stored in the Security Account Manager (SAM) or Active Directory.

• Kerberos Protocol: A ticket-based authentication method used in domain environments.

• NTLM (NT LAN Manager): A challenge-response authentication protocol for non-domain systems or backward compatibility.

• Biometric Authentication: Uses features like Windows Hello for facial recognition or fingerprint scanning.

Authorization

Authorization determines what actions a user or process is permitted to perform after authentication. It relies on:

• Access Control Lists (ACLs): Define the permissions for objects, like files or registry keys.

• Group Memberships: Users inherit permissions based on their group affiliations, such as "Administrators" or "Users."

• Security Policies: Set through Group Policy to enforce restrictions or grant privileges.

Session Management

Session management handles user sessions to ensure secure and isolated execution of processes.

• Logon Sessions: Created when a user logs in and managed by the Local Security Authority Subsystem Service (LSASS).

• Session Isolation: Ensures that one user’s processes and data cannot interfere with another’s.

• Access Tokens: Generated during authentication to represent the user and their permissions throughout the session.

Security Principals and Security Identifiers (SIDs)

Security Principals

Security principals are entities that can be authenticated and granted access to resources, they can be:

• Users (e.g., JohnDoe)

• Groups (e.g., Administrators)

• Computer accounts

• Threads or processes

Security Identifiers (SIDs)

A SID is a unique, immutable identifier assigned to each security principal. SIDs are used internally by Windows to track permissions and rights.

• Structure of a SID:

  S-1-5-21-<DomainID>-<SubAuthority1>-<SubAuthority2>-<RID>

  • S-1: Identifier authority (Windows NT SID).

  • 5: Security authority (NT Authority).

  • 21: Identifier for domain or local computer.

  • <RID>: Relative identifier unique to the principal.

SIDs are generated by different components depending on the situation:

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

• The SID for domain users and domain group is generated by the Domain Controller (DC)

Well-Known SIDs

Predefined SIDs for commonly used entities. Examples include:

• S-1-5-18: Local System account.

• S-1-5-32-544: Administrators group.

• S-1-1-0: Everyone group.

How to Obtain a SID

• Using PowerShell:

  Get-ADUser -Identity <username> | Select-Object SID

• Using CMD:

  whoami /user

---

Access Tokens

An access token is an object that describes the security context of a process or thread. The information in a token includes the identity and privileges of the user account associated with the process or thread. When a user logs on, the system verifies the user's password by comparing it with information stored in a security database. If the password is authenticated, the system produces an access token. Every process executed on behalf of this user has a copy of this access token.

The system uses an access token to identify the user when a thread interacts with a securable object or tries to perform a system task that requires privileges. Access tokens contain the following information:

Access tokens contain the following information:

• The security identifier (SID) for the user's account
• SIDs for the groups of which the user is a member

• A logon SID that identifies the current logon session
• A list of the privileges held by either the user or the user's groups
• An owner SID

• The SID for the primary group

• The default DACL that the system uses when the user creates a securable object without specifying a security descriptor
• The source of the access token

• Whether the token is a primary or impersonation token
• An optional list of restricting SIDs
• Current impersonation levels

• Other statistics

---

File Permissions and ACLs

File Permissions

Permissions determine how users and processes can interact with files and folders. Common permissions include:

• Read: View file contents.

• Write: Modify file contents.

• Execute: Run executable files.

Access Control Lists (ACLs)

An access control list (ACL) is a list of access control entries (ACE). Each ACE in an ACL identifies a trustee and specifies the access rights allowed, denied, or audited for that trustee.

The security descriptor for a securable object can contain two types of ACLs:

• Discretionary ACL (DACL): Specifies who can access an object and their permissions.

• System ACL (SACL): Defines auditing rules for tracking access events.

To check ACLs:

• PowerShell:

  Get-Acl -Path C:\file.txt

• CMD:

  icacls C:\file.txt

icaclsdocsmsft

---

Mandatory Integrity Control (MIC)

MIC adds an additional layer of security by assigning integrity levels to processes and objects.

• Integrity Levels:

  • Low: Limited rights (e.g., internet browsers).

  • Medium: Standard user privileges.

  • High: Elevated privileges (administrators).

  • System: Reserved for OS processes.

• Effect: Objects with lower integrity levels cannot modify objects with higher levels.

View integrity levels:

icacls file.txt /displayintegritylevel

User Account Control (UAC)

User Account Control (UAC) is a security feature in Windows designed to minimize the risk of unauthorized changes to the operating system. By requiring administrative approval for elevated tasks, UAC helps prevent malware and unintentional system modifications.

• Separation of Privileges: Even when logged in as an administrator, users run most applications with standard user permissions. Elevation is required for tasks that could impact system integrity or security.

• Protection Against Malware: Prevents unauthorized programs from making changes by prompting for user consent or administrative credentials.

• Compliance: Aligns with the principle of least privilege (PoLP), ensuring users operate with the minimum required permissions.

How UAC Works

When an application or process requests elevated privileges:

1. Prompt Displayed: UAC prompts the user with a dialog box indicating that an application is requesting higher privileges.

2. Secure Desktop Mode: The desktop dims (a feature called Secure Desktop) to prevent other applications from interacting with the UAC prompt.

3. User Interaction Required: The user must either allow or deny the elevation request.

4. Elevation or Denial:

   • If allowed, the process receives an elevated token with administrative privileges.

   • If denied, the process continues with standard privileges or exits.

Disclaimer

❗ Never use tools and techniques on real IP addresses, hosts or networks without proper authorization!❗