# แรนซัมแวร์ ESXi BlackNevas: Kaspersky ชี้ผู้โจมตีทำลาย vCenter และระบบสำรองก่อนลบ VM

> แรนซัมแวร์ ESXi BlackNevas ทำลายระบบเสมือนขององค์กรใน 10 วัน Kaspersky GERT เปิดรายงาน 13 พ.ย. 2026 ผู้โจมตีใช้เครื่องมือ VMware ปกติ ไม่ต้องใช้ช่องโหว่

- ประเภท: ข่าว · หมวด: Cybersecurity
- เผยแพร่: 2026-11-15T00:35:00.000Z · อัปเดต: 2026-11-15T00:35:00.000Z
- โดย: กองบรรณาธิการ THAI DATA, THAI DATA IT BUSINESS ENTERPRISE
- ที่มา: https://thaidata.co.th/security/blacknevas-esxi-vcenter-ransomware-kaspersky-gert/

## สรุปประเด็นสำคัญ

- ทีม 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 รายงานนี้เน้นวิธีทำงานของผู้โจมตีและสิ่งที่ผู้ป้องกันควรตรวจ ไม่ได้ระบุชื่อองค์กรเหยื่อ

![ห้องเซิร์ฟเวอร์ที่มีตู้แร็กหลายตู้และสายเคเบิลเครือข่าย](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/blacknevas-esxi-vcenter-ransomware-kaspersky-gert/server-room-racks-cables.webp?v=4bb1c4fc) _(ภาพ: Carl Lender (CC BY 2.0))_

## แรนซัมแวร์ 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 ที่แก้ไฟล์ดิสก์

![แผนภาพของ Kaspersky แสดงเส้นทางเข้าสู่ชั้นจัดการ vCenter และ ESXi](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/blacknevas-esxi-vcenter-ransomware-kaspersky-gert/kaspersky-virtualization-trust-stack.webp?v=c941fa38) _(ภาพ: Kaspersky (Securelist))_

## 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 แสดงลำดับการใช้ Host Profile เปิด SSH บนโฮสต์ ESXi](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/blacknevas-esxi-vcenter-ransomware-kaspersky-gert/kaspersky-host-profile-abuse-chain.webp?v=ec1a3dc0) _(ภาพ: Kaspersky (Securelist))_

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](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/blacknevas-esxi-vcenter-ransomware-kaspersky-gert/kaspersky-recovery-failed-before-production.webp?v=073ea8d0) _(ภาพ: Kaspersky (Securelist))_

## ระบบสำรองถูกทำลายก่อน และบทเรียนจากแรนซัมแวร์ ESXi BlackNevas ต่อองค์กรไทย

Kaspersky ระบุว่าในเหตุแรนซัมแวร์ ESXi BlackNevas ระบบสำรองไม่ใช่ความเสียหายพลอยได้ ผู้โจมตีปิดแอนตี้ไวรัสของสภาพแวดล้อมสำรองหลายวันก่อน แล้วในวันโจมตีหยุดบริการสำรอง เข้ารหัสโครงสร้างกู้คืน และล็อกผู้ดูแลออก ทั้งหมดก่อนลงมือกับ ESXi รายงานจึงเสนอให้นิยามระบบสำรองที่ยืดหยุ่นใหม่ ที่เก็บข้อมูลแบบ immutable มีค่า แต่ไม่ปกป้องตัวตน เซิร์ฟเวอร์จัดการ เส้นทางเครือข่าย และขั้นตอนที่ใช้กู้คืน

สิ่งที่องค์กรไทยที่ใช้ VMware ควรตรวจเพื่อกันแรนซัมแวร์ ESXi BlackNevas และตัวล็อกแบบเดียวกัน ตามแนวทางของรายงาน

1. **แยกตัวตน** ใช้บัญชีผู้ดูแล vCenter และ ESXi แยกจากบัญชีโดเมน ไม่ใช้กลุ่มโดเมนกว้าง ๆ เข้าถึงระดับสูง
2. **จำกัดเครือข่ายจัดการ** ให้เข้า vCenter และ ESXi ได้เฉพาะเครือข่ายและเครื่องผู้ดูแลที่จำเป็น
3. **เก็บล็อกออกนอกโฮสต์** ESXi เก็บล็อกบน ramdisk ที่หายเมื่อรีบูต ควรส่งไปเก็บภายนอก เช่น auth.log, shell.log, vpxa.log และ vobd.log
4. **เฝ้าการเปลี่ยนค่าป้องกัน** เช่น ระดับการยอมรับ VIB และค่า execInstalledOnly ซึ่งถ้าถูกลดย่อมน่าสงสัย
5. **ออกแบบระบบกู้คืนเป็นขอบเขตแยก** ใช้ตัวตนคนละชุด มีสำเนาแบบออฟไลน์หรือแยกตรรกะ และทดสอบกู้จริงเป็นระยะ
6. **ตรวจรุ่นที่หมดซัพพอร์ต** เหยื่อมักใช้ ESXi รุ่นที่ไม่ได้รับการสนับสนุน

![แผนภาพของ Kaspersky เปรียบเทียบการออกแบบที่ใช้ตัวตนร่วมกับการแยกอำนาจกู้คืน](https://thaidata-co-th.s3.ap-southeast-1.amazonaws.com/thaidata.co.th/images/articles/blacknevas-esxi-vcenter-ransomware-kaspersky-gert/kaspersky-separated-recovery-authority.webp?v=0fc8186d) _(ภาพ: Kaspersky (Securelist))_

## บริการของ THAI DATA CLOUD ที่เกี่ยวข้อง

รายงานนี้ชี้ว่าสำเนาสำรองที่อยู่ในโดเมนและเครือข่ายเดียวกับ production อาจถูกทำลายก่อนวันโจมตี [On-Premise to Cloud Backup](https://thaidata.cloud/backup-on-premise-to-cloud/) ของ THAI DATA CLOUD สำรองข้อมูลจากเซิร์ฟเวอร์ในองค์กรขึ้นคลาวด์อย่างต่อเนื่อง ด้วย Continuous Data Protection และ Hybrid Cloud Backup จึงเป็นทางเลือกให้องค์กรมีสำเนาอีกชุดนอกสภาพแวดล้อมเดิม (THAI DATA CLOUD เป็นผู้ดำเนินงานเว็บไซต์นี้)

อ่านข่าวแรนซัมแวร์และภัยคุกคามอื่น ๆ ได้ในหมวด [ความปลอดภัยไซเบอร์](/security/)

## คำถามที่พบบ่อย

### แรนซัมแวร์ 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](https://securelist.com/esxi-ransomware/121959/) — Kaspersky (Securelist)
- [Securelist: Threat Response](https://securelist.com/) — Kaspersky (Securelist)