MITRE ATT&CK T1688 Safe Mode Boot: Detecting Control Tampering

Rebooting a Windows host into safe mode is one of the cheapest ways to switch off endpoint protection, because safe mode starts only a minimal set of drivers and services and many security agents are not among them. MITRE ATT&CK v20 tracks this as T1688 Safe Mode Boot under the Defense Impairment tactic (TA0112), Windows only, formerly a sub-technique of Impair Defenses. Ransomware families including LockBit 3.0, Black Basta, REvil, Qilin, RansomHub, AvosLocker and Embargo are recorded using it, usually minutes before encryption. This page covers how the technique works, the boot configuration and registry changes that give it away, the two v20 mitigations, how to monitor for the agent going dark, and how to test safely. It is written for detection engineers, endpoint owners and incident responders. The REvil (Sodinokibi) profile shows the technique inside one ransomware family; this page is the technique view.

Key takeaways

• The tell is a boot configuration change. Forcing safe mode on the next boot means writing a safeboot value to the Boot Configuration Data store, most often with bcdedit /set {current} safeboot minimal or network, which needs administrator rights and is rare in normal operations.
• Persistence in safe mode is a registry write. Malware that must run after the reboot adds its service under HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal or \Network, which is a high-confidence alert.
• ATT&CK's mitigations are simple and effective. M1054 asks that endpoint defences run in safe mode; M1026 asks that the admin rights needed to do this are tightly held.
• Silence is a signal. A host that reboots and whose security agent stops reporting while the machine is still on the network should page someone, not wait for the next daily report.
• It is a late-stage ransomware step. By the time a host is forced into safe mode, the actor already has admin rights; respond as an active ransomware incident.

How the technique works

ATT&CK describes safe mode as starting Windows with a limited set of drivers and services, in two versions: Safe Mode and Safe Mode with Networking, and notes that additional services can be started after a safe mode boot. Third-party security software such as EDR may not start. Adversaries force a host into safe mode after the next reboot by modifying the Boot Configuration Data (BCD) store, and they make their own code run there by adding it to the list of minimal services through the registry (T1112 Modify Registry) or by registering a malicious COM object that is loaded in safe mode.

Research cited by ATT&CK shows the sequence. Sophos documented Snatch ransomware installing a service named SuperBackupMan, adding HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal\SuperBackupMan so it would start in safe mode, running bcdedit.exe /set {current} safeboot minimal and forcing an immediate reboot, then deleting volume shadow copies and encrypting. CyberArk Labs showed in 2016 that an attacker with local administrator rights could do the same remotely, load code through a service or a COM object loaded by explorer.exe, and tamper with security tools that did not run in Minimal Safe Mode before returning the host to normal mode.

Real cases

See the LockBit Threat Actor Profile, Black Basta Threat Actor Profile, Qilin Threat Actor Profile and RansomHub Threat Actor Profile for the wider operations.

What to detect and where

ATT&CK v20 detection strategy DET0116 (analytic AN0323) looks for boot configuration utilities (bcdedit.exe, bootcfg.exe) changing BCD, correlated with registry changes under the SafeBoot keys. The tuning elements it names are the SafeBoot registry paths, the admin tools allowed to make such changes and the time window between them.

Two cautions. First, logs written while the host is in safe mode may be incomplete or later tampered with, which CyberArk Labs also notes, so the reliable evidence is what reached your SIEM before the reboot. Second, event 4826 (Boot Configuration Data loaded) records boot settings such as test signing, kernel debugging and integrity checks, but Microsoft's documentation lists no safe mode field, so do not rely on it for this technique.

The registry and service side overlaps with MITRE ATT&CK T1112 Modify Registry and T1543 Create or Modify System Process Defensive Guide; shadow copy deletion in safe mode is T1490 Inhibit System Recovery Defensive Guide.

Mitigations

NHI Mgmt Group recommendations beyond the v20 list:

• Turn on tamper protection in your EDR: it limits changes to agent services and registry keys, which narrows what an attacker can change while in safe mode.
• Protect the SafeBoot keys: keep default permissions and monitor them; any non-vendor service added there should be investigated.
• Restrict remote service creation and remote reboot paths: limit who can use remote service control, WMI and remote shutdown to administrative tiers, which is how attackers reach many hosts at once.
• Keep offline and immutable backups: if a host does get encrypted in safe mode, recovery depends on backups the attacker could not reach.

Where identity fits

Every recorded use of T1688 needs administrator rights, and ransomware crews usually get them at scale through domain admin credentials or through service accounts used by software deployment and remote management tools, which are often local administrator everywhere. NHI Mgmt Group recommendation: inventory the non-human accounts with local admin rights across the estate, scope each to the hosts it actually manages, and alert when one of them runs bcdedit or creates a service outside its normal job. The EDR Evasion and Defence Guide covers the broader agent protection picture.

Responding to a forced safe mode boot

1. Treat it as active ransomware: invoke the ransomware playbook and check for the same command on other hosts in the last hour.
2. Isolate at the network: if the agent is offline, use switch port, NAC or firewall isolation, because EDR containment will not work.
3. Preserve evidence: collect the pre-reboot SIEM events, the SafeBoot registry hive and the BCD store from an offline copy of the disk where possible.
4. Remove the boot option and persistence: clear the safeboot value and the added SafeBoot service keys before returning the host to service, or rebuild it.
5. Rotate the credentials used: the admin or service account that ran bcdedit is compromised.

How to test

1. Use a lab VM with a snapshot: never test on production endpoints.
2. Set and clear the option without rebooting: run bcdedit /set {current} safeboot minimal, confirm the alert, then bcdedit /deletevalue {current} safeboot. This exercises the detection without taking the host down.
3. Add and remove a test SafeBoot key: create a harmless subkey under SafeBoot\Minimal, confirm Sysmon 12 and the alert, then delete it.
4. Test agent behaviour in safe mode: on the lab VM, boot into Safe Mode with Networking and confirm whether your EDR loads, reports and blocks a test action. Record the result as evidence for M1054.
5. Test the heartbeat rule: reboot the lab VM into safe mode and confirm the agent-offline alert fires within your target time.
6. Roll back: restore the snapshot and confirm the BCD store no longer contains a safeboot value.

Measuring coverage

• Safe mode protection verified: percentage of endpoint builds where the security agent has been tested and confirmed to run in safe mode.
• Command line logging: percentage of Windows hosts sending process creation with command lines (target: all).
• Local admin exposure: number of accounts, human and non-human, with local admin on more than 100 hosts, trending down.
• Agent silence response: median time from agent heartbeat loss after reboot to analyst triage.
• Test pass rate: quarterly emulation of the bcdedit and SafeBoot key tests detected.

Common failure patterns

• Assuming the EDR runs in safe mode: many agents do not, and the only way to know is to test your build.
• No command line logging: without it, bcdedit.exe looks like a routine admin tool.
• Treating agent-offline as a hygiene metric: a missing heartbeat after an unplanned reboot is a live incident signal, not tomorrow's report.
• Shared local admin passwords: one stolen hash lets the actor force safe mode on every host.
• Cleaning the host but not the boot store: a leftover safeboot value or SafeBoot service key re-triggers the problem on the next reboot.

Framework mapping

For the tactic overview and the mitigations catalogue, see the ATT&CK Stealth and Defense Impairment Tactics Guide and the ATT&CK Mitigations hub.

Related Defense Impairment techniques, each with its own page: MITRE ATT&CK T1686 Disable or Modify System Firewall, MITRE ATT&CK T1689 Downgrade Attack.

Practitioner checklist

• Retag detection content from the former Impair Defenses sub-technique ID to T1688.
• Enable command line capture for process creation on all Windows hosts.
• Alert on bcdedit or bootcfg with safeboot in the command line.
• Monitor SafeBoot\Minimal and SafeBoot\Network for new subkeys.
• Build the service install, safeboot, reboot sequence rule.
• Alert on security agents going silent after an unplanned reboot.
• Test and document whether your EDR runs in both safe mode variants.
• Enable EDR tamper protection.
• Remove standing local admin and deploy unique local admin passwords.
• Scope service accounts with local admin rights and watch their use.

Standards and references

• MITRE ATT&CK: T1688 Safe Mode Boot
• MITRE ATT&CK: DET0116 Detection Strategy for Safe Mode Boot Abuse
• CISA: #StopRansomware LockBit 3.0 (AA23-075A)
• Microsoft Learn: bcdedit
• Microsoft Learn: Event 4826 Boot Configuration Data loaded
• Sophos: Snatch ransomware reboots PCs into Safe Mode to bypass protection
• CyberArk Labs: From Safe Mode to Domain Compromise
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: EDR Evasion and Defence Guide · REvil (Sodinokibi) · T1685 Disable or Modify Tools Defensive Guide · Defence Evasion Techniques Guide