Exploiting Unquoted Service Paths in Windows Kernel Drivers

In the landscape of Windows privilege escalation, few vulnerabilities are as deceptively simple yet potentially catastrophic as the unquoted service path. While most security practitioners are familiar with using this technique to escalate from `LocalService` to `SYSTEM` in user-mode, a far more sinister variant exists: the exploitation of unquoted paths to load malicious kernel-mode drivers.

When an attacker successfully hijacks a service path that points to a kernel driver, the boundary between user-mode and kernel-mode (Ring 3 to Ring 0) evaporates. This is not merely a privilege escalation; it is a complete system compromise, providing the attacker with the ability to manipulate the kernel, bypass EDR (Endpoint Detection and Response) hooks, and achieve near-perfect persistence.

The Mechanics of Path Interception

The Windows Service Control Manager (SCM) is responsible for starting, stopping, and managing system services. When a service is configured to run, the SCM looks at the `ImagePath` value within the service's registry key (typically located under `HKLM\SYSTEM\CurrentControlSet\Services\<ServiceName>`).

The vulnerability arises when this `ImagePath` contains spaces and is not enclosed in quotation marks. For example, consider a service configured with the following path:

`C:\Program Files\Custom Driver\driver.sys`

When the SCM attempts to execute this path, the Windows API's failure to find a quoted string causes it to parse the string character by character, treating spaces as delimiters. The SCM will attempt to locate and execute files in the following order:

1. `C:\Program.exe`
2. `C:\Program Files\Custom.exe`
3. `C:\Program Files\Custom Driver\driver.sys`

If an attacker has write permissions to any of the parent directories (e.g., `C:\`), they can drop a malicious executable named `Program.exe`. However, in the context of kernel drivers, the exploitation becomes significantly more complex and dangerous.

Escalating to Ring 0: The Kernel Driver Twist

In a standard user-mode exploit, the payload is a simple `.exe` that spawns a reverse shell. In a kernel-mode exploit, the payload is a `.sys` driver. The goal is to trick the SCM into loading a malicious driver file instead of the legitimate one.

The Attack Vector

For this exploit to be viable, two conditions must be met:

1. Unquoted Path: The `ImagePath` of a driver service must be unquoted and contain spaces.
2. Write Access: The attacker must have write permissions to one of the intermediate directories in the path sequence.

While `C:\` is generally protected, many third-party software installers create directories with overly permissive Access Control Lists (ACLs). If a driver is installed in a path like `C:\Vendor Software\Driver\driver.sys` and the `C:\Vendor Software` directory is writable by `Authenticated Users`, the path is ripe for exploitation.

The Payload: Crafting a Malicious `.sys` File

The payload cannot be a standard user-mode executable. It must be a valid Windows Driver Model (WDM) or Windows Driver Framework (WDF) driver. The entry point for any driver is the `DriverEntry` function.

A minimal, functional malicious driver would look like this (in C):

```c

#include <ntddk.h>

NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath) {

UNREFERENCED_PARAMETER(DriverObject);

UNREFERENCED_PARAMETER(RegistryPath);

// The payload: For demonstration, we'll just print to the kernel debugger

DbgPrint("Kernel exploit successful. Ring 0 access achieved.\n");

// In a real attack, this is where you would:

// 1. Disable Driver Signature Enforcement (DSE) via memory patching

// 2. Patch kernel structures (e.g., EPROCESS for token stealing)

// 3. Hide processes or files

return STATUS_SUCCESS;

}

```

When the SCM executes the intercepted path, it loads this `.sys` file into the kernel address space. Because the SCM is executing the load operation, the driver is initialized with high privileges.

Implementation and Operational Considerations

Discovery

Discovery involves auditing the registry for unquoted paths. A simple PowerShell one-liner can identify potential targets by parsing the `ImagePath` of all services:

```powershell

Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\* |

Where-Object { $_.ImagePath -notmatch '"' -and $_.ImagePath -match ' ' } |

Select-Object PSChildName, ImagePath

```

Execution Flow

1. Identify the target: Find a service like `C:\Hardware Tools\Driver\hw.sys` where `C:\Hardware Tools` is writable.
2. Prepare the payload: Compile the malicious `hw.sys` using the Windows Driver Kit (WDK).
3. Deployment: Drop the malicious `hw.sys` into `C:\Hardware.exe` (if the path allows) or, more accurately for drivers, ensure the hijacked path points to a file that the SCM will load as a driver.

• Note: If the hijacked path leads to a `.exe`, the SCM will run it as a user

Conclusion

As shown across "The Mechanics of Path Interception", "Escalating to Ring 0: The Kernel Driver Twist", "Implementation and Operational Considerations", a secure implementation for exploiting unquoted service paths in windows kernel drivers depends on execution discipline as much as design.

The practical hardening path is to enforce strict token/claim validation and replay resistance, host hardening baselines with tamper-resistant telemetry, and protocol-aware normalization, rate controls, and malformed-traffic handling. This combination reduces both exploitability and attacker dwell time by forcing failures across multiple independent control layers.

Operational confidence should be measured, not assumed: track detection precision under peak traffic and adversarial packet patterns and time from suspicious execution chain to host containment, then use those results to tune preventive policy, detection fidelity, and response runbooks on a fixed review cadence.