ThaiCERT ได้ติดตามสถานการณ์ภัยคุกคามทางไซเบอร์และพบรายงานเกี่ยวกับ VECT 2.0 ransomware แต่จากการวิเคราะห์ของ Check Point Research พบข้อผิดพลาดร้ายแรงในการเข้ารหัสทำให้ไฟล์ที่มีขนาดมากกว่า 131,072 bytes หรือ 128 KB อาจเสียหายถาวร และไม่สามารถกู้คืนได้อย่างสมบูรณ์ แม้จะมีคีย์ถอดรหัสก็ตาม โดยข้อมูลที่จำเป็นต่อการถอดรหัสบางส่วนถูกทิ้งไประหว่างการทำงานของมัลแวร์ ส่งผลให้แม้ผู้เสียหายจ่ายค่าไถ่ ผู้โจมตีก็ไม่สามารถจัดหา decryptor ที่กู้คืนไฟล์ขนาดใหญ่ได้ครบถ้วน [1]
1. รายละเอียด
VECT 2.0 เป็นปฏิบัติการแบบ Ransomware-as-a-Service (RaaS) ที่รองรับ Windows, Linux และ VMware ESXi โดยมีโมเดลข่มขู่แบบหลายชั้น เช่น การขโมยข้อมูล การเข้ารหัส และการขู่เผยแพร่ข้อมูล ทั้งยังมีการเชื่อมโยงกับ BreachForums และ TeamPCP เพื่อเพิ่มช่องทางการกระจายการโจมตีผ่านข้อมูลหรือสิทธิ์เข้าถึงที่ถูกขโมยมาก่อนหน้า โดย VECT 2.0 ใช้กลไกเข้ารหัสที่มีข้อบกพร่อง โดยไฟล์ที่มีขนาดเกิน 131,072 bytes จะถูกแบ่งเป็น 4 ส่วน และมีการสร้าง nonce แยกกันสำหรับแต่ละส่วนแต่มัลแวร์บันทึกไว้เฉพาะ nonce ของส่วนสุดท้าย ส่วน nonce ของ 3 ส่วนแรกถูกสร้าง ใช้งาน แล้วถูกทิ้งไป ทำให้ข้อมูล 3 ส่วนแรกของไฟล์ขนาดใหญ่ไม่สามารถถอดกลับได้ แม้ผู้โจมตีจะมี key ก็ตาม
2. IoCs (Indicators of Compromise) [2]
SHA-256
– a7eadcf81dd6fda0dd6affefaffcb33b1d8f64ddec6e5a1772d028ef2a7da0f2
– 58e17dd61d4d55fa77c7f2dd28dd51875b0ce900c1e43b368b349e65f27d6fdd
– e1fc59c7ece6e9a7fb262fc8529e3c4905503a1ca44630f9724b2ccc518d0c06
– 8ee4ec425bc0d8db050d13bbff98f483fff020050d49f40c5055ca2b9f6b1c4d
– 9c745f95a09b37bc0486bf0f92aad4a3d5548a939c086b93d6235d34648e683f
– e512d22d2bd989f35ebaccb63615434870dc0642b0f60e6d4bda0bb89adee27a
3. แนวทางการป้องกันและแก้ไข
– นำ IoCs ที่เกี่ยวข้อง เช่น hash ของไฟล์, ชื่อ ransom note, นามสกุลไฟล์ .vect และชื่อไฟล์ที่ถูกสร้างขึ้น ไปตรวจสอบในระบบ SIEM, EDR/XDR, antivirus, firewall, proxy, mail gateway และระบบ log management
– หากพบไฟล์นามสกุล “.vect” หรือ ransom note “!!!READ_ME!!!.txt” ให้ถือว่าเป็นเหตุการณ์ destructive ransomware / wiper-like incident และไม่ควรจ่ายค่าไถ่ เนื่องจากไฟล์ขนาดใหญ่จำนวนมากอาจไม่สามารถถอดรหัสได้จริง
– แยกระบบที่ต้องสงสัยออกจากเครือข่ายทันที โดยเฉพาะ Windows server, Linux server, ESXi host, backup server และระบบที่มีสิทธิ์ admin/SSH/domain credential
– ระงับหรือจำกัดช่องทาง lateral movement เช่น SMB admin share, WMI, DCOM, PowerShell Remoting, scheduled task remote creation, SSH และ SCP
– ตรวจสอบและ rotate credentials ที่อาจถูกใช้หรือถูกเข้าถึง เช่น domain admin, local admin, SSH keys, hypervisor credentials, backup credentials, database credentials และ service accounts
– กู้คืนข้อมูลจาก offline / immutable backup ที่ผ่านการทดสอบแล้วเท่านั้น และตรวจสอบให้แน่ใจว่า backup ไม่ถูกเข้ารหัสหรือถูกทำลายก่อนนำกลับมาใช้งาน
– ตรวจสอบร่องรอยบน Windows เช่น การลบ shadow copies, การปิด Windows Defender, การล้าง event logs, การแก้ไข boot configuration/safe mode และการสร้าง remote service หรือ scheduled task ที่ผิดปกติ
– ตรวจสอบร่องรอยบน Linux/ESXi เช่น “/var/log/*” ที่ถูกลบหรือถูก zero-out, shell history ที่หายไป, “known_hosts” ที่ถูกแก้ไข, การเชื่อมต่อ SSH/SCP ผิดปกติ, การหยุด service ด้าน backup/database/security และ activity ใน “/vmfs/volumes”
– เพิ่มการป้องกันเชิงระบบ เช่น network segmentation, least privilege, MFA สำหรับบัญชี privileged, EDR/XDR บน server สำคัญ, การแยก backup network และการซ้อม recovery procedure เป็นประจำ
4. แนวทางการรับมือเมื่อถูกโจมตี [3]
4.1 จำกัดความเสียหายปลดเครื่องที่ติดเชื้อออกจากเครือข่ายทันที (ถอดสาย LAN/Wi-Fi) ห้ามปิดเครื่อง (Do not power down) เพื่อรักษาหลักฐานในหน่วยความจำ
4.2 ประเมินสถานการณ์ประสานทีม Incident Response (IR) ทันทีเพื่อประเมินขอบเขตผลกระทบ
4.3 เก็บหลักฐานทำ System Image และดึงข้อมูล Memory ของเครื่องที่ถูกโจมตีไว้เพื่อใช้วิเคราะห์
4.4 แจ้งผู้เกี่ยวข้อง รายงานทีมบริหาร และหน่วยงานกำกับดูแลด้านไซเบอร์หรือบังคับใช้กฎหมาย
4.5 หาทางถอดรหัส ตรวจสอบความพร้อมของเครื่องมือถอดรหัส (Decryptor) จากผู้เชี่ยวชาญ
4.6 กู้คืนอย่างปลอดภัย กู้คืนระบบจาก Offline Backup หลังจากกำจัดมัลแวร์และอุดช่องโหว่เรียบร้อยแล้วเท่านั้น
4.7 ปฏิบัติตามแนวปฏิบัติพื้นฐานในการป้องกันมัลแวร์เรียกค่าไถ่ (Ransomware) และการรั่วไหลของข้อมูล สำหรับหน่วยงาน [4]
แหล่งอ้างอิง