นักวิจัยด้านความปลอดภัยเปิดเผยจุดบอด (Blind Spot) ใน Microsoft Defender XDR ที่อาจทำให้ทีม Security มองข้ามการเชื่อมต่อ Command and Control (C2) ที่ออกไปยัง Public IP ได้ โดยสาเหตุมาจากวิธีที่ Defender XDR จัดประเภทที่อยู่ IP บางรูปแบบ ทำให้ Detection Rule จำนวนมากที่พึ่งพา Field RemoteIPType มีความเสี่ยงเกิด False Negative
จุดที่น่ากังวลคือปัญหานี้ถูกค้นพบโดยบังเอิญระหว่างการทำ Purple Team Exercise เมื่อ Alert ที่ออกแบบมาเพื่อดักจับ C2 Channel ที่บายพาส Web Proxy ไม่ทำงาน ทั้งที่ Traffic ของการโจมตีถูกบันทึกไว้ในระบบจริง
รากของปัญหาอยู่ที่ไหน
แอปพลิเคชันบน Windows สมัยใหม่จำนวนมากสร้าง Dual-stack Socket ที่สามารถสื่อสารได้ทั้งผ่าน IPv4 และ IPv6 พร้อมกัน เมื่อเกิดกรณีนี้ขึ้น Defender XDR จะไม่ติด Tag ค่า RemoteIPType ของการเชื่อมต่อเป็น "Public" แม้ปลายทางจะเป็น Public IP จริงตามปกติ
แทนที่จะเป็นเช่นนั้น ระบบจะจัดประเภท Record ดังกล่าวเป็น FourToSixMapping ซึ่งหมายถึง IPv4-mapped IPv6 Address ตามมาตรฐาน RFC 4291 (มีรูปแบบคล้าย ::ffff:8.8.8.8)
ผลที่ตามมา: Detection Query จำนวนมากที่เขียนด้วย Kusto Query Language (KQL) และ Filter เฉพาะเงื่อนไข RemoteIPType == "Public" ในตาราง DeviceNetworkEvents จะมองข้าม Traffic กลุ่มนี้ไปโดยสมบูรณ์ แม้ Traffic นั้นจะพุ่งตรงไปยัง Public IP ที่แท้จริงก็ตาม
ทำไมปัญหานี้อันตรายกว่าที่คิด
Blind Spot นี้ไม่ใช่ช่องโหว่ที่ผู้โจมตีต้อง Exploit โดยตรง แต่เป็น ข้อจำกัดในกลไกการตรวจจับ ที่ผู้โจมตีสามารถได้ประโยชน์โดยไม่ต้องรู้ตัวด้วยซ้ำ เพียงแค่ Malware หรือเครื่องมือที่ใช้สร้างการเชื่อมต่อแบบ Dual-stack ตามพฤติกรรมปกติของ Windows ก็เพียงพอที่จะทำให้ Traffic หลุดรอดจาก Detection Rule ที่พึ่งพา RemoteIPType == "Public" ได้
Detection Rule ประเภทที่มีความเสี่ยงสูงต่อปัญหานี้ ได้แก่
- กฎที่ตรวจจับ C2 Communication
- กฎที่ตรวจจับ Suspicious Outbound HTTPS Connection
- กฎที่ตรวจจับ DNS Activity ที่ผิดปกติ
- กฎที่ตรวจจับการใช้งาน Remote Access Tool ที่ไม่ได้รับอนุญาต
- กฎที่ตรวจจับเทคนิค Proxy-bypass
ผลกระทบที่อาจเกิดขึ้น
- C2 Traffic หลุดรอดจากการตรวจจับ แม้จะมีการบันทึก Log ไว้ครบถ้วนในระบบ
- False Sense of Security ทีม SOC อาจเชื่อว่า Detection Coverage ครอบคลุมแล้ว ทั้งที่มี Gap ซ่อนอยู่
- ผลกระทบต่อ Incident Response เพราะการ Investigate ย้อนหลังอาจมองข้าม Connection สำคัญไปเช่นกัน หากใช้ Query แบบเดียวกัน
- กระทบทุกองค์กรที่ใช้ Microsoft Defender XDR และ Microsoft Sentinel ในการเขียน Custom Detection Rule ด้วย KQL
สิ่งที่องค์กรควรทำทันที
- ตรวจสอบ Custom Detection Query ทั้งหมด ใน Microsoft Defender XDR และ Microsoft Sentinel ที่ Filter ด้วยเงื่อนไข
RemoteIPType == "Public" - ปรับปรุง Query ให้ครอบคลุมค่า
FourToSixMappingควบคู่ไปกับPublicเพื่อปิด Blind Spot นี้ - ทดสอบ Detection Rule ด้าน C2 ด้วยการทำ Purple Team Exercise เป็นระยะ เพื่อยืนยันว่า Alert ทำงานได้จริงตามที่ออกแบบไว้
- ทบทวน Detection Rule กลุ่มอื่นที่ใช้
RemoteIPTypeเป็นเงื่อนไขหลัก ไม่ใช่แค่กฎเกี่ยวกับ C2 เท่านั้น - แจ้งทีม Detection Engineering ให้ตรวจสอบ Rule Library ทั้งหมดอย่างเป็นระบบ แทนการแก้ไขทีละ Rule เมื่อพบปัญหา
แนวทางลดความเสี่ยงระยะยาว
1. อย่าพึ่งพา Field เดียวในการตัดสิน Traffic
ควรออกแบบ Detection Logic ให้ใช้หลาย Field ประกอบกัน แทนการ Filter ด้วยเงื่อนไขเดียวที่อาจมีข้อจำกัดที่ยังไม่ทราบ
2. ทำ Detection-as-Code และ Version Control
เพื่อให้สามารถตรวจสอบและปรับปรุง Query จำนวนมากได้อย่างเป็นระบบเมื่อพบปัญหาลักษณะนี้ในอนาคต
3. ทำ Purple Team Exercise เป็นประจำ
ไม่ใช่แค่ตรวจสอบว่า Attack ถูกบันทึกใน Log แต่ต้องยืนยันว่า Alert ที่ควรทำงานได้ทำงานจริง
4. ติดตาม Advisory และ Community Findings เกี่ยวกับเครื่องมือ Detection ที่ใช้งาน
ปัญหาลักษณะนี้มักถูกค้นพบโดยนักวิจัยภายนอกก่อนที่ผู้ผลิตจะประกาศอย่างเป็นทางการ
วิเคราะห์ในมุมมองจาก TXEC
เหตุการณ์นี้เป็นตัวอย่างที่ดีว่า การมี Log ไม่ได้แปลว่าจะตรวจจับได้เสมอไป องค์กรจำนวนมากเข้าใจผิดว่าตราบใดที่ระบบ Logging ทำงานครบถ้วน ทีม Security จะสามารถตรวจพบภัยคุกคามได้ แต่ในความเป็นจริง Detection Logic ที่เขียนขึ้นมาอาจมีข้อจำกัดที่มองไม่เห็นจนกว่าจะมีการทดสอบอย่างจริงจัง
สำหรับองค์กรไทยที่ใช้ Microsoft Defender XDR หรือ Microsoft Sentinel เป็นเครื่องมือหลักในการ Monitor ควรถือว่านี่คือสัญญาณเตือนให้กลับไปทบทวน Detection Rule ที่มีอยู่ทั้งหมด ไม่ใช่แค่รอ Patch จาก Microsoft เพราะ Query ที่องค์กร Custom เขียนขึ้นเองก็มีความเสี่ยงเช่นเดียวกัน
รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า
[ แหล่งอ้างอิง: CyberSecurityNews, GBHackers, Cyberpress, Cryptika Cybersecurity ]