Skip to content
Reverse Engineering
Persistencebeginner

Windows Service Persistence

Malware installs or hijacks a Windows service so the Service Control Manager starts its payload automatically at boot, typically running as SYSTEM.

Windows services are background programs managed by the Service Control Manager (SCM). A service configured with Start = 2 (Automatic) launches at boot, before any user logs on, and usually runs in the SYSTEM context. This combination — early, privileged, automatic execution — makes services a favourite persistence and privilege-retention mechanism, especially for malware that already holds administrative rights.

Attackers either register a brand-new service whose binary is the payload, or hijack an existing service by rewriting its ImagePath to point at malicious code. Payloads may be a standalone EXE, a svchost-hosted service DLL (ServiceDll), or a driver (Type = 1), the last giving kernel-level persistence as seen in rootkits.

How it works

Services are defined under a single registry path; SCM reads it at boot:

text
HKLM\SYSTEM\CurrentControlSet\Services\<ServiceName>
  ImagePath = C:\Windows\System32\evilsvc.exe
  Start     = 2          ; 2 = Automatic, 0/1 = boot/system (drivers)
  Type      = 0x10       ; own-process EXE; 0x20 = shared svchost; 1 = kernel driver
  ObjectName = LocalSystem

A common command-line registration:

text
sc create WindowsHealthSvc binPath= "C:\ProgramData\evilsvc.exe" start= auto
sc start WindowsHealthSvc

For DLL services, attackers add a Parameters\ServiceDll value so the code is loaded inside a shared svchost.exe, blending in with legitimate Windows services. Service names and descriptions are forged to imitate real Microsoft services (WindowsHealthSvc, WinDefendSvc).

Detection & analysis

Static analysis:

  • Enumerate services with Autoruns ("Services" tab) or sc query and flag unsigned ImagePath/ServiceDll binaries, paths outside System32, or services in user-writable directories.
  • Offline, parse HKLM\SYSTEM\CurrentControlSet\Services with RegRipper; review every key's ImagePath, Start, Type, and ObjectName. Last-write timestamps date the install.
  • In a sample, look for imports OpenSCManager, CreateService, ChangeServiceConfig, or a ServiceMain export (DLL services) and the literal CurrentControlSet\\Services.

Dynamic analysis:

  • Run the sample and capture sc.exe/CreateService activity. Security log Event ID 4697 (a service was installed) and System log Event ID 7045 (new service installed by SCM) are the primary indicators; Event ID 7045 fires for nearly every newly created service.
  • Sysmon Event ID 1 captures sc.exe create command lines; Event IDs 12/13 record the Services\<name> registry writes. Watch for SCM (services.exe) spawning the new service binary.

Detection rule hint:

Alert on System Event ID 7045 / Security 4697 where the service binary is unsigned, lives outside System32/Program Files, or is created by a non-installer process. Treat any new ServiceDll loaded into svchost.exe from a user-writable path, or any new kernel driver service, as high severity.

Votes

Comments(0)