ตรวจจับ Ransomware ด้วย Wazuh: ตั้งค่าอะไรบ้าง

Wazuh ตรวจจับ ransomware ได้จากพฤติกรรมก่อนและระหว่างการเข้ารหัส แต่ค่าเริ่มต้นยังไม่พอ ต้องตั้งเพิ่มสี่ส่วน คือ เก็บ log ของ Sysmon บน Windows, เขียน custom rule สำหรับคำสั่งลบ shadow copy และปิดการกู้คืน (ruleset ของ Wazuh ไม่มี rule นี้มาให้), เปิด FIM แบบ realtime กับโฟลเดอร์ข้อมูลพร้อม rule ที่นับไฟล์ที่เปลี่ยนจำนวนมากในเวลาสั้น ๆ และส่ง alert ระดับสูงไปถึงคนที่ต้องตอบสนอง Wazuh ไม่ใช่ EDR ที่รับประกันว่าจะหยุดการเข้ารหัสได้ จึงควรเริ่มจากแจ้งเตือนอย่างเดียวก่อนเปิด active response

บทความนี้เป็นภาคปฏิบัติต่อจาก Ransomware คืออะไร? ป้องกันและรับมืออย่างไร ซึ่งสรุปไว้แล้วว่าสัญญาณของ ransomware มีอะไรบ้างและ Wazuh ช่วยตรงไหน ที่นี่ลงรายละเอียดระดับการตั้งค่า ได้แก่ ต้องเก็บ log อะไร rule ไหนมีมาให้และไหนต้องเขียนเอง FIM ตั้งแบบไหน alert ส่งไปที่ใด และทดสอบอย่างไรโดยไม่เสี่ยงกับระบบจริง เขียนสำหรับผู้ดูแลระบบที่ติดตั้ง Wazuh แล้ว ถ้ายังไม่รู้จัก Wazuh อ่าน Wazuh คืออะไร ก่อน ถ้าสงสัยว่าควรใช้แทน EDR ได้ไหม อ่าน Wazuh กับ EDR และเรื่องการวางเครื่องกับการลด alert noise อยู่ใน วางแผนติดตั้ง Wazuh

ข้อมูลเรื่อง Wazuh อ้างจากเอกสาร Wazuh 4.x ฉบับปัจจุบัน ruleset ของ Wazuh v4.14.9 บน GitHub และบทความบน blog ของ Wazuh ส่วนเทคนิคการโจมตีอ้างจาก MITRE ATT&CK ตรวจทั้งหมด ณ วันที่ 8 พฤศจิกายน 2026 (พ.ศ. 2569) ตัวอย่างการตั้งค่าในบทความตัดมาให้สั้นและต้องทดสอบกับระบบของคุณก่อนใช้

Wazuh ตรวจจับ ransomware ได้จริงแค่ไหน?

Wazuh ตรวจจับจาก log และการเปลี่ยนแปลงของไฟล์ที่ agent ส่งมา แล้วเทียบกับ rule บน server เมื่อ rule ตรงก็สร้าง alert ตาม level ที่ตั้งไว้ จุดแข็งคือมองเห็นพฤติกรรมที่ ransomware หลายตระกูลมักทำ เช่น ลบ shadow copy ปิดเครื่องมือป้องกัน หยุด service และเปลี่ยนไฟล์จำนวนมากในเวลาสั้น ๆ

ข้อจำกัดที่ต้องรู้ก่อนตั้งความคาดหวัง:

• ตรวจจับได้เฉพาะสิ่งที่มี log เข้ามาและมี rule รองรับ ถ้าไม่ได้เก็บ log ของ Sysmon ก็ไม่เห็น command line ของ process
• Wazuh blog เรื่อง Ransomware protection on Windows (ตุลาคม 2024) ระบุเองว่าวิธีในบทความไม่ได้ตรวจจับ ransomware ได้ทุกชนิด และ active response จะทำงานไม่ได้ถ้าโฟลเดอร์ Program Files ถูกเข้ารหัสไปแล้ว
• การตอบสนองอัตโนมัติเป็นสคริปต์ที่รันตาม rule ไม่ใช่การกักกันระดับ kernel แบบ EDR ความต่างนี้อธิบายไว้ใน Wazuh กับ EDR

ดังนั้นเป้าหมายที่ทำได้จริงคือ เห็นสัญญาณให้เร็วพอที่คนจะตัดสินใจแยกเครื่องหรือหยุดบริการก่อนความเสียหายลาม ส่วนการกู้คืนยังต้องพึ่ง backup ที่ ransomware ลบไม่ได้

พฤติกรรมไหนของ ransomware ที่ Wazuh มองเห็นได้?

ตารางนี้จับคู่เทคนิคใน MITRE ATT&CK กับแหล่งข้อมูลและ rule ของ Wazuh รายการสัญญาณทั้งหมดที่ CISA ให้ตามหาอยู่ในบทความเรื่อง ransomware แล้ว ที่นี่ดูเฉพาะว่าแต่ละอย่างต้องตั้งอะไรใน Wazuh

เรื่อง ID ของ ATT&CK: ตั้งแต่ ATT&CK v19 (ปัจจุบัน v20) Disable or Modify Tools ย้ายไปอยู่ที่ T1685 และหน้า T1562.001 เดิมพาไปที่ T1685 ส่วน rule ของ Wazuh v4.14.9 ยัง tag เป็น T1562.001 ตอนค้นใน dashboard จึงต้องค้นด้วย ID เดิม

การเคลื่อนไปเครื่องอื่น (T1021 Remote Services เช่น RDP และ SMB) ดูได้จาก Security log ที่ agent บน Windows เก็บเป็นค่าเริ่มต้นอยู่แล้ว แต่การแยกการล็อกอินปกติกับผิดปกติต้องรู้จักระบบของตัวเอง เราจึงไม่ใส่ไว้ในตาราง

ต้องเก็บ log อะไรบน Windows ให้ Wazuh เห็น ransomware?

ตามเอกสาร log data collection agent บน Windows เก็บ channel System, Application และ Security เป็นค่าเริ่มต้น ซึ่งไม่มี command line ของ process ที่ใช้ตรวจ T1490 และ T1489 จึงต้องเพิ่มสองแหล่ง คือ Sysmon และ Windows Defender

Sysmon ต้องเปิด event ไหนบ้าง?

Sysmon เป็น service และ driver ของ Microsoft ที่บันทึกกิจกรรมของระบบลง Windows event log Microsoft ระบุว่า Sysmon ไม่ได้วิเคราะห์ event ที่ตัวเองบันทึก การวิเคราะห์จึงเป็นหน้าที่ของ SIEM อย่าง Wazuh event ที่เกี่ยวกับ ransomware มีดังนี้

• Event ID 1 (Process creation): บันทึก command line เต็มและ process แม่ เป็นแหล่งหลักสำหรับ vssadmin, wbadmin, bcdedit และ sc stop
• Event ID 10 (ProcessAccess): ใช้ตรวจเครื่องมือที่อ่านหน่วยความจำของ lsass.exe แต่มีปริมาณมาก ต้องกรองในไฟล์ config
• Event ID 11 (FileCreate) และ 13 (Registry value set): ใช้ประกอบ เช่น ไฟล์ใหม่ที่ถูกสร้างหรือเขียนทับ และการแก้ registry
• Event ID 23 และ 26 (FileDelete): Event 23 เก็บสำเนาไฟล์ที่ถูกลบไว้ที่ C:\Sysmon ซึ่ง Microsoft เตือนว่าอาจโตจนใหญ่เกินไป ถ้าต้องการแค่รู้ว่ามีการลบให้ใช้ Event 26 ซึ่งบันทึกโดยไม่เก็บไฟล์
• Event ID 3 (Network connection): ปิดเป็นค่าเริ่มต้น เปิดเมื่อต้องการดู traffic ระหว่างเครื่อง

Microsoft แนะนำให้ใช้ไฟล์ config กรอง event เพราะเก็บทุกอย่างไม่ได้ ติดตั้งด้วย sysmon -accepteula -i c:\windows\config.xml และหน้าเอกสารของ Sysmon (ฉบับ 10 กันยายน 2026) ระบุว่ารองรับ Windows 11 ขึ้นไปและ Windows Server 2019 ขึ้นไป ถ้ามีเซิร์ฟเวอร์รุ่นเก่ากว่านั้นให้ตรวจรายการที่ Microsoft รองรับก่อนวางแผน

จากนั้นเพิ่ม localfile ใน ossec.conf ของ agent แล้ว restart agent ด้วย Restart-Service -Name wazuh

<localfile>
  <location>Microsoft-Windows-Sysmon/Operational</location>
  <log_format>eventchannel</log_format>
</localfile>

ต้องเก็บ log ของ Windows Defender ด้วยไหม?

ควรเก็บ เพราะ ransomware มักปิดเครื่องมือป้องกันก่อนเข้ารหัส ตามเอกสารของ Wazuh ให้เพิ่ม localfile สำหรับ channel Microsoft-Windows-Windows Defender/Operational แบบ eventchannel แล้ว rule ในไฟล์ 0600-win-wdefender_rules.xml (rule 62100 ขึ้นไป) จะทำงาน เช่น rule 62152 เมื่อ real-time protection ถูกปิด (event 5001)

สังเกตว่า rule 62152 มี level 5 ซึ่งต่ำกว่าค่าเริ่มต้นของการส่งอีเมล (level 12) ถ้าไม่ปรับ alert นี้จะอยู่ใน dashboard เฉย ๆ โดยไม่มีใครได้รับแจ้ง วิธีส่งต่ออยู่ในหัวข้อเรื่อง alert ด้านล่าง

นอกจากนี้ #StopRansomware Guide ของ CISA แนะนำให้เปิด log ของ PowerShell (รวมถึง module, script block และ transcription logging) และเก็บไว้อย่างน้อย 180 วัน ถ้าเปิดแล้วก็ส่งเข้า Wazuh ด้วย localfile แบบ eventchannel ในรูปแบบเดียวกันได้

ทำไม Wazuh ไม่แจ้งเตือนเมื่อมีการลบ shadow copy?

เพราะ ruleset มาตรฐานไม่มี rule นี้ เราค้นไฟล์ rule ทั้งหมดใน ruleset ของ Wazuh v4.14.9 ด้วยคำว่า vssadmin, shadow, wbadmin และ bcdedit ไม่พบ rule ที่ตรวจการลบ shadow copy หรือ backup catalog เลย ที่พบมีเพียง rule 92023 ซึ่งตรวจ PowerShell ที่อ่าน hive SAM หรือ SECURITY จาก shadow copy (T1003.002) และ rule แจ้ง error ของ service VSS

Sysmon Event 1 ทุกตัวเข้าที่ rule 61603 ซึ่งมี level 0 คือรับไว้แต่ไม่สร้าง alert การตรวจ T1490 จึงต้องเขียน custom rule ลูกที่อ้าง <if_sid>61603</if_sid> แล้วจับ command line ตัวอย่างนี้ดัดแปลงจาก rule 107014 ในบทความเรื่อง Cephalus ransomware (Wazuh blog, ธันวาคม 2025) ใส่ไว้ใน local_rules.xml บน server

<rule id="107014" level="12">
  <if_sid>61603</if_sid>
  <field name="win.eventdata.CommandLine" type="pcre2">(?i)vssadmin\sdelete\sshadows\s\/all\s\/quiet</field>
  <description>Shadow copy deletion with vssadmin</description>
  <mitre><id>T1490</id></mitre>
</rule>

ข้อสังเกตเมื่อนำไปใช้:

• regex นี้แคบ: จับเฉพาะคำสั่งที่เขียนตรงตามรูปแบบ ถ้าผู้โจมตีเรียกต่างไปเล็กน้อย rule ก็ไม่ตรง ส่วนบทความปี 2024 ของ Wazuh แยกเป็นหลาย rule (100615–100619 สำหรับการลบ shadow copy ทั้งผ่าน vssadmin และ wmic shadowcopy delete, 100621 สำหรับ wbadmin delete catalog และ 100611, 100620, 100622 สำหรับการแก้ค่าการบูตและการกู้คืน) กลุ่ม 100615–100619 เป็น level 12 และ map กับ T1490 (และ T1059.003) ส่วน 100620–100622 เป็น level 12 แต่ blog map ไว้กับ T1059 และ 100611 เป็น level 10 ถ้านำไปใช้ควรแก้ MITRE ID ของกลุ่มนี้เป็น T1490
• เลข rule เป็นตัวอย่าง: ให้เลือกเลขของตัวเองในช่วงที่ Wazuh กันไว้ให้ custom rule และทดสอบไม่ให้ชนกับ rule ที่มีอยู่ (วิธีจัดการ local_rules.xml อยู่ในบทความวางแผนติดตั้ง)
• คำสั่งอื่นในกลุ่มเดียวกัน: ตัวอย่างที่ ATT&CK T1490 ระบุ ได้แก่ wmic shadowcopy delete, wbadmin.exe delete catalog -quiet และ bcdedit.exe /set {default} bootstatuspolicy ignoreallfailures ส่วนการหยุด service ตาม T1489 ใช้รูปแบบ rule เดียวกันกับ net stop และ sc stop แต่ต้องกรองชื่อ service เพราะผู้ดูแลระบบหยุด service เป็นงานปกติ
• ผู้ดูแลระบบอาจลบ shadow copy เองด้วย: ก่อนตั้ง level สูง ให้ดูก่อนว่าในระบบจริงมีสคริปต์หรือซอฟต์แวร์ backup ตัวไหนเรียกคำสั่งเหล่านี้เป็นประจำ

บทความปี 2024 ยังสาธิตการสร้าง shadow copy ตามรอบแล้วปิด service VSS เพื่อไม่ให้ ransomware ลบ snapshot ได้ วิธีนี้เป็นตัวอย่างแนวคิด (PoC) ของผู้ผลิตที่เปลี่ยนพฤติกรรมปกติของ VSS และซอฟต์แวร์ backup เราไม่แนะนำให้ใช้เป็นแนวปฏิบัติมาตรฐาน การเตรียมสำเนาสำหรับกู้คืนอยู่ในบทความเรื่อง backup กัน ransomware

ตั้ง FIM ของ Wazuh อย่างไรให้เห็นการเข้ารหัสไฟล์จำนวนมาก?

File Integrity Monitoring (FIM หรือ syscheck) แจ้งเมื่อไฟล์ในโฟลเดอร์ที่ตั้งเฝ้าถูกสร้าง แก้ หรือลบ การเข้ารหัสไฟล์ทำให้ checksum เปลี่ยน (rule 550) และบางตระกูลสร้างไฟล์ใหม่แล้วลบไฟล์เดิม (rule 554 และ 553) แต่ FIM จะเห็นทันหรือไม่ขึ้นกับโหมดที่ตั้ง

realtime, who-data และ scheduled scan ต่างกันอย่างไร?

รายละเอียดจากเอกสาร advanced settings ที่มีผลกับการตรวจ ransomware:

• Linux แบบ audit: ต้องติดตั้ง auditd (และ audispd-plugins สำหรับ Audit 3.1.1 ขึ้นไป) และต้องไม่มี rule -a never,task ใน audit rules
• Linux แบบ eBPF: ต้องใช้ kernel ที่มี BPF ring buffer และ BTF (upstream 5.8 ขึ้นไป หรือ kernel ที่ backport มา เช่น RHEL 8.10) ชื่อ process ในโหมดนี้ยาวได้ไม่เกิน 15 ตัวอักษร rule ที่จับด้วย path เต็มของโปรแกรมจึงไม่ตรงกับ alert แบบ eBPF และไม่ควรใช้ audit กับ eBPF พร้อมกัน
• เมื่อไฟล์เปลี่ยนพร้อมกันจำนวนมาก: เอกสารแนะนำให้ปรับ queue_size ของ eBPF สำหรับการลบไฟล์จำนวนมาก และปรับ syscheck.rt_delay ใน internal_options.conf บน Linux เมื่อ event ท่วม

ควรเฝ้าโฟลเดอร์ไหน?

บทความของ Wazuh ทั้งสองเรื่องเฝ้าเฉพาะโฟลเดอร์ของผู้ใช้บน Windows บทความปี 2024 เฝ้า Downloads, Documents และ Desktop ใต้ C:\Users\* ส่วนเรื่อง Cephalus เฝ้าเฉพาะ Downloads ทั้งคู่เป็นตัวอย่างบนเครื่องผู้ใช้เครื่องเดียว ส่วนบนเซิร์ฟเวอร์ ผู้ผลิตไม่ได้ให้รายการโฟลเดอร์ไว้ ข้อแนะนำต่อไปนี้จึงเป็นความเห็นของเราเอง

• File server: เฝ้าโฟลเดอร์ที่แชร์บนเครื่อง file server เอง เพราะเอกสาร basic settings ระบุว่าตั้งแต่ Wazuh 4.13.0 FIM บน Windows ไม่รองรับ UNC path หรือ network drive ที่ map ไว้ในทุกโหมด agent บนเครื่องผู้ใช้จึงมองไม่เห็นไฟล์บน share ต้องติดตั้ง agent บน file server
• Web server: เฝ้า document root และไฟล์ config ของแอปพลิเคชัน
• ฐานข้อมูล: ไฟล์ข้อมูลของฐานข้อมูลเปลี่ยนตลอดเวลา FIM จะมีแต่ noise ให้เฝ้าโฟลเดอร์ที่เก็บไฟล์ dump และ config แทน และใช้ rule เรื่องการหยุด service (T1489) ช่วย
• Linux: ค่าเริ่มต้นเฝ้า /etc, /usr/bin, /usr/sbin, /bin, /sbin และ /boot อยู่แล้ว เพิ่มโฟลเดอร์ข้อมูลที่ระบบเก็บไฟล์ของผู้ใช้

ไม่ควรเฝ้ากว้างเกินไป FIM เก็บ entry ได้ 100000 รายการเป็นค่าเริ่มต้น (file_limit) และส่ง event ได้ 50 ต่อวินาที (max_eps) ตามเอกสารอ้างอิง syscheck เราประเมินว่าเมื่อไฟล์จำนวนมากถูกเข้ารหัสพร้อมกัน event ที่เกินเพดานนี้จะไปถึง server ช้ากว่าเวลาที่เกิดจริง ข้อนี้เป็นข้อสรุปของเราจากค่าเริ่มต้น ไม่ใช่คำอธิบายของผู้ผลิต

ไม่แนะนำให้เปิด report_changes กับโฟลเดอร์ข้อมูล เพราะใช้ได้เฉพาะไฟล์ข้อความ และต้องคัดลอกไฟล์ที่เฝ้าไว้เก็บบนเครื่อง ทำให้ใช้พื้นที่ดิสก์เพิ่ม

ตัวอย่างการตั้งค่า (Windows แบบ realtime ตาม blog ของ Wazuh และ Linux แบบ who-data ตามเอกสาร)

<directories realtime="yes">C:\Users\*\Documents</directories>
<directories check_all="yes" whodata="yes">/etc</directories>

เขียน rule จับไฟล์ที่เปลี่ยนจำนวนมากอย่างไร?

rule 550 แจ้งทีละไฟล์ เมื่อไฟล์ถูกเข้ารหัสพร้อมกันจะได้ alert จำนวนมากเกินกว่าจะอ่านทัน สิ่งที่ต้องการคือ rule ที่สรุปว่า "มีไฟล์เปลี่ยนจำนวนมากในเวลาสั้น ๆ" ตัวอย่างนี้ดัดแปลงจาก rule 100627 ใน blog ปี 2024 ซึ่งแจ้งเมื่อ rule 550 เกิดกับไฟล์ใต้ C:\Users ครบ 10 ครั้งภายใน 30 วินาที

<rule id="100627" level="7" timeframe="30" frequency="10" ignore="300">
  <if_matched_sid>550</if_matched_sid>
  <field name="file" type="pcre2">(?i)C:\\Users</field>
  <description>Multiple Files modified in the User directory in a short time</description>
</rule>

ใน blog เดียวกัน rule 100626 แจ้งเมื่อไฟล์ที่มี md5 เดียวกันถูกสร้างในหลายโฟลเดอร์ ซึ่งเป็นลักษณะของ ransom note และ rule 100628 เชื่อมสัญญาณเหล่านี้เป็น alert "Ransomware activity detected" ที่ level 12

ตัวเลข 10 ไฟล์ใน 30 วินาทีเป็นค่าของตัวอย่าง ไม่ใช่ค่าที่เหมาะกับทุกระบบ โฟลเดอร์ที่มีงาน sync หรือ build เปลี่ยนไฟล์เป็นร้อยในไม่กี่วินาทีเป็นปกติ ให้ดูจำนวนการเปลี่ยนแปลงจริงในช่วงปกติก่อนตั้งค่า และใช้ ignore กัน alert ซ้ำ

ฝั่ง Linux ต้องตั้งอะไรเพิ่ม?

บน Linux Wazuh เฝ้า system call ด้วย Linux Audit system ตัวอย่างใน PoC guide เรื่องตรวจคำสั่งอันตราย ตั้ง audit rule ให้บันทึก execve ของผู้ใช้ อ่าน /var/log/audit/audit.log ด้วย <log_format>audit</log_format> แล้วใช้ CDB list ชื่อ suspicious-programs คู่กับ custom rule level 12 (ต่อจาก rule 80792) เพื่อแจ้งเมื่อมีการรันโปรแกรมในรายการ

สำหรับ ransomware บน Linux เราแนะนำให้เริ่มจากสามเรื่อง

• เปิด FIM แบบ who-data กับโฟลเดอร์ข้อมูลและ /etc เพื่อให้รู้ว่าบัญชีและ process ใดแก้ไฟล์
• บันทึกการรันคำสั่งของผู้ใช้ด้วย auditd ตามรูปแบบใน PoC แล้วเพิ่มรายการโปรแกรมที่ไม่ควรถูกรันบนเซิร์ฟเวอร์นั้น
• ดูการหยุด service ด้วย systemctl stop ซึ่ง ATT&CK T1489 ระบุเป็นพฤติกรรมบน Linux

VirusTotal และ YARA ช่วยได้แค่ไหน?

ทั้งสองอย่างต่อยอดจาก FIM และอธิบายระดับแนวคิดไว้แล้วใน Wazuh กับ EDR ประเด็นที่มีผลกับการตั้งค่ามีดังนี้

• VirusTotal: integration ส่งเฉพาะ hash ของไฟล์จาก alert ของ FIM ไม่ได้อัปโหลดไฟล์ ตั้งด้วย <group>syscheck</group> ใน <integration> เมื่อ engine ตรวจพบ rule 87105 (level 12) จะทำงาน และเมื่อติดเพดาน API จะเป็น rule 87101 VirusTotal ระบุว่า Public API ใช้ได้ 500 request ต่อวันและ 4 request ต่อนาที และห้ามใช้ในผลิตภัณฑ์หรือบริการเชิงพาณิชย์ ในทางปฏิบัติจึงช่วยจับไฟล์ malware ที่ VirusTotal รู้จัก hash แล้ว แต่ไม่ช่วยกับไฟล์ข้อมูลที่ถูกเข้ารหัส ซึ่งได้ hash ใหม่ทุกไฟล์
• YARA: FIM เห็นการเปลี่ยนแปลงแล้วสั่ง active response ให้รัน yara.sh หรือ yara.bat ผลที่ได้ต้องเพิ่ม decoder บน server เอง เพราะ Wazuh ไม่ได้ decode ให้ตั้งแต่ต้น และเอกสารเตือนว่า yara.bat ลบทุกไฟล์ที่ตรงกับ rule ของ YARA และแนะนำให้ทดสอบใน sandbox ไม่ใช่บน production

Vulnerability Detection และ SCA ช่วยกัน ransomware ก่อนโดนอย่างไร?

สองโมดูลนี้ไม่ได้ตรวจจับ ransomware แต่ช่วยปิดทางเข้า Vulnerability Detection เทียบรายการซอฟต์แวร์บนเครื่องกับฐานข้อมูลช่องโหว่ เพื่อหาเครื่องที่ยังไม่ได้ patch ส่วน Security Configuration Assessment (SCA) สแกนหาการตั้งค่าที่ไม่ปลอดภัยและแนะนำวิธีแก้ โดย policy ที่มีมาให้ส่วนใหญ่อิง CIS benchmark ผลของทั้งสองโมดูลมีประโยชน์ก็ต่อเมื่อมีคนนำไปจัดลำดับ patch และแก้ค่าตามรอบ MA

ควรเปิด Active Response ตั้งแต่แรกไหม?

ไม่ควร Active response รันสคริปต์บนเครื่องปลายทางเมื่อ alert ตรงกับ rule ID, level หรือ group ที่กำหนด เอกสารของ Wazuh เตือนว่าการตั้ง rule และ response ที่ไม่ดีอาจทำให้เครื่องเสี่ยงขึ้น ถ้า rule ยังมี false positive สคริปต์ก็จะบล็อกหรือลบสิ่งที่ไม่ควรถูกบล็อกหรือลบ

"แจ้งเตือนอย่างเดียว" ไม่ใช่ค่าที่ต้องตั้งใน Wazuh แต่หมายถึงยังไม่เพิ่ม block <active-response> หรือใส่ <disabled>yes</disabled> ไว้จนกว่าจะเห็นว่า rule นั้นแม่นพอในระบบจริง รูปแบบ block ตามเอกสาร how to configure (เลข rule เป็นตัวอย่าง)

<active-response>
  <disabled>yes</disabled>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>100200</rules_id>
  <timeout>600</timeout>
</active-response>

สคริปต์บล็อก IP อย่าง firewall-drop (Linux) หรือ netsh (Windows) อ่าน IP ต้นทางจาก alert (ฟิลด์ srcip หรือ win.eventdata.ipAddress ตามsource code ของ Wazuh v4.14.9) ถ้า rule ที่ผูกไว้ไม่มี IP ในข้อมูล เช่น rule จาก Sysmon Event 1 สคริปต์จะไม่มีอะไรให้บล็อก

สิ่งที่ต้องรู้ก่อนเปิด:

• สคริปต์ที่มีมาให้: ตามรายการสคริปต์เริ่มต้น บน Windows มีแค่ netsh.exe (บล็อก IP), restart-wazuh.exe และ route-null.exe ไม่มีสคริปต์แยกเครื่องหรือหยุด process ส่วนสคริปต์ remove-threat ใน PoC ของ VirusTotal เป็นตัวอย่างที่ผู้ผลิตให้ตรวจสอบเองก่อนใช้
• stateful กับ stateless: ใส่ <timeout> กับคำสั่งที่ตั้ง timeout_allowed แล้ว การบล็อกจะถูกยกเลิกเองเมื่อครบเวลา ถ้าไม่ใส่จะเป็นการทำครั้งเดียว
• ยกเว้นเครื่องสำคัญ: ใช้ <white_list> ใน <global> ระบุ IP หรือ hostname ที่ห้ามถูกบล็อก เช่น server ของ Wazuh, gateway และเครื่องผู้ดูแล
• ระวัง location แบบ all: เอกสารเตือนให้ใช้อย่างระมัดระวัง เพราะตั้งผิดแล้วกระทบทั้งสภาพแวดล้อม
• ดูผลได้ที่ active-responses.log บนเครื่องปลายทาง

ลำดับที่เราแนะนำคือ แจ้งเตือนอย่างเดียวจนรู้จำนวน false positive แล้วจึงเปิด active response ทีละ rule บนกลุ่มเครื่องเล็ก ๆ ที่มีคนเฝ้าดูได้ การแยกเครื่องออกจากเครือข่ายเมื่อเกิดเหตุจริง ให้คนเป็นผู้ตัดสินใจหรือใช้ EDR ที่มีอยู่

ออกแบบ alert ให้คนเห็นทันอย่างไร?

rule จะแม่นแค่ไหนก็ช่วยได้น้อย ถ้า alert ค้างอยู่ใน dashboard โดยไม่มีใครเห็น ต้องออกแบบสามเรื่อง คือ alert ไหนสำคัญ ส่งไปที่ไหน และใครตอบ

alert ไหนควรถึงคนทันที?

Wazuh แบ่ง level เป็น 0–16 ตามrules classification เช่น 12 คือเหตุการณ์สำคัญสูง 15 คือการโจมตีรุนแรงที่ต้องดูทันที และ 16 สงวนไว้ให้ custom rule ที่ต้องการระดับสูงสุด ความหมายของแต่ละระดับและวิธีปรับ level อยู่ในบทความวางแผนติดตั้ง ที่ต้องดูสำหรับ ransomware คือ rule ที่เกี่ยวข้องหลายตัวอยู่ต่ำกว่า level 12 ซึ่งเป็นค่าเริ่มต้นของการส่งอีเมล

• level 12: 92900 (อ่านหน่วยความจำ LSASS), 87105 (VirusTotal พบ) และ custom rule เรื่อง T1490 ในตัวอย่างของผู้ผลิต
• level 9: 60117 (ล้าง audit log)
• level 7: 550 (checksum ของไฟล์เปลี่ยน) และ rule frequency ในตัวอย่าง 100627
• level 5: 62152 (ปิด real-time protection ของ Defender)
• level 3: 504–506 (agent หลุดการเชื่อมต่อ ถูกลบ หรือหยุดทำงาน)

ทางเลือกคือเขียน rule ลูกที่ยก level ของเหตุการณ์ที่ระบบคุณถือว่าสำคัญ หรือส่งต่อตาม rule ID หรือ group ตามหัวข้อถัดไป

ส่ง alert ไปทางไหนได้บ้าง?

• อีเมล: ตามเอกสาร alert management เปิดใน <global> ด้วย email_notification, smtp_server, email_from และ email_to แล้วใช้ <email_alerts> แยกผู้รับตาม level, rule ID หรือ group แต่ค่าขั้นต่ำใน <alerts> มีผลเหนือการตั้งแบบแยก และ Wazuh ไม่รองรับ SMTP ที่ต้อง login ต้องส่งผ่าน relay เช่น Postfix นอกจากนี้ email_maxperhour มีค่าเริ่มต้น 12 ฉบับต่อชั่วโมง
• Slack และระบบอื่น: ตามเอกสาร integration มี integration ในตัวสำหรับ Slack, PagerDuty, VirusTotal, Shuffle และ Maltiverse กรองได้ด้วย <level>, <rule_id> หรือ <group> ถ้าใช้ระบบแชตอื่นต้องเขียน integration เองโดยตั้งชื่อขึ้นต้นด้วย custom-

<integration>
  <name>slack</name>
  <hook_url>https://hooks.slack.com/services/...</hook_url>
  <level>12</level>
  <alert_format>json</alert_format>
</integration>

ใครเป็นคนตอบ?

เป็นการตัดสินใจขององค์กร ไม่ใช่การตั้งค่าใน Wazuh ให้เขียนไว้ก่อนเกิดเหตุว่า alert เรื่อง ransomware ส่งถึงใคร นอกเวลาทำงานใครรับ ใครมีอำนาจสั่งตัดเครื่องออกจากเครือข่าย และต้องตอบภายในเวลาเท่าไร ถ้าผู้ให้บริการภายนอกเป็นผู้ดูแล ให้เขียนขอบเขตและเวลาตอบสนองไว้ในสัญญา ดูเช็กลิสต์สัญญา MA และ SLA ขั้นตอนหลังได้รับ alert ซึ่งได้แก่การแยกเครื่อง เก็บหลักฐาน และแจ้งเหตุ อยู่ในบทความเรื่อง ransomware

ทดสอบว่าตรวจจับได้จริงอย่างไร?

ทดสอบใน lab เท่านั้น PoC guide ของ Wazuh แนะนำให้ใช้ VM แยกและทำ snapshot ทันทีหลังติดตั้งเสร็จ เพื่อให้แต่ละการทดสอบไม่กระทบกัน และ Wazuh blog เรื่อง Emulation of ATT&CK techniques (2022) ซึ่งใช้ Atomic Red Team คู่กับ Sysmon แนะนำให้ใช้ VM ที่ทิ้งได้

• T1490: Atomic Red Team T1490 มี test #1 (ลบ shadow copy ด้วย vssadmin), #2 (ผ่าน WMI) และ #3 (wbadmin ลบ backup catalog) test ทั้งสามต้องใช้สิทธิ์ admin โดย #1 และ #2 ลบ shadow copy จริง ส่วน #3 ลบ backup catalog จริง ห้ามรันบนเครื่อง production หรือเครื่องที่ต่อกับ backup จริง ส่วน WMIC นั้น Microsoft ระบุว่าถูกถอดออกและติดตั้งเป็น Feature on Demand ไม่ได้แล้วใน Windows 11 ตั้งแต่ 24H2 ขึ้นไป (อัปเดตสิงหาคม 2026) test #2 จึงรันไม่ได้บนเครื่องรุ่นนั้น
• T1486: test ของ T1486 ใช้เครื่องมือเข้ารหัสทั่วไป เช่น gpg หรือ 7z หรือจำลองการสร้าง ransom note จึงใช้ทดสอบ rule FIM แบบ frequency ได้โดยไม่ต้องใช้ ransomware จริง
• VirusTotal และ YARA: ใช้ไฟล์ทดสอบ EICAR ตามที่ PoC ของ Wazuh ใช้ ห้ามดาวน์โหลดตัวอย่าง malware จริงมาทดสอบ

สิ่งที่ควรเห็นหลังรันแต่ละ test คือ alert ของ custom rule ที่ level ที่ตั้งไว้ และข้อความถึงช่องทางแจ้งเตือนจริง ถ้า alert ไม่ขึ้นให้ไล่ตามลำดับ คือ event ปรากฏใน Event Viewer ของ VM หรือไม่ agent อ่าน channel นั้นหรือไม่ แล้วจึงดูว่า regex ของ rule ตรงกับ command line จริงหรือไม่ จดผลเป็นตาราง test → rule → ช่องทางแจ้งเตือน แล้วทำซ้ำหลังอัปเกรด Wazuh หรือแก้ rule ทุกครั้ง

Checklist: Wazuh ของคุณพร้อมจับ ransomware หรือยัง?

ตอบใช่หรือไม่ใช่ทีละข้อ ข้อที่ตอบว่าไม่ใช่หรือไม่แน่ใจคือจุดที่ต้องแก้ก่อน

• เครื่อง Windows ที่สำคัญติดตั้ง Sysmon พร้อมไฟล์ config ที่กรอง event แล้ว และ agent อ่าน channel Microsoft-Windows-Sysmon/Operational หรือไม่
• agent อ่าน channel ของ Windows Defender หรือ log ของเครื่องมือป้องกันที่ใช้อยู่หรือไม่
• มี custom rule สำหรับ vssadmin, wmic, wbadmin และ bcdedit ที่ level สูงพอจะส่งแจ้งเตือน และเคยทดสอบใน lab แล้วหรือไม่
• มี rule สำหรับการหยุด service สำคัญ เช่นฐานข้อมูลและ backup agent หรือไม่
• Sysmon บันทึก Event 10 แบบกรองแล้ว และ rule 92900 เคยแจ้งเตือนใน lab หรือไม่
• FIM ของโฟลเดอร์ข้อมูลตั้งเป็น realtime หรือ who-data แล้วหรือไม่ (ค่าเริ่มต้นคือสแกนทุก 12 ชั่วโมง)
• file server ทุกเครื่องติดตั้ง agent ของตัวเองแล้วหรือไม่ (agent บนเครื่องผู้ใช้มองไม่เห็นไฟล์บน drive ที่ map ไว้)
• มี rule แบบ frequency บน rule 550 ที่ตั้งค่าจากปริมาณการเปลี่ยนไฟล์ปกติของระบบคุณหรือไม่
• บน Linux มี auditd หรือ eBPF สำหรับ who-data และบันทึก execve ของผู้ใช้หรือไม่
• alert level 12 ขึ้นไป รวมถึง rule ที่คุณยก level เอง ส่งถึงผู้รับผิดชอบทางอีเมล (ผ่าน relay) หรือ Slack แล้วหรือไม่
• มีการแจ้งเตือนเมื่อ agent หยุดทำงานหรือหลุดการเชื่อมต่อหรือไม่
• เขียนไว้หรือยังว่าใครรับ alert นอกเวลาทำงาน และใครมีอำนาจสั่งแยกเครื่อง
• active response ยังปิดอยู่จนกว่าจะรู้จำนวน false positive และมี white_list สำหรับเครื่องสำคัญหรือไม่
• ถ้าใช้ VirusTotal ได้ตรวจเงื่อนไขการใช้งานเชิงพาณิชย์และเพดาน API แล้วหรือไม่
• ทดสอบซ้ำหลังอัปเกรด Wazuh หรือแก้ rule ทุกครั้งหรือไม่

UNIXDEV ช่วยตั้งค่า Wazuh สำหรับ ransomware ได้อย่างไร?

UNIXDEV ติดตั้ง Wazuh ปรับจูน rule เพื่อลด false positive และดูแลระบบตามขอบเขต MA ที่ตกลงกัน งานที่เกี่ยวกับบทความนี้คือ ตรวจว่าเครื่องสำคัญส่ง log ของ Sysmon และ Defender ครบหรือไม่ เขียนและทดสอบ custom rule สำหรับสัญญาณในตาราง ตั้ง FIM ให้เหมาะกับ file server และเซิร์ฟเวอร์แต่ละแบบ และวางช่องทางแจ้งเตือนให้ถึงผู้รับผิดชอบที่องค์กรกำหนด ส่วนงานพื้นฐานอย่างรอบ patch และ backup อยู่ในบริการ DevOps & SRE Managed Services งานรับมือเหตุและนิติวิทยาศาสตร์ดิจิทัลหลังเกิดเหตุควรใช้ผู้เชี่ยวชาญเฉพาะด้านนั้น

แหล่งอ้างอิงและอ่านต่อ

• Wazuh documentation — syscheck reference · FIM basic settings · FIM advanced settings
• Wazuh documentation — Log data collection configuration · Windows Defender logs collection
• Wazuh ruleset v4.14.9 (GitHub)
• Wazuh documentation — VirusTotal integration · YARA
• Wazuh documentation — Active response configuration · Default scripts · global (white_list)
• Wazuh documentation — Alert management · Integration with external APIs · Rules classification
• Wazuh Proof of Concept guide · Monitoring execution of malicious commands · Detecting and removing malware using VirusTotal
• Wazuh blog — Ransomware protection on Windows with Wazuh (2024) · Detecting and responding to Cephalus ransomware (2025) · Emulation of ATT&CK techniques (2022)
• Microsoft Sysinternals — Sysmon · Microsoft — Deprecated features in the Windows client (WMIC)
• VirusTotal — Public vs Premium API
• MITRE ATT&CK — T1490 Inhibit System Recovery · T1486 · T1489 · T1685 · T1003.001 · T1021
• CISA, MS-ISAC, NSA, FBI — #StopRansomware Guide (September 2023)
• Atomic Red Team — T1490 · T1486
• บทความที่เกี่ยวข้อง: Ransomware คืออะไร? ป้องกันและรับมืออย่างไร
• บทความที่เกี่ยวข้อง: Backup กัน Ransomware: Immutable หรือ Offline?
• บทความที่เกี่ยวข้อง: มี EDR หรือ Antivirus แล้ว ต้องมี Wazuh เพิ่มไหม?
• บทความที่เกี่ยวข้อง: วางแผนติดตั้ง Wazuh
• บทความที่เกี่ยวข้อง: Wazuh คืออะไร
• บทความทั้งหมดในหมวด Wazuh และ Security Monitoring

บทความโดย UNIXDEV Team · 8 พฤศจิกายน 2026 · อ้างอิงเอกสาร Wazuh 4.x, ruleset v4.14.9, blog ของ Wazuh, Microsoft, VirusTotal, MITRE ATT&CK และ CISA ณ วันที่เขียน ซึ่งอาจเปลี่ยนภายหลัง ตัวอย่าง rule และการตั้งค่าดัดแปลงจากเอกสารของผู้ผลิต ต้องปรับและทดสอบกับระบบจริงก่อนใช้ ไม่ใช่คำแนะนำทางกฎหมาย