Suspicious Startup Shell Folder Modification
Identifies suspicious startup shell folder modifications to change the default Startup directory in order to bypass detections monitoring file creation in the Windows Startup folder.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2021/03/15"
3integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"]
4maturity = "production"
5updated_date = "2026/05/03"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies suspicious startup shell folder modifications to change the default Startup directory in order to bypass
11detections monitoring file creation in the Windows Startup folder.
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 Startup Shell Folder Modification"
26references = [
27 "https://www.elastic.co/security-labs/elastic-security-uncovers-blister-malware-campaign",
28 "https://www.elastic.co/security-labs/revisiting-blister-new-developments-of-the-blister-loader",
29]
30risk_score = 73
31rule_id = "c8b150f0-0164-475b-a75e-74b47800a9ff"
32severity = "high"
33tags = [
34 "Domain: Endpoint",
35 "OS: Windows",
36 "Use Case: Threat Detection",
37 "Tactic: Persistence",
38 "Resources: Investigation Guide",
39 "Data Source: Elastic Endgame",
40 "Data Source: Elastic Defend",
41 "Data Source: Sysmon",
42 "Data Source: Microsoft Defender XDR",
43 "Data Source: SentinelOne",
44 "Data Source: Crowdstrike",
45]
46timestamp_override = "event.ingested"
47type = "eql"
48
49query = '''
50registry where host.os.type == "windows" and event.type == "change" and
51 registry.value : ("Common Startup", "Startup") and
52 registry.path : (
53 "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Common Startup",
54 "HKLM\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Common Startup",
55 "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Startup",
56 "HKEY_USERS\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Startup",
57 "HKU\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Startup",
58 "HKU\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Startup",
59 "HKCU\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Startup",
60 "HKCU\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Startup",
61 "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Common Startup",
62 "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Common Startup",
63 "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Startup",
64 "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Startup",
65 "MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Common Startup",
66 "MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Common Startup",
67 "USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\User Shell Folders\\Startup",
68 "USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Explorer\\Shell Folders\\Startup"
69 ) and
70 registry.data.strings != null and
71 /* Normal Startup Folder Paths */
72 not registry.data.strings : (
73 "C:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Startup",
74 "%ProgramData%\\Microsoft\\Windows\\Start Menu\\Programs\\Startup",
75 "%USERPROFILE%\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup",
76 "%%USERPROFILE%%\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup",
77 "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup",
78 "\\\\*"
79 )
80'''
81
82note = """## Triage and analysis
83
84### Investigating Suspicious Startup Shell Folder Modification
85
86#### Possible investigation steps
87
88- What shell-folder scope changed, and which local path now receives Startup items?
89 - Why: `registry.value` separates per-user "Startup" from all-users "Common Startup"; all-users scope broadens persistence beyond one profile.
90 - Focus: `registry.path`, `registry.value`, `registry.hive`, `registry.data.type`, `registry.data.strings`.
91 - Implication: escalate when `registry.data.strings` points to a user-writable, hidden, deceptive, or all-users local path; lower concern here only for a recognized managed redirection target, then continue through process and user/host checks.
92
93- Which process and lineage changed the shell-folder value?
94 - Focus: `process.executable`, `process.command_line`, `process.parent.executable`, `process.parent.command_line`, `process.code_signature.subject_name`.
95 - Implication: escalate when the writer is a COM broker such as dllhost.exe, script host, LOLBin, renamed binary, user-writable executable, or unrelated parent chain; lower concern for management or packaging tooling only when command line and lineage explain this exact shell-folder write. Signed identity never clears the behavior by itself.
96
97- Was a startup artifact staged or executed from the redirected path?
98 - Why: the registry change can be setup only; persistence is proven by startup content in the redirected directory, and delayed staging or value reversion can hide the chain.
99 - Focus: same-process activity, redirected-directory file events, and command lines referencing `registry.data.strings`.
100 - $investigate_0
101 - $investigate_1
102 - $investigate_2
103 - Hint: if file telemetry is available, check file-event writes to that directory; missing file-event visibility is unresolved, not benign.
104 - Implication: escalate when the modifier or later process writes, launches, or reverts around shortcuts, scripts, or binaries in the redirected directory.
105
106- Does the creating identity and host context fit one recognized redirection workflow?
107 - Focus: `user.id`, `user.name`, `user.domain`, `host.id`, `host.name`.
108 - Implication: escalate when an interactive or ad hoc identity changes Startup resolution on a host that does not normally customize shell folders; lower concern only when identity, host cohort, path, and lineage converge on one recognized management or packaging workflow.
109
110- If local evidence is suspicious or unresolved, does same-host activity change scope?
111 - Why: sibling autostart `registry.path` changes can preserve persistence if the redirected Startup folder is noticed, restored, or cleaned.
112 - Focus: use $investigate_3 for the same `host.id`, then filter for the exact `registry.data.strings` path, sibling autostart `registry.path` changes, and process starts referencing the redirected path.
113 - Implication: broaden response when the host shows additional shell-folder or Run-key changes, execution from the redirected path, or repeated attempts to use it; keep scope local only when the pivot finds no matching autostart or execution evidence.
114
115- Do the path, process, payload-use, and context findings support startup-folder evasion?
116 - Implication: escalate for an unexpected process or actor, suspicious local path, shortcut/script/binary content, redirected-path execution, or same-host persistence/evasion; close only when telemetry narrows the case to one exact recognized workflow and outside confirmation verifies legitimacy where telemetry alone cannot; preserve and escalate when file visibility, process context, or workflow evidence is incomplete.
117
118### False positive analysis
119
120- Managed shell-folder redirection or application packaging can repoint "Startup" or "Common Startup" to a nondefault local path, but this is operationally sensitive. Treat these explanations as benign only when alert-window telemetry proves the exact redirected folder, process lineage, expected startup content, and managed host cohort all match one management or packaging job. Use deployment records, management configuration, packaging job logs, or owner confirmation when telemetry alone cannot prove legitimacy; do not close on a management label without this evidence.
121- Before exceptioning, validate recurrence of the same `registry.value`, `registry.data.strings`, `process.executable`, `process.command_line`, `process.parent.executable`, `user.id`, and `host.id` pattern after confirming the benign workflow. Build the exception from that minimum workflow, and avoid exceptions on all Startup shell-folder modifications, the whole Explorer shell-folder key family, or the rule name alone.
122
123### Response and remediation
124
125- If confirmed benign, record the exact registry path/value/data, process lineage, `user.id`, and `host.id` pattern that proved the recognized workflow, then reverse temporary containment. Keep any exception narrow and require recurrence of that same workflow.
126- If suspicious but unconfirmed, preserve the alert, Timeline or case exports, the current shell-folder value, process tree, command line, and redirected-directory contents or metadata when available before changing state. Apply reversible containment first, such as blocking execution from the redirected directory or increasing monitoring on the host. Restore the legitimate Startup path only after evidence capture, dependency review, and validation of the correct per-user or Common Startup path. Isolate the host only when payload execution or related alerts show active compromise.
127- If confirmed malicious, collect staged shortcuts, scripts, binaries, hashes, and registry evidence before eradication. Contain the endpoint when its role allows, contain the creating account when the evidence shows account misuse, validate the correct per-user or Common Startup value, restore that value, and remove only the artifacts identified in the investigation. If direct response is unavailable, escalate with the preserved evidence to the team that can act on the host.
128- Before cleanup, review other user profiles and the all-users Startup scope for the same redirected path, then verify no process execution still points to that directory. After recovery, restrict shell-folder redirection to controlled management tooling, retain registry/process and available file telemetry needed to connect redirection to later payload staging, and document delayed-staging or value-reversion blind spots for future cases.
129"""
130
131setup = """## Setup
132
133This 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.
134
135Setup instructions: https://ela.st/install-elastic-defend
136
137### Additional data sources
138
139This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
140
141- [CrowdStrike](https://ela.st/crowdstrike-integration)
142- [Microsoft Defender XDR](https://ela.st/m365-defender)
143- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
144- [Sysmon Registry Events](https://ela.st/sysmon-event-reg-setup)
145"""
146
147[rule.investigation_fields]
148field_names = [
149 "@timestamp",
150 "host.id",
151 "user.id",
152 "process.entity_id",
153 "process.pid",
154 "process.executable",
155 "process.command_line",
156 "process.parent.executable",
157 "process.parent.command_line",
158 "process.code_signature.subject_name",
159 "registry.path",
160 "registry.hive",
161 "registry.value",
162 "registry.data.type",
163 "registry.data.strings",
164]
165
166[transform]
167
168[[transform.investigate]]
169label = "Activity from this process instance on this host"
170description = ""
171providers = [
172 [
173 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
174 { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" }
175 ],
176 [
177 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
178 { excluded = false, field = "process.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" }
179 ]
180]
181relativeFrom = "now-24h/h"
182relativeTo = "now"
183
184[[transform.investigate]]
185label = "File events in the redirected Startup path"
186description = ""
187providers = [
188 [
189 { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
190 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
191 { excluded = false, field = "file.directory", queryType = "phrase", value = "{{registry.data.strings}}", valueType = "string" }
192 ]
193]
194relativeFrom = "now-24h/h"
195relativeTo = "now"
196
197[[transform.investigate]]
198label = "Process command lines referencing the redirected path"
199description = ""
200providers = [
201 [
202 { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
203 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" },
204 { excluded = false, field = "process.command_line", queryType = "phrase", value = "{{registry.data.strings}}", valueType = "string" }
205 ]
206]
207relativeFrom = "now-24h/h"
208relativeTo = "now"
209
210[[transform.investigate]]
211label = "Recent activity on this host"
212description = ""
213providers = [
214 [
215 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
216 ]
217]
218relativeFrom = "now-48h/h"
219relativeTo = "now"
220
221[[rule.threat]]
222framework = "MITRE ATT&CK"
223
224[[rule.threat.technique]]
225id = "T1547"
226name = "Boot or Logon Autostart Execution"
227reference = "https://attack.mitre.org/techniques/T1547/"
228
229[[rule.threat.technique.subtechnique]]
230id = "T1547.001"
231name = "Registry Run Keys / Startup Folder"
232reference = "https://attack.mitre.org/techniques/T1547/001/"
233
234[rule.threat.tactic]
235id = "TA0003"
236name = "Persistence"
237reference = "https://attack.mitre.org/tactics/TA0003/"
238
239[[rule.threat]]
240framework = "MITRE ATT&CK"
241
242[[rule.threat.technique]]
243id = "T1112"
244name = "Modify Registry"
245reference = "https://attack.mitre.org/techniques/T1112/"
246
247[rule.threat.tactic]
248id = "TA0005"
249name = "Defense Evasion"
250reference = "https://attack.mitre.org/tactics/TA0005/"
Triage and analysis
Investigating Suspicious Startup Shell Folder Modification
Possible investigation steps
-
What shell-folder scope changed, and which local path now receives Startup items?
- Why:
registry.valueseparates per-user "Startup" from all-users "Common Startup"; all-users scope broadens persistence beyond one profile. - Focus:
registry.path,registry.value,registry.hive,registry.data.type,registry.data.strings. - Implication: escalate when
registry.data.stringspoints to a user-writable, hidden, deceptive, or all-users local path; lower concern here only for a recognized managed redirection target, then continue through process and user/host checks.
- Why:
-
Which process and lineage changed the shell-folder value?
- Focus:
process.executable,process.command_line,process.parent.executable,process.parent.command_line,process.code_signature.subject_name. - Implication: escalate when the writer is a COM broker such as dllhost.exe, script host, LOLBin, renamed binary, user-writable executable, or unrelated parent chain; lower concern for management or packaging tooling only when command line and lineage explain this exact shell-folder write. Signed identity never clears the behavior by itself.
- Focus:
-
Was a startup artifact staged or executed from the redirected path?
- Why: the registry change can be setup only; persistence is proven by startup content in the redirected directory, and delayed staging or value reversion can hide the chain.
- Focus: same-process activity, redirected-directory file events, and command lines referencing
registry.data.strings.- $investigate_0
- $investigate_1
- $investigate_2
- Hint: if file telemetry is available, check file-event writes to that directory; missing file-event visibility is unresolved, not benign.
- Implication: escalate when the modifier or later process writes, launches, or reverts around shortcuts, scripts, or binaries in the redirected directory.
-
Does the creating identity and host context fit one recognized redirection workflow?
- Focus:
user.id,user.name,user.domain,host.id,host.name. - Implication: escalate when an interactive or ad hoc identity changes Startup resolution on a host that does not normally customize shell folders; lower concern only when identity, host cohort, path, and lineage converge on one recognized management or packaging workflow.
- Focus:
-
If local evidence is suspicious or unresolved, does same-host activity change scope?
- Why: sibling autostart
registry.pathchanges can preserve persistence if the redirected Startup folder is noticed, restored, or cleaned. - Focus: use $investigate_3 for the same
host.id, then filter for the exactregistry.data.stringspath, sibling autostartregistry.pathchanges, and process starts referencing the redirected path. - Implication: broaden response when the host shows additional shell-folder or Run-key changes, execution from the redirected path, or repeated attempts to use it; keep scope local only when the pivot finds no matching autostart or execution evidence.
- Why: sibling autostart
-
Do the path, process, payload-use, and context findings support startup-folder evasion?
- Implication: escalate for an unexpected process or actor, suspicious local path, shortcut/script/binary content, redirected-path execution, or same-host persistence/evasion; close only when telemetry narrows the case to one exact recognized workflow and outside confirmation verifies legitimacy where telemetry alone cannot; preserve and escalate when file visibility, process context, or workflow evidence is incomplete.
False positive analysis
- Managed shell-folder redirection or application packaging can repoint "Startup" or "Common Startup" to a nondefault local path, but this is operationally sensitive. Treat these explanations as benign only when alert-window telemetry proves the exact redirected folder, process lineage, expected startup content, and managed host cohort all match one management or packaging job. Use deployment records, management configuration, packaging job logs, or owner confirmation when telemetry alone cannot prove legitimacy; do not close on a management label without this evidence.
- Before exceptioning, validate recurrence of the same
registry.value,registry.data.strings,process.executable,process.command_line,process.parent.executable,user.id, andhost.idpattern after confirming the benign workflow. Build the exception from that minimum workflow, and avoid exceptions on all Startup shell-folder modifications, the whole Explorer shell-folder key family, or the rule name alone.
Response and remediation
- If confirmed benign, record the exact registry path/value/data, process lineage,
user.id, andhost.idpattern that proved the recognized workflow, then reverse temporary containment. Keep any exception narrow and require recurrence of that same workflow. - If suspicious but unconfirmed, preserve the alert, Timeline or case exports, the current shell-folder value, process tree, command line, and redirected-directory contents or metadata when available before changing state. Apply reversible containment first, such as blocking execution from the redirected directory or increasing monitoring on the host. Restore the legitimate Startup path only after evidence capture, dependency review, and validation of the correct per-user or Common Startup path. Isolate the host only when payload execution or related alerts show active compromise.
- If confirmed malicious, collect staged shortcuts, scripts, binaries, hashes, and registry evidence before eradication. Contain the endpoint when its role allows, contain the creating account when the evidence shows account misuse, validate the correct per-user or Common Startup value, restore that value, and remove only the artifacts identified in the investigation. If direct response is unavailable, escalate with the preserved evidence to the team that can act on the host.
- Before cleanup, review other user profiles and the all-users Startup scope for the same redirected path, then verify no process execution still points to that directory. After recovery, restrict shell-folder redirection to controlled management tooling, retain registry/process and available file telemetry needed to connect redirection to later payload staging, and document delayed-staging or value-reversion blind spots for future cases.
References
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 ImagePath Service Creation