« AdminSDHolder SDProp Exclusion Added Persistence via Hidden Run Key Detected »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.24

Suspicious ImagePath Service Creation

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Suspicious ImagePath Service Creation

edit

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.

Rule type: eql

Rule indices:

  • logs-endpoint.events.registry-*
  • endgame-*
  • logs-windows.sysmon_operational-*
  • winlogbeat-*
  • logs-m365_defender.event-*
  • logs-sentinel_one_cloud_funnel.*
  • logs-crowdstrike.fdr*

Severity: high

Risk score: 73

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References: None

Tags:

  • Domain: Endpoint
  • OS: Windows
  • Use Case: Threat Detection
  • Tactic: Persistence
  • Data Source: Elastic Endgame
  • Data Source: Elastic Defend
  • Data Source: Sysmon
  • Data Source: Microsoft Defender XDR
  • Data Source: SentinelOne
  • Data Source: Crowdstrike
  • Resources: Investigation Guide

Version: 315

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

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.executable and broader lineage before attributing intent. !{investigate{"description":"","label":"Activity from this writer process","providers":[[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.entity_id","queryType":"phrase","value":"{{process.entity_id}}","valueType":"string"}],[{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"process.pid","queryType":"phrase","value":"{{process.pid}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • 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.
  • 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.id registry events scoped by service registry.key, reviewing registry.value and registry.data.strings. !{investigate{"description":"","label":"Registry events for the same service key","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"registry","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"},{"excluded":false,"field":"registry.key","queryType":"phrase","value":"{{registry.key}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • 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.id process events where process.executable or process.command_line matches the recovered service value, plus process.parent.executable and lineage. !{investigate{"description":"","label":"Process starts on the host near the service change","providers":[[{"excluded":false,"field":"event.category","queryType":"phrase","value":"process","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-1h","relativeTo":"now"}}
  • Range: start with the alert window; expand after @timestamp only 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.
  • 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.
  • 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{"description":"","label":"Alerts associated with the user","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"user.id","queryType":"phrase","value":"{{user.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • !{investigate{"description":"","label":"Alerts associated with the host","providers":[[{"excluded":false,"field":"event.kind","queryType":"phrase","value":"signal","valueType":"string"},{"excluded":false,"field":"host.id","queryType":"phrase","value":"{{host.id}}","valueType":"string"}]],"relativeFrom":"now-48h/h","relativeTo":"now"}}
  • 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.

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, and host.id. Avoid exceptions on registry.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.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.
  • 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.

Setup

edit

Setup

This rule is designed for data generated by Elastic Defend, which provides native endpoint detection and response, along with event enrichments designed to work with our detection rules.

Setup instructions: https://ela.st/install-elastic-defend

Additional data sources

This rule also supports the following third-party data sources. For setup instructions, refer to the links below:

Rule query

edit
registry where host.os.type == "windows" and event.type == "change" and
  registry.value : "ImagePath" and
  registry.path : "*\\SYSTEM\\ControlSet*\\Services\\*\\ImagePath" and
  /* add suspicious registry ImagePath values here */
  registry.data.strings : ("%COMSPEC%*", "*\\.\\pipe\\*")

Framework: MITRE ATT&CKTM

« AdminSDHolder SDProp Exclusion Added Persistence via Hidden Run Key Detected »