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.
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. nssm-2.24 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.
The Non-Sucking Service Manager (NSSM) version 2.24 is susceptible to a Local Privilege Escalation (LPE) vulnerability. NSSM is a utility used to wrap arbitrary applications as Windows Services. Due to insufficient sanitization of the application path and arguments when installed as a service, a local attacker can manipulate the service binary path to execute arbitrary code with SYSTEM privileges. NSSM 2
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 allows users to install a service by specifying an application path (e.g., nssm install ServiceName "C:\Path\To\App.exe"). While NSSM attempts to validate the executable, version 2.24 contains logic flaws regarding how it handles the executable path and command-line arguments passed to the Windows Service Control Manager (SCM). NSSM (Non-Sucking Service Manager) has long been a
The core issue arises because the service configuration created by NSSM often relies on the unquoted service path vulnerability or allows for the injection of commands/arguments that the Service Control Manager passes directly to the CreateProcess API.
If an attacker has write access to a directory involved in the service execution chain (e.g., a directory with weak permissions where the service binary resides or a path containing spaces without quotes), they can plant a malicious executable. When the service is started or restarted, the operating system or NSSM will execute the malicious file with SYSTEM privileges.
Furthermore, specific to NSSM 2.24, the tool allows the modification of the AppParameters or Application registry keys (located at HKLM\SYSTEM\CurrentControlSet\Services\ServiceName\Parameters) without strict integrity checks if the attacker has sufficient privileges to modify the service configuration (often achievable via standard user rights if service permissions are misconfigured).
Attackers can install a NSSM service pointing to cmd.exe /c net user backdoor P@ssw0rd /add & net localgroup administrators backdoor /add. After the next reboot, the backdoor user is created.