Unlocking the Mystery of Unquoted Service Paths: Another Opportunity for Privilege Escalation 

Key Takeaways

• What it is. An unquoted service path occurs when a service is installed using a file path that contains spaces and is not in quotes.
• When it can be abused. The path must also be writable by the current user. Windows checks for the service executable one string at a time until it reaches the next executable.
• Why it matters. It gives an attacker an avenue for local privilege escalation. If the service runs as a domain user, or worse, a Domain Admin, the attacker inherits that account’s permissions and groups.
• How attackers find it. They enumerate with wmic, sc, icacls, and SharpUp or other pre-built tools.
• How to fix it. Enclose the service path in double quotes, and use icacls to remove modify permissions from standard users while still allowing read and execute access.

What is an unquoted service path and why does it matter? This blog covers what an unquoted service path looks like, how an attacker enumerates and exploits it, and how you can audit your services and harden them against this vulnerability.

What Is an Unquoted Service Path?

An unquoted service path occurs when a service is installed using a file path that contains spaces and is not in quotes. The other condition is that the path must have write permissions for the current user, which an attacker can then abuse.

How Windows Reads an Unquoted Service Path

Attackers can abuse this because Windows checks the service executable sequentially, taking the file path one string at a time until it reaches the next executable.

For the service path C:\Program Files\Inventory Service\inventory svc.exe, Windows will attempt to run executables in the following order:

1. C:\Program.exe — A malicious service binary will run if the attacker can write to C:\.
2. C:\Program Files\inventory.exe — A malicious service binary will run if the attacker can write to Program Files.
3. C:\Program Files\Inventory Service\inventory svc.exe — Windows finally arrives at the specified service path.

Why Unquoted Service Paths Matter

Unquoted service paths can be present due to either user or installer error. This configuration matters because an attacker can enumerate these paths and leverage them for privilege escalation.

This does not only give an attacker an avenue for local privilege escalation. If the service is set to run as a domain user, or worse, a Domain Admin, the attacker will inherit the permissions and groups of that account, arming them with even more dangerous capabilities.

Examples of Unquoted Service Paths in Customer Environments

Let’s examine some of the common unquoted service paths we’ve seen in our customers’ environments.

Service Path
C:\Program Files\{REDACTED}\{REDACTED}\ServiceHost.exe
C:\Program Files\{REDACTED}\bin\{REDACTED}.exe
C:\WINDOWS\system32\{REDACTED}\Intel(R) Audio Service\IntelAudioService.exe
C:\WINDOWS\Microsoft.NET\Framework64\v3.0\Windows Communication Foundation\SMSvcHost.exe
C:\Program Files (x86)\{REDACTED}\{REDACTED}\{REDACTED} Management Service\{REDACTED}AppxService.exe

Unquoted Service Path Exploitation in the Wild: An Incident Walkthrough

This incident shows an unquoted service path being abused in the wild on a remote system.

The Scenario

• Starting point: An attacker has gained initial access to a Windows server as a standard domain user and is looking to escalate their privileges to Domain Admin.
• The discovery: They’ve exhausted all other paths for privilege escalation and decide to further enumerate the target system for local privilege escalation. While continuing their enumeration, they stumble upon an unquoted service path vulnerability in a local inventory service.
• The target: They determine that this service is running as a service account that happens to be a Domain Admin. This is how they will achieve their goal of moving vertically to one of the domain controllers.
• The plan: They can abuse the unquoted service path vulnerability to introduce their custom C2 payload into the environment via a malicious service binary, escalate to Domain Admin, and then proceed to run ransomware on the domain controller.

Now, let’s go through the phases of this attack chain.

Phase 1: Enumerating Unquoted Service Paths

To enumerate systems for this vulnerability, attackers may utilize the following tools:

• wmic
• sc
• icacls
• SharpUp or other pre-built tools

Manual Enumeration

1. The attacker uses wmic to enumerate unquoted service paths.

2. Next, the attacker uses sc to find the START_TYPE, BINARY_PATH_NAME, and SERVICE_START_NAME.

3. The attacker sees that the service is running as the domain user ‘NORTH\inventory_svc’ and determines the user’s groups.

They determine that this user is part of the Domain Admins group.

4. The attacker uses icacls to see what permissions are set on the service path.

Tool Enumeration

To make enumeration easier, an attacker can execute SharpUp with the following arguments:

SharpUp.exe audit UnquotedServicePath

What the Attacker Knows After Enumeration

At this point, the attacker knows:

• There is a vulnerable service named “Inventory Service.”
• The service automatically starts when the computer is booted.
• The service is running as a Domain Admin.
• BUILTIN\USERS can write to the service path.
• C:\Program\Inventory Service\inventory is modifiable.

Phase 2: Exploiting the Unquoted Service Path

1. The attacker first verifies that the service is running.

2. Next, the attacker downloads a C2 payload to the “C:\Program Files\Inventory Service” folder and gets a callback in the C2 admin panel as inventory_svc.

3. The attacker can then use the Domain Admin account to access the domain controller and deploy ransomware.

How to Fix Unquoted Service Path Vulnerabilities

To harden systems against this vulnerability, ensure the service configuration contains quotes around the executable path and, most importantly, audit the permissions of the service path and executable to prevent unwanted changes.

Step 1: Enclose the Service Path in Double Quotes

Once an unquoted service path is discovered, edit the service configuration to enclose the path in double quotes, as shown below.

Note: The space after binPath= is required, and the quotes (\”) around the path must be escaped.

This ensures Windows interprets the full path as a single executable and does not mistakenly attempt to run paths such as:

• C:\Program.exe
• C:\Program Files\Example.exe

Step 2: Remove Modify Permissions From Standard Users

One final measure against modifying an unquoted service path is to use icacls to remove modify permissions from standard users while still allowing necessary read and execute access.

Audit Service Paths & Permissions

Understanding and mitigating unquoted service path exploitation is crucial for defending against these seemingly innocuous configuration oversights. By understanding how attackers enumerate and exploit these paths, and by diligently auditing your own services for their presence, you can proactively harden your systems.

Two audits matter most:

• Audit services: Ensure service paths are quoted when they contain spaces.
• Audit permissions: Ensure there are no weak permissions in place for service executable paths and accompanying service executables.

Auditing services and ensuring they adhere to these best practices will protect systems against unquoted service path vulnerabilities, giving you and your customers peace of mind that they are protected from one less privilege escalation vulnerability.

Want to strengthen threat detection and response across your client environments?

Request a Demo →