กลับไปหน้าข่าวสาร

Aurora Ransomware ยกระดับโจมตี ESXi ด้วย AI Agent ช่วยเจาะระบบ เข้ารหัส VM ด้วย ChaCha20+RSA-4096 พร้อมเครื่องมือค้นหาเป้าหมายอัตโนมัติ

แชร์:

ทีม Threat Intelligence จาก Gambit Security เปิดเผยรายละเอียดปฏิบัติการของกลุ่มเรียกค่าไถ่ Aurora ซึ่งเคลื่อนไหวมาตั้งแต่ประมาณเดือนเมษายน 2569 พบว่ากลุ่มนี้พัฒนา Ransomware สายพันธุ์ Linux ที่มีโหมดเฉพาะสำหรับโจมตีสภาพแวดล้อม VMware ESXi และที่น่าสนใจเป็นพิเศษคือการนำ AI Agent อย่าง Cursor Agent ที่รัน Claude Sonnet มาช่วยปฏิบัติการเจาะระบบแบบ Hands-on ในองค์กรเป้าหมายอย่างน้อย 10 แห่ง ระหว่างวันที่ 8 เมษายน ถึง 21 พฤษภาคม 2569 สะท้อนแนวโน้มการนำ AI Agent มาใช้เป็นเครื่องมือโจมตีจริงในภาคสนามมากขึ้นอย่างเป็นรูปธรรม


รายละเอียดมัลแวร์


Ransomware สายพันธุ์ ESXi


ตัวอย่างมัลแวร์ที่ตรวจพบชื่อ encrypt.out เป็นไฟล์ Linux ELF ขนาด 139 KB ทำงานโดยเข้ารหัสไฟล์ในที่เดิมด้วย ChaCha20 และห่อหุ้ม Session Key แต่ละตัวด้วย RSA-4096 Public Key ที่ฝังไว้ใน Binary ตัวมัลแวร์รองรับ Option การใช้งานที่ยืดหยุ่นหลายรูปแบบ รวมถึงการกำหนด Path เฉพาะ, เปอร์เซ็นต์ของไฟล์ที่จะเข้ารหัส, ขนาดไฟล์สูงสุดที่จะประมวลผล และจำนวน Thread ที่ใช้งาน


จุดเด่นที่สุดคือ Option -esxi ซึ่งเปิดใช้งาน ESXi Mode ที่เข้ารหัสเฉพาะไฟล์ VM ประเภท vmdk, vmx, vmsd, vmsn, nvram, vmem, vswp, log และข้าม System Volume ที่ขึ้นต้นด้วย BOOTBANK และ OSDATA โดยเจตนา เพื่อให้ Hypervisor ยังคงสามารถ Boot ได้ตามปกติ เปิดโอกาสให้เหยื่ออ่านข้อความเรียกค่าไถ่ได้


กลไกการเข้ารหัส VM


ในโหมด ESXi มัลแวร์ดำเนินการดังนี้


  1. รันคำสั่ง esxcli vm process list เพื่อรวบรวม World ID ของ Virtual Machine ที่กำลังทำงานอยู่ทั้งหมด
  2. สั่ง esxcli vm process kill --type=force --world-id=<world-id> เพื่อบังคับหยุด VM แต่ละตัว ซึ่งเป็นการปลดล็อก Virtual Disk File ที่ VM ที่กำลังทำงานถืออยู่
  3. เข้ารหัสไฟล์ VM ตามรายการนามสกุลที่กำหนดไว้ ขณะที่ข้าม System Volume ของ Hypervisor เอง


นอกจากนี้ มัลแวร์ยังเขียนข้อความเรียกค่าไถ่ลงใน /etc/ssh/sshd-banner ทำให้ผู้ที่เชื่อมต่อเข้าเครื่องผ่าน SSH เห็นข้อความเรียกค่าไถ่ปรากฏขึ้นก่อนหน้า Login Prompt โดยไม่ต้อง Login สำเร็จก่อน


เครื่องมือค้นหาเป้าหมาย ESXi


esxi_finder.py เป็น Custom NetExec LDAP Module ที่ออกแบบมาเพื่อค้นหา VMware ESXi Hypervisor และ vCenter Server ภายในเครือข่ายเหยื่อโดยเฉพาะ เครื่องมือนี้เรียนรู้ Subnet ภายในองค์กรผ่านการ Query Domain Controller ด้วย LDAP และ Resolve Computer Object หรือใช้ไฟล์ Range ที่ผู้ปฏิบัติการกำหนดเอง จากนั้นสแกน Port 443 และ 902 พร้อมอ่าน TLS Certificate เพื่อยืนยันลายเซ็นของ ESXi และดึงข้อมูลจาก /sdk, /ui/ และ / เพื่อระบุผลิตภัณฑ์และ Build ที่แน่นอน


การนำ AI Agent มาใช้ในการเจาะระบบ


ในบางเครือข่ายเป้าหมาย ผู้ปฏิบัติการ Aurora ใช้ Cursor Agent ที่รัน Claude Sonnet โดยมอบ Credential หรือช่องทางเข้าถึงที่มีอยู่แล้วให้ Agent ดำเนินงานเจาะระบบต่อ งานที่มอบหมายครอบคลุมทั้งการติดตั้งและตั้งค่า VPN Client หรือ Proxychains, การสแกน Subnet ภายในด้วย Nmap หรือ NetExec, การตรวจสอบสิทธิ์ของผู้ใช้ผ่าน BloodHound Collector ของ NetExec, ความพยายามโจมตี NTLM Relay ด้วยเทคนิค PetitPotam, Coerce Plus และ PrinterBug ร่วมกับ Impacket ntlmrelayx รวมถึงการโจมตี Certificate ด้วย Certipy


ที่น่าสังเกตคือคำสั่งส่วนใหญ่ที่มอบหมายให้ Agent ไม่สำเร็จในความพยายามครั้งแรก ต้องมีการปรับแก้คำสั่งและสคริปต์หลายรอบ บางงานสำเร็จในที่สุด ขณะที่บางงานล้มเหลวและได้เพียงรายงานผลกลับไปยังผู้โจมตี ผู้ปฏิบัติการยังกำหนดข้อจำกัดที่ชัดเจนและย้ำซ้ำกับ Agent ในทุกเหยื่อ ได้แก่ ห้ามทำ DCSync โดยเด็ดขาด ห้าม Lock บัญชีจากการ Spray หรือเดารหัสผ่าน และห้ามเพิ่ม Computer Object ใหม่เข้าสู่โดเมน ซึ่งล้วนเป็นมาตรการเพื่อหลีกเลี่ยงการถูกตรวจจับจากระบบ Security ขององค์กรเป้าหมาย


กลุ่มปฏิบัติการที่สอง


นักวิจัยยังระบุกลุ่มปฏิบัติการที่สองซึ่งเชื่อมโยงกับ Aurora ด้วยความมั่นใจระดับปานกลาง อาจเป็นผู้ปฏิบัติการคนละกลุ่ม โดยอ้างอิงจาก Storage Bucket ที่ใช้ Exfiltrate ข้อมูล ซึ่งพบว่ามีข้อมูลขององค์กรหนึ่งที่ถูกเผยแพร่บน Leak Site ของ Aurora ในอีก 9 วันถัดมาหลังข้อมูลถูกโอนเข้า Bucket ดังกล่าว กลุ่มนี้พบเหยื่ออย่างน้อย 8 องค์กรในอิสราเอล เยอรมนี ออสเตรีย สเปน สหรัฐอเมริกา และอาร์เจนตินา โดยใช้เทคนิคที่แตกต่างออกไป ได้แก่ Lateral Movement ผ่าน SQL Server ที่เปิด xp_cmdshell, ยกระดับสิทธิ์เป็น SYSTEM ด้วย GodPotato, ทำ DCSync กับ Domain Controller โดยตรง และ Exfiltrate ข้อมูลด้วย s5cmd ไปยัง S3-compatible Storage Endpoint ที่ผู้โจมตี Host เอง


ผลกระทบที่อาจเกิดขึ้น


  1. องค์กรที่ใช้ VMware ESXi เป็นโครงสร้างพื้นฐาน Virtualization หลักเสี่ยงสูญเสีย VM จำนวนมากพร้อมกันในการโจมตีครั้งเดียว เนื่องจากมัลแวร์ออกแบบมาเพื่อเจาะจงเข้ารหัสไฟล์ VM โดยเฉพาะ และการหยุด VM ผ่าน esxcli ทำได้รวดเร็วในระดับสคริปต์อัตโนมัติ
  2. การใช้ AI Agent ช่วยปฏิบัติการเจาะระบบช่วยลดอุปสรรคทางเทคนิคของอาชญากรไซเบอร์ลงอย่างมีนัยสำคัญ ทำให้ผู้โจมตีที่มีทักษะจำกัดสามารถดำเนินการโจมตีที่ซับซ้อน เช่น NTLM Relay หรือ Certificate Attack ได้โดยอาศัย Agent ช่วยปรับแก้คำสั่งจนสำเร็จ
  3. การมีผู้ปฏิบัติการหลายกลุ่มดำเนินการคู่ขนานภายใต้แบรนด์เดียวกัน ทำให้ยากต่อการคาดการณ์ TTP ที่จะพบในการโจมตีครั้งต่อไป เนื่องจากแต่ละกลุ่มอาจใช้เทคนิคที่แตกต่างกันอย่างสิ้นเชิง
  4. การเขียนข้อความเรียกค่าไถ่ลงใน SSH Banner เป็นเทคนิคที่ทำให้เหยื่อรับรู้ถึงการถูกโจมตีได้แม้ไม่สามารถ Login เข้าเครื่องได้ เพิ่มแรงกดดันทางจิตวิทยาต่อทีม IT ที่พยายามกู้คืนระบบ


สิ่งที่องค์กรควรทำ


  1. ตรวจสอบและจำกัดสิทธิ์การเข้าถึง ESXi Management Interface (Port 443, 902) ให้เข้าถึงได้เฉพาะจาก Network ที่จำเป็น พร้อมเปิดใช้ Multi-factor Authentication สำหรับการเข้าถึง vCenter และ ESXi Host โดยไม่มีข้อยกเว้น
  2. สำรองข้อมูล VM แบบ Offline หรือ Immutable Backup อย่างสม่ำเสมอ และทดสอบกระบวนการกู้คืนเป็นระยะ เพื่อให้มั่นใจว่าสามารถกู้คืนระบบได้จริงหากถูกเข้ารหัส โดยไม่ต้องพึ่งพา Backup ที่อยู่ในเครือข่ายเดียวกับ Production
  3. เฝ้าระวังการใช้งาน esxcli ที่ผิดปกติ โดยเฉพาะคำสั่ง vm process kill จำนวนมากในเวลาสั้นๆ และตรวจสอบการเปลี่ยนแปลงของ SSH Login Banner ที่ไม่ได้รับอนุญาต
  4. ตรวจสอบสิทธิ์การเข้าถึง Credential และ Route ที่มีอยู่ในเครือข่าย ที่อาจถูกนำไปใช้โดยผู้โจมตีหรือ AI Agent ในการเจาะระบบต่อ รวมถึงเฝ้าระวังกิจกรรม Reconnaissance ที่ผิดปกติผ่าน Nmap, NetExec หรือ BloodHound Collector


แนวทางลดความเสี่ยงระยะยาว


1. แยก Management Network ของ ESXi และ vCenter ออกจาก Production Network ทั่วไปอย่างเด็ดขาด

เพื่อลดพื้นผิวการโจมตีที่ผู้ไม่ประสงค์ดีสามารถเข้าถึง Management Interface ได้จากเครื่องที่ถูกบุกรุกในเครือข่ายทั่วไป


2. จัดทำ Runbook สำหรับการตอบสนองต่อ Ransomware ที่มุ่งเป้า ESXi โดยเฉพาะ

เนื่องจากการกู้คืนสภาพแวดล้อม Virtualization มีความซับซ้อนแตกต่างจากการกู้คืนเครื่อง Physical ทั่วไป ควรมีแผนที่ทดสอบแล้วล่วงหน้า


3. ติดตามพัฒนาการของการใช้ AI Agent ในการโจมตีไซเบอร์อย่างต่อเนื่อง

เนื่องจากกรณีนี้เป็นตัวอย่างที่ชัดเจนว่า AI Agent สามารถถูกนำไปใช้ในบทบาทผู้ช่วยปฏิบัติการเจาะระบบจริง องค์กร Security ควรปรับปรุงแนวทางตรวจจับให้ครอบคลุมรูปแบบการโจมตีที่มี Human-in-the-loop ร่วมกับ AI


4. เสริมความเข้มแข็งของการตรวจจับ Lateral Movement Technique ที่หลากหลาย

ครอบคลุมทั้ง NTLM Relay, Certificate Attack, SQL Server xp_cmdshell Abuse และ Potato-family Privilege Escalation เนื่องจากกลุ่ม Aurora แสดงให้เห็นว่ามีผู้ปฏิบัติการหลายกลุ่มที่ใช้เทคนิคหลากหลายภายใต้แบรนด์เดียวกัน


วิเคราะห์ในมุมมองจาก TXEC


กรณีของ Aurora Ransomware เป็นหนึ่งในตัวอย่างที่ชัดเจนที่สุดที่ TXEC ได้ติดตามเกี่ยวกับการนำ AI Agent มาใช้เป็นเครื่องมือโจมตีไซเบอร์จริงในภาคสนาม ไม่ใช่เพียงการคาดการณ์เชิงทฤษฎีอีกต่อไป การที่ผู้ปฏิบัติการสามารถมอบหมายงานเจาะระบบให้ AI Agent ดำเนินการแทน พร้อมกำหนดข้อจำกัดเพื่อหลีกเลี่ยงการถูกตรวจจับอย่างเป็นระบบ แสดงให้เห็นถึงระดับความเข้าใจเชิงลึกของผู้โจมตีต่อทั้งขีดความสามารถของ AI Agent และพฤติกรรมของระบบ Security Detection


TXEC มองว่าองค์กรที่ใช้ VMware ESXi เป็นโครงสร้างพื้นฐานหลักควรยกระดับความสำคัญของการป้องกัน Management Interface และการสำรองข้อมูลแบบ Immutable ให้เป็นมาตรฐานพื้นฐาน ไม่ใช่ทางเลือกเสริม เนื่องจากกลุ่ม Ransomware ที่มุ่งเป้า ESXi โดยเฉพาะมีแนวโน้มเพิ่มขึ้นอย่างต่อเนื่อง และการมี AI Agent ช่วยเร่งความเร็วในการเจาะระบบยิ่งลดระยะเวลาที่องค์กรมีในการตรวจจับและตอบสนองต่อการโจมตีให้สั้นลงกว่าเดิม


รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า


[ แหล่งอ้างอิง: SecurityOnline, Gambit Security, Reuters ]