Potential System Tampering via File Modification
Identifies attempts to delete or modify critical files used during the boot process to prevent the system from booting. This may indicate a destructive attack behavior.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2025/09/01"
3integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"]
4maturity = "production"
5updated_date = "2026/05/03"
6
7[rule]
8author = ["Elastic"]
9description = """
10Identifies attempts to delete or modify critical files used during the boot process to prevent the system from booting.
11This may indicate a destructive attack behavior.
12"""
13from = "now-9m"
14index = [
15 "winlogbeat-*",
16 "logs-endpoint.events.file-*",
17 "logs-windows.sysmon_operational-*",
18 "endgame-*",
19 "logs-m365_defender.event-*",
20 "logs-sentinel_one_cloud_funnel.*",
21]
22language = "eql"
23license = "Elastic License v2"
24name = "Potential System Tampering via File Modification"
25risk_score = 73
26rule_id = "1a3f2a4c-12d0-4b88-961a-2711ee295637"
27severity = "high"
28tags = [
29 "Domain: Endpoint",
30 "OS: Windows",
31 "Use Case: Threat Detection",
32 "Tactic: Impact",
33 "Data Source: Elastic Endgame",
34 "Resources: Investigation Guide",
35 "Data Source: Elastic Defend",
36 "Data Source: Sysmon",
37 "Data Source: Microsoft Defender XDR",
38 "Data Source: SentinelOne",
39]
40timestamp_override = "event.ingested"
41type = "eql"
42
43query = '''
44file where host.os.type == "windows" and event.type in ("change", "deletion") and
45 file.name : ("winload.exe", "winload.efi", "ntoskrnl.exe", "bootmgr") and
46 file.path : ("?:\\Windows\\*", "\\Device\\HarddiskVolume*\\Windows\\*") and
47 not process.executable : (
48 "?:\\Windows\\System32\\poqexec.exe",
49 "?:\\Windows\\System32\\wbengine.exe",
50 "?:\\Windows\\WinSxS\\???64_microsoft-windows-servicingstack_*\\tiworker.exe"
51 ) and
52 not file.path : (
53 "?:\\Windows\\WinSxS\\Temp\\InFlight\\*",
54 "?:\\Windows\\SoftwareDistribution\\Download*",
55 "?:\\Windows\\WinSxS\\amd64_microsoft-windows*",
56 "?:\\Windows\\SystemTemp\\*",
57 "?:\\Windows\\Temp\\????????.???\\*",
58 "?:\\Windows\\Temp\\*\\amd64_microsoft-windows-*",
59 "\\Device\\HarddiskVolume*\\Windows\\SoftwareDistribution\\Download*",
60 "?:\\Windows\\Temp\\BootImages\\{*}\\mount\\Windows\\*"
61 )
62'''
63
64note = """## Triage and analysis
65
66### Investigating Potential System Tampering via File Modification
67
68#### Possible investigation steps
69
70- Does the alert-local file event show modification or deletion of an active boot-critical file?
71 - Focus: `file.path`, `file.name`, `event.type`, `event.action`, and `process.executable`.
72 - Implication: escalate on deletion or active Windows System32, Windows Boot, or EFI boot paths for `winload.exe`, `winload.efi`, `ntoskrnl.exe`, or `bootmgr`; lower concern only when path normalization or surrounding file evidence shows repair content, not active boot content.
73- Is the modifying process consistent with servicing, repair, recovery, or rollback?
74 - Focus: same-process `process.executable`, `process.command_line`, `process.code_signature.subject_name`, and `process.code_signature.trusted`. $investigate_0
75 - Hint: if the transform is ambiguous or empty, recover the process start with `host.id`, `process.pid`, and alert time before judging identity.
76 - Implication: escalate when the binary is unsigned or untrusted, runs from a user-writable or unexpected path, or uses non-servicing commands; a trusted Microsoft or vendor identity lowers concern only when behavior and lineage also fit.
77- What launch chain led to the boot-file modification or deletion?
78 - Focus: same-host process lineage with `process.parent.executable` and `process.parent.command_line`.
79 - Implication: escalate when the chain includes script hosts, remote-management tooling, document launchers, or unexplained intermediaries before the write; lower concern when lineage resolves to a bounded same-host servicing or recovery workflow.
80- Does the user or service context fit legitimate maintenance?
81 - Focus: `user.id`, `user.name`, `user.domain`, and `process.Ext.session_info.logon_type`.
82 - Hint: read `process.Ext.session_info.logon_type` from the same process event used for identity.
83 - Implication: escalate when an interactive or remote user session modifies boot files directly, or when account context does not match repair duties; if session details are unavailable, do not close on user context alone.
84- Did the same process touch other boot, recovery, or protected OS files?
85 - Focus: same-process file telemetry on `host.id` and `process.entity_id`: `file.path`, `event.type`, `event.action`, and rename details for renames. $investigate_1
86 - Hint: if the pivot is ambiguous, constrain it with `host.id`, `process.pid`, and alert time before interpreting file spread.
87 - Implication: escalate when the process modifies multiple boot-related or protected files, renames content into executable extensions, or spreads outside the original target; lower concern when activity stays bounded to the exact repair set.
88- Did the same process or host also inhibit recovery or show broader destructive behavior?
89 - Focus: surrounding process and file telemetry on `host.id`: `process.executable`, `process.command_line`, `file.path`, and `event.type` for shadow-copy, backup, boot-configuration, or WinRE changes. $investigate_2
90 - Implication: escalate when boot-file tampering is paired with vssadmin, wbadmin, diskshadow, bcdedit, REAgentC, or wmic activity that disables recovery, deletes backups, or damages protected paths; lower concern only when this step finds no recovery-control change, backup deletion, or protected-path spread.
91- If the local findings remain suspicious or unresolved, is the pattern isolated or broader for the same host or user?
92 - Focus: related destructive or recovery-inhibition alerts for the same `host.id`: boot-file tampering, shadow-copy deletion, backup deletion, service disruption, or protected-file modification. $investigate_3
93 - Hint: if `user.id` remains relevant, compare related destructive alerts for that user separately. $investigate_4
94 - Implication: escalate scope when the same host or user shows multiple destructive or recovery-control alerts in a short window; keep the case localized only when this is a single bounded event and local evidence resolves cleanly.
95
96- Escalate when file target, actor identity, lineage, session, protected-file spread, recovery-control, or related alerts point to unauthorized boot tampering; close only when evidence binds one recognized repair, recovery, servicing, or rollback workflow on this host with no contradictory spread; if mixed or incomplete, preserve artifacts and escalate.
97
98### False positive analysis
99
100- Offline repair, OEM recovery, Windows servicing, administrator-led boot remediation, or security/backup rollback can replace boot files. Confirm `process.executable`, signer, command line, user or service context, `file.path`, and `event.type` bind to one recognized workflow, stay bounded to the expected repair set, and do not branch into script hosts, unusual parents, protected-file damage, shadow-copy deletion, backup deletion, or boot-configuration tampering. Without change records, require the same signed repair or rollback binary, service or recovery context, protected path family, and no destructive or recovery-control activity on the same `host.id`.
101- Before creating an exception, anchor it on the narrowest stable pattern: `process.executable`, `process.code_signature.subject_name`, `file.path`, and the expected `user.id` or service context. Do not except on `process.name`, `file.name`, or Windows-path activity alone.
102
103### Response and remediation
104
105- If confirmed benign, reverse any temporary containment and record the repair, recovery, servicing, or rollback workflow that matched the process identity, signer, service context, and protected path set. Create an exception only after the same bounded pattern recurs.
106- If suspicious but unconfirmed, preserve the alert event, process-start record, Timeline or case export for the modifying process, boot-file metadata or available copies, recovered binary identity, lineage/session evidence, and any recovery-control or protected-file findings before containment or cleanup.
107- If suspicious but unconfirmed and the host is still online, avoid reboot until boot-file evidence is preserved. Apply reversible containment tied to the findings, such as blocking the remote administration path, disabling the active account session, or isolating the host if protected-file modification or recovery inhibition continues. Weigh host criticality before isolation.
108- If confirmed malicious, isolate the host through endpoint response when boot-file tampering, actor identity, lineage, or recovery-control evidence establishes unauthorized activity. Terminate the offending process only after preserving its entity ID, command line, affected path list, and recovered hashes. If direct response is unavailable, hand off the same evidence to the team that can isolate the host or disk.
109- Review related hosts and users for the same destructive pattern before restoring files so scoping finishes before evidence is destroyed.
110- Restore affected boot files only from trusted media, golden images, or known-good backups after destructive scope is understood, then repair any WinRE, shadow-copy, backup, or boot-configuration controls the attacker disabled.
111- Post-incident hardening: retain file and process telemetry for protected boot paths, restrict who can run repair tooling on critical systems, protect backups from the same account path, and record adjacent destructive behaviors in the case notes."""
112
113setup = """## Setup
114
115This 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.
116
117Setup instructions: https://ela.st/install-elastic-defend
118
119### Additional data sources
120
121This rule also supports the following third-party data sources. For setup instructions, refer to the links below:
122
123- [Microsoft Defender XDR](https://ela.st/m365-defender)
124- [SentinelOne Cloud Funnel](https://ela.st/sentinel-one-cloud-funnel)
125- [Sysmon Event ID 11 - File Create](https://ela.st/sysmon-event-11-setup)
126- [Sysmon Event ID 23 - File Delete](https://ela.st/sysmon-event-23-setup)
127"""
128
129[rule.investigation_fields]
130field_names = [
131 "@timestamp",
132 "host.id",
133 "user.id",
134 "process.entity_id",
135 "process.pid",
136 "process.executable",
137 "process.command_line",
138 "process.parent.executable",
139 "process.parent.command_line",
140 "process.code_signature.subject_name",
141 "process.code_signature.trusted",
142 "file.path",
143 "file.name",
144 "event.action",
145 "event.type",
146]
147
148[transform]
149
150[[transform.investigate]]
151label = "Events for the modifying process on this host"
152description = ""
153providers = [
154 [
155 { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
156 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
157 ],
158 [
159 { excluded = false, field = "process.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" },
160 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
161 ]
162]
163relativeFrom = "now-1h"
164relativeTo = "now"
165
166[[transform.investigate]]
167label = "File events for the modifying process"
168description = ""
169providers = [
170 [
171 { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
172 { excluded = false, field = "process.entity_id", queryType = "phrase", value = "{{process.entity_id}}", valueType = "string" },
173 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
174 ],
175 [
176 { excluded = false, field = "event.category", queryType = "phrase", value = "file", valueType = "string" },
177 { excluded = false, field = "process.pid", queryType = "phrase", value = "{{process.pid}}", valueType = "string" },
178 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
179 ]
180]
181relativeFrom = "now-1h"
182relativeTo = "now"
183
184[[transform.investigate]]
185label = "Process events on the host near the modification"
186description = ""
187providers = [
188 [
189 { excluded = false, field = "event.category", queryType = "phrase", value = "process", valueType = "string" },
190 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
191 ]
192]
193relativeFrom = "now-1h"
194relativeTo = "now"
195
196[[transform.investigate]]
197label = "Alerts associated with the host"
198description = ""
199providers = [
200 [
201 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
202 { excluded = false, field = "host.id", queryType = "phrase", value = "{{host.id}}", valueType = "string" }
203 ]
204]
205relativeFrom = "now-48h/h"
206relativeTo = "now"
207
208[[transform.investigate]]
209label = "Alerts associated with the user"
210description = ""
211providers = [
212 [
213 { excluded = false, field = "event.kind", queryType = "phrase", value = "signal", valueType = "string" },
214 { excluded = false, field = "user.id", queryType = "phrase", value = "{{user.id}}", valueType = "string" }
215 ]
216]
217relativeFrom = "now-48h/h"
218relativeTo = "now"
219
220[[rule.threat]]
221framework = "MITRE ATT&CK"
222
223[[rule.threat.technique]]
224id = "T1485"
225name = "Data Destruction"
226reference = "https://attack.mitre.org/techniques/T1485/"
227
228[[rule.threat.technique]]
229id = "T1490"
230name = "Inhibit System Recovery"
231reference = "https://attack.mitre.org/techniques/T1490/"
232
233[rule.threat.tactic]
234id = "TA0040"
235name = "Impact"
236reference = "https://attack.mitre.org/tactics/TA0040/"
Triage and analysis
Investigating Potential System Tampering via File Modification
Possible investigation steps
-
Does the alert-local file event show modification or deletion of an active boot-critical file?
- Focus:
file.path,file.name,event.type,event.action, andprocess.executable. - Implication: escalate on deletion or active Windows System32, Windows Boot, or EFI boot paths for
winload.exe,winload.efi,ntoskrnl.exe, orbootmgr; lower concern only when path normalization or surrounding file evidence shows repair content, not active boot content.
- Focus:
-
Is the modifying process consistent with servicing, repair, recovery, or rollback?
- Focus: same-process
process.executable,process.command_line,process.code_signature.subject_name, andprocess.code_signature.trusted. $investigate_0 - Hint: if the transform is ambiguous or empty, recover the process start with
host.id,process.pid, and alert time before judging identity. - Implication: escalate when the binary is unsigned or untrusted, runs from a user-writable or unexpected path, or uses non-servicing commands; a trusted Microsoft or vendor identity lowers concern only when behavior and lineage also fit.
- Focus: same-process
-
What launch chain led to the boot-file modification or deletion?
- Focus: same-host process lineage with
process.parent.executableandprocess.parent.command_line. - Implication: escalate when the chain includes script hosts, remote-management tooling, document launchers, or unexplained intermediaries before the write; lower concern when lineage resolves to a bounded same-host servicing or recovery workflow.
- Focus: same-host process lineage with
-
Does the user or service context fit legitimate maintenance?
- Focus:
user.id,user.name,user.domain, andprocess.Ext.session_info.logon_type. - Hint: read
process.Ext.session_info.logon_typefrom the same process event used for identity. - Implication: escalate when an interactive or remote user session modifies boot files directly, or when account context does not match repair duties; if session details are unavailable, do not close on user context alone.
- Focus:
-
Did the same process touch other boot, recovery, or protected OS files?
- Focus: same-process file telemetry on
host.idandprocess.entity_id:file.path,event.type,event.action, and rename details for renames. $investigate_1 - Hint: if the pivot is ambiguous, constrain it with
host.id,process.pid, and alert time before interpreting file spread. - Implication: escalate when the process modifies multiple boot-related or protected files, renames content into executable extensions, or spreads outside the original target; lower concern when activity stays bounded to the exact repair set.
- Focus: same-process file telemetry on
-
Did the same process or host also inhibit recovery or show broader destructive behavior?
- Focus: surrounding process and file telemetry on
host.id:process.executable,process.command_line,file.path, andevent.typefor shadow-copy, backup, boot-configuration, or WinRE changes. $investigate_2 - Implication: escalate when boot-file tampering is paired with vssadmin, wbadmin, diskshadow, bcdedit, REAgentC, or wmic activity that disables recovery, deletes backups, or damages protected paths; lower concern only when this step finds no recovery-control change, backup deletion, or protected-path spread.
- Focus: surrounding process and file telemetry on
-
If the local findings remain suspicious or unresolved, is the pattern isolated or broader for the same host or user?
- Focus: related destructive or recovery-inhibition alerts for the same
host.id: boot-file tampering, shadow-copy deletion, backup deletion, service disruption, or protected-file modification. $investigate_3 - Hint: if
user.idremains relevant, compare related destructive alerts for that user separately. $investigate_4 - Implication: escalate scope when the same host or user shows multiple destructive or recovery-control alerts in a short window; keep the case localized only when this is a single bounded event and local evidence resolves cleanly.
- Focus: related destructive or recovery-inhibition alerts for the same
-
Escalate when file target, actor identity, lineage, session, protected-file spread, recovery-control, or related alerts point to unauthorized boot tampering; close only when evidence binds one recognized repair, recovery, servicing, or rollback workflow on this host with no contradictory spread; if mixed or incomplete, preserve artifacts and escalate.
False positive analysis
- Offline repair, OEM recovery, Windows servicing, administrator-led boot remediation, or security/backup rollback can replace boot files. Confirm
process.executable, signer, command line, user or service context,file.path, andevent.typebind to one recognized workflow, stay bounded to the expected repair set, and do not branch into script hosts, unusual parents, protected-file damage, shadow-copy deletion, backup deletion, or boot-configuration tampering. Without change records, require the same signed repair or rollback binary, service or recovery context, protected path family, and no destructive or recovery-control activity on the samehost.id. - Before creating an exception, anchor it on the narrowest stable pattern:
process.executable,process.code_signature.subject_name,file.path, and the expecteduser.idor service context. Do not except onprocess.name,file.name, or Windows-path activity alone.
Response and remediation
- If confirmed benign, reverse any temporary containment and record the repair, recovery, servicing, or rollback workflow that matched the process identity, signer, service context, and protected path set. Create an exception only after the same bounded pattern recurs.
- If suspicious but unconfirmed, preserve the alert event, process-start record, Timeline or case export for the modifying process, boot-file metadata or available copies, recovered binary identity, lineage/session evidence, and any recovery-control or protected-file findings before containment or cleanup.
- If suspicious but unconfirmed and the host is still online, avoid reboot until boot-file evidence is preserved. Apply reversible containment tied to the findings, such as blocking the remote administration path, disabling the active account session, or isolating the host if protected-file modification or recovery inhibition continues. Weigh host criticality before isolation.
- If confirmed malicious, isolate the host through endpoint response when boot-file tampering, actor identity, lineage, or recovery-control evidence establishes unauthorized activity. Terminate the offending process only after preserving its entity ID, command line, affected path list, and recovered hashes. If direct response is unavailable, hand off the same evidence to the team that can isolate the host or disk.
- Review related hosts and users for the same destructive pattern before restoring files so scoping finishes before evidence is destroyed.
- Restore affected boot files only from trusted media, golden images, or known-good backups after destructive scope is understood, then repair any WinRE, shadow-copy, backup, or boot-configuration controls the attacker disabled.
- Post-incident hardening: retain file and process telemetry for protected boot paths, restrict who can run repair tooling on critical systems, protect backups from the same account path, and record adjacent destructive behaviors in the case notes.
Related rules
- Volume Shadow Copy Deleted or Resized via VssAdmin
- Volume Shadow Copy Deletion via PowerShell
- Volume Shadow Copy Deletion via WMIC
- Backup Deletion with Wbadmin
- Modification of Boot Configuration