
## General

In Windows, a service is a program that runs in the background to perform a specific function or task. The Service Control Manager (SCM) is a system service that is responsible for starting, stopping, and managing services on the computer. Service misconfiguration refers to the incorrect configuration of a service, which could potentially allow an attacker to exploit the service and gain unauthorized access to the system.

There are several ways in which service misconfiguration could be exploited via the SCM:

-   Starting a service with elevated privileges: An attacker could configure a service to start with higher privileges than intended, which could allow the service to perform actions that the user does not have permission to perform.
    
-   Modifying the properties of an existing service: An attacker could change the properties of an existing service, such as the path to the executable file or the user account under which the service runs, to execute malicious code or to gain unauthorized access to the system.
    
-   Creating a new service: An attacker could create a new service that runs malicious code, potentially allowing the attacker to gain access to the system or to perform other unauthorized actions.
    
-   Stopping or disabling a critical service: An attacker could stop or disable a critical service, such as the firewall or antivirus software, which could leave the system vulnerable to attacks.


## Commands

Windows services are managed by the **Service Control Manager** (SCM). The SCM is a process in charge of managing the state of services as needed, checking the current status of any given service and generally providing a way to configure services.

Each service on a Windows machine will have an associated executable which will be run by the SCM whenever a service is started. It is important to note that service executables implement special functions to be able to communicate with the SCM, and therefore not any executable can be started as a service successfully. Each service also specifies the user account under which the service will run.

To better understand the structure of a service, let's check the apphostsvc service configuration with the `sc qc` command:

Command Prompt
```shell-session
C:\> sc qc apphostsvc
```

Here we can see that the associated executable is specified through the **BINARY_PATH_NAME** parameter, and the account used to run the service is shown on the **SERVICE_START_NAME** parameter.

Services have a Discretionary Access Control List (DACL), which indicates who has permission to start, stop, pause, query status, query configuration, or reconfigure the service, amongst other privileges. The DACL can be seen from Process Hacker (available on your machine's desktop):

![Service DACL](https://tryhackme-images.s3.amazonaws.com/user-uploads/5ed5961c6276df568891c3ea/room-content/d8244cfd9d64a7be30f5fb0308fd0806.png)  

All of the services configurations are stored on the registry under `HKLM\SYSTEM\CurrentControlSet\Services\`:

![Service registry entries](https://tryhackme-images.s3.amazonaws.com/user-uploads/5ed5961c6276df568891c3ea/room-content/06c05c134e4922ec8ff8d9b56382c58f.png)  

A subkey exists for every service in the system. Again, we can see the associated executable on the **ImagePath** value and the account used to start the service on the **ObjectName** value. If a DACL has been configured for the service, it will be stored in a subkey called **Security**. As you have guessed by now, only administrators can modify such registry entries by default.

- **Insecure Permissions on Service Executable (Example)**

	If the executable associated with a service has weak permissions that allow an attacker to modify or replace it, the attacker can gain the privileges of the service's account trivially.

	To understand how this works, let's look at a vulnerability found on Splinterware System Scheduler. To start, we will query the service configuration using `sc`:

	Command Prompt

	```shell-session
	C:\> sc qc WindowsScheduler
	[SC] QueryServiceConfig SUCCESS
	
	SERVICE_NAME: windowsscheduler
        TYPE               : 10  WIN32_OWN_PROCESS
        START_TYPE         : 2   AUTO_START
        ERROR_CONTROL      : 0   IGNORE
        BINARY_PATH_NAME   : C:\PROGRA~2\SYSTEM~1\WService.exe
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : System Scheduler Service
        DEPENDENCIES       :
        SERVICE_START_NAME : .\svcuser1
	```

	We can see that the service installed by the vulnerable software runs as svcuser1 and the executable associated with the service is in `C:\Progra~2\System~1\WService.exe`. We then proceed to check the permissions on the executable:

	Command Prompt

	```shell-session
	C:\Users\thm-unpriv>icacls C:\PROGRA~2\SYSTEM~1\WService.exe
	C:\PROGRA~2\SYSTEM~1\WService.exe Everyone:(I)(M)
	                                  NT AUTHORITY\SYSTEM:(I)(F)
	                                  BUILTIN\Administrators:(I)(F)
	                                  BUILTIN\Users:(I)(RX)
		                              APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
	                                  APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APPLICATION PACKAGES:(I)(RX)
	
	Successfully processed 1 files; Failed processing 0 files
	```

	And here we have something interesting. The Everyone group has modify permissions (M) on the service's executable. This means we can simply overwrite it with any payload of our preference, and the service will execute it with the privileges of the configured user account.

	Let's generate an exe-service payload using msfvenom and serve it through a python webserver:
