Nssm224 Privilege Escalation Updated

sc sdset MyService D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)

This grants full control only to SYSTEM and Administrators.

The following is an updated attack simulation for authorized penetration testers and blue teams.

Researchers discovered that in NSSM 2.24, the Parameters subkey (which holds Application, AppDirectory, AppParameters) is not always protected. If the installer used the default NSSM service creation without adjusting registry permissions: nssm224 privilege escalation updated

Mitigation (for admins): Manually restrict ACLs on the service Parameters registry key. NSSM 2.24 does not do this automatically.

When NSSM 2.24 installs a service pointing to a path containing spaces (e.g., C:\Program Files\MyApp\run.bat) without quotes, Windows parses the path ambiguously. This grants full control only to SYSTEM and Administrators

Example of vulnerable installation:

nssm install MyService C:\Program Files\MyApp\run.bat

If the service runs as SYSTEM, an attacker with write access to C:\ or C:\Program Files\ can place a malicious Program.exe or Files.exe. When the service starts, the attacker’s binary executes with SYSTEM rights. Mitigation (for admins): Manually restrict ACLs on the

sc.exe sdshow nssm_managed_service

Look for (A;;RPWP;;;WD) or (A;;RPWPDT;;;AU) – these allow authenticated users to modify service configuration.

Set ServiceSidType = Unrestricted in the service registry to limit token privileges.

The infamous nssm224 privilege escalation issue is not a bug in NSSM’s code per se. Instead, it stems from misconfigurations combined with NSSM’s default behavior.