กลับไปหน้าบทความ

เจาะลึก ValleyRAT / Winos4.0 Kernel Rootkit: จาก Driver Plugin ถึง HiddenGate Device พร้อม IOC และ Detection Rules

แชร์:
เจาะลึก ValleyRAT / Winos4.0 Kernel Rootkit: จาก Driver Plugin ถึง HiddenGate Device พร้อม IOC และ Detection Rules
⚠️ หมายเหตุการเผยแพร่: รายงานฉบับนี้เป็นการสรุปและวิเคราะห์เชิงเทคนิคของ ValleyRAT (Winos4.0) Kernel Rootkit โดยทีม TXEC จากการรวบรวมข้อมูลภัยคุกคามที่เปิดเผยต่อสาธารณะ (Check Point Research) เพื่อสนับสนุนการทำ Threat Hunting และการพัฒนา Detection ภายในองค์กรสมาชิก ข้อมูลนี้เป็นการสรุปจาก Public Threat Intelligence ไม่ใช่ผลตรวจพิสูจน์จากเครื่องผู้เสียหายโดยตรง


บทสรุป (Summary)


ValleyRAT หรือที่รู้จักในชื่อ Winos4.0 เป็นมัลแวร์แบบ Modular ที่สามารถเชื่อมต่อ Command and Control (C2) Server เพื่อรับคำสั่งและดาวน์โหลด Driver Plugin เพิ่มเติมมายังเครื่องเป้าหมาย จุดที่ทำให้กรณีนี้มีความรุนแรงสูงคือความสามารถในการติดตั้ง Kernel-mode Rootkit ซึ่งเป็น Driver ที่ทำงานในระดับสิทธิ์สูงสุดของระบบปฏิบัติการ Windows เปิดทางให้ผู้โจมตีซ่อนไฟล์ ซ่อน Registry ปกป้อง Process ฝังโค้ดเข้าสู่ Process ที่น่าเชื่อถือ และรบกวนการทำงานของ Antivirus/EDR ได้สำเร็จ


รายงานฉบับนี้สรุปผลการวิเคราะห์เชิงเทคนิคของ ValleyRAT Kernel Rootkit ครอบคลุมตั้งแต่การติดตั้ง Kernel Driver Service ชื่อ kernelquick การสร้าง Kernel Device ชื่อ HiddenGate สำหรับสื่อสารผ่าน IOCTL การจัดเก็บ Shellcode ภายใต้ Registry Path HKLM\SOFTWARE\IpDates การทำ APC Injection เข้า Process dwm.exe และฟังก์ชัน ForceDeleteFile() ที่ใช้ลบ Driver ของผลิตภัณฑ์ AV/EDR ระดับ Kernel โดยตรง


เนื้อหาครอบคลุมตั้งแต่ Execution Flow, IOC ที่ยืนยันแล้ว, MITRE ATT&CK Mapping, Detection Rules พร้อมใช้งาน (YARA และ Sigma) ไปจนถึงข้อเสนอแนะด้าน Containment, Detection และการเตรียมความพร้อมรับมือในระยะยาว



1. บทนำ


การตรวจพบมัลแวร์ที่สามารถติดตั้ง Kernel-mode Rootkit บนระบบปฏิบัติการ Windows ถือเป็นหนึ่งในสัญญาณสำคัญที่บ่งชี้ว่าระบบอาจถูกบุกรุกในระดับสูง เนื่องจาก Driver ที่ทำงานในระดับ Kernel มีสิทธิ์เข้าถึงส่วนสำคัญของระบบ และสามารถใช้เป็นกลไกสำหรับซ่อนไฟล์ ซ่อน Registry ปกป้อง Process ฝังโค้ดเข้าสู่ Process ที่น่าเชื่อถือ รวมถึงลดประสิทธิภาพหรือรบกวนการทำงานของระบบ Antivirus และ Endpoint Detection and Response (EDR) ได้สำเร็จ ในหลายกรณี ผู้โจมตีอาจใช้ Rootkit เพื่อคงอยู่ภายในระบบ รับคำสั่งจากระยะไกล และปกปิดกิจกรรมที่เกิดขึ้น ทำให้การตรวจจับและการวิเคราะห์เหตุการณ์มีความซับซ้อนกว่ามัลแวร์ทั่วไป


ข้อมูลนี้จัดทำขึ้นโดยทีม TXEC เพื่อสรุปผลการวิเคราะห์กรณีศึกษา ValleyRAT หรือ Winos4.0 Kernel Rootkit จากข้อมูลภัยคุกคามที่เปิดเผยต่อสาธารณะโดย Check Point Research (ช่วงเวลาที่วิเคราะห์: พฤศจิกายน 2567 – พฤศจิกายน 2568 เผยแพร่ข้อมูล: ธันวาคม 2568) โดยภายหลังการตรวจสอบพบว่า ValleyRAT สามารถดาวน์โหลด Driver Plugin เพิ่มเติมจาก C2 Server เพื่อติดตั้ง Kernel Driver Service ชื่อ kernelquick สร้าง Device ชื่อ HiddenGate และจัดเก็บ Shellcode ภายใต้ Registry Path HKLM\SOFTWARE\IpDates ก่อนนำ Payload ไปฝังใน Process เช่น dwm.exe ผ่านเทคนิค APC Injection


ระบบเป้าหมาย: Windows 10 / Windows 11 (x64) โดยเฉพาะ Endpoint ที่ใช้งาน Antivirus หรือ EDR


2. กระบวนการวิเคราะห์ (Analysis Process)


ทีม TXEC ดำเนินการรวบรวมและวิเคราะห์ข้อมูลภัยคุกคามที่เปิดเผยต่อสาธารณะ โดยมุ่งเน้นการตรวจสอบ ValleyRAT/Winos4.0 ในส่วนของ Driver Plugin และ Kernel-mode Rootkit รวมถึงพฤติกรรมการติดตั้ง Driver Service การสร้างค่า Configuration ใน Registry การซ่อน Artifact การฝัง Shellcode เข้า Process เป้าหมาย และการรบกวนระบบ AV/EDR แบ่งออกเป็น 5 ขั้นตอนหลัก เพื่อให้การตรวจสอบมีลำดับที่ชัดเจน สามารถอ้างอิงแหล่งข้อมูลได้ และลดความเสี่ยงจากการสรุปผลเกินกว่าข้อมูลที่เผยแพร่จริง


ขั้นตอนที่ 1: Scoping & Framing (กำหนดขอบเขตและคำถามการวิเคราะห์)


กำหนดขอบเขตของกรณีศึกษาและคำถามหลักในการวิเคราะห์ โดยมุ่งตรวจสอบว่า ValleyRAT ใช้ Driver Plugin และ Kernel-mode Rootkit เพื่อเพิ่มความสามารถในการซ่อนตัว ปกป้อง Process ฝัง Shellcode และรบกวนระบบรักษาความปลอดภัยอย่างไร รวมถึงกำหนดให้ข้อมูลจากรายงาน HoneyMyte ของ Kaspersky เป็นข้อมูลอ้างอิงเชิงเทคนิคเท่านั้น


ขั้นตอนที่ 2: Evidence Identification & Collection (การระบุและรวบรวมข้อมูลอ้างอิง)


รวบรวมข้อมูลที่เกี่ยวข้องจากแหล่งข้อมูลสาธารณะ เช่น รายงานวิเคราะห์ ValleyRAT ของ Check Point Research รายงาน HoneyMyte ของ Kaspersky เอกสาร Microsoft Sysmon มาตรฐาน MITRE ATT&CK รวมถึง Public IOC, SHA-256, Service Name, Registry Path, Device Name, Process เป้าหมาย และข้อมูล IOCTL ที่เกี่ยวข้อง


ขั้นตอนที่ 3: Examination & Filtering (การตรวจสอบและคัดกรองข้อมูล)


ตรวจสอบรายละเอียดของข้อมูลที่รวบรวม โดยแยก Public IOC ออกจาก Behavioral Artifact และข้อมูลประกอบ เช่น ค่า Hash ของ Driver Plugin และ Rootkit, Service kernelquick, Device HiddenGate, Registry HKLM\SOFTWARE\IpDates, ค่า KernelQuick_*, Process dwm.exe และ IOCTL ที่ใช้สั่งลบไฟล์หรือ Inject Shellcode พร้อมตัดข้อมูลที่ไม่สามารถยืนยันแหล่งที่มาได้


ขั้นตอนที่ 4: Correlation Analysis (การวิเคราะห์ความสัมพันธ์ของข้อมูล)


เชื่อมโยงข้อมูลจากหลายส่วน เช่น การดาวน์โหลด Driver Plugin การสร้าง Driver Service การเขียน Registry Configuration การโหลด Rootkit Driver การสื่อสารผ่าน IOCTL การอ่าน Shellcode จาก IpDates การ Inject เข้า dwm.exe และการลบ Driver ของ AV/EDR เพื่อวิเคราะห์ลำดับการทำงานและผลกระทบที่อาจเกิดขึ้น


ขั้นตอนที่ 5: Reporting & Conclusion (การสรุปผลและจัดทำรายงาน)


สรุปผลการวิเคราะห์ทั้งในมุมผู้บริหารและเชิงเทคนิค พร้อมจัดทำบทวิเคราะห์ Public IOC, High-Value Artifacts, MITRE ATT&CK Mapping, ผลกระทบ ข้อจำกัด ข้อเสนอแนะด้าน Incident Response และตัวอย่าง YARA/Sigma Rules สำหรับนำไปปรับใช้กับระบบ SIEM หรือ EDR


3. ข้อค้นพบสำคัญ: Execution Flow และพฤติกรรมของ ValleyRAT Kernel Rootkit



3.1 Initial Access และการดาวน์โหลด Driver Plugin


จากข้อมูลที่เปิดเผยต่อสาธารณะ ValleyRAT เข้าถึงระบบเป้าหมายในระยะแรกผ่าน Web Application (พบความเชื่อมโยงกับการรันคำสั่งผ่าน PHP Webshell) ก่อนที่มัลแวร์จะติดต่อไปยัง C2 Server และรับ Driver Plugin ซึ่งเป็นไฟล์ DLL ที่ทำหน้าที่เป็น User-mode Client ของ Rootkit Driver โดยรักษาการเชื่อมต่อกับ C2 และแปลงคำสั่งที่ได้รับเป็น IOCTL เพื่อควบคุมการทำงานของ Driver


Driver Plugin รองรับความสามารถหลากหลาย ได้แก่ การติดตั้ง Driver ใน Normal Mode หรือ Stealth Mode, การเปิด/ปิด Rootkit และตรวจสอบสถานะ, การเพิ่ม/ลบรายการไฟล์ โฟลเดอร์ Registry Key และ Registry Value ที่ต้องการซ่อน, การเพิ่ม/ลบ Process ที่ต้องการปกป้อง และการสั่ง Force-delete ไฟล์หรือ User-mode Shellcode Injection ผ่าน Rootkit Driver


3.2 การติดตั้ง Kernel Driver Service และ Persistence


ใน Normal Mode ตัว Client จะ Drop Driver ลง Disk และติดตั้งเป็น Kernel Service ชื่อ kernelquick พร้อมสร้าง Registry Key HKLM\SYSTEM\CurrentControlSet\Services\kernelquick โดยลงทะเบียนเป็น SERVICE_KERNEL_DRIVER และกำหนดค่าเริ่มต้นแบบ Demand Start ใน Stealth Mode การติดตั้งจะเพิ่มขั้นตอนเพื่อลดโอกาสตรวจพบ เช่น การสั่ง ipconfig /release และ ipconfig /renew เพื่อรบกวนการเชื่อมต่อชั่วคราว รวมถึงใช้ MalSeclogon-based Impersonation และ PPID Spoofing เพื่อให้ Process Chain ดูใกล้เคียง Process ปกติของ Windows


Rootkit สามารถเปลี่ยน Start Type ของ Service kernelquick เป็น SERVICE_SYSTEM_START เพื่อให้ Driver โหลดพร้อม Windows และเริ่มทำงานก่อนเครื่องมือรักษาความปลอดภัยใน User Mode จะเริ่มทำงาน


3.3 HiddenGate Device และ Registry Configuration


เมื่อ Driver เริ่มทำงาน จะสร้าง Kernel Device ชื่อ HiddenGate และกำหนด IrpDeviceControlHandler() เป็นตัวรับคำสั่ง IOCTL จาก Driver Plugin ทำให้โปรแกรมฝั่ง User Mode สามารถเปลี่ยน Configuration หรือสั่งฟังก์ชันระดับ Kernel ได้จากระยะไกล


ระหว่างการติดตั้ง Client จะเขียนค่า Configuration สำหรับควบคุมการซ่อนและปกป้ององค์ประกอบของ Rootkit ลง Registry เช่น KernelQuick_HideFsFiles, KernelQuick_ProtectedImages, KernelQuick_State, KernelQuick_StealthMode, KernelQuick_HideFsDirs, KernelQuick_HideRegKeys, KernelQuick_HideRegValues และ KernelQuick_IgnoredImages


3.4 Shellcode Staging และ APC Injection


Driver Plugin รองรับการรับ Shellcode จากผู้ควบคุมและเก็บข้อมูลไว้ใน Registry Path HKLM\SOFTWARE\IpDates เมื่อได้รับคำสั่ง Rootkit จะอ่าน Shellcode ดังกล่าวและทำ APC-based Injection เข้า dwm.exe ในช่วง Initial Activation หรือ Inject เข้า Process ID อื่นที่ผู้ควบคุมระบุผ่าน IOCTL 0x222144


กระบวนการ UMInjection() จะหา Thread ที่เหมาะสม จัดสรรหน่วยความจำใน Process เป้าหมาย เขียน Shellcode และ Queue APC เพื่อให้โค้ดทำงานในบริบทของ Process ปกติ วิธีนี้ช่วยพรางการทำงานภายใต้ Process ที่น่าเชื่อถือและอาจหลบการตรวจจับแบบที่พิจารณาเฉพาะชื่อ Process


3.5 ForceDeleteFile และการรบกวน AV/EDR


ForceDeleteFile() เป็นฟังก์ชันที่นำการลบไฟล์ไปทำงานในระดับ Kernel โดยใช้ IRP โดยตรง แก้ไข Attribute และกำหนด FileDispositionInformation รวมถึงจัดการ Section Object เพื่อข้าม File Lock ฟังก์ชันนี้สามารถถูกเรียกอัตโนมัติระหว่าง Driver Initialization หรือเรียกผ่าน IOCTL 0x222140 จาก User-mode Client


รายงานต้นทางพบรายการ Driver ของผลิตภัณฑ์ AV/EDR หลายรายเป็นเป้าหมายการลบ ผลกระทบที่สำคัญคือ Agent อาจยังคงมี Process หรือ UI อยู่ แต่ Driver หลักถูกลบหรือไม่สามารถโหลดได้ ทำให้ Telemetry ลดลงและเกิด Blind Spot ในช่วงที่ผู้โจมตีกำลังดำเนินกิจกรรมอื่น สุดท้ายมัลแวร์จะซ่อนไฟล์ ซ่อน Registry ปกป้อง Process รบกวนการทำงานของระบบรักษาความปลอดภัย และคงการเชื่อมต่อไปยัง C2 ผ่าน Proxy/Tunnel เพื่อรับคำสั่งเพิ่มเติม



ทั้งนี้ ลำดับการทำงานดังกล่าวเป็นการสรุปจากข้อมูลภัยคุกคามสาธารณะ ไม่ใช่ผลตรวจพิสูจน์จากเครื่องผู้เสียหายโดยตรง


3.6 Driver Signing และความเสี่ยงบนระบบ Windows


Check Point ระบุว่า Driver ที่วิเคราะห์ถูก Compile ในปี 2023 แต่ลงนามด้วย Certificate เก่าที่หมดอายุแล้ว ซึ่งยังเคยอยู่ภายใต้ข้อยกเว้นของ Windows Driver Signing Policy ทำให้ Driver โหลดบน Windows 11 รุ่นที่อัปเดตแล้วได้ในช่วงเวลาที่ Certificate ยังไม่ถูกเพิกถอน นอกจากนี้ยังพบ Rootkit Driver หลาย Variant ที่มี Certificate ไม่ถูกเพิกถอน



ข้อควรทราบ: สถานะ Signed ไม่ได้เท่ากับ Safe ควรตรวจ Certificate Chain, Revocation Status, Publisher Reputation, Hash, Driver Path และ Baseline ขององค์กรร่วมกัน


4. แหล่งข้อมูลและผลการตรวจสอบ


การวิเคราะห์ครั้งนี้อ้างอิงจาก Malware Research, Public IOC และมาตรฐาน MITRE ATT&CK เพื่อให้ครอบคลุมทั้งตัว Binary, Operational Context และแนวทางรับมือ


  • ▸ Check Point Research — Cracking ValleyRAT (December 2025) — ใช้เพื่อวิเคราะห์ Driver Plugin, Kernel Rootkit และ Execution Flow → ผลตรวจ: ยืนยันการติดตั้ง Kernel Driver Service kernelquick, Device HiddenGate, Registry Configuration, Shellcode Staging ใน IpDates, APC Injection เข้า dwm.exe และ ForceDeleteFile() สำหรับลบ Driver ของ AV/EDR
  • ▸ Check Point Public IOC — ใช้เพื่อตรวจสอบค่า Hash ของ Rootkit Driver และ Driver Plugin → ผลตรวจ: ได้ SHA-256 สำหรับ Rootkit Driver (64-bit) และ Driver Plugin (32-bit/64-bit) พร้อม External IP/C2 สำหรับนำไปใช้กับ EDR, SIEM และ Retrospective Hunting
  • ▸ Kaspersky HoneyMyte Report — ใช้เป็นข้อมูลอ้างอิงเชิงเทคนิคประกอบเท่านั้น → ผลตรวจ: ไม่ได้นำมาใช้ยืนยันข้อสรุปหลักของรายงานฉบับนี้โดยตรง
  • ▸ Microsoft Sysmon Documentation — ใช้เพื่อกำหนด Event ID ที่เกี่ยวข้องกับการตรวจจับ → ผลตรวจ: ระบุ Event ID 6 (Driver Load), 12-14 (Registry) และ 13 (Registry Set) ที่ใช้ในการเขียน Detection Rules
  • ▸ MITRE ATT&CK Framework — ใช้เพื่อจัดหมวดหมู่ TTP → ผลตรวจ: ครอบคลุม Ingress Tool Transfer, Create/Modify System Process, Modify Registry, Process Injection, Access Token Manipulation, Hide Artifacts และ Impair Defenses


5. Indicators of Compromise (IOC)




IOC ชุดนี้รวบรวมจาก Public Threat Intelligence (Check Point Research, December 2025) พร้อมสำหรับการนำไปใช้ใน SIEM, EDR, WAF/IPS และ Threat Intelligence Platform ค่า Hash เหมาะสำหรับ Retrospective Hunting ส่วน Behavior Artifact ควรนำไป Correlate กับ Endpoint Telemetry เพื่อเพิ่ม Detection Coverage — ไม่ควรใช้ Indicator เพียงรายการเดียวเป็นหลักฐานยืนยันการบุกรุก


✅ SHA-256 [CONFIRMED / HIGH]

2aa029088c04eb10b056c18fcc39395936e6f01ee9ebdeed2558e4899116ee86

Rootkit Driver แบบ 64-bit


✅ SHA-256 [CONFIRMED / HIGH]

79daa001c67dc83bdd6189417ccf4bf83ea5da4c6211bbac91c1d7d55f76fa5f

Driver Plugin แบบ 32-bit


✅ SHA-256 [CONFIRMED / HIGH]

14b85b07bfdd134e709ff973871d75d33ecca964457373b76b34a70183c2b1d0

Driver Plugin แบบ 64-bit


✅ Service Name [CONFIRMED / HIGH]

kernelquick

ชื่อ Kernel Driver Service ที่ ValleyRAT ติดตั้ง


👁️ Registry Path [OBSERVED / MEDIUM]

HKLM\SYSTEM\CurrentControlSet\Services\kernelquick

ตำแหน่งการติดตั้งและกำหนดค่า Driver Service


✅ Registry Path [CONFIRMED / HIGH]

HKLM\SOFTWARE\IpDates

ตำแหน่งจัดเก็บ Shellcode ก่อน Inject


👁️ Kernel Device [OBSERVED / MEDIUM]

HiddenGate

Device ที่ Rootkit สร้างขึ้นเพื่อรับคำสั่ง IOCTL


👁️ Registry Value [OBSERVED / MEDIUM]

KernelQuick_* (เช่น KernelQuick_HideFsFiles, KernelQuick_ProtectedImages, KernelQuick_State, KernelQuick_StealthMode)

Configuration สำหรับการซ่อนและปกป้อง Artifact


👁️ Process [OBSERVED / MEDIUM]

dwm.exe

Process เป้าหมายเริ่มต้นของ APC Injection (ผู้ควบคุมสามารถกำหนด Process อื่นผ่าน IOCTL ได้)


👁️ IOCTL [OBSERVED / MEDIUM-HIGH]

0x222140 (ForceDeleteFile), 0x222144 (UMInject)

คำสั่ง IOCTL ที่พบในการทำงานของ Rootkit — เป็น Technical Artifact ไม่ใช่ Network IOC


👁️ External IP [OBSERVED / MEDIUM]

103.146.230.91:80

ปลายทางเครือข่ายที่พบเกี่ยวข้องกับกิจกรรม C2 — ควรตรวจสอบร่วมกับ Threat Intelligence ล่าสุดก่อนใช้ Block โดยตรง เนื่องจาก IP อาจเปลี่ยนแปลงหรือถูกใช้ซ้ำโดยผู้อื่น


Threat Hunting Guidance:


  • ตรวจสอบ HTTP POST ไปยังไฟล์ PHP ที่ไม่ใช่ไฟล์ปกติบน Web Server ที่เผยแพร่สู่อินเทอร์เน็ต
  • ตรวจสอบการใช้งาน User-Agent ที่ไม่ปกติ เช่น python-requests, PostmanRuntime
  • ตรวจสอบการเชื่อมต่อออกไปยัง IP:Port 103.146.230.91:80 หรือปลายทางภายนอกที่ไม่รู้จัก
  • ตรวจสอบ Web Server Log, Application Log, Process/Command History และไฟล์ที่เกี่ยวข้อง (เช่น nohup.out)
  • เฝ้าระวังการสร้าง Service ชื่อ kernelquick และการโหลด Driver ที่ไม่ปกติ
  • ตรวจสอบการ Inject Shellcode เข้าสู่ dwm.exe หรือ Process อื่น
  • ตรวจหาไฟล์และค่า Hash ที่ตรงกับ SHA-256 ข้างต้นแบบ Exact Match


MITRE ATT&CK Mapping:


  • ▸ T1105 — Ingress Tool Transfer: ดาวน์โหลด Driver Plugin หรือส่วนประกอบเพิ่มเติมจาก C2
  • ▸ T1543.003 — Create or Modify System Process: Windows Service: ติดตั้งและเปลี่ยน Start Type ของ Service kernelquick
  • ▸ T1112 — Modify Registry: เขียนค่า KernelQuick_* และจัดเก็บ Shellcode ใน HKLM\SOFTWARE\IpDates
  • ▸ T1055.004 — Process Injection: Asynchronous Procedure Call: Inject Shellcode ผ่าน APC เข้า dwm.exe หรือ Process อื่น
  • ▸ T1134.004 — Access Token Manipulation: Parent PID Spoofing: ใช้ PPID Spoofing และ Impersonation ระหว่างการติดตั้งแบบ Stealth Mode
  • ▸ T1564.001 — Hide Artifacts: Hidden Files and Directories: ซ่อนไฟล์และ Directory ผ่าน Rootkit
  • ▸ T1562.001 — Impair Defenses: Disable or Modify Tools: ลบ Driver ของ AV/EDR และลด Visibility ของ Endpoint Security


Attack Technique Flow: Initial Access (ผ่าน Web Application) → Command Execution (ผ่าน PHP Webshell) → Driver Load (โหลด Driver และติดตั้ง Rootkit) → External Connection (Proxy/Tunnel/C2)


6. Detection Rules


6.1 YARA Rule: Exact Hash Detection (Confirmed Samples)


yara

import "hash"

rule TXEC_ValleyRAT_Confirmed_SHA256
{
    meta:
        author      = "TXEC Team"
        description = "Detects confirmed ValleyRAT Driver Plugin and Rootkit samples"
        category    = "Malicious Driver / Rootkit"
        severity    = "critical"
        confidence  = "high"
        status      = "experimental"
        reference   = "Check Point Research, December 2025"

    condition:
        filesize > 0 and
        (
            hash.sha256(0, filesize) ==
            "2aa029088c04eb10b056c18fcc39395936e6f01ee9ebdeed2558e4899116ee86" or
            hash.sha256(0, filesize) ==
            "79daa001c67dc83bdd6189417ccf4bf83ea5da4c6211bbac91c1d7d55f76fa5f" or
            hash.sha256(0, filesize) ==
            "14b85b07bfdd134e709ff973871d75d33ecca964457373b76b34a70183c2b1d0"
        )
}

Rule นี้จะตรวจพบเฉพาะไฟล์ที่มี Hash ตรงกับ 3 ค่านี้เท่านั้น หากมัลแวร์ถูกแก้ไข แพ็กใหม่ หรือเปลี่ยนเพียงเล็กน้อย ค่า Hash จะเปลี่ยนและกฎอาจตรวจไม่พบ


6.2 YARA Rule: Driver Plugin Behavior


yara

import "pe"

rule TXEC_ValleyRAT_Driver_Plugin_Behavior
{
    meta:
        author      = "TXEC Team"
        description = "Hunts for ValleyRAT Driver Plugin and rootkit artifacts"
        category    = "Kernel Rootkit"
        confidence  = "medium"
        status      = "experimental"

    strings:
        $svc   = "kernelquick" ascii wide nocase
        $dev   = "HiddenGate" ascii wide
        $cfg1  = "KernelQuick_HideFsFiles" ascii wide
        $cfg2  = "KernelQuick_ProtectedImages" ascii wide
        $store = "IpDates" ascii wide

    condition:
        pe.is_pe and filesize < 20MB and 3 of them
}

YARA Rule สำหรับตรวจค้นไฟล์ PE ที่มี Artifact สำคัญซึ่งสัมพันธ์กับ ValleyRAT/Winos4.0 เช่น Service kernelquick, Device HiddenGate, ค่า KernelQuick_* และ Registry Artifact IpDates โดยกำหนดให้พบอย่างน้อย 3 รายการก่อนแจ้งเตือน ทั้งนี้ กฎอยู่ในสถานะ Experimental และควรใช้ร่วมกับ Hash, Driver Load, Registry และ Endpoint Telemetry ก่อนยืนยันเหตุการณ์


6.3 YARA Rule: IOC Artifact Detection (IOCTL + Strings)


yara

import "pe"

rule TXEC_ValleyRAT_Rootkit_IOC_Artifacts
{
    meta:
        author      = "TXEC Team"
        description = "Detects ValleyRAT rootkit configuration and IOCTL artifacts"
        category    = "Rootkit IOC"
        confidence  = "medium"
        status      = "experimental"

    strings:
        $service = "kernelquick" ascii wide nocase
        $device  = "HiddenGate" ascii wide
        $regkey  = "SOFTWARE\\IpDates" ascii wide nocase
        $ioctl_force_delete = { 40 21 22 00 }
        $ioctl_um_inject    = { 44 21 22 00 }

    condition:
        pe.is_pe and filesize < 20MB and
        2 of ($service, $device, $regkey) and
        1 of ($ioctl_*)
}

Rule นี้เพิ่มการตรวจค่า IOCTL แบบ Little-endian ร่วมกับ String ของ Service, Device และ Registry Path เพื่อเพิ่มความเฉพาะเจาะจง เงื่อนไขยังเป็น Experimental เนื่องจาก Compiler, Obfuscation และ Variant ใหม่อาจทำให้ Byte Pattern เปลี่ยนได้


6.4 Sigma Rule: Kernel Driver Service Installation


yaml

title: ValleyRAT Kernel Driver Service Installation
id: 4bb02bbc-545b-4fd1-ae98-0af70eb491c1
status: experimental
description: Detects the kernelquick service or an unusual kernel driver service
references:
  - Check Point Research - Cracking ValleyRAT, December 2025
author: TXEC Team
date: 2026-07-21
logsource:
  product: windows
  service: system
detection:
  selection_exact:
    EventID: 7045
    ServiceName|contains: 'kernelquick'
  selection_driver:
    EventID: 7045
    ServiceType|contains: 'kernel mode driver'
    ImagePath|endswith: '.sys'
  condition: selection_exact or selection_driver
falsepositives:
  - Legitimate hardware or security driver installation
level: high
tags:
  - attack.persistence
  - attack.t1543.003

Rule นี้ตรวจ Windows System Event ID 7045 โดยเน้น Service ชื่อ kernelquick และการติดตั้ง Kernel Driver Service ที่มี ImagePath ลงท้ายด้วย .sys เหตุการณ์ดังกล่าวอาจเกิดจากการติดตั้ง Driver ปกติ จึงต้องตรวจ Change Ticket, Publisher, Signature และ Driver Baseline เพิ่มเติม


6.5 Sigma Rule: Shellcode Staging in IpDates


yaml

title: ValleyRAT Shellcode Staging in IpDates Registry Key
id: 79be3feb-69c0-45ea-bf2a-b6ad36f1ac45
status: experimental
description: Detects shellcode staging or KernelQuick configuration changes
references:
  - Check Point Research - Cracking ValleyRAT, December 2025
author: TXEC Team
date: 2026-07-21
logsource:
  product: windows
  category: registry_set
detection:
  selection_shellcode:
    EventID: 13
    TargetObject|contains: '\SOFTWARE\IpDates'
  selection_config:
    EventID: 13
    TargetObject|contains: '\Services\kernelquick\KernelQuick_'
  condition: selection_shellcode or selection_config
falsepositives:
  - Unlikely; validate authorized software and registry deployment activity
level: high
tags:
  - attack.defense-evasion
  - attack.t1112

Rule นี้ใช้ Sysmon Registry Set Event เพื่อตรวจการเขียนข้อมูลที่ HKLM\SOFTWARE\IpDates หรือค่า KernelQuick_* ใต้ Service Registry เหมาะสำหรับตรวจช่วงติดตั้งและเปลี่ยน Configuration ของ Rootkit โดยควรเก็บ Value Data และ Process ที่เขียน Registry เพื่อใช้ยืนยัน


7. ข้อเสนอแนะด้านการควบคุมความปลอดภัยและการดำเนินการต่อ


เพื่อให้การรับมือเหตุการณ์ที่อาจเกี่ยวข้องกับ ValleyRAT Kernel Rootkit เป็นไปอย่างเหมาะสม ลดความเสี่ยงจากการทำงานของมัลแวร์ในระดับ Kernel และช่วยให้องค์กรควบคุมสถานการณ์ได้อย่างเป็นระบบ TXEC ขอเสนอแนวทางดำเนินการทั้งในระยะเร่งด่วน ระยะเฝ้าระวังต่อเนื่อง และระยะเตรียมความพร้อมในอนาคต


⚡ ระยะเร่งด่วน: การจำกัดผลกระทบ (Containment)


  1. แยกเครื่องต้องสงสัยออกจากระบบเครือข่ายหลัก เพื่อตัดการเชื่อมต่อไปยัง C2 Server และป้องกันการดาวน์โหลด Driver Plugin หรือส่วนประกอบเพิ่มเติม โดยควรรักษาช่องทางที่จำเป็นสำหรับการเก็บหลักฐานและการบริหารจัดการเหตุการณ์ไว้ตามความเหมาะสม
  2. จัดเก็บ Memory Image, รายการ Process และ Thread, Network Connection, Driver ที่ถูกโหลด, Windows Event Log และ Registry Hive ก่อน Shutdown หรือแก้ไขระบบ เมื่อสามารถดำเนินการได้อย่างปลอดภัย เนื่องจากข้อมูลเกี่ยวกับ Shellcode, APC Injection, Kernel Device และ Driver Object อาจปรากฏอยู่ในหน่วยความจำและสูญหายภายหลังการปิดเครื่อง
  3. ตรวจสอบไฟล์ Driver Plugin และ Rootkit Driver กับค่า SHA-256 ที่ระบุไว้ใน Public IOC รวมถึงตรวจสอบ File Path, PE Metadata, Digital Signature, Certificate Chain และเวลาที่ไฟล์ถูกสร้างหรือโหลด หากพบไฟล์ต้องสงสัยควรเก็บสำเนาแบบ Read-only และคำนวณค่า Hash ก่อนดำเนินการกักกัน
  4. ตรวจสอบ Kernel Driver Service ชื่อ kernelquick ภายใต้ Registry Path HKLM\SYSTEM\CurrentControlSet\Services\kernelquick รวมถึงค่า Configuration ที่ขึ้นต้นด้วย KernelQuick_* โดยควรเก็บสำเนา SYSTEM Registry Hive และ Transaction Log ก่อนแก้ไขหรือลบข้อมูล
  5. ตรวจสอบ Registry Path HKLM\SOFTWARE\IpDates และ Memory ของ Process dwm.exe เพื่อค้นหา Binary Data, Executable Memory Region, Thread Start Address, APC Activity หรือโค้ดที่ไม่สัมพันธ์กับ Module ปกติ ทั้งนี้ การพบชื่อ dwm.exe เพียงอย่างเดียวยังไม่เพียงพอสำหรับยืนยันการบุกรุก เนื่องจากเป็น Process ปกติของระบบ Windows
  6. ตรวจสอบสถานะของ Antivirus/EDR Agent, Service และ Kernel Driver ว่ายังคงทำงานและส่ง Telemetry ได้ตามปกติหรือไม่ หากพบว่า Security Driver ถูกลบ ไม่สามารถโหลด หรือยืนยันว่า Rootkit Driver ทำงานในระบบแล้ว ควรพิจารณา Reimage เครื่องจากแหล่งติดตั้งที่เชื่อถือได้ แทนการลบไฟล์หรือ Service เพียงอย่างเดียว


📋 ระยะต่อเนื่อง: การเฝ้าระวังและการตรวจจับ


  1. สร้าง Detection Rule สำหรับการสร้างหรือแก้ไข Service ภายใต้ HKLM\SYSTEM\CurrentControlSet\Services โดยเฉพาะ Service ชื่อ kernelquick, Service Type แบบ Kernel Driver, Start Type แบบ System Start และ Driver Path ที่ไม่อยู่ในรายการ Baseline ขององค์กร
  2. ตรวจสอบการโหลด Driver ผ่าน Sysmon Event ID 6, Windows System Log หรือ EDR Driver Telemetry โดยพิจารณาค่า Hash, Digital Signature, Certificate, Publisher, Driver Path และเวลาที่ Driver ถูกโหลดเข้าสู่ระบบ
  3. สร้าง Rule สำหรับตรวจสอบการสร้างหรือแก้ไข Registry Path Services\kernelquick, HKLM\SOFTWARE\IpDates และ Registry Value ที่ขึ้นต้นด้วย KernelQuick_* ผ่าน Sysmon Event ID 12-14 หรือ EDR Registry Telemetry
  4. เฝ้าระวังพฤติกรรม Process Injection เช่น การจัดสรรหน่วยความจำแบบ Executable การเขียนข้อมูลไปยัง Process อื่น การเปลี่ยน Memory Protection, Thread หรือ APC Activity และ Executable Region ที่ไม่เชื่อมโยงกับ Image File ปกติ โดยเฉพาะเหตุการณ์ที่เกิดขึ้นภายใน dwm.exe
  5. ตรวจสอบ File Creation และ File Deletion ที่เกี่ยวข้องกับไฟล์ Driver นามสกุล .sys รวมถึงการลบหรือการหายไปของ Driver ของผลิตภัณฑ์ AV/EDR และเชื่อมโยงกับช่วงเวลาที่ Endpoint Telemetry ลดลงหรือขาดหายโดยไม่มีแผนบำรุงรักษารองรับ
  6. ส่ง Windows System Log, Security Log, Sysmon, EDR Telemetry, Firewall, Proxy และ DNS Log เข้าสู่ Centralized Logging หรือ SIEM เพื่อให้สามารถค้นหาและเชื่อมโยงเหตุการณ์ย้อนหลังได้ แม้เครื่องเป้าหมายหรือ Security Agent จะถูกรบกวน
  7. จัดทำ Baseline ของ Driver และ Service ที่ได้รับอนุญาต โดยบันทึกค่า Hash, Publisher, Certificate, File Path, Service Name, Service Type และ Start Type เพื่อใช้เปรียบเทียบเมื่อพบ Driver หรือ Service ใหม่ที่ไม่เคยปรากฏในระบบ


🔒 ระยะยาว: Incident Playbook และการเตรียมพร้อม


  1. จัดทำ Playbook สำหรับกรณีตรวจพบ Malicious Driver หรือ Kernel Rootkit โดยระบุขั้นตอนตั้งแต่การตรวจสอบ Alert การแยกเครื่อง การเก็บ Memory Image การตรวจ Driver และ Service การตรวจ Registry การประเมินสถานะ AV/EDR และเกณฑ์การตัดสินใจว่าจะ Remove, Restore หรือ Reimage ระบบ
  2. กำหนด Escalation Workflow ว่าเมื่อพบ Driver ต้องสงสัยหรือ EDR Telemetry ขาดหาย ต้องแจ้งผู้ที่เกี่ยวข้อง เช่น SOC, Incident Response Team, Endpoint Security, Windows Administrator, System Owner, Network Team และ Management ตามระดับผลกระทบ
  3. กำหนดมาตรฐานการเก็บรักษาหลักฐาน เช่น โครงสร้าง Folder รูปแบบชื่อไฟล์ การคำนวณ Hash, Chain of Custody และวิธีจัดเก็บ Memory Image, Registry Hive, Driver File, Windows Event Log และ Screenshot เพื่อให้การตรวจสอบแต่ละครั้งมีมาตรฐานเดียวกัน
  4. เพิ่มมาตรการควบคุมการโหลด Driver เช่น Driver Allowlisting, Microsoft Vulnerable Driver Blocklist และ HVCI/Memory Integrity ตามความเหมาะสม โดยควรทดสอบนโยบายใน Audit Mode ก่อนบังคับใช้งานจริง เพื่อลดผลกระทบต่อ Driver ที่จำเป็นต่อการดำเนินธุรกิจ
  5. ซ้อม Tabletop Exercise หรือ Technical Drill เป็นระยะ โดยจำลองสถานการณ์ตรวจพบ Kernel Driver ต้องสงสัย การหายไปของ EDR Telemetry และการพบ Process Injection เพื่อให้ทีมที่เกี่ยวข้องเข้าใจบทบาท การเก็บหลักฐานก่อน Shutdown การแยกเครื่อง และการกู้คืนระบบเมื่อเกิดเหตุการณ์จริง


8. ข้อจำกัดของการวิเคราะห์


  • รายงานนี้เป็นการสรุปและวิเคราะห์จาก Public Threat Intelligence (Check Point Research) ไม่ใช่การตรวจพิสูจน์หลักฐานดิจิทัลจากเหตุการณ์ที่เกิดขึ้นกับองค์กรใดองค์กรหนึ่งโดยตรง
  • ลำดับ Execution Flow เป็นการสรุปจากข้อมูลภัยคุกคามสาธารณะ ไม่ใช่ผลตรวจพิสูจน์จากเครื่องผู้เสียหายโดยตรง
  • IOC ชุดนี้ รวมถึง External IP อาจมีการเปลี่ยนแปลงหรือถูกใช้ซ้ำโดยผู้อื่นได้ตามเวลา ควรตรวจสอบร่วมกับ Threat Intelligence ล่าสุดก่อนนำไปใช้ Block โดยตรง
  • Detection Rules ที่ให้ไว้อยู่ในสถานะ Experimental ควรผ่านการทดสอบในสภาพแวดล้อม Lab ขององค์กรก่อนนำไปใช้งานจริงบน Production เพื่อประเมิน False Positive ที่อาจเกิดขึ้น
  • การไม่พบไฟล์หรือ Registry บน Live System ไม่ได้ยืนยันว่า Artifact ไม่มีอยู่ หาก Rootkit กำลังกรองผลลัพธ์อยู่ ควรใช้ Offline Analysis (Disk Image, Registry Hive, Memory Image) ประกอบการตรวจสอบ


9. วิเคราะห์ในมุมมองจาก TXEC


ValleyRAT/Winos4.0 สะท้อนให้เห็นแนวโน้มที่น่ากังวลของมัลแวร์ที่ลงทุนพัฒนาความสามารถระดับ Kernel เพื่อยกระดับการหลบเลี่ยงการตรวจจับ ประเด็นที่ TXEC อยากเน้นย้ำเป็นพิเศษมีดังนี้


1. สถาปัตยกรรมแบบ Modular ทำให้ความเสี่ยงขยายตัวได้ตามคำสั่งของผู้ควบคุม

การแยก Driver Plugin ออกจาก Rootkit Driver ทำให้ผู้ควบคุมสามารถเลือกโหลดความสามารถเพิ่มเติมภายหลังการเข้าถึงเครื่องแล้วตามต้องการ องค์กรที่พบ Driver Plugin เพียงอย่างเดียวจึงไม่ควรประเมินความเสี่ยงต่ำเกินจริง เนื่องจากความสามารถของ Rootkit อาจถูกขยายเพิ่มเติมได้ตลอดเวลาที่ยังเชื่อมต่อกับ C2


2. ForceDeleteFile() คือเทคนิคที่กระทบ Visibility ขององค์กรโดยตรง

การลบ Driver ของผลิตภัณฑ์ AV/EDR ในระดับ Kernel ผ่าน IRP โดยตรงเป็นเทคนิคที่มีประสิทธิภาพสูงในการทำลาย Telemetry ที่จำเป็นต่อการตรวจสอบเหตุการณ์ องค์กรควรมีการ Monitor สถานะสุขภาพของ EDR Agent และ Driver แยกต่างหากจาก Alert ปกติ เพื่อให้ทราบทันทีหากระบบป้องกันถูกรบกวน


3. Driver Signing ที่ถูกต้องไม่ได้แปลว่าปลอดภัย

กรณีที่ Driver ถูก Compile ในปี 2023 แต่ลงนามด้วย Certificate เก่าที่ยังไม่ถูกเพิกถอน แสดงให้เห็นช่องว่างของ Windows Driver Signing Policy ที่ผู้โจมตีสามารถใช้ประโยชน์ได้ องค์กรควรเสริมการตรวจสอบด้วย Driver Allowlisting และ Vulnerable Driver Blocklist แทนการเชื่อถือสถานะ Signed เพียงอย่างเดียว


4. IOC และ Detection Rules ในรายงานนี้ควรใช้เป็นจุดเริ่มต้น ไม่ใช่การป้องกันที่สมบูรณ์

เนื่องจากมัลแวร์แบบ Modular สามารถปรับเปลี่ยน Component และ IOC เฉพาะเจาะจงได้ตามการพัฒนาของผู้โจมตี องค์กรควรให้ความสำคัญกับ Detection ที่อ้างอิงจาก Behavior Chain (Driver Load → Service Creation → Registry Configuration → APC Injection → AV/EDR Driver Deletion) มากกว่าการพึ่งพา IOC แบบ Static เพียงอย่างเดียว


รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า



🔒 เนื้อหานี้จัดทำขึ้นเพื่อสมาชิก TXEC โดยเฉพาะ
กรุณาอย่าเผยแพร่นอกแพลตฟอร์ม TXEC โดยไม่ได้รับอนุญาต
IOC และ Detection Rules สามารถนำไปใช้ในองค์กรของท่านได้โดยอ้างอิงที่มาว่า "TXEC Team" และควรทดสอบในสภาพแวดล้อม Lab ก่อนนำไปใช้งานจริงบน Production



ความคิดเห็น