Escalation: Nssm-2.24 Privilege

Published: For educational and defensive security purposes. Always obtain permission before testing on any system you do not own.

Understanding NSSM-2.24 and Potential Privilege Escalation NSSM (the Non-Sucking Service Manager) version 2.24 is a widely used utility that allows administrators to wrap any executable or script into a Windows service. While NSSM itself is not inherently "vulnerable" in its core code, the way it is deployed and configured—especially in version 2.24—frequently introduces Local Privilege Escalation (LPE) vulnerabilities in the host systems it manages. Common Attack Vectors Involving NSSM-2.24

Privilege escalation typically occurs not because of a bug in NSSM, but because of misconfigurations in the services it creates. In many cases, these misconfigurations allow a low-privileged user to gain SYSTEM or Administrator access. 1. Unquoted Service Paths

This is the most common vulnerability associated with NSSM-2.24 deployments.

The Issue: If a service's executable path contains spaces and is not enclosed in double quotes, Windows may misinterpret the path. For example, if the path is C:\Program Files\My Service\nssm.exe, Windows might try to execute C:\Program.exe first.

The Exploit: If a low-privileged user has write access to the root directory (e.g., C:\), they can place a malicious binary named Program.exe there. When the service restarts, Windows executes the malicious file with the elevated privileges of the service (often LocalSystem). 2. Insecure Permissions on NSSM.exe Pelco VideoXpert 1.12.105 - Local Privilege Escalation

While NSSM 2.24 is a legitimate tool used to manage Windows services, it is often central to privilege escalation attacks due to improper deployment permissions rather than a flaw in its own source code.

When NSSM is bundled with third-party installers, it frequently inherits weak folder or file permissions, allowing low-privileged users to replace the nssm.exe binary or its managed application with malicious code. Key Attack Vectors

Improper File Permissions: Many applications (e.g., Wowza Streaming Engine, Apache CouchDB, Phoenix Contact) have been found to install NSSM with "Full Control" for the "Everyone" or "Users" group. Attackers can swap the binary with a malicious executable, which then runs with SYSTEM privileges upon the next service restart.

Unquoted Service Paths: If the service path to NSSM contains spaces and is not enclosed in quotes, Windows may attempt to execute files at different points in the path. For example, if installed in C:\Program Files (x86)\App Name\nssm.exe, an attacker with write access to C:\ could place a malicious file at C:\Program.exe to gain elevated access.

Weak Registry Permissions: If the registry keys governing the NSSM service (e.g., ImagePath) are writable by unprivileged users, they can modify the service configuration to execute arbitrary payloads. Known Affected Products (Examples)

Wowza Streaming Engine 4.5.0: Vulnerable via replacing the nssm_x64.exe binary due to improper permissions.

Apache CouchDB 2.0.0: Vulnerable because files inherited parent directory permissions, allowing the substitution of nssm.exe.

Phoenix Contact Device & Update Management: Misconfigured permissions on nssm.exe allowed local privilege escalation. Mitigation and Defense

Windows Privilege Escalation — Part 1 (Unquoted Service Path)

Title: From Service Manager to SYSTEM: Abusing NSSM 2.24 for Privilege Escalation

Date: [Insert Date] Tags: #Windows #PrivilegeEscalation #NSSM #InfoSec nssm-2.24 privilege escalation

Summary

Affected versions

Root cause

Typical exploitation scenarios

PoC outline (high-level, non-code)

Mitigations and remediation

References and further research

If you want, I can:

When a standard user is tricked or coerced into running NSSM 2.24 (perhaps via a phishing attack or a malicious script on a shared terminal server), the tool does not properly validate the executable path and arguments before the service starts.

More specifically, the flaw exists in how NSSM 2.24 manages the Application and AppDirectory parameters. A low-privilege user can modify the configuration of an existing NSSM-managed service or, in some versions, inject a malicious payload during the initial (aborted) installation sequence.

Imagine a corporate environment using a legacy monitoring agent installed via NSSM 2.24 on hundreds of Windows Server 2012 R2 machines. A contractor with limited access discovers the NSSM service LegacyMonitor has its binary stored in C:\ProgramData\Monitor\. The ProgramData folder, by default, grants BUILTIN\Users write access.

The contractor replaces monitor.exe with a reverse shell payload compiled as a Windows service executable. Upon the next scheduled restart (or triggered manually), the shell pops back as NT AUTHORITY\SYSTEM, giving the attacker full control over the domain controller if the service runs there.

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. Published: For educational and defensive security purposes

Disclaimer: This post is for educational and defensive purposes only. Unauthorized access to systems is illegal.

Understanding NSSM-2.24 Privilege Escalation: Risk and Remediation

In the world of Windows system administration, the Non-Sucking Service Manager (NSSM) is a beloved tool. It allows users to wrap any executable into a Windows service, ensuring applications restart automatically after crashes or reboots. However, security researchers have identified specific configurations and vulnerabilities within certain versions—most notably discussed around version 2.24—that can lead to Privilege Escalation (LPE).

If you are running NSSM, understanding how an attacker can move from a low-privilege user to SYSTEM is critical for securing your infrastructure. What is NSSM?

NSSM is an open-source service helper. Unlike the native Windows sc.exe, NSSM provides a user-friendly interface and robust monitoring features. It is frequently used in development environments and by DevOps teams to manage web servers, database proxies, and custom scripts as background services. The Core of the Vulnerability: Insecure File Permissions

While NSSM itself is not inherently "malicious," the way it is often deployed creates a classic Insecure Service Executable vulnerability.

In many installations of NSSM 2.24, the privilege escalation path typically follows this logic:

Service Configuration: A service is created using NSSM to run under the LocalSystem account.

Weak Permissions: The directory where the nssm.exe binary or the target application executable resides has "Modify" or "Full Control" permissions granted to "Authenticated Users" or "Everyone."

The Hijack: A low-privilege user replaces the legitimate nssm.exe (or the application it points to) with a malicious payload (e.g., a reverse shell).

Execution: When the service restarts (either via a system reboot or manual trigger), the malicious binary runs with SYSTEM privileges. The "AppDirectory" and Registry Weakness

NSSM stores its configuration in the Windows Registry under HKLM\System\CurrentControlSet\Services\\Parameters.

If a low-privilege user has write access to these registry keys, they can change the Application or AppParameters values. By pointing the service to cmd.exe, an attacker can execute commands as SYSTEM the next time the service initializes. How the Escalation is Exploited (Proof of Concept)

Note: This information is for educational and defensive purposes only.

An attacker generally follows these steps to exploit a misconfigured NSSM instance:

Enumeration: Identify services managed by NSSM using commands like tasklist or Get-Service. Title: From Service Manager to SYSTEM: Abusing NSSM 2

Permission Check: Use icacls to check if the service directory is writable. powershell icacls "C:\Path\To\NSSM\Directory" Use code with caution.

Replacement: If permissions are weak, the attacker renames the original nssm.exe and uploads a malicious executable with the same name.

Trigger: The attacker waits for a reboot or uses wmic service to attempt a restart if they have the rights to do so. How to Mitigate NSSM-2.24 Risks

To prevent your NSSM installation from becoming a gateway for attackers, follow these security best practices: 1. Audit File System Permissions

This is the most important step. Ensure that the directory containing nssm.exe and the application it manages follows the Principle of Least Privilege. Only Administrators and SYSTEM should have write/modify access. 2. Secure the Registry

Check the permissions on the registry keys where NSSM stores its parameters. Ensure that standard users cannot modify keys under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\. 3. Use Service Accounts

Avoid running services as LocalSystem unless absolutely necessary. Instead, create a Managed Service Account (MSA) or a dedicated low-privilege user account with only the specific permissions required to run that application. 4. Upgrade and Monitor

While the 2.24-release era is the most discussed regarding these configurations, always ensure you are using the most stable, updated version of your tools. Furthermore, use Endpoint Detection and Response (EDR) tools to monitor for suspicious service modifications or unexpected child processes spawning from nssm.exe. Conclusion

The "NSSM-2.24 privilege escalation" isn't usually a flaw in the code itself, but a failure in the deployment environment. By hardening file permissions and registry access, you can continue to use NSSM’s powerful service management features without leaving your Windows environment vulnerable to local exploits.

Are you looking to automate a permissions audit for your Windows services?

Non-Sucking Service Manager (NSSM) version 2.24 does not have a unique, built-in "exploit" or CVE inherent to its code. Instead, privilege escalation involving NSSM almost always stems from insecure deployment configurations

. Because NSSM is an executable used to wrap other applications as services, it is a high-value target for attackers who have already gained a foothold on a system. Primary Escalation Vectors

When NSSM 2.24 is present, it is usually targeted via three common Windows service misconfigurations: Head Mare and Twelve: Joint attacks on Russian entities

NSSM version 2.24 does not have inherent privilege escalation vulnerabilities in its code, but it is frequently used in local privilege escalation scenarios due to misconfigurations like insecure file permissions, unquoted service paths, or placement in writable folders. While often flagged by security tools, mitigation involves upgrading to the 2.25 pre-release, auditing permissions, and securing service paths. For specific bugs and fixes, refer to the NSSM Bug Tracker. Bugs - NSSM - the Non-Sucking Service Manager

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.