ESET NOD32 Antivirus 17.0.16.0 - Unquoted Service Path

ESET NOD32 Antivirus 17.0.16.0 — Unquoted Service Path: Analysis, Detection, and Mitigation

This article explains the unquoted service path issue reported for ESET NOD32 / ESET Security (version 17.0.16.0) and provides defensive guidance for detection, risk assessment, and remediation. It focuses on accurate technical detail, real-world context, and practical hardening steps while avoiding instructions that would enable abuse.

What is an unquoted service path?

An unquoted service path is a configuration issue in Windows services where the BINARY_PATH_NAME contains spaces but is not enclosed in quotes. When a service configured to start under a high-privilege account (for example, LocalSystem) uses such an unquoted path, Windows can interpret the path components in a way that allows an attacker with write access to certain directories to influence which executable is launched. This can lead to local privilege escalation if an attacker can write to one of those directories.

Classically this is categorized under CWE-428 (Unquoted Search Path or Element) and is considered a configuration weakness rather than a code bug. The attack requires local write access to a directory referenced by the unquoted path and sufficient privileges to place a program there that the service would execute.

Why this matters for ESET NOD32 / ESET Security

ESET services typically run with SYSTEM privileges to perform deep system scanning and protection. If a service's binary path is unquoted and contains spaces (for example, C:\Program Files\ESET\...), it could be potentially exploitable on systems where an attacker already has local write access to one of the path components. Whether the actual product instance is vulnerable depends on how the service was installed and how its BINARY_PATH_NAME is represented in the service configuration.

Item	Observed Value (example)
Service name	ekrn (ESET Service)
BINARY_PATH_NAME	"C:\Program Files\ESET\ESET Security\ekrn.exe" (quoted) — safe
Alternative output	C:\Program Files (x86)\ESET\ESET Security\ekrn.exe (unquoted) — potentially vulnerable depending on exact configuration

Detection: How to check your system (defensive)

The following commands and a PowerShell scan show how to identify services with unquoted paths. These checks are intended for administrators and defenders to inventory and remediate potential issues.

Windows built-in commands

wmic service get name,displayname,pathname,startmode | findstr /i "auto" | findstr /i /v "c:\windows\\" | findstr /i /v '"'

Explanation: This WMIC pipeline lists services set to Auto start, filters out typical Windows services under C:\Windows\, and then filters out entries that already contain quotes (a quick heuristic to highlight unquoted paths). It helps surface candidate services for further review. Administrative privileges are typically required to see all service paths.

sc qc ekrn

Explanation: The "sc qc" command queries the specific service configuration (here for the example service ekrn). Look at BINARY_PATH_NAME — if it is not quoted and contains spaces, the service should be investigated. Output showing the binary path quoted indicates that the service, as configured, is not subject to the traditional unquoted-service-path risk.

PowerShell scan (defensive)

Get-WmiObject -Class Win32_Service |
  Where-Object { $_.StartMode -eq 'Auto' -and $_.PathName -and $_.PathName -notmatch '^"' } |
  Select-Object Name, DisplayName, PathName

Explanation: This PowerShell snippet enumerates services set to Auto start, filters out entries where the PathName begins with a quote, and lists Name, DisplayName and PathName for review. Use this script as an inventory tool; it identifies candidates that warrant manual inspection and remediation.

Interpreting detection results

• If a service BINARY_PATH_NAME is already wrapped in quotes, the classic unquoted-path attack vector is not present for that configured path.
• If you see unquoted paths containing spaces (e.g., C:\Program Files\Vendor\app.exe), these services should be reviewed promptly. Note that some services may be using system call semantics or arguments that require careful validation before changing.
• Not all unquoted paths are exploitable in practice — exploitation also requires local write access to one of the directories in the path and appropriate timing/placement of a crafted executable. Nevertheless, it is a simple and recommended hardening step to quote service paths where appropriate.

Risk assessment: attack feasibility and prerequisites

An attacker would generally need local write privileges to one of the path components (for example, C:\Program.exe if the service binary path is C:\Program Files\Vendor\app.exe and interpreted as C:\Program.exe). This means unquoted service paths are primarily dangerous when:

• an attacker already has some local access or can drop files into directories in the path chain;
• the service runs with high privileges (SYSTEM, LocalService, or another privileged account); and
• the system lacks other defense-in-depth controls that would block or detect unauthorized binaries (Windows Defender, application whitelisting, EDR/HIPS, etc.).

Responsible disclosure and vendor status

Vulnerability handling of this class often results in vendor guidance rather than code fixes because the correct fix is to ensure service paths are quoted and file system permissions are hardened. In many cases, software installers already quote BINARY_PATH_NAME. For ESET, installations on different architectures (x86 vs x64) or custom installers could produce different path formats; administrators should verify their installed service entries.

Mitigation and remediation (recommended)

The most reliable mitigations are administrative and configuration-focused. Apply the following prioritized steps:

• Apply vendor updates: Ensure ESET is updated to the latest supported version and apply any vendor-recommended hardening updates.
• Quote the service path: Ensure BINARY_PATH_NAME is enclosed in quotes. Modify the service configuration only as an administrator and follow change-management policies. Verifying and correcting service paths eliminates the attack vector caused by path parsing ambiguity.
• Restrict NTFS write permissions: Ensure only trusted administrators have write access to program folders and parent directories. Prevent non-privileged users from writing to locations under C:\Program Files\ or other system-level paths.
• Use application allowlisting: Implement AppLocker or Windows Defender Application Control (WDAC) to prevent unknown binaries from running, reducing the impact of misuse if files are placed into directories.
• Monitor and alert: Use EDR/AV logs and SIEMs to detect unexpected service modifications, new executables in program folders, or service restarts under unusual circumstances.

How to safely correct a service path (administrative change)

You can correct an unquoted BINARY_PATH_NAME using Windows service configuration tools. Any change should be performed by an administrator and validated in a test environment before rolling out to production. Example administration steps (defensive) include using the Service Control Manager (services.msc), the registry editor (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\), or sc.exe to set the binpath to a quoted value.

sc config "ekrn" binPath= "\"C:\Program Files\ESET\ESET Security\ekrn.exe\""

Explanation: This command sets the service binary path to a quoted string, which prevents the unquoted-path ambiguity. Note: changing a service configuration can affect service behavior — validate after change and restart the affected service if required. Always follow change-control policies and have backups or snapshots available.

Operational hardening checklist

• Regularly scan for unquoted service paths and remediate findings.
• Lock down write permissions on program directories and their parents.
• Apply vendor and OS security updates promptly.
• Use application control and endpoint detection/response to catch anomalous behavior.
• Document changes and maintain an inventory of critical services and their configurations.

Summary

Unquoted service paths are a long-standing Windows configuration issue that can facilitate privilege escalation when combined with local write access to path components and services running with high privileges. For ESET NOD32 / ESET Security installations, verify the configured BINARY_PATH_NAME for each service; if a path is unquoted and contains spaces, treat it as a configuration issue to remediate. The recommended fixes are straightforward: ensure paths are quoted, lock down NTFS permissions, keep software updated, and use defense-in-depth controls such as application allowlisting and monitoring.

Following the detection and remediation guidance above will reduce exposure to this class of vulnerability and improve the overall security posture of endpoints running security products and other services.