Windows Services

A Windows service is not just “a program that starts with the machine” — it’s a process managed by the Service Control Manager (SCM) and required to speak the SCM’s control protocol: service binaries implement ServiceMain and a control handler so the SCM can start, stop, pause, and interrogate them. That protocol requirement is the single most important fact for offense and defense alike.

Why a normal EXE makes a bad service

You can point a service at an ordinary executable (binPath = C:\evil.exe), but a regular binary never answers the SCM’s handshake. Consequences:

  • The SCM marks the service failed shortly after start — a bright-red 7000/7009-series event in the System log, exactly the kind of failure defenders are told to notice.
  • The SCM may kill the process as unresponsive, so a reverse shell or beacon dies with it. Stable persistence needs a real service binary, a service wrapper (e.g. srvany-style shims), or a payload that correctly implements the service API.

One-shot command execution doesn’t care about any of this — the command fires before the SCM gives up. That’s why the WMI remote-service pattern (create → start → delete within seconds) works fine with cmd /c payloads but is the wrong shape for a persistent listener.

Where service configuration lives

Service definitions are registry data under HKLM\SYSTEM\CurrentControlSet\Services\<ServiceName>:

  • ImagePath — the binary/command line
  • ObjectName — the account the service runs as (LocalSystem, NetworkService, a domain account…)
  • Start — start type (2 = automatic)
  • Security subkey — the service’s own DACL, stored as a security descriptor. It governs who may change or start the service, which is a distinct question from filesystem permissions on the binary.

Two escalation primitives fall out of this layout:

  1. Weak service DACLs — a low-privileged user who can write the service config can repoint ImagePath and get their code run as the service account (often SYSTEM). Audit with sc.exe sdshow <service> / Get-Acl on the registry key, and see icacls for the file-side equivalent on the binary itself.
  2. Writable binary paths — a service running as SYSTEM whose ImagePath binary (or its parent directory) is writable by users is a straight-line privesc.

binPath to a driver: kernel execution

If ImagePath/binPath names a .sys file rather than a user-mode EXE, starting the service loads the driver into the kernel. Service creation is thus also the standard driver-load primitive — legitimate (that’s how drivers install) and offensive (BYOVD attacks register a vulnerable signed driver this way, then exploit it for ring-0). EID 4697/7045 plus driver-load telemetry (Sysmon EID 6) cover this path.

Detection quick reference

EventSignal
Security 4697 / System 7045Service installed — scrutinize random names, cmd /c or PowerShell in ImagePath, binaries in temp/user paths
System 7036/7035Service started/stopped — an install followed within seconds by start+stop+delete is the ephemeral-execution heartbeat
System 7000/7009Service failed to start/respond — often the fingerprint of a normal EXE misused as a service
Sysmon 6Driver loaded — catches the .sys binPath case

Sources