JadePuffer/Storm-3168: فاعل وكيلي يحذف تخزين مستأجر Azure في اندفاع تدميري خلال 7 دقائق

أفادت أبحاث الأمن في مايكروسوفت في25 سبتمبر 2026بأن جهة فاعلة استخدمت اثنين من كيانات الخدمة المخترقة (service principals) ونشطت داخل مستأجر Azure لم يُسمَّ في أوائل يونيو 2026، بدءًا بأكثر من 15 ساعة من الاستطلاع، ثم حاولت في غضون نحو سبع دقائق حذف أكثر من 100 حساب تخزين ونجحت في ذلك مع معظمها، وحذفت Azure Key Vault وFunction App وخطة App Service. وتنسب مايكروسوفت الاختراق إلى الجهة التي تتعقبها باسمStorm-3168، والتي تسميها شركة الأمن SysdigJADEPUFFERووثّقتها في يوليو 2026 بوصفها أول عملية فدية تُدار من البداية إلى النهاية بواسطة نموذج لغوي كبير. وقالت مايكروسوفت إنها لم تعثر على أي مذكرة فدية ولم تؤكد تسريب أي بيانات. ويسجّل الأرشيف هذه الحملة بوصفها حادثة عالية الخطورة مع تورط مؤكد للذكاء الاصطناعي وضرر فعلي، والمدخل الكامل في أرشيف Orca لحوادث الذكاء الاصطناعييتضمن مصادره وتصنيف خطورته وتقييم الثقة فيه.

لم يُذكر اسم الضحية. يصف تقرير Microsoft مستأجر Azure واحدًا، واثنين من مديري الخدمة المخترقين كانا يخصانه، وتوزيعًا للمهام بينهما: تولّى أحد المديرين الاستطلاع لنحو 15 ساعة و30 دقيقة، ونفّذ أكثر من 300 عملية قراءة ناجحة لاستعراض الأجهزة الافتراضية والاشتراكات ومجموعات الموارد والموارد؛ بينما نفّذ الآخر الاستكشاف والعمليات التدميرية وجمع بيانات الاعتماد. لم تذكر Microsoft عدد المؤسسات المتأثرة، ولم تتمكن من تحديد كيفية اختراق مديري الخدمة في المقام الأول.

ما تُظهره القياسات عن بُعد، بالترتيب

بدأت الهوية الرئيسية الثانية بعد نحو 90 دقيقة من بدء الأولى، وسردت الأجهزة الظاهرية ومجموعات الموارد عبر اشتراكين في نحو خمس ثوانٍ، وفقًا لمايكروسوفت. استخدمت كلتا الهويتين بنية تحتية تربطها مايكروسوفت بـ Storm-3168، وكانت لهما البصمة الشبكية نفسها وقدَّمتا وكيل المستخدم نفسه، python-requests/2.34.2. قالت مايكروسوفت إن التوقيت وتقسيم العمل «يشير بقوة إلى تنفيذ آلي أو عبر سكربت».

بعد نحو 16 ساعة، فحص الكيان الرئيسي الثاني مخازن تكوين Azure App Service بحثًا عن بيانات اعتماد مكشوفة، وبحث دون نجاح عن Azure OpenSearch. وبعد ذلك بسبعين ثانية، حاول تنفيذ عملية ListKey ضد حساب تخزين غير موجود. وبعد أقل من ثانية واحدة من ذلك الاستدعاء الفاشل، بدأ التدمير. وعلى مدى الدقائق الـ35 التالية، أحصت Microsoft أكثر من 150 عملية تدمير أو جمع بيانات اعتماد؛ واستمرت المرحلة التدميرية الأساسية نحو سبع دقائق.

الدقائق السبع، وأدوات التحكم التي صمدت

تقول Microsoft إن معظم حسابات التخزين التي استهدفتها الجهة الفاعلة قد حُذفت بنجاح. كما حذفت الجهة الفاعلة Azure Key Vault وFunction App وخطة App Service كانت موجودة في مجموعة الموارد نفسها ويبدو أنها كانت تدعم Function App. ولم يقتصر الاستهداف على التخزين: فقد سجّلت Microsoft محاولات متعددة لحذف أقفال Azure Site Recovery وأقفال حماية Azure Backup، وأفادت بأن تلك المحاولات فشلت.

تقول مايكروسوفت إنه لم ينجح كل حذف، وتختلف الأسباب على نحو يهم المدافعين. نجت بعض حسابات التخزين لأن أقفال موارد Azure والحماية من الحذف على مستوى حساب التخزين منعت العملية. وفشلت المحاولات المتوازية لحذف قواعد بيانات Azure SQL لسبب مختلف: فقد استخدم كل منها إصدار API غير مدعوم. ووصفت منظمة Cloud Security Alliance ذلك بأنه خطأ تشغيلي وليس إجراءً محظورًا. ولخّصت مايكروسوفت الجمع بين حذف الموارد، ومحاولات التدخل في الاسترداد، وجمع بيانات الاعتماد بأنه "يتوافق مع تكتيكات يمكن أن تدعم عمليات برامج الفدية والابتزاز."

يصف سرد Microsoft تعيينات أدوار Azure العادية بدلاً من استغلال Azure نفسه. ووجد أن دور Storage Account Contributor الممنوح لمجموعة قد سمح بتدمير التخزين، وأن دور Contributor المباشر سمح بحذف موارد التطبيق الثلاثة واسترداد مفتاح آخر، وأن دور SQL DB Contributor المباشر سمح بمحاولات SQL الفاشلة. لاحظت Microsoft خمسة رموز مميزة صادرة للجهة الخدمية الرئيسية الثانية: أربعة منها دعمت الحذف، والخامس تعامل مع جرد التخزين واسترداد المفاتيح. كان اثنان من رموز الحذف نشطين خلال الفترة نفسها البالغة 70 ثانية. ويشير التقرير أيضًا إلى أن حسابات التخزين ذات الأسماء terraform وbackup ذات الطابع كانت من بين الأهداف، ربما لإعاقة الاسترداد.

الإرجاع الخاص بمفاتيح التخزين

بعد نحو 30 دقيقة من انتهاء عملية التدمير، عاد المسؤول الرئيسي نفسه. وقد جرد حسابات التخزين ونفّذ أكثر من 30 طلب ListKeys ناجح، بما في ذلك ضد تخزين مرتبط بـ Site Recovery. وكان حساب تخزين مشابه الاسم في مجموعة الموارد نفسها قد أُعفِي خلال مرحلة الحذف، ثم نجح سرد مفاتيحه. ولم تلاحظ Microsoft رسالة فدية ولم تؤكد نجاح تسريب البيانات، لكنها قالت إن المفاتيح المجمّعة قد تدعم تسريبًا مستقبلًا.

تغيّر تلك السلسلة من الأحداث معنى الاستعادة، وفقًا لروس فيليبيك، مسؤول أمن المعلومات الرئيسي في Corsica Technologies، الذي تحدث إلى CSO Online عن الحادث. وقال إن إعادة بناء الأصول المحذوفة لا تكفي، لأن طلبات مفاتيح التخزين اللاحقة قد تخلق مسارًا آخر إلى البيانات؛ فعلى المستجيبين تحديد الهويات والمفاتيح التي طالها الأمر ومراجعة استخدامها قبل الوثوق بالخدمات المستعادة. وقال فيليبيك لـ CSO Online: «بمجرد أن يمتلك المهاجمون هوية تطبيق، قد تبدو أنشطتهم كإدارة سحابية عادية».

كيف ظهرت بيانات الاعتماد

لم تتمكن Microsoft من تأكيد ناقل الوصول الأولي. وما وجدته هو انكشاف: فقد ظهر معرّف العميل والسر الخاص بالعميل ومعرّف المستأجر لأحد كيانات الخدمة الرئيسية بنص صريح في مشكلة عامة على GitHub، نشرها موظف في المؤسسة المتأثرة. تم تعديل المشكلة لاحقًا، لكن Microsoft قالت إن السر ظل متاحًا عبر سجل التعديلات العام للمشكلة. ويذكر التقرير بوضوح أن Microsoft لم تتمكن من تأكيد ما إذا كان هذا السر هو المستخدم.

التحذير المرفق بذلك الاكتشاف هو الجزء العملي. وتقول Microsoft إن بيانات الاعتماد التي جرى كشفها علنًا ينبغي التعامل معها باعتبارها مخترقة، وإلغاؤها أو تدويرها فورًا، والتحقيق في أي استخدام سابق لها؛ فإزالة سر مكشوف أو حجبه لا يبطله، وتبقى بيانات الاعتماد المكشوفة علنًا قابلة للاستخدام إلى أن يتم إلغاؤها أو تدويرها.

كما وصفت Microsoft أيضًا استكشافًا أوسع من البنية التحتية المرتبطة بـ Storm-3168 منذ أوائل 2026 ضد Azure App Services عند إدارة WordPress، وPHP-CGI، ونقطة نهاية Langflow /api/v1/validate/code، ومسارات شبيهة بـ webshell. لم تتداخل تلك الأهداف مع اشتراكات الضحية، ولم يجد 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 بأنه أول حالة موثّقة لبرامج فدية «وكيلية» — «عملية ابتزاز كاملة يُديرها نموذج لغوي كبير من البداية إلى النهاية» — وقال إن قدراته مصدرها وكيل ذكاء اصطناعي لا مجموعة أدوات يديرها إنسان. وفي ذلك الاختراق، استغل الفاعل CVE-2025-3248 في نسخة Langflow متاحة على الإنترنت، وشفّر 1,342 عنصرًا من عناصر تهيئة Nacos باستخدام الدالة المدمجة في MySQL AES_ENCRYPT()، وأسقط الجداول الأصلية، وترك جدولًا 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: موكّلان خدميان مخترقان في مستأجر واحد؛ أكثر من 300 عملية قراءة ناجحة على مدى نحو 15 ساعة ونصف؛ أكثر من 100 محاولة لحذف حسابات التخزين نجحت معظمها؛ حذف Key Vault وFunction App وخطة App Service؛ محاولات حذف قواعد بيانات SQL التي فشلت جميعها بسبب إصدار API غير مدعوم؛ حسابات تخزين أُنقذت بفضل أقفال الموارد وحماية الحذف؛ أكثر من 30 طلب ListKeys ناجح بعد عملية التدمير؛ بيانات اعتماد الموكل الخدمي بنص صريح في مشكلة GitHub عامة وفي سجل تعديلاتها؛ لم تُلاحَظ أي مذكرة فدية؛ ولم يُؤكَّد أي تسريب.

وفق تقييم مايكروسوفت: أن النشاط يخص Storm-3168؛ وأن الجمع بين الحذف والتدخل في الاسترداد وجمع المفاتيح يتسق مع برامج الفدية والابتزاز؛ وأن التنفيذ كان على الأرجح آليًا أو مكتوبًا كسكربت؛ وأن المفاتيح المجمعة قد تدعم تسريبًا مستقبليًا. لا يصف تقرير مايكروسوفت العام وكيلًا مستقلًا يستدل عبر الخطوات الخاصة بـ Azure.

مفتوح: كيف تم اختراق هويات الخدمة لأول مرة؛ وهوية الضحية وعدد المؤسسات المتأثرة؛ وما إذا كانت أي بيانات قد غادرت المستأجر؛ وما إذا كان وكيل ذكاء اصطناعي، بدلاً من نص برمجي، قد وجّه عمليات Azure نفسها.

وضعت Cloud Security Alliance فجوة الأدلة بدقة في مذكرتها المؤرخة 28 سبتمبر: فقد كتبت أن توصيف «الوكيلي» يقوم حالياً «على الدقة والإيقاع وتقسيم العمل عبر الهويات»، بدلاً من آثار استدلال الوكيل التي جرى التقاطها. والأدلة التي استخدمتها Sysdig في يوليو — حمولات تسرد ذاتها ودورة سريعة من التشخيص والتصحيح — غائبة عن السجل العام لحملة Azure. وقال نيك تاوسيك من شركة الأمن Swimlane لـ CSO Online إن أدلة Azure تُظهر «أتمتة منسقة بدلاً من إثبات أن الذكاء الاصطناعي وجّه كل خطوة».

استخدمت التغطية الإعلامية للكشف صياغة أقوى. فقد وصف عنوان BleepingComputer «هجمات ذكاء اصطناعي وكيلية» على Azure، ووصف عنوان Dark Reading «فاعل ذكاء اصطناعي» يخترق مستأجر Azure؛ في حين يقول تقرير مايكروسوفت نفسه إن التوقيت وتقسيم العمل «يشير بقوة إلى تنفيذ آلي أو مبرمج بنص برمجي»، ولا ينسب الخطوات الفردية في Azure إلى وكيل.

يُقيّم الأرشيف هذا السجل بدرجة ثقة A ولا يضع عليه علامة كونه محل نزاع. ويعتمد وسم مشاركة الذكاء الاصطناعي «المؤكَّدة» في هذا السجل على نسبته إلى JADEPUFFER، الفاعل الذي وثّقته Sysdig بأنه مدفوع بنموذج لغوي كبير؛ وهو ليس ادعاءً بأن مايكروسوفت التقطت استدلال وكيل أثناء عمليات الحذف في Azure. فالضرر ثابت، والأتمتة ثابتة، والاستقلالية مستنتجة.

ما تقول Microsoft إنه ينبغي تغييره

توصيات Microsoft تشغيلية، وهي تنبثق مباشرة من طريقة عمل هذا الاختراق. وهي تطلب من المدافعين تمكين خطط Microsoft Defender for Cloud ذات الصلة لـ Resource Manager وStorage وKey Vault وApp Service وقواعد البيانات؛ وإبقاء بيانات اعتماد كيان الخدمة الرئيسي ومفاتيح التخزين وسلاسل الاتصال والأسرار الأخرى خارج الشيفرة المصدرية والتكوين والمستودعات والمشكلات؛ واستخدام Microsoft Entra Workload ID بدلاً من الأسرار طويلة الأمد؛ وتطبيق مبدأ الامتياز الأقل ومراجعة تعيينات Azure RBAC لهويات حمل العمل؛ وتقييد ومراقبة موارد النسخ الاحتياطي والاسترداد، بما في ذلك محاولات تغيير ضوابط الحماية الخاصة بها.

لا يوضح تقرير Microsoft العام ما إذا كان المستأجر قد استعاد بياناته، أو ما إذا كان قد تم إخطار الضحية، أو ما إذا كان قد تم استخدام أي من المفاتيح التي جُمعت لاحقًا. هذه النتائج ليست في السجل. ما يحمله السجل هو تباين قابل للقياس: فقد منعت أقفال الموارد والحماية من الحذف بعض عمليات الحذف حتى ضد هويات ذات امتيازات واسعة، بينما أُنجيت قواعد بيانات SQL بخطأ في إصدار API بدلًا من قرار اتخذه أحد المدافعين. لا يذكر تقرير Microsoft ما فعله المستأجر بعد ذلك. لكنه يذكر أن الفاعل أمضى أكثر من 15 ساعة في القراءة قبل أن يمضي سبع دقائق في الحذف.