Windows PrivEsc: From Standard User to SYSTEM Administrator

Before exploring specific exploits, one must understand how Windows handles authorization. When a user logs onto a Windows machine, the Local Security Authority (LSA) authenticates their credentials and generates an Access Token.

Think of this Access Token as a digital ID badge. It contains the user's Security Identifier (SID), the SIDs of the groups they belong to (e.g., Domain Users, Local Administrators), and a list of specific privileges they hold (e.g., SeBackupPrivilege, SeImpersonatePrivilege). Every time a process or thread attempts to interact with a securable object (like opening a file, writing to a registry key, or starting a service), the Windows Security Reference Monitor checks the Access Token against the object's Access Control List (ACL) to determine if the action is permitted.

The goal of Windows PrivEsc is essentially to acquire or manipulate an Access Token that possesses higher privileges than the one currently assigned to the attacker's initial shell.

Windows Privilege Escalation rarely relies on highly sophisticated zero-day kernel exploits. Instead, it overwhelmingly capitalizes on misconfigurations, lazy administration, and insecure default settings in third-party software.

1. Unquoted Service Paths

When a Windows Service is created, the operating system must be told where the executable file for that service is located on the hard drive. If this file path contains spaces (e.g., C:\Program Files\Enterprise App\service.exe) but the path is not enclosed in quotation marks within the registry configuration, a critical vulnerability known as an Unquoted Service Path is introduced.

Due to how the Windows API parses commands, when it attempts to start a service with an unquoted path containing spaces, it doesn't immediately go to the final executable. Instead, it tries to execute every word before the space as an executable file, in sequential order.

In our example, Windows will attempt to execute:

1. C:\Program.exe
2. C:\Program Files\Enterprise.exe
3. C:\Program Files\Enterprise App\service.exe (The actual service)

If a low-privileged attacker has write permissions to the root of the C:\ drive (which is surprisingly common) or the C:\Program Files\ directory, they can place a malicious executable named Program.exe in that location. The next time the vulnerable service starts—typically running as SYSTEM—Windows will execute the attacker's Program.exe instead of the legitimate service. The malicious payload will execute with SYSTEM privileges, granting the attacker total control.

2. Insecure Service Permissions

Sometimes, the vulnerability lies not in the path, but in the permissions governing the service itself or its underlying executable.

• Weak Executable Permissions: If the executable file that a service runs (e.g., C:\Apps\MyService\run.exe) has an Access Control List (ACL) that allows the "Everyone" or "Users" group to modify or overwrite it, an attacker can simply replace the legitimate run.exe with a malicious payload. Upon reboot or service restart, the payload executes as SYSTEM.
• Weak Registry Permissions: Services are configured in the Registry under HKLM\SYSTEM\CurrentControlSet\Services. If a standard user has write access to a service's registry key, they can modify the ImagePath value to point to their own malicious executable instead of the intended service binary.
• Weak Service Configuration Permissions: Using tools like accesschk.exe, an attacker might discover they have SERVICE_CHANGE_CONFIG rights over a service running as SYSTEM. This allows them to use the sc config command to directly change the path of the executable the service launches, replacing it with a malicious payload.

3. The AlwaysInstallElevated Misconfiguration

Windows Installer (.msi files) normally executes with the privileges of the user running the installation. However, administrators can use Group Policy to enable a setting called AlwaysInstallElevated. If this setting is enabled in both the Local Machine and Current User registry hives, it instructs Windows to run all .msi installations with full NT AUTHORITY\SYSTEM privileges, regardless of who initiated the installation.

This is a massive security risk designed for convenience (allowing users to install software without bothering the Help Desk). An attacker who discovers this misconfiguration can use a tool like msfvenom to generate a malicious .msi payload containing a reverse shell. When the attacker executes the .msi file from their low-privileged command prompt, the payload executes as SYSTEM, providing an immediate administrative shell.

4. Token Impersonation (The "Potato" Attacks)

Token Impersonation is a complex but highly effective technique often utilized by Red Teams. It exploits the SeImpersonatePrivilege or SeAssignPrimaryTokenPrivilege. These privileges are typically assigned to service accounts (like those used by IIS or SQL Server) to allow them to impersonate a user (e.g., a web user) when accessing local resources.

If an attacker compromises one of these service accounts, they possess the SeImpersonatePrivilege. They can then use tools like Juicy Potato, Rogue Potato, or PrintSpoofer to trick a highly privileged SYSTEM process (often via complex COM/DCOM interactions or RPC calls) into authenticating to a malicious listener controlled by the attacker.

When the SYSTEM process authenticates, the attacker captures its SYSTEM Access Token and uses their SeImpersonatePrivilege to apply that token to their own malicious process, instantly elevating their privileges from a service account to full SYSTEM.

During an internal penetration test, an operator gains access to a developer's workstation via a phishing payload, resulting in a shell running as the user jdoe. jdoe is a standard Domain User with no local administrative rights.

1. Reconnaissance: The operator uploads a tool like WinPEAS (Windows Privilege Escalation Awesome Scripts) to automate the enumeration of the system.
2. Discovery: WinPEAS flags a vulnerable service named BackupService. The service is configured to start automatically, runs as LocalSystem, and its ImagePath is C:\Program Files\Backup Utility\backup.exe (unquoted).
3. Permission Check: The operator uses icacls to check the permissions of C:\Program Files\. They discover that due to a misconfiguration by the IT team, the "Users" group has write access to the C:\Program Files\ directory.
4. Exploitation: The operator generates a malicious executable containing a reverse shell and names it Backup.exe. They place this file directly in C:\Program Files\.
5. Execution: The operator reboots the workstation (if they have the rights) or waits for the user to reboot. When Windows restarts, it attempts to launch BackupService. Due to the unquoted path, it executes C:\Program Files\Backup.exe instead of the legitimate utility.
6. Escalation: The operator receives a reverse shell connection on their attack infrastructure. Running whoami reveals the current user is NT AUTHORITY\SYSTEM. The operator now has total control of the workstation and can begin dumping credentials to pivot further into the network.

Preventing Windows Privilege Escalation requires a fastidious approach to system configuration and continuous auditing.

1. Quote Service Paths: Administrators must ensure that all third-party software and custom scripts installed as services have their ImagePath enclosed in quotation marks within the registry.
2. Enforce Strict NTFS Permissions: The root of the C:\ drive and directories like C:\Program Files or C:\Windows must never grant write or modify permissions to standard users. Access Control Lists must be strictly managed using the Principle of Least Privilege.
3. Never Use AlwaysInstallElevated: This setting should be explicitly disabled via Group Policy across the entire domain. The convenience it provides is vastly outweighed by the catastrophic security risk.
4. Manage Service Account Privileges: Service accounts should be granted the minimum permissions necessary to function. Be highly restrictive with assigning SeImpersonatePrivilege. Consider using Group Managed Service Accounts (gMSAs) to handle credential management securely.
5. Regular Auditing and Vulnerability Scanning: Utilize vulnerability scanners and configuration auditing tools (like BloodHound or Tenable Nessus) to continuously scan the environment for weak permissions, unquoted paths, and missing security patches. Red Teams and Penetration Testers should be employed regularly to identify misconfigurations before malicious actors can exploit them.