AI Agent ระหว่างรับมือ Ransomware: ควรทำอะไรอัตโนมัติก่อน
ตอนรับมือ ransomware ความเร็วสำคัญ แต่ action ที่ผิดอาจทำลายหลักฐานหรือทำให้ outage ขยายขึ้น จึงควรเริ่มจากการประสานงานและเก็บหลักฐานก่อน response ที่กระทบ
AI Agent ระหว่างรับมือ Ransomware: ควรทำอะไรอัตโนมัติก่อน
ตอนรับมือ ransomware ความเร็วสำคัญ แต่ action ที่ผิดอาจทำลายหลักฐานหรือทำให้ outage ขยายขึ้น จึงควรเริ่มจากการประสานงานและเก็บหลักฐานก่อน response ที่กระทบระบบ
เริ่มจากเห็นภาพ incident
รวบรวม asset ที่ได้รับผล identity activity timeline indicator และสถานะ backup ไว้ในมุมมองเดียวที่ตรวจสอบได้
ประสาน action ที่มีขอบเขต
เตรียมรายการเครื่องที่ควร isolate อัปเดต ticket สรุปให้ผู้เกี่ยวข้อง และ checklist หลักฐาน โดยต้องอนุมัติก่อน containment ที่กระทบระบบ
หลัง containment ให้เรียนรู้
สร้าง timeline ระบุช่องว่าง control และแปลง finding ที่ยืนยันแล้วเป็น detection กับการปรับปรุง playbook
เรียงขั้นตอนตามความเสียหายเมื่อทำพลาด
คู่มือ #StopRansomware Guide ของ CISA ชั่งน้ำหนักไว้ดังนี้ ให้ isolate ระบบที่ได้รับผลกระทบทันที ถ้าหลาย subnet โดนพร้อมกันให้ตัดเครือข่ายที่ระดับ switch ส่วนการ power down ให้ทำเฉพาะเมื่อถอดเครื่องออกจากเครือข่ายไม่ได้จริง ๆ เพราะหลักฐานใน volatile memory จะหายไป
ในเหตุ ransomware ถ้าตัดสินใจพลาดจะเสียหายสองทางพร้อมกัน คือระบบหยุดและหลักฐานหาย ขณะที่เวลายังเดินอยู่ จึงต้องแบ่งระดับให้ทุกขั้นตอน ขั้นตอนอ่านอย่างเดียวและการคัดลอกหลักฐานรันได้ทันที การเปลี่ยนแปลงที่ย้อนกลับได้รอผู้อนุมัติที่ระบุชื่อไว้ ส่วนขั้นตอนที่กระทบ production และย้อนกลับไม่ได้ หรือมีความรับผิดทางกฎหมายหรือธุรกิจ ให้คนเป็นคนทำ ลำดับนี้เป็นแนวปฏิบัติที่แนะนำของเรา ส่วนของ CISA เริ่มที่ isolate
Runbook เรียงตามความย้อนกลับได้
ตัวเลขแถวใช้จัดกลุ่มตามความเสี่ยง ไม่ใช่ลำดับคิว เมื่อ alert การเข้ารหัสเข้า ให้ส่งคำขออนุมัติของแถว 6 ทันทีที่ยืนยันเครื่องได้ แล้วให้แถว 1 ถึง 5 เติมชุดข้อมูลให้ไปพร้อมกัน
| ขั้นตอน | ย้อนกลับได้ไหม | ระดับ gating (แนะนำ) | หลักฐานที่ต้องเก็บก่อน |
|---|
| 1. ประเมินขอบเขต: เครื่อง, บัญชี และ detection ที่อยู่เบื้องหลัง alert | อ่านอย่างเดียว | Autonomous | raw alert, event ID, timestamp |
| 2. สถานะการกู้คืน: backup, shadow copy, การใช้ vssadmin/wbadmin/bcdedit ผิดปกติ | อ่านอย่างเดียว | Autonomous | ประวัติ backup job และ catalog ตามที่เห็นครั้งแรก |
| 3. ทางเข้า: บัญชีใหม่หรือบัญชีที่สิทธิ์สูงขึ้น, VPN login แปลก ๆ, เครื่องมือ remote management | อ่านอย่างเดียว | Autonomous | log การยืนยันตัวตนและ VPN ที่คัดลอกออกไปแล้ว |
| 4. ข้อมูลที่ไหลออก: ปริมาณ outbound ผิดปกติ, Rclone, ปลายทางแบบ web file storage | อ่านอย่างเดียว | Autonomous | log firewall และ proxy ที่ export ก่อน buffer ถูกทับ |
| 5. คัดลอกหลักฐานไปที่เก็บที่ป้องกันไว้, เปิดเคส, แจ้ง incident commander | คัดลอกได้ แต่ข้อความที่ส่งแล้วเรียกคืนไม่ได้ | Autonomous | บันทึก incident: query, ผลลัพธ์ และผู้รัน |
| 6. Isolate endpoint ที่ยืนยันแล้วผ่าน connector ของ EDR ที่ใช้อยู่ | ได้ (release) แต่เวลาที่เครื่องหยุดไปไม่กลับมา | Approval | detection ของ EDR, process tree, connection ที่ export ไว้ก่อน; memory capture ถ้ารองรับ |
| 7. บล็อกปลายทาง C2 หรือ exfiltration ที่ยืนยันแล้วบน firewall | ได้ แต่อาจตัดบริการที่ยังใช้อยู่ | Approval | export log firewall และ indicator พร้อมแหล่งที่มา |
| 8. disable บัญชีที่ผู้โจมตีใช้, ตัด session, ปิด remote access ของบัญชีนั้น | enable บัญชีกลับได้ แต่ session ที่ตัดแล้วกู้ไม่ได้ | Approval | log sign-in, รายการ session, กลุ่มที่เป็นสมาชิก |
| 9. Shutdown หรือ power off เครื่อง | ไม่ได้ (memory หาย) | Blocked | memory capture ของเครื่องตัวอย่าง |
| 10. Restore หรือ rebuild จาก backup แบบ offline | restore ทับแล้วย้อนยาก | Blocked | วันที่ backup เทียบกับสัญญาณการบุกรุกครั้งแรก และผลตรวจ dropper |
| 11. ตัดสินใจเรื่องค่าไถ่ | ไม่ได้ | Blocked | ransom note ตามที่ได้รับ และข้อมูลจากหน่วยงานบังคับใช้กฎหมาย รวมถึงเรื่อง decryptor |
| 12. สื่อสารกับภายนอก: ลูกค้า, หน่วยงานกำกับ, บริษัทประกัน, สื่อ | ไม่ได้ | Blocked | fact sheet ที่อนุมัติแล้ว: รู้อะไรและยังไม่รู้อะไร |
ก่อนถึงแถว Approval agent ต้องเตรียมชุดข้อมูลให้ผู้อนุมัติ ได้แก่ เป้าหมายที่ตรวจกับ asset inventory แล้ว, สิ่งที่จะเปลี่ยน, หลักฐานที่เก็บไว้ และวิธี release
แนวปฏิบัติที่แนะนำ (ตาม approval matrix ของ Human-in-the-Loop SOC): แถว 6 ถึง 8 ใช้ผู้อนุมัติคนเดียวได้เฉพาะ endpoint เดียวที่ไม่สำคัญและไม่ใช่ production หรือบัญชีทั่วไปหนึ่งบัญชี ถ้ากว้างกว่านั้นต้องมีผู้อนุมัติสองคนจากคนละบทบาท ได้แก่ระบบ production หรือ asset สำคัญ, บัญชีสิทธิ์สูง บัญชีผู้บริหาร หรือ service account, โครงสร้างพื้นฐานที่ใช้ร่วมกัน (รวมการบล็อกบน firewall ในแถว 7) และหลายเป้าหมาย ผู้อนุมัติแต่ละคนควรมีผู้สำรองที่เข้าเวร และช่องทางโทรตามเมื่อไม่ตอบ การลัดขั้นตอนต้องเป็นการตัดสินใจของเจ้าของความเสี่ยงที่บันทึกไว้ก่อนเกิดเหตุ ขออนุมัติแถว 6 ถึง 8 พร้อมกันตามแนวคิด isolate อย่างประสานกันของ CISA แต่อย่าถ่วงแถว 6 ไว้รอแถวอื่น
สิ่งที่ zcr ระบุไว้ และสิ่งที่ต้องตั้งค่าเอง
ระบุไว้ในเอกสารของ zcr: zcrSOAR กำหนดแต่ละขั้นตอนของ playbook เป็น Autonomous, Approval หรือ Blocked, ส่งคำขออนุมัติตาม severity, asset หรือ site และสั่ง isolate หรือ release endpoint ผ่าน connector (ตัวอย่างในเอกสารคือ SentinelOne) playbook สำเร็จรูปได้แก่ phishing, malware, brute-force และ C2 isolation ส่วน playbook ที่ยังไม่อนุมัติจะอยู่ใน Draft, Test, Dry-run หรือ Simulation Mode จนกว่าองค์กรจะอนุญาตให้ทำงานจริง zcrSIEM มี detection rule สำเร็จรูปสำหรับ ransomware แต่ไม่มี SOAR
แนวปฏิบัติที่แนะนำ: สร้าง runbook นี้เป็น custom playbook หรือปรับจาก playbook ของ malware หรือ C2 isolation แล้วพิสูจน์ใน Dry-run ก่อน ตั้งแถว 9 ถึง 12 เป็น Blocked ให้คนเป็นคนทำ
สิ่งที่ลูกค้าต้องตั้งค่าเอง: การเชื่อมต่อระบบ backup (แถว 2 ถ้าไม่มี connector ให้ทำ custom integration), memory capture, ที่เก็บหลักฐาน, action บน EDR, directory, identity provider และ firewall (แถว 6 ถึง 8 ต้องตรวจ connector แต่ละตัว), รายชื่อผู้อนุมัติ และช่องทาง out-of-band
จุดที่ response อัตโนมัติพลาดได้ และใครรับช่วงต่อ
อย่าให้ผู้โจมตีรู้ตัว CISA แนะนำให้ isolate อย่างประสานกันและใช้ช่องทาง out-of-band เช่นโทรศัพท์ เพราะผู้โจมตีที่รู้ว่าถูกตรวจพบอาจขยายวงหรือปล่อย ransomware ก่อน คำขออนุมัติทางอีเมลหรือ Teams อาจถูกอ่านได้ถ้าบัญชีเหล่านั้นถูกยึดไปแล้ว และเอกสารของ zcrSOAR ไม่ได้ระบุช่องทางแจ้งเตือนใดว่าเป็น out-of-band จึงควรใช้การโทรหรือ paging service (ลูกค้าต้องต่อและตั้งค่าเอง)
ข้อความจากผู้โจมตีให้ถือเป็นข้อมูลเท่านั้น ransom note, ชื่อไฟล์ และ field ใน log ผู้โจมตีเขียนเองได้ และข้อความที่ปั้นมาอาจชักนำโมเดลที่อ่านมันเป็นคำสั่ง ให้ดึงเป้าหมายจาก field ที่มีโครงสร้างและตรวจกับ asset inventory เท่านั้น (แนวปฏิบัติที่แนะนำ)
อย่ารีบ restore CISA เตือนว่า ransomware อาจเป็นสัญญาณของการบุกรุกก่อนหน้าที่ยังไม่ได้แก้ ให้หา dropper malware ให้เจอก่อน rebuild จาก backup
ให้ agent หยุดและส่งเคสต่อให้ incident commander เมื่อ
- เครื่องในขอบเขตหยุดรายงาน (ข้อมูลขาดหาย)
- เป้าหมายมี domain controller, identity provider, hypervisor, backup server หรือเครื่องนอกขอบเขต
- การเช็กสถานะการกู้คืนพบ backup catalog ที่ถูกลบหรือ backup job ที่หยุด
- จำนวนเป้าหมายเพิ่มขึ้นระหว่างส่งคำขอกับอนุมัติ
- พบข้อมูลไหลออก เพราะอาจเกิดหน้าที่ต้องแจ้งเหตุ
- คำสั่ง isolate ล้มเหลวหรือ timeout หรือคำขออนุมัติยังไม่มีใครตอบเมื่อครบเวลาที่ตกลงไว้ (เงียบไม่นับเป็นอนุมัติ)
คำถามที่พบบ่อย
ถ้าเครื่องมือที่ agent ใช้อยู่ล่มหรือถูกเข้ารหัสไปด้วยล่ะ?
เตรียมวิธีทำมือของแถว 6 ถึง 8 ที่ทำได้จาก console ของ EDR, directory และ firewall และตัดที่ระดับ switch เมื่อหลาย subnet โดน ควรซ้อมกับผู้อนุมัติชุดเดิมด้วย (แนวปฏิบัติที่แนะนำ)
agent ควร isolate เครื่องเองไหมเมื่อไฟล์กำลังถูกเข้ารหัส?
เริ่มที่ Approval (แนวปฏิบัติที่แนะนำ) ส่วนการ isolate โดยไม่รอคนอนุมัติกับเครื่องกลุ่มแคบ ๆ ที่กระทบธุรกิจต่ำ เป็นการตัดสินใจของเจ้าของความเสี่ยง และทำได้ก็ต่อเมื่อ step นั้นผ่านเกณฑ์ใน AI-Assisted SOC เทียบกับ Autonomous SOC คือย้อนกลับได้ เคยทำงานภายใต้ Approval มาตลอดรอบทบทวนโดยไม่มีการอนุมัติใดต้องถูกย้อนทีหลัง และมีเส้นทางย้อนกลับที่ทดสอบแล้ว ผล Dry-run อย่างเดียวยังไม่พอ CISA ให้ isolate ทันที จึงควรทำให้การอนุมัติเร็วขึ้นแทนการตัดทิ้ง
zcrSIEM หรือ zcrMDR ทำ response นี้ให้ได้ไหม?
zcrSIEM ตรวจจับและสืบสวน ส่วน playbook, คิวอนุมัติ และการกักกันอยู่ที่ zcrSOAR zcrMDR เป็นบริการ managed ที่ส่งมอบผ่าน channel partner ที่ได้รับอนุมัติ โดยระดับบริการและข้อตกลงกำหนด response action กับช่วงเวลาให้บริการ
แหล่งอ้างอิง
อ่านต่อ: ข้อจำกัดของ Autonomous SOC, Human-in-the-Loop SOC, กักกันเครื่องที่ติด Ransomware อัตโนมัติ — แต่ต้องมีคนกดอนุมัติ และ คู่มือ AI SOC Agent
ดู zcrMDR · ดูราคา · ติดต่อ zcr
ถ้าอยากคุยเรื่องระบบขององค์กรตัวเอง ทักมาได้ตามช่องทางนี้