I found a service on my Windows 10 computer which uses an unquoted service path. As the path contains and are not quoted, Windows look for the .exe file the following way:


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

C:\Program Files (x86)\Donald Duck\Donald_Duck.exe <original path>

My current problem is that if I put another exe file in C:\Program Files (x86)\Donald.exe which I want the service to execute, I get this error message:

"A timeout (30000 milliseconds) was reached while waiting for a transaction response from the Donald Duck service".

The service which starts this process during startup is NT AUTHORITY\SYSTEM and has full access to both files. As I get this error I'm pretty sure the file is in the correct path but I don't know how to further exploit this vulnerability as the Event Viewer doesn't give me any more detailed information.

Could there be any form of hashcheck before the file execution?

  • Tried disabling UAC? Commented Dec 16, 2016 at 12:02
  • @Shritam Bhowmick: Yes I have, without any luck. Still the same problem. Commented Dec 16, 2016 at 12:58
  • Is the exploit executable you place there an actual service implementing the server manager interface? If not it might get started but you receive the error message.
    – eckes
    Commented Jul 14, 2017 at 6:12

3 Answers 3


Your service should always return back to windows service manger(SIM) within a proper amount of time... if your .exe file is a back door obviously it wont return to windows service manager... You can make your donald.exe to start another process and return safely to windows.. the other proc can be your backdoor.Check createprocess example in msn for this.


Vinod has the right information, but to expand on it a little bit:

The Service Control Manager (SCM, also see MSDN) is the parent process of all Windows services, and is also a Remote Procedure Call (RPC) server. When a service is started (and assuming that the service isn't in a shared binary, typically svchost.exe, which is a configuration primarily used for Microsoft-written services) the SCM launches the service command (in your example, C:\Program Files (x86)\Donald Duck\Donald_Duck.exe) and then waits for the service to connect back to the SCM via RPC and report that it is in startup. If the service fails to report back to the SCM (or it reports back that it was unable to start for some reason, or fails to proceed from the startup to running state) within a time limit (30000ms, or 30 seconds) then the SCM will kill the process.

For exploitation purposes, there's three ways around this.

  • Do your work within the 30 second window (ideally well within it, as on a sufficiently-loaded machine you may spend a lot of that window waiting on CPU time or I/O). If all you need to do is, say, change a registry key or access a file, or perhaps something like inject a DLL into another privileged process, this is usually fine.
  • Launch a child process that does the actual work. The SCM will kill the process it launched, but children of that process can continue executing.
  • Report back to the SCM that you are, in fact, the hijacked service and are doing the right thing. This is non-trivial but not actually that difficult if you know any C - or especially Win32 - programming (in particular, you needn't know a thing about RPC, as it is all wrapped in Win32 ServiceDoThing() APIs). You may need to do this if, for example, it's important to your exploit scenario that the service appear to be running (perhaps some other component cares about whether starting the service succeeded, or some monitoring process will complain to somebody if the launch fails). The documentation on reporting that you are a service program is found in MSDN.

Regardless of all this, there's something else you should consider. Unless somebody has changed the NTFS permissions from their defaults, you cannot actually create any of those files without already being an Administrator! By default, non-admin users can create (or edit) directories but not files in the root of a drive, and of course the Program Files (x86) directory already exists so you can't create a new copy of it. Nor can you rename it, to replace it with another directory you control. You also cannot create, edit, or rename contents of Program Files or Program Files (x86) at all, without admin privileges.

Since having Administrator privileges is equivalent to having SYSTEM privileges (that is, an admin can either take control and edit the ACL on anything they want to access even if it's normally SYSTEM-only, or can simply launch a program as SYSTEM), if you have enough privileges to exploit this coding error, you already have all the privileges it would give you. In other words, there is no Escalation of Privilege here. It is still a coding error, and could have a security impact on a misconfigured system, but at that point the error really comes down to whoever changed the ACLs on the root of the drive or the Program Files (x86) directory.


It's possible that a fix, such as -- https://gallery.technet.microsoft.com/scriptcenter/Windows-Unquoted-Service-190f0341 -- has been implemented?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .