Field Notes: NSSM - the Non-Sucking Service Manager
Table of Contents
Introduction
While analyzing Autoruns entries during a Compromise Assessment or an Incident Response case, would you take a second look at the nssm.exe binary running as a service? Hopefully. In a recent case, attackers used nssm.exe to start ngrok as a service to maintain a persistent backdoor. Here is a practical breakdown of how this mechanism works and how you can hunt for it in your environment.

Why Attackers Love NSSM
NSSM (the Non-Sucking Service Manager) is a legitimate tool designed to run standard executables as Windows services. The installer simply takes an application path and arguments, allowing the service name to be freely configured. For an attacker, installing a backdoor via NSSM brings two advantages:
- Resilience: NSSM monitors the running application and automatically restarts it if it crashes or when the system reboots.
- Stealthier Persistence: It provides convenient persistence without relying on more heavily monitored locations, such as standard Registry Run keys or Startup folders.
In this specific scenario, the tool being kept alive was ngrok, a utility often used by ransomware groups and threat actors to tunnel protocols out of a network and make internal services (like RDP or VNC) accessible directly from the internet. The installation via the NSSM GUI is straightforward.

Hunting
How to analyze NSSM installations in your environment.
Event Log Triage (Event ID 7045)
Look for Event ID 7045 (A service was installed in the system). The catch here is that the log won’t explicitly name ngrok.exe (as in our scenario). The installed application in your case might differ. Instead, the ImagePath field will point directly to the nssm.exe binary. A legitimate administrative tool like NSSM suddenly appearing in an unexpected directory might be a red flag.

Digging Into the Registry
If you spot a suspicious service or find NSSM listed in Autoruns output, the top-level Registry keys might still hide the true payload. The standard ImagePath value under the service key points to NSSM.

To find the real executable, navigate to the Parameters subkey. This is where NSSM stores the actual application path and arguments it is responsible for launching. If it’s handling a tunnel like in our use case, you’ll find the path to ngrok.exe right here.

Live Process Analysis (PsList / Process Explorer)
If the machine is live and you suspect an active tunnel, inspect process command lines with Process Explorer or Velociraptor’s Windows.System.Pslist artifact. For ngrok, a major giveaway is the config= parameter pointing to an external configuration file.

Another Example
In this scenario, we observe a service named komari-agent. Checking the root service key reveals the standard ImagePath pointing to C:\WINDOWS\nssm.exe and running as LocalSystem. However, investigating the Parameters subkey exposes the true execution details:
- Service Name: komari-agent
- Application: C:\Program Files\Komari\komari-agent.exe
- AppDirectory: C:\Program Files\Komari
- AppParameters: -e http://45[..]:60773 -t b8yT[..]

Conclusion
NSSM is not malicious by itself, but it can conceal the real executable behind an otherwise legitimate Windows service wrapper. When a service points to nssm.exe, do not stop at ImagePath, inspect the service’s Parameters subkey and the live process command line to identify the application, working directory, and arguments NSSM is actually launching. Unexpected install locations, user-writable paths, tunnel tooling, and suspicious or unknown service names should elevate the priority of the investigation.
Field Notes: Short blog posts about interesting techniques we encounter in the wild.