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, and process.executable.
    • 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.
  • Is the modifying process consistent with servicing, repair, recovery, or rollback?

    • Focus: same-process process.executable, process.command_line, process.code_signature.subject_name, and process.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.
  • What launch chain led to the boot-file modification or deletion?

    • Focus: same-host process lineage with process.parent.executable and process.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.
  • Does the user or service context fit legitimate maintenance?

    • Focus: user.id, user.name, user.domain, and process.Ext.session_info.logon_type.
    • Hint: read process.Ext.session_info.logon_type from 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.
  • Did the same process touch other boot, recovery, or protected OS files?

    • 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
    • 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.
  • 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, and event.type for 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.
  • 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.id remains 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.
  • 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, 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.
  • 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.

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

to-top