Home/ATT&CK Technique/Path Interception by Unquoted Path
ATT&CK Technique

Path Interception by Unquoted Path

T1574.009 · stealth, execution

Adversaries may execute their own malicious payloads by hijacking vulnerable file path references. Adversaries can take advantage of paths that lack surrounding quotations by placing an executable in a higher level directory within the path, so that Windows will choose the adversary's executable to launch. Service paths and shortcut paths may also be vulnerable to path interception if the path has one or more spaces and is not surrounded by quotation marks (e.g., C:\unsafe path with space\program.exe vs. "C:\safe path with space\program.exe").

(stored in Windows Registry keys) An adversary can place an executable in a higher level directory of the path, and Windows will resolve that executable instead of the intended executable. For example, if the path in a shortcut is C:\program files\myapp.exe, an adversary may create a program at C:\program.exe that will be run instead of the intended program. This technique can be used for persistence if executables are called on a regular basis, as well as privilege escalation if intercepted executables are started by a higher privileged process.

Windows
▸

Atomic Tests

1
Executable Atomic Red Team test cases for exercising this technique in a lab. Copy a command, run it on the listed platform, confirm your detections fire.
command_promptelevatedwindowsExecution of program.exe as service with unquoted service path
When a service is created whose executable path contains spaces and isn’t enclosed within quotes, leads to a vulnerability known as Unquoted Service Path which allows a user to gain SYSTEM privileges. In this case, if an executable program.exe in C:\ exists, C:\program.exe will be executed instead of test.exe in C:\Program Files\subfolder\test.exe. 
copy "#{service_executable}" "C:\Program Files\windows_service.exe"
copy "#{service_executable}" "C:\program.exe"
sc create "Example Service" binpath= "C:\Program Files\windows_service.exe" Displayname= "Example Service" start= auto
sc start "Example Service"
▣

Mitigations

3
MITRE ATT&CK mitigations - vendor-agnostic guidance for reducing exposure to this technique.
M1022Restrict File and Directory Permissions

Restricting file and directory permissions involves setting access controls at the file system level to limit which users, groups, or processes can read, write, or execute files. By configuring permissions appropriately, organizations can reduce the attack surface for adversaries seeking to access sensitive data, plant malicious code, or tamper with system files.

Enforce Least Privilege Permissions
  • Remove unnecessary write permissions on sensitive files and directories.
  • Use file ownership and groups to control access for specific roles. Example (Windows): Right-click the shared folder.
  • Properties.
  • Security tab.
  • Adjust permissions for NTFS ACLs.
Harden File Shares
  • Disable anonymous access to shared folders.
  • Enforce NTFS permissions for shared folders on Windows. Example: Set permissions to restrict write access to critical files, such as system executables (e.g., /bin or /sbin on Linux). Use tools like chown and chmod to assign file ownership and limit access. On Linux, apply: chmod 750 /etc/sensitive.conf `chown root:admin /etc/sensitive.
conf` File Integrity Monitoring (FIM)
  • Use tools like Tripwire, Wazuh, or OSSEC to monitor changes to critical file permissions.
Audit File System Access
  • Enable auditing to track permission changes or unauthorized access attempts.
  • Use auditd (Linux) or Event Viewer (Windows) to log activities.
Restrict Startup Directories
  • Configure permissions to prevent unauthorized writes to directories like C:\ProgramData\Microsoft\Windows\Start Menu. Example: Restrict write access to critical directories like /etc/, /usr/local/, and Windows directories such as C:\Windows\System32.
  • On Windows, use icacls to modify permissions: icacls "C:\Windows\System32" /inheritance:r /grant:r SYSTEM:(OI)(CI)F.
  • On Linux, monitor permissions using tools like lsattr or auditd.
M1038Execution Prevention

Prevent the execution of unauthorized or malicious code on systems by implementing application control, script blocking, and other execution prevention mechanisms. This ensures that only trusted and authorized code is executed, reducing the risk of malware and unauthorized actions.

Application Control
  • Use Case: Use tools like AppLocker or Windows Defender Application Control (WDAC) to create whitelists of authorized applications and block unauthorized ones. On Linux, use tools like SELinux or AppArmor to define mandatory access control policies for application execution.
  • Implementation: Allow only digitally signed or pre-approved applications to execute on servers and endpoints. (e.g., `New-AppLockerPolicy -PolicyType Enforced -FilePath "C:\Policies\AppLocker.
xml"`) Script Blocking
  • Use Case: Use script control mechanisms to block unauthorized execution of scripts, such as PowerShell or JavaScript. Web Browsers: Use browser extensions or settings to block JavaScript execution from untrusted sources.
  • Implementation: Configure PowerShell to enforce Constrained Language Mode for non-administrator users. (e.g.
, Set-ExecutionPolicy AllSigned) Executable Blocking
  • Use Case: Prevent execution of binaries from suspicious locations, such as %TEMP% or %APPDATA% directories.
  • Implementation: Block execution of .exe, .bat, or .ps1 files from user-writable directories.
Dynamic Analysis Prevention
  • Use Case: Use behavior-based execution prevention tools to identify and block malicious activity in real time.
  • Implemenation: Employ EDR solutions that analyze runtime behavior and block suspicious code execution.
M1047Audit

Auditing is the process of recording activity and systematically reviewing and analyzing the activity and system configurations. The primary purpose of auditing is to detect anomalies and identify potential threats or weaknesses in the environment. Proper auditing configurations can also help to meet compliance requirements.

The process of auditing encompasses regular analysis of user behaviors and system logs in support of proactive security measures. Auditing is applicable to all systems used within an organization, from the front door of a building to accessing a file on a fileserver. It is considered more critical for regulated industries such as, healthcare, finance and government where compliance requirements demand stringent tracking of user and system activates.

System Audit
  • Use Case: Regularly assess system configurations to ensure compliance with organizational security policies.
  • Implementation: Use tools to scan for deviations from established benchmarks.
Permission Audits
  • Use Case: Review file and folder permissions to minimize the risk of unauthorized access or privilege escalation.
  • Implementation: Run access reviews to identify users or groups with excessive permissions.
Software Audits
  • Use Case: Identify outdated, unsupported, or insecure software that could serve as an attack vector.
  • Implementation: Use inventory and vulnerability scanning tools to detect outdated versions and recommend secure alternatives.
Configuration Audits
  • Use Case: Evaluate system and network configurations to ensure secure settings (e.g., disabled SMBv1, enabled MFA).
  • Implementation: Implement automated configuration scanning tools like SCAP (Security Content Automation Protocol) to identify non-compliant systems.
Network Audits
  • Use Case: Examine network traffic, firewall rules, and endpoint communications to identify unauthorized or insecure connections.
  • Implementation: Utilize tools such as Wireshark, or Zeek to monitor and log suspicious network behavior.
◈

Detection Coverage

1/6 layers
Coverage across standard detection surfaces. Rows marked none have no rule of that type mapped. Some are real blind spots worth closing; others are simply not applicable to this technique (e.g. YARA matches malware files, not network behaviour).
Behavioral / log (Sigma) none
Analytics (MITRE CAR) 2
Runtime / container (Falco) none
File / malware (YARA) none
Network (Suricata/Snort) none
Vuln scan (Nuclei) none
◈

CAR Analytics

2
MITRE Cyber Analytics Repository - field-tested detection logic for this technique, written as pseudocode/queries you adapt to your own SIEM (Splunk, Sentinel, EQL). Each is a ready starting point for a detection rule, not just a description.
CAR-2013-01-002Moderate coverageAutorun Differences

The Sysinternals tool [Autoruns](../sensors/autoruns) checks the registry and file system for known identify persistence mechanisms. It will output any tools identified, including built-in or added-on Microsoft functionality and third party software. Many of these locations are known by adversaries and used to obtain Persistence.

Running Autoruns periodically in an environment makes it possible to collect and monitor its output for differences, which may include the removal or addition of persistent tools. Depending on the persistence mechanism and location, legitimate software may be more likely to make changes than an adversary tool. Thus, this analytic may result in significant noise in a highly dynamic environment.

While Autoruns is a convenient method to scan for programs using persistence mechanisms its scanning nature does not conform well to streaming based analytics. This analytic could be replaced with one that draws from sensors that collect registry and file information if streaming analytics are desired. Utilizes the Sysinternals autoruns tool (ignoring validated Microsoft entries).

Primarily not a detection analytic by itself but through analysis of results by an analyst can be used for such. Building another analytic on top of this one identifying unusual entries would likely be a beneficial alternative.

CAR-2014-07-001High coverageService Search Path Interception

According to ATT&CK, an adversary may escalate privileges by intercepting the search path for legitimately installed services. As a result, Windows will launch the target executable instead of the desired binary and command line. This can be done when there are spaces in the binary path and the path is unquoted.

Search path interception should never happen legitimately and will likely be the result of an adversary abusing a system misconfiguration. With a few regular expressions, it is possible to identify the execution of services with intercepted search paths.

pseudocode
process = search Process:Create
services = filter processes where (parent_exe == "services.exe")
unquoted_services = filter services where (command_line != "\"*" and command_line == "* *")
intercepted_service = filter unquoted_service where (image_path != "* *" and exe not in command_line)
output intercepted_service
▣

Comply & Defend

NIST 800-53AC-02, AC-03, AC-04, AC-05, AC-06, CA-07, CM-02, CM-06, CM-07, CM-08, RA-05, SI-03, SI-04, SI-07, SI-10
D3FEND12 defensive techniques
Intelligence Graph · click any node to traverse
CVETechnique ActorTool Family
drag to reposition · click any node to traverse · button top-right enlarges
External lookups - second-class, for what we don’t hold ourselves
MITRE ATT&CKAtomic Red Teamcar (MITRE)
Vulnerabilities
CISA KEV catalog
CWE weaknesses
CAPEC attack patterns
Package vulnerabilities
Threat intelligence
Threat actors
Tools & malware
ATT&CK techniques
IOCs
Detection & defense
Sigma rules
YARA rules
Atomic Red Team tests
D3FEND countermeasures
Compliance
NIST 800-53
ISO 27001:2022
SOC 2 TSC
PCI-DSS v4.0
CIS Controls v8.1
About
All capabilities
Live statistics
Data sources
Privacy policy
Terms of service
threatengine.sh  ·  Open-source threat intelligence platform  ·  100+ authoritative sources  ·  Every fact traces to its origin