Privilege Escalation Upd: Nssm-2.24

NSSM (Non-Sucking Service Manager) version 2.24 is a widely used tool for managing Windows services, but it presents specific security risks, primarily revolving around Local Privilege Escalation (LPE). While NSSM itself is not inherently "malicious," its misconfiguration or presence in a compromised environment can be leveraged by attackers to gain NT AUTHORITY\SYSTEM privileges. Deep Review of NSSM 2.24 Vulnerabilities 1. Unquoted Service Path (Most Common)

The most significant risk with NSSM 2.24 is the Unquoted Service Path vulnerability. This occurs when the path to the nssm.exe binary or the application it manages contains spaces and is not enclosed in quotation marks.

Mechanism: If a service path is C:\Program Files\Service\nssm.exe, Windows will attempt to execute files in this order: C:\Program.exe C:\Program Files\Service.exe C:\Program Files\Service\nssm.exe

Exploitation: An attacker with low-level write access to the root directory (e.g., C:\) can place a malicious executable named Program.exe. When the service restarts, it will run the attacker's code with the privileges of the service account, typically SYSTEM. 2. Service Binary Hijacking nssm-2.24 privilege escalation

If the permissions on the folder where nssm.exe or its managed application resides are weak (e.g., BUILTIN\Users has Modify or Write permissions), an attacker can replace the legitimate binary with a malicious one. Since NSSM is designed to restart services if they crash, an attacker can simply kill the process and wait for NSSM to restart their malicious version. 3. Known Bugs in v2.24

Version 2.24 has several documented stability and security-related bugs that were addressed in the 2.25 pre-release builds:

Elevation Loop: NSSM 2.24 may enter a crash and restart loop if run without administrator rights when privilege elevation is required, potentially leading to a Denial of Service (DoS). NSSM (Non-Sucking Service Manager) version 2

Resource Leaks: It leaks thread handles when applications restart, which can lead to system instability over time.

Windows 10 Compatibility: It may fail to launch services on newer Windows versions (Windows 10 Creators Update/Server 2016+) unless specific registry keys like AppNoConsole=1 are set. Summary Table: NSSM 2.24 Security Profile Status/Risk Recommendation Primary Vulnerability Unquoted Service Path Always wrap paths in double quotes in the registry. Account Privileges Runs as SYSTEM by default Use a low-privilege Service Account whenever possible. Stability Known crashes on XP and Nano Server Upgrade to the latest pre-release or stable build. Permissions Weak folder ACLs lead to LPE Restrict write access to Administrators and SYSTEM only. Mitigation & Recommendations To secure an environment using NSSM 2.24, you should:

Upgrade: Move to NSSM 2.25 pre-release or a newer version to fix known handle leaks and Windows 10 bugs. Upgrade to NSSM 2

Audit Paths: Use tools like the PrivescCheck script to identify any unquoted service paths.

Strict ACLs: Ensure the directory containing nssm.exe is only writable by high-privilege accounts.

Least Privilege: Configure the service to "Log on" as a specific user with the minimum required permissions rather than the default SYSTEM account. Download - NSSM - the Non-Sucking Service Manager

Real-World Impact: Why This Matters

1. Persistent Backdoors

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.

Mitigation / Fix

Upgrade to NSSM 2.24.1+ (if a patched version exists — check official site).
Manually fix: Set the service DACL to allow only SYSTEM and Administrators to modify the service or its registry keys.
```
sc sdset MyNSSMService "D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)"
```
Alternative: Use a more secure service wrapper (e.g., WinSW with config protection, or Windows built-in sc + proper ACLs).
Monitor for changes to binPath or Parameters\Application keys.

3. Proof of Concept (Conceptual)

Discovery: An attacker enumerates services installed via NSSM using standard Windows commands (e.g., sc qc ServiceName or wmic service).
Vulnerability Identification: The attacker identifies that the service binary path contains spaces and is not enclosed in quotes (Unquoted Service Path), or that the NSSM parameters allow for command injection.
- Example Vulnerable Path: C:\Program Files\My Service\service.exe
- Execution Logic: Windows attempts to execute C:\Program.exe, then C:\Program Files\My.exe, etc.
Exploitation: The attacker places a malicious binary (e.g., a payload generated by Metasploit or a simple user-addition script) in the vulnerable path (e.g., C:\Program Files\My.exe).
Trigger: The attacker restarts the service or waits for a system reboot. The malicious binary is executed as SYSTEM.