Check Point Research published a detailed reverse-engineering report on Microsoft Defender’s Boot-Time Removal driver, commonly referenced as BTR.sys. Their research shows how a legitimate, Microsoft-signed remediation component can be repurposed into a powerful early-boot file and registry operation primitive.

The important point for defenders is not that Windows Defender is “malware.” It is that trusted security tooling can expose high-privilege behaviors that look very similar to attacker tradecraft when they are staged, triggered, or abused outside the expected remediation path.

What Check Point found

The report describes a Windows Defender remediation driver that is dropped and loaded when Defender needs to perform boot-time cleanup, such as removing locked files. The driver is signed, legitimate, and designed to execute one-shot remediation transactions before unloading itself.

Check Point’s researchers found that the transaction mechanism can be reconstructed and used to ask the driver to perform kernel-level file and registry operations. In practical terms, that means a trusted defensive component can become a way to delete files, move files, alter registry values, and interfere with endpoint security controls during a window where normal user-mode defenses may not yet be fully active.

The research also highlights behaviors defenders should care about during incident response: randomized driver and service names, alternate data streams used for configuration, boot-time execution, cleanup behavior, and log removal patterns. Those indicators can be easy to misread because some of them also occur during legitimate Defender activity.

Why this matters

Many small businesses and government contractors rely heavily on the trust boundary around signed Microsoft components. That trust is necessary, but it should not become blind trust. Attackers increasingly look for ways to operate through legitimate administrative, security, and system components because those actions blend into normal telemetry better than obvious malware.

This research fits that pattern. It is not a classic bring-your-own-vulnerable-driver case where the attacker introduces a known bad third-party driver. The more uncomfortable lesson is that a built-in remediation path can provide sensitive primitives if an adversary can stage and trigger it in the right context.

Defensive takeaways

  • Baseline Defender remediation activity. Know what legitimate boot-time cleanup looks like in your environment so random driver/service creation does not get dismissed or over-escalated without context.
  • Monitor system-start driver creation. Pay attention to new kernel-driver services, especially randomized names, unusual ImagePath values, and boot/system start configurations.
  • Watch for alternate data streams in sensitive paths. ADS usage under driver or system directories should be rare enough to justify investigation.
  • Correlate registry and file tampering after reboot. If an endpoint security service, policy key, startup entry, or protected file changes during boot, treat that as a high-signal event.
  • Do not rely on signature alone. Signed does not always mean safe in the operational context. Evaluate parent process, staging path, service configuration, timing, and intended use.
  • Include security-tool abuse in IR playbooks. When containment fails or controls disappear after reboot, investigate whether trusted remediation, update, backup, or management components were used as the mechanism.

Bulwark Black assessment

This is the kind of research that should push defenders toward behavior-based validation. For SMBs and government contractors, the highest-value move is not chasing every proof-of-concept detail. It is building detections and runbooks around privileged system changes that happen during reboot, especially when those changes affect endpoint protection, persistence locations, or sensitive files.

Security teams should also review whether their EDR, SIEM, and Windows logging pipelines preserve enough evidence across reboot boundaries. If boot-time activity only becomes visible after the endpoint is already back online and cleaned up, the investigation starts with missing context.

Original research: Check Point Research — BTR Reforged: Weaponizing Defender’s Remediation Driver as a Kernel Operation Primitive.