A Sigma rule for Windows service installation catches a persistence and privilege-escalation pattern that has not gone out of style: an attacker registering a new service so their code runs as SYSTEM at boot. Windows records every new service as Event ID 7045 in the System log, and unlike the scheduled-task event I covered earlier, this one is on by default. This post turns that event into a portable Sigma rule, so the detection converts to KQL or SPL instead of living in one SIEM's query language.

Key Takeaways

• Service-based persistence (MITRE ATT&CK T1543.003) is recorded as Event ID 7045 in the System log, which requires no extra audit policy to generate.
• A Sigma rule for Windows service installation keys on the ImagePath — a service binary that is really a script host, lives in a temp path, or loads an unsigned driver is the signal.
• Kernel-mode service installs (ServiceType of a driver) deserve their own attention because they are the entry point for bring-your-own-vulnerable-driver attacks.
• A companion process-creation rule on sc.exe create covers the command-line path and works even where System-log collection is incomplete.
• The rule converts cleanly to KQL; 7045 arrives through the Event table, while the audited equivalent 4697 arrives through SecurityEvent.

Environment

• sigma-cli 1.0+ with a backend installed (kusto for Microsoft Sentinel in my case).
• Windows endpoints forwarding the System event log — 7045 is written there by Service Control Manager with no audit policy required.
• Optionally, "Audit Security System Extension" enabled if you also want the Security-log equivalent, Event ID 4697.
• Process command-line logging via Sysmon or Security 4688 for the companion sc.exe rule.
• A SIEM workspace to validate the converted query before promoting it to an analytics rule.

The Problem

Installing a service is a privileged, legitimate operation that happens constantly — drivers, agents, and platform components all register services. It is also one of the cleanest ways for an attacker to get code running as SYSTEM that survives a reboot, which is exactly why it stays in the playbook. The detection challenge is the same as it was for scheduled tasks: the event volume is dominated by benign installs, and the malicious one looks structurally identical unless you read what the service actually points at.

The discriminator is the ImagePath. A real service binary is a signed executable in System32 or a vendor's Program Files directory. A malicious one is frequently cmd.exe /c, a PowerShell one-liner, a binary dropped in \AppData\ or \Temp\, or an unsigned kernel driver. Writing the detection in Sigma lets me describe those shapes once and convert them, rather than re-deriving the query each time I move between a client's Splunk and my own Sentinel workspace. The technique reference is MITRE ATT&CK T1543.003.

The Solution — Writing a Sigma Rule for Windows Service Installation

Step 1 — Match suspicious service binaries in Event ID 7045

Event ID 7045 carries the service name, the image path, the service type, and the start type. The rule keys on the image path, because that is the field an attacker cannot make look legitimate while still pointing at their payload:

title: Suspicious Service Installed via Event ID 7045
id: 4c8a2e91-6b3d-4f7a-9e0c-1a5d7f2b8c63
status: experimental
description: Detects a new Windows service whose image path is a script host, an encoded command, or a user-writable location
references:
  - https://attack.mitre.org/techniques/T1543/003/
author: SecurityScriptographer
date: 2026-05-30
tags:
  - attack.persistence
  - attack.privilege_escalation
  - attack.t1543.003
logsource:
  product: windows
  service: system
detection:
  selection:
    Provider_Name: 'Service Control Manager'
    EventID: 7045
  suspicious_path:
    ImagePath|contains:
      - 'powershell'
      - 'pwsh'
      - 'cmd.exe /c'
      - 'mshta'
      - 'rundll32'
      - 'regsvr32'
      - '-enc'
      - '-EncodedCommand'
      - '\AppData\'
      - '\Temp\'
      - '\Users\Public\'
      - '\ProgramData\'
  condition: selection and suspicious_path
falsepositives:
  - Some legitimate agents stage installers in ProgramData; confirm the signer before excluding
level: high

The selection block pins the provider and event ID; suspicious_path is an OR-list of indicators that almost never appear in a clean service binary. Keeping them in separate named blocks combined with and means the rule fires only on a genuine 7045 event that also carries a staging indicator.

Step 2 — Flag kernel-driver service installs separately

A service with a kernel-mode type is loading a driver. Legitimate driver installs happen, but they are rare enough on a typical workstation that a separate, lower-threshold rule is worthwhile — this is the foothold for bring-your-own-vulnerable-driver attacks:

title: Kernel-Mode Driver Service Installed
id: 9e1d4a7c-2f86-4b03-a5e9-0c6b8f3d2a14
status: experimental
description: Detects installation of a kernel-mode (driver) service, the entry point for BYOVD
references:
  - https://attack.mitre.org/techniques/T1543/003/
author: SecurityScriptographer
date: 2026-05-30
tags:
  - attack.persistence
  - attack.t1543.003
logsource:
  product: windows
  service: system
detection:
  selection:
    Provider_Name: 'Service Control Manager'
    EventID: 7045
    ServiceType: 'kernel mode driver'
  condition: selection
falsepositives:
  - Endpoint security agents and legitimate hardware drivers install kernel services
level: medium

This one is deliberately broad. The point is not to alert-and-forget but to feed a review queue — a driver install on an accounting laptop is worth thirty seconds of an analyst's time even when it turns out to be a printer.

Step 3 — Cover the command-line path with sc.exe

Where System-log collection is patchy, or where the attacker uses the built-in tool, a process-creation rule on sc.exe catches the same action from the other direction. It depends only on command-line logging from Sysmon or Security 4688:

title: Service Created via sc.exe with Staging Indicators
id: 1b7f3c80-5a2e-4d96-b1c4-8e0a2f6d9b57
status: experimental
description: Detects sc.exe creating a service that runs a script host or binary from a user-writable path
references:
  - https://attack.mitre.org/techniques/T1543/003/
author: SecurityScriptographer
date: 2026-05-30
tags:
  - attack.persistence
  - attack.t1543.003
logsource:
  category: process_creation
  product: windows
detection:
  selection_img:
    Image|endswith: '\sc.exe'
    CommandLine|contains: 'create'
  selection_payload:
    CommandLine|contains:
      - 'binPath'
      - 'powershell'
      - 'cmd.exe'
      - '\AppData\'
      - '\Temp\'
  condition: all of selection_*
falsepositives:
  - Administrative provisioning scripts that register services from staging paths
level: medium

all of selection_* requires both the sc.exe create invocation and a payload indicator, which keeps the rule off routine sc.exe query and sc.exe config calls. This mirrors the two-rule approach I used for scheduled-task detection: one rule on the registered object, one on the tool that created it.

Step 4 — Convert and route to the right table

Conversion is the same single command, but the target table depends on which event you collected. The System-log 7045 lands in the Event table; the audited Security-log 4697 lands in SecurityEvent:

sigma convert -t kusto -p sysmon service_install_7045.yml

The converted query is the one I would otherwise write by hand against Defender or Sentinel, in the spirit of my SIEM correlation rules walkthrough:

Event
| where Source == "Service Control Manager" and EventID == 7045
| extend ImagePath = tostring(parse_xml(EventData).DataItem.EventData.Data[1])
| where ImagePath has_any ("powershell", "cmd.exe /c", "-enc", "\\AppData\\", "\\Temp\\")
| project TimeGenerated, Computer, ImagePath

The field extraction differs by collection method — Azure Monitor Agent and the legacy Log Analytics agent shape the System log differently — so validate the parsing against your own data before trusting the result. The essential Windows Event IDs reference covers the related service-control events (7034 crash, 7040 start-type change) worth collecting alongside 7045.

Step 5 — Exclude your real noise by signer, not by weakening the rule

The predictable false positives are security agents and hardware drivers. Exclude them by their known service name or signer rather than by removing indicators:

  filter_known_good:
    ServiceName|startswith:
      - 'Sense'           # Defender for Endpoint
      - 'WinDefend'
  condition: selection and suspicious_path and not filter_known_good

Record each exclusion in the falsepositives field. An exclusion that is not documented looks identical to an attacker's evasion when the next analyst reviews the rule, and that ambiguity is how good detections quietly rot.

Frequently Asked Questions

Does Event ID 7045 require special audit settings?

No. 7045 is written to the System log by Service Control Manager regardless of audit policy, which makes it more reliable than the Security-log equivalent. If you want the audited version, Event ID 4697 requires "Audit Security System Extension" to be enabled.

What is the difference between Event ID 7045 and 4697?

Both record a new service install. 7045 is in the System log and on by default; 4697 is in the Security log and requires auditing. Collecting 7045 is usually the lower-effort choice; collect 4697 as well if you want the richer Security-log context and subject fields.

How do I detect malicious driver installs specifically?

Filter on the kernel-mode service type, as in the second rule above. Driver installs are rare on most endpoints, so a broad rule that feeds a review queue is reasonable — pair it with driver block-list enforcement to actually stop bring-your-own-vulnerable-driver attacks.

Will this catch services created with PowerShell instead of sc.exe?

The 7045 rule will, because it keys on the installed service regardless of how it was created. The process-creation rule is specific to sc.exe; add a parallel selection for New-Service in a PowerShell command line to cover the cmdlet path.

How do I tune false positives without missing real installs?

Exclude legitimate agents by service name or signer in a filter block, and keep the indicator list intact. Trimming indicators to silence one noisy vendor is how you end up blind to the malicious install that uses the same path.

Conclusion

Service installation is an attacker favourite because it is privileged, persistent, and indistinguishable from legitimate activity until you look at the image path. Event ID 7045 gives you that field without any audit configuration, which makes it one of the better-value detections to stand up. Writing it as Sigma means the logic converts into whatever SIEM you run and survives a migration intact.

As with the scheduled-task rules, none of these is complete alone. Pair the 7045 rule with the kernel-driver rule and the sc.exe process rule, exclude your real false positives by signer, and document why. That combination separates the printer driver from the loader, which is the entire job.

Related Posts

• Windows Security: Best Practices for Securing Windows Services — the hardening side of the same service attack surface.
• Windows Security: Detecting Malicious Scheduled Tasks — the sibling persistence technique, detected with the same two-rule pattern.
• Sysmon Configuration for Windows Security Monitoring — the process-creation log source the sc.exe rule depends on.

Authoritative reference: MITRE ATT&CK T1543.003 — Windows Service and the SigmaHQ rule repository.

Editorial note: posts on this blog are drafted with AI assistance and then reviewed, edited, and tested against a real environment before publishing. Commands, output, and screenshots come from systems I actually ran the work on.