แรนซัมแวร์ ESXi BlackNevas ทำลายระบบเสมือนขององค์กรใน 10 วัน Kaspersky GERT เปิดรายงาน 13 พ.ย. 2026 ผู้โจมตีใช้เครื่องมือ VMware ปกติ ไม่ต้องใช้ช่องโหว่
โดย กองบรรณาธิการ THAI DATA อ่าน 5 นาที
สรุปประเด็นสำคัญ
- ทีม GERT ของ Kaspersky เผยแพร่รายงานเมื่อ 13 พฤศจิกายน 2026 ว่าผู้โจมตีกลุ่ม BlackNevas ทำลายระบบเสมือนขององค์กรหนึ่งตลอด 10 วัน ทั้ง ESXi 4 โฮสต์ ทุก VM บนโฮสต์ vCenter Server Appliance 2 ตัว และโครงสร้างสำรองข้อมูลทั้งหมด
- จุดสำคัญคือ ไม่ได้ใช้ช่องโหว่ชั้นเสมือน ไม่มีการหลุดจาก guest ไปโฮสต์ และไม่มี memory corruption ทุกคำสั่งที่ใช้กับ ESXi ทำผ่านช่องทางจัดการของ VMware ที่ถูกต้อง
- ผู้โจมตีใช้ vCenter Host Profile เปิด SSH บนโฮสต์ ESXi ภายในราว 11 นาที หลังอ่านค่าตั้งต้น แล้วเข้าโฮสต์จาก IP ของ vCenter ซึ่งเครือข่ายมักเชื่อถือ ก่อนที่ VM ทั้งหมดจะดับภายใน 23 วินาที
- ระบบสำรองถูกทำลาย ก่อน โจมตี ESXi: ปิดแอนตี้ไวรัสของระบบสำรองหลายวันก่อน หยุดบริการสำรอง เข้ารหัสระบบกู้คืน และล็อกผู้ดูแลออก Kaspersky ชี้ว่าความไม่เปลี่ยนแปลงของที่เก็บข้อมูลอย่างเดียวไม่พอ
- Kaspersky ระบุว่าแรนซัมแวร์คิดเป็น 39.4% ของเหตุที่ GERT รับมือในปี 2025 และโค้ด Babuk ที่รั่วเมื่อ กันยายน 2021 ทำให้อย่างน้อย 10 ตระกูล แรนซัมแวร์ใช้ตัวล็อก ESXi ได้ง่ายขึ้น
แรนซัมแวร์ ESXi BlackNevas ทำลายระบบเสมือนขององค์กรหนึ่งตลอด 10 วัน ตามรายงานของทีม Global Emergency Response Team (GERT) ของ Kaspersky ที่เผยแพร่เมื่อวันที่ 13 พฤศจิกายน 2026 ผู้โจมตีทำลาย ESXi 4 โฮสต์ ทุก VM บนโฮสต์ vCenter Server Appliance 2 ตัว และระบบสำรองข้อมูลทั้งหมด โดยที่ Kaspersky ระบุว่าไม่มีการใช้ช่องโหว่ในชั้นเสมือน ทุกคำสั่งกับ ESXi ทำผ่านช่องทางจัดการของ VMware ที่ถูกต้อง
ในเหตุแรนซัมแวร์ ESXi BlackNevas ใบเรียกค่าไถ่ระบุว่าเป็นกลุ่ม BlackNevas ซึ่ง Kaspersky บอกว่าพบครั้งแรกเมื่อเดือนพฤศจิกายน 2024 รายงานนี้เน้นวิธีทำงานของผู้โจมตีและสิ่งที่ผู้ป้องกันควรตรวจ ไม่ได้ระบุชื่อองค์กรเหยื่อ
แรนซัมแวร์ ESXi BlackNevas ทำให้การโจมตีระบบเสมือนคุ้มค่าขึ้นอย่างไร
Kaspersky อธิบายว่าระบบเสมือนช่วยลดต้นทุนและรวมศูนย์การดูแล แต่ก็ลดจุดควบคุมลงด้วย จึงเป็นเหตุให้แรนซัมแวร์ ESXi BlackNevas และตัวล็อกแบบเดียวกันสร้างความเสียหายได้กว้าง ถ้าเครื่องเดียวติดมัลแวร์ผลกระทบมักจำกัดอยู่ที่ระบบปฏิบัติการนั้น แต่ถ้าผู้โจมตียึดชั้นจัดการได้ ก็เข้าถึงโฮสต์หลายเครื่อง และเมื่อกระทบที่เก็บข้อมูลของ ESXi โดยตรง ระบบ guest จำนวนมากใช้งานไม่ได้พร้อมกัน
ตัวเลขที่ Kaspersky อ้างถึงได้แก่
- แรนซัมแวร์คิดเป็น 39.4% ของเหตุที่ GERT รับมือในปี 2025
- โค้ด Babuk รั่วเมื่อกันยายน 2021 พร้อมตัวล็อก ESXi และอย่างน้อย 10 ตระกูล แรนซัมแวร์ใช้โค้ดนั้นต่อ ทำให้กลุ่มที่ไม่เก่งเทคนิคก็ทำตัวล็อก ESXi ได้
- เหยื่อมักใช้ ESXi รุ่นที่ไม่ได้รับการสนับสนุน ซึ่งโจมตีง่ายกว่า
อีกข้อที่ Kaspersky เน้นคือช่องว่างการมองเห็น Broadcom ระบุว่าไม่รองรับการติดตั้งเอเจนต์ของบริษัทอื่นหรือแอนตี้ไวรัสบน ESXi และ vCenter Server Appliance โดยตรง ผู้ป้องกันจึงต้องพึ่งการเสริมความแข็งแรงในตัว ข้อมูลจากชั้นจัดการ และการเชื่อมระบบแบบไม่ติดตั้งเอเจนต์ EDR ในเครื่อง guest เห็นแค่ผลที่ตามมา เช่น I/O ผิดพลาดหรือเครื่องดับกะทันหัน ไม่เห็นกระบวนการฝั่ง ESXi ที่แก้ไฟล์ดิสก์
4 เส้นทางที่นำแรนซัมแวร์ ESXi BlackNevas ไปถึงชั้นจัดการเสมือน
รายงานเรื่องแรนซัมแวร์ ESXi BlackNevas จัดเส้นทางที่พบซ้ำไว้ 4 แบบ ตามตารางนี้
| เส้นทาง | สิ่งที่ Kaspersky ระบุ |
|---|---|
| ใช้ช่องโหว่ที่เปิดเผยแล้ว | ตัวอย่างเช่น ช่องโหว่ vCenter และ ESXi หลายรายการที่ CISA ขึ้นบัญชี KEV แต่ในเหตุนี้ ไม่มีหลักฐาน ว่าใช้ช่องโหว่เป็นทางเข้า |
| ใช้รหัสผ่านซ้ำจากระบบ Windows | บัญชีผู้ดูแลที่อยู่บน domain controller, jump server, ระบบสำรอง หรือเครื่องผู้ดูแล ใช้เข้า vCenter หรือ ESXi ได้ถ้าใช้บัญชีเดียวกันข้ามส่วน ในเหตุนี้ใช้เส้นทางนี้ |
| ใช้การผูก Active Directory | ช่องโหว่อย่าง CVE-2024-37085 เปลี่ยนสิทธิ์ในกลุ่มโดเมนเป็นสิทธิ์ผู้ดูแล ESXi เต็มรูปแบบ แก้แล้วใน ESXi 8.0 U3 |
| ใช้ระบบสำรองเป็นสะพานรหัสผ่าน | ระบบสำรองต้องมีบัญชีบริการและสิทธิ์กว้าง ในเหตุนี้ผู้โจมตีดึงรหัสที่เก็บไว้ออกมาหลังได้สิทธิ์ผู้ดูแลบนเครื่องสำรอง |
Kaspersky เตือนว่าการเข้าด้วยบัญชีที่ถูกต้องอาจดูเป็นเรื่องปกติทั้งหมด การตรวจจึงต้องดูต้นทาง ประวัติบัญชี เวลา ปลายทาง และสิ่งที่ทำต่อ ว่าบัญชีนั้นปกติดูแลระบบเสมือนหรือไม่
แรนซัมแวร์ ESXi BlackNevas ใช้ vCenter Host Profile เปิดทางเข้า ESXi
หลังเข้าถึง vCenter ผู้โจมตีฝังตัวไว้ 2 ชั้น คือเครื่องมือจัดการระยะไกลที่ถูกกฎหมายและอุโมงค์ย้อนกลับ จากนั้นใช้ฟีเจอร์ Host Profile ซึ่งออกแบบมาเก็บและบังคับค่าตั้งต้นบนโฮสต์ ESXi ไปเปลี่ยนสถานะบริการ SSH บนโฮสต์เป้าหมาย ตามบันทึก ผู้โจมตีใช้เวลาราว 11 นาทีนับจากอ่านค่าตั้งต้น จนโฮสต์เปลี่ยนจากปิด SSH ตามนโยบายเป็นเข้าระยะไกลได้ แล้วเข้าโฮสต์ ESXi จาก IP ของ vCenter ซึ่งเครือข่ายมักเชื่อถืออยู่แล้ว
Kaspersky สรุปว่ากลไกป้องกันไม่ได้ถูกเจาะจากด้านล่าง แต่ถูกตั้งค่าใหม่จากด้านบน จึงควรถือ vCenter เป็นสินทรัพย์ระดับสูงสุด (Tier 0) แยกบัญชีผู้ดูแลออกจากการดูแลองค์กรทั่วไป และตั้งแจ้งเตือนเมื่อ Host Profile เปลี่ยนค่า SSH นอกช่วงที่อนุมัติ โดยเฉพาะเมื่อตามด้วยการเข้า SSH จาก vCenter
ขั้นสุดท้ายของแรนซัมแวร์ ESXi BlackNevas: VM ทั้งหมดดับใน 23 วินาที
ในโฮสต์สำรองภัยพิบัติที่แรนซัมแวร์ ESXi BlackNevas โจมตี บันทึกของ ESXi แสดงว่า VM ทั้งหมดหยุดภายใน 23 วินาที และจำนวน VM ที่รันต่อชั่วโมงตกเป็นศูนย์ ผู้โจมตีทดลองรันตัวล็อกราว 16 วินาทีเมื่อประมาณ 3 ชั่วโมงก่อนลงมือจริง ซึ่ง Kaspersky ตีความว่าอาจเป็นการทดสอบความเข้ากันได้กับ ESXi รุ่นนั้น จากนั้นตัวล็อกเขียนทับราว 2 KB แรกของไฟล์ดิสก์ ซึ่งทำให้ guest บูตไม่ได้ แต่ Kaspersky ชี้ว่าไม่ได้แปลว่ากู้ไม่ได้เสมอไป เพราะ GPT มีส่วนหัวสำรองอยู่อีกที่ การกู้ได้หรือไม่ขึ้นกับข้อมูลโครงสร้างอื่นที่เหลือ
ระบบสำรองถูกทำลายก่อน และบทเรียนจากแรนซัมแวร์ ESXi BlackNevas ต่อองค์กรไทย
Kaspersky ระบุว่าในเหตุแรนซัมแวร์ ESXi BlackNevas ระบบสำรองไม่ใช่ความเสียหายพลอยได้ ผู้โจมตีปิดแอนตี้ไวรัสของสภาพแวดล้อมสำรองหลายวันก่อน แล้วในวันโจมตีหยุดบริการสำรอง เข้ารหัสโครงสร้างกู้คืน และล็อกผู้ดูแลออก ทั้งหมดก่อนลงมือกับ ESXi รายงานจึงเสนอให้นิยามระบบสำรองที่ยืดหยุ่นใหม่ ที่เก็บข้อมูลแบบ immutable มีค่า แต่ไม่ปกป้องตัวตน เซิร์ฟเวอร์จัดการ เส้นทางเครือข่าย และขั้นตอนที่ใช้กู้คืน
สิ่งที่องค์กรไทยที่ใช้ VMware ควรตรวจเพื่อกันแรนซัมแวร์ ESXi BlackNevas และตัวล็อกแบบเดียวกัน ตามแนวทางของรายงาน
- แยกตัวตน ใช้บัญชีผู้ดูแล vCenter และ ESXi แยกจากบัญชีโดเมน ไม่ใช้กลุ่มโดเมนกว้าง ๆ เข้าถึงระดับสูง
- จำกัดเครือข่ายจัดการ ให้เข้า vCenter และ ESXi ได้เฉพาะเครือข่ายและเครื่องผู้ดูแลที่จำเป็น
- เก็บล็อกออกนอกโฮสต์ ESXi เก็บล็อกบน ramdisk ที่หายเมื่อรีบูต ควรส่งไปเก็บภายนอก เช่น auth.log, shell.log, vpxa.log และ vobd.log
- เฝ้าการเปลี่ยนค่าป้องกัน เช่น ระดับการยอมรับ VIB และค่า execInstalledOnly ซึ่งถ้าถูกลดย่อมน่าสงสัย
- ออกแบบระบบกู้คืนเป็นขอบเขตแยก ใช้ตัวตนคนละชุด มีสำเนาแบบออฟไลน์หรือแยกตรรกะ และทดสอบกู้จริงเป็นระยะ
- ตรวจรุ่นที่หมดซัพพอร์ต เหยื่อมักใช้ ESXi รุ่นที่ไม่ได้รับการสนับสนุน
บริการของ THAI DATA CLOUD ที่เกี่ยวข้อง
รายงานนี้ชี้ว่าสำเนาสำรองที่อยู่ในโดเมนและเครือข่ายเดียวกับ production อาจถูกทำลายก่อนวันโจมตี On-Premise to Cloud Backup ของ THAI DATA CLOUD สำรองข้อมูลจากเซิร์ฟเวอร์ในองค์กรขึ้นคลาวด์อย่างต่อเนื่อง ด้วย Continuous Data Protection และ Hybrid Cloud Backup จึงเป็นทางเลือกให้องค์กรมีสำเนาอีกชุดนอกสภาพแวดล้อมเดิม (THAI DATA CLOUD เป็นผู้ดำเนินงานเว็บไซต์นี้)
อ่านข่าวแรนซัมแวร์และภัยคุกคามอื่น ๆ ได้ในหมวด ความปลอดภัยไซเบอร์
คำถามที่พบบ่อย
แรนซัมแวร์ ESXi BlackNevas โจมตีอย่างไรตามรายงาน Kaspersky?
แรนซัมแวร์ ESXi BlackNevas ตามรายงาน Kaspersky GERT คือการที่ผู้โจมตีกลุ่ม BlackNevas ใช้เวลา 10 วัน เข้าถึงระบบ vCenter และเครื่องสำรองด้วยบัญชีที่ได้จากระบบอื่นในองค์กร แล้วสั่ง ESXi ผ่านเครื่องมือจัดการของ VMware เอง ก่อนทำลายไฟล์ดิสก์ของ VM ทั้งหมด โดยไม่พบการใช้ช่องโหว่ในชั้นเสมือน
แรนซัมแวร์ ESXi BlackNevas ทำลายระบบสำรองข้อมูลก่อนโจมตีจริงหรือไม่?
ใช่ ในเหตุแรนซัมแวร์ ESXi BlackNevas ตามรายงานของ Kaspersky ผู้โจมตีปิดแอนตี้ไวรัสของระบบสำรองหลายวันก่อน แล้วหยุดบริการสำรอง เข้ารหัสระบบกู้คืน และล็อกผู้ดูแลออก ก่อนลงมือกับ ESXi ผลคือผู้ดูแลกู้ระบบจริงไม่ได้ในช่วงที่ต้องใช้มากที่สุด
ป้องกันแรนซัมแวร์ ESXi อย่างไรให้ได้ผลตามคำแนะนำ Kaspersky?
เพื่อรับมือแรนซัมแวร์ ESXi BlackNevas และตัวล็อกแบบเดียวกัน Kaspersky แนะนำให้ถือ vCenter เป็นสินทรัพย์ระดับสูงสุด แยกบัญชีผู้ดูแลระบบเสมือนออกจากบัญชีโดเมนทั่วไป จำกัดเครือข่ายจัดการ เก็บล็อกของ ESXi ไปที่ระบบภายนอก และออกแบบระบบกู้คืนให้เป็นอีกขอบเขตหนึ่งที่ไม่ใช้บัญชีและเครือข่ายเดียวกับ production
ผู้ใช้ VMware ในไทยต้องกังวลแรนซัมแวร์ ESXi BlackNevas หรือไม่?
รายงานแรนซัมแวร์ ESXi BlackNevas ไม่ได้ระบุว่ามีองค์กรไทยเป็นเหยื่อ แต่ทุกองค์กรที่ใช้ ESXi และ vCenter ควรตรวจสิทธิ์ผู้ดูแล การแยกเครือข่ายจัดการ และการสำรองข้อมูล เพราะวิธีโจมตีที่ Kaspersky บรรยายอาศัยบัญชีและการตั้งค่า ไม่ใช่ช่องโหว่ที่แพตช์แล้วจบ
แหล่งอ้างอิง
- Ransomware at the hypervisor layer: how attackers use ESXi and vCenter features for malicious purposes — Kaspersky (Securelist)
- Securelist: Threat Response — Kaspersky (Securelist)
บุคคล องค์กร และสถานที่ในข่าวนี้
เลือกชื่อเพื่ออ่านข่าวทั้งหมดที่กล่าวถึง ตัวเลขคือจำนวนข่าว
- องค์กรและบริษัท
- VMware38Broadcom30CISA85
- ผลิตภัณฑ์และเทคโนโลยี
- Windows142
พบข้อมูลคลาดเคลื่อน? แจ้งกองบรรณาธิการ