Windows Service Persistence
Creating a new Windows service as a persistence mechanism gives you code execution that starts automatically with the system, runs as SYSTEM by default, and restarts on failure if configured to do so. Unlike scheduled tasks, services run before any user logs in and are harder to associate with a specific user account.
Creating a new service
Requires local Administrator or SYSTEM. The binary pointed to by the service runs as SYSTEM unless a different account is specified.
SERVICE_NAME: WindowsHelper
TYPE : 10 WIN32_OWN_PROCESS
START_TYPE : 2 AUTO_START
ERROR_CONTROL : 1 NORMAL
BINARY_PATH_NAME : C:\Windows\Temp\payload.exe
LOAD_ORDER_GROUP :
TAG : 0
DISPLAY_NAME : Windows Helper Service
DEPENDENCIES :
SERVICE_START_NAME : LocalSystem
The failure recovery configuration makes the service restart automatically if the payload crashes or is killed. The format is actions= restart/delayms — three restart actions with a 5-second delay each. This makes the persistence significantly more resilient.
Service DLL persistence
Instead of pointing a service at an EXE, you can register a DLL as the service binary via ServiceDll. The DLL is loaded by svchost.exe, which means your malicious code runs inside a legitimate Windows process.
Service DLL payloads must export a ServiceMain function and implement basic service control handler logic. A raw DLL without these exports will fail to load. Use a purpose-built service DLL payload from your framework rather than a generic DLL.
Remote service creation
Cleaning up
References
-
sc create — Microsoft Docslearn.microsoft.com/en-us/windows-server/administration/windows-commands/sc-create (opens in new tab)
Full parameter reference for sc.exe service creation
-
Impacket services — GitHubgithub.com/fortra/impacket (opens in new tab)
Remote service management via impacket-services
Was this helpful?
Your feedback helps improve this page.