สรุปสั้น
ทีมวิจัยของบริษัท Check Point ได้เปิดเผยเทคนิคที่นำไดรเวอร์ของ Microsoft Defender เองมาใช้เป็นเครื่องมือสั่งงานระดับเคอร์เนล ไดรเวอร์ตัวนั้นคือ BTR.sys หรือ Boot Time Removal Tool ซึ่งเป็นส่วนที่ Defender ใช้เก็บกวาดมัลแวร์ให้เสร็จหลังรีบูต ด้วยการลบไฟล์หรือรายการรีจิสทรีที่ถูกล็อกอยู่ขณะวินโดวส์กำลังทำงาน เทคนิคนี้เปิดทางให้สั่งลบไฟล์ ย้ายไฟล์ ลบคีย์รีจิสทรี และเขียนค่ารีจิสทรีใหม่ได้ตามอำเภอใจในระดับ Ring 0 บนวินโดวส์ตั้งแต่ Windows 7 ไปจนถึง Windows 11 25H2 โดยไม่ต้องอาศัยช่องโหว่ของซอฟต์แวร์ตัวใดเลย และไม่ต้องนำไดรเวอร์จากภายนอกเข้ามาในเครื่อง
จุดที่ทำให้เรื่องนี้ต่างจากการโจมตีแบบนำไดรเวอร์ที่มีช่องโหว่ของตัวเองเข้ามาใช้ หรือที่เรียกว่า bring your own vulnerable driver คือ BTR.sys เป็นคอมโพเนนต์บังคับของวินโดวส์ที่ติดมากับทุกเครื่อง ทำให้ไม่สามารถเพิ่มเข้าไปในบัญชีไดรเวอร์อันตรายของไมโครซอฟท์ หรือสั่งบล็อกผ่าน Windows Defender Application Control ได้เลย เพราะการบล็อกไดรเวอร์ตัวนี้เท่ากับทำให้ Defender เองใช้งานไม่ได้ไปด้วย เทคนิคนี้จึงลบมาตรการรับมือที่ฝ่ายตั้งรับคุ้นเคยที่สุดออกไปตั้งแต่ต้น
นาย Jiří Vinopal นักวิจัยภัยคุกคามและผู้เชี่ยวชาญด้านการวิเคราะห์ย้อนกลับของบริษัท Check Point เป็นผู้นำเสนอผลการวิจัยนี้บนเวทีหลักของงาน Black Hat USA 2026 และ DEF CON 34 ที่นครลาสเวกัส พร้อมเผยแพร่รายงานฉบับเต็มและเครื่องมือพิสูจน์แนวคิดชื่อ BTR_CLI เมื่อวันที่ 20 สิงหาคม 2569 ทั้งนี้ทีมวิจัยระบุชัดว่าไม่พบหลักฐานว่าเทคนิคนี้เคยถูกนำไปใช้โจมตีจริง เงื่อนไขสำคัญที่จำกัดความเสี่ยงคือผู้โจมตีต้องมีบัญชีระดับผู้ดูแลระบบที่ถือสิทธิ์ SeLoadDriverPrivilege อยู่ก่อนแล้ว ซึ่งเป็นเหตุผลที่ศูนย์รับมือด้านความมั่นคงของไมโครซอฟท์ตอบกลับว่ากรณีนี้ยังไม่เข้าเกณฑ์ที่ต้องออกแพตช์แก้ไขทันที
รายละเอียดข่าว
เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 21 สิงหาคม 2569 ว่าทีมวิจัยของบริษัท Check Point ได้เปิดเผยเทคนิคที่ใช้ไดรเวอร์เก็บกวาดตอนบูตของ Microsoft Defender ซึ่งมีลายเซ็นดิจิทัลถูกต้องตามกฎหมาย มาสั่งงานกับไฟล์และรีจิสทรีในระดับเคอร์เนลได้ตามอำเภอใจ บนวินโดวส์ตั้งแต่ Windows 7 จนถึง Windows 11 25H2 โดยไม่มีการใช้ช่องโหว่ของซอฟต์แวร์ใดและไม่มีการนำไดรเวอร์จากนอกเครื่องเข้ามา
ทีมวิจัยระบุไว้อย่างชัดเจนว่ายังไม่พบร่องรอยการนำไปใช้จริง โดยอธิบายว่า “ตลอดการวิเคราะห์ตัวอย่างที่เก็บรวบรวมมาทั้งหมดและแหล่งเทเลเมทรีต่าง ๆ เราไม่พบหลักฐานว่ามีการใช้ BTR.sys ในทางที่ผิดในโลกจริงตามรูปแบบที่สาธิตในงานวิจัยนี้ ซึ่งบ่งชี้ว่าเทคนิคนี้ยังเป็นสิ่งที่ผู้ไม่หวังดียังไม่รู้จักหรือยังไม่ได้ใช้ ทำให้การพัฒนาแนวทางตรวจจับเชิงรุกก่อนที่มันจะถูกนำไปใช้จริงยังเป็นไปได้อยู่” ซึ่งเป็นการวางกรอบที่สำคัญสำหรับผู้อ่าน เพราะเรื่องนี้ยังอยู่ในสถานะงานวิจัย ไม่ใช่การรายงานเหตุโจมตีที่กำลังเกิดขึ้น
ที่มาของงานวิจัยชิ้นนี้ก็ไม่ธรรมดา ทีมวิจัยเล่าไว้ในรายงานว่า “งานวิจัยนี้มีจุดเริ่มต้นระหว่างการสอบสวนเหตุการณ์บุกรุกที่เกี่ยวข้องกับเครื่องที่ถูกเจาะ ซึ่งเทเลเมทรีบางส่วนจากอุปกรณ์ปลายทางดูน่าสงสัย แต่สุดท้ายสาวกลับไปพบว่าเป็นกิจกรรมการเก็บกวาดของ Windows Defender ที่ถูกต้องตามปกติ” กล่าวคือสิ่งที่เริ่มต้นจากการแยกแยะว่าอะไรคือพฤติกรรมปกติของเครื่องมือความปลอดภัยเอง กลับกลายเป็นการค้นพบว่าพฤติกรรมปกตินั้นเองสามารถถูกสวมรอยได้
ตัวไดรเวอร์ BTR.sys ไม่ได้วางอยู่บนดิสก์ในสภาพปกติ แต่ถูกฝังอยู่ในไฟล์ MpEngine.dll ของ Defender ในฐานะทรัพยากรชื่อ BOOTTIMETOOL และจะถูกนำออกมาใช้เมื่อ Defender จำเป็นต้องกำจัดมัลแวร์ให้เสร็จหลังการรีบูต เพื่อลบไฟล์หรือรายการรีจิสทรีที่ถูกล็อกไว้ตอนวินโดวส์ทำงานอยู่ นาย Vinopal ได้วิเคราะห์ย้อนกลับโปรโตคอลธุรกรรมเฉพาะตัวที่ไม่มีเอกสารกำกับของไดรเวอร์ตัวนี้ และพบว่าก้อนข้อมูลการตั้งค่าทุกก้อนที่ส่งให้ BTR.sys ถูกเข้ารหัสด้วย RC4 โดยใช้กุญแจขนาด 256 ไบต์ที่ถูกฝังตายตัวอยู่ในส่วน .rdata ของ BTR.sys ทุกรุ่นที่ออกมาตั้งแต่ Windows 7 และตรวจสอบยืนยันแล้วว่าไม่เคยเปลี่ยนเลยตลอด 18 เวอร์ชัน 64 บิตที่ไม่ซ้ำกัน
ประเด็นสุดท้ายที่ต้องระบุไว้คือสถานะการแก้ไข ทีมวิจัยเขียนไว้ในรายงานว่า “ปัญหานี้ไม่ใช่ช่องโหว่ในความหมายดั้งเดิม แต่เป็นขอบเขตความไว้วางใจเชิงสถาปัตยกรรมที่ถูกข้ามได้หากผู้โจมตีมีสิทธิ์ผู้ดูแลระบบอยู่แล้ว หลังจากการเปิดเผยอย่างมีความรับผิดชอบ MSRC ยืนยันว่าข้อค้นพบเหล่านี้ยังไม่เข้าเกณฑ์ที่ต้องดำเนินการแก้ไขทันที เนื่องจากเทคนิคนี้อาศัยสิทธิ์ผู้ดูแลระบบที่มีอยู่ก่อนแล้ว (SeLoadDriverPrivilege)” ขณะที่หน้าที่เก็บเครื่องมือ BTR_CLI บน GitHub ของนาย Vinopal ระบุเพิ่มเติมว่า “ไม่มีแผนออกแพตช์” ซึ่งเป็นถ้อยคำที่ไมโครซอฟท์ยังไม่ได้ออกมายืนยันต่อสาธารณะ ทั้งนี้สำนักข่าวได้ติดต่อทั้งไมโครซอฟท์เพื่อขอความเห็นเรื่องจุดยืนต่อเทคนิคนี้ และติดต่อทีมวิจัยเพื่อขอรายละเอียดทางเทคนิคเพิ่มเติม แต่ยังไม่ได้รับคำตอบจากทั้งสองฝ่ายจนถึงเวลาที่รายงานถูกเผยแพร่
วิธีการโจมตี
เครื่องมือพิสูจน์แนวคิด BTR_CLI เริ่มจากการค้นหาไฟล์ MpEngine.dll ที่อยู่ใต้โฟลเดอร์ Definition Updates ของ Defender แล้วดึงไบนารี BTR.sys ที่ฝังอยู่ข้างในออกมา จากนั้นจึงประกอบธุรกรรมที่เข้ารหัสอย่างถูกต้องตามโปรโตคอลของไดรเวอร์ ก่อนจะติดตั้งไดรเวอร์เป็นบริการด้วยการเขียนรีจิสทรีลงใต้ HKLM โดยตรง โดยกำหนดค่า Type=1, Start=1 และ Group เป็น “Boot Bus Extender” วิธีนี้ข้ามตัวจัดการบริการของวินโดวส์หรือ Service Control Manager ไปทั้งหมด ผลที่ตามมาซึ่งสำคัญต่อฝ่ายตั้งรับคือไม่มีการบันทึกเหตุการณ์ Windows Event ID 7045 ที่แปลว่ามีการติดตั้งบริการใหม่ ซึ่งเป็นสัญญาณที่ทีมความมั่นคงจำนวนมากใช้เป็นด่านแรกในการจับการวางไดรเวอร์แปลกปลอม
เมื่อไดรเวอร์ถูกโหลดขึ้นมา มันจะดำเนินการตามรายการคำสั่งที่ถูกจัดคิวไว้จากระดับ Ring 0 และในเทเลเมทรีจะถูกระบุว่าเป็นการกระทำของโปรเซส System ซึ่งมีหมายเลขโปรเซสเท่ากับ 4 ความสามารถที่ทำได้ครอบคลุมการลบไฟล์และไดเรกทอรีที่ถูกล็อกอยู่ การย้ายไฟล์ไปยังเส้นทางที่ไม่ถูกจำกัดรวมถึงโฟลเดอร์ System32\drivers การลบคีย์และค่าในรีจิสทรี ตลอดจนการเขียนค่ารีจิสทรีใหม่ได้ทุกชนิด กล่าวคือเป็นชุดความสามารถที่ครบพอจะรื้อโครงสร้างการป้องกันของเครื่องได้ทั้งระบบ โดยที่ทุกการกระทำถูกบันทึกว่ามาจากโปรเซสหลักของระบบปฏิบัติการเอง
จุดที่แหลมคมที่สุดของเทคนิคนี้อยู่ที่โหมดทริกเกอร์แบบที่สอง ซึ่งจัดคิวคำสั่งเหล่านั้นให้ทำงานในการบูตครั้งถัดไป ไดรเวอร์จะทำงานในช่วงที่นาย Vinopal เรียกว่า “golden window” หรือหน้าต่างทอง อันหมายถึงช่วงเวลาหลังจากระบบไฟล์เขียนได้แล้ว แต่ก่อนที่บริการฝั่งผู้ใช้ของ Defender จะเริ่มทำงาน ช่วงเวลานี้เองที่ BTR.sys สามารถลบไบนารีของซอฟต์แวร์ความปลอดภัยอย่าง WdFilter.sys และ MsMpEng.exe ออกไปได้จริง ๆ ก่อนที่โปรแกรมเหล่านั้นจะทันล็อกตัวเองไว้ การสาธิตสดบนเวที Black Hat แสดงให้เห็น BTR_CLI ลบชุด Defender ทั้งหมดออกจากเครื่อง Windows 11 25H2 ที่อัปเดตครบและเปิด Tamper Protection ไว้
เงื่อนไขที่จำกัดขอบเขตของเทคนิคนี้คือผู้โจมตีต้องมีบัญชีระดับผู้ดูแลระบบที่ถือสิทธิ์ SeLoadDriverPrivilege อยู่ก่อน โดยเครื่องมือจะเปิดใช้สิทธิ์นั้นให้อัตโนมัติสำหรับบัญชีที่มีสิทธิ์อยู่แล้ว นั่นหมายความว่าเทคนิคนี้ไม่ใช่ทางเข้าเครื่อง แต่เป็นสิ่งที่ผู้โจมตีทำหลังจากเข้ามาได้แล้วเพื่อกวาดล้างเครื่องมือตรวจจับทิ้ง ซึ่งเป็นขั้นตอนที่ในทางปฏิบัติมีความสำคัญไม่แพ้ขั้นตอนเจาะเข้ามา เพราะเป็นตัวชี้ว่าผู้ป้องกันจะได้เห็นสิ่งที่เกิดขึ้นต่อจากนั้นหรือไม่
ในแง่พัฒนาการของเทคนิค การใช้ไดรเวอร์ที่ติดมากับวินโดวส์เองแทนไดรเวอร์บุคคลที่สามที่มีช่องโหว่นั้นเคยปรากฏมาก่อนแล้วในกรณี AvNeutralizer ของกลุ่ม FIN7 ซึ่งนำไดรเวอร์ ProcLaunchMon.sys ของวินโดวส์มาใช้ร่วมกับไดรเวอร์ของ Process Explorer เพื่อรบกวนการทำงานของซอฟต์แวร์ป้องกันอุปกรณ์ปลายทาง สิ่งที่งานวิจัยชิ้นนี้เพิ่มเข้ามาคือการยกระดับจากการรบกวนไปสู่การลบทิ้งทั้งชุด และการเลือกไดรเวอร์ที่บล็อกไม่ได้เลยเพราะเป็นส่วนหนึ่งของตัวเครื่องมือป้องกันเอง
นอกจากนี้ BTR.sys ยังเคยถูกนักวิจัยความปลอดภัยตรวจสอบมาก่อนแล้วเมื่อห้าปีก่อนด้วยประเด็นคนละแบบ ในเดือนกุมภาพันธ์ 2564 นาย Kasif Dekel นักวิจัยจาก SentinelLabs ได้เปิดเผยช่องโหว่ CVE-2021-24092 ซึ่งเป็นช่องโหว่ยกระดับสิทธิ์ที่เปิดทางให้ผู้ใช้ทั่วไปที่ไม่ใช่ผู้ดูแลระบบเขียนทับไฟล์ใดก็ได้ ด้วยการวาง hard link ไว้ที่เส้นทางไฟล์บันทึกของไดรเวอร์ ไมโครซอฟท์ออกแพตช์แก้ CVE-2021-24092 เมื่อวันที่ 9 กุมภาพันธ์ 2564 โดยนาย Dekel อธิบายไว้ในตอนนั้นว่า “เราสันนิษฐานว่าช่องโหว่นี้ไม่ถูกค้นพบมาจนถึงตอนนี้เพราะปกติไดรเวอร์ตัวนี้ไม่ได้อยู่บนฮาร์ดดิสก์ แต่ถูกวางลงและเรียกใช้เมื่อจำเป็น (ด้วยชื่อแบบสุ่ม) แล้วก็ถูกล้างทิ้งไป” ซึ่งเป็นคำอธิบายเดียวกับที่ทำให้ไดรเวอร์ตัวนี้อยู่นอกสายตาของทั้งผู้โจมตีและผู้ป้องกันมาโดยตลอด
ผลกระทบ
ผลกระทบที่แท้จริงของงานวิจัยชิ้นนี้ไม่ใช่ความเสี่ยงเฉพาะหน้า เพราะเงื่อนไขการใช้งานต้องการสิทธิ์ผู้ดูแลระบบอยู่ก่อนแล้ว องค์กรที่ผู้โจมตีเข้าถึงระดับนั้นได้ก็มีปัญหาหนักอยู่แล้วโดยไม่ต้องพึ่งเทคนิคนี้ สิ่งที่เปลี่ยนไปคือสมมติฐานที่ทีมความมั่นคงจำนวนมากใช้ในการวางแผนรับมือ นั่นคือความเชื่อว่าเครื่องมือตรวจจับบนอุปกรณ์ปลายทางจะยังคงส่งข้อมูลออกมาให้เห็นได้แม้ผู้โจมตีจะได้สิทธิ์ผู้ดูแลระบบไปแล้ว เมื่อชุด Defender ทั้งหมดถูกลบออกได้ในหน้าต่างเวลาก่อนที่มันจะเริ่มทำงาน สมมติฐานนั้นก็ไม่เป็นจริงอีกต่อไป
สิ่งที่ทำให้เรื่องนี้ยากกว่าการโจมตีด้วยไดรเวอร์ที่มีช่องโหว่แบบเดิมคือกลไกรับมือมาตรฐานใช้ไม่ได้ทั้งหมด บัญชีไดรเวอร์อันตรายของไมโครซอฟท์และการควบคุมผ่าน Windows Defender Application Control ทำงานได้บนหลักการว่ามีไดรเวอร์บางตัวที่ควรถูกปฏิเสธ แต่ BTR.sys เป็นไดรเวอร์ที่ต้องอนุญาตเสมอเพราะระบบป้องกันเองต้องใช้ กุญแจ RC4 ที่ฝังตายตัวและไม่เคยเปลี่ยนตลอด 18 เวอร์ชันตั้งแต่ Windows 7 ยิ่งทำให้เทคนิคนี้ใช้ได้กับเครื่องแทบทุกรุ่นที่ยังใช้งานอยู่ในองค์กร โดยไม่ต้องปรับแต่งอะไรตามเวอร์ชัน
อีกมุมที่ควรพิจารณาคือผลต่องานสอบสวนหลังเกิดเหตุ เมื่อทุกการกระทำถูกบันทึกว่ามาจากโปรเซส System หมายเลข 4 และการติดตั้งบริการไม่ทิ้งเหตุการณ์ 7045 ไว้ ร่องรอยที่นักสอบสวนคุ้นเคยก็หายไปสองชั้นพร้อมกัน ยิ่งไปกว่านั้นต้นเรื่องของงานวิจัยนี้เองก็มาจากการที่ทีมรับมือเหตุเห็นเทเลเมทรีน่าสงสัยแล้วสรุปว่าเป็นการทำงานปกติของ Defender ซึ่งสะท้อนอีกด้านหนึ่งของปัญหาว่า พฤติกรรมของเครื่องมือความปลอดภัยเองมักถูกจัดเป็นสิ่งที่ไม่ต้องสงสัยโดยอัตโนมัติ และนั่นคือพื้นที่ที่ผู้โจมตีจะได้ประโยชน์มากที่สุดหากวันหนึ่งเทคนิคนี้ถูกนำไปใช้จริง
ในแง่ระยะเวลา ข้อเท็จจริงที่ว่าไมโครซอฟท์ประเมินว่ายังไม่เข้าเกณฑ์ต้องแก้ไขทันที และเครื่องมือพิสูจน์แนวคิดถูกเผยแพร่พร้อมไบนารีสำเร็จรูปแล้ว หมายความว่าองค์กรไม่สามารถรอแพตช์ได้ มาตรการที่เหลืออยู่จึงเป็นเรื่องของการจำกัดสิทธิ์และการตรวจจับพฤติกรรมล้วน ๆ ซึ่งเป็นงานที่ต้องลงมือเองทั้งหมด
คำแนะนำ
มาตรการเสริมความแข็งแกร่งหลักที่ทีมวิจัยแนะนำคือการจำกัดการมอบสิทธิ์ SeLoadDriverPrivilege ให้เหลือน้อยที่สุดเท่าที่จำเป็น เพราะสิทธิ์นี้คือเงื่อนไขบังคับของเทคนิคทั้งหมด องค์กรควรตรวจสอบว่าปัจจุบันมีกลุ่มหรือบัญชีใดบ้างที่ได้รับสิทธิ์นี้ผ่านนโยบายกลุ่ม และในหลายกรณีจะพบว่าสิทธิ์ถูกให้ไว้กับกลุ่มผู้ดูแลระบบทั้งกลุ่มโดยไม่มีใครทบทวนมานาน การลดจำนวนบัญชีที่ถือสิทธิ์นี้ลงมีผลโดยตรงต่อการลดพื้นที่โจมตีมากกว่ามาตรการอื่นใดในกรณีนี้
ในด้านการตรวจจับ ควรนำเงื่อนไขที่ทีมวิจัยระบุไว้ไปสร้างเป็นกฎเฝ้าระวังล่วงหน้า เนื่องจากยังไม่มีการนำเทคนิคนี้ไปใช้จริง นี่จึงเป็นโอกาสไม่บ่อยนักที่ฝ่ายตั้งรับได้เตรียมตัวก่อนฝ่ายโจมตีจะลงมือ โดยเฉพาะกฎที่จับการเขียนรีจิสทรีสร้างบริการที่มีค่า Group เป็น “Boot Bus Extender” โดยไม่มีเหตุการณ์ 7045 ตามมา ซึ่งเป็นลายเซ็นที่ตรงกับวิธีติดตั้งของเครื่องมือนี้โดยตรง
นอกจากนี้ควรทบทวนสมมติฐานของแผนรับมือเหตุที่พึ่งพาเทเลเมทรีจากอุปกรณ์ปลายทางเป็นหลัก โดยเพิ่มการส่งล็อกออกไปเก็บนอกเครื่องแบบต่อเนื่อง เพื่อให้ยังมีหลักฐานเหลืออยู่แม้เครื่องมือบนเครื่องจะถูกลบไปแล้ว ควบคู่กับการตั้งการแจ้งเตือนเมื่อบริการหรือไดรเวอร์ของระบบป้องกันหยุดส่งข้อมูลกะทันหัน เพราะในสถานการณ์แบบนี้ ความเงียบของเซนเซอร์คือสัญญาณเตือน ไม่ใช่สัญญาณว่าทุกอย่างปกติ สุดท้าย ควรระวังการตั้งกฎยกเว้นแบบเหมารวมให้กับพฤติกรรมของเครื่องมือความปลอดภัยเอง เพราะเป็นชุดสมมติฐานเดียวกับที่ทำให้กิจกรรมของ BTR.sys ถูกมองข้ามมาตลอด
สัญญาณสำหรับการตรวจจับ
ทีมวิจัยของบริษัท Check Point ระบุเงื่อนไขจาก Sysmon และเหตุการณ์ของวินโดวส์ที่ควรใช้เฝ้าระวังการนำ BTR.sys ไปใช้ในทางที่ผิดไว้ดังนี้
| เงื่อนไข | สิ่งที่บ่งชี้ |
|---|---|
Sysmon Event ID 15 (FileCreateStreamHash) ที่ชื่อไฟล์เป้าหมายลงท้ายด้วย .sys:changelist | การเขียนข้อมูลการตั้งค่าที่เข้ารหัสไว้ลงใน Alternate Data Stream ของไฟล์ไดรเวอร์ |
RegistryEvent (Sysmon Event ID 12 หรือ 13) ที่สร้างคีย์ของบริการซึ่งค่า Args มีคำว่า :changelist และค่า Group เป็น “Boot Bus Extender” | การติดตั้งไดรเวอร์เป็นบริการโดยข้าม Service Control Manager โดยเฉพาะเมื่อไม่มี Windows Event ID 7045 ตามมา |
Sysmon Event ID 11 (FileCreate) และ 23 (FileDelete) ที่บันทึกการสร้างและลบไฟล์ \SystemRoot\Temp\BootClean.log อย่างรวดเร็วโดยโปรเซส System (PID 4) | เส้นทางไฟล์บันทึกที่ถูกฝังตายตัวไว้ในไดรเวอร์ ซึ่งจะถูกเขียนทุกครั้งไม่ว่าผู้เรียกจะเป็นใคร |
| Sysmon Event ID 6 (DriverLoad) ตามด้วย Sysmon Event ID 23 (FileDelete) ทันทีโดยโปรเซส System (PID 4) | ลายนิ้วมือของการทำงานในระดับเคอร์เนลขณะ BTR.sys ถูกทริกเกอร์จริง |
แหล่งอ้างอิง
- Check Point Research — BTR Reforged: Weaponizing Defender’s Remediation Driver as a Kernel Operation Primitive
- SentinelLabs — CVE-2021-24092: 12 Years in Hiding, a Privilege Escalation Vulnerability in Windows Defender
- The Hacker News — Microsoft Defender’s Own Driver Can Be Weaponized to Delete Security Software at Boot
