Attackers use Path Interception by Unquoted Path when a service or process starts from a path containing spaces but no quotes, allowing Windows to search the wrong executable location. A planted binary earlier in the path can then run with elevated privileges. Defenders should quote service paths correctly and audit for writable directories in service paths.
How Windows chooses the wrong executable in an unquoted path
Path interception by unquoted path is an execution-order problem, not a privilege problem by itself. Windows parses the service command line from left to right, and when a path contains spaces without quotes it can treat earlier path fragments as candidate executables. That creates a predictable way for an attacker to redirect startup into a different binary.
The practical issue is that the service may still start normally from the administrator’s point of view while the wrong file is launched underneath it. That is why this weakness often stays hidden until someone inspects the exact service path, the filesystem layout, and which directories in that path are writable by non-admin users.
When the planted executable sits earlier in the search path and the service runs with elevated privileges, the attacker gets those privileges on launch. The weakness is most dangerous where the service account has broad local or domain permissions, or where the path includes user-writable directories that make the hijack easy to stage.
Why the attacker needs a writable directory, not just a bad command line
Unquoted paths become exploitable when the attacker can place a malicious binary in a location Windows will check before the intended executable. That usually means a writable folder in the service path, weak service permissions, or a deployment pattern that leaves an installation directory exposed. The flaw is therefore part path parsing, part filesystem control.
In practice, the attacker is looking for the earliest viable insertion point in the path. If that directory is protected, the unquoted path is usually only a misconfiguration; if it is writable, it becomes an execution opportunity. That distinction matters because defenders should not stop at quoting the path, they should also verify whether the path itself contains a writable segment.
The same logic is why remediation has to include both command-line hygiene and permission review. A quoted path removes the ambiguity, but a weak directory ACL or an over-permissive service installation can still create related startup abuse paths that deserve separate review.
What defenders should verify before calling it fixed
Fixing the string in the service configuration is necessary, but the control is only trustworthy after you confirm the service really launches the intended image and not a lookalike earlier in the path. That means checking the exact service command, the resolved executable, and the permissions on every directory the path traverses.
It is also worth reviewing whether the service runs as Local System or another high-privilege account. A path interception issue becomes far more serious when the launched binary inherits powerful privileges, because the compromise is immediate privilege abuse rather than a low-value user context execution.
For defenders who want a broader view of how attackers turn weak execution paths into footholds, Persistence Techniques Guide is a useful companion because it places service abuse and path hijacking alongside other startup-persistence methods. The same launch-condition thinking also appears in CWE Top 25 Guide, which helps teams map the underlying weakness to a structured software-security view.
Risk and Threat Considerations
Unquoted service paths are attractive because they convert a routine startup path into code execution with very little noise. The threat is strongest when the attacker can write to one of the candidate directories and when the service is restarted during maintenance, patching, or troubleshooting.
Failure mechanism: Windows searches for an executable at partial path boundaries when a spaced path is not quoted, so a planted binary earlier in the path can be launched instead of the intended service binary.
Impact: The wrong executable can inherit the service’s privileges, enabling local privilege escalation, persistence, or follow-on abuse of the host and connected credentials.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1036 — Masquerading | Unquoted path abuse redirects execution to a planted binary. |
| Recommendation — Map hijacked startup execution to T1036 and hunt for lookalike binaries in service paths. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Excessive service privileges make a path hijack materially worse. |
| Recommendation — Restrict service accounts to the minimum privileges needed to limit escalation impact. | ||
| CIS Controls v8 | CIS-5 — Account Management | Service execution depends on controlled accounts and permissions. |
| Recommendation — Review service account and directory permissions to remove writable execution paths. | ||
Practitioner Guidance
What to verify: Confirm that every Windows service path with spaces is quoted, then test the resolved image path rather than assuming the registry or service manager text is enough. Also check that no directory in the path is writable by non-administrators.
Decision rule: If the service runs with elevated privileges and any path segment is writable, treat the condition as exploitable exposure, not a cosmetic configuration issue. If the path is quoted but the directory ACLs remain weak, keep investigating adjacent service-abuse paths.
Practitioner takeaway: The real control is not just quoting a path, it is eliminating ambiguity and removing write access anywhere Windows could be tricked into launching the wrong binary.