กลุ่ม JADEPUFFER (Storm-3168) ใช้ service principal ที่ถูกยึดลบทรัพยากร Azure จำนวนมาก — Microsoft ชี้เป็นการโจมตีคลาวด์ที่ขับเคลื่อนด้วย AI

สรุปสั้น

บริษัท Microsoft เผยแพร่รายงานเชิงลึกครั้งแรกที่เปิดเผยว่ากลุ่มผู้ก่อภัยคุกคามที่รู้จักในชื่อ JADEPUFFER ซึ่ง Microsoft ติดตามในชื่อ Storm-3168 ได้ลงมือทำลายทรัพยากรภายในสภาพแวดล้อม Microsoft Azure โดยอาศัย service principal ที่ถูกยึด (non-human identity ที่แอปพลิเคชันใช้สื่อสารกับ Azure) การโจมตีเกิดขึ้นในช่วงต้นเดือนมิถุนายน 2569 กินเวลาราว 18 ชั่วโมง โดยผู้โจมตีใช้ service principal ที่ถูกยึด 2 ตัวจาก tenant เดียวกัน ตัวหนึ่งทำหน้าที่ลาดตระเวนและค้นหาทรัพยากร อีกตัวรับผิดชอบการทำลายและเก็บ credential ซึ่ง Microsoft ระบุว่าเป็นการแบ่งงานกันอย่างชัดเจนและมีลักษณะเป็นการทำงานอัตโนมัติหรือสคริปต์

Microsoft อธิบายว่าปลายทางของการโจมตีน่าจะสอดคล้องกับพฤติกรรม ransomware เพราะนำไปสู่การลบทรัพยากร Azure จำนวนมาก รวมถึงทรัพยากรที่เกี่ยวกับการสำรองและกู้คืนข้อมูล ซึ่งบ่งชี้ว่าผู้โจมตีต้องการบั่นทอนความสามารถของเหยื่อในการกู้คืนจากความเสียหาย อย่างไรก็ตามครั้งนี้ยังไม่พบ ransom note หรือหลักฐานการขโมยข้อมูลออกไปสำเร็จ ที่น่าสนใจคือ Azure resource lock และ deletion protection ระดับ storage account สามารถบล็อกความพยายามลบบางส่วนได้ แม้ identity ที่ถูกยึดจะมีสิทธิ์ระดับผู้ดูแลกว้างขวางก็ตาม ซึ่ง Microsoft ชี้ว่าตอกย้ำคุณค่าของมาตรการป้องกันอิสระที่ยังทำงานได้แม้ตัวตนถูกยึด

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

เว็บไซต์ The Hacker News รายงานเมื่อวันที่ 28 กันยายน พ.ศ. 2569 ว่า Microsoft ได้เผยแพร่การวิเคราะห์พฤติกรรมของ JADEPUFFER ภายใน Azure เป็นครั้งแรก โดยเรียกกิจกรรมนี้ว่าเป็นวิวัฒนาการของชั้นเชิงกลุ่มผู้ก่อภัย ก่อนหน้านี้ JADEPUFFER ถูกบันทึกไว้ครั้งแรกโดยบริษัท Sysdig ซึ่งอธิบายว่าเป็นปฏิบัติการ ransomware ครั้งแรกที่ดำเนินการแบบ end-to-end ด้วยความช่วยเหลือของโมเดลภาษาขนาดใหญ่ (LLM) โดยเอเจนต์เจาะเข้าระบบผ่านช่องโหว่ที่รู้จักใน Langflow (CVE-2025-3248) เก็บเกี่ยว credential เคลื่อนที่ลึกเข้าไปในเครือข่าย เข้ารหัสไฟล์คอนฟิกของ Nacos และทิ้ง ransom note เรียกค่าไถ่เป็น Bitcoin ต่อมา Langflow instance เดียวกันยังถูกโจมตีซ้ำด้วย ransomware สาย Go ชื่อ ENCFORGE ที่สร้างมาเพื่อโครงสร้างพื้นฐาน AI โดยเฉพาะ ซึ่ง Cloud Thunder เคยรายงานทั้งสองเหตุการณ์ไว้ก่อนหน้านี้

ในการวิเคราะห์ครั้งใหม่ Microsoft ระบุว่าพบ service principal ที่ถูกยึด 2 ตัวซึ่งผูกกับ tenant เดียวกัน ตัวแรกใช้ลาดตระเวนและค้นหาทรัพยากร ส่วนตัวที่สองใช้ทำลายและเก็บ credential การสำรวจเริ่มในต้นเดือนมิถุนายน 2569 โดย identity แรกใช้เวลาราว 15 ชั่วโมงครึ่งไล่รายการ Virtual Machine, subscription, resource group และทรัพยากรอื่น ๆ รวมกว่า 300 คำสั่งอ่าน จากนั้นราว 90 นาทีต่อมา identity ที่สองก็ทำกิจกรรมคล้ายกันข้าม 2 subscription ภายในเวลาเพียง 5 วินาที ทั้งสองตัวใช้โครงสร้างพื้นฐานของ Storm-3168 มี network fingerprint เดียวกัน และใช้ user agent ตัวเดียวกันคือ python-requests/2.34.2 ซึ่งเป็นหลักฐานสำคัญที่ชี้ว่าเป็นการทำงานแบบสคริปต์

วิธีการโจมตี

หลังจากผ่านไป 16 ชั่วโมง identity ตัวที่สองสามารถไล่รายการ configuration store ของ Azure App Service ได้สำเร็จ ซึ่งน่าจะเป็นการมองหา credential ที่เปิดโล่ง และยังพยายามค้นหาทรัพยากร Azure OpenSearch แต่ไม่สำเร็จ ราว 70 วินาทีหลังการสำรวจครั้งสุดท้าย service principal เดียวกันสั่ง ListKey กับ storage account ที่ไม่มีอยู่จริง และไม่ถึงหนึ่งวินาทีหลังคำขอที่ล้มเหลวนั้น การลบข้อมูลก็เริ่มต้นขึ้น ในช่วง 35 นาที identity นี้พยายามปฏิบัติการทำลายหรือเก็บ credential กว่า 150 ครั้ง โดยส่วนที่เป็นการทำลายจริงกินเวลาราว 7 นาที มีความพยายามลบ storage account กว่า 100 บัญชีและสำเร็จเป็นส่วนใหญ่ พร้อมทั้งลบ Key Vault, Function App และ App Service plan จาก resource group เดียวกันที่ดูเหมือนรองรับแอปตัวเดียวกัน

ไม่ใช่ทุกอย่างที่ถูกลบสำเร็จ Azure resource lock และ deletion protection ระดับ storage account ช่วยกัน storage account หลายบัญชีไว้ได้ ส่วนความพยายามลบฐานข้อมูล Azure SQL หลายตัวพร้อมกันล้มเหลวทั้งหมดเพราะสคริปต์ใช้ API เวอร์ชันที่ไม่รองรับสำหรับทรัพยากรประเภทนั้น กลายเป็นว่าข้อผิดพลาดทางเทคนิคเล็ก ๆ กลับช่วยขวางการโจมตีบางส่วนไว้ได้ ผู้โจมตียังเล็งระบบสำรองและกู้คืนด้วย โดยพยายามปลด Azure Site Recovery lock และ Azure Backup protection lock หลายครั้งแต่ไม่สำเร็จ และมุ่งเป้าไปยัง storage account ที่มีชื่อเกี่ยวกับ Terraform และการสำรองข้อมูล บ่งชี้ว่าตั้งใจทำให้การกู้คืนยากขึ้น หลังการลบครั้งสุดท้ายราวครึ่งชั่วโมง identity เดิมยังกลับมาขอ key อีกครั้ง โดยส่ง ListKeys ที่สำเร็จกว่า 30 คำขอ รวมถึงบัญชีที่ผูกกับ Azure Site Recovery

Microsoft ระบุว่ายังไม่สามารถยืนยันได้ว่า service principal ถูกยึดตั้งแต่แรกอย่างไร แต่พบว่า client ID, client secret และ tenant ID เคยถูกเปิดเผยเป็น plaintext ใน GitHub issue สาธารณะโดยพนักงานขององค์กรที่ตกเป็นเหยื่อ แม้ภายหลังจะแก้ไข issue เพื่อลบ secret ออก แต่ secret นั้นยังเข้าถึงได้ผ่านประวัติการแก้ไข (edit history) ที่เปิดสาธารณะ Microsoft ย้ำว่าการลบหรือปิดบัง secret ที่หลุดออกไปแล้วไม่ได้ทำให้ credential นั้นใช้ไม่ได้ ทุก credential ที่เปิดเผยในที่สาธารณะบนอินเทอร์เน็ตต้องถือว่าถูกยึดและควรเพิกถอนหรือหมุนเปลี่ยนทันที นอกจากนี้ Microsoft ยังพบการยิงโพรบจากโครงสร้างพื้นฐานที่โยงกับ Storm-3168 มาตั้งแต่ต้นปี เล็งไปที่ Azure App Service ของลูกค้าหลายราย ด้วยเส้นทางอย่างหน้าจัดการ WordPress, PHP-CGI และปลายทางตรวจสอบโค้ดของ Langflow ที่ /api/v1/validate/code

ผลกระทบ

เหตุการณ์นี้สะท้อนการเปลี่ยนผ่านครั้งใหญ่ไปสู่การโจมตีที่ขับเคลื่อนด้วย AI ซึ่งผู้ก่อภัยสามารถประสานปฏิบัติการหลังเจาะระบบที่ซับซ้อนข้ามสภาพแวดล้อมคลาวด์ได้ด้วยความเร็วและขนาดที่มากขึ้น การแบ่งงานระหว่าง service principal สองตัวและจังหวะเวลาที่กระชับแสดงให้เห็นว่ากระบวนการถูกทำให้เป็นอัตโนมัติ ทำให้เวลาตอบสนองของฝ่ายป้องกันแคบลงมาก จุดที่ต้องขีดเส้นใต้คือต้นเหตุไม่ได้มาจากช่องโหว่ที่ซับซ้อน แต่มาจาก credential ของ non-human identity ที่หลุดออกสู่สาธารณะและไม่ถูกหมุนเปลี่ยน ขณะเดียวกันเหตุการณ์นี้ก็เป็นบทพิสูจน์ว่ามาตรการป้องกันเชิงลึก เช่น resource lock, deletion protection และการควบคุมเวอร์ชัน API ยังมีคุณค่าจริง เพราะสามารถลดความเสียหายได้แม้ในสถานการณ์ที่ตัวตนซึ่งมีสิทธิ์สูงถูกยึดไปแล้ว

คำแนะนำ

• ถือว่า credential ทุกตัว (โดยเฉพาะ client secret ของ service principal) ที่เคยปรากฏในที่สาธารณะ เช่น GitHub issue, commit history หรือ edit history ถูกยึดแล้ว ต้องเพิกถอนและหมุนเปลี่ยนทันที การลบข้อความออกไม่พอ
• จำกัดสิทธิ์ของ service principal ตามหลัก least privilege และเฝ้าระวังพฤติกรรมผิดปกติ เช่น การไล่ enumerate ทรัพยากรจำนวนมากในเวลาสั้น หรือ user agent อย่าง python-requests ที่ไม่ควรมาจากแอปพลิเคชันปกติ
• เปิดใช้งาน Azure resource lock, deletion protection ระดับ storage account, soft delete และ immutable backup เพื่อให้มีชั้นป้องกันอิสระที่การยึด identity เพียงตัวเดียวไม่สามารถล้มได้
• ปกป้องทรัพยากรสำรองและกู้คืน (Azure Backup, Site Recovery) เป็นพิเศษ และแยกสิทธิ์การจัดการออกจาก identity ที่ใช้งานทั่วไป
• ตรวจสอบและบล็อกตัวบ่งชี้ในตาราง IoC ด้านล่าง รวมถึงเฝ้าระวังการยิงโพรบไปยังปลายทาง /api/v1/validate/code ของ Langflow และแพตช์ CVE-2025-3248

Indicators of Compromise (IoCs)

หมายเหตุ: ที่อยู่ IP ถูก defang ไว้ (เช่น [.]) เพื่อป้องกันการเชื่อมต่อโดยไม่ตั้งใจ ให้ re-fang เฉพาะในแพลตฟอร์ม threat intelligence ที่ควบคุมได้ เช่น MISP, VirusTotal หรือ SIEM เท่านั้น

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

• JADEPUFFER-Linked Attackers Used Compromised Service Principals to Delete Azure Resources — The Hacker News
• Storm-3168: Agentic-driven cloud attacks using compromised service principals — Microsoft