Suspicious ImagePath Service Creation
Identifies the creation of a suspicious ImagePath value. This could be an indication of an adversary attempting to stealthily persist or escalate privileges through abnormal service creation.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2020/11/23"
3integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
4maturity = "production"
5updated_date = "2026/05/03"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies the creation of a suspicious ImagePath value. This could be an indication of an adversary attempting to
11stealthily persist or escalate privileges through abnormal service creation.
12"""
13from = "now-9m"
14index = [
15 "logs-endpoint.events.registry-*",
16 "endgame-*",
17 "logs-windows.sysmon_operational-*",
18 "winlogbeat-*",
19 "logs-m365_defender.event-*",
20 "logs-sentinel_one_cloud_funnel.*",
21 "logs-crowdstrike.fdr*",
22]
23language = "eql"
24license = "Elastic License v2"
25name = "Suspicious ImagePath Service Creation"
26risk_score = 73
27rule_id = "36a8e048-d888-4f61-a8b9-0f9e2e40f317"
28severity = "high"
29tags = [
30 "Domain: Endpoint",
31 "OS: Windows",
32 "Use Case: Threat Detection",
33 "Tactic: Persistence",
34 "Data Source: Elastic Endgame",
35 "Data Source: Elastic Defend",
36 "Data Source: Sysmon",
37 "Data Source: Microsoft Defender XDR",
38 "Data Source: SentinelOne",
39 "Data Source: Crowdstrike",
40 "Resources: Investigation Guide",
41]
42timestamp_override = "event.ingested"
43type = "eql"
44
45query = '''
46registry where host.os.type == "windows" and event.type == "change" and
47 registry.value : "ImagePath" and
48 registry.path : "*\\SYSTEM\\ControlSet*\\Services\\*\\ImagePath" and
49 /* add suspicious registry ImagePath values here */
50 registry.data.strings : ("%COMSPEC%*", "*\\.\\pipe\\*")
51'''
52
53note = """## Triage and analysis
54
55### Investigating Suspicious ImagePath Service Creation
56
57#### Possible investigation steps
58
59- What exact service "ImagePath" behavior did the alert preserve?
60 - Why: shell and pipe-backed service launches require different execution pivots.
61 - Focus: `registry.path`, `registry.key`, `registry.value`, `registry.data.type`, `registry.data.strings`.
62 - Implication: escalate when the value invokes the command interpreter, chains shell commands, or points to a local named pipe instead of a normal service executable; lower concern only when exact key and value match a recognized same-product service wrapper.
63
64- Who wrote the service value, and does that context fit service management?
65 - Focus: `process.executable`, `process.command_line`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `user.id`.
66 - Hint: if the writer is "svchost.exe" or another broker, use `process.parent.executable` and broader lineage before attributing intent. $investigate_0
67 - Implication: escalate for unsigned utilities, script hosts, remote-admin tools, unusual paths, or user contexts that do not fit service changes; lower concern only when signer, path, command line, and user fit a recognized installer or management agent.
68
69- Did the same writer change other values under the service key?
70 - Why: existing-service edits can preserve trust while changing start mode, account context, DLL loading, failure behavior, or security descriptor.
71 - Focus: same-`host.id` registry events scoped by service `registry.key`, reviewing `registry.value` and `registry.data.strings`. $investigate_1
72 - Implication: escalate when surrounding values make the service autostart, run privileged, load a DLL/parameter path, restart on failure, or become harder to enumerate; lower concern when the writer performs only one bounded product-owned service update.
73
74- Did the service path execute or spawn follow-on activity?
75 - Focus: later same-`host.id` process events where `process.executable` or `process.command_line` matches the recovered service value, plus `process.parent.executable` and lineage. $investigate_2
76 - Range: start with the alert window; expand after `@timestamp` only to test delayed service start.
77 - Hint: for command-interpreter paths, search "cmd.exe" and recovered command fragments in `process.command_line`; for named-pipe paths, search "services.exe" lineage, helpers, or service-start failures instead of expecting a file-backed executable.
78 - Implication: escalate when service lineage launches a shell, pipe helper, or unexpected child soon after the write; do not close solely because execution is not visible, since the service may start later or fail during launch.
79
80- If execution occurred, does the launched process fit the expected service?
81 - Focus: recovered launch event: `process.hash.sha256`, `process.code_signature.subject_name`, `process.code_signature.trusted`, `process.pe.original_file_name`, `process.Ext.relative_file_creation_time`.
82 - Implication: escalate when the binary is unsigned, newly created, renamed, PE-mismatched, or unrelated to the writer signer; lower concern when identity, signer, age, and service value all fit the same recognized product.
83
84- What disposition do service value, writer, adjacent values, execution, and related alerts support?
85 - Hint: if local evidence remains suspicious or unresolved, review user- and host-scoped alerts.
86 - $investigate_3
87 - $investigate_4
88 - Implication: escalate when shell or named-pipe execution plus writer, adjacent value, execution, or alert context fails to fit one recognized workflow; close only when those categories converge on the exact service-management activity, using outside confirmation when telemetry cannot prove legitimacy; if evidence is mixed or incomplete, preserve registry and process evidence and escalate.
89
90### False positive analysis
91
92- Software installation, repair, agent upgrade, remote-support, or deployment tooling can rewrite service "ImagePath" values or register short-lived helper services only when a signed installer, management component, vendor behavior, or internal test plan owns the service end-to-end. Confirm `process.executable`, signer/trust, `user.id`, `registry.key`, `registry.data.strings`, and later parent/command-line activity align with that workflow, not an ad hoc shell or pipe helper.
93- Shell or pipe "ImagePath" behavior is an anti-pattern unless the vendor or test plan accounts for that exact helper. Without records, require current-case telemetry that writer, signer, service key/value, `user.id`, `host.id`, later execution, and related alerts align without contradiction.
94- Before creating an exception, use prior alerts only to prove exception stability, not to close the case. Validate consistent service value, writer, user, host, and execution behavior across the same workflow. Treat a first occurrence as a candidate exception, not a suppression. Build the exception from the minimum confirmed pattern: writer signer and path, exact service key, exact `registry.data.strings`, `user.id`, and `host.id`. Avoid exceptions on `registry.value` = "ImagePath", "services.exe", or the rule name alone.
95
96### Response and remediation
97
98- If confirmed benign, preserve the case export and document the writer identity, exact service key and value, affected `user.id` and `host.id`, and later service-start behavior that proved the recognized workflow before reversing temporary containment. Keep any exception narrow and require recurrence of the same workflow pattern.
99- If suspicious but unconfirmed, preserve a case export of the triggering registry event, exact service key/value, writer process details, launched-process details, and volatile service state before containment. Then apply reversible containment tied to those findings, such as disabling the affected service, preventing the referenced command from starting, or isolating the host only after weighing service criticality. Escalate to account or broader host action only when related alerts or later execution show wider compromise.
100- If confirmed malicious, preserve the same registry and process evidence before destructive action. Disable and remove the malicious or hijacked service, restore the expected "ImagePath", quarantine the referenced executable or command artifact when present, and review the same `process.entity_id`, `registry.key`, and service lineage for additional unauthorized service changes before cleanup. Use endpoint response tooling to contain the host or terminate the recovered malicious process when available; if direct response is unavailable, escalate with the preserved identifiers to the team that can act.
101- After containment, review other hosts for the same `registry.data.strings`, service-key pattern, signer, hash, or command fragment before deleting artifacts, then verify that no additional services reference the same shell, named pipe, or staged payload.
102- Post-incident hardening: restrict service creation and service-registry writes to trusted installers and management tools, retain registry and process telemetry needed to correlate "ImagePath" changes to later execution, and record any adjacent service-abuse variant surfaced during triage.
103"""
104
105setup = """## Setup
106
107This rule is designed for data generated by [Elastic Defend](https://www.elastic.co/security/endpoint-security), which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.
108
109Setup instructions: https://ela.st/install-elastic-defend
110
111### Additional data sources
112
113This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
114
115- [CrowdStrike](https://ela.st/crowdstrike-integration)
116- [Microsoft Defender XDR](https://ela.st/m365-defender)
117- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
118- [Sysmon Registry Events](https://ela.st/sysmon-event-reg-setup)
119"""
120
121[rule.investigation_fields]
122field_names = [
123 "@timestamp",
124 "host.id",
125 "user.id",
126 "process.entity_id",
127 "process.pid",
128 "process.executable",
129 "process.command_line",
130 "process.code_signature.subject_name",
131 "process.code_signature.trusted",
132 "process.parent.executable",
133 "registry.path",
134 "registry.key",
135 "registry.value",
136 "registry.data.type",
137 "registry.data.strings",
138]
139
140[transform]
141
142[[transform.investigate]]
143label = "Activity from this writer process"
144description = ""
145providers = [
146 [
147 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
148 { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
149 ],
150 [
151 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
152 { excluded = false, field = "process.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" }
153 ]
154]
155relativeFrom = "now-1h"
156relativeTo = "now"
157
158[[transform.investigate]]
159label = "Registry events for the same service key"
160description = ""
161providers = [
162 [
163 { excluded = false, field = "event.category", queryType = "phrase", value = "registry", valueType = "string" },
164 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
165 { excluded = false, field = "registry.key", queryType = "phrase", value = "{{registry.key}}", valueType = "string" }
166 ]
167]
168relativeFrom = "now-1h"
169relativeTo = "now"
170
171[[transform.investigate]]
172label = "Process starts on the host near the service change"
173description = ""
174providers = [
175 [
176 { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
177 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
178 ]
179]
180relativeFrom = "now-1h"
181relativeTo = "now"
182
183[[transform.investigate]]
184label = "Alerts associated with the user"
185description = ""
186providers = [
187 [
188 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
189 { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
190 ]
191]
192relativeFrom = "now-48h/h"
193relativeTo = "now"
194
195[[transform.investigate]]
196label = "Alerts associated with the host"
197description = ""
198providers = [
199 [
200 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
201 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
202 ]
203]
204relativeFrom = "now-48h/h"
205relativeTo = "now"
206
207[[rule.threat]]
208framework = "MITRE ATT&CK"
209
210[[rule.threat.technique]]
211id = "T1543"
212name = "Create or Modify System Process"
213reference = "https://attack.mitre.org/techniques/T1543/"
214
215[[rule.threat.technique.subtechnique]]
216id = "T1543.003"
217name = "Windows Service"
218reference = "https://attack.mitre.org/techniques/T1543/003/"
219
220[rule.threat.tactic]
221id = "TA0003"
222name = "Persistence"
223reference = "https://attack.mitre.org/tactics/TA0003/"
224
225[[rule.threat]]
226framework = "MITRE ATT&CK"
227
228[[rule.threat.technique]]
229id = "T1112"
230name = "Modify Registry"
231reference = "https://attack.mitre.org/techniques/T1112/"
232
233[rule.threat.tactic]
234id = "TA0005"
235name = "Defense Evasion"
236reference = "https://attack.mitre.org/tactics/TA0005/"
Triage and analysis
Investigating Suspicious ImagePath Service Creation
Possible investigation steps
-
What exact service "ImagePath" behavior did the alert preserve?
- Why: shell and pipe-backed service launches require different execution pivots.
- Focus:
registry.path,registry.key,registry.value,registry.data.type,registry.data.strings. - Implication: escalate when the value invokes the command interpreter, chains shell commands, or points to a local named pipe instead of a normal service executable; lower concern only when exact key and value match a recognized same-product service wrapper.
-
Who wrote the service value, and does that context fit service management?
- Focus:
process.executable,process.command_line,process.code_signature.subject_name,process.code_signature.trusted,user.id. - Hint: if the writer is "svchost.exe" or another broker, use
process.parent.executableand broader lineage before attributing intent. $investigate_0 - Implication: escalate for unsigned utilities, script hosts, remote-admin tools, unusual paths, or user contexts that do not fit service changes; lower concern only when signer, path, command line, and user fit a recognized installer or management agent.
- Focus:
-
Did the same writer change other values under the service key?
- Why: existing-service edits can preserve trust while changing start mode, account context, DLL loading, failure behavior, or security descriptor.
- Focus: same-
host.idregistry events scoped by serviceregistry.key, reviewingregistry.valueandregistry.data.strings. $investigate_1 - Implication: escalate when surrounding values make the service autostart, run privileged, load a DLL/parameter path, restart on failure, or become harder to enumerate; lower concern when the writer performs only one bounded product-owned service update.
-
Did the service path execute or spawn follow-on activity?
- Focus: later same-
host.idprocess events whereprocess.executableorprocess.command_linematches the recovered service value, plusprocess.parent.executableand lineage. $investigate_2 - Range: start with the alert window; expand after
@timestamponly to test delayed service start. - Hint: for command-interpreter paths, search "cmd.exe" and recovered command fragments in
process.command_line; for named-pipe paths, search "services.exe" lineage, helpers, or service-start failures instead of expecting a file-backed executable. - Implication: escalate when service lineage launches a shell, pipe helper, or unexpected child soon after the write; do not close solely because execution is not visible, since the service may start later or fail during launch.
- Focus: later same-
-
If execution occurred, does the launched process fit the expected service?
- Focus: recovered launch event:
process.hash.sha256,process.code_signature.subject_name,process.code_signature.trusted,process.pe.original_file_name,process.Ext.relative_file_creation_time. - Implication: escalate when the binary is unsigned, newly created, renamed, PE-mismatched, or unrelated to the writer signer; lower concern when identity, signer, age, and service value all fit the same recognized product.
- Focus: recovered launch event:
-
What disposition do service value, writer, adjacent values, execution, and related alerts support?
- Hint: if local evidence remains suspicious or unresolved, review user- and host-scoped alerts.
- $investigate_3
- $investigate_4
- Implication: escalate when shell or named-pipe execution plus writer, adjacent value, execution, or alert context fails to fit one recognized workflow; close only when those categories converge on the exact service-management activity, using outside confirmation when telemetry cannot prove legitimacy; if evidence is mixed or incomplete, preserve registry and process evidence and escalate.
- Hint: if local evidence remains suspicious or unresolved, review user- and host-scoped alerts.
False positive analysis
- Software installation, repair, agent upgrade, remote-support, or deployment tooling can rewrite service "ImagePath" values or register short-lived helper services only when a signed installer, management component, vendor behavior, or internal test plan owns the service end-to-end. Confirm
process.executable, signer/trust,user.id,registry.key,registry.data.strings, and later parent/command-line activity align with that workflow, not an ad hoc shell or pipe helper. - Shell or pipe "ImagePath" behavior is an anti-pattern unless the vendor or test plan accounts for that exact helper. Without records, require current-case telemetry that writer, signer, service key/value,
user.id,host.id, later execution, and related alerts align without contradiction. - Before creating an exception, use prior alerts only to prove exception stability, not to close the case. Validate consistent service value, writer, user, host, and execution behavior across the same workflow. Treat a first occurrence as a candidate exception, not a suppression. Build the exception from the minimum confirmed pattern: writer signer and path, exact service key, exact
registry.data.strings,user.id, andhost.id. Avoid exceptions onregistry.value= "ImagePath", "services.exe", or the rule name alone.
Response and remediation
- If confirmed benign, preserve the case export and document the writer identity, exact service key and value, affected
user.idandhost.id, and later service-start behavior that proved the recognized workflow before reversing temporary containment. Keep any exception narrow and require recurrence of the same workflow pattern. - If suspicious but unconfirmed, preserve a case export of the triggering registry event, exact service key/value, writer process details, launched-process details, and volatile service state before containment. Then apply reversible containment tied to those findings, such as disabling the affected service, preventing the referenced command from starting, or isolating the host only after weighing service criticality. Escalate to account or broader host action only when related alerts or later execution show wider compromise.
- If confirmed malicious, preserve the same registry and process evidence before destructive action. Disable and remove the malicious or hijacked service, restore the expected "ImagePath", quarantine the referenced executable or command artifact when present, and review the same
process.entity_id,registry.key, and service lineage for additional unauthorized service changes before cleanup. Use endpoint response tooling to contain the host or terminate the recovered malicious process when available; if direct response is unavailable, escalate with the preserved identifiers to the team that can act. - After containment, review other hosts for the same
registry.data.strings, service-key pattern, signer, hash, or command fragment before deleting artifacts, then verify that no additional services reference the same shell, named pipe, or staged payload. - Post-incident hardening: restrict service creation and service-registry writes to trusted installers and management tools, retain registry and process telemetry needed to correlate "ImagePath" changes to later execution, and record any adjacent service-abuse variant surfaced during triage.
Related rules
- Creation of a Hidden Local User Account
- Persistence via Hidden Run Key Detected
- Persistence via Microsoft Office AddIns
- Persistence via TelemetryController Scheduled Task Hijack
- Suspicious Startup Shell Folder Modification