Windows services (formerly known as NT services) allow you to create long-running actions/programs that execute in their own Windows sessions. Services can be started automatically when the computer boots up, can be stopped or started manually, and in any case, they don’t display a graphical interface, everything happens in the background.
Services can run in the context of a different user than the one or those who have logged into the computer.
With this last statement, thinking from an attacker’s perspective, this Windows feature may already catch our attention regarding a possible privilege escalation. If a service is misconfigured and is executed by, for example, the nt authority\system user, we might be able to take advantage of it to inject actions by impersonating this user (or whatever user executes it).
Index:
Types of Privilege Escalations
There are several known privilege escalations that are related to Windows services:
- Insecure Service Permissions
- Unquoted Service Path
- Weak Registry Permissions
- Insecure Service Executables
- DLL Hijacking
All these possible escalations are based on misconfigurations that can be found on the Windows system. However, none of these escalations will work even if that misconfiguration exists, if we don’t have the ability to:
- Start, stop, or restart the service
- Restart the Windows computer (assuming the vulnerable service starts on system boot)
So we shouldn’t fall into the trap of thinking that if we find any of these possible misconfigurations, we’ll be able to exploit them. Everything will depend on whether we’re capable of performing either of the last two mentioned actions.
Now let’s see how we can enumerate the permissions and configurations of a service, file, and directory.
Enumeration using accesschk.exe
Accesschk is a command-line tool that belongs to the Windows Sysinternals toolkit, so it’s from Microsoft itself. It allows you to see what type of access specific users or groups have to resources such as files, directories, Registry keys, global objects, and Windows services. It can be downloaded from the official documentation.
The structure of accesschk is as follows:
accesschk.exe [options] [user or group] <object name>
Knowing this, let’s look at some specific commands that can be useful to us:
View permissions that a certain user has over a service
accesschk.exe /accepteula -ucqv <user> <service>
Argument explanation:
/accepteula–> when we run a Windows Sysinternals tool, the first time we do it, a graphical window usually appears to accept terms and so on. To avoid problems from our shell, by directly adding this argument we accept the terms from the console itselfu–> We indicate not to show errors if there are anyc–> We indicate that the<object name>represents a Windows serviceq–> We remove the tool’s banner from the outputv–> Typical verbose of any tool (display more detailed information)
In this example we can see how the user user has the ability on the daclsvc service to:
- Edit the service configuration
- Start the service
- Stop the service
This way, we would identify permissions which can be useful to know to determine some possible exploitation.
View write permissions on a directory
accesschk.exe /accepteula -uwdq <directory>
Argument explanation:
/accepteula–> when we run a Windows Sysinternals tool, the first time we do it, a graphical window usually appears to accept terms and so on. To avoid problems from our shell, by directly adding this argument we accept the terms from the console itselfu–> We indicate not to show errors if there are anyw–> Shows only permissions that contain write accessd–> We indicate that the object is a folder. And that we’re interested in the permissions of this object and not its contentsq–> We remove the tool’s banner from the output
This way, we can see how all users (BUILTIN\Users) have write capability on the specified directory, which could be useful to take advantage of some misconfiguration.
Check the permissions of a registry key
accesschk.exe /accepteula -uvwqk HKLM\System\CurrentControlSet\Services\regsvc
Argument explanation:
/accepteula–> when we run a Windows Sysinternals tool, the first time we do it, a graphical window usually appears to accept terms and so on. To avoid problems from our shell, by directly adding this argument we accept the terms from the console itselfu–> We indicate not to show errors if there are anyv–> Typical verbose of any tool (display more detailed information)w–> Shows only permissions that contain write accessq–> We remove the tool’s banner from the outputk—> We indicate that the<object name>represents a registry key
In this case, thanks to accesschk we can know that the INTERACTIVE group has write permissions on the registry. This group includes all users who have ever logged into the machine locally, so it’s very likely that any user belongs to this group.
Knowing this, in this case we’ve been able to verify that we have write capability on this registry, which could be useful.
FYI, as a curiosity, all services in Windows are located at the path:
HKLM\System\CurrentControlSet\Services\<service name>
Check if we have write permissions on an executable
accesschk.exe /accepteula -quvw <executable>
Argument explanation:
/accepteula–> when we run a Windows Sysinternals tool, the first time we do it, a graphical window usually appears to accept terms and so on. To avoid problems from our shell, by directly adding this argument we accept the terms from the console itselfq–> We remove the tool’s banner from the outputu–> We indicate not to show errors if there are anyv–> Typical verbose of any tool (display more detailed information)w–> Shows only permissions that contain write access
This way, we can see how all users have write capability on the specified file. Which can be very useful to replace it and take advantage of it somehow.
Accesschk.exe is a very useful tool for enumerating information that can be very useful to know for the different types of escalations related to Windows services. In any case, its practical use will be better seen in each post of the different escalations.
How to restart services
As mentioned previously, in all escalations related to Windows services, an essential requirement is the ability to start, stop, or restart a service (not counting directly restarting the computer for a service that starts on boot). Once we know that we have the privileges to do so, there are different ways to carry it out:
net
We can start a service using:
net start <service name>
Similarly, we can stop it with:
net stop <service name>
We can also use net to list all running services:
net start
sc
sc (Service Controller) is a command-line program used for communication with the Windows Service Controller and installed services.
We can start a service with:
sc start <service name>
And stop it with:
sc stop <service name>
As extra information, with sc we can:
Check current service configuration
sc qc <service>
Example:
Check current service status
sc query <service>
Powershell
From PowerShell we can use a cmdlet to restart services:
Restart-Service <service name> -Force
Similarly, there are cmdlets to start and stop a service:
Start-ServiceStop-Service
The syntax is simple: <cmdlet> <service name>. Although you can also use the -Name argument to refer to the service:
Start-Service -Name <service name>Stop-Service -Name <service name>