JadePuffer/Storm-3168: ผู้โจมตีแบบเอเจนต์ลบที่จัดเก็บข้อมูลของ Azure tenant ในปฏิบัติการทำลายล้างภายใน 7 นาที

Microsoft Security Research รายงานเมื่อ25 กันยายน 2026ว่าแอ็กเตอร์ที่ใช้ service principal ที่ถูกบุกรุกสองรายได้ดำเนินการภายใน Azure tenant ที่ไม่ระบุชื่อในช่วงต้นเดือนมิถุนายน 2026 โดยเริ่มต้นด้วยการลาดตระเวนนานกว่า 15 ชั่วโมง จากนั้นภายในเวลาประมาณเจ็ดนาทีก็พยายามลบบัญชีจัดเก็บข้อมูลมากกว่า 100 บัญชี โดยประสบความสำเร็จกับบัญชีส่วนใหญ่ และลบ Azure Key Vault, Function App และ App Service plan อย่างละหนึ่งรายการ Microsoft เชื่อมโยงการบุกรุกนี้กับแอ็กเตอร์ที่บริษัทติดตามในชื่อStorm-3168 ซึ่งบริษัทความมั่นคงปลอดภัย Sysdig เรียกว่าJADEPUFFER และได้บันทึกไว้ในเดือนกรกฎาคม 2026 ว่าเป็นปฏิบัติการแรนซัมแวร์ครั้งแรกที่ดำเนินการตั้งแต่ต้นจนจบโดยโมเดลภาษาขนาดใหญ่ Microsoft กล่าวว่าไม่พบหมายเรียกค่าไถ่และไม่ได้ยืนยันว่ามีข้อมูลใดถูกนำออกไป คลังข้อมูลบันทึกแคมเปญนี้เป็นเหตุการณ์ระดับความรุนแรงสูงที่มีการยืนยันการมีส่วนเกี่ยวข้องของ AI และความเสียหายจริง และรายการฉบับเต็มใน Orca AI Incident Archiveมีแหล่งที่มา การจัดระดับความรุนแรง และการประเมินความเชื่อมั่นอยู่

ไม่มีการระบุชื่อเหยื่อ รายงานของ Microsoft อธิบายถึง Azure tenant เดียว service principal ที่ถูกบุกรุกสองรายการซึ่งเป็นของ tenant นั้น และการแบ่งหน้าที่ระหว่างกัน: principal รายหนึ่งทำการสำรวจ (reconnaissance) ประมาณ 15 ชั่วโมง 30 นาที และดำเนินการอ่านที่สำเร็จมากกว่า 300 ครั้ง เพื่อแจกแจงเครื่องเสมือน (virtual machines) subscription กลุ่มทรัพยากร และทรัพยากร ส่วนอีกรายดำเนินการค้นหา (discovery) การดำเนินการที่สร้างความเสียหาย และการเก็บรวบรวมข้อมูลรับรอง Microsoft ไม่ได้ระบุว่ามีกี่องค์กรที่ได้รับผลกระทบ และไม่สามารถยืนยันได้ว่า service principal เหล่านั้นถูกบุกรุกในครั้งแรกได้อย่างไร

สิ่งที่ข้อมูลเทเลเมตรีแสดง ตามลำดับ

principal รายที่สองเริ่มต้นประมาณ 90 นาทีหลังจากรายแรกเริ่ม และได้แจกแจงเครื่องเสมือนและกลุ่มทรัพยากรในสอง subscription ภายในเวลาประมาณห้าวินาที ตามข้อมูลของไมโครซอฟต์ ทั้งสองตัวตนใช้โครงสร้างพื้นฐานที่ไมโครซอฟต์เชื่อมโยงกับ Storm-3168 มีลายนิ้วมือเครือข่ายเดียวกัน และแสดง user agent เดียวกัน คือ python-requests/2.34.2. ไมโครซอฟต์กล่าวว่า ช่วงเวลาและการแบ่งงาน "บ่งชี้อย่างชัดเจนถึงการดำเนินการแบบอัตโนมัติหรือผ่านสคริปต์."

ประมาณ 16 ชั่วโมงต่อมา principal ตัวที่สองได้ตรวจสอบที่จัดเก็บการกำหนดค่าของ Azure App Service เพื่อหาข้อมูลรับรองที่ถูกเปิดเผย และค้นหา Azure OpenSearch แต่ไม่สำเร็จ เจ็ดสิบวินาทีหลังจากนั้น มันได้ลองดำเนินการ ListKey กับบัญชีที่เก็บข้อมูลที่ไม่มีอยู่จริง ไม่ถึงหนึ่งวินาทีหลังจากคำเรียกที่ล้มเหลวนั้น การทำลายก็เริ่มขึ้น ในช่วง 35 นาทีถัดมา Microsoft นับการดำเนินการทำลายหรือการเก็บรวบรวมข้อมูลรับรองได้มากกว่า 150 ครั้ง โดยช่วงการทำลายหลักกินเวลาประมาณเจ็ดนาที

เจ็ดนาที และการควบคุมที่ยังคงอยู่

Microsoft กล่าวว่าบัญชีพื้นที่เก็บข้อมูลส่วนใหญ่ที่ผู้โจมตีกำหนดเป้าหมายถูกลบสำเร็จ ผู้โจมตียังได้ลบ Azure Key Vault, Function App และ App Service plan ที่อยู่ในกลุ่มทรัพยากรเดียวกันและดูเหมือนจะรองรับ Function App การกำหนดเป้าหมายไม่ได้จำกัดอยู่เพียงพื้นที่เก็บข้อมูล: Microsoft บันทึกความพยายามหลายครั้งในการลบล็อก Azure Site Recovery และล็อกป้องกัน Azure Backup และรายงานว่าความพยายามเหล่านั้นล้มเหลว

Microsoft กล่าวว่าการลบไม่ได้ผลทุกครั้ง และเหตุผลนั้นแตกต่างกันในแบบที่สำคัญต่อฝ่ายป้องกัน บัญชีที่เก็บข้อมูลบางบัญชีรอดมาได้เพราะล็อกทรัพยากร Azure และการป้องกันการลบระดับบัญชีที่เก็บข้อมูลบล็อกการดำเนินการนั้น ความพยายามแบบขนานในการลบฐานข้อมูล Azure SQL ล้มเหลวด้วยเหตุผลที่ต่างออกไป: ทุกรายการใช้เวอร์ชัน API ที่ไม่รองรับ Cloud Security Alliance อธิบายว่าสิ่งนั้นเป็นข้อผิดพลาดในการดำเนินงานมากกว่าการถูกบล็อกการกระทำ Microsoft สรุปการรวมกันของการลบทรัพยากร ความพยายามแทรกแซงการกู้คืน และการเก็บรวบรวมข้อมูลรับรองว่า "สอดคล้องกับกลยุทธ์ที่สามารถสนับสนุนการปฏิบัติการแรนซัมแวร์และการกรรโชกทรัพย์"

คำอธิบายของ Microsoft ระบุถึงการกำหนดบทบาท Azure ตามปกติ ไม่ใช่การโจมตีช่องโหว่ของ Azure เอง พบว่าบทบาท Storage Account Contributor ที่ให้ผ่านกลุ่มอนุญาตให้ทำลายที่เก็บข้อมูล บทบาท Contributor โดยตรงอนุญาตให้ลบทรัพยากรแอปพลิเคชันทั้งสามและดึงคีย์อีกครั้ง และบทบาท SQL DB Contributor โดยตรงอนุญาตให้พยายามใช้ SQL ที่ล้มเหลว Microsoft สังเกตเห็นโทเค็นเฉพาะห้ารายการที่ออกให้กับ service principal ตัวที่สอง: สี่รายการสนับสนุนการลบ และรายการที่ห้าจัดการสินค้าคงคลังที่เก็บข้อมูลและการดึงคีย์ โทเค็นการลบสองรายการเปิดใช้งานในช่วง 70 วินาทีเดียวกัน รายงานยังระบุด้วยว่าที่เก็บข้อมูลที่มีชื่อในธีม terraform และ backup อยู่ในกลุ่มเป้าหมาย ซึ่งอาจเพื่อทำให้การกู้คืนเสียหาย

ค่าส่งคืนสำหรับคีย์จัดเก็บ

ประมาณ 30 นาทีหลังจากกระบวนการทำลายสิ้นสุดลง principal รายเดิมก็กลับมา มันได้สำรวจบัญชีที่เก็บข้อมูลและส่งมากกว่า 30 คำขอ ListKeys ที่สำเร็จ ซึ่งรวมถึงบัญชีที่เก็บข้อมูลที่เชื่อมโยงกับ Site Recovery ด้วย บัญชีที่เก็บข้อมูลที่ตั้งชื่อคล้ายกันในกลุ่มทรัพยากรเดียวกันรอดพ้นในช่วงการลบ และจากนั้นก็ถูกเรียกดูคีย์สำเร็จ Microsoft ไม่ได้พบบันทึกเรียกค่าไถ่ และไม่ได้ยืนยันการขโมยข้อมูลออกไปสำเร็จ แต่ระบุว่าคีย์ที่เก็บรวบรวมได้อาจสนับสนุนการขโมยข้อมูลออกไปในอนาคต

ลำดับเหตุการณ์ดังกล่าวเปลี่ยนความหมายของการกู้คืน ตามคำกล่าวของ Ross Filipek ประธานเจ้าหน้าที่ความมั่นคงปลอดภัยสารสนเทศของ Corsica Technologies ซึ่งให้สัมภาษณ์กับ CSO Online เกี่ยวกับเหตุการณ์นี้ เขากล่าวว่าการสร้างสินทรัพย์ที่ถูกลบขึ้นใหม่เพียงอย่างเดียวไม่เพียงพอ เพราะคำขอคีย์พื้นที่เก็บข้อมูลที่เกิดขึ้นในภายหลังอาจสร้างเส้นทางอื่นไปยังข้อมูลได้ ผู้ตอบสนองเหตุการณ์ต้องระบุว่ามีอัตลักษณ์และคีย์ใดบ้างที่ถูกแตะต้อง และตรวจสอบการใช้งานสิ่งเหล่านั้นก่อนจะไว้วางใจบริการที่กู้คืนแล้ว "เมื่อผู้โจมตีถืออัตลักษณ์แอปพลิเคชันไว้ กิจกรรมของพวกเขาอาจดูเหมือนการบริหารจัดการคลาวด์ตามปกติ" Filipek กล่าวกับ CSO Online

ข้อมูลรับรองปรากฏขึ้นได้อย่างไร

Microsoft ไม่สามารถยืนยันเวกเตอร์การเข้าถึงเริ่มต้นได้ สิ่งที่พบคือการเปิดเผยข้อมูล: client ID, client secret และ tenant ID ของหนึ่งใน service principals ปรากฏเป็นข้อความธรรมดาใน issue บน GitHub สาธารณะ ซึ่งโพสต์โดยพนักงานขององค์กรที่ได้รับผลกระทบ issue นี้ถูกแก้ไขในภายหลัง แต่ Microsoft กล่าวว่าความลับยังคงเข้าถึงได้ผ่านประวัติการแก้ไขสาธารณะของ issue รายงานระบุอย่างชัดเจนว่า Microsoft ไม่สามารถยืนยันได้ว่าความลับนี้คือตัวที่ถูกใช้หรือไม่

คำเตือนที่แนบมากับข้อค้นพบดังกล่าวคือส่วนที่เป็นภาคปฏิบัติ Microsoft ระบุว่าข้อมูลรับรอง (credential) ที่ถูกเปิดเผยต่อสาธารณะแล้วนั้น ควรถือว่าเสมือนถูกบุกรุก (compromised) และต้องเพิกถอนหรือหมุนเวียนเปลี่ยนใหม่ (rotate) ทันที พร้อมทั้งตรวจสอบการใช้งานที่ผ่านมา การลบหรือปิดทับข้อมูลลับที่ถูกเปิดเผยไม่ได้ทำให้ข้อมูลนั้นเป็นโมฆะ และข้อมูลรับรองที่ถูกเปิดเผยต่อสาธารณะยังคงใช้งานได้จนกว่าจะถูกเพิกถอนหรือหมุนเวียนเปลี่ยนใหม่

Microsoft ยังได้อธิบายถึงการสแกนตรวจสอบในวงกว้างขึ้นโดยโครงสร้างพื้นฐานที่เชื่อมโยงกับ Storm-3168 ตั้งแต่ต้นปี 2026 ต่อ Azure App Services ณ ตำแหน่งผู้ดูแลระบบ WordPress, PHP-CGI, endpoint Langflow /api/v1/validate/code, และเส้นทางที่คล้ายเว็บเชลล์ เป้าหมายเหล่านั้นไม่ทับซ้อนกับ subscription ของเหยื่อ และ Microsoft ไม่พบเส้นทางจาก App Service ไปยังข้อมูลรับรอง Azure Resource Manager รายงานระบุตัวบ่งชี้สามรายการ: 45.131.66[.]106 สำหรับการสแกนตรวจสอบและคำขอ ARM ที่เป็นอันตราย และ 34.153.223[.]102 และ 64.20.53[.]230 สำหรับการสแกนตรวจสอบ App Service

ผู้กระทำเดียวกัน แต่เป็นการดำเนินการที่แตกต่างกัน

รายงานของ Sysdig ฉบับวันที่ 1 กรกฎาคม 2026 คือเหตุผลที่คำว่า “agentic” ถูกใช้กับแอ็กเตอร์รายนี้เลย Sysdig อธิบายว่า JADEPUFFER เป็นกรณีแรกที่มีการบันทึกไว้ของแรนซัมแวร์แบบ agentic — “ปฏิบัติการกรรโชกทรัพย์ที่ขับเคลื่อนตั้งแต่ต้นจนจบโดยโมเดลภาษาขนาดใหญ่” — และกล่าวว่าความสามารถของมันมาจากเอเจนต์ AI ไม่ใช่ชุดเครื่องมือที่มนุษย์เป็นผู้ดำเนินการ ในการบุกรุกครั้งนั้น แอ็กเตอร์ได้ใช้ประโยชน์จาก CVE-2025-3248 ในอินสแตนซ์ Langflow ที่เปิดสู่อินเทอร์เน็ต, เข้ารหัสรายการกำหนดค่า Nacos จำนวน 1,342 รายการโดยใช้ AES_ENCRYPT() ซึ่งเป็นฟังก์ชันในตัวของ MySQL, ลบตารางต้นฉบับทิ้ง และทิ้ง README_RANSOM ซึ่งเป็นตารางที่มีที่อยู่ Bitcoin และช่องทางติดต่อ Proton Mail Sysdig รายงานว่ามีเพย์โหลดที่แตกต่างกันมากกว่า 600 รายการ โค้ดที่บรรยายตัวเอง และเพย์โหลดหลายขั้นตอนเพื่อแก้ไขสถานการณ์ที่เกิดขึ้นภายใน 31 วินาทีหลังจากการเข้าสู่ระบบ Nacos ล้มเหลว Sysdig ยังกล่าวอีกว่าไม่สามารถมองเห็นพรอมป์ของระบบหรือการกำหนดค่าของเอเจนต์ได้

แคมเปญ Azure เป็นปฏิบัติการที่แยกต่างหากของกลุ่มผู้โจมตีรายเดียวกัน ไม่ใช่การทำซ้ำของการบุกรุกในเดือนกรกฎาคม โดยมุ่งเน้นการลบข้อมูลและการเก็บรวบรวมคีย์ ไม่ใช่การเข้ารหัส และ Microsoft ไม่พบข้อความเรียกค่าไถ่ ความเชื่อมโยงระหว่างสองเหตุการณ์นี้ส่วนหนึ่งอาศัยโครงสร้างพื้นฐาน Cloud Security Alliance ระบุในบันทึกการวิจัยเมื่อวันที่ 28 กันยายนว่า ที่อยู่ IP สองรายการที่ Microsoft ระบุ ได้แก่ 45.131.66[.]106 และ 34.153.223[.]102 ปรากฏอยู่ในรายงานของ Sysdig เมื่อเดือนกรกฎาคม บันทึกเดียวกันเตือนว่าการใช้ IP ซ้ำเพียงอย่างเดียวไม่สามารถตัดความเป็นไปได้เรื่องการใช้งานโฮสติ้งของบุคคลที่สามร่วมกัน

ก่อตั้งแล้ว ประเมินแล้ว และยังเปิดอยู่

กลไกของการบุกรุก Azure ได้รับการบันทึกไว้อย่างละเอียด แต่ความเป็นอิสระไม่ได้ถูกบันทึกไว้ตามมาตรฐานเดียวกัน และความแตกต่างนี้คือข้อแม้ที่สำคัญที่สุดในบันทึกนี้

ข้อมูลเทเลเมทรีของ Microsoft ยืนยันว่า: มี service principal ที่ถูกบุกรุกสองรายในเทนแนนต์เดียว; การดำเนินการอ่านที่สำเร็จมากกว่า 300 ครั้งในช่วงประมาณ 15 ชั่วโมงครึ่ง; ความพยายามลบบัญชีที่เก็บข้อมูลมากกว่า 100 ครั้ง ซึ่งส่วนใหญ่สำเร็จ; การลบ Key Vault, Function App และ App Service plan อย่างละหนึ่งรายการ; การลบฐานข้อมูล SQL ที่ล้มเหลวทั้งหมดเนื่องจากเวอร์ชัน API ที่ไม่รองรับ; บัญชีที่เก็บข้อมูลที่ได้รับการปกป้องโดย resource locks และการป้องกันการลบ; คำขอ ListKeys ที่สำเร็จมากกว่า 30 รายการหลังการทำลาย; ข้อมูลรับรอง service principal แบบข้อความธรรมดาใน issue บน GitHub สาธารณะและประวัติการแก้ไข; ไม่พบหมายเรียกค่าไถ่; และไม่มีการขโมยข้อมูลออกที่ยืนยันได้

ประเมินโดย Microsoft: กิจกรรมดังกล่าวเป็นของ Storm-3168; การรวมกันของการลบ การรบกวนการกู้คืน และการเก็บรวบรวมคีย์นั้นสอดคล้องกับแรนซัมแวร์และการกรรโชก; การดำเนินการน่าจะเป็นแบบอัตโนมัติหรือใช้สคริปต์; และคีย์ที่เก็บรวบรวมได้อาจสนับสนุนการนำข้อมูลออกในอนาคต รายงานสาธารณะของ Microsoft ไม่ได้อธิบายถึงเอเจนต์อัตโนมัติที่ใช้เหตุผลผ่านขั้นตอนเฉพาะของ Azure

ประเด็นที่ยังเปิดอยู่: service principals ถูกบุกรุกเป็นครั้งแรกได้อย่างไร; ตัวตนของเหยื่อและจำนวนองค์กรที่ได้รับผลกระทบ; มีข้อมูลใดออกจาก tenant หรือไม่; และ AI agent แทนที่จะเป็นสคริปต์เป็นผู้สั่งการปฏิบัติการของ Azure ด้วยตนเองหรือไม่

Cloud Security Alliance ระบุช่องว่างทางหลักฐานไว้อย่างชัดเจนในบันทึกวันที่ 28 กันยายนว่า ลักษณะ "agentic" นั้น ในปัจจุบันอาศัย "ความแม่นยำ จังหวะ และการแบ่งงานระหว่างอัตลักษณ์" มากกว่าอาศัยร่องรอยการให้เหตุผลของเอเจนต์ที่ถูกบันทึกไว้ หลักฐานที่ Sysdig ใช้ในเดือนกรกฎาคม — เพย์โหลดที่บรรยายตัวเองและวงจรวินิจฉัยและแก้ไขอย่างรวดเร็ว — ไม่ปรากฏในบันทึกสาธารณะของแคมเปญ Azure Nick Tausek จากบริษัทความปลอดภัย Swimlane บอกกับ CSO Online ว่าหลักฐานของ Azure แสดงให้เห็น "ระบบอัตโนมัติที่ประสานกัน มากกว่าจะพิสูจน์ว่า AI เป็นผู้กำกับแต่ละขั้นตอน"

การรายงานข่าวเกี่ยวกับการเปิดเผยข้อมูลครั้งนี้ใช้กรอบที่แรงกว่า พาดหัวข่าวของ BleepingComputer บรรยายถึง “การโจมตีด้วย AI แบบเอเจนต์” ที่มีต่อ Azure ส่วนพาดหัวของ Dark Reading บรรยายถึง “ผู้ก่อภัยที่ใช้ AI” ซึ่งเจาะระบบ tenant ของ Azure ขณะที่รายงานของ Microsoft เองระบุว่าเวลาและการแบ่งงาน “บ่งชี้อย่างชัดเจนถึงการดำเนินการแบบอัตโนมัติหรือผ่านสคริปต์” และไม่ได้ระบุว่าแต่ละขั้นตอนใน Azure เกิดจากเอเจนต์

คลังข้อมูลให้เกรดความเชื่อมั่นของบันทึกนี้เป็น A และไม่ติดธงว่าเป็นกรณีที่มีข้อโต้แย้ง ป้ายกำกับ “confirmed” เรื่องการมีส่วนเกี่ยวข้องของ AI ของบันทึกนี้ขึ้นอยู่กับการระบุว่าเป็นฝีมือของ JADEPUFFER ซึ่งเป็นแอ็กเตอร์ที่ Sysdig ระบุว่าขับเคลื่อนด้วย LLM; ไม่ใช่ข้อกล่าวอ้างว่า Microsoft บันทึกกระบวนการคิดของเอเจนต์ระหว่างการลบข้อมูลใน Azure ความเสียหายเป็นที่ยืนยันแล้ว ระบบอัตโนมัติเป็นที่ยืนยันแล้ว และความเป็นอิสระนั้นอนุมานได้

สิ่งที่ Microsoft บอกว่าควรเปลี่ยนแปลง

คำแนะนำของ Microsoft เป็นแนวทางปฏิบัติ และเป็นผลโดยตรงจากวิธีการที่การบุกรุกครั้งนี้เกิดขึ้น โดยขอให้ฝ่ายป้องกันเปิดใช้งานแผน Microsoft Defender for Cloud ที่เกี่ยวข้องสำหรับ Resource Manager, Storage, Key Vault, App Service และ Databases; เก็บข้อมูลรับรองของ service principal คีย์ที่เก็บข้อมูล สตริงการเชื่อมต่อ และความลับอื่น ๆ ออกจากซอร์สโค้ด การกำหนดค่า พื้นที่เก็บโค้ด และรายการปัญหา; ใช้ Microsoft Entra Workload ID แทนความลับที่มีอายุการใช้งานยาวนาน; ใช้หลักสิทธิ์น้อยที่สุดและตรวจทานการกำหนดสิทธิ์ Azure RBAC สำหรับ workload identities; และจำกัดและตรวจสอบทรัพยากรสำรองข้อมูลและการกู้คืน รวมถึงความพยายามในการเปลี่ยนแปลงการควบคุมการป้องกันของทรัพยากรเหล่านั้น

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