Boot configuration tampering

Threat snapshot

The Windows boot configuration controls how the operating system starts, which recovery options are available, and how the system behaves when it encounters an error. These settings are managed through the Boot Configuration Data (BCD) store and through a set of registry keys under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager. When an attacker modifies these keys, they are not simply making a configuration change. They are altering the conditions under which the system recovers, potentially disabling safe mode access, removing recovery options, or ensuring that a destructive payload can run without interference from Windows recovery mechanisms.

Ransomware operators in particular have made boot configuration tampering a standard pre-deployment step. By modifying boot registry keys before encrypting files, they ensure that an infected system cannot be booted into safe mode for recovery, cannot load recovery tools from the Windows Recovery Environment, and may not be able to restore from a shadow copy. Log360 detects this activity through the Registry Boot Key Altered rule, which fires whenever monitored boot configuration registry values are modified. Any alert from this rule warrants immediate investigation because boot key modifications outside a documented maintenance context have very few legitimate explanations.

At a glance

How this attack works

Windows boot behaviour is controlled by a combination of the BCD store and registry keys under the Session Manager path. The registry keys most commonly targeted by attackers are:

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\BootExecute
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\SetupExecute
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Execute
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\S0InitialCommand

The BootExecute value specifies programs that run before the Windows session manager fully initialises. Its default value is autocheck autochk *, which runs the file system check utility. Modifying this value allows an attacker to insert a program that runs at the earliest stage of the boot process, before most security controls, antivirus drivers, or endpoint protection tools have loaded. A payload placed in BootExecute runs with kernel-level timing and is extremely difficult to detect or remove from a running system.

The SetupExecute and Execute values serve similar purposes for different boot phases. S0InitialCommand specifies a command that runs during early system initialisation in specific boot scenarios. All four are valuable to attackers because they provide code execution at boot time, with the system in a partially initialised state where fewer defensive controls are active.

Beyond these execution values, ransomware operators also use the bcdedit.exe command-line tool to modify the BCD store directly, disabling Windows Error Recovery, removing the recovery boot menu, and setting the boot status policy to ignore all failures. These bcdedit changes prevent the system from offering a recovery boot option when it detects that files have been encrypted and the system cannot start normally. The Registry Boot Key Altered rule targets the registry-level component of this technique.

The ransomware connection

Boot configuration tampering is a documented pre-deployment step in the operational playbooks of multiple ransomware families including Conti, LockBit, BlackCat, and REvil. These operators modify boot keys before encrypting files so that victims cannot boot into safe mode to run recovery tools, cannot use the Windows Recovery Environment to restore files, and cannot access the system through any mechanism that would allow them to bypass the encryption. Detecting the registry boot key modification is detecting the ransomware operator in the preparation phase, before the encryption runs.

Attack chain

The table below maps each stage of a boot configuration tampering attack to the corresponding MITRE ATT&CK technique.

Real-world scenario

A managed services provider operates a Windows Server environment serving multiple clients from a shared infrastructure. An attacker who gained access via a compromised RDP credential has been moving laterally across the environment for 36 hours. Having identified the backup server, several file servers, and the domain controller, the attacker begins the pre-deployment preparation phase of a ransomware attack.

Using a script that runs as SYSTEM via a previously planted scheduled task, the attacker executes two registry modifications on each target host: modifying the BootExecute value under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager to append a reference to a dropper binary, and modifying the SetupExecute value to reference the same binary as a secondary execution path. Simultaneously, bcdedit.exe is run with arguments to disable Windows Error Recovery and set the recovery boot policy to ignore all failures.

Log360 fires the Registry Boot Key Altered rule on each host where the modification occurs. The alerts reach the SOC queue 40 seconds after the first modification. The SOC analyst who reviews the alert recognises the Session Manager key path and escalates immediately. The incident response team isolates the affected hosts before the ransomware encryptor, which was scheduled to run two hours later, can execute. The boot key modifications are reversed, the dropper binary is removed, and the scheduled task that served as the execution vehicle is eliminated.

Why this happens
Boot configuration registry keys are rarely modified in normal enterprise operations. Unlike Run keys or scheduled tasks, which are modified regularly by software installers and update processes, the Session Manager boot execution keys have a narrow set of legitimate uses. This makes them a high signal-to-noise detection target: any modification is likely to be either a ransomware preparation step or a significant misconfiguration, both of which require immediate investigation. The challenge is that most environments have no alert configured for these keys because they are not well known outside of low-level Windows internals and threat research.

Business impact: What can go wrong

Boot configuration tampering has consequences that extend beyond the immediate modification and directly amplify the impact of subsequent attacks:

• Recovery option elimination: modifications that disable Windows Error Recovery and remove the recovery boot menu mean that when an encrypted or corrupted system attempts to boot and fails, it does not offer a recovery option. The system simply fails to start, with no path to the Windows Recovery Environment available to the end user or support team.
• Ransomware impact amplification: boot key tampering before ransomware deployment is specifically designed to maximise the damage of the encryption event. Without recovery options, the time required to restore encrypted systems increases significantly, raising the pressure on organisations to pay a ransom rather than recover independently.
• Persistent low-level code execution: a payload inserted into the BootExecute or SetupExecute value runs before most security controls initialise. It can reinstall ransomware, disable antivirus drivers, or perform other destructive actions on every boot, surviving the removal of the original ransomware binary from the file system.
• Shadow copy inaccessibility: boot configuration changes that prevent safe mode access also prevent the use of safe mode-based recovery tools that can access volume shadow copies. Combined with vssadmin shadow copy deletion, this creates a situation where no local recovery mechanism is available.
• Extended recovery time: restoring boot configuration on a large number of affected hosts requires either booting from external media to access the BCD store offline, or using remote management tools to modify the registry before the next boot. At scale, this is a time-consuming and resource-intensive recovery process.
• Compliance failure: for environments subject to availability and integrity requirements under PCI DSS, HIPAA, or ISO 27001, a successful boot configuration tampering attack that results in extended system unavailability constitutes a control failure with potential breach notification and audit implications.

Indicators of compromise and detection signals

Prerequisites for detection using Log360

Before the Registry Boot Key Altered rule can fire reliably, ensure the following are in place:

• Sysmon is deployed on all monitored endpoints with a configuration capturing Event ID 13 (Registry Value Set) for the Session Manager boot key paths. The Sysmon configuration must explicitly include all four key paths: BootExecute, SetupExecute, Execute, and S0InitialCommand under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager.
• Windows Process Creation auditing with command-line logging is enabled, generating Event ID 4688 with the full ProcessCommandLine field. This is required to detect the bcdedit.exe recovery-disabling commands that typically accompany registry boot key modifications as part of the same attack preparation sequence.
• Windows Object Access auditing for the registry is enabled to generate Event ID 4657 as a supplementary audit record for the Session Manager key modifications. This provides an independent Windows kernel-level record separate from the Sysmon driver.
• Endpoint agents or Windows Event Forwarding are configured to forward Security and Sysmon logs from all monitored endpoints to Log360 in near-real-time. Boot key modifications are pre-deployment preparation steps, meaning the window between the modification and the payload execution may be short. Prompt log forwarding is essential for the alert to reach the SOC while there is still time to intervene.

Note
The Registry Boot Key Altered rule fires on the registry modification itself, not on the payload that may have been inserted into the boot path. This means the alert provides advance warning before any boot-level code runs. Acting on this alert quickly is the primary mechanism for preventing the boot-level persistence from activating. If the affected system is rebooted before the boot key modification is reversed, any code inserted into BootExecute or SetupExecute will execute during the next boot cycle.

Detecting boot configuration tampering using Log360

Once log collection is configured, follow these steps to enable and tune detection in Log360:

Step 1: Enable the detection rule

Navigate to Security > Manage Rules > Rule Library in the Log360 console. Install and enable the rule: Registry Boot Key Altered. Configure an alert profile for the same. Set the severity to Critical and configure immediate SOC queue notification. Boot key modifications have very few legitimate explanations in normal enterprise operations and any alert from this rule should be treated as high priority until ruled out.

Step 2: Tune the rule for your environment

After enabling the rule, review the following:

• Identify any legitimate software in your environment that modifies these boot keys. Disk encryption products, some backup agents, and certain endpoint protection tools write to these keys during installation. Document the specific product, the value it writes, the process that makes the write, and the hosts it applies to. Create scoped exclusions covering that exact process name and target key combination.
• Consider the scope of the rule carefully. Boot key modifications on servers are higher severity than on workstations, because servers are more likely to be targeted in the pre-deployment phase of a ransomware attack. If alerting volume requires prioritisation during the initial deployment, apply the rule to servers and domain controllers first.

Step 3: Read the alert

When the rule fires, the alert will display the hostname, the account that made the registry modification, the specific key path and value name modified, the new value data written, and the process responsible for the write. Review the value data first: any addition to BootExecute beyond autocheck autochk * is immediately suspicious. Then review the writing process: a signed disk encryption or backup installer during a documented deployment window is the primary false positive scenario. PowerShell, reg.exe, or an unrecognised binary writing to these keys is high confidence malicious.

Investigating an alert

When the Registry Boot Key Altered rule fires, an L2 analyst should work through the following steps:

• Read the modified value data immediately. Open the alert detail and identify exactly what was written to the boot key. If BootExecute now contains anything other than autocheck autochk *, identify the additional entry. If it contains a binary path or a filename that is not a documented system component, treat this as confirmed high-severity and proceed directly to containment while the investigation continues.
• Check for bcdedit.exe execution on the same host. Query Log360 for Event ID 4688 records showing bcdedit.exe on the same hostname in the same time window as the boot key alert. Look specifically for command-line arguments containing recoveryenabled No, bootstatuspolicy ignoreallfailures, or deletevalue. The combination of a registry boot key modification and bcdedit recovery disablement in the same window is strong confirmation of ransomware pre-deployment activity.
• Identify the file being referenced in the modified boot value. If BootExecute or SetupExecute was modified to reference a specific binary, locate that file on disk. Query Log360 for Sysmon Event ID 11 (File Create) on the same host to find when the file was dropped and by which process. Hash the file and verify its digital signature. An unsigned or unrecognised binary is confirmed malicious.
• Identify the process that made the registry modification. Open the Incident Workbench and trace the process responsible for the boot key write back through its parent chain. Determine whether it ran interactively, via a remote session, via a scheduled task, or via a service. A remote session from an unrecognised source IP initiating a boot key modification is the highest-confidence indicator of an active intrusion.
• Check for other ransomware preparation activity on the same host. Query Log360 for vssadmin.exe with delete shadows arguments, net share with the /delete flag, or other monitoring disablement registry modifications in the same time window. The presence of multiple pre-deployment preparation steps confirms an active ransomware campaign.
• Verify against documented administrative activity. Check the change management system for any approved maintenance, disk encryption installation, or recovery configuration change that would explain the boot key modification. If no ticket exists and the modification cannot be attributed to a known, documented process, treat it as confirmed malicious.

Escalation trigger
Escalate immediately to L3 if the BootExecute or SetupExecute value contains any entry beyond the default autocheck autochk *; if bcdedit.exe was run with recovery-disabling arguments on the same host in the same time window; if vssadmin.exe shadow copy deletion was also observed; or if the registry modification was made via a remote session from an unrecognised source IP. Do not wait for the investigation to complete before initiating host isolation if any of these conditions are present.

Responding and remediating

Immediate containment

• Isolate the affected host immediately using EDR host isolation or by disabling the network adapter. Boot key modifications in a ransomware context are made immediately before encryption deployment. Isolation prevents the encryptor from reaching additional hosts via the network while the investigation proceeds.
• Do not reboot the affected host until the boot key modification has been reversed and any referenced binary has been removed. If the system is rebooted while a malicious entry exists in BootExecute or SetupExecute, the referenced code will execute during the next boot cycle before security controls initialise.
• Reverse the boot key modification immediately. Restore the BootExecute value to its default: autocheck autochk *. Remove any entries from SetupExecute, Execute, or S0InitialCommand that cannot be attributed to documented, authorised software. Use reg.exe or PowerShell Set-ItemProperty remotely if the host has not yet been isolated via network.
• If bcdedit.exe was used to disable recovery, restore the recovery configuration: run bcdedit /set {default} recoveryenabled Yes and bcdedit /set {default} bootstatuspolicy DisplayAllFailures to restore the default recovery behaviour.

Forensic preservation

• Export the Windows Security event log and Sysmon operational log from the affected host before any remediation. These logs contain the full sequence of boot key modifications, any associated bcdedit executions, file creation events, and the account and session context for each action.
• Preserve a copy of any binary referenced in the modified boot key values before removing it from disk. Hash the file, document its path and creation timestamp, and submit it to a sandbox environment for behavioural analysis.
• Document the exact modified state of all four boot key values and the BCD store before restoring them to their defaults. This information is required for the incident record and may be needed if the modification was part of a broader campaign affecting multiple hosts.

Eradication and recovery

• Scan all other endpoints in the environment for the same boot key modifications. Query Log360 for Registry Boot Key Altered alerts across all agents in the preceding 24 hours. Run a targeted scan of all managed hosts to compare the current BootExecute and SetupExecute values against the documented baseline.
• Review all persistence mechanisms on the affected host in addition to the boot key modification: scheduled tasks, services, Run keys, AppCertDlls entries, and startup folder contents. An attacker who modified boot keys likely established secondary persistence mechanisms in the same session.
• Rotate credentials for all accounts that had active sessions on the affected host during the incident window. Boot key modification requires SYSTEM or local administrator access. Determine how the attacker obtained that access and rotate the credentials used to do so, as well as all credentials accessible from the compromised session.

False positive guidance

The Session Manager boot keys are modified infrequently in normal enterprise operations. False positives are uncommon and typically attributable to one of the following scenarios:

• Full-disk encryption product installation: disk encryption products such as BitLocker, VeraCrypt, or third-party enterprise encryption tools may write to BootExecute or SetupExecute during initial installation to insert a pre-boot authentication component. Verify the writing process is the documented installer binary from a known vendor, the modification aligns with a change-managed installation window, and the value written references the product's documented pre-boot component path.
• Windows Update and system component installation: some Windows updates and optional feature installations modify boot execution values as part of their setup process. These modifications will occur in the context of a Windows Update session, the writing process will be a signed Windows component, and the values written will be recognisable Windows system binaries.
• Backup and disaster recovery software: some enterprise backup agents modify boot execution keys to ensure their components run early in the boot process for system state capture purposes. Verify the product, the documented value it writes, and the installation change record. Add a scoped exclusion for the specific process name and the exact value path.
• Authorised security research or testing: authorised penetration testers or internal security teams may exercise boot key modification techniques during a sanctioned assessment. Cross-reference with the test schedule and scope documentation before treating the alert as malicious. Document the test activity against the alert in the incident record.

Key differentiator

Legitimate boot key modifications are made by signed vendor installers during documented installation or update windows. The value written will be a recognisable, signed system component and will be consistent across all hosts where the same product is installed. An attacker-initiated modification will reference an unrecognised binary path, will be written by PowerShell, reg.exe, or a non-installer process, and will appear on a single host or a small cluster of targeted hosts outside any software deployment window. Any BootExecute value containing anything other than autocheck autochk * that cannot be immediately attributed to a documented disk encryption or system component is malicious until proven otherwise.

Hardening and prevention

The following controls reduce the risk of boot configuration tampering in your environment:

• Apply registry ACLs to restrict write access to the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager key and its subkeys. Limit write access to SYSTEM and documented installation service accounts only. Removing write access from interactive administrator sessions makes boot key modification significantly harder for an attacker operating under a compromised admin account.
• Deploy Sysmon with explicit registry monitoring for all four Session Manager boot key paths. Without Sysmon coverage of these specific paths, the Registry Boot Key Altered rule cannot fire. Verify the Sysmon configuration includes these paths explicitly rather than relying on a broad HKLM\SYSTEM wildcard that may generate excessive volume.
• Enable Secure Boot on all endpoints where technically feasible. Secure Boot verifies the digital signature of all boot components before allowing them to execute, preventing unsigned binaries inserted into boot paths from running even if the registry modification is not detected before the next reboot.
• Restrict execution of bcdedit.exe to documented administrative accounts via AppLocker or WDAC policies. Outside of planned recovery configuration changes and disk encryption setup, bcdedit.exe has no routine operational use on standard endpoints. Blocking its execution for non-administrative accounts eliminates the most common recovery-disabling step in ransomware pre-deployment.
• Include the boot key registry values in your configuration management baseline. A periodic automated scan comparing the current BootExecute and SetupExecute values against the documented baseline provides a detective control that catches modifications made outside the Log360 monitoring window.
• Maintain offline backup copies of the BCD store configuration for all servers and domain controllers. In the event of a successful boot configuration tampering attack, having a documented and tested recovery procedure that does not depend on the compromised system's own recovery mechanisms significantly reduces recovery time.