Skip to content
Reverse Engineering
Persistenceadvanced

Netsh Helper DLL

Malware registers a helper DLL with netsh so the library loads into the netsh.exe process whenever the tool runs, yielding stealthy registry-backed persistence.

netsh.exe is the built-in Windows network configuration shell. Its functionality is extensible through helper DLLs: libraries that register a context (such as firewall or wlan) and are loaded into the netsh process whenever it starts. An attacker who registers their own helper DLL gains persistence that fires every time netsh runs — at logon scripts, by other tools, by administrators, or on a scheduled trigger — while executing inside a signed, trusted Microsoft binary.

The mechanism is attractive precisely because it is obscure and registry-backed: a single value under the NetSh key names the DLL, and netsh resolves and loads it through the normal DLL search path. The malicious code typically lives in the DLL's InitHelperDll export, so it runs as soon as the library is mapped, giving proxy-execution and persistence in one step.

How it works

Registered helpers are listed under a single registry key, and the DLL is loaded by netsh from the system path:

text
HKLM\SOFTWARE\Microsoft\NetSh
  <name> = "evilhelper.dll"          one value per registered helper

DLL search:  %SystemRoot%\System32\evilhelper.dll  (or PATH)
Export:      InitHelperDll            entry point netsh calls on load

Registration is done with netsh add helper C:\path\evilhelper.dll, which writes the value above; thereafter any netsh invocation maps the DLL and calls InitHelperDll. Operators commonly drop the DLL into System32 (requiring admin) or alongside a writable PATH directory, give it a network-themed name, and pair it with something that runs netsh routinely so the payload re-executes. The DLL often does little beyond launching the real implant in a new process.

Detection & analysis

Static analysis:

  • Inspect the registry key HKLM\SOFTWARE\Microsoft\NetSh: each value names a registered helper. Microsoft's own helpers (fwcfg.dll, wcmdll.dll, nettrace.dll, etc.) live in System32 and are signed; any value pointing at an unsigned DLL, a non-System32 path, or a recently dropped file is the core indicator. The key's last-write time dates the change.
  • In a captured DLL, the presence of an exported InitHelperDll plus networking or process-creation imports marks it as a netsh helper payload. Confirm the on-disk DLL named by the registry value is unsigned or signature-mismatched.
  • Triage with Autoruns, which enumerates netsh helpers and flags unverified entries among the known-good Microsoft set.

Dynamic analysis:

  • Run the sample under Procmon filtered on Path contains \NetSh to capture the RegSetValue that registers the helper, and watch for a child netsh.exe add helper. Sysmon Event ID 13 records the registry write with the writing process.
  • Observe netsh.exe at runtime: Sysmon Event ID 7 (Image Load) shows the unexpected helper DLL mapping into netsh.exe, and Event ID 1 captures any implant netsh then spawns — netsh.exe launching a child process is itself anomalous.

Detection rule hint:

Alert on any new value under HKLM\SOFTWARE\Microsoft\NetSh (Sysmon 13) that is not part of a known-good baseline, and on netsh.exe add helper command lines (Sysmon 1). Flag netsh.exe loading a DLL outside System32 or one that is unsigned (Sysmon 7), and treat netsh.exe spawning a child process as high-fidelity.

Votes

Comments(0)