ผู้ไม่ประสงค์ดีดำเนินการ BGP Hijack เพื่อเปลี่ยนเส้นทาง Traffic ของ Softaculous ระหว่างวันที่ 28-30 สิงหาคม 2026 และส่งอัปเดต Virtualizor ที่แฝง Payload อันตรายไปยัง Hypervisor Server บางส่วน ตามรายงานเหตุการณ์อย่างเป็นทางการจากผู้ให้บริการ เนื่องจาก Virtualizor เป็นระบบจัดการ VPS ระดับ Master ที่ควบคุม Hypervisor ได้หลายร้อยเครื่อง เหตุการณ์นี้จึงถือเป็นการโจมตีที่กระทบโครงสร้างพื้นฐานของผู้ให้บริการ Hosting ในวงกว้าง ไม่ใช่เพียงเว็บไซต์เดียว
รายละเอียดการโจมตี
กลไกของ BGP Hijack
ผู้โจมตีใช้ AS62390 (NexonHost) ประกาศเส้นทาง 162.55.80.0/24 ซึ่งเป็น IP Range ของ Hetzner ที่ Softaculous ใช้สำหรับระบบอัปเดตและ Billing ผ่าน AS6204 (Zet.net) โดยปกติ Hetzner ประกาศเพียงเส้นทางกว้าง 162.55.0.0/16 เท่านั้น การที่ผู้โจมตีประกาศ Prefix ที่เฉพาะเจาะจงกว่า (/24) ทำให้เส้นทางปลอมนี้ชนะในเกือบทุกจุดที่แพร่กระจายไป ตามหลักการทำงานของ BGP Routing ที่ให้ความสำคัญกับเส้นทางที่เฉพาะเจาะจงที่สุด
การ Hijack เริ่มตั้งแต่ราว 20:57 UTC วันที่ 28 สิงหาคม จนถึง 06:10 UTC วันที่ 30 สิงหาคม ข้อมูลจาก RIPE RIS (Routing Information Service) แสดงให้เห็นว่า Collector Peer ทั้ง 368 จุด เคยรับเส้นทางปลอมนี้อย่างน้อยหนึ่งครั้งในช่วงเวลาดังกล่าว และในช่วงที่การ Hijack กำลัง Active อยู่ ราว 72% ของ Peer เหล่านั้นเลือกเส้นทางผ่าน AS62390 เป็น Best Path การโจมตีมีลักษณะเป็นคลื่น (Flapping) 2 ช่วง รวมเวลาประมาณ 22 ชั่วโมง โดยมีช่วงพักราว 11 ชั่วโมงคั่นกลาง หลังจาก Hetzner ประกาศเส้นทาง /24 ของตนเองกลับคืนราว 08:50 UTC วันที่ 29 สิงหาคม
การขอใบรับรอง TLS ที่ถูกต้องผ่านเส้นทางที่ถูกเปลี่ยน
ระหว่างที่ Traffic ถูกเปลี่ยนเส้นทาง ผู้โจมตีสามารถผ่านกระบวนการ Let's Encrypt Domain Validation และได้รับใบรับรอง TLS ที่ถูกต้องตามกฎหมายสำหรับโดเมน virtualizor.com, api.virtualizor.com และ files.virtualizor.com ซึ่งเป็นโดเมนที่ให้บริการ Softaculous Client Area ด้วย ทำให้ผู้ใช้งานที่เข้าสู่ระบบในช่วงเวลานั้นไม่เห็น TLS Warning ใดๆ และอาจมี Credential รั่วไหลไปยังผู้โจมตีโดยไม่รู้ตัว
จุดอ่อนที่ทำให้การโจมตีสำเร็จ: ไม่มีการตรวจสอบ Package ด้วย Signature
Virtualizor ยอมรับว่า Update Client ของตนไม่มีการตรวจสอบ Package ด้วย Cryptographic Signature ซึ่งหมายความว่าการทำ BGP Hijack ที่รวมกับใบรับรอง TLS ที่ถูกต้องเพียงพอให้โค้ดของผู้โจมตีรันบน Server เป้าหมายด้วยสิทธิ์ Root ได้ทันที อย่างไรก็ตาม เนื่องจากการเปลี่ยนเส้นทางมีลักษณะไม่ต่อเนื่อง (พบการ Withdraw เส้นทางราว 10,600 ครั้ง) ทำให้มีเพียง Server จำนวนหนึ่งที่เช็คอัปเดตในช่วงเวลาที่ถูกเปลี่ยนเส้นทางพอดีเท่านั้นที่ได้รับ Payload อันตราย
ขอบเขตผลกระทบและสถานะการตรวจสอบ
เนื่องจาก Server ของผู้โจมตีไม่เคยปรากฏใน Log ของ Vendor ทำให้ Virtualizor Host ทุกเครื่องควรถูกพิจารณาว่าอยู่ในขอบเขตความเสี่ยง จนกว่าจะมีการตรวจสอบยืนยัน ปัจจุบันยังไม่พบหลักฐานว่า Webuzo, Softaculous, Backuply หรือ SitePad ได้รับ Package ที่เป็นอันตราย และยังไม่พบหลักฐานว่า VPS Guest ถูกแก้ไขโดยตรง แต่เนื่องจาก Virtualizor Master อยู่เหนือ VPS Instance ทั้งหมดในเครื่อง Hypervisor ที่ถูกบุกรุก จึงไม่สามารถสรุปได้ว่าผลกระทบจำกัดอยู่เพียงระดับ Control Panel เท่านั้น
Indicator ที่ยืนยันแล้ว: ไฟล์ /etc/systemd/system/java-jre-update.service — Virtualizor แนะนำให้ Operator ที่พบไฟล์นี้ติดต่อ Vendor ก่อนดำเนินการใดๆ แทนการลบทิ้งทันที เพื่อรักษาหลักฐานสำหรับการตรวจสอบ
ผลกระทบที่อาจเกิดขึ้น
- Virtualizor เป็นระบบจัดการ VPS ระดับ Master ที่ควบคุม Hypervisor Server บน KVM, Xen, LXC, OpenVZ และ Proxmox ได้หลายร้อยเครื่องพร้อมกัน การถูกบุกรุกจึงวางตำแหน่งสูงในสถาปัตยกรรม Hosting ทำให้ผลกระทบขยายวงกว้างกว่าการบุกรุกระบบเดี่ยวทั่วไป
- Hypervisor ที่ถูกบุกรุกด้วยสิทธิ์ Root ทำให้ทุก VPS Guest บนเครื่องนั้นมีความเสี่ยง แม้ยังไม่พบหลักฐานว่า Guest ถูกแก้ไขโดยตรง แต่ผู้ดูแลระบบไม่สามารถสันนิษฐานได้ว่าผลกระทบจำกัดอยู่ที่ระดับ Control Panel เท่านั้น
- ผู้ที่ Login เข้า Softaculous Client Area ระหว่างช่วงเวลาที่ถูกเปลี่ยนเส้นทางอาจมี Credential รั่วไหล เนื่องจากใบรับรอง TLS ที่ถูกต้องทำให้ผู้ใช้งานไม่มีสัญญาณเตือนใดๆ ระหว่างการโจมตี
- การที่ Server ของผู้โจมตีไม่เคยปรากฏใน Log ของ Vendor ทำให้ยากต่อการระบุขอบเขตผลกระทบที่แท้จริง ผู้ให้บริการ Hosting ที่ใช้ Virtualizor จึงต้องดำเนินการตรวจสอบเชิงรุกแทนการรอการยืนยันจาก Vendor เพียงอย่างเดียว
สิ่งที่องค์กรควรทำ
- ตรวจสอบ Server ทุกเครื่องที่รัน Virtualizor ว่ามีไฟล์
/etc/systemd/system/java-jre-update.serviceหรือไม่ หากพบ ให้ติดต่อ Vendor ก่อนดำเนินการใดๆ เพื่อรักษาหลักฐานและรับคำแนะนำที่ถูกต้อง - Rotate API Key ทั้งหมดที่เกี่ยวข้องกับ Virtualizor และ Softaculous พร้อมล็อกการเข้าถึง SSH และ API ให้เฉพาะ IP Address ที่เชื่อถือได้เท่านั้น
- ตรวจสอบบัญชีผู้ใช้ SSH Key และ Scheduled Job ที่ไม่รู้จักบน Server ทุกเครื่องที่เกี่ยวข้อง โดยเฉพาะเครื่องที่อาจเช็คอัปเดตในช่วงวันที่ 28-30 สิงหาคม 2026
- ผู้ที่เคย Login เข้า Softaculous Client Area ระหว่างช่วงเวลาดังกล่าวควรเปลี่ยนรหัสผ่านและสร้าง API Key ใหม่ทันที เนื่องจาก Credential อาจรั่วไหลผ่านเส้นทางที่ถูกเปลี่ยนโดยไม่มีสัญญาณเตือนใดๆ
แนวทางลดความเสี่ยงระยะยาว
1. บังคับใช้การตรวจสอบ Package ด้วย Cryptographic Signature สำหรับระบบ Update ที่มีสิทธิ์สูงทุกระบบ
เหตุการณ์นี้แสดงให้เห็นชัดเจนว่าการพึ่งพาเพียง TLS/HTTPS ไม่เพียงพอต่อการยืนยันความถูกต้องของ Package หากผู้โจมตีสามารถควบคุมเส้นทาง Network ได้ ระบบที่มีสิทธิ์สูงอย่าง Hypervisor Management Software ควรตรวจสอบลายเซ็นของ Package ก่อนติดตั้งเสมอ
2. ติดตาม Route Monitoring และ RPKI (Resource Public Key Infrastructure) สำหรับ IP Range สำคัญขององค์กร
BGP Hijack เป็นภัยคุกคามระดับโครงสร้างพื้นฐานที่ตรวจจับได้ยากด้วยเครื่องมือทั่วไป การใช้บริการ Route Monitoring และการนำ RPKI มาใช้ช่วยลดโอกาสที่เส้นทางปลอมจะถูกยอมรับอย่างแพร่หลาย
3. ทบทวนสถาปัตยกรรมการจัดการ Hosting Infrastructure ที่มี Single Point of Control สูง
ระบบจัดการระดับ Master ที่ควบคุม Server จำนวนมากพร้อมกันควรมีมาตรการป้องกันเพิ่มเติมมากกว่าระบบทั่วไป เนื่องจากการบุกรุกจุดเดียวสามารถขยายผลกระทบไปยังโครงสร้างพื้นฐานทั้งหมดได้
4. จัดทำแผน Incident Response เฉพาะสำหรับกรณี Supply Chain หรือ Update Mechanism ถูกบุกรุก
เนื่องจากการโจมตีลักษณะนี้อาศัยช่องทางที่องค์กรมักไว้วางใจ (กระบวนการอัปเดตซอฟต์แวร์) แผนตอบสนองควรครอบคลุมการตรวจสอบ Integrity ของระบบหลังพบสัญญาณผิดปกติ ไม่ใช่เพียงการแพตช์ช่องโหว่ตามปกติ
วิเคราะห์ในมุมมองจาก TXEC
เหตุการณ์นี้เป็นตัวอย่างที่ชัดเจนของความเสี่ยงที่ TXEC ให้ความสำคัญมาโดยตลอด นั่นคือการโจมตีที่มุ่งเป้าไปยังกลไกความไว้วางใจพื้นฐานของระบบ ในกรณีนี้คือกระบวนการ Update Software ที่องค์กรส่วนใหญ่มักไม่ตั้งคำถามถึงความถูกต้อง การที่ผู้โจมตีสามารถใช้ BGP Hijack ร่วมกับใบรับรอง TLS ที่ถูกต้องตามกฎหมายเพื่อผ่านการป้องกันที่ดูเหมือนแข็งแกร่ง สะท้อนให้เห็นว่า TLS เพียงอย่างเดียวไม่ใช่หลักประกันความปลอดภัยที่สมบูรณ์ หากปราศจากการตรวจสอบ Package Integrity ในชั้นถัดไป
TXEC มองว่าองค์กรที่พึ่งพา Third-party Control Panel หรือระบบจัดการ Infrastructure ระดับ Master ควรตั้งคำถามกับ Vendor เกี่ยวกับกลไกการตรวจสอบความถูกต้องของ Update อย่างจริงจัง โดยเฉพาะระบบที่มีสิทธิ์ควบคุมสูงและกระทบ Server จำนวนมากพร้อมกัน เหตุการณ์นี้ควรเป็นจุดเริ่มต้นให้ผู้ให้บริการ Hosting และองค์กรที่ใช้ระบบจัดการลักษณะเดียวกันทบทวนมาตรการ Defense-in-depth ในกระบวนการ Software Update ของตนเองอย่างจริงจัง
รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า
[ แหล่งอ้างอิง: Cyber Security News, Virtualizor Security Incident Report ]