Security1 publisher3 min readPublished
Defender's own signed driver becomes the bypass: BTR.sys and the week's trusted-component defects
Check Point says Microsoft's signed BTR.sys remediation driver can be repurposed as a kernel operation engine with no vulnerable driver needed. Signature-based blocking does not apply.
The Watch · Security desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Check Point reverse engineered Microsoft Defender's Defender Boot-Time Removal driver (BTR.sys) and demonstrated it is possible to repurpose the signed remediation driver as a universal kernel operation engine to bypass endpoint security solutions by exploiting a "golden window" between system start and user mode initialization, without relying on the bring your own vulnerable driver (BYOVD) method.
- Security researcher Jiri Vinopal said: "Because BTR.sys is a legitimate Microsoft-signed component, signature-based blocking is ineffective."
- Vinopal said a well-crafted weaponization tool (like BTR_CLI) intentionally mimics the operational footprint of the legitimate Windows Defender remediation process.
- The Hacker News ThreatsDay bulletin frames the week as trouble starting with something trusted doing exactly what it was allowed to do: signed drivers get turned against defenses, legitimate apps help malware blend in, and a weak header check opens a path to code execution.
- The bulletin's headline names a Gogs 10.0 RCE and an n8n workflow-to-RCE among the week's items.
Compiled by The WatchSomething wrong?How this is made
Why it matters
Check Point has reverse engineered BTR.sys, Microsoft Defender's Boot-Time Removal driver, and demonstrated that the signed remediation component can be repurposed as a universal kernel operation engine to bypass endpoint security products, without any bring-your-own-vulnerable-driver step [1]. That takes away the two controls most teams lean on against kernel tampering, because as researcher Jiri Vinopal put it, "Because BTR.sys is a legitimate Microsoft-signed component, signature-based blocking is ineffective" [2].
The timing element matters as much as the signature. According to Check Point, the technique works by exploiting a "golden window" between system start and user mode initialization [1]. That is precisely the interval in which an EDR agent's user-mode components are not yet arbitrating anything, and it is the interval that most detection engineering treats as somebody else's problem. Vinopal also notes that a well-crafted weaponization tool, such as the BTR_CLI proof of concept, "intentionally mimics the operational footprint of the legitimate Windows Defender remediation process" [3]. Behavioural detection on a driver that is supposed to delete things at boot is a hard problem, and the research is explicit that the mimicry is deliberate.
The same bulletin from The Hacker News frames the week's pattern as trusted things doing what they were allowed to do: signed drivers turned against defences, legitimate applications helping malware blend in, and a weak header check opening a path to code execution [4]. Among the named items are a Gogs 10.0 remote code execution issue and an n8n workflow-to-RCE [5]. The summary text we were supplied does not give version-level detail or identifiers for either, so treat the vendor advisories as the source of record before you plan a maintenance window; the operational point stands regardless, which is that self-hosted Git and workflow-automation servers are unauthenticated-reachable code execution targets when they face the internet.
The blend-in half of the pattern has a live example. A new Grandoreiro campaign abuses the legitimate Duplicate Files Finder application to run malicious code by DLL sideloading, and Acronis telemetry puts the activity mostly in Latin America, with Mexico, Spain, Peru and Argentina accounting for most infections [6]. Acronis says the initial sample runs sandbox detection, virtual machine artefact checks, process blacklisting and environment profiling before it tries to reach command-and-control at all [7].
The week's other consequential item is enforcement rather than engineering. The Justice Department charged 17 members of the Mabna Institute, an Iran-based company that since at least 2013 intruded into 144 US universities, 178 foreign universities, at least 42 US and 11 foreign private sector companies, at least five US federal and state agencies, and at least two NGOs [8], which is at least 382 named institutions in total [9]. The DoJ says the campaign ran from approximately 2013 through at least December 2017 [10], that the defendants acted for the Islamic Revolutionary Guard Corps, and that stolen data was resold through Megapaper.ir and Gigapaper.ir [11]. More than 31 TB of academic data and intellectual property was taken, and of more than 100,000 professor accounts targeted, roughly 8,000 were compromised [12], a hit rate near 8 percent [13]. The State Department is offering a $10 million reward for information on five of the defendants or associated individuals and entities [14]. Check Point's Shmuel Gihon called Mabna "the privatization of state espionage: a contractor selling stolen research to whoever's paying, with the IRGC as an anchor client rather than a sole owner" [15].
What to watch: whether Microsoft treats BTR.sys as a component needing hardening or revocation rather than an accepted-risk signed binary, since blocklists do not help here [1][2]. Also watch for exploitation reports against exposed Gogs and n8n instances now that both are named in a widely read bulletin [5].