NSSM 2.24 privilege escalation is not a classic buffer overflow or race condition—it is a design weakness amplified by common misconfigurations. Attackers love it because it turns a low-privilege foothold into full SYSTEM access with minimal noise.
The key takeaway: Audit your services today. Run accesschk.exe -c * | findstr "NSSM" across your Windows fleet. If you find NSSM 2.24, assume it is a potential backdoor. Harden it, replace it, or risk becoming the next case study in a privilege escalation report.
type C:\ProgramData\poc.txt
On a vulnerable system, this file will be created by SYSTEM. On a patched system, NSSM will reject the change due to validation errors. nssm-2.24 privilege escalation
The issue is not a memory corruption bug but a logic/permission flaw:
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
When NSSM installs a service using the command:
nssm install <ServiceName> <path-to-executable>
It creates a service with the following security descriptor (by default):
This allows an unprivileged user to:
Using PowerShell:
Get-ChildItem -Path C:\ -Filter nssm.exe -Recurse -ErrorAction SilentlyContinue | ForEach-Object & $_.FullName version
Using Sysmon or EDR: Look for process creation events where:
Later versions of NSSM (2.24.1, 2.25, and above) introduced critical safeguards: type C:\ProgramData\poc
Version 2.24 was the last build before these patches. It exists in countless enterprise golden images, legacy application stacks, and developer test environments where security updates are deprioritized.