สรุปสั้น
เครื่องมือ OpenSource ประเภท red team ที่เพิ่งเปิดตัวใหม่ชื่อ EDRChoker นำเสนอเทคนิคใหม่ในการปิดการตรวจจับของ EDR (Endpoint Detection and Response) ประเภทที่เชื่อมต่อด้วยระบบคลาวด์ ไม่ใช่วิธีการ kill process หรือใส่โค้ดแปลกปลอม Code Injection แต่ดำเนินการด้วยการแอบบีบแบนด์วิดท์เครือข่ายของให้เหลือเกือบศูนย์ โดยใช้กลไก Policy-Based Quality of Service (QoS) ที่มีมากับระบบปฏิบัติการ Windows ซึ่งเป็นกลไกการจัดลำดับความสำคัญและบริหารจัดการการรับส่งข้อมูลในระบบเครือข่าย
EDRChoker พัฒนาโดยนักวิจัยความปลอดภัยไซเบอร์ @TwoSevenOneT เครื่องมือนี้ใช้ประโยชน์จาก Windows Policy-Based QoS เพื่อจำกัดความเร็วในการรับ-ส่งข้อมูล (throttle) process ของ EDR ทำให้แบนด์วิดท์เหลือเกือบศูนย์ ส่งผลให้ EDR ถูกตัดขาดจากโครงสร้างการรับ command ของตัวเอง ซึ่งปกติ EDR สมัยใหม่พึ่งพาการเชื่อมต่อแบบ persistent และ low-latency ระหว่าง agent ที่อยู่ปลายทางกับเซิร์ฟเวอร์บริหารจัดการระบบ EDR บนคลาวด์
ความสัมพันธ์กับเซิร์ฟเวอร์นี้เป็นหัวใจของกระบวนการรวบรวมข้อมูลจากระยะไกล (telemetry) การ ตรวจจับความสัมพันธ์กับภัยคุกคาม (correlate) และการควบคุมจากผู้ดูแลความปลอดภัยไซเบอร์ หากตัดการเชื่อมต่อนี้ จะทำให้ EDR agent ไม่สามารถทำงานได้อย่างมีประสิทธิภาพ ไม่สามารถรายงานการตรวจจับ รับนโยบายที่อัปเดต หรือรับคำสั่งจากระยะไกลจากผู้ดูแลได้ การพึ่งพาเชิงสถาปัตยกรรมนี้คือสิ่งที่ EDRChoker ใช้แสวงประโยชน์ ในการโจมตี
รายละเอียดข่าว
เว็บไซต์ Cyber Security News รายงานเมื่อวันที่ 7 มิถุนายน พ.ศ. 2569 ว่า อดีต เมื่อ red team ใช้วิธีหลักสองอย่างในการตัดการสื่อสารของ EDR คือ การใช้ Windows Defender Firewall rule และการเรียก Windows Filtering Platform (WFP) API เช่น เครื่องมือ EDRSilencer ที่ใช้ FwpmFilterAdd0 API เพื่อลงทะเบียน network filter ขาออกที่เลือก drop แพ็กเก็ตของ EDR agent
ข้อจำกัดสำคัญ คือ การบล็อกแบบ WFP นั้นสร้าง event packet-block และ packet-drop ที่แพลตฟอร์มความปลอดภัยอย่าง Elastic Defend ตรวจจับได้ผ่าน detection rule เฉพาะ และยกเป็น alert ทันที
EDRChoker แก้ปัญหานี้ด้วยการใช้คำสั่งสร้าง QoS policy ที่ตั้ง ThrottleRateActionBitsPerSecond เป็น 8 ที่ความเร็ว 8 bps การทำ TLS handshake มาตรฐานซึ่งต้องใช้ข้อมูล certificate chain ระหว่าง 3 KB ถึง 6 KB กลายเป็นสิ่งที่ทำไม่ได้
EDR agent จึง time out ไม่สามารถที่จะแลกเปลี่ยนข้อมูลแพ็กเก็ตไม่ได้แม้แต่ตัวเดียว ทำให้เกิด error แบบ connection-dropped แทนที่จะเป็น firewall block event ที่ตรวจจับได้
ข้อได้เปรียบทางเทคนิคของ EDRChoker เป็นเชิงสถาปัตยกรรม คือ การ throttle ด้วย QoS ถูกบังคับใช้โดย pacer.sys ซึ่งเป็น NDIS Lightweight Filter Driver ที่ทำงานอยู่เหนือ NIC ทางกายภาพโดยตรง ต่ำกว่า WFP หนึ่งชั้นในสแตกเครือข่ายของ Windows
รายละเอียดช่องโหว่
ลำดับของสแตกมีความสำคัญ WFP อยู่ภายใน tcpip.sys ที่ชั้น Transport ส่วน pacer.sys ดักจับ raw Ethernet frame ที่ขอบเขต NDIS ซึ่งใกล้ฮาร์ดแวร์มากกว่า เนื่องจาก pacer.sys ทำงานที่ระดับสิทธิ์ต่ำกว่าในสแตก กฎของมันจึงควบคุมแพ็กเก็ตที่เครื่องมือ monitoring ระดับ WFP ของ EDR เข้าไม่ถึง
นักวิจัย @TwoSevenOneT ระบุว่า EDRChoker รับไฟล์ input ที่เป็นรายชื่อ process ของ EDR แล้วสร้าง QoS policy ที่ตั้งชื่อไม่ซ้ำกันโดยอัตโนมัติ (ชื่อ process + random GUID ต่อการรันแต่ละครั้ง) เพื่อให้แน่ใจว่าไม่มีการ deploy สองครั้งใดสร้าง rule signature ที่เหมือนกัน เครื่องมือนี้ซึ่งเปิดให้ใช้บน GitHub ซึ่งทำงานได้สองโหมด คือ
- Remove mode ที่รันโดยไม่มีพารามิเตอร์เพื่อล้าง QoS policy ที่ติดตั้งทั้งหมด
- Install mode ที่รับไฟล์รายชื่อ process EDR แล้วสร้าง QoS policy ชื่อไม่ซ้ำที่อยู่รอดข้าม reboot
เทคนิคนี้ตอกย้ำความจริงเชิงสถาปัตยกรรมว่า EDR ที่พึ่งพาการเชื่อมต่อด้วยคลาวด์ทั้งหมดมี single point of failure โดยธรรมชาติ
ผลกระทบต่อไทย
องค์กรไทยจำนวนมากในภาคการเงิน หน่วยงานรัฐ และองค์กรขนาดใหญ่ ลงทุนในโซลูชัน EDR ที่เชื่อมต่อคลาวด์เป็นแนวป้องกันหลักของ endpoint
เทคนิคแบบ EDRChoker เป็นความเสี่ยงโดยตรงเพราะมันทำให้ EDR เงียบ ไม่ตรวจพบความผิดปกติใด ๆ โดยไม่มีการ kill process จึงไม่กระตุ้นเกิดการแจ้งเตือน alert ตามปกติ และหลบเหลี่ยง detection rule ที่ตรวจจับการบล็อกแบบ WFP ได้
หากผู้โจมตีเข้าถึงเครื่องในองค์กรไทยและใช้เทคนิคนี้ ทีม SOC อาจเข้าใจผิดว่า endpoint ยังปลอดภัยทั้งที่จริง EDR ถูกตัดขาดจากเซิร์ฟเวอร์และมองไม่เห็นกิจกรรมอันตราย ช่องว่างการมองเห็นนี้อันตรายอย่างยิ่งในช่วงที่ผู้โจมตีดำเนินการขั้นต่อไป เช่น การฝัง ransomware หรือขโมยข้อมูล แม้ EDRChoker จะต้องอาศัยสิทธิ์ระดับสูงในการสร้าง QoS policy แต่ผู้โจมตีที่ยกระดับสิทธิ์สำเร็จแล้วก็ใช้มันได้
คำแนะนำ
ทีมรักษาความปลอดภัยไซเบอร์ควรขยายการ monitoring ให้ลึกถึงระดับ NDIS และ QoS ไม่ใช่แค่ระดับ WFP เฝ้าระวังการสร้างหรือแก้ไข Net QoS policy ที่ผิดปกติ โดยเฉพาะ policy ที่ตั้ง ThrottleRate ต่ำผิดปกติและชี้ไปยัง process ของ EDR ตรวจสอบ alert แบบ connection-dropped หรือ EDR agent ที่หยุดส่ง telemetry กะทันหันโดยไม่มีสาเหตุ ซึ่งอาจเป็นสัญญาณว่าถูก choke ใช้การตรวจสอบสถานะ (health check) ของ EDR agent จากฝั่งเซิร์ฟเวอร์ เพื่อตรวจจับ endpoint ที่ขาดการติดต่อ บังคับหลัก least privilege เพื่อจำกัดไม่ให้ผู้ใช้ทั่วไปสร้าง QoS policy ได้ และพิจารณาใช้ EDR ที่มีความสามารถ local detection หรือ tamper protection ที่ไม่พึ่งพาการเชื่อมต่อคลาวด์เพียงอย่างเดียว เพื่อลดความเสี่ยงจาก single point of failure