RedSun: ช่องโหว่ Zero-day บน Windows เมื่อ Defender กลายเป็นผู้โจมตี

Windows Defender ถูกติดตั้ง และเปิดใช้งานเป็นค่าเริ่มต้นใน Windows ทุกเครื่อง โดยทำงานด้วยสิทธิ์ระดับสูงสุด (SYSTEM) เพื่อให้สามารถตรวจสอบไฟล์ และจัดการภัยคุกคามได้อย่างครอบคลุม ซึ่งสิทธิ์ระดับที่ 'แตะต้องได้ทุกอย่าง' นี้เอง คือหัวใจสำคัญที่ทำให้แอนติไวรัสทำงานได้จริง แต่ในขณะเดียวกันความไว้วางใจดังกล่าวนั้นกลับกลายเป็นจุดอ่อนที่สามารถถูกนำมาใช้โจมตีได้เช่นกัน

นักวิจัยด้านความปลอดภัยนามแฝง 'Chaotic Eclipse' ได้เผยแพร่ Exploit สำหรับการยกระดับสิทธิ์ในระบบ Windows ออกสู่สาธารณะ โดย Exploit ดังกล่าวมีชื่อเรียกว่า 'RedSun' ซึ่งมุ่งเป้าไปที่ Logic ในกระบวนการ Remediation (การจัดการไฟล์) ของ Windows Defender ซึ่งช่วยให้ User ที่ไม่มีสิทธิ์ Admin สามารถรันโค้ดในระดับ SYSTEM บนเครื่อง Windows ที่ลงแพตช์อัปเดตล่าสุดได้

สาเหตุหลักเกิดจากการขาดการตรวจสอบ Reparse Point ในไฟล์ MpSvc.dll ซึ่งเป็น Malware Protection Engine ตัวหลักที่ถูกเรียกใช้งานโดย MsMpEng.exe เพื่อจัดการ Logic ในการสแกน, ตรวจจับ และทำ Remediation ทั้งหมด

เมื่อ Defender ตรวจพบไฟล์อันตรายที่มีคุณสมบัติเป็น Cloud Files ระบบจะพยายามทำการ Restore ไฟล์นั้นกลับไปยัง Original Detection Path โดยกระบวนการเขียนข้อมูลนี้เกิดขึ้นโดยไม่ได้ตรวจสอบว่าเส้นทางปลายทางดังกล่าวถูก Redirect ผ่าน Junction Point ไปยังตำแหน่งอื่นแล้วหรือไม่

ด้วยการวางเงื่อนไขเรื่อง Timing ให้กระบวนการ Restore ทำงานสอดคล้องกับการทำ Batch OPLOCK แล้วทำการสลับไดเรกทอรีปลายทางด้วย Mount Point Reparse ไปที่ C:\Windows\System32 ผู้โจมตีจึงสามารถทำให้ Defender เขียนไฟล์ Binary ใด ๆ ลงในโฟลเดอร์ System32 แทนตนเองได้

Exploit ดังกล่าวได้รับการยืนยันแล้วว่าสามารถใช้งานได้จริงบน Windows 11 25H2 Build 26200.8246 แม้จะเปิดใช้งานระบบป้องกันแบบ Real-time Protection ไว้อย่างเต็มรูปแบบก็ตาม และมีความเป็นไปได้สูงว่าช่องโหว่นี้จะส่งผลกระทบต่อ Windows เวอร์ชันอื่น ๆ ด้วยเช่นกัน

Technical Background

RedSun ทำงานโดยการนำฟีเจอร์พื้นฐานของ Windows จำนวน 4 อย่างที่ทำงานถูกต้องตาม Documentation มาเชื่อมโยงเข้าด้วยกันเพื่อสร้าง Exploit Primitive โดยที่องค์ประกอบแต่ละส่วนไม่ได้มีช่องโหว่ในตัวมันเอง แต่ข้อผิดพลาดเกิดขึ้นจากการทำงานร่วมกันภายใต้ Timing Condition ที่เฉพาะเจาะจง

Opportunistic Locks (OPLOCKs)

OPLOCK คือกลไกแจ้งเตือนโปรเซสที่เปิดไฟล์ค้างไว้ เมื่อมีการพยายามเข้าถึงไฟล์เดียวกันจากโปรเซสอื่น โดยเฉพาะ Batch OPLOCK ที่จะรวบรวมคำสั่งจัดการไฟล์ไว้ด้วยกัน และจะทำการ Break เพื่อบังคับให้โปรเซสที่ถือครองไฟล์อยู่ต้องยกเลิกการถือครอง ก่อนที่โปรเซสใหม่จะเข้าถึงไฟล์นั้นได้

ผู้โจมตีเลือกใช้ Batch OPLOCK เป็น 'Timing Instrument' เพื่อขัดจังหวะ และหน่วงให้ Defender ติดสถานะ Blocked ในขั้นตอนที่ต้องการ ซึ่งเทคนิคนี้ช่วยเปลี่ยนการโจมตีแบบ Race Condition ที่ปกติจะควบคุมผลลัพธ์ได้ยาก ให้กลายเป็นการโจมตีที่แม่นยำ และสามารถกำหนดผลลัพธ์ได้โดยสมบูรณ์

Cloud Files API

Windows Cloud Files API (CfApi.dll) คือโครงสร้างพื้นฐานสำหรับบริการ Cloud Sync อย่าง OneDrive โดยเปิดให้โปรเซสต่าง ๆ สามารถลงทะเบียนไดเรกทอรีเป็น Sync Root เพื่อสร้าง Placeholder Files ซึ่งเป็นไฟล์จำลองขนาดเล็ก (Stub) สำหรับใช้เป็นตัวแทนของข้อมูลบนคลาวด์ที่ยังไม่ได้ดาวน์โหลดลงมาที่เครื่อง

การสร้างไฟล์ Placeholder ที่กำกับด้วยแฟล็ก CF_PLACEHOLDER_CREATE_FLAG_MARK_IN_SYNC จะเป็นการส่งสัญญาณบอกระบบว่าไฟล์นี้อัปเดตเป็นปัจจุบันแล้ว เพื่อระงับการเรียกใช้งาน Hydration Callbacks (กระบวนการดึงข้อมูลจริงจากคลาวด์) ในการโจมตีนี้ ผู้โจมตีจะสร้าง Cloud Files Placeholder ขึ้นในไดเรกทอรีของตนเอง เพื่อใช้เป็นไฟล์ที่ผู้โจมตีควบคุมได้ในการหลอกให้ Scanner ของ Defender เข้ามาตรวจสอบ

Volume Shadow Copy Service (VSS)

VSS คือ Service ของ Windows ที่มีหน้าที่สร้าง Snapshot ของข้อมูลใน Volumes ณ เวลาใดเวลาหนึ่ง เมื่อ Defender ตรวจพบไฟล์อันตราย ระบบจะสร้าง VSS Snapshot ขึ้นเพื่อสำรองไฟล์นั้นไว้สำหรับใช้ในกระบวนการ Remediation

Snapshot ดังกล่าวจะถูก Mount เป็น Device Object ภายใต้ Path \Device\HarddiskVolumeShadowCopy* และสามารถเข้าถึงได้ผ่าน NT Object Namespace โดยตัว Exploit จะคอยเฝ้าตรวจสอบใน Object Manager Directory เพื่อดูการปรากฏขึ้นของ Shadow Copy ตัวใหม่ ซึ่งถือเป็นสัญญาณบ่งบอกว่า Defender ได้เข้าสู่ขั้นตอนการจัดการไฟล์แล้ว ก่อนที่ผู้โจมตีจะเริ่มดำเนินการในขั้นถัดไป

Junction Points (Mount Point Reparse)

Junction Point คือประเภทหนึ่งของ Reparse Point ที่ทำหน้าที่ Redirect การทำงานของระบบไฟล์ (Filesystem Operations) จากไดเรกทอรีหนึ่งไปยังอีกไดเรกทอรีหนึ่ง โดยผู้ใช้งานทั่วไปสามารถสร้าง Junction Point ได้เองโดยไม่จำเป็นต้องมีสิทธิ์ Admin

ในการโจมตีนี้ หลังจากที่ OPLOCK เริ่มทำงาน ไดเรกทอรีที่ผู้โจมตีใช้งานจะถูกแทนที่ด้วย Junction ที่ชี้ไปยัง "??\C:\Windows\System32" ทันที ส่งผลให้การเขียนไฟล์ใด ๆ ที่มุ่งเป้ามายังไดเรกทอรีเดิมจะถูก Kernel Redirect ไปยังโฟลเดอร์ System32 โดยอัตโนมัติ โดยที่โปรเซสผู้เขียน (ซึ่งในที่นี้คือ Defender) จะไม่รับรู้เลยว่ามีการเปลี่ยน Path เกิดขึ้น

ขั้นตอนการทำงานของ Exploit

ส่วนนี้จะอธิบายลำดับของ Exploit Chain โดยอ้างอิงจาก PoC ต้นฉบับที่ไม่มีการดัดแปลง ซึ่งผลการทดสอบนี้รันบน Windows Virtual Machine ที่เปิดใช้งาน Real-time Protection ไว้เต็มรูปแบบ

ขั้นตอนที่ 1: การเฝ้าตรวจสอบ Shadow Copy

ก่อนเริ่มการโจมตี ระบบจะสร้าง Background Thread เพื่อเปิด NT Object Manager ใน Path \Device และทำการบันทึกข้อมูล (Snapshot) ของอุปกรณ์ HarddiskVolumeShadowCopy* ทั้งหมดที่มีอยู่ในขณะนั้น

จากนั้นจะทำการ Polling เพื่อตรวจสอบ และเปรียบเทียบข้อมูลอย่างต่อเนื่อง จนกว่าจะตรวจพบ Shadow Copy ตัวใหม่ ที่ถูกสร้างขึ้น ซึ่งถือเป็นสัญญาณสำคัญที่บ่งบอกว่า Defender ได้เข้าสู่ Remediation Workflow เรียบร้อยแล้ว

ขั้นตอนที่ 2: การวางไฟล์ EICAR และการ Trigger ระบบ

ข้อความทดสอบมาตรฐานอย่าง EICAR จะถูกจัดเก็บแบบ Reversed ไว้ภายในตัวไฟล์ Binary เพื่อหลีกเลี่ยงการตรวจจับแบบ Static Analysis เมื่อเริ่มทำงาน สตริงดังกล่าวจะถูก Reversed ในหน่วยความจำ และเขียนลงในไฟล์ชั่วคราวชื่อ TieringEngineService.exe ภายใต้ Path %TEMP%

โดยการเปิดไฟล์ด้วยสิทธิ์ FILE_EXECUTE จะเป็นการบังคับให้ Defender เข้ามาสแกนไฟล์นั้นทันที ซึ่งจะไป Trigger ให้เกิด Remediation Workflow ตามที่วางแผนไว้

ขั้นตอนที่ 3: การ Synchronisation ด้วย OPLOCK และการสลับ Junction

ระบบจะทำการถือครอง Batch OPLOCK ไว้บนไฟล์เป้าหมาย เมื่อ Defender พยายามเข้าถึงไฟล์นั้นในระหว่างขั้นตอน Remediation ตัว OPLOCK จะทำการ Break เพื่อส่งสัญญาณให้ Main Thread เริ่มทำงานทันที ในจังหวะที่แม่นยำนี้ ไฟล์ต้นฉบับจะถูกลบทิ้งผ่านฟังก์ชัน FileDispositionInformationEx โดยอาศัย POSIX Semantics แล้วสร้าง Cloud Files Placeholder ขึ้นมาแทนที่ผ่าน CfCreatePlaceholders จากนั้นจะทำการ Rename ตัว Working Directory เดิมออกไป แล้วสร้าง Junction Point อันใหม่ขึ้นมา

ขั้นตอนที่ 4: Defender เขียน Payload ลงใน System32

เมื่อวาง Junction Point เรียบร้อยแล้ว Defender จะเริ่มกระบวนการ Remediation Write ต่อทันที โดยมุ่งเป้าไปยัง Original Path ที่ตรวจพบมัลแวร์ในตอนแรก ซึ่งในจังหวะนั้น Kernel จะทำหน้าที่ Redirect ผ่าน Junction Point อย่างแนบเนียน

ส่งผลให้ Defender เขียนไฟล์ Binary ที่ผู้โจมตีควบคุมไว้ลงใน C:\Windows\System32\TieringEngineService.exe โดยตรงภายใต้สิทธิ์ SYSTEM ซึ่งจากการทำ Reverse Engineering ไฟล์ MpSvc.dll ยืนยันได้ว่า ไม่มีการตรวจสอบ Reparse Point ในทุกขั้นตอนของกระบวนการ Remediation"

ขั้นตอนที่ 5: การเรียกใช้ SYSTEM Shell ผ่าน Storage Tiers COM Server

ตัว Exploit จะทำการเรียกใช้ CLSID {50d185b9-fff3-4656-92c7-e4018da4361d} ผ่านทาง DCOM ซึ่งเป็น Service ของ Storage Tiers Management Engine ที่จะไปสั่งรันไฟล์ TieringEngineService.exe โดยอัตโนมัติ

เนื่องจากไฟล์ดังกล่าวถูกแทนที่ด้วย Payload ของผู้โจมตีไปแล้ว มันจึงถูกรันขึ้นภายใต้สิทธิ์ SYSTEM ทันที โดย Payload จะตรวจสอบบริบทการทำงาน ผ่านฟังก์ชัน IsRunningAsLocalSystem() จากนั้นจะอ่านค่า Session ID ของผู้ใช้จาก Named Pipe (\\.\pipe\REDSUN) เพื่อทำการรัน conhost.exe ขึ้นมาใน Session ปัจจุบัน และมอบสิทธิ์การควบคุม Command Prompt ให้กับผู้โจมตีโดยสมบูรณ์

ทำไมช่องโหว่นี้ถึงเกิดขึ้น?

MpSvc.dll คือหัวใจหลักของ Antimalware Engine ซึ่งเป็นไฟล์ Binary ที่ MsMpEng.exe จะเรียกใช้งานเพื่อจัดการหน้าที่ในการสแกน, ตรวจจับ และทำ Remediation ทั้งหมด และนี่เองคือจุดที่กระบวนการ Write-back Path มีช่องโหว่แฝงตัวอยู่

ส่วนจัดการการกำหนดค่าเพื่อกู้คืนไฟล์

ค่าคอนฟิก EnableLocalFileRollback จะถูกอ่าน และนำมาเปรียบเทียบกับสถานะที่บันทึกไว้ใน Cache เมื่อพบว่ามีการเปลี่ยนแปลงสถานะ ระบบจะส่งคำสั่ง Rollback ออกไปทันที โดยทำการส่งค่า Original Detection Path (เส้นทางเดิมที่ตรวจพบไฟล์อันตราย) ลงไปยังขั้นตอนถัดไปของกระบวนการ

โดยในขั้นตอนนี้ไม่มีการตรวจสอบ Reparse Point แต่อย่างใด เนื่องจากระบบมอบความไว้วางใจให้แก่ Path ดังกล่าวโดยไม่มีเงื่อนไข"

ฟังก์ชันนี้เป็นเพียง Wrapper มาตรฐานสำหรับเรียกใช้งาน MpConfigGetValue API (ซึ่งถูกส่งออกมาจาก MpClient.dll) โดยมันมีหน้าที่อ่านค่าคอนฟิกแบบ DWORD และไม่มีผลข้างเคียง (Side Effect) ใด ๆ ต่อระบบ

ตัวฟังก์ชันนี้ไม่ได้มีช่องโหว่หากพิจารณาแบบแยกส่วน แต่ช่องโหว่ที่แท้จริงคือ 'การขาดการตรวจสอบใด ๆ' หลังจากที่ฟังก์ชันนี้ส่งค่ากลับมาแล้วนั่นเอง

ตารางต่อไปนี้จะแสดงลำดับการเรียกใช้งานฟังก์ชันทั้งหมดตั้งแต่ขั้นตอนการตรวจจับภัยคุกคาม ไปจนถึงขั้นตอนการ Remediation ผลการวิเคราะห์ยืนยันว่าไม่มีฟังก์ชันใดเลยที่มีการเรียกใช้งาน API สำหรับการตรวจสอบ Junction Point หรือการเช็ค Reparse Point เลยแม้แต่จุดเดียว

Original Detection Path จะถูกบันทึกไว้ตั้งแต่ขั้นตอนการสแกน และถูกนำมาใช้เป็น Write Destination สำหรับการกู้คืนไฟล์แบบ Verbatim (คงเดิมทุกตัวอักษร) โดยในระหว่างขั้นตอนเหล่านี้ ไม่มีฟังก์ชันใดเลยที่ทำหน้าที่ตรวจสอบว่า Path ดังกล่าวยังคงชี้ไปยัง Filesystem Object ตัวเดิมอยู่หรือไม่

ในทางปฏิบัติ เพียงแค่การเรียกใช้งานฟังก์ชัน DeviceIoControl(FSCTL_GET_REPARSE_POINT) หรือ GetFinalPathNameByHandle เพียงครั้งเดียวก่อนที่จะทำการเขียนไฟล์ ก็เพียงพอที่จะป้องกันช่องโหว่ร้ายแรงนี้ได้แล้ว เนื่องจากฟังก์ชันเหล่านี้จะช่วยยืนยันได้ว่าปลายทางไม่ใช่ Junction หรือ Symlink ที่ถูกสลับเปลี่ยนโดยผู้โจมตี

ผลกระทบ และการป้องกัน

RedSun ส่งผลกระทบต่อ Windows ทุกเวอร์ชันที่เปิดใช้งาน Windows Defender และมีส่วนประกอบของ cldapi.dll (ครอบคลุม Windows 10, 11 และ Windows Server 2019 ขึ้นไป) โดย Exploit นี้มีความเสถียรสูง (Highly Reliable) แม้จะเป็นระบบที่ติดตั้งอัปเดตล่าสุดของเดือนเมษายน 2026 แล้วก็ตาม

การโจมตีนี้ใช้เพียงสิทธิ์ผู้ใช้ทั่วไป โดยไม่ต้องอาศัย Kernel Exploit, การติดตั้ง Driver หรือการโต้ตอบจากผู้ดูแลระบบ

ปัจจุบันยังไม่มี Patch สำหรับ RedSun และ Microsoft ยังไม่ได้ออกหมายเลข CVE หรือแนวทางแก้ไข แม้ว่า BlueHammer (ผลงานก่อนหน้าของนักวิจัยคนเดียวกัน) จะได้รับการแก้ไขไปแล้วใน CVE-2026-33825 แต่ RedSun เป็นช่องทางการโจมตีที่แยกอิสระจากกัน และยังคงใช้งานได้โดยสมบูรณ์บน Windows ทุกเวอร์ชัน

แนวทางการป้องกันชั่วคราว (จนกว่าจะมีแพตช์):

ในระหว่างที่รอ Official Patch องค์กรควรเน้นไปที่การตรวจจับเชิงพฤติกรรม (Behavioral Detection) ดังนี้:

• เฝ้าระวังการสแกนหา VSS: การเรียกใช้งาน NtQueryDirectoryObject เพื่อหาอุปกรณ์ HarddiskVolumeShadowCopy* จากโปรเซสของผู้ใช้ทั่วไป (Standard User) ถือเป็นพฤติกรรมที่ผิดปกติอย่างมาก (High Anomaly)
• แจ้งเตือนการลงทะเบียน Sync Root: การใช้ฟังก์ชัน CfRegisterSyncRoot จากโปรเซสที่ไม่น่าเชื่อถือ (นอกเหนือจาก OneDrive หรือ Dropbox) คือสัญญาณบ่งชี้ (Indicator) ที่ชัดเจนของเทคนิคนี้
• ตรวจสอบการสร้าง Junction ใน %TEMP%: หากพบการสร้าง Mount Point ในโฟลเดอร์ชั่วคราวทันทีหลังจากมีการทำ OPLOCK ให้สันนิษฐานว่าเป็นพฤติกรรมอันตรายสูง
• เฝ้าระวังการเขียนไฟล์ใน System32 โดย MsMpEng.exe: แม้จะเป็นการเขียนจากตัว Defender เอง แต่หากมีการสร้างไฟล์ที่ไม่อยู่ในรายการที่คาดไว้ ระบบ File Integrity Monitoring (FIM) ควรแจ้งเตือนความผิดปกติทันที
• ปิดระบบ Cloud Delivered Protection (เฉพาะระบบที่มีความเสี่ยงสูง): แม้จะเป็นวิธีตัดวงจรการทำงานของ CfApi ได้ แต่ไม่แนะนำให้ทำเป็นวงกว้างเพราะจะทำให้ประสิทธิภาพการตรวจจับภาพรวมของ Defender ลดลงอย่างมาก

ที่มา : Cloudsek