PrivEsc: Unquoted Service Path

A couple of days ago I posted an article about the first steps an attacker would likely take to perform a desktop breakout attack. Where that post left off was at the point of looking for privilege escalation from domain user to local administrator.

This step isn’t always required as an attacker could look to mount attacks against other hosts on the domain to gain local administrator on key hosts or to skip straight to domain administrator through attacks such as token impersonation.

However gaining local administrator is often a required next step for an attacker and one method of achieving that is by exploiting unquoted service paths. In my experience finding unquoted service paths is a common occurrence, however actually being able to exploit them is not. (This is due to standard users not having write access to the root of C:\, which will be explained later – but there are sometimes alternative options!)

If a service is vulnerable an attacker may be able to escalate privileges to the level of the account that starts the service. A service is vulnerable if the path to the executable has a space in the filename and the file name is not wrapped in quote marks; exploitation requires write permissions to the path before the quote mark.

It’s that last part which is generally the problem in my experience as by default since Windows XP this has not been possible under default configuration. I have however used this during Penetration Tests where permissions and configuration have been messed up, so it’s worth being aware of even if you can’t drop it during every engagement. I’ll demonstrate through a real world example – PrivateFirewall 7.0, Unquoted Service Path Vulnerability.

Here I’ve got my locked-down Windows 8 machine and through a desktop breakout attack we’ve managed to get a command line. At this point I can use the following command to determine if there are any potentially vulnerable services:

wmic service get name,pathname

This will show me something like the following:

Here you can see in the centre of my command window there is a service called PFNet which has a path that includes a space but the path is not wrapped in quote marks. Now for this to be worth while the service must run with higher privileges than I already have as a domain user, I can check that with the command:

wmic service get pathname,startname

This will give me something like this:

Here I can see that the vulnerable path is running as LocalSystem! So this is  prime target for a privilege escalation attack. The vulnerability occurs because the path is not quote wrapped Windows cannot tell if the path is supposed to be:

C:\Program Files (x86)\Privacyware\Privatefirewall 7.0\pfsvc.exe
C:\Program Files (x86)\Privacyware\Privatefirewall.exe

This means that it will attempt to execute the file as if any of those were correct, starting at the shortest and moving up to the longest path until one works. Therefore if you can create a file in the root of C:\ called Program.exe, when Windows attempts to start the service it will first try to execute your program and not the valid EXE.

However by default you will not have write permissions to these directories as a domain user or local user. However if the permissions have been changed from default privilege escalation is possible.

Any EXE that you plant in the C:\Program.exe position will be executed when the system loads. Generally however, users won’t have write access to the root of C:\. Here we have an alternative option though in: C:\Program Files (x86)\Privacyware\Privatefirewall.exe

If you can write to either of these locations, the exploit should work. For this task I create an EXE which executes the following commands:

net user tester Password123! /add
net localgroup "Administrators" tester /add

So for our example I planted the EXE in the required location, rebooted and when I logged in I was prompted with the following warning:

Which is an additional “side effect” of using the C:\Program option instead of the previously mentioned subdirectory choice.

However the EXE has already been executed and if I run the net user command we can see my new account has been created as a local administrator:

At this point I can logout and the log in using my newly created local administrator account and I’ve completed the breakout of this host – and I’ve also put myself in a great position for escalating all the way up to domain administrator, details of those steps are here!


Be very wary before altering the permissions on folders in the C:\ drive, in particular anything under “Program Files”. Also be aware that when software installs itself it can alter these permissions so it’s always best to ensure that permissions on key directories are sane.

Additionally you can test to determine if any services are potentially vulnerable through being “unquoted” by using the wmic command as shown above.

An unofficial PowerShell script is available to fix this issue in a more automated manner: