Windows Services constitute a near-ubiquitous control surface within the operating system's process architecture. A service is a privileged process capable of executing independently of any interactive user session and irrespective of logon state. Because of their elevated privileges, persistence potential across reboots, and ability to run in the context of SYSTEM or other high-integrity accounts, services represent a high-value target for adversaries seeking durable execution, defense evasion, or lateral movement. Consequently, service-related artifacts frequently yield high-fidelity indicators of compromise during incident response and forensic examination.
Service-related telemetry resides exclusively within the System event log under the Service Control Manager (SCM) provider. The SCM is responsible for transmitting control codes to services and drivers, maintaining their runtime status, and committing the corresponding telemetry to the System log. Within this corpus, the following Event IDs are of primary investigative utility:
- Event ID 7034 — Unexpected service termination (crash). The event records that a service process exited abnormally and enumerates the cumulative failure count. While legitimate causes (resource exhaustion, driver instability, orderly shutdown races) exist, anomalous or repeated 7034 events—particularly when correlated with injection-based tradecraft (process-injection techniques or DLL side-loading)—warrant prioritized scrutiny.
- Event ID 7035 — Successful transmission of a start or stop control by the SCM. On legacy platforms (Windows XP / Server 2003), this event frequently populated the User field with the initiating principal; on modern Windows, the user context is inconsistently present, and informational events may be suppressed by policy or log configuration.
- Event ID 7036 — Confirmed state transition (service entered the running or stopped state). This event is the authoritative indicator that the control issued in 7035 was acted upon. Correlative analysis of 7035/7036 pairs establishes both intent and outcome.
- Event ID 7040 — Modification of a service’s start type. The event documents the transition among the canonical start types: Boot, System, Automatic (including Automatic Delayed Start), Manual (Demand / “On Request”), and Disabled. Changes that elevate a service to Boot or System start, or that disable security-relevant services, constitute classic persistence and defense-evasion techniques. Coverage is reliable for native Windows services and most third-party services that register with the SCM; certain specialized or non-SCM-managed components may not generate 7040 telemetry.
- Event ID 7045 — Beginning with Windows Vista / Server 2008 (commonly observed from Windows 7 / Server 2008 R2 onward in enterprise baselines), Event ID 7045 was introduced in the System log to record the installation of a new service. Because service installation is comparatively rare relative to routine start/stop activity, 7045 exhibits a high signal-to-noise ratio and is an excellent starting point when hunting for suspicious services. Tools that create ephemeral services and subsequently delete them (e.g., PsExec and functional equivalents) still generate a distinct 7045 on each installation cycle, providing an opportunistic detection opportunity for transient malicious services.
- Event ID 4697 — This appears in the Security log and is generated only when the “Audit Security System Extension” advanced audit policy subcategory is enabled for Success. It is the Security log counterpart to System Event 7045 and therefore facilitates correlation with other Security log events. However, the Subject field frequently resolves to SYSTEM (or the machine account) rather than the interactive or remote principal that actually initiated the installation; correlation with the corresponding 7045 and surrounding logon events is, therefore, required to recover actor context. Service Start Type is recorded numerically in registry-compatible form (0 = Boot, 1 = System, 2 = Automatic, 3 = Manual/Demand, 4 = Disabled).
On Windows XP / Server 2003 the classic runtime and control events (7034, 7035, 7036, 7040) were already present; the nearest equivalent for service installation was Event ID 601. Modern investigations should therefore prioritize the 7045/4697 pair on Vista and later platforms while retaining the classic quartet for legacy systems and for ongoing lifecycle analysis. Collectively, these events—examined in temporal correlation with binary path, service account, parent process, and surrounding logon or process-creation artifacts—form a core analytical set for detecting and attributing malicious service activity.
Suspicious Services: PsExec
The Sysinternals PsExec utility furnishes a canonical illustration of how newly installed services can surface otherwise stealthy remote execution. Each invocation of the authentic Microsoft binary registers a transient service (default name PSEXESVC) with the Service Control Manager, thereby generating System Event ID 7045 by default and, when the “Audit Security System Extension” subcategory is enabled, Security Event ID 4697. Because legitimate services are engineered for non-interactive, background operation, they are almost invariably configured to run under built-in accounts such as NT AUTHORITY\SYSTEM or NT AUTHORITY\LOCAL SERVICE. Consequently, the appearance of a domain-user or interactive-user SID (e.g., S-1-5-21-572887454-1858499753-1978773125-1003) in the service account field is anomalous and merits immediate investigation; such misconfigurations frequently expose high-value credentials or signal adversary activity.
In the figure above, two discrete PsExec sessions occurred within an approximate five-hour window. The service name PSEXESVC itself is a strong indicator of remote code execution. Actor attribution is recovered by resolving the associated SID against contemporaneous Security log events or by locating the corresponding Event ID 4624 network logon.
Adversary frameworks replicate the same service-based execution pattern while deliberately diverging in implementation details. Metasploit’s PsExec-style modules, for example, still create a new Windows service, yet commonly embed an encoded and obfuscated PowerShell payload and assign a randomized service name—both of which appear highly anomalous under forensic review. Impacket’s psexec.py likewise generates a short, typically four-character random service name. These implementation differences do not eliminate the underlying telemetry: every such tool still produces Event IDs 7045 and (when audited) 4697.
The broader investigative implication is that systematic examination of new-service installation events yields high-fidelity detection coverage across multiple stages of the attack lifecycle. Persistent backdoors (Cobalt Strike Beacon, Meterpreter), credential-dumping utilities (fgdump and successors), and lateral-movement tooling all frequently rely on the service abstraction to achieve execution. Consequently, Event IDs 7045 and 4697—augmented by service-name heuristics, binary-path analysis, and account-context review—constitute a high-value analytic pivot for identifying both commodity remote-execution tools and more exotic malware.
Per-User Services
Services remain a heavily abused Windows execution primitive; consequently, the “new service installed” events—Security Event ID 4697 and System Event ID 7045—constitute high-value analytic pivots for detecting malicious activity. Prior to Windows 10, these events maintained a favorable signal-to-noise ratio because genuine service installations on a typical endpoint were comparatively rare.
That calculus changed with the introduction of per-user services in Windows 10 (and Windows Server 2016 with Desktop Experience). As a resource-management optimization, the operating system now instantiates a distinct service instance for each interactive user logon. These instances are named by appending a Locally Unique Identifier (LUID) to the base service name (e.g., OneSyncSvc_32d44dec, UserDataSvc_<LUID>). The same LUID is frequently reused across the set of per-user services created for that session. Because the Security log treats each newly created instance as a never-before-seen service, a single user logon can generate a burst of Event ID 4697 records. This design decision materially degrades the signal-to-noise ratio of 4697 and expands the volume of benign events an analyst must triage.
Naïve filtering that simply discards any service name containing an underscore (“_”) is operationally fragile but an adversary can trivially name a malicious service OneSyncSvc_<plausible-LUID> and blend into the noise. A more resilient approach is to filter on the ServiceFileName (Image Path) field, maintaining an allow-list of known-good command lines such as C:\Windows\system32\svchost.exe -k UnistackSvcGroup and similar legitimate host-process invocations. With disciplined path-based filtering, Event ID 4697 retains investigative utility. An often superior alternative is to prioritize System Event ID 7045. At present, 7045 does not appear to record the bulk of these ephemeral per-user service instances, thereby preserving a cleaner signal. In addition, the System log frequently retains a longer temporal window of activity than the Security log, further enhancing its forensic value for service-installation hunting.
In short, while per-user services have diluted the purity of Security Event ID 4697, disciplined filtering on ServiceFileName combined with preferential analysis of System Event ID 7045 continues to make new-service telemetry a high-fidelity detection mechanism across the attack lifecycle.
Post a Comment