Join our Newsletter — 33% off our NHI Course

Path Interception by Unquoted Path

Path Interception by Unquoted Path is a Windows weakness where a service or process starts from a path containing spaces but no quotation marks, allowing another executable earlier in the path to run. Attackers use it for privilege escalation. Defenders should quote paths correctly and review services with writable directories.

What the weakness is

Unquoted path interception happens when Windows resolves a service or process path that contains spaces but is not wrapped in quotation marks. The parser can treat the first space as the end of the command path, which lets an attacker place a different executable earlier in the path and have it run instead.

This is a classic execution-flow weakness, not a networking or malware-specific bug. It becomes dangerous because the operating system is doing exactly what it was asked to do, but with ambiguous syntax that can be exploited during startup or service launch.

Why it matters in Windows services

The weakness is especially relevant for services because services often run automatically and may have elevated privileges. If an attacker can write to a directory that appears earlier in the unquoted path, they may be able to intercept execution and turn a path-handling mistake into privilege escalation. That makes the issue a persistence technique as well as a local escalation path.

It is closely related to other execution-hijacking classes, including search-order abuse, path hijacking, and insecure service configuration. NHI Management Group’s CWE Top 25 Guide is useful context here because this weakness sits in the broader family of software flaws that turn parsing ambiguity into unintended execution.

How exposure is usually found and confirmed

Organisations usually start with service inventory and path review. The practical question is whether a service binary path contains spaces, whether it is quoted correctly, and whether any directory in the search path is writable by a lower-privileged user. Review should also include vendor documentation and service configuration, because the visible service name alone does not always show the real launch command.

Local testing can confirm whether another executable would be found first, but the real exposure check is environmental: writable directories, inherited permissions, and where the service runs with respect to privilege. A path that is harmless on a locked-down host can become exploitable if a directory later becomes writable or if a deployment script changes the service command line.

How to prevent and detect it

The primary fix is simple: quote service and process paths correctly, and do not leave writable directories in positions where they can be mistaken for executable locations. The defensive goal is to remove ambiguity before the service starts, not to rely on users or operators noticing the problem later.

Detection should look for services whose command lines contain spaces without quotes, newly created files in suspicious parent directories, and unexpected executables near service paths. After remediation, review whether anything already ran from the vulnerable path, because an intercepted launch can leave behind a backdoor, a modified service binary, or other follow-on persistence.

Risk and Threat Considerations

Unquoted path interception is dangerous because it converts a parsing flaw into code execution, often in a high-privilege context. The attacker does not need to break the service, only to supply a better-named executable in an earlier location that the operating system will choose.

Failure mechanism: An unquoted command path with spaces lets Windows split the launch string at the wrong point, then search and execute a different binary placed earlier in the path.

Impact: The attacker can gain elevated execution, plant persistence, or gain a foothold for lateral movement if the affected service runs with broad privileges.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
NIST SP 800-53 Rev 5 IA-5 — Authenticator Management Covers controlling credential and access-material handling around privileged Windows services.
AC-6 — Least Privilege Limits the damage when a hijacked service starts with excessive authority.
CM-7 — Least Functionality Supports removing unnecessary services and launch paths that create interception exposure.
Recommendation — Review service credentials and rotate any exposed secrets after a path-hijack compromise. Reduce service privileges so a hijacked launch cannot escalate beyond its needed scope. Disable unnecessary services and keep launch paths as simple as possible.
CIS Controls v8 CIS-5 — Account Management Supports reviewing service accounts and the privileges tied to exposed service launches.
CIS-6 — Access Control Management Supports restricting write access to directories that could be used for path interception.
Recommendation — Audit service-account scope and remove excess access from vulnerable services. Tighten directory permissions so lower-privileged users cannot plant an intercepting binary.

Practitioner Guidance

Why practitioners should care: This weakness often survives for years because services appear to work normally until someone tests the path syntax or changes directory permissions. Treat it as a configuration defect with real privilege impact, not a cosmetic hardening issue.

What to watch for: Focus on services that run as local system, services installed by third-party software, and any launch path that includes spaces. If the path cannot be corrected immediately, reduce write access around the path and validate that the service cannot be hijacked during startup.