# BTR Reforged Turns Defender Against Itself Source: https://www.egnworks.com/blog/btr-reforged-turns-defender-against-itself Author: Jacob Strix Published: 2026-09-05 Updated: 2026-09-05 Category: Red Team Tags: Windows Internals, Microsoft Defender, EDR Evasion, Kernel Security, BTR.sys > BTR Reforged repurposes Defender's signed remediation driver as a controlled Ring 0 file and registry operation primitive. --- Microsoft Defender contains a signed remediation driver designed to remove threats that cannot be cleaned while Windows is fully running. BTR Reforged shows that an administrator can reconstruct the driver's private input format and redirect those trusted kernel operations toward arbitrary files and registry objects. This is not a local privilege escalation, a memory-corruption exploit, or a conventional vulnerable-driver case. The operator already needs administrative execution and `SeLoadDriverPrivilege`. The technique matters because those prerequisites can be converted into file and registry operations executed by Microsoft code in Ring 0, including an early-boot window before Defender's user-mode services start. Check Point Research published the reverse engineering in August 2026 with a proof of concept named BTR_CLI. The work was also presented at Black Hat USA 2026 and DEF CON 34. The researchers reported no observed exploitation in the wild at publication. ## The Component Being Reused `BTR.sys` is Defender's Boot-Time Removal driver. Defender uses it when remediation cannot safely complete during the current session, such as when an infected file is locked. The driver is not normally exposed as a permanent standalone tool. It is embedded as a PE resource in `MpEngine.dll` and extracted when reboot-time cleanup is required. Defender gives the extracted driver a random eight-letter filename ending in `.sys`. A temporary kernel-driver service points to that file, uses the `Boot Bus Extender` load-order group, and stores an `Args` value that identifies a transaction stream. The stream is an NTFS alternate data stream named `:changelist` attached to the driver file. The driver reads that stream during `DriverEntry`, decrypts it, validates several checksums, and executes a sequence of remediation items. Results are written to a feedback file as `NTSTATUS` values. The normal design is coherent: Defender prepares a trusted cleanup plan in user mode, then its signed driver applies the plan where file locks and process protections are less restrictive. BTR Reforged separates the planner from the executor. It recreates the planner's serialization logic and lets the original Microsoft-signed executor process attacker-selected objects. ## Why This Is Not Classic BYOVD Bring Your Own Vulnerable Driver usually imports a signed third-party driver containing an exploitable IOCTL, an arbitrary kernel read or write, or another implementation defect. The attacker abuses that defect to alter kernel memory, terminate protected processes, or disable security controls. BTR Reforged does not rely on a memory-safety bug. The driver accepts file and registry operations because performing those operations is its intended job. The research reconstructed the private transaction protocol instead of exploiting a malformed request. | Property | Classic BYOVD | BTR Reforged | | --- | --- | --- | | Trusted component | Usually a third-party signed driver | Microsoft Defender `BTR.sys` | | Core mechanism | Exploits a driver vulnerability | Supplies valid remediation transactions | | Kernel capability | Often arbitrary memory access | Defined file and registry actions | | Initial privilege | Commonly administrator or equivalent | Administrator plus `SeLoadDriverPrivilege` | | Blocklist fit | Known vulnerable hashes are practical targets | Blocking may disrupt a Defender component | | Confirmed scope | Depends on the vulnerable driver | Defender removal and file or registry operations in the published PoC | The distinction changes defensive assumptions. Signature trust answers who signed a binary, not whether the current caller, configuration, and target paths are legitimate. A Microsoft signature on `BTR.sys` is expected. A Microsoft-signed remediation driver loading from an unusual path with a newly created `:changelist` stream is not. ## Reconstructing the Transaction Protocol The configuration stored in `:changelist` is encrypted with RC4 using a hard-coded 256-byte key from the driver's `.rdata` section. Check Point identified 18 unique 64-bit `BTR.sys` builds that retained the same key and compatible transaction format. That stability made a version-independent proof of concept practical across the tested systems. Integrity is enforced with a modified CRC32 routine. It uses polynomial `0xEDB88320`, initializes the accumulator to `0xFFFFFFFF`, and omits the usual final XOR. The global structure and every item carry independently calculated checksums, so copying a valid stream and changing a path is insufficient. | Structure | Size | Relevant fields | | --- | ---: | --- | | Global header | 24 bytes | Magic `0xFEE1DEAD`, version `2`, payload offset `0x10`, global CRC, transaction ID | | Global payload | Variable | Null-terminated UTF-16 feedback path | | Item header | 16 bytes | Data size, action ID, header CRC, data CRC | | Item data | Variable | Action flags, paths or registry data, four-byte trailing padding | The transaction ID packs two values. Its low 32 bits contain the modified CRC32 of the payload, while its high 32 bits contain the payload size. Simple delete actions omit the leading flags field used by other items. Before writing feedback, the driver shifts their path data four bytes into the mandatory padding so the first four bytes can hold the resulting `NTSTATUS` value. Successful processing ends with `0xC0000056`, or `STATUS_DELETE_PENDING`, rather than `STATUS_SUCCESS`. The status tells Windows that the driver image is marked for deletion while the driver unloads. A parser or detector that treats any nonzero status as failure will misread this lifecycle. ## From User Mode to Ring 0 The public BTR_CLI implementation is self-contained. It can extract `BTR.sys` from the local Defender engine or use an embedded fallback, serialize the selected actions, encrypt the transaction, write the ADS, create the service configuration, and request the load. It also adds an action for `\SystemRoot\Temp\BootClean.log`, a file created by the driver itself, so the proof of concept can remove that artifact. The following diagram separates attacker-controlled preparation from signed kernel execution. The trust transition occurs at driver load, but the semantic transition occurs earlier when untrusted target paths are encoded into a structurally valid Defender remediation stream. ```mermaid flowchart TD A["Administrative foothold"] --> B["BTR_CLI transaction builder"] subgraph Stage["User-mode staging"] B --> C["Extract signed BTR.sys"] C --> D["Serialize action records"] D --> E["Calculate modified CRC32"] E --> F["RC4 encrypt transaction"] F --> G["Write .sys:changelist ADS"] G --> H["Create service registry data"] end H --> I{"Execution mode"} subgraph Load["Driver activation"] I -->|Runtime| J["Enable SeLoadDriverPrivilege"] J --> K["Call NtLoadDriver"] I -->|Next boot| L["Start 1 system driver"] L --> M["Boot Bus Extender group"] K --> N["BTR.sys DriverEntry"] M --> N end subgraph Kernel["Signed Ring 0 execution"] N --> O["Read and decrypt ADS"] O --> P{"Validate headers and CRCs"} P -->|Invalid| Q["Abort transaction"] P -->|Valid| R["Dispatch action IDs 1 to 6"] R --> S["Write NTSTATUS feedback"] S --> T["Return STATUS_DELETE_PENDING"] end T --> U["Unload and cleanup"] ``` Runtime loading requires an elevated process and `SeLoadDriverPrivilege`, which BTR_CLI attempts to enable in its token before calling `NtLoadDriver`. Microsoft assigns this privilege to administrators by default on client systems and member servers. Microsoft also warns that any principal allowed to load drivers can effectively take control of the system. Those prerequisites are material. BTR Reforged does not help an unprivileged user become an administrator. It gives an existing administrator a quieter and more trusted execution path for operations that may otherwise be blocked by file locks, protected processes, or security-product self-defense. ## The Early-Boot Window The boot variant is more interesting than the runtime path because timing determines which defensive components exist when the transaction runs. The researchers found that configuring `BTR.sys` as a boot-start driver with `Start=0` failed. The driver performs file I/O inside `DriverEntry`, but at that point the storage stack and `\SystemRoot` symbolic link were not ready. The working configuration uses `Start=1`, which maps to a system-start driver, together with the `Boot Bus Extender` group. Microsoft documents that all boot-start drivers load before system-start drivers and that load-order groups sequence drivers within each start class. In the observed trace, the storage and NTFS layers were ready before BTR executed. ```mermaid sequenceDiagram participant OS as Windows loader participant FS as Storage and NTFS participant BTR as BTR.sys participant UM as Defender user mode participant TEL as Telemetry OS->>FS: Load boot-start storage drivers FS-->>OS: SystemRoot and NTFS become available OS->>BTR: Load Start 1 driver by group order BTR->>BTR: Read and validate changelist ADS BTR->>FS: Apply file and registry actions BTR->>TEL: Create BootClean.log and feedback BTR-->>OS: Return STATUS_DELETE_PENDING OS->>UM: Start Defender services later UM->>TEL: Observe post-remediation state ``` In Check Point's Windows 11 trace, BTR loaded roughly 34 seconds before `MsMpEng.exe`. That number is an observation from one trace, not a universal Windows timing guarantee. The reliable point is the relative order: the driver can execute after the filesystem becomes usable but before Defender's main user-mode engine is active. That interval is the useful primitive. A transaction scheduled for the next boot can operate on files that were locked during the previous session and can alter Defender components before the services responsible for normal monitoring and self-defense finish starting. ## The Six Kernel Operations The reconstructed protocol exposes six action identifiers. They are not arbitrary kernel code execution. They form a constrained but operationally useful set of filesystem and registry primitives. | ID | Operation | Important behavior | | ---: | --- | --- | | 1 | Delete file | Can remove files despite exclusive user-mode locks | | 2 | Delete directory | Succeeds only for an empty directory | | 3 | Move or quarantine file | An empty destination becomes deletion; a destination path enables an arbitrary move | | 4 | Delete registry key | Removes a key recursively | | 5 | Delete registry value | Splits the registry path and value name at a double backslash delimiter | | 6 | Set registry value | Creates missing key paths and supports common registry data types | Action 3 has the broadest effect because a move into a protected destination behaves like an arbitrary file placement primitive when the source is attacker-controlled. The published demonstration moved another driver into `System32` after deleting Defender components. That shows composition across actions, not an unrestricted kernel write. Registry actions extend the primitive beyond file removal. Recursive key deletion can dismantle service configuration, while value creation can establish or modify driver and service state for the next boot. The result is a compact kernel operation language executed under Microsoft's signature. ## What the Proof of Concept Proved The researchers tested the technique on Windows 7 SP1, Windows 8.1, Windows 10 22H2, and a fully updated Windows 11 25H2 system as of July 2026. All six actions worked across that stated matrix. This supports broad compatibility across the tested builds, but it does not prove that every Windows edition, Defender engine, or future update behaves identically. The demonstration removed Defender service registry keys at runtime, scheduled deletion of `WdFilter.sys` and `MsMpEng.exe` for boot, and moved another driver into the Windows system directory. These are direct observations from the public proof of concept. Claims about disabling every third-party EDR should remain hypothetical unless separately tested. The public repository includes prebuilt x64 and x86 releases and source intended for Visual Studio 2022 with the v143 Desktop C++ workload and a Windows SDK. Its MIT license covers the proof-of-concept source, not the Microsoft-owned `BTR.sys` fallback binary. That distinction matters when reproducing the research inside a controlled lab. Check Point reported the issue to Microsoft in February 2026. According to the researchers, Microsoft did not plan immediate servicing because exploitation already requires administrator rights and driver-loading privilege. No separate public MSRC advisory or CVE was identified during this review, so that disposition should be attributed to the researchers rather than presented as an independently published Microsoft statement. ## Detection Engineering Hash-only detection is weak here. Check Point found multiple legitimate driver versions, and the normal Defender workflow also creates and loads `BTR.sys`. The useful analytic is behavioral correlation across an unusual driver path, ADS creation, direct service-registry writes, driver load, and cleanup artifacts. | Signal | Event | Suspicious context | | --- | ---: | --- | | Driver load | Sysmon 6 | Microsoft-signed BTR image loaded outside expected Defender remediation context | | Driver or log creation | Sysmon 11 | Random `.sys` file followed by `BootClean.log` activity | | Service key creation | Sysmon 12 | New kernel-driver service under `CurrentControlSet\Services` | | Service value write | Sysmon 13 | `Args` contains `:changelist` or `Group` is `Boot Bus Extender` | | Named stream creation | Sysmon 15 | `.sys:changelist`; `.sys:*.dat` is especially associated with the current PoC | | File deletion | Sysmon 23 | Driver or `BootClean.log` removed soon after load by system context | Legitimate Defender feedback is normally a standalone file under `C:\ProgramData\Microsoft\Windows Defender\Scans\RebootActions\`. The public PoC instead places its feedback in an ADS on the driver. That difference is useful today, but it is an implementation fingerprint, not a protocol requirement. A modified tool could choose a path closer to the legitimate workflow. The following PowerShell reads existing Sysmon telemetry and emits candidate BTR Reforged signals. It does not load a driver or modify the host. Run it from an elevated PowerShell session on a system where Sysmon is already installed and configured to collect the required event IDs. ```powershell param( [datetime]$StartTime = (Get-Date).AddDays(-7) ) $logName = 'Microsoft-Windows-Sysmon/Operational' $eventIds = 6, 11, 12, 13, 15, 23 $events = Get-WinEvent -FilterHashtable @{ LogName = $logName Id = $eventIds StartTime = $StartTime } -ErrorAction Stop $findings = foreach ($event in $events) { [xml]$xml = $event.ToXml() $fields = @{} foreach ($node in $xml.Event.EventData.Data) { $fields[[string]$node.Name] = [string]$node.'#text' } $record = ($fields.GetEnumerator() | ForEach-Object { '{0}={1}' -f $_.Key, $_.Value }) -join '; ' $reasons = [System.Collections.Generic.List[string]]::new() if ($event.Id -eq 15 -and $record -match '\.sys:changelist(?:;|$)') { $reasons.Add('BTR transaction ADS created') } if ($event.Id -in 12, 13 -and $record -match '\\CurrentControlSet\\Services\\' -and $record -match ':changelist|Boot Bus Extender') { $reasons.Add('BTR-like driver service configuration') } if ($event.Id -in 11, 23 -and $record -match '\\SystemRoot\\Temp\\BootClean\.log|\\Windows\\Temp\\BootClean\.log') { $reasons.Add('BTR cleanup log activity') } if ($event.Id -eq 6 -and $record -match '\\(Temp|ProgramData)\\[^;]+\.sys') { $reasons.Add('Driver loaded from a writable staging path') } if ($reasons.Count -gt 0) { [pscustomobject]@{ TimeCreated = $event.TimeCreated EventId = $event.Id Reasons = $reasons -join ', ' Record = $record } } } $findings | Sort-Object TimeCreated | Format-Table -Wrap ``` This is a hunting query, not a production verdict. A useful production rule should correlate signals within the same boot session, record the full service key and driver hash, verify the signer, and compare the creating process against known Defender paths. Alerting on every signed Microsoft driver or every ADS would produce noise without adding confidence. ## Hardening the Boundary The strongest control is preventing an untrusted administrative process from acquiring `SeLoadDriverPrivilege`. Review assignments through Group Policy, constrain privileged service accounts, and separate software deployment from interactive administration. Administrator membership is already a severe boundary failure, but reducing driver-loading authority removes the direct runtime path used by the proof of concept. Application Control remains relevant, but the policy decision is not identical to blocking a retired third-party driver. The Microsoft recommended vulnerable-driver blocklist targets known vulnerable or malicious kernel drivers. `BTR.sys` is an active Defender remediation component, so a bespoke deny rule can break a legitimate security workflow. Microsoft recommends testing driver policy changes in audit mode because incorrect blocks can cause application failure or, in rare cases, a system crash. Protect the inputs as well as the binary. Monitor new service keys that combine `Type=1`, `Start=1`, `Group=Boot Bus Extender`, and an `Args` value referencing `:changelist`. Baseline the paths and parent processes used by legitimate Defender reboot remediation. The same signed image has different risk depending on who extracted it, where it was staged, and which transaction it consumed. Finally, treat successful use as a full administrative compromise. Restoring deleted Defender files is not sufficient. Investigators should preserve the service registry data, ADS content, driver hash, Sysmon logs, and boot telemetry before rebuilding the endpoint or rotating credentials exposed to the compromised administrator context. ## Operational Limits BTR Reforged is powerful because it converts a narrow remediation language into a post-compromise primitive, but the language remains narrow. It does not provide arbitrary kernel memory access, an interactive implant, or a path from standard user to administrator. Its runtime mode depends on a privilege that defenders can audit and restrict. The boot mode also leaves a sequence of persistent artifacts before restart: a driver image, an NTFS ADS, and service configuration. Direct registry creation may avoid the standard Service Control Manager installation event, but it does not erase Sysmon registry telemetry or the underlying disk changes. The current public tooling creates recognizable paths and cleanup behavior. Those fingerprints can change. The durable detection model is the relationship between transaction creation, system-driver registration, signed driver load, early file or registry operations, and feedback cleanup. ## Conclusion BTR Reforged demonstrates a trust-boundary failure rather than a memory-safety failure. Defender's signed remediation driver correctly performs the operations encoded in its transaction. The security problem is that an existing administrator can manufacture that transaction and choose the targets. For red teams, the research is a useful study in protocol recovery, driver-loading semantics, and early-boot execution. For defenders, it is a reminder that signed-driver inventory is only the first layer. Configuration provenance, load context, and target behavior determine whether trusted code is doing trusted work. The practical response is equally specific: restrict driver-loading privilege, correlate the ADS and service artifacts, baseline legitimate Defender remediation, and investigate any BTR load that does not fit that baseline. ## References [BTR Reforged Research](https://research.checkpoint.com/2026/btr-reforged-weaponizing-defenders-remediation-driver-as-a-kernel-operation-primitive/) [BTR CLI Proof of Concept](https://github.com/Dump-GUY/BTR_CLI) [Black Hat USA 2026 Briefings Schedule](https://blackhat.com/us-26/briefings/schedule/) [Sysmon Documentation](https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon) [Load and Unload Device Drivers Policy](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/load-and-unload-device-drivers) [File System Filter Load Order](https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/what-determines-when-a-driver-is-loaded)