สรุปสั้น

ทีมวิจัยของบริษัท 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 ถูกทริกเกอร์จริง

แหล่งอ้างอิง