CVE-2026-59310 เปิดโปงแคมเปญโจมตี VMware vCenter ที่ต้องมองไกลกว่าการแพตช์

CVE-2026-59310 ไม่ใช่แค่ช่องโหว่ที่ต้องรีบติดตั้งแพตช์อีกต่อไป แต่กลายเป็นช่องทางที่ถูกใช้เจาะระบบ VMware vCenter อย่างรวดเร็ว Broadcom เปิดเผยช่องโหว่และออกแพตช์เมื่อวันที่ 29 กรกฎาคม 2026 ทว่านักวิจัยพบสัญญาณการโจมตีตั้งแต่วันที่ 3 สิงหาคม หรือเพียง 5 วันให้หลัง

แคมเปญดังกล่าวเชื่อมโยงกับ IP ที่พบว่าถูกโจมตี 361 รายการใน 47 ประเทศ และใช้ reverse SSH เพื่อรักษาช่องทางเข้าถึงระบบอย่างต่อเนื่อง Shadowserver ระบุว่า vCenter ที่พบกลไกดังกล่าวควรถูกถือว่า “ถูกเจาะเต็มรูปแบบ”

CVE-2026-59310 คืออะไร และอันตรายแค่ไหน

Broadcom และ National Vulnerability Database (NVD) อธิบายว่า CVE-2026-59310 เป็นช่องโหว่ประเภท directory traversal ใน Syslog Server ของ vCenter ซึ่งทำให้ผู้โจมตีที่เข้าถึง vCenter ผ่านเครือข่ายสามารถส่งคำขอที่หลบออกนอกเส้นทางไฟล์ที่ควรได้รับอนุญาต และนำไปสู่การสั่งรันโค้ดใด ๆ บนระบบได้โดยไม่ต้องยืนยันตัวตน ช่องโหว่นี้มีคะแนน CVSS 9.8 อยู่ในระดับวิกฤต

ในทางปฏิบัติ vCenter ที่เปิดให้เข้าถึงจากอินเทอร์เน็ตหรือจากเครือข่ายภายในที่กว้างเกินไป อาจถูกเปลี่ยนจากระบบบริหารโครงสร้างพื้นฐานเสมือนให้กลายเป็นจุดเริ่มต้นของการฝังช่องทางลับและขยายการเข้าถึงไปยังระบบเสมือนอื่น ๆ ได้

มีรายงานบางส่วนระบุว่าการรันโค้ดบนอุปกรณ์เกิดขึ้นในบริบทสิทธิ์ระดับ root แต่คำอธิบายจากผู้ผลิตและฐานข้อมูลช่องโหว่ที่เป็นทางการยืนยันในวงกว้างถึงความเสี่ยงจาก arbitrary code execution มากกว่าจะยืนยันสิทธิ์ของทุกเหตุการณ์โจมตีเป็นกรณี ๆ ไป

Broadcom ระบุแพตช์เวอร์ชันที่แก้ไขแล้ว แต่ไม่มีวิธีแก้ชั่วคราว ดังนั้นการอัปเดตตามเวอร์ชันที่ผู้ผลิตกำหนดจึงเป็นวิธีแก้ไขอย่างเป็นทางการเพียงทางเดียว

ไทม์ไลน์ที่น่ากังวล: ออกแพตช์ก่อน แต่ถูกโจมตีหลังจากนั้น 5 วัน

Broadcom เปิดเผย CVE-2026-59310 และออกแพตช์เมื่อวันที่ 29 กรกฎาคม ขณะที่ QUIRSO รายงานว่าพบการเริ่มโจมตีตั้งแต่วันที่ 3 สิงหาคม ก่อนกิจกรรมจะขยายตัวอย่างรวดเร็วในเวลาต่อมา

ประเด็นนี้มีความสำคัญต่อการตอบสนองเหตุการณ์ เพราะระบบที่ติดตั้งแพตช์หลังวันที่ 3 สิงหาคมไม่ควรถูกสรุปว่า “ปลอดภัยแล้ว” เพียงเพราะการอัปเดตเสร็จสมบูรณ์

ผู้ดูแลระบบต้องแยก 2 งานออกจากกันให้ชัดเจน ได้แก่ การปิดช่องโหว่ด้วยแพตช์ และการตรวจสอบว่าผู้โจมตีได้เข้ามาฝังตัวไว้ก่อนหน้านั้นหรือไม่

ขอบเขตของแคมเปญ: 361 IP ใน 47 ประเทศ

นักวิจัยเชื่อมโยงกิจกรรมนี้กับ IP ที่พบว่าถูกโจมตี 361 รายการใน 47 ประเทศ โดยเยอรมนี สหรัฐฯ ตุรกี อิหร่าน และฝรั่งเศสคิดเป็นมากกว่าครึ่งหนึ่งของชุดข้อมูลที่สังเกตพบ

อย่างไรก็ตาม ตัวเลขนี้ต้องอ่านอย่างระมัดระวัง เพราะ 1 IP ไม่ได้หมายความว่าเป็น 1 บริษัทหรือ 1 หน่วยงานเสมอไป จึงไม่สามารถสรุปได้ว่ามีองค์กรที่ตกเป็นเหยื่อ 361 แห่ง ตัวเลขดังกล่าวสะท้อน IP ที่ตรวจพบและเชื่อมโยงกับระบบ vCenter ที่ถูกบุกรุกเท่านั้น

ถึงกระนั้น รายงานที่มีอยู่ก็ชี้ให้เห็นว่าแคมเปญนี้มีขอบเขตกว้าง และมุ่งเป้าไปยังระบบ vCenter ที่เข้าถึงได้จากอินเทอร์เน็ตหรือถูกเปิดให้เครือข่ายอื่นเข้าถึงได้

ทำไมจึงถูกประเมินว่าอาจมีความเชื่อมโยงกับจีน

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

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

ดังนั้น คำอธิบายที่รัดกุมที่สุดในตอนนี้คือ “ผู้โจมตีที่สงสัยว่ามีความเชื่อมโยงกับจีน” ไม่ใช่ปฏิบัติการที่ยืนยันแล้วว่าได้รับการสนับสนุนจากรัฐ การระบุแหล่งที่มาจากภาษา เครื่องมือ เวลาโจมตี และรูปแบบเหยื่ออาจเปลี่ยนแปลงได้เมื่อมีหลักฐานเพิ่มเติม

ลำดับการโจมตีที่มีการรายงาน

จากข้อมูลที่เผยแพร่ แคมเปญน่าจะใช้ CVE-2026-59310 เพื่อเข้ารันโค้ดในระยะแรก ก่อนติดตั้งกลไกคงอยู่และเครื่องมือเข้าถึงหลายชั้น ดังนี้

1. Directory traversal: ผู้โจมตีส่งคำขอที่สร้างขึ้นเป็นพิเศษไปยังบริการ Syslog เพื่อหลบออกจากเส้นทางที่กำหนดและเขียนข้อมูลที่ผู้โจมตีควบคุมได้
2. การคงอยู่ผ่าน cron: มีรายงานว่าผู้โจมตีสร้างรายการ cron ที่ผิดรูปแบบ เพื่อให้คำสั่งต่อเนื่องถูกเรียกใช้ตามกำหนดเวลา
3. การส่งแบ็กดอร์: มีการใช้ curl หรือ wget ดาวน์โหลดแบ็กดอร์ชื่อ linuxFile ซึ่งใช้ WebSocket และการทำให้สตริงสับสนด้วย XOR ตามรายงานเหตุการณ์ที่ตรวจพบ
4. Reverse SSH: ผู้โจมตีติดตั้งเครื่องมือ reverse SSH เพื่อสร้างการเชื่อมต่อขาออกกลับไปยังโครงสร้างพื้นฐานที่ควบคุมโดยผู้โจมตี Shadowserver รายงานว่ากลไกนี้พบในเหยื่อทั้งหมดในรายงานพิเศษขององค์กร
5. การใช้บัญชีและข้อมูลรับรอง: นักสืบสวนรายงานการสร้างบัญชีผู้ดูแล vCenter และ ESXi ที่ไม่ได้รับอนุญาต รวมถึงการใช้ข้อมูลรับรองของ VMware Directory Service
6. การติดตั้งแรนซัมแวร์: รายงานอย่างน้อยบางส่วนเชื่อมโยงกิจกรรมนี้กับแรนซัมแวร์ดัดแปลงจาก Babuk ซึ่งเติมนามสกุล .babyk ให้ไฟล์

ประเด็น reverse SSH มีความสำคัญเป็นพิเศษ เพราะเป็นช่องทางให้ผู้โจมตีเชื่อมต่อกลับเข้าระบบได้ แม้ผู้ดูแลจะลบไฟล์บางส่วนหรือปิดช่องโหว่ไปแล้วก็ตาม Shadowserver จึงสรุปในเชิงปฏิบัติว่าระบบที่ติดตั้งกลไกนี้ควรถูกถือว่า “ถูกเจาะเต็มรูปแบบ”

การลบไบนารีหรือลบ cron job เพียงอย่างเดียวจึงไม่เพียงพอ องค์กรควรสร้างความน่าเชื่อถือของระบบขึ้นใหม่ และเปลี่ยนข้อมูลรับรองสิทธิ์สูงทั้งหมดตามกระบวนการรับมือเหตุการณ์ที่เป็นทางการ

แรนซัมแวร์อาจถูกใช้เพื่อกลบหลักฐาน

กิจกรรมที่เติมนามสกุล .babyk ไม่จำเป็นต้องหมายถึงแคมเปญแรนซัมแวร์แบบดั้งเดิมที่มุ่งเข้ารหัสข้อมูลจำนวนมากเพื่อเรียกค่าไถ่เสมอไป นักวิเคราะห์เสนอว่าการเข้ารหัสล็อกของ ESXi แบบเลือกเป้าหมาย อาจมีจุดประสงค์เพื่อขัดขวางการสืบสวนและซ่อนหลักฐานการบุกรุก

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

GitHub และการปลอมตัวเป็นเครื่องมือดูแลระบบ

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

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

ผลกระทบต่อ Broadcom และ VMware

หุ้น Broadcom ปรับตัวลงประมาณ 5–6% เมื่อวันที่ 14 สิงหาคม หลังข่าวการโจมตี VMware vCenter ที่กำลังเกิดขึ้นถูกเผยแพร่สู่ตลาด รายงานหนึ่งระบุว่าราคาหุ้นลดจาก 417.82 ดอลลาร์เหลือ 392.99 ดอลลาร์ภายในวันเดียว

อย่างไรก็ตาม ยังไม่ควรสรุปว่าการร่วงลงทั้งหมด หรือมูลค่าตลาดที่หายไปเป็นจำนวนเท่าใด เกิดจาก CVE-2026-59310 เพียงปัจจัยเดียว เพราะในช่วงเวลาเดียวกันยังมีรายงานความกังวลอื่นของนักลงทุน รวมถึงความเสี่ยงด้านหนี้ที่เกี่ยวข้องกับธุรกิจ AI

ปัจจุบันยังมีหลักฐานไม่เพียงพอที่จะสรุปว่าแคมเปญนี้ทำให้รายได้ VMware ลดลงอย่างวัดผลได้ ผลกระทบระยะใกล้ที่รองรับด้วยข้อมูลมากกว่าคือค่าใช้จ่ายในการแก้ไขระบบ ความเสี่ยงจากการหยุดชะงักของการดำเนินงาน และแรงกดดันต่อชื่อเสียงของผลิตภัณฑ์

แนวทางรับมือสำหรับผู้ดูแล vCenter

การติดตั้งแพตช์เป็นขั้นตอนแรก ไม่ใช่จุดสิ้นสุด องค์กรควรดำเนินการดังนี้

1. ติดตั้งแพตช์ของ Broadcom ทันที ให้กับ vCenter ที่ได้รับผลกระทบทุกเครื่อง โดยจัดลำดับความสำคัญให้ระบบที่เชื่อมต่ออินเทอร์เน็ต และระบบที่เข้าถึงได้จากเครือข่ายภายในวงกว้าง Broadcom ระบุว่าไม่มีวิธีแก้ชั่วคราว
2. ถือว่าระบบอาจถูกบุกรุกเมื่อพบตัวบ่งชี้ เช่น cron ถูกแก้ไขโดยไม่ทราบสาเหตุ ร่องรอย reverse SSH ไฟล์ linuxFile การดาวน์โหลดผ่าน curl หรือ wget ที่ไม่คาดคิด บัญชีผู้ดูแล vCenter หรือ ESXi ที่ไม่คุ้นเคย และกิจกรรมผิดปกติของ VMware Directory Service
3. แยกอุปกรณ์ที่น่าสงสัยออกจากเครือข่าย พร้อมเก็บภาพดิสก์ ล็อก และหลักฐานในหน่วยความจำก่อนสร้างระบบใหม่ หากข้อจำกัดด้านการปฏิบัติงานเอื้ออำนวย
4. เปลี่ยนข้อมูลรับรองสิทธิ์สูงทั้งหมด รวมถึง vCenter SSO, VMware Directory Service, ESXi หรือ root, บัญชี API, บัญชีบริการ และบัญชีผู้ดูแลที่เชื่อมโยงกัน พร้อมยกเลิกเซสชันที่ยังใช้งานอยู่และตรวจสอบเส้นทาง federation
5. สร้างระบบใหม่แทนการทำความสะอาดอย่างเดียว สำหรับระบบที่ยืนยันว่ามีกลไกคงอยู่ โดยรวมถึงการลบบัญชี cron job ไบนารี SSH key และ tunnel ที่ไม่ได้รับอนุญาตภายใต้กระบวนการรับมือเหตุการณ์ที่มีเอกสารกำกับ
6. ตรวจค้นทั่วโครงสร้างพื้นฐานเสมือน หาไฟล์หรือกิจกรรม .babyk การเชื่อมต่อ SSH หรือ WebSocket ขาออกที่ผิดปกติ บัญชีปลอม และร่องรอยการแก้ไขล็อกของ ESXi
7. กู้คืนข้อมูลและระบบติดตามจากแหล่งที่เชื่อถือได้ ใช้แบ็กอัปที่ทราบว่าไม่ถูกแก้ไขและไม่สามารถเปลี่ยนแปลงย้อนหลังได้ หากล็อกหรือการตั้งค่าถูกทำลาย
8. ลดการเปิดเผยในอนาคต จำกัดการเข้าถึงระบบบริหาร vCenter ให้อยู่บนเครือข่ายดูแลระบบที่แบ่งส่วน และตรวจสอบการเชื่อมต่อขาออกจาก vCenter กับ ESXi อย่างต่อเนื่อง

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