กลุ่มโยงจีนเจาะ VMware vCenter ด้วย CVE-2026-59310 — เหยื่อ 361 ไอพีใน 47 ประเทศ ปิดท้ายด้วยแรนซัมแวร์สาย Babuk บน ESXi

สรุปสั้น

ช่องโหว่ CVE-2026-59310 ใน VMware vCenter ของบริษัท Broadcom ซึ่งเป็นช่องโหว่ประเภท directory traversal คะแนน CVSS 9.8 และได้รับแพตช์ไปเมื่อวันที่ 29 กรกฎาคม 2569 ถูกนำไปใช้โจมตีจริงในวงกว้าง โดยบริษัทรับมือเหตุการณ์สัญชาติเยอรมนีชื่อ QUIRSO ประเมินด้วยความมั่นใจระดับปานกลางว่าผู้อยู่เบื้องหลังคือกลุ่มภัยคุกคามขั้นสูงที่มีความเชื่อมโยงกับจีน โดยอาศัยหลักฐานที่บรรจบกันหลายด้าน ทั้งร่องรอยภาษาจีนในสคริปต์ที่ผู้โจมตีสร้างขึ้น การหยิบงานวิจัยจากสำนักข่าวความปลอดภัยภาษาจีนมาใช้ซ้ำ การใช้เครื่องมือและซอฟต์แวร์บริหารจัดการภาษาจีนอย่างต่อเนื่อง รูปแบบเหยื่อที่ไม่มีจีนแผ่นดินใหญ่อยู่ในรายชื่อ และช่วงเวลาทำงานที่สอดคล้องกับโซนเวลา UTC+08:00

การโจมตีเริ่มขึ้นห้าวันตามปฏิทินหลังการเปิดเผยช่องโหว่ต่อสาธารณะ และประเมินว่ากระทบเหยื่ออย่างน้อย 361 ไอพีที่ไม่ซ้ำกันใน 47 ประเทศ โดยกระจุกตัวมากที่สุดในเยอรมนี 55 ราย สหรัฐอเมริกา 41 ราย ตุรกี 38 ราย อิหร่าน 26 ราย และฝรั่งเศส 25 ราย ผู้โจมตีได้สิทธิ์รันโค้ดระดับ root บนเครื่อง vCenter Server Appliance ทันทีโดยไม่ต้องยึดบัญชีผู้ใช้ธรรมดาแล้วยกระดับสิทธิ์ก่อน จากนั้นจึงฝังแบ็กดอร์ชื่อ linuxFile ตั้ง cronjob ที่ปลอมชื่อเป็นบริการของ VMware วางเว็บเชลล์ สร้างบัญชีผู้ดูแลระบบเพิ่มหลายบัญชี และปิดท้ายด้วยการปล่อยแรนซัมแวร์บนโฮสต์ ESXi ที่เข้ารหัสไฟล์ด้วยนามสกุล .babyk ซึ่งเป็นลายเซ็นของแรนซัมแวร์สายที่ต่อยอดจาก Babuk

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

รายละเอียดข่าว

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 17 สิงหาคม 2569 ว่านักวิจัยด้านความปลอดภัยไซเบอร์ได้เชื่อมโยงการโจมตีที่ใช้ช่องโหว่ซึ่งเพิ่งได้รับแพตช์ใน VMware vCenter ของบริษัท Broadcom เข้ากับกลุ่มภัยคุกคามขั้นสูงที่ต้องสงสัยว่ามีความเชื่อมโยงกับจีน โดยรายงานมาจากบริษัท QUIRSO ซึ่งเป็นบริษัทรับมือเหตุการณ์ด้านความปลอดภัยของเยอรมนี ผู้จัดทำคือนางสาว Maike Orlikowski นาย Çağatay Yürekli และนาย Denis Szadkowski

ทีมวิจัยระบุว่า “การประเมินนี้ตั้งอยู่บนการบรรจบกันของหลักฐานหลายด้าน ได้แก่ ร่องรอยภาษาจีนในสคริปต์ที่ผู้โจมตีสร้างขึ้น การนำงานวิจัยจากสิ่งพิมพ์ด้านความปลอดภัยภาษาจีนมาใช้ซ้ำอย่างชัดเจน การใช้เครื่องมือและซอฟต์แวร์บริหารจัดการภาษาจีนซ้ำ ๆ ในเชิงปฏิบัติการ ลักษณะเหยื่อที่ตัดจีนแผ่นดินใหญ่ออกไป และรูปแบบกิจกรรมที่สอดคล้องกับเวลาทำงานในโซน UTC+08:00” ซึ่งเป็นการอธิบายฐานของการชี้ตัวอย่างตรงไปตรงมาว่าเป็นการอนุมานจากพฤติกรรม ไม่ใช่การยืนยันตัวตนของผู้โจมตี

สิ่งที่ทำให้เคสนี้น่าสนใจคือเครื่อง vCenter Server Appliance เครื่องหนึ่งที่ QUIRSO วิเคราะห์ ถูกโจมตีด้วยช่องโหว่สองตัวคู่กัน คือ CVE-2026-59310 และ CVE-2026-59309 ซึ่งตัวหลังเป็นช่องโหว่บายพาสการยืนยันตัวตนที่พบว่ามีการสแกนหาเป้าหมายอย่างต่อเนื่องเช่นกัน หลักฐานชี้ว่ากิจกรรมที่สอดคล้องกับการใช้ CVE-2026-59309 เกิดขึ้นตั้งแต่วันที่ 1 สิงหาคม 2569 ตามด้วยการสร้างบัญชีผู้ดูแลระบบบน vCenter ทั้งที่ไม่พบเหตุการณ์ล็อกอินของบัญชีผู้ดูแลระบบตัวจริงที่ถูกใช้สร้างบัญชีใหม่นั้นเลย การสร้างบัญชีมีต้นทางจากไอพี 146.59.252[.]178 และตามด้วยการสำรวจ vSphere ผ่าน REST API ในวันที่ 3 สิงหาคม โดยใช้ค่า User-Agent อย่าง “GoodMoodle-VCFleet/1.0” เพื่อพรางตัวให้ดูเหมือนกิจกรรมปกติของ VMware เอง เนื่องจาก VCF Fleet คือความสามารถบริหารจัดการแบบรวมศูนย์ที่ Broadcom เพิ่งใส่มาใน VMware Cloud Foundation เวอร์ชัน 9.0

อย่างไรก็ตาม QUIRSO ระบุว่าไม่พบความทับซ้อนระหว่างกิจกรรมชุดนี้กับสายเหตุการณ์ที่ใช้ CVE-2026-59310 บนเครื่องเดียวกันซึ่งเริ่มวันที่ 3 สิงหาคม และบัญชีผู้ดูแลระบบชื่อ “vcenter_admin” ที่ถูกสร้างขึ้นก็ไม่ได้ถูกนำไปใช้ในขั้นตอนถัดไปของการโจมตี นั่นแปลว่าบนเครื่องเดียวกันอาจมีผู้เล่นมากกว่าหนึ่งรายหรืออย่างน้อยก็มีปฏิบัติการที่แยกจากกัน ซึ่งเป็นรายละเอียดที่ผู้ดูแลระบบไม่ควรมองข้ามเวลาสอบสวนเหตุการณ์จริง

ต่อมาในวันที่ 14 สิงหาคม 2569 QUIRSO เผยแพร่การวิเคราะห์เพิ่มเติมว่าพบคลังโค้ดบน GitHub ชื่อ “pikpak0066/tmpclean” ที่เชื่อมโยงกับผู้โจมตีรายเดียวกัน เมื่อดูผิวเผินมันคือโปรแกรมภาษา Go สำหรับลบไฟล์เก่าในไดเรกทอรีชั่วคราวของ Linux โดยอัตโนมัติ นาย Szadkowski อธิบายว่า “เราพบคลังโค้ดนี้ตั้งแต่แรกเพราะสังเกตเห็นผู้โจมตีตั้งค่ามันผ่านคำสั่ง link ของโครงสร้างพื้นฐาน reverse_ssh ที่เราเฝ้าติดตามอยู่ จากนั้นเราจึงวิเคราะห์และย้อนรอยไฟล์ไบนารีที่เผยแพร่ในรีลีสของคลังโค้ด ซึ่งยืนยันได้อย่างเป็นอิสระว่าไฟล์เหล่านั้นคือ reverse_ssh ที่สร้างขึ้นและผูกกับโครงสร้างพื้นฐานของผู้โจมตี” ตัวโปรแกรมทำงานเป็นเซอร์วิส systemd ที่กวาดโฟลเดอร์ /tmp แล้วลบทุกอย่างที่มีเวลาแก้ไขเก่ากว่า 24 ชั่วโมงทุก ๆ หนึ่งชั่วโมง และเนื่องจากสิ่งประดิษฐ์ของการบุกรุกส่วนใหญ่ถูกวางไว้ที่ /tmp จึงเชื่อกันว่าเครื่องมือนี้ถูกใช้เพื่อลบหลักฐานอย่างเป็นระบบ

รายละเอียดช่องโหว่

กิจกรรมแรกของการใช้ CVE-2026-59310 คือ cron daemon บันทึกไฟล์ cron ที่ผิดรูปแบบชื่อ “zz-poc59310-syslog.log” ขั้นต่อมาจึงมีการรันคำสั่ง curl หรือ wget เพื่อดึงแบ็กดอร์จาก 5.34.177[.]38:9861 มารันแล้วลบไฟล์ล็อกทิ้ง ชื่อไฟล์เป็นเบาะแสสำคัญเพราะอ้างถึงหมายเลข CVE ตรง ๆ และบ่งชี้ว่าเป็นโค้ดสาธิตที่เขียนขึ้นหลังรายละเอียดช่องโหว่ถูกเปิดเผยต่อสาธารณะแล้ว QUIRSO อธิบายว่า “ส่วนต่อท้าย ‘-syslog.log’ เลียนแบบรูปแบบการตั้งชื่อไฟล์ syslog ระยะไกลของ vCSA แต่ไฟล์กลับไปโผล่ที่ /etc/cron.d แทนที่จะเป็นไดเรกทอรีปลายทางของ syslog ที่ตั้งค่าไว้ ซึ่งบ่งชี้ว่าเซิร์ฟเวอร์ syslog ของ vCSA ถูกใช้เป็นช่องทางวางไฟล์ลงในตำแหน่งที่มีสิทธิ์รันโค้ด”

แบ็กดอร์ linuxFile ถูกออกแบบมาให้ผู้โจมตีสั่งรันคำสั่งจากระยะไกลได้ โดยเชื่อมต่อกับตัวควบคุมผ่านช่องทาง WebSocket เพื่อรับคำสั่ง แล้วรันผ่าน /bin/sh ก่อนส่งผลลัพธ์กลับ นาย Szadkowski อธิบายเพิ่มว่า “ที่อยู่ C2 ถูกอำพรางด้วย XOR และถอดรหัสตอนรันไทม์ ส่วนการสื่อสารได้รับการปกป้องด้วยกลไกเข้ารหัสระดับแอปพลิเคชันของมัลแวร์เอง แม้จะรับส่งผ่าน ws:// ที่ไม่เข้ารหัสก็ตาม นอกจากนี้มันยังเชื่อมต่อใหม่อัตโนมัติเมื่อล้มเหลว และมีรูทีนสำหรับตั้งค่าการคงอยู่ผ่าน systemd และ cron”

ผู้โจมตีอาศัย cron อย่างหนักในการรันเพย์โหลด ทั้งการดึงสคริปต์เชลล์ชื่อ “esxi.sh” จาก 185.144.28[.]120:3232 ซึ่งทำหน้าที่เป็นตัวดาวน์โหลดและตัวติดตั้งการคงอยู่ให้ไบนารี reverse_ssh ที่ตรงกับสถาปัตยกรรมของเครื่อง และ cronjob อื่น ๆ ที่สร้างไดเรกทอรีพักไฟล์ ดาวน์โหลดไฟล์ปฏิบัติการ เปลี่ยนสิทธิ์ แล้วสั่งรัน โดยอ้างอิงเซิร์ฟเวอร์ที่ 192.255.141[.]13:8080 และ 5.34.176[.]100:5244 ซึ่งเครื่องหลังนี้ถือเป็นความพลาดด้านความปลอดภัยเชิงปฏิบัติการของผู้โจมตีเอง เพราะเปิดชุดไบนารี reverse_ssh ให้เห็นผ่านหน้ารายการไดเรกทอรีของ AList

การกระทำที่ QUIRSO บันทึกไว้มีดังนี้

• ปล่อย “linuxFile” (มีชื่ออื่นว่า systemlog หรือ linux_x86) ที่เชื่อมต่อไปยัง ws://intel.se9ly9upbhay.shop:8080/ws และคงอยู่ผ่านเซอร์วิส systemd
• ตั้ง cronjob สามชุดที่ปลอมเป็นบริการของ VMware ได้แก่ vmware-vpxd-stats-* ซึ่งเปิดช่องทางเข้าถึงระยะไกลผ่าน SSH ด้วยการเพิ่มกุญแจสาธารณะของผู้โจมตีลงในไฟล์ authorized keys, vmware-perf-collect-* ซึ่งวางเว็บเชลล์ JSP ชื่อ “vmware-perf-update.jsp” และ vmware-perf-sync-* ซึ่งวางเว็บเชลล์ตัวเดียวกันพร้อมรันสคริปต์เข้ารหัส Base64 ที่ขโมยข้อมูลยืนยันตัวตนและตั้งบัญชีใหม่ชื่อ “adminuser” แล้วเพิ่มเข้ากลุ่ม vSphere SSO Administrators
• สร้างบัญชีเพิ่มอีกสองบัญชี คือเพิ่ม “vcadmin” เข้า vSphere ด้วยสคริปต์ Python ที่เข้ารหัส Base64 และวางบนดิสก์ผ่านคำสั่ง bash ใน cronjob และสร้างบัญชีผู้ดูแล vSphere ผ่านการดำเนินการ LDAP “Add” จากภายนอกไปยัง VMware Directory Service ของ vCenter โดยใช้บัญชีผู้ดูแลระบบเดิมที่ถูกยึดไปแล้ว
• สร้างไฟล์ /etc/sudoers.d/vmware-perf ที่ให้บัญชีบริการ “perfcharts” ใช้ sudo เป็น root ได้แบบไม่จำกัดและไม่ต้องใส่รหัสผ่าน
• รันสคริปต์อย่าง /tmp/.vmware-perf-upd.sh เพื่อดึงข้อมูลยืนยันตัวตนของ vmdir จากรีจิสทรี HKEY_THIS_MACHINE\services\vmdir และถ้าวิธีนี้ล้มเหลวจะหันไปเรียกโมดูล Python ชื่อ vmafd ของ VMware ผ่านฟังก์ชัน GetMachineName(), GetMachinePassword() และ GetDomainName() เพื่อเอาชื่อและรหัสผ่านของบัญชีเครื่อง vCenter ไปแก้ไขไดเรกทอรีระดับสิทธิ์สูง
• ใช้ vSphere API สำรวจสภาพแวดล้อม และใช้ “esxi.sh” ติดตั้งไคลเอนต์ reverse_ssh
• สร้างบัญชีท้องถิ่นบนโฮสต์ ESXi เช่น “adminuser” เพื่อเปิดทางให้แรนซัมแวร์เข้ารหัสไฟล์ได้

ปลายทางคือแรนซัมแวร์บนโฮสต์ ESXi ที่เข้ารหัสไฟล์ด้วยนามสกุล .babyk ซึ่งมักผูกกับแรนซัมแวร์ที่ต่อยอดจากซอร์สโค้ด Babuk แต่ยังไม่ชัดว่านี่คือเป้าหมายสุดท้ายของปฏิบัติการ หรือเพย์โหลดนี้ถูกเลือกมาใช้ “แบบฉวยโอกาสหรือกระทั่งจงใจ” เพื่อทำให้การชี้ตัวผู้โจมตีสับสน โดยนาย Szadkowski เปรียบเทียบว่าการปล่อยแรนซัมแวร์ครั้งนี้เหมือนม่านควันที่ออกแบบมาเบี่ยงเบนความสนใจของฝ่ายป้องกันออกจากการบุกรุกหลัก และขัดขวางการวิเคราะห์ด้วยการเข้ารหัสไฟล์ล็อกของ ESXi ทำให้เข้าถึงข้อมูลเทเลเมทรีที่จะบอกได้ว่าผู้โจมตีทำอะไรบ้างไม่ได้

ผลกระทบ

องค์กรที่รับความเสี่ยงตรงที่สุดคือผู้ที่เปิด vCenter Server สู่อินเทอร์เน็ตและยังไม่ได้ติดตั้งแพตช์ของวันที่ 29 กรกฎาคม 2569 เพราะการใช้ CVE-2026-59310 ให้สิทธิ์รันโค้ดระดับ root แบบไม่ต้องโต้ตอบบนตัวเครื่อง vCSA ทันที ทีมวิจัยสรุปไว้ตรง ๆ ว่า “คำสั่งที่ CROND บันทึกไว้หลังจากนั้นจึงถูกรันด้วยสิทธิ์ root อยู่แล้ว ทำให้ผู้โจมตีเข้าถึง VCSA ได้อย่างไม่จำกัด โดยไม่ต้องยึดบัญชีท้องถิ่นที่ไม่มีสิทธิ์แล้วยกระดับขึ้นมาก่อน” ในทางปฏิบัติแปลว่าเมื่อ vCenter แตก ระบบเสมือนทั้งฟาร์มที่มันดูแลอยู่ก็อยู่ในมือผู้โจมตีไปด้วย

ขนาดของการโจมตี 361 ไอพีใน 47 ประเทศ เมื่อเทียบกับช่วงเวลาเพียงห้าวันหลังการเปิดเผยช่องโหว่ แสดงให้เห็นว่าหน้าต่างเวลาระหว่างแพตช์ออกกับการถูกโจมตีจริงสั้นลงจนแทบไม่เหลือช่องให้วางแผนล่วงหน้า และการที่ผู้โจมตีตั้งชื่อไฟล์อ้างหมายเลข CVE ตรง ๆ บ่งชี้ว่าโค้ดสาธิตสาธารณะถูกหยิบไปประกอบเป็นเครื่องมือโจมตีได้เร็วมาก

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

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

คำแนะนำ

• ติดตั้งแพตช์ของ Broadcom สำหรับ CVE-2026-59310 และ CVE-2026-59309 ทันทีหากยังไม่ได้ทำ และถือว่าเครื่อง vCenter ที่เปิดสู่อินเทอร์เน็ตและยังไม่ได้แพตช์ตั้งแต่ต้นเดือนสิงหาคมคือเครื่องที่ต้องสอบสวนย้อนหลัง ไม่ใช่แค่แพตช์แล้วจบ
• ตรวจ /etc/cron.d และ crontab ทั้งหมดบน vCSA หา cronjob ที่ตั้งชื่อเลียนบริการของ VMware โดยเฉพาะรูปแบบ vmware-vpxd-stats-*, vmware-perf-collect-* และ vmware-perf-sync-* รวมถึงไฟล์ล็อกผิดรูปแบบที่ขึ้นต้นด้วย zz-
• ตรวจสอบบัญชีผู้ใช้ทั้งบน vCenter และโฮสต์ ESXi หาบัญชีที่ไม่ได้สร้างโดยทีมงาน โดยเฉพาะชื่ออย่าง vcenter_admin, vcadmin และ adminuser รวมถึงสมาชิกที่ถูกเพิ่มเข้ากลุ่ม vSphere SSO Administrators
• ตรวจไฟล์ /etc/sudoers.d/ หารายการที่ให้บัญชีบริการอย่าง perfcharts ใช้ sudo แบบไม่ต้องใส่รหัสผ่าน และตรวจไฟล์ authorized keys ของทุกบัญชีหากุญแจ SSH ที่ไม่รู้จัก
• ค้นหาเว็บเชลล์ JSP ที่ชื่อคล้ายบริการของ VMware เช่น vmware-perf-update.jsp และไฟล์ซ่อนใน /tmp ที่ขึ้นต้นด้วยจุด เช่น .vmware-perf-upd.sh
• ส่งล็อกของ vCenter และ ESXi ออกไปเก็บนอกเครื่องแบบเรียลไทม์ เพราะผู้โจมตีชุดนี้ทั้งเข้ารหัสล็อกและใช้เครื่องมือกวาด /tmp ทุกชั่วโมงเพื่อทำลายหลักฐาน
• หมุนเวียนข้อมูลยืนยันตัวตนของบัญชีเครื่อง vCenter และบัญชีผู้ดูแลทั้งหมดหลังพบการบุกรุก เพราะผู้โจมตีมีเส้นทางดึงรหัสผ่านของ vmdir ได้หลายทาง
• เฝ้าระวังการเชื่อมต่อขาออกไปยังไอพีและโดเมนในตาราง IoC ด้านล่าง และพิจารณาบล็อกทราฟฟิก WebSocket ขาออกจากเครื่องบริหารจัดการที่ไม่ควรมีเหตุผลต้องเชื่อมต่อออกอินเทอร์เน็ต

Indicators of Compromise (IoCs)

ตัวบ่งชี้ต่อไปนี้เรียบเรียงจากรายงานของ QUIRSO ที่ถูกอ้างในบทความต้นทาง โดยไอพีและโดเมนถูก defang ไว้แล้วเพื่อป้องกันการเชื่อมโยงโดยไม่ตั้งใจ ให้แปลงกลับเฉพาะในระบบข่าวกรองภัยคุกคามที่ควบคุมได้เท่านั้น

แหล่งอ้างอิง

• Suspected China-Nexus Actor Exploits VMware vCenter Flaw, Deploys Babuk-Derived Ransomware — The Hacker News
• คลังโค้ด pikpak0066/tmpclean บน GitHub ที่เชื่อมโยงกับผู้โจมตี
• Cloud Thunder — Broadcom แพตช์ช่องโหว่ VMware 3 รายการวิกฤต (โพสต์ 2026/07/300)