How T1688 safe mode boot takes security tooling offline on Windows
When a Windows host goes quiet and its security agents stop reporting, the first question for the SOC lead is whether the host is down or whether something has stopped its tooling from running. T1688 Safe Mode Boot is a technique in which an adversary restarts a host into Windows Safe Mode so that many third-party security services and drivers do not load, leaving the host running while its defenses are absent. The attacker's goal is a window in which activity on the machine is not recorded or blocked by the controls that normally watch it. The technique sits under the Defense Impairment tactic (TA0112), which MITRE ATT&CK describes as adversaries trying to "break security mechanisms, pipelines, and tooling so defenders can't see or trust what's happening" (MITRE ATT&CK tactic TA0112). Defense Impairment was added as a separate tactic in ATT&CK v19, released April 28, 2026, which split it out of Defense Evasion, so older playbooks may still file this behavior under the previous tactic. This page targets ATT&CK v20.0, and technique IDs and mappings can change between releases, so confirm the version your detections reference before you rely on them.
In intrusions, this behavior is most useful to an adversary as a step taken after access is already established, when the goal is to operate on a host without endpoint telemetry or prevention in the path. Because the change is made at the boot configuration level, it can appear as an ordinary administrative restart, which is why it is easy to miss when it is the only signal. The practical risk for your team is a gap: a host that drops out of the console, a sensor that stops checking in, or a restart that no change ticket explains. Decide now which of these events must page an analyst, how long a silent host may stay silent before it is treated as suspicious, and who can authorize a restart into Safe Mode outside a maintenance window. Confirm with your endpoint vendor which of your agents and drivers are affected when Safe Mode is used, because that list determines what a silent host actually means in your environment.
Detection of this technique relies on the boot and registry change that precedes the restart, combined with process activity on the host, rather than on the agent's own health alone. The sections that follow cover those data sources, the detection logic and the mitigations.
Telemetry that reveals safe mode boot changes and which open-source tool collects it
This table maps each Windows telemetry source to the safe mode boot signal it can reveal and the open-source collector that gets it into a monitoring stack. Read it as a checklist: a data source only helps if the matching audit policy is on and the events reach a place where analysts can search them. Coverage varies with the audit settings in each environment, so confirm them on your own hosts before relying on any row.
| Telemetry | Signal to look for around T1688 | Collector and forwarding path |
|---|---|---|
| Process Creation (DC0032) | Command-line activity that changes boot configuration or schedules a reboot into safe mode, and unusual child processes started shortly before or after a restart | Sysmon process creation events or Windows Security process auditing, forwarded to Wazuh or Security Onion |
| Windows Registry Key Modification (DC0063) | Writes to boot-related registry values that control which services and drivers load in safe mode, including changes to minimal-boot configuration keys | Sysmon registry events or Windows registry auditing on monitored keys, forwarded to Wazuh through the agent |
| Windows Registry Key Creation (DC0063) | New boot-related keys or subkeys appearing in safe mode configuration paths, which can indicate a new entry rather than an edit to an existing one | Sysmon registry events or Windows registry auditing, collected by the Wazuh agent or shipped to Security Onion |
| Process activity around reboots | Restarts initiated by unexpected accounts or hosts, and processes that run only in the window between a configuration change and the next boot | Windows event logs for shutdown and startup, combined with Sysmon process events in the same host timeline |
| Audit policy coverage | Whether object access and registry auditing are enabled for the keys that matter; without it, the registry rows above may show nothing | Group Policy or local audit policy, verified on sample hosts before rollout; Wazuh agent configuration controls which keys are monitored |
| Central retention and correlation | Ability to line up a registry change, a process event and a boot event for the same host within a short window | Wazuh alerting or Security Onion dashboards, with retention set to match your investigation needs |
Detection logic for T1688 that a detection engineer can tune
Safe Mode Boot abuse leaves a chain of small, ordinary-looking signals: a boot configuration change, a reboot, a tool launch and a host that goes quiet. No single signal is conclusive, so the rules work best when they are correlated per host and tuned against a documented list of approved maintenance. Write each rule as a Sigma rule that names the ATT&CK version it targets.
Boot configuration registry changes
Alert on creation or modification of the boot configuration values that determine whether Windows starts in Safe Mode, such as the SafeBoot option set under the SYSTEM\CurrentControlSet\Control hive. Use Windows Registry Key Modification and Registry Key Creation telemetry from Sysmon or the agent, and filter by host group and change window. Tune the threshold to alert on any change outside an approved maintenance window, not on volume, because a single change is enough to matter. Expect false positives from imaging and security tooling that set these values during standard builds.
Reboot following boot configuration change
Correlate a boot configuration change with a host restart within a short, tuned time window, for example a window you set after reviewing change tickets for your fleet. The pairing is stronger than either event alone. Source the reboot from System event logs and the change from registry telemetry, joined on hostname and time. Patch management, scheduled restarts and imaging produce the most common benign pairs, so suppress known patch and reimage job identifiers, and review the window length with your operations team before enabling the alert.
Process lineage around the boot tool
Review process creation events for the built-in boot configuration utility, bcdedit.exe, and flag invocations whose parent process is unusual, such as a script host, a remote management session or an unsigned binary running from a user profile path. Command Execution and Process Creation telemetry should both be enabled so the command line and parent chain are visible. Document approved administrators and automation accounts first, since helpdesk and deployment scripts legitimately call this tool and will drive most false positives.
Agent check-in gaps on modified hosts
Treat a host that stops reporting to the SIEM or endpoint agent shortly after a boot configuration change as a high-priority gap. Build a rule or scheduled search that compares the last check-in time against a tuned maximum silence period and joins it to recent registry events. Hosts that are powered off for maintenance, laptops off the network and reimaged systems create the main false positives, so exclude asset-management lifecycle states and confirm the silence threshold with your endpoint team before deployment.
Sigma rule governance and versioning
Store each T1688 rule as a Sigma rule and record the ATT&CK version it targets in the rule metadata, so that later releases that rename or deprecate content do not silently change coverage. Keep the false positive list in the same file, and review it on every ATT&CK release and every change to your image or patch pipeline. Validate the converted rules in your SIEM and in the cyber range before promoting them, and track exceptions with an owner and an expiry date.
How to confirm the T1688 detection fires before you trust it
This sequence proves, in a lab or cyber range, that the T1688 Safe Mode Boot detection produces the expected events, alerts and fields before anyone relies on it in production. It ends with a dated, traceable record that a tuning change can be checked against.
Agree scope and rules of engagement
The detection owner, the SIEM administrator, the test host owner and the range operator agree in writing what will be run, on which isolated test host, during which window, and who can stop the exercise. Defense Impairment techniques can disrupt the very tooling that records them, so the rules should state how the test host is restored and what happens if logging stops. The step is done when every party has signed off the scope document and the rollback plan.
Map the planned behavior to T1688
The team writes down the behavior the emulation plan will exhibit, described in plain words such as changing the host's boot configuration to start in a diagnostic mode, and maps it to Safe Mode Boot in MITRE ATT&CK Enterprise. Record the ATT&CK version the mapping targets, because techniques can be renamed or deprecated between releases. Confirm the expected data sources, which for this detection are Process Creation, Windows Registry Key Modification and Windows Registry Key Creation. The step is done when each planned action has a single expected telemetry source written beside it.
Run the emulation on a test host
The range operator runs the agreed emulation on a dedicated Windows test host that has the same logging configuration as production, and does so from the approved plan without improvising. The operator records the start and end times, the operator account used and any deviation from the plan. Keep the host isolated from production networks throughout. The step is done when the run log is complete and the host is back in its baseline state.
Confirm expected events reach the SIEM
The SIEM administrator checks that the Windows events generated by the run arrive in the platform, such as Wazuh or another SIEM the client uses, within the ingestion latency the team has measured for that environment. Compare the events received against the expected list from the mapping step, and note any gap in event channels, agents or parsing. Confirm the events were received intact and not truncated. The step is done when each expected telemetry source shows at least one matching event, or a documented gap is raised as a defect.
Check each rule fires with the right fields
The detection engineer checks that each rule, whether written as Sigma or native SIEM logic, fires on the events from the run and populates the fields it depends on, such as the process name, the registry key path, the value written and the user context. A rule that fires with empty or wrong fields is a failed check even if an alert appears. Test one negative sample as well, a benign boot-configuration action, so the team knows what a non-match looks like. The step is done when every rule has a pass or fail result against a named field list.
Record timestamps, host identifiers and alert IDs
The team records, for each alert, the event timestamps, the host identifier, the rule name and version, the SIEM alert ID and a link or reference to the raw events. These records are the evidence that the detection worked on a specific date against a specific ATT&CK mapping. Store them with the emulation plan and the scope document in the client's change or evidence repository. The step is done when a reviewer who was not in the run can trace one alert from the rule to the raw events and back to the plan.
Re-run the emulation after tuning
Whenever a rule is tuned, such as to reduce noise from legitimate maintenance, the team repeats the emulation and the checks above before the change is promoted to production. The re-run confirms that tuning has not removed the detection for the planned behavior, and the new results are recorded beside the earlier ones. Treat a failed re-run as a block on promotion. The step is done when the tuned rule passes the same checks against the same planned behavior and the comparison is filed.
Preventive controls that limit safe mode boot abuse
Safe Mode Boot abuse depends on being able to change boot behavior, which normally requires administrative rights and a configuration change. The two ATT&CK mitigations covered here, Privileged Account Management and Software Configuration, reduce the chance that an attacker reaches those steps unnoticed. The cards below describe the controls to review and the checks to confirm in your own environment.
Limit local administrator rights
Restrict who holds local administrator rights on Windows endpoints, since changing the boot configuration to Safe Mode generally requires elevated privileges. Review group membership for the local Administrators group on workstations and servers, and remove standing rights that users do not need for their role. Confirm with your Windows administrators which accounts can run boot configuration tools, and whether that access is granted by default in your image or by group policy.
Require privileged access management
Route administrative sessions through a privileged access workflow that issues time-limited elevation, records who requested it, and ties it to an approval. Without this, a compromised account with standing rights can change boot behavior at any hour without a second person knowing. Ask your identity team whether elevation is just-in-time, whether session recording covers console and remote access, and how quickly elevated sessions expire.
Control boot configuration changes
Treat changes to boot configuration as a controlled change, not a routine administrative task. Use group policy or endpoint management to restrict who can modify boot settings, and alert on changes made outside the change process. Confirm which tools in your fleet can alter boot entries and whether those tools are limited to approved administrators and hosts.
Baseline approved software configuration
Define a hardened build for each Windows image, including boot settings, and check endpoints against that baseline on a schedule. Drift from the baseline is a useful signal because an unexpected Safe Mode boot setting is rarely part of normal operations. Confirm with your configuration management team how baselines are versioned, who approves exceptions, and how drift reports reach the security operations team.
Protect the endpoint management plane
Limit who can push configuration through your endpoint management, scripting and remote management tools, because a change pushed through those channels can reach many machines at once. Require strong authentication and separate accounts for administration, and log every policy push. Ask your platform owners which consoles can modify boot or startup settings and whether those consoles are covered by the same logging as domain controllers.
What to do when a T1688 alert fires on a Windows host
When a T1688 alert fires on a Windows host, the first decision is whether the change was authorized. Check the change record, the maintenance window and the administrator account that produced the process creation or registry write. Safe Mode configuration is sometimes changed during recovery from a failed update, a driver problem or a disk repair, so a legitimate explanation is possible. Confirm it with the owner of the host and the administrator who was working on it, and record the answer before anyone changes the machine. An unexplained boot configuration change on a server or a privileged workstation should be treated as suspicious until the owner proves otherwise.
Next, preserve the host as your incident policy requires. Some organizations isolate the endpoint from the network at once, others keep it connected so that active sessions can be observed, and others require a memory capture before any reboot. The incident owner decides on containment, and that decision weighs business impact, the sensitivity of the host and the risk of tipping off an intruder. While the host is in that state, collect the relevant Windows event records, the Process Creation events that launched the boot configuration tool, and the Windows Registry Key Modification and Key Creation events for the boot configuration keys, along with a snapshot of the current registry state. Hash and log every artifact under your own evidence handling procedures, and confirm with counsel or your forensic provider where chain of custody matters.
Then check related hosts for the same pattern. Search the same data components across the fleet for the same account, the same command pattern and the same registry changes within a window around the alert, and include hosts that share an administrator, a management tool or a build image. Build the timeline from the first suspicious event to the alert, the response actions and the final state, and record who made each decision and why. Confirm with your own change and logging teams which telemetry was complete for that period, because gaps change what the timeline can prove. The timeline then supports the closure decision, any reporting duty and the review of the detection itself, including whether Microsoft's documentation on Windows event logging matches the events your Wazuh or Security Onion pipeline actually received.
Rehearsing T1688 detection and response in a private cyber range
The range should mirror the production Windows estate closely enough that telemetry behaves the same way, but stay fully isolated from corporate networks and production identity systems. Build a small set of Windows endpoints joined to a lab domain, with Sysmon installed under a version-pinned configuration and forwarded to a Wazuh manager or a Security Onion stack. Keep time synchronized across all hosts so alert timestamps can be compared during the review.
- Isolated Windows hosts: Use snapshot-restorable virtual machines on a segregated network segment with no route to production.
- Logging pipeline: Confirm that Process Creation, Windows Registry Key Modification and Windows Registry Key Creation events reach the SIEM, and record the ingestion delay for each source.
- Sysmon configuration: Document the exact configuration file, its version and the event IDs it enables, and store it in version control so the range and production use the same baseline.
- Detection content: Load the Sigma rules or Wazuh rules under test, tagged with the ATT&CK version they target.
- Reset process: Define how hosts return to a clean snapshot between runs.
Confirm with your SIEM vendor or project documentation which fields each rule depends on before the exercise begins.
Injects are scheduled events that the facilitator releases to the blue team during the exercise. For T1688 the facilitator should script the activity at a conceptual level, using a pre-approved plan that describes which telemetry categories should be produced, not the operational steps an adversary would use. The facilitator keeps a master timeline so every observed alert can be matched against the time the inject was released.
- Scheduled timeline: Write the inject schedule before the exercise, with a release time, target host and expected telemetry category for each event.
- Change-driven scenarios: Use a benign, documented boot configuration change on a range host so the team must distinguish it from noise.
- Telemetry checkpoints: Note which data source should show the activity, so gaps in collection are found during the exercise rather than afterward.
- Escalation variants: Add a second inject that follows the first, to test whether the team connects related events across hosts.
- Control inject: Include a routine administrative change that should not alert, to measure false positives.
Ask the red team or exercise provider to confirm that all injects were approved in writing and stay within the agreed rules of engagement.
Good detection means the right signal reaches an analyst within the window the team agreed in advance, on the right host, with the fields needed to decide what happened. The exercise should measure timing, accuracy and completeness separately, because an alert that fires late or names the wrong host is a finding even when the rule technically matched.
- Alert within the agreed window: Record the time between each inject release and the first alert, and compare it with the window the team set in its plan.
- Correct host and user fields: Verify that the alert names the endpoint where the change occurred and the account that made it.
- Usable process and registry context: Check that the parent process, command context and registry path or value are present in the event, not only in the raw log.
- Coverage across the control inject: Confirm that the routine change did not create an alert, or that any alert was documented and tuned.
- Detection gap log: Record each missed or delayed event with its cause, such as a missing Sysmon rule, a dropped log or a parsing error.
For each finding, ask whether the fix belongs in the rule, the endpoint configuration or the log pipeline, and assign an owner.
Good response is measured by the quality of decisions and records, not by speed alone. Analysts should triage the alert, document what they checked, decide whether to contain the host, and feed the results into lessons learned. The facilitator should observe how the team uses its runbook, who is contacted, and whether the decision to isolate a host is made with enough evidence and approval.
- Triage notes: Require analysts to record the alert source, the timeline, the fields reviewed and the conclusion, using a template that matches the incident record.
- Containment decision: Check that the team decides whether to isolate the endpoint, who approves it, and how that choice affects the range and any dependent services.
- Escalation path: Confirm that the on-call contacts and communication channels in the runbook were reached within the agreed time.
- Lessons learned: Hold a structured review within a set period after the exercise, with actions assigned to named owners and tracked to closure.
- Evidence preservation: Verify that relevant logs and host state were preserved before any remediation or reset.
Check that the runbook, contact list and approval rules match the production process your organization actually uses.
Questions SOC leads and detection engineers ask about T1688
How do I separate a routine maintenance reboot into Safe Mode from T1688 activity?
Look at context rather than the reboot alone: who initiated the boot, from which host and account, whether a change record or maintenance window exists, and whether the boot configuration change that set Safe Mode was followed by a reboot within a short, expected interval. Routine Safe Mode use by help desk or patch troubleshooting usually comes from known administrator accounts on managed endpoints with matching tickets. Treat a Safe Mode configuration change from an unexpected account, on a server or on a host with no open ticket as the higher-priority case. Build an allow list of approved maintenance paths and review exceptions weekly so analysts are not paging on every reboot.
Which Windows event sources should I enable before writing a Safe Mode detection?
At minimum, the detection depends on process creation events with full command line capture, and on registry change events for the boot configuration keys that control Safe Mode. Enable the Windows Security audit policy for process creation and include command line in those events, and confirm that the Sysmon or equivalent endpoint agent records registry value set and key creation for the relevant keys. Forward these to your Wazuh or other SIEM pipeline and confirm end to end delivery with a test change on a non-production host. Without the registry events, the detection can only see the command that ran, not the state change it made. Confirm each setting against your own Windows build and agent version, since audit behavior varies by configuration.
How should I version Sigma rules against ATT&CK releases?
Record the ATT&CK version each rule targets in its metadata, and treat that version as part of the rule's identity. ATT&CK publishes content as STIX 2.1 bundles per domain and version, and releases can rename, deprecate or revoke techniques, so a rule mapped to a technique ID may need review after a release. Keep rules in version control, tag the ATT&CK version used for mapping, and run a diff against the new STIX bundle when you upgrade. Review the MITRE ATT&CK updates pages for the release notes that describe changes to detections, data components and tactics before you change mappings. Pin the version in your detection pipeline so a silent upstream change does not alter alert logic.
How do I handle sub-technique changes without losing coverage history?
Keep the parent technique as the anchor for reporting, and map each detection to the most specific sub-technique it actually observes. When a sub-technique is added, split, renamed or deprecated, do not silently rewrite old mappings. Instead, record the change, note which rules are affected, and decide whether existing detections still fit. Check whether T1688 has sub-techniques in the ATT&CK version you target, because the page and its child entries can differ between releases. Keep a mapping table that links each rule ID to a technique and sub-technique with a version field, so historical coverage reports remain reproducible.
How do I measure detection coverage for T1688 in a way an auditor can follow?
Measure whether the required telemetry arrives, whether a rule fires on it, and whether an analyst responds, and report these three separately. Start with a log source inventory that shows which hosts send process creation and registry events, then track rule health and alert outcomes. Use cyber range results to show that the detection fired on a controlled Safe Mode change, and record the test date, host, account and ATT&CK version. Coverage percentages are only as good as the test set behind them, so state the scope plainly. DeployOpen can help prepare these control and test records for a compliance assessment, but independent auditors decide whether the evidence is sufficient.
Can my team build and maintain this detection without outside help?
Many SOC teams can build a first version with Wazuh or a comparable SIEM, Sigma rules and a Sysmon configuration, especially if they already run endpoint telemetry. The harder work is ongoing: tuning out legitimate maintenance, keeping event sources healthy across Windows builds, and re-validating after ATT&CK releases. Ask internally who owns each of those tasks and how many hours a month they can reliably give. Where capacity or expertise is thin, a fixed-scope engagement can cover the initial build, testing and documentation, with a retainer for upkeep. Get the scope, deliverables and timeline in writing before work starts.
Where to confirm T1688 details and ATT&CK version changes
Before you write or tune a rule for T1688 Safe Mode Boot, confirm its current ID, name and tactic on the MITRE ATT&CK Defense Impairment tactic page. Defense Impairment is a separate Enterprise tactic with the ID TA0112, and it is where T1688 is expected to sit. From the tactic page, open the T1688 technique entry and check its listed data components, its detection strategies and analytics, and its mitigations. Since ATT&CK v18 replaced technique-level detections with detection strategies, your rule should cite the detection strategy and analytic IDs, not a free-text description of the detection. Record the ATT&CK version you checked, because the same technique can change between releases.
Check the ATT&CK updates page before every rule release. MITRE publishes changes on its updates page, and the releases that matter most for this topic are v18 (October 28, 2025), v19 (April 28, 2026) and v20 (October 13, 2026), as listed in the repository index. Version 19 split Defense Evasion into Stealth (TA0005) and Defense Impairment (TA0112), so older rule metadata may still point to a tactic that no longer describes the technique. Releases can also rename, deprecate or revoke techniques and sub-techniques. Ask the detection owner to confirm which release the rule targets, and set a review step that runs when a new release is published.
For an audit-ready check, download the Enterprise 20.0 bundle from the attack-stix-data repository and filter it for the T1688 object. Confirm the relationships to the data components used for the detection, including Process Creation and Windows Registry Key Modification, and the mapped mitigations, including Privileged Account Management and Software Configuration. Compare those results with the live website and note any differences. Store the bundle file name, download date and checksum with the rule's change record, so reviewers can reproduce the mapping. Confirm all of this with the detection owner before deployment, because mappings can change between releases.
How DeployOpen builds T1688 detections and cyber range scenarios
DeployOpen works on T1688 Safe mode boot as a fixed-scope engagement inside your own environment, with the scope agreed in writing before any work starts. The work covers Windows telemetry, open-source detection content, validation in a private cyber range, and documentation your team can run after handover.
How we scope
- Confirm which Windows versions, endpoint populations and logging sources fall inside the written scope.
- Agree which telemetry (Process Creation, Windows Registry Key Modification and Windows Registry Key Creation) is already collected and which needs enabling.
- Record the ATT&CK version the detections target, so mappings stay accurate when MITRE updates technique content.
How we build
- Write detection logic for Safe Mode Boot changes in open formats such as Sigma and deploy it to your Wazuh or other SIEM stack.
- Tune the detection against your administrators' legitimate boot configuration changes to reduce noise before handover.
- Map coverage to Privileged Account Management and Software Configuration, and document where each mitigation is enforced in your environment.
How we hand over
- Deliver the detection rules, test cases, data source checklist and response runbook for T1688 Safe mode boot.
- Rehearse the detection and response in a private cyber range with your security operations staff, using a written scenario.
- Provide a readiness record that your internal team or independent auditor can review, without DeployOpen issuing any attestation.
How we support
- Review detection performance after handover against your alert volume and any changes to Windows logging configuration.
- Update detection mappings when new ATT&CK versions change the technique or its data components.
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the original engagement.
