Windows Privilege Escalation – An Approach For Penetration Testersresearch vulnerability
The race between attackers and defenders is a continuing one. Companies must protect their data. Preventing privilege escalation attempts from malicious employees or attackers decreases the probability of a data breach.
One way to assess and improve the security level of a company’s infrastructure is by engaging security experts to perform penetration tests. The main objective of a penetration test is the determination of vulnerabilities within a system, network, or application to detect weaknesses that an attacker could exploit.
The starting point of this article is the complex task, which penetration testers face after acquiring low privileged access to a system. The next logical step is the attempt to escalate privileges to be fully operative on the system without any restrictions. Due to the diversity of systems, escalating privileges can be a challenging task. A great number of different operating systems, configurations, hardening levels, etc. exist. Worldwide, security experts encounter this problem during their daily work.
This post shall provide security experts with an overview of relevant methods and techniques that can be used to expand privileges on a target system and provide practical examples without claiming completeness. These methods and techniques form the basis for a systematic and practical approach, which can be used by a penetration tester during an assessment.
Windows, compared to other operating systems, holds a market share of over 80% for desktops. It is the de-facto standard operating system of enterprises and organizations for their employees’ workstations. Microsoft offers different editions of Windows. From Windows Home, Education to Enterprise; every edition has its target audience and functions.
Furthermore, there are Windows Desktop and Windows Server versions. Windows Server supports more memory, uses CPUs more efficiently, allows more network connections than Windows Desktops and is configured to prioritize background tasks (e.g. file servers, web servers, databases) while Windows Desktop prioritizes foreground applications.
Service Packs combine previous patches including security fixes, performance improvements as well as support for new types of hardware. A newer Service Pack version incorporates previous Service Pack patches.
The kernel contains a set of functions that provide fundamental mechanisms. It provides scheduling or synchronization, which is used by components and low-level hardware architecture. It is written in C and contains assembly code for complex tasks that require access to special registers. The kernel’s tasks include reading and writing to memory and communicating with input and network devices. 
The registry is a central component that contains necessary boot and system information, system-wide software settings, the security database and also per-user configuration settings.
The registry is composed of keys and values. A key is a container that can consist of keys and values. The highest level of keys is called root keys. The registry contains the following six root keys :
|HKEY_CURRENT_USER||HKCU||Stores data associated with the currently logged-on user. This root key is mapped to the currently logged user’s key in HKEY_USERS|
|HKEY_USERS||HKU||Stores information about all the accounts on the machine|
|HKEY_CLASSES_ROOT||HKCR||Stores file association and Component Object Model (COM) object registration information|
|HKEY_LOCAL_MACHINE||HKLM||Stores system-related information and contains most keys|
|HKEY_PERFORMANCE_DATA||HKCC||Stores performance information|
|HKEY_CURRENT_CONFIG||HKPD||Stores some information about the current hardware profile|
The registry can be accessed through Regedit.exe:
A process contains a set of resources used when executing the instance of the program :
- a private virtual address space, used to prevent a process to access or modify other processes’ or operating system data
- an executable program, which is mapped into the process’ private virtual address space
- a security context (called access token), which includes identification of the user, security groups, privileges, etc.
- a process ID
- one or more threads of execution
A group of processes can be managed as a unit. The object that can control this group is called job. Jobs are nameable and can be secured with certain security constraints. E.g. jobs can prevent processes from impersonating or creating processes with access tokens that contain the local administrator’s group. Furthermore, it is possible to enable the job to remove certain privileges and security IDs (SIDs) when threads are impersonated.
Windows’ mechanism to start processes at system startup, which are not tied to an interactive user, are called Windows services. These are similar to UNIX daemon processes. An example for a user independent process is a web server. This Windows service runs independently, regardless if a user is logged on or not.
For each service, a registry key exists in HKLM\SYSTEM\CurrentControlSet\Services. The subkeys of a service’s key contain information regarding the executable file path, parameters and configuration options. If a service is configured to start from a particular account’s security context, the subkeys also contain the username.
The following figure shows a service registry key:
Services run in the context of user accounts. Unless otherwise specified, a service runs under the local system account (referred to as SYSTEM or LocalSystem), which possesses the highest privileges.
|Local System Account||Can enable all privileges -> Highest privileges possible||also called SYSTEM, Core Windows components run under this account|
|Network Service Account||Some privileges including SeImpersonate ||Used for services that authenticate to network services|
|Local Service Account||same as Network Service Account but not for authenticating to network services|
Startup programs (also called autoruns) are similar to services with the difference that services are managed by the Service Manager.
Some important and effective local privilege escalation methods and techniques are described in this section. These have been ordered by their success rate.
In a company environment, updates cannot always be deployed in a timely fashion. Compatibility, availability, resource problems, or a high number of systems are possible reasons for delayed or missing updates. This opens further vectors to escalate privileges.
The following graph depicts the possibilities to elevate privileges by exploiting outdated software:
Vulnerabilities in the Windows kernel are published from time to time of which many can be used to escalate privileges.
The following command can be used to retrieve installed patches and their date:
wmic qfe get Caption,Description,HotFixID,InstalledOn
Hereafter, the HotFixID (KB*) can be compared to the HotFixIDs in Microsoft’s security bulletin database. A missing HotFixID on the system means that a patch is missing and potentially an exploit can be used to escalate privileges.
Most software contains thousands of lines of code written by multiple developers. Ensuring that no vulnerabilities creep in, is virtually impossible. If a vulnerability can be used to execute arbitrary code and that application runs under high privileges, a successful exploit leads to escalated privileges. For this method, the first step is to retrieve currently installed software and their versions. Publicly available exploits for these software versions can be searched by using Google or dedicated exploit databases. If no exploits are publicly available, one might, depending on the time resources, consider developing an exploit or finding a 0-day vulnerability.
Wmic can be used to retrieve installed software and their versions:
wmic product get name, version
One possible way to escalate privileges is by exploiting misconfigured services. The goal is to embed a malicious file in a high privileged service. This file will then be executed the next time the service starts and will have the same privileges as the service possesses. As most services start with SYSTEM privileges, the chance to obtain SYSTEM privileges is high.
The following graph depicts the possibilities to elevate privileges by exploiting insecure services:
Weak Service Executable or Configuration File Permissions
Services execute the file defined in their file path. If this file can be modified by an attacker, he is able to replace it by a malicious file of his own.
Furthermore, services sometimes load configuration files. Depending on the program, it might be possible that such a configuration file can be used to execute an arbitrary file. If write permissions for such a configuration file exists, privileges can be escalated.
The following figure shows that the binary file of a service WavesSysSvc, which runs under SYSTEM privileges, can be modified by anyone of the group Users as they possess write permissions (permissions were modified in this example for demonstration purposes):
The output was generated with PowerSploit’s PowerUp script using the Get-ModifiableServiceFile method.
Weak Service Permissions
Weak service permissions can be used to modify the binary path in a service and hereby executy arbitrary files. A real world example can be seen in another blog post by SEC Consult: What unites HP, Philips and Fujitsu? One service and millions of vulnerable devices
Windows applications usually load DLL files when started. It may happen that a DLL file does not exist and the application is unable to load it. Nevertheless, an application will continue to execute as long as the missing DLL is not needed.
In case the application uses a relative and not an absolute file path, Windows searches for the file in the following directories:
- The directory from which the application is loaded
- The current working directory
- Directories in the system PATH environment variable
- Directories in the user PATH environment variable
The folders C:\Windows and “C:\Program Files” are usually protected as no low privileged users are able to write in these. Therefore, the highest potential for a successful DLL hijack is given when a low privileged user has write access to a directory included in the system or user PATH environment variable. A low privileged user can place a malicious DLL file with the same name as the missing DLL in one of these directories. When the application is started, this DLL file is loaded and will run under the application’s privileges.
To search for missing DLLs, PowerSploit can be used with the following script:
Hereafter, we can check the permissions in the directories that Windows searches for DLL files:
In the last step we can create a malicious DLL file with the following script:
If this is the case, we can move our malicious DLL file to the directory we have write access to. The next time the application is started, the created DLL file will be executed.
Unquoted Service Paths
Another way to escalate privileges is to exploit the order in which Windows searches for executables based on the value defined in the ImagePath parameter of a service when this value contains spaces and is not embedded within double quotes. An example can be seen in the following figure for the WavesSysSvc service, a sound manager application that comes shipped with DELL laptops (to our knowledge this vulnerability was fixed):
Windows first tries to execute an executable file in the location where the first space is. E.g. the service path
C:\Program Files\Waves\MaxxAudio\WavesSysSvc64.exe would
lead Windows to first search for an executable file Program.exe in the C:\ directory:
This applies to every space in the unquoted service path. If this file exists, Windows executes it. If it does not exist, the subsequent path is executed. An attacker that can write to the C:\ directory would be able to place an executable file named Program.exe in the directory. The next time the service starts, this file is executed.
Major vendors sometimes deploy software with unquoted service paths. E.g. in 2017 Lenovo patched an unquoted service path in the ElanTech Touchpad Driver, which is deployed on most of their notebooks. Also, Dell fixed unquoted service paths in one of their software called Dell Active Roles in 2017.
Please note, that this technique requires write permissions for low privileged users for a directory in the service path. Normally, a low-privileged user does not have write permissions to C:\. However, there is still the chance that write permissions exist for a directory in the remaining service path.
Finding a clear-text password or guessing it may allow for authentication as another user.
The following graph depicts the possibilities to elevate privileges by attacking insecure credentials:
In the process of automating different tasks, system administrators often knowingly or unknowingly write clear-text passwords in files or in the registry of accounts, which are used for authenticating to different services.
One example is that when administrators want to deploy images on a large number of devices without user interaction (called unattended installations) they use the Windows Deployment Services. However, this requires that the local system administrator’s password or other, privileged account passwords are stored in one or more of the following locations:
As an example, the following CMD commands can be used to search for passwords in configuration files:
findstr /si password passwd *.txt
findstr /si password passwd *.xml
findstr /si password passwd *.ini
findstr /si password passwd *.dat
Furthermore, the following PowerSploit scripts can be used:
The following commands are used to search for passwords in the registry:
reg query HKLM /f password /t REG_SZ /s
reg query HKLM /f passwd /t REG_SZ /s
reg query HKU /f password /t REG_SZ /s
reg query HKU /f passwd /t REG_SZ /s
reg query HKCU /f password /t REG_SZ /s
reg query HKCU /f passwd /t REG_SZ /s
Insufficient Physical Access Manipulation Protection
Further privilege escalation attack vectors exist if physical access to the target system is available. This section describes how privileges can be escalated on a system, which an attacker has physical access to and which is protected insufficiently against file manipulation.
The following graph depicts the possibilities to elevate privileges by attacking devices which we have physical access to:
Missing Disk Encryption
A machine that does not encrypt the Windows partition and allows booting from CD, USB or a pre-boot execution environment (PXE) is prone to privilege escalation through file manipulation. Such a machine can be compromised by booting a live operating system and replacing an executable file that is executed within a Windows service running with SYSTEM privileges. One example is the utilman.exe file used for input assistance (Ease of Access) at the Windows logon screen. This file can be replaced by cmd.exe. The following figure shows that a CMD with SYSTEM privileges is opened when clicking on the Ease of Access button:
Disk Encryption without Pre-boot Authentication (Cold Boot Attack)
Disk encryption software may use pre-boot authentication to ensure that a file volume is decrypted after providing a password, smartcard, etc. A number of disk encryption software load the decryption key into the RAM. If an already decrypted machine is shut down and can be booted from CD, USB or a PXE, it is possible to dump the RAM data of that machine by booting software that dumps the RAM. This is possible as RAM, although it is a volatile storage, does not directly erase data when it is no longer supplied with power, but it is erased gradually. The time after which RAM data is deleted can be extended to several hours by cooling the RAM, e.g. by spraying nitrogen on the RAM. Such an attack is also referred to as Cold Boot attack.
Some companies choose not to use pre-boot authentication in order to enable a PXE or to improve user experience. Here, the key is loaded into memory when booted. These machines can be started and shutdown several times. Therefore, the memory can be dumped repeatedly until it contains the decryption keys. This increases the chance of a successful key extraction. Such attacks have been demonstrated by the Princeton University research.
The privilege escalation approach, which is introduced here, was developed and improved in a realistic lab environment. It consists of three phases. In the first phase of the approach, general information about the target are gathered. The next phase concludes an iterative approach with four steps where every technique and method is iterated through. The last phase is the reporting phase.
The main goal is to escalate to the highest privileges possible. In case no vertical privilege escalation attacks are successful, horizontal privilege escalation attacks can be conducted to possibly find new attack vectors. If a horizontal privilege escalation was successful, the approach should be started from scratch.
In every phase, it is crucial to take notes in a structured manner. A list containing all possible attack vectors ordered by the most interesting and unusual observations should be maintained to keep a good overview.
Phase 1: General Information Gathering
The first step is to gather general information in order to have a good overview about the system.
On what system am I? In which domain? What Windows version and SP is used? What CPU architecture does the system use?
Who am I? What privileges do I have? In which groups am I?
net user %username%
Which users and groups exist? Which users are in the Administrators group?
net localgroup administrators
Who is currently logged in?
qwinsta (Windows Servers)
What is the purpose of this system? What is installed on it?
wmic product get name
Browse through the file system, especially the directories Program Files and Program Files (x86).
Which processes are running? Which ports are open? Which services are started? Which antivirus or endpoint protection software is in use?
In which networks is the system? How does the routing look like?
Which devices are connected to the system? Which shares are connected?
Phase 2: Method and Technique Iteration
After obtaining a good overview of the system, every method and technique introduced is iterated through. While doing so, the steps described in this phase should be performed.
Step 1: Information Gathering
In this step, the goal is to find out whether the target system is vulnerable to the method we are currently evaluating and whether all conditions for a successful attack are given. If there is the possibility that the target system is vulnerable, we proceed to step 2.
Step 2: Research and Development
Research and development are a crucial step towards a working exploit. In this step, all necessary information about the attack and how it can be used against the target system should be gathered. This information allows us to develop a customized attack for the target. This has to be done carefully as minor details can be the difference between a successful exploit and a crashed system.
It is recommended to set up a test environment that is similar to the target system and develop and test the attack on it. The reason for this is that it is easier to find out why the attack fails and hereby analyze what changes have to be made. This increases the probability of successful exploitation and can be considered for more complex methods that require a number of conditions to be in place.
Sometimes, no more than one attack attempt is given as the targeted service or system would crash if the attempt is not successful. If there is no possibility to restart the service or system, a failed attack would render the attack vector useless. After crashing a process or potentially the whole system, one last option would be to ask responsible system administrators to restart the system. However, if the system or service can be restarted and the attack is known to have a good success rate, it might save time to conduct an exploitation attempt with only a small amount of research. Sometimes, several hours are put into developing and testing an attack without any success. If this is the case, it might make sense to take a step back and later on proceed developing the attack further. In the meantime, other attack vectors should be approached.
During research and development, possible security mechanisms that could prevent an attack from working should be considered. One can put himself into the position of a system administrator and ask himself what security mechanisms could have been installed. E.g. a firewall might implicitly prevent the usage of certain TCP ports. However, TCP connections to port 80 or 443 are often allowed. This should be considered when trying to create a reverse shell that connects back to your machine. Furthermore, after conducting the general information gathering phase, it should be clear which antivirus or endpoint protection software is in use. E.g. an exploit should not be detected by the antivirus software. An online virus scanner can be used, or the antivirus or endpoint protection software can be installed directly in a test environment to ensure that the exploit is not detected. If the antivirus software detects the exploit, different evasion techniques can be used.
Summarized, thoroughly conducted research allows a penetration tester to save time. Sufficient effort should be put into it.
Step 3: Exploitation
In this step, the attack that has been researched and developed in the previous two steps will be tested. Often, an attack will not work right away even after putting in some effort. Most times, several repetitions of the previous steps have to be carried out until a working attack is found.
Step 4: Post-Exploitation
Every step of the attack should be carefully documented including results from the information gathering phase. A good documentation helps system administrators or developers to fix the identified vulnerabilities as they often require understanding the whole attack process to be able to fix the issues.
Furthermore, if a monitoring system (e.g. a SIEM) is in place, it can be discussed whether the system has detected the exploit. If not, the customer should be advised to improve the monitoring activities and verify that similar attacks will be detected in the future.
The following table lists tools that can be used to automate steps of the approach:
|BeRoot||Unquoted service paths, modifiable services, startups or scheduled tasks, writable service, startup and scheduled tasks directories, writable PATH directories, AlwaysInstallElevated, unattended install files||https://github.com/AlessandroZ/BeRoot|
|JAWS||General information gathering, AlwaysInstallElevated, services, scheduled tasks, potentially interesting files||https://github.com/411Hall/JAWS|
|Metasploit||Modules for general information gathering, patch enumeration and exploit suggestion, a great number of software and kernel exploits, automated privilege escalation, token impersonation||https://github.com/rapid7/metasploit-framework|
|PowerSploit||services, DLL hijacking, AlwaysInstallElevated, autologon credentials, scheduled tasks, clear-text passwords in common files, etc.||https://github.com/PowerShellMafia/PowerSploit/tree/master/Privesc|
|Sherlock||Check missing software patches that can be used for privilege escalation||https://github.com/rasta-mouse/Sherlock|
|Windows-Exploit-Suggester||Checks for missing patches and proposes suitable exploits||https://github.com/GDSSecurity/Windows-Exploit-Suggester|
|Windows-privesc-check||Modifiable services, service binary files, processes and modifying programs on FAT file systems||https://github.com/pentestmonkey/windows-privesc-check|
|Windows Sysinternals Suite||General information gathering||https://docs.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite|
Please note, that these tools may also generate false positives. Therefore, a manual check has to be done.
Important privilege escalation methods and techniques were described. A systematic and practical approach to escalating privileges for penetration testers was introduced. Also, tools that can be used to automate steps of the approach were introduced.
The methods and techniques described here can help system administrators and architects to understand the functionality of privilege escalation techniques in order to prevent these and ultimately improve their infrastructure’s security. A Windows system can be – if configured with care – a tough challenge for penetration testers that want to escalate privileges. System administrators and architects have to be knowledgeable about Windows and its security mechanisms in order to be able to configure a Windows system securely. Microsoft keeps the patch time for vulnerabilities short. This decreases the chance of successful exploitation during a penetration test (or a real breach).
Overall, it can be concluded that Windows implements a great number of security mechanisms. This enables a granular configuration of privileges and access rights and herein allows the principle of least privilege to be potentially applied in an optimal way. On the other hand, the complexity of Windows configurations may impede the security of a company’s systems.
 Windows internals, Pavel Yosifovich et al., p. 57
 Windows internals, Pavel Yosifovich et al., p. 280
 Windows internals, Pavel Yosifovich et al., p. 5
 SeImpersonate can be used to use the (Rotten) Potato exploit and to possibly escalate to SYSTEM privileges: https://github.com/foxglovesec/RottenPotato
EOF K. Bijjou / @2019