.\nssm.exe set ElevationTest Application "cmd.exe /c echo SYSTEM LEVEL > C:\ProgramData\poc.txt"
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. nssm-2.24 privilege escalation
In the ecosystem of Windows system administration, few tools are as beloved yet as misunderstood as the Non-Sucking Service Manager (NSSM). For years, NSSM has been the go-to solution for developers and sysadmins needing to run executable files (batch scripts, Python apps, or Node.js servers) as Windows services. Its ability to automatically restart crashed processes and its intuitive GUI have made it a staple.
However, version 2.24 (released several years ago) contains a specific, reproducible privilege escalation vulnerability that has flown under the radar for many organizations. While the maintainers have since addressed this in later versions, countless legacy systems and poorly maintained servers still run NSSM 2.24. The issue is not a memory corruption bug
This article dissects the mechanics of the NSSM 2.24 privilege escalation attack, why it works, and what happens when an attacker gains a foothold on a machine with this version installed.
The issue is not a memory corruption bug but a logic/permission flaw: released in the mid-2010s
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.
Since NSSM is often a trusted binary (signed, known), it can be used to execute arbitrary unsigned scripts under the guise of a legitimate service manager.