Privileges Escalation Techniques (Basic to Advanced) for Windows - (Part-2)

LE0_Hak

Hello Friend. Welcome back to a new part of this series. One month or more has elapsed since part 1 came. Took a long break I guess 🙂

Check out the first part of this series from HERE.

In this part, we’re going to cover 3 techniques.

3. Privilege Escalation: Registry (AlwaysElevatedPrivileges (.msi))

Theory
A .msi file is specifically designed for software installation on Windows operating systems. It contains information and files needed to install a software application in a standardized way that is managed by the Windows Installer service.
The “Always Elevated Privileges” vulnerability occurs in Windows Installer packages (.msi) that have been designed to run with administrative privileges by default. This means that any user or application that executes the .msi package is granted administrative privileges automatically, without requiring any further user input or authentication.

The AlwaysElevatedPrivileges methodology is simple;

Precondition: Permission of both Registry key values given below is set to TRUE in order to exploit this vulnerability.

Check the Registry keys if the current user is allowed to download .msi
reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated # must be set as 1 (0×1) means enabled
reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated # also must be set as 1 (0×1) means enabled
Create a .msi payload & send it to the target. Execute that .msi & whatever is in it will get executed with ADMIN/SYSTEM privileges.

Practical
Let’s check those two registry key’s value that allows us to install .msi via ADMIN privileges.

Both are set to TRUE == Enabled

Target is vulnerable to “AlwaysElevatedPrivileges” Vulnerability or more technically misconfiguration. So It’s time to create a malicious .msi payload.

Host this payload on HTTP, SMB server, or whatever technique suits you & on the target side use certutil, PowerShell, or SMB to download the .msi payload from the attacker’s server.
Now Run the .msi payload to trigger our reverse shell (stageless) Code.

Target’s Side

Attacker’s Side

4. Privilege Escalation: Services (Unquoted Service Path)

Theory
Windows service is a computer program that operates in the background. It is similar in concept to a Unix daemon.
Each service in Windows stores a path of its executable in a variable known as “BINARY_PATH_NAME”. When we start the service it’ll check this variable & execute the .exe set under it.

Note: BinPath uhh, Yes it’s the same thing we talk about in Insecure Service Permission or BINPATH Privilege Escalation technique but there’s the binpath variable is writable so we hijack it but this technique totally different. Useful where the Service’s BINPATH is secured/not allowed to manipulate.

The “Unquoted Service Path” vulnerability occurs in Windows services that have been installed with an executable binpath containing spaces, but without enclosing quotes. When Windows starts a service, it looks for the executable file in the path specified in the service’s configuration. If the service path does not contain quotes and has spaces in it, Windows will attempt to execute the first word of the path as the executable, and use the remaining words as command-line arguments.

For example, for the Service’s Path C:\Program Files\Script dir\service.exe
Windows will try to execute all the following possibilities:
C:\Program.exe
C:\Program Files\Script.exe (Here \Program Files dir is writable so the attacker can create a payload with the service’s extension to get it executed by OS during traversing)
C:\Program Files\Script dir\service.exe

The Unquoted Service Path methodology is simple;

Pre-Condition: Must’ve Service’s Path without enclosing quotes & contain space. Another thing is we’ve writable perm in a higher precedence directory compared to the original binary directory.

Enumerate all the services to check if any service’s BinPath is unquoted and contains whitespace or other separators.
Then find at least one writable directory in the listed unquoted binary path & it must be higher in precedence as compared to the original.
Query the service using sc to check if that service runs with (SYSTEM/Admin) privileges.
Create a payload in that writable directory.
Refresh or start the service to execute the .exe with SYSTEM Privileges.

Practical

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

Last Service’s Path has spaces & not disclosed in quotes

Ok, We’re now confirmed that the target is vulnerable but let’s check the second condition to successfully exploit this vuln is to have a writable path in higher precedence compared to the original service’s path.

So, First Directory Check.

Look like we don’t have permission to write on this dir
Ok, Let’s move to the second directory.

COOL, So we’ve Full-Access (rwx) permission in Unquoted Path Service Directory & now we know a place where we can create our payload & it’s also higher in precedence.

Copy our payload to the writable directory & change its name to Common.exe (as OS will execute this dir during traversing)
Now just start this service using net start <service-name> & we’ll get the payload result which is the ADMIN privilege shell of the target.

If you still don’t get this (Practical) then let me give you a simple breakdown of the whole scenario.
The Vulnerable Directory we found is C:\Program Files\Unquoted Path Service\Common Files\UnquotedPathService.exe Because its BinPath has Spaces but it’s not enclosed in Quotes so it results in the causing this Vulnerability.
So normal cases whenever this service starts the Windows OS will read this Vulnerable BinPath in the following way.
C:\Program.exe (Program Not Found)
C:\Program Files\Unquoted.exe (Program Not Found)
C:\Program Files\Unquoted Path.exe (Program Not Found)
C:\Program Files\Unquoted Path Service\Common.exe (Program Not Found)
C:\Program Files\Unquoted Path Service\Common Files\UnquotedPathService.exe (Program Found)
So you see it’s executing every point where it finds a Space & adding a .exe extension at the end of that. If it Doesn’t find that Binary then it’ll traverse further until find the right one at the end of BinPath.
Now, For the Attacker’s POV, all he has to do is find one writable path between the original service path.
If he did he can create his payload with the same name & extension that Windows will traverse to find the binary so it allows him to execute his payload.
In this example, we found the “/Unquoted Path Service” Directory’s writable so we create Common.exe as Windows will find this & execute it.

5. Privilege Escalation: Services (Weak Registry Permission)

Theory
The registry is a database that stores settings and configuration information for the operating system, as well as for installed applications and services. The Registry is a critical component of the Windows operating system.
Attackers can use weak registry permissions on a Windows service to escalate their privileges to the administrator level by modifying the service’s configuration settings to run with elevated privileges.
“ImagePath” is a registry value that specifies the location of the executable file for a Windows service. The ImagePath value contains the full path and filename of the executable file that runs the service, along with any command-line arguments or options that the service requires.
In Windows, services have registry keys, and those keys are located at HKLM\SYSTEM\CurrentControlSet\Services<service_name>

The Weak Registry Permission methodology is simple;

Pre-Condition: Must have a service with SYSTEM/ADMIN privileges running & its registry keys permission are writable.

Enumerate all services to check if their registry keys are writable.
Modify the “ImagePath” (contains the path to the application binary) of the service
Refresh or start the service & the service will execute whatever is in its image path key with SYSTEM privileges.

Practical
Let’s Enumerate the target system to find this vulnerability.

Let’s check this service’s registry keys permission

NT AUTHORITY\INTERACTIVE (it’s a group which means essentially all logged-on users on the system)
Nice, It’s confirmed target is vulnerable as the “regsvc” service’s registry key’s permission is set to KEY_ALL_ACCESS which grants a user or group full access to a registry key, including the ability to view, modify, and delete its values and subkeys.

OK, Let’s modify the key “ImagePath” of this service “regsvc”

After changing the registry key value just start or restart the service to get our payload executed as SYSTEM/ADMIN Privileges

Automated Scripts:

exploit/windows/local/always_install_elevated : Metasploit script to automatically enumerate & exploit “AlwaysInstallElevated”
exploit/windows/local/service_permissions: inspect existing services to look for insecure configuration, file, or registry permissions that may be hijacked. It will then attempt to restart the replaced service to run the payload.
PowerUp.ps1: PowerShell scripts that enumerate all the possible path for local privileges escalate vuln/misconfig & even has an exploit script.

The next part will cover more 3 techniques so activate Sleep(7 * 24 * 60 * 60 * 1000); if want to support us with coffee then ping us at here