Detecting Unquoted Service Path Abuse: Inventory, Planting and Execution

When a service ImagePath contains spaces and is not wrapped in quotes, the service control manager tries each space-delimited prefix as an executable, so C:\Program Files\Vendor App\svc.exe is tried as C:\Program.exe first. If an attacker can write to an intermediate directory, the planted file runs with the service’s privileges on the next start (T1574.009). The weakness is common, cheap to find and cheap to detect.

Signals at a Glance

Finding Exposed Services

Start by measuring the exposure. An inventory of services with unquoted, space-containing paths gives you both a remediation list and an allowlist for the runtime detections. The query below overcounts because arguments also contain spaces, so refine the output before raising findings:

-- osquery: services with unquoted paths containing spaces
SELECT name, display_name, path, user_account, start_type
FROM services
WHERE path LIKE '% %'
  AND path NOT LIKE '"%'
  AND path NOT LIKE 'C:\Windows\%'
  AND start_type != 'DISABLED';
-- tune/validate: arguments after the executable produce false positives.

Catching the Planted Binary

Exploitation requires dropping an executable at a very specific path. File creation at the root of Program Files, or at C:\Program.exe, is almost never legitimate, and the later launch by services.exe confirms the abuse:

title: Executable Planted at Unquoted Service Path Segment
logsource:
  product: windows
  category: file_event
detection:
  program_root:
    TargetFilename: 'C:\Program.exe'
  programfiles_root:
    TargetFilename|re: '^C:\\Program Files( \(x86\))?\\[^\\]+\.exe$'
  condition: program_root or programfiles_root
level: high
# tune/validate: installers occasionally drop launchers here; allowlist by signer.

// Microsoft Defender (KQL) - services.exe launching a root-level executable
DeviceProcessEvents
| where InitiatingProcessFileName =~ "services.exe"
| where FolderPath =~ @"C:\Program.exe"
     or FolderPath matches regex @"^C:\\Program Files( \(x86\))?\\[^\\]+\.exe$"
| project Timestamp, DeviceName, FolderPath, SHA256, AccountName

• Fix the cause as well as the symptom: quote the ImagePath, or restrict write access on the intermediate directories. Both close the hole, and the quoting fix is a single registry edit per service.
• Re-run the inventory after every software deployment cycle. New vendor installers reintroduce the weakness regularly.
• Check ACLs on the intermediate directories, not just the final folder. The vulnerable segment is usually C:\ itself or a vendor parent folder.