sigma-rules/rules/windows/impact_modification_of_boot_config.toml

[metadata]
creation_date = "2020/03/16"
maturity = "production"
updated_date = "2022/03/31"

[rule]
author = ["Elastic"]
description = """
Identifies use of bcdedit.exe to delete boot configuration data. This tactic is sometimes used as by malware or an
attacker as a destructive technique.
"""
from = "now-9m"
index = ["winlogbeat-*", "logs-endpoint.events.*", "logs-windows.*"]
language = "eql"
license = "Elastic License v2"
name = "Modification of Boot Configuration"
note = """## Triage and analysis

### Investigating Modification of Boot Configuration

Boot entry parameters, or boot parameters, are optional, system-specific settings that represent configuration options.
These are stored in a boot configuration data (BCD) store, and administrators can use utilities like `bcdedit.exe` to
configure these.

This rule identifies the usage of `bcdedit.exe` to:

- Disable Windows Error Recovery (recoveryenabled).
- Ignore errors if there is a failed boot, failed shutdown, or failed checkpoint (bootstatuspolicy ignoreallfailures).

These are common steps in destructive attacks by adversaries leveraging ransomware.

#### Possible investigation steps

- Investigate the script execution chain (parent process tree).
- Identify the user account that performed the action and whether it should perform this kind of action.
- Confirm whether the account owner is aware of the operation.
- Investigate other alerts related to the user/host in the last 48 hours.
- Check for similar behavior in other hosts in the environment.
- Check if any files on the host machine have been encrypted.

### False positive analysis

- The usage of these options is not inherently malicious. Administrators can modify these configurations to force a
machine to boot for troubleshooting or data recovery purposes.

### Related rules

- Deleting Backup Catalogs with Wbadmin - 581add16-df76-42bb-af8e-c979bfb39a59

### Response and remediation

- Initiate the incident response process based on the outcome of the triage.
- Isolate the involved host to prevent destructive behavior, which is commonly associated with this activity.
- Reset the password of the involved accounts.
- If any other destructive action was identified on the host, it is recommended to prioritize the investigation and look
for ransomware preparation and execution activities.

## Config

If enabling an EQL rule on a non-elastic-agent index (such as beats) for versions <8.2, events will not define `event.ingested` and default fallback for EQL rules was not added until 8.2, so you will need to add a custom pipeline to populate `event.ingested` to @timestamp for this rule to work.
"""
risk_score = 21
rule_id = "69c251fb-a5d6-4035-b5ec-40438bd829ff"
severity = "low"
tags = ["Elastic", "Host", "Windows", "Threat Detection", "Impact"]
timestamp_override = "event.ingested"
type = "eql"

query = '''
process where event.type in ("start", "process_started") and
  (process.name : "bcdedit.exe" or process.pe.original_file_name == "bcdedit.exe") and
  (process.args : "/set" and process.args : "bootstatuspolicy" and process.args : "ignoreallfailures") or
  (process.args : "no" and process.args : "recoveryenabled")
'''


[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1490"
name = "Inhibit System Recovery"
reference = "https://attack.mitre.org/techniques/T1490/"


[rule.threat.tactic]
id = "TA0040"
name = "Impact"
reference = "https://attack.mitre.org/tactics/TA0040/"