Understanding Windows Service Permission Vulnerabilities Using WMI Queries

Windows services are background processes that perform important system and application tasks. Many services run with elevated privileges, allowing them to access critical system resources and perform administrative functions.

Because of their elevated privileges, Windows services are often targeted by attackers seeking to gain unauthorized access to a system. One common security issue involves weak permissions on service executable files, which can allow regular users to modify service binaries and potentially gain administrator-level access.

This article explains how security scanners use WMI queries to identify vulnerable Windows services and how administrators can investigate and remediate these issues.


What Is a Windows Service?

A Windows service is a program that runs in the background without direct user interaction. Services can start automatically when Windows boots and often continue running regardless of whether a user is logged in.

Examples of Windows services include:

  • Print Spooler
  • Windows Update
  • SQL Server Services
  • Antivirus Services
  • Backup Services
  • Monitoring Agents

Many of these services run under privileged accounts such as:

  • LocalSystem
  • LocalService
  • NetworkService

Because these accounts possess elevated permissions, compromising a service can provide significant access to a system.


What Is Privilege Escalation?

Privilege escalation occurs when a user gains permissions beyond those originally assigned to their account.

For example:

  1. A user logs in with a standard account.
  2. The user discovers a vulnerable service executable.
  3. The user replaces or modifies the executable.
  4. The service restarts.
  5. The malicious code runs under the service account.
  6. The user gains elevated privileges.

This attack is particularly dangerous because it often does not require administrative credentials.


Understanding the Vulnerability

The reported vulnerability focuses on weak file permissions applied to service executable files.

A vulnerable scenario might look like this:

C:\Program Files\Application\Service.exe

If the Windows “Users” group has permission to:

  • Write
  • Modify
  • Full Control

then any regular user could potentially replace the executable with malicious code.

When the service starts again, the malicious code executes using the service account’s privileges.


What Is WMI?

Windows Management Instrumentation (WMI) is a Microsoft technology that provides a standardized way to access management information about Windows systems.

Administrators and security tools use WMI to:

  • Retrieve hardware information
  • Query installed software
  • Obtain operating system details
  • Manage services
  • Monitor system performance

WMI exposes information through classes organized in namespaces.

One of the most commonly used namespaces is:

root\cimv2

The Win32_Service WMI Class

The vulnerability scanner uses the following WMI class:

Win32_Service

This class contains information about all Windows services, including:

  • Service Name
  • Display Name
  • Start Mode
  • Status
  • Service Account
  • Executable Path

A security scanner can query this information using:

SELECT PathName
FROM Win32_Service

The result returns the executable path associated with every service installed on the machine.


Running WMI Queries on Windows

Administrators can test the same query manually using PowerShell.

Display Service Executable Paths

Get-WmiObject -Query "SELECT PathName FROM Win32_Service" `
              -Namespace "root\cimv2"

Modern versions of PowerShell can also use CIM:

Get-CimInstance Win32_Service |
Select-Object Name, PathName

Example output:

Name            PathName
----            --------
Spooler         C:\Windows\System32\spoolsv.exe
MSSQLSERVER     C:\Program Files\Microsoft SQL Server\MSSQL\sqlservr.exe
MyService       C:\Applications\MyService\Service.exe

What Happens After the WMI Query?

The WMI query only identifies service executable locations.

The vulnerability scanner then performs additional checks:

  1. Retrieve executable path
  2. Read file permissions (ACL)
  3. Determine whether unprivileged users can modify the file
  4. Flag the service if insecure permissions are detected

Understanding ACLs

ACL stands for Access Control List.

An ACL defines who can perform actions on a file or folder.

Common permissions include:

PermissionDescription
ReadView file contents
WriteModify file contents
ModifyRead, write, and delete
Full ControlComplete access

Security scanners typically focus on permissions granted to:

  • Everyone
  • Users
  • Authenticated Users

If any of these groups can modify a service executable, the system may be vulnerable.


Checking File Permissions Manually

You can inspect permissions using PowerShell:

Get-Acl "C:\Program Files\Application\Service.exe" |
Format-List

Or using the Windows graphical interface:

  1. Right-click the executable.
  2. Select Properties.
  3. Open the Security tab.
  4. Review group permissions.

Look for permissions assigned to:

  • Everyone
  • Users
  • Authenticated Users

Particularly:

  • Write
  • Modify
  • Full Control

Example of a Vulnerable Configuration

Suppose a service runs as LocalSystem:

Service Name: DataCollector
Executable:
C:\Program Files\DataCollector\collector.exe

Permissions:

Administrators - Full Control
SYSTEM         - Full Control
Users          - Modify

This configuration is dangerous because any standard user can replace:

collector.exe

with a malicious executable.

When the service restarts, the attacker’s code executes as LocalSystem.


How Security Scanners Detect This Issue

Vulnerability management platforms perform the following workflow:

Step 1

Query installed services:

SELECT PathName
FROM Win32_Service

Step 2

Extract executable locations.

Step 3

Inspect ACL permissions.

Step 4

Check whether groups such as:

  • Users
  • Everyone

possess:

  • Write
  • Modify

permissions.

Step 5

Report the service as vulnerable if weak permissions are detected.


Remediation Recommendations

To address the vulnerability:

Restrict File Permissions

Only trusted accounts should have modification rights.

Recommended permissions:

SYSTEM         Full Control
Administrators Full Control
Users          Read & Execute

Protect Parent Directories

Verify permissions on:

C:\Program Files\Application\

as well as the executable itself.

Review Third-Party Software

Many findings originate from:

  • Monitoring agents
  • Backup software
  • Legacy applications
  • Custom services

Conduct Regular Security Audits

Periodically review:

  • Service configurations
  • File permissions
  • Service accounts
  • Startup settings

Useful PowerShell Commands

List Services and Executable Paths

Get-CimInstance Win32_Service |
Select Name, PathName

View File Permissions

Get-Acl "C:\Path\Service.exe"

Find Services Running as LocalSystem

Get-CimInstance Win32_Service |
Where-Object {$_.StartName -eq "LocalSystem"}

Conclusion

Weak permissions on Windows service executables represent a common privilege escalation vulnerability. Security scanners often use WMI queries such as:

SELECT PathName
FROM Win32_Service

to identify service executable locations before examining their file permissions. If regular users have write or modify access to these executables, attackers may be able to execute malicious code with elevated privileges.

Understanding how WMI queries, ACLs, and Windows services work together allows administrators to investigate findings reported by vulnerability scanners and secure their systems against unauthorized privilege escalation attacks.

This article is inspired by real-world challenges we tackle in our projects. If you're looking for expert solutions or need a team to bring your idea to life,

Let's talk!

    Please fill your details, and we will contact you back

      Please fill your details, and we will contact you back