(Non-Sucking Service Manager) does not have a single, direct CVE for a "built-in" privilege escalation flaw, it is
frequently used by attackers and identified in vulnerabilities where its misconfiguration improper installation
by third-party software allows for local privilege escalation (LPE) Phoenix Contact
The most common ways privilege escalation occurs involving NSSM 2.24 include: 1. Insecure File Permissions
This is the most frequent exploitation path. Many installers deploy NSSM 2.24 with weak Access Control Lists (ACLs), such as granting the "Everyone" group "Full Control" or "Modify" rights to the folder where National Institute of Standards and Technology (.gov) The Attack : A low-privileged user replaces the legitimate
or the binary it launches with a malicious executable. When the service restarts (or the system reboots), the malicious code runs with privileges. Notable Examples IBM Robotic Process Automation
: Vulnerable to LPE because standard users could substitute the service binary. Apache CouchDB
: Vulnerable because files inherited parent directory permissions, allowing non-privileged users to swap the service launcher. Wowza Streaming Engine : Allowed authenticated users to replace nssm_x64.exe to gain LocalSystem rights. National Institute of Standards and Technology (.gov) 2. Unquoted Service Path Vulnerability If NSSM is installed in a path containing spaces (e.g., C:\Program Files\App\nssm.exe ) and the service's
registry entry is not enclosed in double quotes, it is vulnerable to "Unquoted Service Path" exploitation. The Attack
: Windows will attempt to find and execute files along the path in order. For example, it might try to run C:\Program.exe nssm-2.24 privilege escalation
before reaching the intended file. An attacker can place a malicious Program.exe at the root of the drive to hijack the service execution. NSSM - the Non-Sucking Service Manager 3. Exploitation in Ransomware Campaigns
The Non-Sucking Service Manager (NSSM) 2.24 is a popular tool for running any application as a Windows service. While the tool itself is not inherently malicious, it is frequently exploited for Local Privilege Escalation (LPE) due to misconfigurations or unquoted service paths. Core Vulnerability: Unquoted Service Paths
The most common privilege escalation involving NSSM 2.24 stems from "Unquoted Service Paths".
The Flaw: If a service path contains spaces (e.g., C:\Program Files\NSSM\nssm.exe) and is not enclosed in double quotes, Windows will look for executables at every break.
The Attack: An attacker can place a malicious program.exe in C:\ or nssm.exe in C:\Program Files\. When the service restarts, Windows may execute the attacker's file instead of the intended one, granting SYSTEM privileges. Exploitation in the Wild
NSSM is a "dual-use" tool often leveraged by advanced threat groups for persistence and elevated access:
Akira Ransomware: Used nssm-2.24 to create malicious services (like sysmon) to launch tunneling tools like Ngrok.
Head Mare & Twelve: Used NSSM to make traffic tunneling tools (e.g., Localtonet) persistent on compromised business automation servers.
Pelco VideoXpert: A known advisory (ZSL-2017-5418) highlighted how NSSM 2.24 in this software suite allowed non-privileged users to execute arbitrary code by replacing binaries in writable paths. Key Technical Details Vulnerable Version NSSM 2.24 (often bundled with third-party software) Common Path (Non-Sucking Service Manager) does not have a single,
C:\ProgramData\... or C:\Program Files\... with weak permissions Impact Full system takeover (Vertical Privilege Escalation) Detection EDR alerts for nssm.exe in unusual paths like \Windows\tmp\ Prevention & Mitigation
Quote Service Paths: Ensure all service binary paths are wrapped in double quotes.
Strict Permissions: Restrict write access for standard users on directories containing service executables.
Audit Services: Use sc qc [ServiceName] to check for unquoted paths or insecure binary locations.
If you'd like to see a sample Proof of Concept (PoC) script for detecting these vulnerabilities or need a remediation guide for a specific environment, let me know! Head Mare and Twelve: Joint attacks on Russian entities
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.
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. Step 1 – Enumeration An attacker with low-privileged
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 is convenient but dangerous if misconfigured. Always assume that a service running as SYSTEM with writable configuration is a local privilege escalation vector. Audit your endpoints, and don’t let convenience override security.
Disclaimer: This post is for educational and defensive purposes only. Unauthorized access to systems is illegal.
Title:
NSSM 2.24 – Weak Default Service Permissions Allow Local Privilege Escalation
Affected Software:
NSSM (Non-Sucking Service Manager) version 2.24 (and possibly prior versions)
Severity: High
Attack Vector: Local
Privileges Required: Low-privileged user (Authenticated, non-admin)
User Interaction: None
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.