Service Misconfiguration

Privilege escalation is a common technique used by penetration testers to test unauthorised access to a system. One way to achieve privilege escalation is through service misconfigurations in Windows.

A service is a program that runs in the background on a Windows system, and it can have a variety of functions such as managing network connections, printing, or running scheduled tasks. Services can be configured to run under different user accounts, and some may have higher privileges than others. If services run with SYSTEM privileges and are misconfigured, exploiting them may lead to command execution with SYSTEM privileges too.

In this blog post, we’ll discuss these Service Misconfigurations:


1.  Insecure Service Properties
2.  Unquoted Service Path
3.  Weak Registry Permissions
4.  Insecure Service Executables
5.  DLL Hijacking.

The following are service commands that will be used.

To query the configuration of a service: sc.exe qc <service name>
To query the current status of a service: sc.exe query <service name>
To modify a configuration option of a service: sc.exe config <service name> <option>= <value>. Please leave one space after equal sign.
To start a service: net start <service name>
To stop a service: net stop <service name>

Note: To follow along or get the best out of this blog, please check how to set up a virtual lab that we are going to be using. After having your lab set up, now let’s go through each type of service misconfiguration.

Insecure service permissions

Permissions to access a certain resource in Windows are controlled by the access control list (ACL) for that resource. Each service has an ACL that defines certain service-specific permissions.

Some permissions are harmless because they can’t give us a way to run executable files (e.g. SERVICE_QUERY_CONFIG, SERVICE_QUERY_STATUS).
Some may be useful (e.g. SERVICE_STOP, SERVICE_START).
Some are dangerous (e.g. SERVICE_CHANGE_CONFIG, SERVICE_ALL_ACCESS) because If our user has permission to change the configuration of a service which runs with SYSTEM privileges, we can change the executable the service uses to one of our own.

NOTE : If we cannot stop/start the service, we may not be able to escalate privileges! This applies to all service privilege escalation.

Steps to exploit this misconfiguration

Step 1

Run winPeas to enumerate and identify potential vulnerabilities in a Windows system.

.\winPEASany.exe quiet servicesinfo

The above command runs WinPEAS in quiet mode and specifically focuses on gathering information about Windows services. Running this command, WinPEAS will enumerate all installed Windows services and provide information about their status, display name, service name, path, and description. Additionally, it will look for services with weak permissions or misconfigured service binaries that may be vulnerable to privilege escalation.

By default, WinPEAS will save the output to a file named winPEAS.<timestamp>.txt in the current directory. You can use the > operator to redirect the output to a different file or location.

Step 2

After running the above command, we can read the output file and identify service permissions of our user to check if there is a service with SYSTEM privileges and we have permission to modify it.

If you are using the virtual lab we created before, after running the above command we can verify this on the winpeas output.

daclsvc_service

In the above screenshot, we can see daclsvc service can be modified. This can also be confirmed on the modifiable services section on winpeas file.

Step 3

Verify if the above service is modifiable with accesschk. For more about accesschk tool and how to use it, please check accesschk write-up.

Run this command to check more info about the service .\accesschk.exe -uwcqv user daclsvc

permission_output From the above output, we can see the permissions we have. However, the two most important permissions are to start/stop the service and to change the configuration of the service.

Step 4.

Enumerate this service to see more information and check its current status.

To enumerate this service, use the command sc qc daclsvc
To check the status of the service, use the command sc query daclsvc

As we can see from the output of our commands: service_output From the above results:

The service is configured to demand start, meaning it has to be started manually.
The binary path name points to daclservice.exe.
The service has no dependencies.
It should also run with the permissions of LocalSystem.
The service is currently stopped, meaning after we reconfigure the service, we can start it to trigger the exploit.

Step 5.

Since we have the permission to configure the service, we can configure the binary path to the path of our reverse shell payload. To achieve that, run sc config daclsvc binpath="\C:\PrivEsc\reverse.exe\" (set the path to your reverse shell path).

Step 6.

Start a listener with netcat: listerner

Step 7.

Start a service where our reverse shell payload will be executed: service_and_listener

As you can see from the above, we have a reverse shell with system privileges.

Unquoted Service Path

In Windows, it is possible to run executable files without specifying their file extension, for example, running "ipconfig.exe" by typing "ipconfig". However, some executables require additional arguments to be passed to them, separated by spaces, such as "program.exe arg1 arg2 arg3...". This can create ambiguity when using absolute paths that contain spaces and are unquoted, which can cause the wrong executable to be run.

Suppose we have an unquoted path in Windows, such as "C:\Program Files\Directory DirName\Program.exe". While it’s clear to us that the intended executable is Program.exe, Windows may interpret "C:\Program" as the executable with two arguments: "Files\Directory" and "DirName\Program.exe". or "C:\Program Files\Directory" as the executable with argument "DirName\Program.exe".

To resolve this ambiguity, Windows checks each of the possible executable paths in turn. This creates a security vulnerability, as an attacker could potentially trick a service into running a malicious executable instead of the intended one by writing the malicious file to a location that Windows checks before the actual executable.

Steps to exploit this misconfiguration.

From the winpeas output that we run before (.\winPEASany.exe quiet servicesinfo) we can see this misconfiguration on service information section. winpeasy_png

Step 1.

Query the configuration of the service sc qc unquotedsvc Here is the output. unqoutedsvc

From the output of our query, the path is C:\Program Files\Unquoted Path Service\Common Files\unquotedpathservice.exe
It has LocalSystem privileges, meaning if we can run our reverse shell payload, we will have System privileges.
It demands start

Step 2.

Use accesschk.exe to see if we have permission to start the service (if we don’t, then we can’t exploit it even if it is vulnerable), and writable permission.

Checking if we have permission to start the service.

.\accesschk.exe -ucqv user unquotedsvc We can see that we have permission to start and stop the service.

Step 3.

Using accesschk.exe to check for writable permissions of C:\Program Files\Unquoted Path Service\Common Files\unquotedpathservice.exe

Check write permission of C:\ run .\accesschk.exe -uwdq C:\
Check write permission of C:\Program Files\ run .\accesschk.exe -uwdq "C:\Program Files\"
Check write permission of C:\Program Files\Unquoted Path Service\Common Files run .\accesschk.exe -uwdq "C:\Program Files\Unquoted Path Service\"

writable_perm From the above results, we can see the C:\Program Files\Unqouted Path Service directory all BUILTIN\Users have the RW permissions This means, if we create a file in this directory, when the service starts, it will execute.