Service execution or recovery registry value rewritten

Siemphony@siemphonylowT1574.011unverified

AN1195's `MonitoredServiceKeys` knob names `ImagePath`, `ServiceDll`, `FailureCommand` and the `Parameters` subkey as the values a weak ACL lets an attacker rewrite to redirect what a service launches; this rule matches a registry write under `CurrentControlSet\Services\` to any of those value names. The brief's `sigmaLogsource` for this leg is `registry_set` with no `service` qualifier, which is Sysmon's EventID 13 shape (`TargetObject` carries the full key-plus-value path, `Details` carries the written data), and that is the vocabulary this rule is written in. The brief also lists Security EventID 4657 for the same analytic, but 4657 is a structurally different feed — it splits the key and value into separate `ObjectName` and `ObjectValueName` fields rather than Sysmon's single `TargetObject` — so turning on *Audit Registry* and a SACL on the Services key would not make this rule see anything; it would need its own field mapping. The System 7040 leg (service start-type changed) is a different signal again — a configuration change surfaced by the Service Control Manager, not the registry write itself — and is likewise not combined here. This rule cannot express AN1195's `BaselineServiceConfig` or `TimeWindow` knobs: comparing a new value against a known-good baseline, or correlating the write with the service process that starts afterward, both need state or a cross-event join lib/sigma does not model, so a hit is evidence of a rewrite and not by itself evidence that the new value is wrong. Sysmon is not installed by default, and most shipped configurations exclude the high-volume `Services` subtree from EventID 13 entirely — on such a host this rule returns zero rows, which reads as quiet but means blind. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0427, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 4 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Sentinel · KQL

Run this as a search.

DeviceRegistryEvents| where (RegistryKey contains "\\CurrentControlSet\\Services\\" and (RegistryKey endswith "\\ImagePath" or RegistryKey endswith "\\FailureCommand" or RegistryKey endswith "\\Parameters\\ServiceDll"))

Splunk · SPL

Run this as a search.

index=* (TargetObject="*\\CurrentControlSet\\Services\\*" AND (TargetObject="*\\ImagePath" OR TargetObject="*\\FailureCommand" OR TargetObject="*\\Parameters\\ServiceDll"))

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(registry.path) LIKE "*\\\\currentcontrolset\\\\services\\\\*" AND (TO_LOWER(registry.path) LIKE "*\\\\imagepath" OR TO_LOWER(registry.path) LIKE "*\\\\failurecommand" OR TO_LOWER(registry.path) LIKE "*\\\\parameters\\\\servicedll"))

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,registry_set,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="5">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="TargetObject" type="pcre2">(?i)\\CurrentControlSet\\Services\\</field>    <field name="TargetObject" type="pcre2">(?i)(\\ImagePath$|\\FailureCommand$|\\Parameters\\ServiceDll$)</field>    <description>Service execution or recovery registry value rewritten</description>    <mitre>      <id>T1574.011</id>    </mitre>  </rule></group>

At a glance

Logsource: registry_set / windows
Level: low
Category: registry_persistence
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 77e94954-f423-4b75-a9b7-5047c8325302

ATT&CKT1574.011

T1574.011Services Registry Permissions Weakness

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessonregistry persistence

registry persistenceAI draft — unreviewed

01 · What this rule detects

A Windows registry write under CurrentControlSet\Services\ to one of the value names that control what a service launches: ImagePath, FailureCommand, or Parameters\ServiceDll. AN1195's MonitoredServiceKeys knob names these (plus a bare Parameters subkey, not implemented separately here) as the values a weak service ACL lets an attacker rewrite to redirect what runs when the service starts, recovers from a crash, or loads its hosting DLL — hijacking a trusted, often auto-start, execution path.

02 · Telemetry you need

category: registry_set, product: windows — Sysmon EventID 13. Sysmon is not installed by default, and most shipped configurations exclude the high-volume Services subtree from EID13 entirely to control log volume — on such a host this rule returns zero rows, which reads as quiet but means blind. This is the vocabulary the rule is written in specifically because the brief's sigmaLogsource for this leg carries no service qualifier, which is Sysmon's shape: a single TargetObject field carrying the full key-plus-value path, with Details carrying the written data.

03 · How the logic works

Two selections, ANDed:

contains gates on any services key, endswith narrows to the specific value names inside it. Both conditions read one field, TargetObject, because Sysmon packs key and value into that single path rather than splitting them. The brief also lists Security EventID 4657 for the same analytic, and this rule deliberately does not fold it in. 4657 is a structurally different feed: it splits what Sysmon puts in one TargetObject into separate ObjectName and ObjectValueName fields. Turning on Audit Registry and a SACL on the Services key would not make this rule see anything more — it would need its own selection written against 4657's fields. Telling a reader to enable that auditing as though it feeds this rule would send them to configure a feed this Sigma cannot read. AN1195's BaselineServiceConfig and TimeWindow knobs are also not attempted: comparing the new value against a known-good baseline, or correlating the write with the service process that starts afterward against a time window, both need state or a cross-event join lib/sigma doesn't model. A hit here is evidence a value was rewritten — not, by itself, evidence the new value is malicious.

04 · Common false positives

ImagePath is written for every new service install — sc.exe create, New-Service, or any MSI/EXE installer's service-install custom action — making ordinary software and driver installs the highest-volume source of matches by a wide margin. Windows Update and component servicing rewrite ServiceDll for in-box svchost-hosted services (BITS, wuauserv, and similar) during cumulative updates even when the referenced DLL file itself never moves. Endpoint-management agents (Configuration Manager, Intune) reconfigure FailureCommand and restart-recovery actions fleet-wide as routine hardening. Plug and Play driver installation via pnputil or Device Manager writes ImagePath for every newly installed kernel or filter driver service. level: low reflects that the loudest of these — routine service install — vastly outnumbers any adversarial rewrite.

05 · Detection maturity

tier_1: .** UNVERIFIED — derived from DET0427 and never run against a log line. The value-name list traces to MITRE's MonitoredServiceKeys, but which of them matter most for your environment, and what a normal install baseline looks like, is unverified.
tier_2: needs a week of EID13 from a Services-inclusive Sysmon config to separate routine install noise from rewrites of pre-existing services before this is usable without heavy triage.

Tuning & false positivesexperimental · 4 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

Pair the write with the writing process from a joined process-creation event: sc.exe, msiexec.exe, TrustedInstaller.exe, and known deployment-agent binaries account for most legitimate writes and can be excluded once confirmed. Track whether the target service already existed (a first-seen ImagePath for a brand-new service name is routine install; a change to an existing, long-running service's ImagePath is a different and more interesting event) — that distinction needs the BaselineServiceConfig state this rule doesn't have. Scope the Sysmon config to actually emit EID13 for the Services subtree, since most baselines exclude it and the rule is blind without that change.

Declared by the author

Ordinary service installation through sc.exe create, New-Service, or an MSI/EXE installer's service-install custom action, which writes ImagePath for every new service on every host — this is the highest-volume source of matches here and fires on essentially any software or driver install that registers a service.
Windows Update and component servicing rewriting ServiceDll for in-box svchost-hosted services (BITS, wuauserv, and similar) as part of a cumulative update, even though the referenced DLL file itself did not move.
Endpoint-management agents such as Configuration Manager or Intune reconfiguring FailureCommand or restart-recovery actions across a fleet as part of a routine service-hardening baseline.
Plug and Play driver installation via pnputil or Device Manager, which creates or updates the ImagePath value for a newly installed kernel or filter driver service.

Noise checkfires on 1 of 6

Fires on 1 of 6 ordinary behaviours the baseline holds for this log type. Each is something a managed estate does on purpose, so each is a false positive an analyst would have to close.

reg-service-install
Service registration during a normal software install.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
0 true · 1 false · 100.0% noise

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1574.011, evaluated against their registry_set events.

Share this rule

/u/siemphony/77e94954-f423-4b75-a9b7-5047c8325302

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

Service execution or recovery registry value rewritten

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it