Nssm-2.24 Exploit

The "NSSM-2.24 exploit" typically refers to Local Privilege Escalation (LPE) vulnerabilities involving the Non-Sucking Service Manager (NSSM) version 2.24, a popular tool used to run applications as Windows services. While NSSM 2.24 is not inherently malicious, its widespread use and common misconfigurations have made it a staple in security research and real-world attacks. The Core Vulnerability: Unquoted Service Paths

The most frequent exploit involving NSSM 2.24 is the Unquoted Service Path vulnerability (CWE-428).

The Flaw: When a service is registered with a file path containing spaces (e.g., C:\Program Files\My Service\nssm.exe) but lacks surrounding quotation marks, Windows interprets the path ambiguously.

The Mechanism: Windows attempts to execute the path in parts. For the example above, it first looks for C:\Program.exe, then C:\Program Files\My.exe, and finally the intended nssm.exe.

The Exploit: An attacker with low-level write access to the root directory (like C:\) can place a malicious file named Program.exe. When the system reboots or the service restarts, Windows executes the attacker's code with SYSTEM privileges—the highest level of access on the machine. Vulnerabilities in Bundled Software

Because developers often bundle NSSM 2.24 with their own software to manage background tasks, vulnerabilities in the parent application can expose NSSM to exploitation:

Odoo (CVE-2021-32680): Versions of Odoo (e.g., 12.0) bundled nssm.exe with an unquoted service path, allowing local users to escalate privileges. nssm-2.24 exploit

Apache CouchDB (CVE-2016-8742): CouchDB 2.0.0 had weak file permissions that allowed non-privileged users to replace the nssm.exe binary itself with a malicious one, which would then run as an administrator upon service restart.

Pelco VideoXpert: Suffered from both improper binary permissions and unquoted search paths for its core services using NSSM, allowing attackers to swap binaries for rootkits. Pelco VideoXpert 1.12.105 - Local Privilege Escalation

Understanding and Addressing the NSSM-2.24 Exploit

Example of a Detection Rule

Here is a basic example of an IDS/IPS rule to detect potential NSSM exploit attempts:

rule detect_nssm_exploit 
    meta:
        description = "Detect potential NSSM-2.24 exploit attempts"
        author = "Your Name"
        date = "2023-04-01"
    rule $process_creation
$nssm_path = "c:\\path\\to\\nssm.exe"
        $suspicious_arg = "suspicious_argument_here"
process where $process_creation and 
                   (process.name == "nssm.exe" and 
                    process.args == $suspicious_arg and 
                    file.path == $nssm_path)

Details of the Exploit

The specific details of the NSSM-2.24 exploit involve how NSSM handles certain operations or inputs, potentially leading to:

• Privilege Escalation: An attacker could exploit the vulnerability to gain elevated privileges, allowing them to perform actions that would typically be restricted.
• Arbitrary Code Execution: In some cases, the exploit might enable an attacker to execute arbitrary code on the system, leading to a complete compromise.

If you saw “nssm-2.24 exploit” in a report or forum

It was likely referring to:

• Metasploit module exploit/windows/local/nssm_perm (if it exists — I don’t recall an official one for NSSM; there is one for weak service permissions in general).
• A blog post demonstrating how to abuse NSSM’s service installation to persist as SYSTEM after already having admin rights — used in red teaming, not exploitation of a bug.

Claim 1: Privilege Escalation via Weak Service Permissions

Reality: NSSM 2.24, when used to install a service, creates a service with default permissions. By default, the SC_MANAGER_ALL_ACCESS is not granted to low-privileged users. However, if an administrator installs a service using NSSM without locking down the service’s DACL (Discretionary Access Control List), a local attacker with authenticated access could modify the service binary path.

Example:
A sysadmin runs:

nssm install MyService C:\tools\legacy_app.exe

If the admin does not explicitly set nssm set MyService ObjectName NT AUTHORITY\LocalService, the service runs as LocalSystem (high privilege). An attacker with SERVICE_CHANGE_CONFIG access (sometimes granted to Users group on misconfigured systems) can change the binary path to cmd.exe /c net user hacker P@ssw0rd /add.

This is not a vulnerability in NSSM’s code—it is a configuration weakness inherited from Windows service security models. Any service installer (sc, PowerShell) faces the same risk.

5. Monitor Service Installations

Event ID 7045 (A service was installed) in the System log records the service name, binary path, and start type. Correlate this with unusual parent processes (e.g., powershell.exe spawning nssm.exe).

The So-Called "NSSM-2.24 Exploit": Breaking Down the Claims

Searching for "nssm-2.24 exploit" yields a mix of misleading blog posts, exploit-db archives, and Reddit threads. Let’s separate fact from fiction. The "NSSM-2

Why Version 2.24 Specifically?

Penetration testers often bundle NSSM 2.24 for two reasons:

• Stability – It is the last version before 2.25-beta, which sometimes crashes on Windows Server 2012 R2.
• Signature evasion – Many antivirus engines have hashes of NSSM 2.24 flagged as "hacktool" only after 2020. Outdated EDRs may ignore it.

Attackers rarely use a memory corruption exploit; they use NSSM as a living-off-the-land (LotL) binary.

Why would someone search for “nssm-2.24 exploit”?

Common reasons include:

1. Misconfiguration abuse – If an attacker can write to the directory where NSSM stores service configs (HKLM\SYSTEM\CurrentControlSet\Services\...), they can change the binary path to a malicious executable and restart the service.

   • This requires Administrator privileges already, so it’s not an exploit — it’s just abuse of existing permissions.

2. DLL hijacking – Old versions of NSSM might load DLLs from unsecured paths (e.g., current working directory). If an attacker can plant a malicious DLL there, and a privileged process runs NSSM, they could achieve code execution. This is a potential local privilege escalation vector if a service starts NSSM from a user-writable directory.

3. Unquoted service path vulnerability – NSSM installs services. If an admin uses NSSM to install a service with an unquoted path containing spaces and doesn’t set proper ACLs, standard Windows unquoted service path issues apply — but that’s not NSSM’s flaw. Details of the Exploit The specific details of the NSSM-2