BTR Reforged Defender Kernel 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.

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.

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.

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

BTR CLI Proof of Concept

Black Hat USA 2026 Briefings Schedule

Sysmon Documentation

Load and Unload Device Drivers Policy

File System Filter Load Order