Introduction

In this article, we will discuss the top techniques that hackers use today when performing privilege escalation within Windows machines. Where necessary, we shall give examples of the techniques being discussed in order to show how it can be done. 

This article is intended for hackers who already have an idea of Windows hacking, so we will not be providing an introduction to concepts such as Metasploit hacking and msfvenom payload generation.

Overview

As a penetration tester or hacker, you often break into a Windows machine either through a vulnerability or weak credentials. In situations like these, you’ll want to identify the privileges that you are running under. 

For every hacker, there are numerous times where your shell will be low-privileged. The following are the methods by which you can be able to elevate privileges within your compromised host:

Unquoted service paths

An unquoted service path is a vulnerability that occurs when a service path is not enclosed with quotation marks and contains spaces.

This happens when a service is created with an executable path containing spaces that are not enclosed within quotes.

How are unquoted service paths detected?

In order to detect unquoted service paths, you can use the following command:

wmic service get name,displayname,pathname,startmode |findstr /i "Auto" |findstr /i /v 
"C:\Windows\\" |findstr /i /v """

The following screenshot shows this command and the output received from Windows:

If we are to look at how this registry entry is defined by using “regedit”, we can note something interesting. The entry is given as shown below:

C:\Program Files (x86)\Program Folder\A Subfolder\Executable.exe

The entry should be given as follows, defined around quotation marks:

"C:\Program Files (x86)\Program Folder\A Subfolder\Executable.exe"

The screenshot showing this is given below:

When Windows attempts to run this service, it follows the following order and will run the first .exe file that it finds:

  • C:\Program.exe
  • C:\Program Files.exe
  • C:\Program Files (x86)\Program.exe
  • C:\Program Files (x86)\Program Folder\A.exe
  • C:\Program Files (x86)\Program Folder\A Subfolder\Executable.exe

If we can have a malicious .EXE file within any of these locations, Windows will run it as SYSTEM, but that will be dependent on the permissions we have within these folders.

The vulnerability is introduced by the CreateProcess function found in Windows. This issue is described in more detail here.

We can use icals to check the permissions of the current folder that we are currently in, named “Program Folder”.  The screenshot below shows the output of the icals command:

 

The following key shows an explanation of the screenshot above:

  • F: Full control
  • CI: Container inherit. This flag indicates that subordinate containers will inherit this ACE
  • OI: Object inherit. This flag indicates that subordinate files will inherit the ACE

As can be seen, “Everyone” has full control permission to access the folder. We can now place our malicious EXE file in this folder. We can use msfvenom in Kali Linux to create the malicious file. See the screenshot below:

We now copy the file A.exe to the folder location, restart the machine and see what we can do with the running process.

Upon uploading the file and doing an ls, we can see that the file sits in the directory we uploaded it to. We will now restart the machine and attempt to terminate the process. See the screenshot below:

The operation fails because we do not have sufficient permissions to initiate or terminate the service. This is actually normal, so we wait until someone restarts the machine. Note that we can also do this using the shutdown command, as shown below:

As soon as the system reboots, we receive a reverse connection back to our attacking machine (assuming we had started a reverse handler to receive the Meterpreter).

Notice that this time round, our payload began running as SYSTEM. This can be seen below:

To prevent the Meterpreter session from dying so quickly, you can migrate to another process that is much more stable.

Services with vulnerable privileges

In Windows, services run as SYSTEM. However, there are some instances where the files, folders and registry entries belonging to these services are not sufficiently protected. We can leverage on these insufficient settings in order to gain privileges on a compromised system. Let’s discuss three of the most common vulnerable points as a result of insufficient privileges.

1. Insecure registry permissions

Windows stores all the necessary data that is related to services in the registry key location below:

HKLM\SYSTEM\CurrentControlSet\Services

We can include a vulnerable service in the same location and with a new key:

HKLM\SYSTEM\CurrentControlSet\Services\Vulnerable Service

A screenshot of this can be seen below:

The major issue with this service is that it is accessible by everyone, as it allows everyone “full control.”

If we can upload a malicious file to the same service location and change the ImagePath value to match the malicious payload location, we can be able to execute it with permissions. We use msfvenom to generate a malicious payload, then we upload this to the target machine. The screenshots below demonstrate these actions:

Generating the malicious payload and issuing reverse connection information is shown above.

Once we are inside our target machine, we can upload the malicious payload that we just generated above.

We can now create the registry keys, pointing to our new malicious payload. This is shown above.

At the next reboot, the computer will run the Payload.exe file as SYSTEM. We started a handler and a soon as the boot-up was complete, we took the following screenshot:

Notice that the payload runs as SYSTEM. To sustain the Meterpreter session, remember to migrate to a more stable process. 

2. Insecure service permissions

This vulnerability is quite similar to the one discussed above. The difference comes in where instead of changing the ImagePath as we did above, we modify the service properties. We make use of the AccessChk tool from SysInternals Suite. Once we have compromised the target machine, we upload the AccessChk tool then use the following command:

C:\Users\testuser\AppData\Local\Temp>accesschk.exe -uwcqv "testuser" * 
accesschk.exe -uwcqv "TestUser" *

The upload command can be seen below:

The screenshot below shows the output received once we run the accesschk.exe tool:

From the screenshot above, we can see that the account “testuser” has SERVICE_ALL_ACCESS. This setting tells us that we have full control and can modify the properties of Vulnerable Service. We can check the properties of this service using the sc command, as shown below:

The setting for BINARY_PATH_NAME indicates the location of the executable file. We can actually change this to a command of our choice. This command will be run as SYSTEM at the next start of the service. The screenshot below shows how we change this setting into the netuser command to add the user eviladmin with a password P4ssw0rd@.

Remember to add the new account to the administrators group by changing the binpath using the command below:

"net localgroup Administrators eviladmin /add"

The account will be added to the local administrators group, as shown below:

 

You can also check out this Metasploit module.

3. Insecure file/folder permissions

This method is very similar to the unquoted service paths method. As we saw above, in order to exploit unquoted service paths, we had to manipulate the “CreateProcess” function, folder permissions and executable file path of a service. Here, instead of doing that, we replace the executable. The screenshot below shows the permissions of Vulnerable Service’s executable path:

We can replace “Executable.exe” with a reverse shell. Doing so and rebooting the machine allows us to run a Meterpreter session with SYSTEM privileges.

AlwaysInstallElevated

When AlwaysInstallElevated is enabled, Windows applies privileges to all programs. This can be thought to be the same as applying admin privileges to non-privileged users.

You can check to see whether this is enabled from the registry, as shown below:

The location within the registry to these settings are given below:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer]

“AlwaysInstallElevated”=dword:00000001

[HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Windows\Installer]

“AlwaysInstallElevated”=dword:00000001

If you have managed to have a low-privileged Meterpreter session within the target system, the commands in the screenshot below can be used to extract these same values from the registry.

The output above shows “ERROR” because the policy was never created and the system is not vulnerable. However, if you receive the output shown below, this means that the target system is vulnerable and you can exploit it.

At this point, you can get creative and even use msfpayload to generate a payload that you can upload and run on the target to receive a high-privileged Meterpreter session.

Alternatively, you could use the following Metasploit module:

exploit/windows/local/always_install_elevated

You can link your low-privilege Meterpreter to this module and let it run.

DLL hijacking

This attack happens when an application dynamically loads a DLL without specifying a fully qualified path name. As Windows attempts to load this file, it looks for it within a well-defined set of directories in a particular order. 

When hackers access the DLL search path, they may include a malicious copy of a DLL which the application will load if it does not find a legitimate DLL. Now, in the case of the application that just landed, this DLL is running with administrator privileges and the hacker will be able to achieve local privilege escalation.

Stored credentials and kernel exploits

Suppose you attempt all the above methods and they fail to work. Well, you might decide to attempt to search for stored credentials within the system. You may use the following queries to search through the system for sensitive files:

  • dir c:\*vnc.ini /s /b /c
  • dir c:\*ultravnc.ini /s /b /c
  • dir c:\ /s /b /c | findstr /si *vnc.ini
  • findstr /si password *.txt | *.xml | *.ini
  • findstr /si pass *.txt | *.xml | *.ini

These sensitive files will often be located within the following directory locations:

  • C:\unattend.xml
  • C:\sysprep.inf
  • C:\sysprep\sysprep.xml

You may also look for exploits that might be relevant during the attack. The following command will be able to list all the applied hotfixes and updates that have been performed on the target system.

  • wmic qfe get Caption,Description,HotFixID,InstalledOn

Conclusion

Privilege escalation depends on how creative you can get during hacking. The methods above do not exhaust all of the options you can achieve during Windows privilege escalation. In fact, the methods of payload generation that we have used above are bound to be caught by antivirus solutions. 

You should definitely consider researching more on antivirus evasion techniques and how you can generate payloads that are less likely to be caught. Consider starting your research here and here.

 

Sources

  1. Windows Privilege Escalation Methods for Pentesters, Pentest Blog
  2. Windows Escalate Service Permissions Local Privilege Escalation, Rapid7
  3. Windows Privilege Escalation — Part 1 (Unquoted Service Path), Sumit Verma (Medium)
  4. Unquoted Service Paths, Common Exploits
  5. Art of Anti Detection 1 – Introduction to AV & Detection Techniques, Pentest Blog
  6. Art of Anti Detection 2 – PE Backdoor Manufacturing, Pentest Blog

Be Safe

Section Guide

Lester
Obbayi

View more articles from Lester

As you grow in your cybersecurity career, Infosec Skills is the platform to ensure your skills are scaled to outsmart the latest cyber threats.

Section Guide

Lester
Obbayi

View more articles from Lester