يبحث المهاجمون باستمرار عن طرق جديدة لاستهداف البيئات السحابية وتصعيد الوصول الأولي إلى امتيازات إدارية كاملة.
في الأشهر الأخيرة، لاحظ فريق البحث لدينا ارتفاعًا في محاولات تصعيد الامتيازات بدءًا من الوصول إلى مجموعات Kubernetes إلى مستويات التحكم السحابية، مما يخلق مخاطر كبيرة للعديد من المؤسسات. نظرًا لأن الحاويات غالبًا ما تفتقر إلى ضوابط الرؤية والوقاية المطبقة بشكل شائع على موارد الحوسبة التقليدية، فإن هذا التوسع في سطح الهجوم السحابي يمكن أن يمثل تحديًا بشكل خاص.
يسلط الهجوم الأخير الذي هزمه فريق البحث الضوء على أهمية الاكتشافات الإرشادية عبر السحابة وقدرات الاستجابة الفورية لمكافحة هذه التهديدات المتزايدة. ولحماية هوية المنظمة الضحية، تم تعديل بعض تفاصيل الهجوم، ولكن تم تنفيذ كل مرحلة من مراحل دراسة الحالة المقدمة من قبل مهاجمين ومستجيبين حقيقيين.
كشف التهديدات
تم إجراء التحقيق من خلال اثنين من هجمات TTP الخاصة بالمهاجمين التي تم اكتشافها في بيئة إنتاج حساسة لدى AWS:
-
يتم استخدام دور IAM لمثيل EC2 من عنوان IP مصدر غير منتظم في AWS.
-
يتم تنفيذ إجراءات الاستطلاع الظاهرة بواسطة نفس الدور الذي يستعلم عن مثيلات EC2 ومجموعات الأمان المتعددة.
على الرغم من أنه ربما لم يتم تصنيف كل من هذه الإجراءات على أنها مشبوهة للغاية في حد ذاتها، فقد حدد التحليل الإرشادي المستند إلى خطوط الأساس للمخزون البيئي الدور على أنه دور ينتمي إلى مثيل EC2 الذي يقوم بتشغيل حجرة EKS. وكانت هذه الحقيقة أساسية لاكتشاف الهجوم مبكرًا – حيث تم تحديد الإجراءات التي قد تكون شائعة أو مشروعة عند تنفيذها بواسطة أدوار أخرى في البيئة بشكل صحيح على أنها سلوك مشبوه لدور IAM المحدد.
مع تحديد هذا النشاط الأولي، تحول المدافعون إلى عملية فرز سريعة وقرروا أنه لا يوجد سبب مشروع لهذا الدور للقيام بالإجراءات المكتشفة. ومع انتقال الفريق إلى التحقيق الكامل، أصبحت الأسئلة الرئيسية هي ما إذا كان من الممكن اختراق هذا الدور وكيف. وبدون حل سريع وحاسم لهذا اللغز، واجه الفريق معضلة مألوفة في الاستجابة للحادث: هل نرد واحتواء النشاط المشبوه قبل معرفة كل الحقائق؟
إن الاستجابة السريعة لها فائدة واضحة تتمثل في إمكانية منع المزيد من الضرر، ولكن القيام بذلك دون سياق غالبًا ما يؤدي إلى تدابير احتواء غير فعالة لا تؤدي إلا إلى إعلام المهاجمين بأنه يتم التحقيق معهم وتسريع هجومهم. هذا هو المكان الذي أصبح فيه التحقيق السياقي السريع أمرًا بالغ الأهمية.
التحقيق والرد
من خلال سحب خيط الأحداث المشبوهة الأولية، تمكن الفريق من الاستفادة من السياق من سجلات CloudTrail، وسجلات VPC Flow، والأدوات الجنائية من مثيل EC2، لتجميع أجزاء اللغز معًا بسرعة. نظرًا للتكوين الافتراضي الذي تم تركه في مكانه، تم السماح لوحدات EKS بالاتصال بخدمة بيانات تعريف المثيل (IMDS) على مثيل EC2 المضيف الخاص بها. قبل وقت قصير من بدء نشاط الاستطلاع، مع الاستفادة من دور مثيل EC2 المخترق، أظهرت سجلات نظام التشغيل المحلي أنه يتم الوصول إلى خدمة بيانات تعريف المثيل من المثيل – مما يتيح للمهاجم الذي يصل إليها تصعيد وصول الجهاز للتحكم في دور IAM.
كشفت أدلة الطب الشرعي والسجل أيضًا أن مثيل EC2 كان يشغل تطبيقًا مفتوح المصدر يحتوي على برنامج CVE لتنفيذ التعليمات البرمجية عن بُعد والذي تم نشره مؤخرًا. تم استغلال هذا CVE بنجاح من خلال الفحص المفترض قبل ساعات فقط من اختراق دور IAM لمثيل EC2.
كما حدث، تم تشغيل هذا التطبيق مفتوح المصدر خصيصًا من قبل فريق DevOps خلف مجموعة أمان تمنع أي وصول من الإنترنت. لكن هذا تغير في يوم الهجوم. لسوء الحظ، تم نشر خدمة مواجهة الإنترنت على نفس الشبكة الفرعية مثل التطبيق مفتوح المصدر الضعيف، مما أدى إلى تعديل نفس مجموعة الأمان التحكم في الوصول إلى كلا الجهازين.
خاتمة
تعمل دراسة الحالة هذه على تسليط الضوء على أهمية الكشف والاستجابة السريعة والإرشادية والدقيقة والسياقية في السحابة. بالإضافة إلى النقاط الواضحة المتمثلة في تنفيذ إدارة فعالة للثغرات الأمنية وفصل تطبيقات الإنتاج، يجب علينا أن نتقبل حقيقة أن الأخطاء والتكوينات الخاطئة لا تزال تحدث.
وترتفع المخاطر بشكل خاص من الهجمات التي تستفيد من التهديدات الخطيرة التي تم إصدارها حديثًا أو التطبيقات قليلة المراقبة، مثل هذا الهجوم الذي يستهدف Kubernetes. وبالتالي فإن القدرة على اكتشاف الأحداث الشاذة المعقدة في السحابة مركزيًا وفرزها سريعًا ليست مجرد “أمر جميل” ولكنها متطلب حيوي لاستراتيجية أمان سحابية ناجحة.
