<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Kernel-Level on CuraSec</title><link>https://curasec.metacog.co.kr/tags/kernel-level/</link><description>Recent content in Kernel-Level on CuraSec</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sat, 22 Aug 2026 11:32:44 +0000</lastBuildDate><atom:link href="https://curasec.metacog.co.kr/tags/kernel-level/index.xml" rel="self" type="application/rss+xml"/><item><title>Microsoft Defender's BTR.sys Driver Abused to Delete Security Tools at Boot</title><link>https://curasec.metacog.co.kr/insights/2026-08-22-microsoft-defender-s-own-driver-can-be-weaponized-to-delete/</link><pubDate>Sat, 22 Aug 2026 11:32:44 +0000</pubDate><guid>https://curasec.metacog.co.kr/insights/2026-08-22-microsoft-defender-s-own-driver-can-be-weaponized-to-delete/</guid><description>&lt;ul>
&lt;li>&lt;strong>Engineer — Learn:&lt;/strong> No exploitable flaw and no patch exists — this is abuse of a legitimately signed Defender component, so there&amp;rsquo;s nothing to patch; understand the technique and evaluate whether existing attack surface reduction or kernel driver allow-listing policies limit BTR.sys invocation outside Defender&amp;rsquo;s normal use.&lt;/li>
&lt;li>&lt;strong>SOC/IR — Plan:&lt;/strong> Novel boot-time EDR-disablement technique worth building detections for: plan to hunt for anomalous BTR.sys loading events or unexpected security product file/registry removal at boot, and check whether your EDR vendor provides detection coverage for this abuse pattern.&lt;/li>
&lt;li>&lt;strong>Leader — Learn:&lt;/strong> Research disclosure with no active exploitation signals; relevant background if stakeholders ask about Defender&amp;rsquo;s reliability as a security control, but no leadership action is required at this time.&lt;/li>
&lt;/ul></description></item></channel></rss>