أظهرت Microsoft أن اختراق هوية واحدة قد يتحول إلى مسار وصول واسع داخل بيئات التطوير والسحابة، حتى من دون استخدام برمجيات خبيثة أو استغلال ثغرات. ففي تقرير جديد ضمن سلسلة Cyberattack Series، وثّق فريق Microsoft Detection and Response Team (DART) تحرك مجموعة Storm-3068 من حساب مخترق إلى Azure DevOps وخطوط التطوير وموارد Kubernetes.
بدأ التسلل عبر عملية إعادة تعيين كلمة مرور ذاتية الخدمة. وبعد الوصول إلى حساب المستخدم، سجّل المهاجم وسائل مصادقة خاصة به، ما منحه وصولاً مستمراً إلى الهوية. ثم استخدم أدوات إدارية مشروعة ونصوصاً آلية لجرد المستودعات والمشروعات وخطوط الأنابيب وبيئات النشر في Azure DevOps.
من الهوية إلى مسارات النشر
كان Azure DevOps نقطة عالية القيمة لأنه يربط بين الهوية وتطوير البرمجيات وتشغيل السحابة. ومن خلال رسم خريطة لمسارات النشر والموارد المرتبطة بها، حدد Storm-3068 طرقاً للانتقال إلى أجزاء أخرى من البيئة.
اكتشف المحققون خط أنابيب خبيثاً صُمم لجمع بيانات اعتماد Kubernetes على نطاق واسع. نشر الخط وكيلاً لـ Kubernetes ونفذ وظائف متعددة لجمع ملفات kubeconfig التي تتضمن تفاصيل الاتصال بالعناقيد وبيانات المصادقة. وبفضل صلاحيات الحساب المخترق، كان الخط مخولاً بالوصول إلى أكثر من 50 مورداً والمصادقة على خدمات مختلفة.
كما عُدّلت نصوص خطوط الأنابيب لتثبيت وكيل الإدارة عن بُعد Atera وتنزيل أداة إنشاء الأنفاق Chisel. واستُخدمت أوامر Chisel لإنشاء نفق عكسي إلى عنوان IP خارجي، بما أتاح احتمال التفاعل عن بُعد مع عناقيد Kubernetes. وأعاد فريق التحقيق بناء المرحلة التالية من الهجوم بالاعتماد على سجلات تدقيق Azure DevOps وسجل إصدارات Git، حيث أُضيفت سبعة ملفات kubeconfig مسروقة إلى مستودع.
ما الذي تكشفه الحالة للمدافعين؟
تكمن أهمية الحادثة في أن نقطة الاختراق الأولى لم تكن كافية وحدها لتفسير حجم الوصول النهائي. الخطر نشأ من الترابط بين أنظمة الهوية والمستودعات وخطوط البناء والنشر والبنية التشغيلية. لذلك فإن تأمين كل طبقة بمعزل عن الأخرى لا يضمن احتواء حساب مخترق إذا كانت صلاحياته تفتح مسارات موثوقة إلى طبقات لاحقة.
استجاب DART بتحليل البيانات من أنظمة الهوية ومنصات التطوير والبنية السحابية، وعمل مع العميل عبر إحاطات يومية وتوجيهات مرتبة حسب الأولوية للاحتواء والمعالجة. كما تعاون مع Microsoft Threat Intelligence لوضع النشاط في سياقه الأوسع.
إجراءات دفاعية عملية
- مراقبة نشاط إعادة تعيين كلمات المرور بحثاً عن محاولات متكررة أو أنماط تستهدف عدة مستخدمين.
- تقليل تعرض الحسابات ذات الصلاحيات العالية لمسارات إعادة التعيين الذاتي، وفرض مصادقة متعددة العوامل مقاومة للتصيد.
- اشتراط الموافقة على تغييرات الشفرة وتفعيل حماية الفروع لمنع التعديلات غير المصرح بها.
- تقييد الالتزام المباشر بالفروع الحرجة وإلزام التغييرات بمراجعة واعتماد واضحين.
- ضبط صلاحيات خطوط البناء والنشر وتحديد من يمكنه إنشاؤها أو تعديلها أو تشغيلها.
- تطبيق مبدأ أقل الصلاحيات على الهويات ومنصات التطوير والموارد السحابية للحد من أثر اختراق حساب واحد.
لماذا يهم هذا الخبر؟
توضح هذه الحالة أن سجلات الهوية وAzure DevOps وGit وبيئات Kubernetes يجب أن تُقرأ كصورة أمنية مترابطة، لا كمصادر منفصلة. أما الأسئلة المفتوحة التي يثبتها المصدر فتتعلق بمدى قدرة المؤسسات على اكتشاف إساءة استخدام الأدوات المشروعة، ومراجعة الصلاحيات العابرة للبيئات، ومنع تسرب ملفات الاعتماد إلى المستودعات قبل استخدامها للوصول إلى الإنتاج.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.