Ransomware คืออะไร? ป้องกันและรับมืออย่างไร

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

บทความนี้เขียนสำหรับทีม IT ผู้บริหาร และเจ้าหน้าที่คุ้มครองข้อมูลส่วนบุคคล (DPO) ของทั้งบริษัทและหน่วยงานรัฐในไทย ครอบคลุมสามช่วง คือก่อนเกิดเหตุ ระหว่างเกิดเหตุ และหลังเกิดเหตุ รวมถึงหน้าที่แจ้งเหตุตามกฎหมายไทย ถ้าต้องการรู้ว่า Wazuh คืออะไร อ่าน Wazuh คืออะไร และถ้าสงสัยว่า SIEM กับ EDR ต่างกันอย่างไร อ่าน มี EDR แล้ว ต้องมี Wazuh เพิ่มไหม แหล่งอ้างอิงทั้งหมดตรวจ ณ วันที่ 7 พฤศจิกายน 2026 (พ.ศ. 2569)

Ransomware คืออะไร?

#StopRansomware Guide ของ CISA (หน่วยงานความมั่นคงปลอดภัยไซเบอร์ของสหรัฐฯ) ให้นิยามว่า ransomware คือมัลแวร์ที่ออกแบบมาเพื่อเข้ารหัสไฟล์บนอุปกรณ์ ทำให้ไฟล์และระบบที่พึ่งพาไฟล์เหล่านั้นใช้งานไม่ได้ จากนั้นผู้โจมตีเรียกค่าไถ่เพื่อแลกกับการถอดรหัส คู่มือฉบับนี้เป็นฉบับปรับปรุงเดือนกันยายน 2023 จัดทำร่วมกันโดย CISA, MS-ISAC, NSA และ FBI แบ่งเป็นสองส่วน คือแนวทางป้องกัน และเช็กลิสต์รับมือเมื่อเกิดเหตุ

คู่มือเดียวกันระบุว่าผู้โจมตีปรับวิธีให้สร้างความเสียหายมากขึ้น โดยขโมยข้อมูลออกไปก่อน แล้วกดดันให้จ่ายด้วยการขู่จะเปิดเผยข้อมูล การใช้ทั้งการเข้ารหัสและการขู่เปิดเผยข้อมูลพร้อมกันเรียกว่า double extortion และบางกรณีผู้โจมตีขโมยข้อมูลแล้วขู่เปิดเผยอย่างเดียวโดยไม่เข้ารหัสเลย ผลที่ตามมาคือ backup ที่ดีช่วยให้กลับมาทำงานได้ แต่ไม่ได้แก้ปัญหาข้อมูลที่ถูกขโมยออกไปแล้ว

ในฐานข้อมูล MITRE ATT&CK ซึ่งรวบรวมเทคนิคของผู้โจมตี การเข้ารหัสข้อมูลคือเทคนิค T1486 Data Encrypted for Impact ส่วนการลบหรือปิดกลไกกู้คืนระบบ เช่น shadow copy และ backup catalog ของ Windows คือ T1490 Inhibit System Recovery ซึ่ง MITRE ระบุว่าอาจทำให้เข้าถึง backup และทางเลือกในการกู้คืนไม่ได้

Ransomware สมัยนี้เข้ามาและลุกลามในองค์กรอย่างไร?

การเข้ารหัสมักเป็นขั้นสุดท้าย ก่อนหน้านั้นผู้โจมตีต้องเข้ามาให้ได้ ยกระดับสิทธิ์ เคลื่อนไปยังเครื่องอื่น และขโมยข้อมูลออกไป ช่วงก่อนเข้ารหัสจึงเป็นช่วงที่องค์กรมีโอกาสตรวจพบ ช่องทางเข้าที่ #StopRansomware Guide จัดกลุ่มไว้ได้แก่ ช่องโหว่และการตั้งค่าผิดของระบบที่เปิดสู่อินเทอร์เน็ต บัญชีที่ถูกขโมย phishing มัลแวร์ที่ฝังเข้ามาก่อน (precursor malware หรือ loader/dropper) วิศวกรรมสังคมแบบซับซ้อน และบุคคลที่สามหรือผู้ให้บริการดูแลระบบ (managed service provider)

ตารางนี้เป็นตัวอย่างที่เราเรียบเรียงจากชื่อเทคนิคใน ATT&CK ไม่ใช่ลำดับที่ผู้โจมตีทุกกลุ่มทำเหมือนกัน CISA ระบุว่าผู้โจมตีมักเข้ามาทางบริการระยะไกลที่เปิดไว้และป้องกันไม่ดี แล้วเคลื่อนไปในเครือข่ายด้วย RDP ของ Windows เอง และมักเข้าทาง VPN ที่มีช่องโหว่หรือใช้บัญชีที่ถูกขโมย

สกมช. พูดถึง ransomware ในไทยว่าอย่างไร?

เราไม่พบตัวเลขจำนวนเหตุ ransomware ในไทยจากแหล่งทางการที่ตรวจได้ จึงไม่ใส่ตัวเลขดังกล่าว สิ่งที่สำนักงานคณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติ (สกมช.) เผยแพร่มีดังนี้

• รายงานประจำปี สกมช. 2568 ระบุว่ามัลแวร์มีแนวโน้มซับซ้อนและตรวจจับยากขึ้น โดยเฉพาะ Ransomware และ Trojan ที่แฝงมากับอีเมลหรือไฟล์ออนไลน์ และผู้ไม่หวังดีมุ่งโจมตีช่องโหว่ของซอฟต์แวร์ที่ไม่ได้อัปเดต โดยเฉพาะระบบเวอร์ชันเก่าที่ขาดการจัดการ patch
• รายงานเดียวกัน (หน้า 57) ระบุว่า username และ password ที่รั่วไหลภายใต้โดเมน .th มีรวม 204,066,962 บัญชี และ ThaiCERT แจ้งเตือนหน่วยงานที่ได้รับผลกระทบ 5,875 หน่วยงาน (ข้อมูลตุลาคม 2567 ถึง 30 กันยายน 2568) โดยระบุการติดตั้ง ransomware เป็นหนึ่งในผลกระทบที่อาจตามมาจากบัญชีที่รั่วไหล ตัวเลขนี้คือบัญชีที่รั่ว ไม่ใช่จำนวนเหตุ ransomware
• รายงานผลการประเมินความเสี่ยงจากภัยคุกคามทางไซเบอร์ของประเทศไทย ประจำปี พ.ศ. 2568 จัดให้การที่ผู้ประสงค์ร้ายจากภายนอกใช้ช่องโหว่ซอฟต์แวร์ฝังมัลแวร์เฉพาะทาง เช่น Ransomware ชนิดพิเศษที่หลบเลี่ยงการตรวจจับ ลงในระบบสารสนเทศขององค์กรในหมวดข้อมูลทั่วไปของรัฐบาล เป็นหนึ่งในความเสี่ยงสูงสุด 5 อันดับแรกของประเทศ ส่วนความเสี่ยงที่ข้อมูลสำคัญถูกทำลาย เช่น ถูก ransomware โจมตี ถูกกล่าวถึงในรายงานความเสี่ยงของทุกภาคส่วน โดยส่วนใหญ่อยู่ในระดับต่ำและปานกลาง

สิ่งที่อ่านได้จากรายงานเหล่านี้คือ ช่องทางเข้าที่ สกมช. เน้น คือซอฟต์แวร์ที่ไม่ได้ patch อีเมล และบัญชีที่รั่ว ตรงกับช่องทางที่ CISA ระบุ งานป้องกันจึงควรเริ่มจากสามเรื่องนี้

ป้องกัน ransomware ต้องเริ่มจากอะไร?

เริ่มจากปิดช่องทางเข้าที่พบบ่อย แล้วจำกัดไม่ให้ผู้โจมตีที่เข้ามาได้แล้วลุกลามง่าย แนวทางในส่วนนี้มาจาก #StopRansomware Guide และ NIST IR 8374 Rev. 1 (Ransomware Risk Management: A Cybersecurity Framework 2.0 Community Profile, มิถุนายน 2026)

ระบบที่เปิดสู่อินเทอร์เน็ต

• ไม่เปิด RDP และบริการลักษณะเดียวกันสู่อินเทอร์เน็ต (CISA) ถ้าต้องเข้าจากภายนอก ให้เข้าผ่าน VPN ที่ปลอดภัยเท่านั้น (NIST)
• patch ซอฟต์แวร์และ firmware ของ VPN อุปกรณ์เครือข่าย และอุปกรณ์ที่ใช้ทำงานจากระยะไกล ให้เป็นเวอร์ชันล่าสุด และเปิด MFA กับการเชื่อมต่อ VPN ทุกช่องทาง
• สแกนช่องโหว่เป็นประจำ โดยเฉพาะอุปกรณ์ที่เปิดสู่อินเทอร์เน็ต และ patch เซิร์ฟเวอร์ที่เปิดสู่อินเทอร์เน็ตให้ทันเวลา โดยเฉพาะช่องโหว่ที่รู้แล้วว่าถูกใช้โจมตีจริง
• ระบบเก่าที่ patch ไม่ได้แล้ว ต้องใช้มาตรการชดเชย เช่น แยกโซนเครือข่ายและเฝ้าระวังเชิงรุก ดูรายละเอียดใน ระบบเก่าหมด support แต่ยังต้องใช้ต่อ

บัญชีและสิทธิ์

• ใช้ MFA แบบต้านทาน phishing (phishing-resistant MFA) ตามที่ CISA แนะนำ และถ้าพบระบบที่ใช้ MFA ไม่ได้ ให้รายงานผู้บริหารระดับสูง
• รหัสผ่านไม่ซ้ำกันและยาวอย่างน้อย 15 ตัวอักษร ตามนโยบายที่ CISA แนะนำ และเปลี่ยนชื่อผู้ใช้และรหัสผ่านค่าเริ่มต้นของบัญชีผู้ดูแล
• แยกบัญชีผู้ดูแลระบบออกจากบัญชีใช้งานปกติ ให้ผู้ใช้ทำงานประจำวันด้วยบัญชีสิทธิ์มาตรฐานที่มี MFA และให้สิทธิ์เท่าที่จำเป็น (least privilege) ตามแนวทางของ NIST
• บุคคลที่สามและผู้ให้บริการ ให้สิทธิ์เท่าที่จำเป็นและแบ่งแยกหน้าที่ ถ้าผู้ให้บริการเป็นผู้ดูแล backup ให้ตรวจว่าทำตามแนวปฏิบัติเดียวกัน และเขียนข้อกำหนดด้านความปลอดภัยไว้ในสัญญา หัวข้อที่ควรมีในสัญญาดูได้ใน เช็กลิสต์สัญญา MA และ SLA

เครือข่ายและอีเมล

• แบ่งโซนเครือข่ายภายใน (segmentation) เพื่อไม่ให้มัลแวร์แพร่ไปทั้งองค์กร และอนุญาตให้รันเฉพาะแอปพลิเคชันที่อนุมัติแล้ว ตามแนวทางพื้นฐานของ NIST
• ตั้ง DMARC เพื่อลดโอกาสที่อีเมลปลอมจากโดเมนของเราเองจะหลุดไปถึงผู้รับ CISA ระบุว่า DMARC ป้องกันการปลอมโดเมนของเรา แต่ไม่ป้องกันอีเมลขาเข้าที่ปลอมมาจากโดเมนที่ไม่ได้ตั้ง DMARC
• ระวังไฟล์บีบอัดที่ตั้งรหัสผ่าน CISA เตือนว่ามัลแวร์มักมาในไฟล์บีบอัดที่ตั้งรหัสผ่าน ซึ่งเลี่ยงการสแกนของ antivirus และตัวกรองอีเมลได้

Backup แบบไหนที่ ransomware เข้าไม่ถึง?

คือ backup ที่อย่างน้อยหนึ่งชุดอยู่นอกการเข้าถึงของผู้โจมตี และเคยลองกู้คืนจริงแล้ว หัวข้อนี้สรุปเฉพาะหลักการ ส่วนการเลือก immutable หรือ offline การแยกสิทธิ์ลบ backup และการซ้อมกู้คืนอยู่ใน Backup กัน Ransomware: Immutable หรือ Offline? CISA อธิบายว่า backup ต้องเก็บแบบ offline เพราะ ransomware หลายตัวพยายามค้นหาแล้วลบหรือเข้ารหัส backup ที่เข้าถึงได้ เพื่อให้กู้คืนไม่ได้นอกจากจ่ายค่าไถ่ NIST IR 8374r1 (PR.DS-11) เขียนในทำนองเดียวกันว่า backup ควรมีสำเนาหนึ่งชุดที่เก็บแบบ offline หรือเก็บในลักษณะที่ผู้โจมตีเข้าถึงไม่ได้หรือ ransomware ทำลายไม่ได้

• แยกออกจากระบบที่ใช้งาน: backup ที่อยู่บน share เดียวกัน ใช้บัญชี domain เดียวกัน หรือลบได้จาก console ที่ผู้ดูแลระบบล็อกอินตามปกติ ถือว่ายังเข้าถึงได้ ในมุมมองของเรา คำถามที่ต้องตอบคือ "ถ้าบัญชีผู้ดูแลระบบถูกยึด ผู้โจมตีลบ backup ชุดนี้ได้ไหม"
• Immutable storage ใช้ด้วยความระมัดระวัง: CISA ระบุว่าผู้ให้บริการคลาวด์บางรายมี immutable storage ที่ปกป้องข้อมูลได้โดยไม่ต้องแยกสภาพแวดล้อม แต่ให้ใช้อย่างระวัง เพราะไม่ผ่านเกณฑ์ compliance ของข้อกำหนดบางฉบับ และการตั้งค่าผิดอาจทำให้เกิดค่าใช้จ่ายสูง
• ทดสอบกู้คืนจริง: CISA แนะนำให้เก็บ backup แบบ offline และเข้ารหัส และทดสอบความพร้อมใช้และความครบถ้วนของ backup ในสถานการณ์กู้คืนเป็นประจำ
• ตรวจความครบถ้วนก่อนกู้คืน: NIST IR 8374r1 (RC.RP-03) ระบุว่าต้องตรวจความครบถ้วนของ backup ก่อนนำมาใช้กู้คืนจากเหตุ ransomware
• เก็บสิ่งที่ใช้สร้างระบบใหม่: CISA แนะนำให้เก็บ golden image ของระบบสำคัญ เก็บ template ของ infrastructure as code ไว้ offline และเก็บ source code หรือไฟล์ executable ไว้กับ backup แบบ offline

หลัก 3-2-1 (สำเนาสามชุด สื่อสองประเภท หนึ่งชุดอยู่นอกสถานที่) และการทดสอบกู้คืนระบบเก่าบนเครื่องอื่น อธิบายไว้แล้วใน บทความเรื่องระบบเก่า ส่วนใครรับผิดชอบ backup และการทดสอบกู้คืนเมื่อจ้างผู้อื่นดูแล ควรระบุไว้ในสัญญา MA

ต้องเตรียมแผนรับมือและซ้อมอย่างไร?

CISA แนะนำให้จัดทำ ดูแล และซ้อมแผนรับมือเหตุไซเบอร์ (incident response plan, IRP) ขั้นพื้นฐานเป็นประจำ พร้อมแผนการสื่อสารที่มีขั้นตอนรับมือและการแจ้งเหตุสำหรับ ransomware และการขโมยหรือรั่วไหลของข้อมูล ให้ผู้บริหารสูงสุดหรือเทียบเท่าทบทวนและอนุมัติเป็นลายลักษณ์อักษร และให้มีฉบับกระดาษกับฉบับ offline เพราะระหว่างเกิดเหตุ ระบบเอกสารขององค์กรอาจใช้ไม่ได้ NIST IR 8374r1 เสริมว่าแผนควรกำหนดบทบาทและวิธีตัดสินใจ มีช่องทางสื่อสารนอกระบบ (out-of-band) และมีรายชื่อผู้ติดต่อ เช่น หน่วยงานบังคับใช้กฎหมาย ที่ปรึกษากฎหมาย และผู้เชี่ยวชาญรับมือเหตุ

สิ่งที่ควรอยู่ในแผนตั้งแต่ก่อนเกิดเหตุ:

• ทะเบียนทรัพย์สิน: CISA ให้ทำทะเบียนทรัพย์สิน IT ทั้งเชิงตรรกะ (ข้อมูล ซอฟต์แวร์) และเชิงกายภาพ (ฮาร์ดแวร์) รู้ว่าระบบใดสำคัญที่สุดและพึ่งพากันอย่างไร และเก็บเอกสารนี้อย่างปลอดภัย พร้อมสำเนา offline และฉบับกระดาษ
• ลำดับการกู้คืน: รายการระบบสำคัญที่ตกลงไว้ล่วงหน้า เพราะ CISA ใช้รายการนี้จัดลำดับว่าจะกู้ระบบใดก่อน
• ข้อมูลสำหรับแจ้งเหตุ: แบบฟอร์มตัวอย่างการแจ้งเหตุของ สคส. ถามถึงวันเวลาเกิดเหตุ จำนวนและลักษณะข้อมูล มาตรการแก้ไขเบื้องต้น การแจ้งความ ผลกระทบที่คาดว่าเจ้าของข้อมูลจะได้รับ มาตรการเชิงองค์กร เทคนิค และกายภาพ บันทึกกิจกรรมการประมวลผล (RoPA) และการประเมินความเสี่ยง ข้อมูลเหล่านี้หลายข้อเตรียมไว้ก่อนได้
• ใครตัดสินใจเรื่องใด: ใครสั่งตัดเครือข่าย ใครประเมินหน้าที่แจ้งเหตุ ใครพูดกับสื่อและลูกค้า และใครเป็นผู้ประกาศว่าเหตุจบแล้ว

การซ้อมแผนบนโต๊ะ (tabletop exercise) คือการนั่งไล่สถานการณ์สมมติกับผู้เกี่ยวข้องโดยไม่ต้องแตะระบบจริง CISA มีชุดสถานการณ์ซ้อมแบบนี้ให้ใช้ (CISA Tabletop Exercise Packages) ในมุมมองของเรา สถานการณ์ ransomware ที่ควรซ้อมอย่างน้อยหนึ่งครั้งคือ "ไฟล์ share ถูกเข้ารหัสเช้าวันจันทร์ และ backup server ก็ถูกเข้ารหัสด้วย" เพราะจะเผยว่าทีมรู้หรือไม่ว่าต้องติดต่อใคร และ backup ชุดไหนยังใช้ได้

สำหรับหน่วยงานของรัฐ หน่วยงานควบคุมหรือกำกับดูแล และหน่วยงาน CII มาตรา 44 ของ พ.ร.บ.การรักษาความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562 กำหนดให้ประมวลแนวทางปฏิบัติของหน่วยงานต้องมีอย่างน้อยสองเรื่อง คือแผนตรวจสอบและประเมินความเสี่ยงที่ทำปีละครั้งเป็นอย่างน้อย และแผนการรับมือภัยคุกคามทางไซเบอร์ ส่วนมาตรา 56 กำหนดให้หน่วยงาน CII ต้องมีกลไกเฝ้าระวังภัยคุกคามทางไซเบอร์ และเข้าร่วมการทดสอบความพร้อมที่ สกมช. จัดขึ้น

ตรวจจับ ransomware ได้จากสัญญาณอะไร และ Wazuh ช่วยตรงไหน?

สัญญาณที่มีค่าที่สุดคือสัญญาณก่อนการเข้ารหัส CISA แนะนำให้รวม log จากอุปกรณ์เครือข่าย เครื่องปลายทาง และบริการคลาวด์ไว้ที่ระบบ SIEM เพื่อให้ดู log เครือข่ายกับ log ของเครื่องร่วมกันได้ เก็บ log ของระบบสำคัญอย่างน้อยหนึ่งปีถ้าทำได้ และปรับเครื่องมือบนเครื่องปลายทางให้ตรวจจับไฟล์โปรแกรมผิดปกติ การเคลื่อนไปยังเครื่องอื่น และเทคนิคการฝังตัว

สัญญาณที่ CISA ให้ตามหาเมื่อสงสัยว่ามีผู้บุกรุก ได้แก่

• บัญชีใหม่ใน Active Directory หรือบัญชีที่ถูกยกระดับสิทธิ์ และการล็อกอิน VPN ที่ผิดปกติ
• การใช้ vssadmin.exe, wbadmin.exe, bcdedit.exe, fsutil.exe หรือ wmic.exe ในลักษณะที่กระทบ backup, shadow copy หรือการตั้งค่าการบูต ซึ่ง CISA ระบุว่าเป็นเทคนิคที่ ransomware ใช้บ่อยเพื่อขัดขวางการกู้คืน ตัวอย่างใน ATT&CK T1490 เช่น vssadmin.exe delete shadows /all /quiet
• ซอฟต์แวร์ดูแลเครื่องระยะไกลที่ไม่ได้ติดตั้งโดยทีม IT การใช้ PowerShell หรือ PsTools ที่ผิดปกติ และการดึงรหัสผ่านจาก LSASS
• traffic ระหว่างเครื่องผู้ใช้ด้วยกันที่ไม่ควรมี และข้อมูลขาออกปริมาณผิดปกติ เช่น ผ่าน Rclone, Rsync, บริการเก็บไฟล์บนเว็บ หรือ FTP/SFTP
• service หรือ scheduled task ใหม่ที่ไม่มีใครสร้าง

Wazuh (SIEM/XDR แบบ open source) ช่วยได้ในส่วนต่อไปนี้ ตามที่เอกสารของ Wazuh ระบุ

• File integrity monitoring (FIM): ตามเอกสาร FIM Wazuh แจ้งเตือนเมื่อผู้ใช้หรือ process สร้าง แก้ หรือลบไฟล์ในโฟลเดอร์ที่ตั้งเฝ้าไว้ ค่าเริ่มต้นสแกนทุก 12 ชั่วโมง ถ้าต้องการเห็นทันทีต้องเปิด realtime ซึ่งใช้ได้กับ Windows และ Linux และเปิด who-data เพื่อรู้ว่าผู้ใช้และโปรแกรมใดเป็นผู้แก้ไฟล์ การเปลี่ยนแปลงไฟล์จำนวนมากผิดปกติในโฟลเดอร์ที่เฝ้าไว้จึงเป็นสัญญาณให้เข้าไปดู
• Vulnerability detection: ตามเอกสาร vulnerability detection agent ส่งรายการซอฟต์แวร์ที่ติดตั้งให้ server เทียบกับข้อมูลช่องโหว่ ช่วยหาเครื่องที่ยังไม่ได้ patch ซึ่งเป็นช่องทางเข้าที่ สกมช. และ CISA เน้น
• Sysmon และ custom rule: ในบทความบน Wazuh blog (ธันวาคม 2025) ผู้ผลิตสาธิตการใช้ log ของ Sysmon, FIM แบบ real-time, YARA ผ่าน active response และ custom rule ซึ่งมี rule สำหรับการลบ Volume Shadow Copies ที่ map กับ T1490 ส่วนบทความปี 2024 สาธิตการใช้ FIM ร่วมกับ VirusTotal, active response และการทำ snapshot ด้วย VSS เพื่อกู้ไฟล์คืน ทั้งสองเป็นตัวอย่างการตั้งค่าของผู้ผลิต rule และสคริปต์เป็น custom ไม่ได้มากับระบบเป็นค่าเริ่มต้น และบทความปี 2024 ระบุเองว่าวิธีนี้ไม่ได้ตรวจจับ ransomware ได้ทุกชนิด

วิธีตั้งค่าแต่ละส่วนในระดับ config ทั้ง localfile ของ Sysmon, custom rule สำหรับการลบ shadow copy (ruleset มาตรฐานของ Wazuh ไม่มี rule นี้มาให้), โหมดของ FIM และการส่ง alert ให้ถึงคน อยู่ใน ตรวจจับ Ransomware ด้วย Wazuh: ตั้งค่าอะไรบ้าง

ข้อจำกัดที่ต้องรู้: Wazuh ไม่ได้ทดแทน EDR และไม่ได้ทดแทน backup ตามที่อธิบายไว้ใน Wazuh กับ EDR ซึ่งมีวิธีตั้ง Sysmon, YARA และ VirusTotal ด้วย และเราไม่พบความสามารถแยกเครื่องออกจากเครือข่าย (host isolation) ในตัวจากเอกสารของ Wazuh นอกจากนี้ SIEM ต้องปรับจูน rule ให้เข้ากับระบบจริงและต้องมีคนดู alert ตามเวลาที่ตกลงกัน alert ที่เกิดตอนตีสองแล้วไม่มีใครเห็นจนเช้า ช่วยได้น้อย วิธีวางเครื่อง เก็บ log และลด alert noise อยู่ใน วางแผนติดตั้ง Wazuh

ถ้าโดน ransomware แล้ว ชั่วโมงแรกทำอะไร?

ทำตามแผนที่อนุมัติไว้ ลำดับด้านล่างสรุปจาก Response Checklist ใน #StopRansomware Guide และแนวทางเก็บหลักฐานสำหรับหน่วยงาน CII ในประกาศคณะกรรมการการรักษาความมั่นคงปลอดภัยไซเบอร์แห่งชาติ (กมช.) เรื่อง ลักษณะภัยคุกคามทางไซเบอร์ฯ พ.ศ. 2564 ไม่ได้แทนแผนขององค์กร

1. เปิดแผนรับมือและเรียกทีมผ่านช่องทางนอกระบบ เช่น โทรศัพท์ เพราะ CISA เตือนว่าการสื่อสารผ่านระบบที่ถูกยึดอาจทำให้ผู้โจมตีรู้ตัว
2. ระบุเครื่องที่ได้รับผลกระทบและแยกออกจากเครือข่ายทันที ถ้ากระทบหลายเครื่องหรือหลาย subnet ให้ตัดเครือข่ายที่ระดับ switch ถ้ากระทบไม่กี่เครื่อง ให้ถอดสาย LAN หรือปิด Wi-Fi ของเครื่องนั้น และแยกทุกเครื่องพร้อมกันตามแผน
3. อย่าปิดเครื่องถ้ายังแยกด้วยวิธีอื่นได้ CISA ให้ปิดเครื่องเฉพาะเมื่อตัดออกจากเครือข่ายไม่ได้ เพราะการปิดเครื่องทำให้หลักฐานในหน่วยความจำหายไป
4. เก็บหลักฐาน อย่าล้างเครื่อง ทำ snapshot ของ volume บนคลาวด์ ทำ image และเก็บ memory จากเครื่องที่ได้รับผลกระทบบางเครื่องไว้เป็นตัวอย่าง เก็บ log ที่หายเร็ว เช่น Windows Security log และ log ใน buffer ของ firewall สำหรับหน่วยงาน CII แนวทางท้ายประกาศ กมช. พ.ศ. 2564 กำหนดให้เก็บรักษาข้อมูลเหตุการณ์ไว้อย่างปลอดภัยเพื่อใช้ในกระบวนการทางนิติวิทยาศาสตร์และเป็นพยานหลักฐานในการดำเนินคดี องค์กรอื่นก็ควรทำแนวเดียวกัน
5. ตรวจว่า backup ชุดที่ offline ยังไม่ถูกแตะ และอย่าเชื่อมต่อเข้ากับเครือข่ายที่ยังไม่สะอาด
6. แจ้งผู้บริหาร ฝ่ายกฎหมาย และ DPO ให้เริ่มประเมินหน้าที่แจ้งเหตุทันที เพราะกรอบเวลาตาม PDPA นับแต่ทราบเหตุ และของ CII นับจากตรวจพบหรือเกิดเหตุ (ดูหัวข้อถัดไป)
7. ยังไม่ restore จนกว่าจะหาช่องทางที่ผู้โจมตีเข้ามา มัลแวร์ที่ฝังเข้ามาก่อน และจุดที่ฝังตัวไว้ได้ เพราะ CISA ระบุว่าเหตุ ransomware อาจเป็นหลักฐานของการบุกรุกก่อนหน้าที่ยังไม่ถูกแก้ และให้หามัลแวร์ที่ฝังเข้ามาก่อนก่อนสร้างระบบใหม่จาก backup

โดน ransomware แล้วต้องแจ้งใครบ้างตามกฎหมายไทย?

ขึ้นกับว่าเหตุกระทบข้อมูลส่วนบุคคลหรือไม่ และองค์กรเป็นหน่วยงานประเภทใด ส่วนนี้สรุปจากตัวบทและประกาศที่อ้างถึง ไม่ใช่คำแนะนำทางกฎหมาย หน้าที่ที่ใช้กับองค์กรจริงให้ฝ่ายกฎหมายและ DPO เป็นผู้ประเมิน

PDPA: เมื่อเหตุกระทบข้อมูลส่วนบุคคล

มาตรา 37(4) ของ พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 ให้ผู้ควบคุมข้อมูลส่วนบุคคลแจ้งเหตุการละเมิดแก่สำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล (สคส.) โดยไม่ชักช้าภายใน 72 ชั่วโมงนับแต่ทราบเหตุเท่าที่จะทำได้ เว้นแต่การละเมิดนั้นไม่มีความเสี่ยงที่จะมีผลกระทบต่อสิทธิและเสรีภาพของบุคคล ถ้ามีความเสี่ยงสูง ต้องแจ้งเจ้าของข้อมูลพร้อมแนวทางการเยียวยาโดยไม่ชักช้าด้วย ส่วนมาตรา 40(2) ให้ผู้ประมวลผลแจ้งเหตุแก่ผู้ควบคุม

รายละเอียดอยู่ในประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่อง หลักเกณฑ์และวิธีการในการแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล พ.ศ. 2565 (ราชกิจจานุเบกษา เล่ม 139 ตอนพิเศษ 292 ง วันที่ 15 ธันวาคม 2565) ประเด็นที่เกี่ยวกับ ransomware โดยตรงมีดังนี้

• ข้อ 3 นิยามการละเมิดข้อมูลส่วนบุคคลให้รวมเหตุที่เกิดจากการกระทำความผิดเกี่ยวกับคอมพิวเตอร์และภัยคุกคามทางไซเบอร์
• ข้อ 4 แบ่งการละเมิดเป็นสามประเภท หนึ่งในนั้นคือการละเมิดความพร้อมใช้งาน (Availability Breach) ซึ่งทำให้เข้าถึงข้อมูลส่วนบุคคลไม่ได้ หรือข้อมูลถูกทำลายจนไม่อยู่ในสภาพพร้อมใช้งาน การที่ ransomware เข้ารหัสข้อมูลส่วนบุคคลจึงอาจเข้าข่ายแม้ไม่มีข้อมูลถูกขโมยออกไป และถ้ามีการขโมยออกไปด้วย ก็อาจเข้าข่ายการละเมิดความลับ (Confidentiality Breach) ด้วย
• ข้อ 5 เมื่อทราบว่ามีหรือน่าจะมีเหตุ ให้ประเมินความน่าเชื่อถือของข้อมูลและตรวจข้อเท็จจริงเบื้องต้นโดยไม่ชักช้า ระงับหรือแก้ไขทันทีถ้าความเสี่ยงสูง และแจ้ง สคส. ภายใน 72 ชั่วโมงถ้ามีเหตุอันควรเชื่อว่ามีการละเมิดจริง
• ข้อ 6 การแจ้งต้องระบุเท่าที่ทำได้ ได้แก่ ลักษณะของการละเมิดและจำนวนเจ้าของข้อมูลหรือจำนวนรายการ ช่องทางติดต่อ DPO หรือผู้ประสานงาน ผลกระทบที่อาจเกิดขึ้น และมาตรการที่ใช้หรือจะใช้
• ข้อ 7 ถ้ามีเหตุจำเป็นทำให้แจ้งช้ากว่า 72 ชั่วโมง ขอให้ สคส. พิจารณายกเว้นความผิดได้โดยชี้แจงเหตุผล แต่ต้องแจ้งไม่เกิน 15 วันนับแต่ทราบเหตุ และการแจ้ง สคส. ไม่ได้ยกเว้นหน้าที่ตามกฎหมายเฉพาะหรือกฎหมายอื่น
• ข้อ 8 สัญญากับผู้ประมวลผลต้องกำหนดให้ผู้ประมวลผลแจ้งเหตุแก่ผู้ควบคุมโดยไม่ชักช้าภายใน 72 ชั่วโมงนับแต่ผู้ประมวลผลทราบเหตุเท่าที่ทำได้ ซึ่งควรอยู่ในสัญญากับผู้ให้บริการ MA, hosting และคลาวด์
• ข้อ 9 ผู้ควบคุมอาจยกข้อยกเว้นการแจ้งได้ถ้าพิสูจน์ได้ว่าไม่มีความเสี่ยง เช่น ข้อมูลไม่อยู่ในสภาพที่ใช้งานได้เพราะมีมาตรการทางเทคโนโลยีที่เพียงพอ และต้องส่งหลักฐานให้ สคส. พิจารณา

ตามคู่มือการให้บริการการแจ้งเหตุการละเมิดข้อมูลส่วนบุคคลของ สคส. หน่วยงานแจ้งเหตุผ่านระบบสารบัญอิเล็กทรอนิกส์ ส่งเอกสารทางอีเมลได้ที่ saraban@pdpc.or.th (รับวันจันทร์ถึงศุกร์ 08.30–16.30 น. เว้นวันหยุดราชการ) และไม่มีค่าธรรมเนียม

พ.ร.บ.ไซเบอร์: หน่วยงาน CII และหน่วยงานของรัฐ

ตาม พ.ร.บ.การรักษาความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562

• มาตรา 57 เมื่อเกิดภัยคุกคามทางไซเบอร์อย่างมีนัยสำคัญต่อระบบของหน่วยงาน CII ให้รายงานต่อ สกมช. และหน่วยงานควบคุมหรือกำกับดูแล และมาตรา 73 กำหนดโทษปรับไม่เกินสองแสนบาทสำหรับหน่วยงาน CII ที่ไม่รายงานโดยไม่มีเหตุอันสมควร
• มาตรา 58 เมื่อเกิดหรือคาดว่าจะเกิดภัยคุกคามทางไซเบอร์ต่อระบบของหน่วยงานของรัฐหรือหน่วยงาน CII ให้ตรวจสอบ ป้องกัน รับมือ และแจ้ง สกมช. และหน่วยงานควบคุมหรือกำกับดูแลโดยเร็ว
• ประกาศคณะกรรมการกำกับดูแลด้านความมั่นคงปลอดภัยไซเบอร์ (กกม.) เรื่อง หลักเกณฑ์และวิธีการรายงานภัยคุกคามทางไซเบอร์ พ.ศ. 2566 (ราชกิจจานุเบกษา เล่ม 140 ตอนพิเศษ 107 ง) ข้อ 4 ให้หน่วยงานของรัฐหรือ CII ที่ตรวจพบภัยคุกคามแจ้ง สกมช. โดยเร็วตามแบบ ก1 ข้อ 5 ให้ CII ส่งรายงานตามแบบ ก2 ถึง สกมช. ภายใน 24 ชั่วโมงหลังตรวจพบหรือเกิดเหตุที่มีนัยสำคัญ อัปเดตระหว่างรับมือ และส่งรายงานปิดเหตุ โดยใช้กับหน่วยงานของรัฐโดยอนุโลมเมื่อเหตุมีนัยสำคัญต่อระบบสารสนเทศของรัฐ เอกสารแนบระบุว่าถ้ากรอกไม่ครบใน 24 ชั่วโมง ให้ส่งด้วยข้อมูลเท่าที่มีแล้วอัปเดตเป็นระยะ
• ransomware อยู่หมวดไหน: ประกาศ กมช. เรื่องลักษณะภัยคุกคามทางไซเบอร์ฯ พ.ศ. 2564 จัดการบุกรุกด้วยมัลแวร์ไว้ในหมวด 4 และคู่มือประกอบแนวทางการแจ้งหรือรายงานเหตุภัยคุกคามทางไซเบอร์ พ.ศ. 2569 ของ สกมช. ยก ransomware เป็นตัวอย่างของหมวดนี้ และมีสถานการณ์ตัวอย่างที่หน่วยงานส่งรายงานด้วยข้อมูลเท่าที่ทราบเมื่อใกล้ครบ 24 ชั่วโมง แม้ยังหาสาเหตุไม่ได้

องค์กรที่ไม่แน่ใจว่าเป็น CII หรือไม่ ให้ตรวจกับประกาศ กมช. เรื่อง หลักเกณฑ์ ลักษณะหน่วยงานที่มีภารกิจหรือให้บริการเป็นหน่วยงานโครงสร้างพื้นฐานสำคัญทางสารสนเทศ และการมอบหมายการควบคุมและกำกับดูแล พ.ศ. 2568 (ราชกิจจานุเบกษา 16 กันยายน 2568) มาตรา 49 กำหนดด้านที่ประกาศเป็น CII ได้ เช่น บริการภาครัฐที่สำคัญ การเงินการธนาคาร เทคโนโลยีสารสนเทศและโทรคมนาคม การขนส่งและโลจิสติกส์ พลังงานและสาธารณูปโภค และสาธารณสุข ภาคการเงินและภาคอื่นอาจมีหน่วยงานกำกับดูแลที่กำหนดเวลาแจ้งของตัวเองเพิ่มด้วย

องค์กรทั่วไป ThaiCERT และตำรวจ

• เอกชนที่ไม่ใช่ CII ไม่มีหน้าที่ตามมาตรา 57 แต่มาตรา 58 วรรคสองเปิดให้หน่วยงานหรือบุคคลที่พบปัญหาในการรับมือภัยคุกคามขอความช่วยเหลือจาก สกมช. ได้ ช่องทางแจ้งเหตุภัยคุกคามไซเบอร์ตามหน้าติดต่อของ ThaiCERT คืออีเมล thaicert@ncsa.or.th (มี PGP key ให้ดาวน์โหลด) และโทร 02 114 3531
• แจ้งความ: แจ้งความออนไลน์ได้ที่ thaipoliceonline.go.th ของศูนย์ปราบปรามอาชญากรรมทางเทคโนโลยีสารสนเทศ สำนักงานตำรวจแห่งชาติ แบบฟอร์มตัวอย่างของ สคส. ก็ถามว่ามีการแจ้งความหรือไม่ และให้แนบหลักฐานถ้ามี

ควรจ่ายค่าไถ่หรือไม่?

เป็นการตัดสินใจของผู้บริหารร่วมกับฝ่ายกฎหมายและหน่วยงานบังคับใช้กฎหมาย ไม่ใช่ของทีม IT ฝ่ายเดียว NIST IR 8374r1 อธิบายว่า ransomware ทำให้ผู้บริหารต้องเลือกระหว่างจ่ายค่าไถ่แล้วหวังว่าผู้โจมตีจะรักษาคำพูด คือคืนการเข้าถึงและไม่เปิดเผยข้อมูล หรือไม่จ่ายแล้วพยายามกู้ระบบเอง

• FBI ระบุว่าไม่สนับสนุนการจ่ายค่าไถ่ เพราะการจ่ายไม่ได้รับประกันว่าจะได้ข้อมูลคืน และกระตุ้นให้เกิดการโจมตีมากขึ้น
• OFAC กระทรวงการคลังสหรัฐฯ (ประกาศแนะนำ 21 กันยายน 2021) ระบุว่ารัฐบาลสหรัฐฯ ไม่สนับสนุนอย่างยิ่งให้จ่ายค่าไถ่ และการช่วยให้เกิดการจ่ายอาจเสี่ยงละเมิดมาตรการคว่ำบาตร ซึ่งเป็นกฎของสหรัฐฯ แต่แสดงให้เห็นว่าการจ่ายอาจมีความเสี่ยงทางกฎหมายที่ต้องตรวจ
• เราไม่พบแนวทางทางการของไทยเรื่องการจ่ายค่าไถ่ในแหล่งที่ตรวจ จึงไม่สรุปว่าการจ่ายถูกหรือผิดกฎหมายไทย

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

กู้คืนระบบหลังโดน ransomware อย่างไรไม่ให้โดนซ้ำ?

กำจัดผู้โจมตีออกให้หมดก่อน แล้วจึงกู้ระบบตามลำดับความสำคัญ ขั้นตอนต่อไปนี้สรุปจากส่วน Containment, Eradication และ Recovery ของ #StopRansomware Guide

• หาขอบเขตของการบุกรุก: ระบุระบบและบัญชีที่เกี่ยวข้องตั้งแต่ต้น รวมถึงบัญชีอีเมล CISA ระบุว่าการบุกรุกมักมาพร้อมการขโมยรหัสผ่านจำนวนมาก บางกรณีจึงต้องปิด VPN เครื่องสำหรับเข้าถึงระยะไกล ระบบ SSO และบริการที่เปิดสู่ภายนอกชั่วคราว และต้องหาจุดฝังตัวทั้งจากภายนอกเข้ามาและจากภายในออกไป
• สร้างระบบใหม่จากของที่สะอาด: สร้างระบบตามลำดับบริการสำคัญจาก image มาตรฐานที่เตรียมไว้ แล้วกู้ข้อมูลจาก backup แบบ offline ระวังไม่ให้ระบบที่สะอาดติดซ้ำ เช่น นำเฉพาะระบบที่สะอาดแล้วเข้า VLAN สำหรับกู้คืนที่สร้างใหม่
• เปลี่ยนรหัสผ่านและปิดช่องโหว่: เมื่อทำความสะอาดและสร้างระบบใหม่ครบแล้ว ให้รีเซ็ตรหัสผ่านของทุกระบบที่ได้รับผลกระทบ แก้ช่องโหว่ที่พบ และปิดจุดที่ระบบตรวจจับยังมองไม่เห็น (visibility gap)
• ประกาศจบเหตุตามเกณฑ์: ผู้รับผิดชอบด้าน IT หรือความปลอดภัยที่กำหนดไว้เป็นผู้ประกาศว่าเหตุจบ ตามเกณฑ์ที่ตั้งไว้ล่วงหน้า สำหรับ CII ต้องส่งรายงานปิดเหตุด้วยตามประกาศ กกม. 2566
• บันทึกบทเรียน: CISA ให้บันทึกบทเรียนจากเหตุและการรับมือ เพื่อปรับนโยบาย แผน และการซ้อมครั้งต่อไป ประกาศแจ้งเหตุละเมิดฯ พ.ศ. 2565 ข้อ 5 ก็ให้ดำเนินมาตรการป้องกันเหตุซ้ำและทบทวนมาตรการรักษาความมั่นคงปลอดภัย

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

Checklist: เตรียมองค์กรรับมือ Ransomware

• ทำทะเบียนข้อมูล ซอฟต์แวร์ และฮาร์ดแวร์ ระบุระบบสำคัญและลำดับการกู้คืน และเก็บสำเนา offline กับฉบับกระดาษ
• ตรวจว่าไม่มี RDP หรือหน้าจัดการระบบเปิดสู่อินเทอร์เน็ต และให้เข้าจากภายนอกผ่าน VPN ที่มี MFA เท่านั้น
• สแกนช่องโหว่อุปกรณ์ที่เปิดสู่อินเทอร์เน็ตเป็นประจำ และ patch VPN และ firewall ก่อน โดยเฉพาะช่องโหว่ที่ถูกใช้โจมตีแล้ว
• เปิด MFA ให้ VPN อีเมล และบัญชีผู้ดูแล และรายงานผู้บริหารเมื่อพบระบบที่ใช้ MFA ไม่ได้
• แยกบัญชีผู้ดูแลออกจากบัญชีใช้งานปกติ เปลี่ยนรหัสผ่านค่าเริ่มต้น และตัดสิทธิ์ที่ไม่จำเป็น รวมถึงสิทธิ์ของผู้ให้บริการภายนอก
• แบ่งโซนเครือข่ายให้เครื่องผู้ใช้เชื่อมต่อถึงเซิร์ฟเวอร์และ backup ได้เฉพาะเส้นทางที่จำเป็น
• ตั้ง DMARC ให้โดเมนขององค์กร
• เก็บ backup ข้อมูลสำคัญอย่างน้อยหนึ่งชุดแบบ offline หรือแยกจากบัญชีและเครือข่ายที่ใช้ทำงาน และทดสอบกู้คืนตามรอบที่กำหนด
• เก็บ golden image, template ของ infrastructure as code และไฟล์ติดตั้งระบบไว้กับ backup แบบ offline
• รวม log ของเครื่องปลายทาง อุปกรณ์เครือข่าย และคลาวด์ไว้ที่ SIEM และกำหนดว่าใครดู alert ในและนอกเวลาทำการ
• ตั้ง alert สำหรับการใช้ vssadmin, wbadmin และ bcdedit ที่ผิดปกติ บัญชีผู้ดูแลใหม่ และการล็อกอิน VPN ผิดปกติ
• เขียนแผนรับมือและแผนการสื่อสาร ให้ผู้บริหารสูงสุดอนุมัติเป็นลายลักษณ์อักษร และพิมพ์เก็บไว้
• ทำรายชื่อผู้ติดต่อ: ผู้บริหาร DPO ฝ่ายกฎหมาย ผู้ให้บริการ MA สคส. สกมช. หรือ ThaiCERT และตำรวจ
• ตรวจว่าองค์กรเป็นหน่วยงานของรัฐหรือ CII หรือไม่ แล้วเขียนกรอบเวลาแจ้งเหตุ (72 และ 24 ชั่วโมง) ไว้ในแผน
• เขียนในสัญญากับผู้ประมวลผลข้อมูลให้แจ้งเหตุภายใน 72 ชั่วโมง และกำหนดว่าใครดูแล backup และทดสอบกู้คืน
• ซ้อมแผนบนโต๊ะด้วยสถานการณ์ ransomware ที่ backup ถูกโจมตีด้วย แล้วปรับแผนจากสิ่งที่พบ

UNIXDEV ช่วยเตรียมรับมือ ransomware ได้แค่ไหน?

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

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

• CISA, MS-ISAC, NSA, FBI — #StopRansomware Guide (September 2023)
• NIST IR 8374 Rev. 1 — Ransomware Risk Management: A Cybersecurity Framework 2.0 Community Profile
• NIST SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• CISA — Tabletop Exercise Packages
• MITRE ATT&CK — T1486 Data Encrypted for Impact
• MITRE ATT&CK — T1490 Inhibit System Recovery
• MITRE ATT&CK — T1566 Phishing · T1190 · T1133 · T1078 · T1068 · T1003 · T1021.001 · T1219 · T1567 · T1048 · T1489
• FBI IC3 — Ransomware
• U.S. Treasury OFAC — Updated Advisory on Potential Sanctions Risks for Facilitating Ransomware Payments (2021)
• พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 (สำเนาราชกิจจานุเบกษา เผยแพร่โดย สคส.)
• ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล เรื่อง หลักเกณฑ์และวิธีการในการแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล พ.ศ. 2565
• สคส. — คู่มือการให้บริการ การแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล
• สคส. — แบบฟอร์มตัวอย่างการแจ้งเหตุการละเมิดข้อมูลส่วนบุคคล
• พ.ร.บ.การรักษาความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562 (สำเนาราชกิจจานุเบกษา เผยแพร่โดย สกมช.)
• ประกาศ กกม. เรื่อง หลักเกณฑ์และวิธีการรายงานภัยคุกคามทางไซเบอร์ พ.ศ. 2566
• ประกาศ กมช. เรื่อง ลักษณะภัยคุกคามทางไซเบอร์ มาตรการป้องกัน รับมือ ประเมิน ปราบปราม และระงับภัยคุกคามทางไซเบอร์แต่ละระดับ พ.ศ. 2564
• สกมช. — คู่มือประกอบแนวทางการแจ้งหรือรายงานเหตุภัยคุกคามทางไซเบอร์ พ.ศ. 2569
• สกมช. — ประกาศ กมช. เรื่อง หลักเกณฑ์ ลักษณะหน่วยงาน CII และการมอบหมายการควบคุมและกำกับดูแล พ.ศ. 2568
• สกมช. — รายงานประจำปี 2568
• สกมช. — รายงานผลการประเมินความเสี่ยงจากภัยคุกคามทางไซเบอร์ของประเทศไทย ประจำปี พ.ศ. 2568
• ThaiCERT — ติดต่อและแจ้งเหตุ
• ศูนย์ปราบปรามอาชญากรรมทางเทคโนโลยีสารสนเทศ สำนักงานตำรวจแห่งชาติ — แจ้งความออนไลน์
• Wazuh documentation — File integrity monitoring
• Wazuh documentation — Vulnerability detection
• Wazuh blog — Ransomware protection on Windows with Wazuh (2024)
• Wazuh blog — Detecting and responding to Cephalus ransomware with Wazuh (2025)
• บทความที่เกี่ยวข้อง: Wazuh คืออะไร
• บทความที่เกี่ยวข้อง: มี EDR หรือ Antivirus แล้ว ต้องมี Wazuh เพิ่มไหม?
• บทความที่เกี่ยวข้อง: วางแผนติดตั้ง Wazuh
• บทความที่เกี่ยวข้อง: ตรวจจับ Ransomware ด้วย Wazuh: ตั้งค่าอะไรบ้าง
• บทความที่เกี่ยวข้อง: Backup กัน Ransomware: Immutable หรือ Offline?
• บทความที่เกี่ยวข้อง: ระบบเก่าหมด support แต่ยังต้องใช้ต่อ
• บทความที่เกี่ยวข้อง: เช็กลิสต์สัญญา MA และ SLA
• บทความทั้งหมดในหมวด Wazuh และ Security Monitoring

บทความโดย UNIXDEV Team · 7 พฤศจิกายน 2026 · อ้างอิงเอกสารของ CISA, NIST, MITRE, สคส., สกมช. และ Wazuh ณ วันที่เขียน ซึ่งอาจเปลี่ยนภายหลัง สรุปข้อกฎหมายเพื่อประกอบการวางแผน ไม่ใช่คำแนะนำทางกฎหมาย และตัวอย่างการตั้งค่า Wazuh จาก blog ของผู้ผลิตต้องปรับและทดสอบกับระบบจริงก่อนใช้