Windows Privilege Escalation – An Approach For Penetration Testers

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

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.

Kernel

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. [1]

Registry

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 [2]:

Processes

A process contains a set of resources used when executing the instance of the program [3]:

• 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

Jobs

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.

Services

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. 

Service Accounts

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. 

Startup Programs

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. 

Outdated Software

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.

Windows Kernel

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.

Vulnerable Applications

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

Insecure Services

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.

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):

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

DLL Hijacking

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
• C:\Windows\System32
• C:\Windows\System
• C:\Windows
• 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:

Find-ProcessDLLHijack 

Hereafter, we can check the permissions in the directories that Windows searches for DLL files:

Find-PathDLLHijack

In the last step we can create a malicious DLL file with the following script:

Write-HijackDll

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.

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:

C:\Program.exe

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.

Clear-text Passwords

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:

• C:\unattend.xml
• C:\Windows\Panther\Unattend.xml
• C:\Windows\Panther\Unattend\Unattend.xml
• C:\Windows\system32\sysprep.inf
• C:\Windows\system32\sysprep\sysprep.xml

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:

Get-UnattendedInstallFile
Get-Webconfig
Get-ApplicationHost
Get-SiteListPassword
Get-CachedGPPPassword

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

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 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?

systeminfo

Who am I? What privileges do I have? In which groups am I?

whoami
whoami /priv
net user %username%

Which users and groups exist? Which users are in the Administrators group?

net user
net localgroup
net localgroup administrators

Who is currently logged in?

qwinsta (Windows Servers)

What is the purpose of this system? What is installed on it?

tasklist /SVC
netstat -ano
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?

tasklist /SVC
netstat -ano
net start

In which networks is the system? How does the routing look like?

ipconfig /all
route print

Which devices are connected to the system? Which shares are connected?

net use
net share

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.

Tools

The following table lists tools that can be used to automate steps of the approach:

Please note, that these tools may also generate false positives. Therefore, a manual check has to be done.

——————————————————

[1] Windows internals, Pavel Yosifovich et al., p. 57

[2] Windows internals, Pavel Yosifovich et al., p. 280

[3] Windows internals, Pavel Yosifovich et al., p. 5

[4] 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