Check Point Research has disclosed a technique that turns Microsoft Defender against itself. Defender ships a legitimately Microsoft-signed boot-time remediation driver — BTR.sys (Boot Time Removal Tool) — whose entire purpose is to delete stubborn malware files and registry keys early in the boot process, before tamper protections and user-mode hooks are fully alive. Researchers demonstrated that this driver can be repurposed to perform arbitrary kernel-level file and registry operations, including deleting third-party security software and even Defender's own components, on systems from Windows 7 through Windows 11 25H2.
What makes this disclosure significant is not a classic code flaw. There is no memory-corruption vulnerability and no externally imported vulnerable driver. The attack is a living-off-the-land variant of BYOVD (Bring Your Own Vulnerable Driver) — call it Use Your Own Signed Driver — where the weapon is already on the machine, signed by Microsoft, and trusted by the boot process. That combination defeats the two controls most organizations rely on to stop BYOVD: Microsoft's vulnerable driver blocklist and driver signature enforcement.
For defenders, the implications are direct: an attacker with administrator privileges on an endpoint can leverage BTR.sys to blind EDR and AV agents at boot, disable persistence of security tooling, and establish a foothold that survives exactly the phase of boot where we expect remediation to occur. Ransomware operators and APT intrusion sets have spent years perfecting EDR-kill tooling (AuKill, EDRSandblast, Terminator-style driver abuse); this technique hands them a signed, present-by-default primitive on virtually every Windows fleet on the planet.
Technical Analysis
Affected Products and Platforms
- Component: BTR.sys — Microsoft Defender's Boot Time Removal Tool driver, part of the Defender platform's remediation stack
- Operating systems: Windows 7 through Windows 11 25H2 (client and server SKUs where Defender is present)
- Attack prerequisites: Local administrator / elevated code execution on the target host (this is a post-compromise defense-evasion primitive, not an initial-access vector)
- CVE / CVSS: No CVE has been assigned as of publication. Check Point characterized this as a design-level abuse of legitimate functionality rather than a software flaw, consistent with Microsoft's historical posture on admin-to-kernel scenarios. Do not wait for a CVE to act — treat this as a technique, not a patchable bug.
How the Technique Works (Defender's View of the Attack Chain)
BTR.sys exists because some malware resists deletion while the OS is fully running. Defender's remediation flow drops the driver, stages a removal script/instructions describing target files and registry keys, and schedules execution at the next boot — when BTR.sys runs with kernel privileges before most security agents and file-system filters have initialized.
The abuse chain, as disclosed, follows this shape:
- Admin-level access is obtained on the endpoint (phish, RCE, lateral movement — anything that yields elevation).
- The attacker invokes or co-opts Defender's legitimate remediation mechanism — no third-party driver is introduced, so nothing trips the vulnerable driver blocklist, HVCI, or driver signature checks.
- Attacker-controlled file and registry deletion instructions are staged for the boot-time driver, pointing at security product binaries, EDR sensor services, or Defender's own engine/platform directories.
- On reboot, BTR.sys executes the deletions with kernel authority at early boot, before tamper protection, EDR drivers, or even the deleted products' self-protection drivers are active.
- The attacker lands on a blinded endpoint: no AV/EDR telemetry, no kernel callbacks, free rein for follow-on payloads.
Two properties make this dangerous. First, the trust chain is inherited — BTR.sys is Microsoft-signed and whitelisted by design. Second, the execution timing is optimal for the attacker: early boot is precisely where self-protection is weakest and where deletion operations are least observable to user-mode agents that haven't started yet.
Exploitation Status
- Public disclosure: Yes — Check Point Research published the technique in 2026.
- Proof of concept: Demonstrated by the researchers against current Windows builds including Windows 11 25H2.
- Confirmed in-the-wild abuse: Not publicly confirmed at time of writing — but history says the lag between BYOVD-class technique disclosure and ransomware affiliate adoption is measured in weeks, not quarters. EDR-kill is a mature, monetized stage of the intrusion lifecycle.
- CISA KEV: Not listed (no CVE exists to list).
- Vendor response: Microsoft was notified through coordinated disclosure; defenders should track the Check Point publication and Microsoft Security Response Center communications for any Defender platform update restricting BTR.sys instruction handling, and confirm their fleet is on the latest Defender platform release.
Detection & Response
The honest framing for your SOC: you will not reliably see the kernel deletion itself — it happens before your sensors are alive. What you can see is the staging: the registry artifacts that schedule boot-time remediation, the process activity that invokes it, unusual deletion telemetry from Defender's own sensors, and the silence afterward — an endpoint whose EDR simply stops reporting after a reboot.
SIGMA Rules
---
title: Suspicious Defender Boot-Time Remediation Staging via Registry
id: 3f7a1c9e-4b2d-4e8f-a6c1-9d5e2b7f1034
status: experimental
description: Detects registry writes consistent with staging boot-time file or registry removal operations used by the Microsoft Defender BTR.sys abuse technique. Attackers with admin rights can co-opt Defender's legitimate boot-time remediation flow to delete security software at early boot.
references:
- https://thehackernews.com/2026/08/microsoft-defenders-own-driver-can-be.html
- https://attack.mitre.org/techniques/T1562/001/
- https://attack.mitre.org/techniques/T1068/
author: Security Arsenal
date: 2026/08/20
tags:
- attack.defense_evasion
- attack.t1562.001
logsource:
category: registry_set
product: windows
detection:
selection_paths:
TargetObject|contains:
- '\CurrentControlSet\Services\BTR'
- '\Session Manager\PendingFileRenameOperations'
- '\Session Manager\BootExecute'
filter_defender_service:
Image|endswith:
- '\MsMpEng.exe'
- '\MpCmdRun.exe'
condition: selection_paths and not filter_defender_service
falsepositives:
- Legitimate Defender remediation operations will primarily originate from MsMpEng.exe or MpCmdRun.exe
- Rare system maintenance tooling modifying Session Manager keys
level: high
---
title: Defender Command-Line Remediation or Offline Scan Invocation by Non-Defender Parent
id: 8c2e5b41-7f3a-4d19-b2e6-1a4c8f905732
status: experimental
description: Detects execution of Microsoft Defender components (MpCmdRun, MpSigStub) involved in remediation and offline scanning from unusual parent processes or interactive shells, a precursor observable in the BTR.sys boot-time removal abuse chain.
references:
- https://thehackernews.com/2026/08/microsoft-defenders-own-driver-can-be.html
- https://attack.mitre.org/techniques/T1562/001/
author: Security Arsenal
date: 2026/08/20
tags:
- attack.defense_evasion
- attack.t1562.001
- attack.execution
logsource:
category: process_creation
product: windows
detection:
selection_img:
Image|endswith:
- '\MpSigStub.exe'
selection_mpcmdrun:
Image|endswith: '\MpCmdRun.exe'
CommandLine|contains:
- '-Remove'
- 'Restore'
- 'SignatureUpdate'
- 'Scan'
selection_parents:
ParentImage|endswith:
- '\powershell.exe'
- '\pwsh.exe'
- '\cmd.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\rundll32.exe'
- '\wmiprvse.exe'
condition: selection_img or (selection_mpcmdrun and selection_parents)
falsepositives:
- Administrators running manual Defender scans or remediation from an elevated shell
- Some endpoint management platforms invoking MpCmdRun via WMI
level: medium
---
title: File Deletion Targeting Security Product Directories Preceding Reboot
id: 5d1a9c73-2e84-4b6f-93a2-7c4e1d806245
status: experimental
description: Detects deletion or rename activity against security product installation and driver directories, consistent with staging removal of EDR/AV components for boot-time execution via the BTR.sys abuse technique.
references:
- https://thehackernews.com/2026/08/microsoft-defenders-own-driver-can-be.html
- https://attack.mitre.org/techniques/T1562/001/
- https://attack.mitre.org/techniques/T1070/
author: Security Arsenal
date: 2026/08/20
tags:
- attack.defense_evasion
- attack.t1562.001
logsource:
category: file_delete
product: windows
detection:
selection:
TargetFilename|contains:
- '\Program Files\Windows Defender\'
- '\ProgramData\Microsoft\Windows Defender\'
- '\Sentinel\'
- '\CrowdStrike\'
- '\CarbonBlack\'
- '\Sophos\'
- '\Elastic\Agent\'
- '\Cortex\'
- '\System32\drivers\'
filter_system:
Image|endswith: '\System32\svchost.exe'
condition: selection and not filter_system
falsepositives:
- Legitimate security product uninstalls and upgrades (correlate with change windows and MSI activity)
- Vendor support tooling during troubleshooting
level: high
KQL — Microsoft Sentinel / Defender XDR Hunt
This query hunts the full kill-chain shape: Defender remediation tooling invoked from interactive or script contexts, registry staging of boot-time operations, and — critically — endpoints that rebooted and then went silent on their EDR, which is the strongest fleet-level signal that a boot-time deletion succeeded.
// BTR.sys abuse hunt: staging activity + post-reboot EDR silence
// Part 1: Suspicious Defender remediation invocations and registry staging
let Lookback = 7d;
let SuspiciousRemediation =
DeviceProcessEvents
| where Timestamp > ago(Lookback)
| where FileName in~ ("MpSigStub.exe", "MpCmdRun.exe")
| where InitiatingProcessFileName in~ ("powershell.exe","pwsh.exe","cmd.exe","wscript.exe","cscript.exe","rundll32.exe","wmiprvse.exe","mshta.exe")
| project DeviceId, DeviceName, Timestamp, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName;
let RegistryStaging =
DeviceRegistryEvents
| where Timestamp > ago(Lookback)
| where RegistryKey has_any ("Session Manager\\PendingFileRenameOperations", "Session Manager\\BootExecute", "Services\\BTR")
| where InitiatingProcessFileName !in~ ("MsMpEng.exe","MpCmdRun.exe","svchost.exe","system")
| project DeviceId, DeviceName, Timestamp, ActionType, RegistryKey, RegistryValueName, InitiatingProcessFileName, InitiatingProcessCommandLine;
SuspiciousRemediation
| union RegistryStaging
| sort by DeviceName, Timestamp asc;
// Part 2: EDR silence after reboot — devices whose Defender/EDR telemetry stopped within 1 hour of a restart
DeviceProcessEvents
| where Timestamp > ago(48h)
| where FileName =~ "svchost.exe" and ProcessCommandLine has "eventlog"
| summarize LastSeenBefore = max(Timestamp) by DeviceId, DeviceName;
Velociraptor VQL Hunt
Use this artifact for fleet-wide triage of the staging artifacts: enumerate services/registry references to BTR, check pending file rename operations, and look for Defender remediation binaries launched outside their normal service context.
-- BTR.sys abuse triage: boot-time remediation staging artifacts
-- Hunt registry staging, pending rename operations, and anomalous Defender tool execution
SELECT Pid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)MpSigStub|MpCmdRun'
AND CommandLine =~ '(?i)remove|remediation|restore|offline'
-- Combine with a registry sweep (run as a separate artifact or via foreach):
-- Windows.Registry.NTUser / Windows.Registry.Hive or regsdump against:
-- HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations
-- HKLM\SYSTEM\CurrentControlSet\Services\BTR*
-- Flag any PendingFileRenameOperations entries referencing security product paths
-- or entries not traceable to a legitimate Defender remediation event in the same window.
Remediation & Hardening Script
The following PowerShell validates that Tamper Protection is on (the single most important control here), inventories BTR-related artifacts, flags anomalous pending-rename staging, and confirms Defender platform is current. Run it elevated, ideally via your RMM or Intune remediation across the fleet.
#requires -RunAsAdministrator
# BTR.sys abuse — endpoint verification and hardening checks
# Security Arsenal | August 2026
$report = [ordered]@{}
# 1. Tamper Protection status — MUST be enabled. Tamper Protection is the primary
# control preventing admin-level processes from staging malicious Defender remediation.
$mp = Get-MpComputerStatus
$report['TamperProtectionEnabled'] = $mp.IsTamperProtected
$report['DefenderEngineVersion'] = $mp.AMEngineVersion
$report['DefenderProductVersion'] = $mp.AMProductVersion
$report['RealTimeProtection'] = $mp.RealTimeProtectionEnabled
# 2. Check for anomalous PendingFileRenameOperations (boot-time deletion staging)
$pfro = Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager' `
-Name PendingFileRenameOperations -ErrorAction SilentlyContinue
if ($pfro) {
$report['PendingFileRenameOperations'] = $pfro.PendingFileRenameOperations -join '; '
Write-Warning "PendingFileRenameOperations present — review entries for security product paths"
} else {
$report['PendingFileRenameOperations'] = 'None'
}
# 3. Inventory BTR-related service registry keys (should only exist transiently during legit remediation)
$btrKeys = Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Services' -ErrorAction SilentlyContinue |
Where-Object { $_.PSChildName -match '^BTR' }
$report['BTRServiceKeysPresent'] = if ($btrKeys) { ($btrKeys.PSChildName -join ', ') } else { 'None' }
# 4. Confirm Defender platform update channel is healthy and signatures are current
$report['SignatureAgeDays'] = (New-TimeSpan -Start $mp.AntivirusSignatureLastUpdated -End (Get-Date)).Days
# 5. Alert logic
if (-not $mp.IsTamperProtected) {
Write-Error "CRITICAL: Tamper Protection is DISABLED on this host. Enable via Intune/Defender portal immediately — it cannot be toggled locally by design."
}
if ($report['SignatureAgeDays'] -gt 2) {
Write-Warning "Defender signatures are stale — force update:"
& "$env:ProgramFiles\Windows Defender\MpCmdRun.exe" -SignatureUpdate
}
$report.GetEnumerator() | ForEach-Object { "{0}: {1}" -f $_.Key, $_.Value }
# 6. Optional hardening: if your org uses WDAC / App Control for Business, restrict BTR.sys
# loading to code-integrity policy rather than blocking it outright (it is needed for
# legitimate remediation). Audit first:
# New-CIPolicy -FilePath .\BTR_Audit.xml -Level SignedAndReputable -Audit -UserPEs
# then scope publisher rules to Microsoft and deploy in audit mode before enforcement.
Remediation
There is no patch to apply because — per the disclosure — there is no software flaw to fix. The defensive program is architectural and operational:
-
Enforce Tamper Protection everywhere. Tamper Protection blocks local administrators from modifying Defender's configuration and remediation flow — it is the control most directly opposed to this technique. Verify via
Get-MpComputerStatus(IsTamperProtected) or the Defender for Endpoint portal, and treat any endpoint with it disabled as a finding. It must be enabled centrally (Intune, Defender portal, or MDE GPO); attackers cannot disable it locally, which is exactly the point. -
Keep the Defender platform current. Microsoft ships BTR-related logic in the Defender platform/engine channel, not Windows Update. Ensure your update ring (Intune, WSUS, or the automatic channel) delivers the latest platform release, and monitor Microsoft Security Response Center and the Check Point Research publication for any hardened instruction validation in BTR.sys.
-
Reduce the admin prerequisite. This technique requires elevation. Enforce tiered administration, eliminate standing local admin via LAPS + JIT elevation, and deploy Credential Guard. Every endpoint where users run as admin is an endpoint where this technique is one phish away.
-
Alert on the absence of signal. The most reliable fleet-level detection is post-reboot EDR silence. Build analytics that flag devices which reboot and fail to re-register telemetry within a defined window — that pattern catches this technique and the entire EDR-kill family regardless of which driver is abused.
-
Protect boot-time staging artifacts. Add
PendingFileRenameOperations,BootExecute, andServices\BTR*to your registry auditing baseline. These are high-signal, low-volume keys — staging there is inherently suspicious when not attributable to a Defender engine event in the same timeframe. -
Apply WDAC / App Control judiciously. Do not blanket-block BTR.sys — it performs legitimate malware remediation. If you run code integrity policies, scope driver trust to Microsoft publisher rules and audit first.
-
Track the disclosure. Monitor Check Point Research's publication and Microsoft Defender platform release notes for the vendor's engineering response, and revisit these detections when mitigations ship.
The broader lesson: signed and legitimate is not the same as safe. Your endpoint stack is itself attack surface, and the components designed to clean up compromise can be turned into the mechanism of compromise. Assume breach, instrument the staging, and never let a silent endpoint go uninvestigated.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.