Potential Masquerading as Svchost

Identifies attempts to masquerade as the Service Host process svchost.exe to evade detection and blend in with normal system activity.

Elastic rule (View on GitHub)

  1[metadata]
  2creation_date = "2025/11/12"
  3integration = ["endpoint", "windows", "system"]
  4maturity = "production"
  5updated_date = "2026/09/18"
  6min_stack_comments = "Changing min stack to 9.3.0, the latest minimum supported version for 9.X releases."
  7min_stack_version = "9.3.0"
  8[rule]
  9author = ["Elastic"]
 10description = """
 11Identifies attempts to masquerade as the Service Host process `svchost.exe` to evade detection and blend in with
 12normal system activity.
 13"""
 14from = "now-9m"
 15interval = "8m"
 16language = "esql"
 17license = "Elastic License v2"
 18name = "Potential Masquerading as Svchost"
 19risk_score = 73
 20rule_id = "32f95776-6498-4f3c-a90c-d4f6083e3901"
 21severity = "high"
 22tags = [
 23    "Domain: Endpoint",
 24    "OS: Windows",
 25    "Use Case: Threat Detection",
 26    "Tactic: Defense Evasion",
 27    "Resources: Investigation Guide",
 28    "Data Source: Elastic Defend",
 29    "Data Source: Windows Security Event Logs",
 30    "Data Source: Sysmon",
 31    "Noise: Medium",
 32    "Performance: Normal",
 33    "Profile: Recommended",
 34    "Threat: Masquerading",
 35    "Rule Type: ES|QL",
 36    "Platform: Windows",
 37]
 38timestamp_override = "event.ingested"
 39type = "esql"
 40
 41query = '''
 42FROM logs-endpoint.events.process-*, logs-windows.sysmon_operational-*, logs-system.security-*, logs-windows.*, winlogbeat-* metadata _id, _version, _index
 43| where event.category == "process" and event.type == "start" and
 44  match(process.name, "svchost.exe", { "fuzziness": 1, "max_expansions": 10 }) and
 45  not to_lower(process.executable) in ("c:\\windows\\syswow64\\svchost.exe", "c:\\windows\\system32\\svchost.exe") and
 46  not to_lower(process.executable) like """\\device\\harddiskvolume*\\windows\\system32\\svchost.exe""" and
 47  not to_lower(process.executable) like """\\device\\harddiskvolume*\\windows\\syswow64\\svchost.exe""" 
 48| keep *
 49'''
 50
 51note = """## Triage and analysis
 52
 53### Investigating Potential Masquerading as Svchost
 54
 55#### Possible investigation steps
 56
 57- Does the alert confirm a service-host-like name running from a noncanonical path?
 58  - Focus: `process.name`, `process.executable`, `process.command_line`, `process.parent.executable`, and `host.id`, comparing the path with `C:\\Windows\\System32\\svchost.exe` and `C:\\Windows\\SysWOW64\\svchost.exe`.
 59  - Hint: use `process.entity_id`, hash, and signer fields where present; if enrichments are missing, keep the gap unresolved and scope by `host.id`, path, and alert time.
 60  - Implication: escalate when svchost.exe or a near-match runs from a user-writable, temp, share-backed, or product-mismatched path; lower concern only when a recognized lab, build-test, or recovery workflow also fits later evidence.
 61
 62- Is the file identity or rename timing consistent with Microsoft Service Host?
 63  - Focus: `process.hash.sha256`, `process.pe.original_file_name`, `process.code_signature.*`, rename timing, and file events for the same path. $investigate_0
 64  - Implication: escalate for an unfamiliar hash, unsigned/untrusted or non-Microsoft signer, recent rename, or original filename conflict; Microsoft identity and stable name timing reduce identity concern but do not clear the noncanonical path.
 65
 66- Does the launch context fit service-controlled svchost.exe behavior?
 67  - Focus: `process.parent.name`, `process.parent.executable`, `process.parent.command_line`, `process.command_line`, and session context, checking for services.exe and service grouping arguments such as `-k <group>` or `-s <service>`.
 68  - Implication: escalate when the parent is a shell, script engine, Office process, archive tool, or user-run utility, when service-group arguments are absent, or when context is interactive; services.exe plus service grouping lowers launch-context concern, but the noncanonical path still needs explanation.
 69
 70- Does this process instance behave like a launcher rather than a passive service host?
 71  - Focus: child starts where `process.parent.entity_id` matches `process.entity_id`, especially child `process.name`, `process.executable`, and `process.command_line`. $investigate_1
 72  - Hint: use `process.Ext.ancestry` only as a deeper fallback when direct parent-child lineage is missing or incomplete.
 73  - Implication: escalate when it spawns shells, script engines, admin tools, installers, additional lookalikes, or short-lived command chains; absent or service-like child activity narrows launcher risk but does not close the name/path anomaly.
 74
 75- If local findings remain suspicious or unresolved, does related alert scope show reuse of the same masquerading path?
 76  - Focus: related alerts for the same `process.executable` or `process.hash.sha256`, comparing `host.id` and `user.id` where available. $investigate_2 $investigate_3
 77  - Implication: broaden scope and raise urgency when the same path or hash appears on other hosts, users, or alert types; keep local only when related alerts are absent and all local evidence supports one recognized lab, build, or recovery workflow.
 78
 79- Escalate when the path anomaly plus identity, lineage, timing, child-process, or scope evidence points to masquerading or broader compromise; close only when path, identity, launch context, and bounded host/user scope prove one recognized lab, build, or recovery workflow; if telemetry cannot prove legitimacy, preserve artifacts and escalate.
 80
 81### False positive analysis
 82
 83- Controlled malware-analysis, image-build, or recovery testing can stage a service-host-like file outside canonical Windows paths. Confirm by aligning identity (`process.hash.sha256`, `process.pe.original_file_name`, signer trust/subject), launch context (`process.parent.executable`, `process.parent.command_line`, `process.command_line`), and scope (`host.id`, `host.name`, `user.id`). Without outside records, close only when process fields prove the controlled workflow.
 84- Treat a noncanonical svchost.exe name as suspicious until process evidence proves one complete benign workflow; a trusted Microsoft signer, familiar parent, or single quiet execution is not enough when the path or name still mimics Service Host.
 85- Before creating an exception, require recurring `process.executable`, `process.hash.sha256`, signer subject, parent executable, command-line shape, and `host.id` or controlled host cohort across prior alerts from this rule. Avoid exceptions on `process.name`, svchost.exe, `user.name`, or a host alone.
 86
 87### Response and remediation
 88
 89- If confirmed benign, reverse any temporary containment and record the exact workflow evidence: `process.executable`, `process.hash.sha256`, `process.code_signature.subject_name`, `process.parent.executable`, `process.command_line`, `host.id`, and the controlled lab, build, or recovery scope. Create an exception only after the same evidence pattern recurs.
 90- If suspicious but unconfirmed, preserve the alert, source process event, recovered `process.entity_id`, `process.executable`, `process.hash.sha256`, signature metadata, parent context, command line, and related-alert results before containment. Apply reversible controls first, such as heightened monitoring or temporary network restrictions for the affected `host.id`, and avoid termination or deletion until scope is clearer.
 91- If confirmed malicious, first preserve the recovered `process.entity_id`, command line, child-process list, path evidence, and forensic package for `process.executable`. Finish same-path and same-hash scoping, then isolate the endpoint when host criticality allows, terminate only the suspicious noncanonical service-host process, and remove the masquerading executable or launcher artifacts. Do not stop canonical Service Host instances unless that exact instance is proven malicious.
 92- After containment, restore any affected service-host component from known-good media if a legitimate file was replaced, restrict execution from user-writable or share-backed paths where feasible, and document the recovered command-line and parent-chain pattern that separated this fake service host from normal services.exe-launched instances.
 93"""
 94
 95setup = """## Setup
 96
 97This 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.
 98
 99Setup instructions: https://ela.st/install-elastic-defend
100
101### Additional data sources
102
103This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
104
105- [Sysmon Event ID 1 - Process Creation](https://ela.st/sysmon-event-1-setup)
106- [Windows Process Creation Logs](https://ela.st/audit-process-creation)
107"""
108
109[rule.investigation_fields]
110field_names = [
111    "@timestamp",
112    "host.name",
113    "host.id",
114    "user.name",
115    "user.id",
116    "process.name",
117    "process.entity_id",
118    "process.executable",
119    "process.command_line",
120    "process.hash.sha256",
121    "process.pe.original_file_name",
122    "process.code_signature.subject_name",
123    "process.code_signature.trusted",
124    "process.parent.executable",
125    "process.parent.command_line",
126]
127
128[transform]
129
130[[transform.investigate]]
131label = "File events for the masquerading executable path"
132description = ""
133providers = [
134  [
135    { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
136    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
137    { excluded = false, field = "file.path", queryType = "phrase", value = "{{process.executable}}", valueType = "string" }
138  ]
139]
140relativeFrom = "now-24h"
141relativeTo = "now"
142
143[[transform.investigate]]
144label = "Child process starts from the masquerading svchost instance"
145description = ""
146providers = [
147  [
148    { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
149    { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
150    { excluded = false, field = "process.parent.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
151  ]
152]
153relativeFrom = "now-1h"
154relativeTo = "now"
155
156[[transform.investigate]]
157label = "Alerts associated with the same executable path"
158description = ""
159providers = [
160  [
161    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
162    { excluded = false, field = "process.executable", queryType = "phrase", value = "{{process.executable}}", valueType = "string" }
163  ]
164]
165relativeFrom = "now-48h/h"
166relativeTo = "now"
167
168[[transform.investigate]]
169label = "Alerts associated with the same executable hash"
170description = ""
171providers = [
172  [
173    { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
174    { excluded = false, field = "process.hash.sha256", queryType = "phrase", value = "{{process.hash.sha256}}", valueType = "string" }
175  ]
176]
177relativeFrom = "now-48h/h"
178relativeTo = "now"
179
180[[rule.threat]]
181framework = "MITRE ATT&CK"
182[[rule.threat.technique]]
183id = "T1036"
184name = "Masquerading"
185reference = "https://attack.mitre.org/techniques/T1036/"
186[[rule.threat.technique.subtechnique]]
187id = "T1036.005"
188name = "Match Legitimate Resource Name or Location"
189reference = "https://attack.mitre.org/techniques/T1036/005/"
190
191[rule.threat.tactic]
192id = "TA0005"
193name = "Defense Evasion"
194reference = "https://attack.mitre.org/tactics/TA0005/"

Triage and analysis

Investigating Potential Masquerading as Svchost

Possible investigation steps

  • Does the alert confirm a service-host-like name running from a noncanonical path?

    • Focus: process.name, process.executable, process.command_line, process.parent.executable, and host.id, comparing the path with C:\Windows\System32\svchost.exe and C:\Windows\SysWOW64\svchost.exe.
    • Hint: use process.entity_id, hash, and signer fields where present; if enrichments are missing, keep the gap unresolved and scope by host.id, path, and alert time.
    • Implication: escalate when svchost.exe or a near-match runs from a user-writable, temp, share-backed, or product-mismatched path; lower concern only when a recognized lab, build-test, or recovery workflow also fits later evidence.
  • Is the file identity or rename timing consistent with Microsoft Service Host?

    • Focus: process.hash.sha256, process.pe.original_file_name, process.code_signature.*, rename timing, and file events for the same path. $investigate_0
    • Implication: escalate for an unfamiliar hash, unsigned/untrusted or non-Microsoft signer, recent rename, or original filename conflict; Microsoft identity and stable name timing reduce identity concern but do not clear the noncanonical path.
  • Does the launch context fit service-controlled svchost.exe behavior?

    • Focus: process.parent.name, process.parent.executable, process.parent.command_line, process.command_line, and session context, checking for services.exe and service grouping arguments such as -k <group> or -s <service>.
    • Implication: escalate when the parent is a shell, script engine, Office process, archive tool, or user-run utility, when service-group arguments are absent, or when context is interactive; services.exe plus service grouping lowers launch-context concern, but the noncanonical path still needs explanation.
  • Does this process instance behave like a launcher rather than a passive service host?

    • Focus: child starts where process.parent.entity_id matches process.entity_id, especially child process.name, process.executable, and process.command_line. $investigate_1
    • Hint: use process.Ext.ancestry only as a deeper fallback when direct parent-child lineage is missing or incomplete.
    • Implication: escalate when it spawns shells, script engines, admin tools, installers, additional lookalikes, or short-lived command chains; absent or service-like child activity narrows launcher risk but does not close the name/path anomaly.
  • If local findings remain suspicious or unresolved, does related alert scope show reuse of the same masquerading path?

    • Focus: related alerts for the same process.executable or process.hash.sha256, comparing host.id and user.id where available. $investigate_2 $investigate_3
    • Implication: broaden scope and raise urgency when the same path or hash appears on other hosts, users, or alert types; keep local only when related alerts are absent and all local evidence supports one recognized lab, build, or recovery workflow.
  • Escalate when the path anomaly plus identity, lineage, timing, child-process, or scope evidence points to masquerading or broader compromise; close only when path, identity, launch context, and bounded host/user scope prove one recognized lab, build, or recovery workflow; if telemetry cannot prove legitimacy, preserve artifacts and escalate.

False positive analysis

  • Controlled malware-analysis, image-build, or recovery testing can stage a service-host-like file outside canonical Windows paths. Confirm by aligning identity (process.hash.sha256, process.pe.original_file_name, signer trust/subject), launch context (process.parent.executable, process.parent.command_line, process.command_line), and scope (host.id, host.name, user.id). Without outside records, close only when process fields prove the controlled workflow.
  • Treat a noncanonical svchost.exe name as suspicious until process evidence proves one complete benign workflow; a trusted Microsoft signer, familiar parent, or single quiet execution is not enough when the path or name still mimics Service Host.
  • Before creating an exception, require recurring process.executable, process.hash.sha256, signer subject, parent executable, command-line shape, and host.id or controlled host cohort across prior alerts from this rule. Avoid exceptions on process.name, svchost.exe, user.name, or a host alone.

Response and remediation

  • If confirmed benign, reverse any temporary containment and record the exact workflow evidence: process.executable, process.hash.sha256, process.code_signature.subject_name, process.parent.executable, process.command_line, host.id, and the controlled lab, build, or recovery scope. Create an exception only after the same evidence pattern recurs.
  • If suspicious but unconfirmed, preserve the alert, source process event, recovered process.entity_id, process.executable, process.hash.sha256, signature metadata, parent context, command line, and related-alert results before containment. Apply reversible controls first, such as heightened monitoring or temporary network restrictions for the affected host.id, and avoid termination or deletion until scope is clearer.
  • If confirmed malicious, first preserve the recovered process.entity_id, command line, child-process list, path evidence, and forensic package for process.executable. Finish same-path and same-hash scoping, then isolate the endpoint when host criticality allows, terminate only the suspicious noncanonical service-host process, and remove the masquerading executable or launcher artifacts. Do not stop canonical Service Host instances unless that exact instance is proven malicious.
  • After containment, restore any affected service-host component from known-good media if a legitimate file was replaced, restrict execution from user-writable or share-backed paths where feasible, and document the recovered command-line and parent-chain pattern that separated this fake service host from normal services.exe-launched instances.

Related rules

to-top