في القسم الأخير من سلسلة المدونات هذه حول الكشف عن الهجمات السحابية المختلطة المعقدة، سنشارك العناصر الأساسية للرد على الهجوم السحابي المتطور الواقعي الموضح في الجزء 2. ولحماية هوية المنظمة الضحية، تم تعديل بعض تفاصيل الهجوم ودمجها مع هجمات أخرى شوهدت على أرض الواقع، ولكن تم تنفيذ كل مرحلة من دراسة الحالة المقدمة من قبل مهاجمين ومستجيبين حقيقيين.
من خلال تحليل جهود الاستجابة أثناء تطورها من منظور المدافع، يمكننا تسليط الضوء على كيفية الاستفادة من الاستجابة للحوادث المستندة إلى المعلومات الاستخبارية لهزيمة حتى الهجمات الأكثر تعقيدًا.
ننتقل الآن إلى جهود الاستجابة للحادث والتحقيق التي قامت بها المنظمة الضحية. وبدلاً من تفصيل كل عنصر من هذه الجهود الطويلة، سينصب تركيزنا على التحديات الرئيسية التي نواجهها بسبب الطبيعة الهجينة وطويلة الأمد للهجوم، والطرق التي تم حلها بها في النهاية من خلال الاستفادة من الاستجابة الفعالة للحوادث المستندة إلى المعلومات الاستخبارية.
الكشف الأولي ومعالجة السحابة
بدأ فريق الأمان التابع للمؤسسة الضحية في التحقيق في الهجوم لأول مرة عندما لاحظ مهندس سحابي يعمل على مثيل EC2 في بيئة إنتاج AWS أن سجلات نظام التشغيل المحلية مفقودة من المثيل. في محاولة لمعرفة ما حدث للسجلات المفقودة، تم تصعيد التحقيق في النهاية إلى أعضاء فريق الأمان الذين قاموا بتوسيع نطاقهم وحددوا حالات شاذة مماثلة في حالات EC2 المتعددة.
وبعد إجراء مزيد من التحقيق، أخذوا لقطة من AMI لواحدة من هذه الحالات واتبعوا قواعد اللعبة الجنائية الخاصة بهم لتحليلها. حدد هذا التحليل القذائف العكسية التي خلفها المهاجمون وراءهم، وقاد المحققين على الفور إلى فهم أنهم كانوا يتعاملون مع حادثة كبيرة.
بالإضافة إلى القلق الفوري الناتج عن الاختراق المكتشف حديثًا لمثيلات EC2 الحساسة للإنتاج، كان الفريق مهتمًا للغاية بالكشف عن السبب الجذري للحادث. من خلال الإسناد الترافقي للطوابع الزمنية للإنشاء للهياكل العكسية للمهاجمين المحددين وسجلات AWS CloudTrail، والتي تم الاحتفاظ بجزء منها فقط في SIEM التنظيمي للإطار الزمني ذي الصلة لأكثر من عام مسبقًا، تمكن المحققون من تحديد النمط المشبوه.
قبل وقت قصير من وضع الأصداف العكسية الضارة على العديد من مثيلات EC2، أجرى نفس مستخدم AWS IAM عملية “GetPasswordData” تستهدف تلك المثيلات نفسها. ستزود هذه العمليات كل من قام بتشغيلها بكلمات مرور المسؤول المحلي لمثيلات EC2 المستهدفة، مما يتيح له الوصول الكامل لتثبيت الأصداف العكسية وحذف سجلات نظام التشغيل المحلي بشكل مستمر.
وبعد اكتشاف هذا الارتباط، تحول المحققون إلى فحص بقية أنشطة مستخدم IAM المشتبه به. على الرغم من أن الرؤية الكاملة لم تكن ممكنة بسبب قيود الاحتفاظ بالسجل، فقد تم تحديد الوصول إلى حاويات S3 وقواعد بيانات RDS شديدة الحساسية. لا يزال النطاق الكامل لهذا الوصول والبيانات التي تم سحبها بالضبط غير معروف حتى يومنا هذا، وذلك بسبب تعديلات سياسة التدقيق التي أجراها المهاجمون.
ومع إدراك أن كل خطوة من خطوات الهجوم يبدو أنه قد تم تنفيذها من خلال الوصول إلى مستخدم IAM الوحيد ذي الامتيازات، شرعت المنظمة في تغيير بيانات الاعتماد الخاصة بها. وكإجراء احترازي إضافي، تم تدوير جميع بيانات اعتماد AWS المميزة وتم عزل جميع مثيلات EC2 التي وصل إليها المهاجمون واستعادتها من إصدارات النسخ الاحتياطي الآمنة التي تم التحقق منها.
بالإضافة إلى ذلك، تمت استعادة سياسات التسجيل التي تم العبث بها، وتم تكوين تسجيل إضافي بما في ذلك سجلات تدفق VPC، وتمت إضافة قواعد اكتشاف محددة إلى SIEM. ومع مرور أسابيع منذ أنشطة الاستئصال والمعالجة الأولية هذه وعدم اكتشاف أي نشاط ضار آخر، بدا أنه تم التعامل مع الهجوم بفعالية.
عودة المهاجمين
بعد عدة أسابيع من انتهاء جهود الاستجابة الأولية، تفاجأ أعضاء فريق الأمان برؤية أحد التنبيهات التي تم إنشاؤها حديثًا يتم تشغيلها – كان شخص ما يحاول تعديل سياسات التدقيق في قواعد بيانات RDS مرة أخرى.
كشفت عملية الفرز السريعة أن مستخدم IAM نفسه الذي تم اختراقه سابقًا والذي كان يقوم بالعمليات، دون معرفة أو موافقة أي من أعضاء فريق الهندسة السحابية أو فرق التطوير.
كشف تحليل أعمق للسجلات أن هذا المستخدم كان يقوم بسحب البيانات من قاعدة بيانات RDS الحساسة لمدة ثلاثة أيام قبل محاولة إعادة تعديل سياسات التدقيق، ونجح في سرقة معلومات حساسة جديدة قبل اكتشافها.
نظرًا لأن الفريق قام بسرعة بمعالجة سياسات التدقيق المتغيرة وإعادة تدوير بيانات اعتماد مستخدم IAM المخترقة، فقد أصبح لديهم الآن الكثير من المعلومات لمحاولة تحديد السبب الجذري. تم إجراء أحدث وصول ضار باستخدام مفتاح وصول AWS الجديد الذي تم إصداره للمستخدم المخترق بعد التحقيق السابق، مما يشير إلى تعرضه للاختراق مرة أخرى.
لم تكشف محاولات التحقيق في الوصول إلى سر AWS Secrets Manager الذي خزن بيانات الاعتماد الجديدة عن أي وصول غير عادي – تم الوصول إلى المفتاح فقط من عناوين IP المعروفة بواسطة مستخدمين ينتمون إلى موظفي التطوير والهندسة السحابية. أثارت هذه النتيجة خوفًا جديدًا في أذهان كبار المسؤولين التنفيذيين الذين اطلعوا على الوضع: هل يمكن أن يكون هذا تهديدًا من الداخل؟
من المعروف أن التحقيقات في التهديدات الداخلية صعبة للغاية، وقد يستغرق حل المشكلة التي تلت ذلك شهورًا بينما تفتقد القصة الحقيقية لهذا الهجوم. ولحسن الحظ، كان لدى المستجيبين للحوادث سبيل تحقيقي آخر لاستنفاده، وهو الاستفادة من معلومات التهديدات لدفع التحقيق.
في هذه المرحلة، لم يكن لدى المحققين سوى القليل من المعلومات بشأن المهاجمين الذين يقفون وراء التسوية. وكانت المعلومة الرئيسية الوحيدة التي حصلوا عليها هي مجموعة صغيرة من عناوين IP التي استفاد منها المهاجمون طوال الهجوم.
في حين أن عناوين IP المستخدمة للوصول إلى معظم الخدمات السحابية تنتمي إلى خدمات VPN المعروفة لإخفاء الهوية، فقد تم تمكين سجلات تدفق VPC بعد أن كشف التحقيق السابق الآن عن عناوين C2 IP التي كانت تتواصل معها القذائف العكسية للمهاجم. كشفت الإسناد الترافقي لعناوين IP هذه مع العديد من محركات استخبارات التهديدات العامة عن خادم HTTPS والذي من المحتمل أن يكون بمثابة C2 الرئيسي للمهاجمين.
أدى تحديد هذا الخادم إلى تمكين إجراء مزيد من التحليل وجمع معلومات التهديد، وكشف عن تثبيت شهادة SSL ذات خصائص فريدة عليه. وعلى وجه التحديد، تضمن حقلا “الصادر عن” و”الصادر إلى” في الشهادة أسماء غير شائعة. ومن خلال الاستفادة مرة أخرى من محركات استخبارات التهديدات العامة، أجرى المحققون فحصًا على مستوى الإنترنت لتحديد أي خوادم أخرى قد تستخدم شهادات SSL بنفس الخصائص الفريدة. كشفت هذه الخطوة عن اكتشاف مثير – حيث تم العثور على خادم واحد آخر على الإنترنت لديه شهادة SSL مطابقة.
ومع إدراكهم أن هذا الخادم الذي تم تحديده حديثًا من المحتمل أن يكون مملوكًا لنفس المهاجم، أجرى المحققون بحثًا واسع النطاق عبر SIEM لتحديد أي اتصال محتمل بعنوان IP الخاص بالخادم. بدلاً من الكشف عن المزيد من الأدلة على وجود اختراق في بيئة الإنتاج السحابية، أدى هذا البحث إلى نتيجة مفاجئة – كان هناك جهاز داخل بيئة الشركة المحلية يتواصل مع عنوان IP هذا من خلال جدار الحماية التنظيمي.
كان هذا الجهاز عبارة عن خادم سريع تم اختراقه من قبل المهاجمين في المراحل الأولى من الهجوم. لم تكن هذه النتائج ممكنة دون اتباع نهج حقيقي قائم على الاستخبارات في الاستجابة للحوادث. أدى الجمع بين الاستخبارات العامة والداخلية مع تحليل السجل الكلاسيكي إلى تحقيق تقدم حاسم في التحقيق، وهو ما لم يكن ممكنًا في هذه الحالة وغيرها الكثير.
بعد أن شعروا بسعادة غامرة بالنتائج الجديدة، تمكن المحققون بسرعة من التعرف على الغلاف العكسي الذي قام المهاجمون بتثبيته على خادم الانتقال. لقد فهموا الآن لماذا لم يكن تدوير بيانات اعتماد AWS المخترقة مفيدًا لهم كثيرًا. نظرًا للطبيعة الهجينة للهجوم، عاد المهاجمون ببساطة إلى خادم الانتقال وانتظروا حتى يستخدمه شخص ما ويعيد إليهم بيانات الاعتماد مباشرة.
نظرًا لعدم تمكنه من التحقيق بشكل كامل في الاختراق الأصلي لخادم الانتقال بسبب قيود الاحتفاظ بالسجل، قام الفريق مع ذلك بإزالة الغلاف العكسي، وأعاد تدوير بيانات الاعتماد المخترقة، واعتقد أنهم هزموا الهجوم.
الكشف عن مسار الهجوم الكامل
عندما تم إطلاق نفس التنبيه لتعديل سياسات تدقيق RDS مرة أخرى بعد بضعة أسابيع، كان فريق الأمان يصل إلى مستوى جديد من الإحباط. كشف الفرز الفوري أن مستخدم IAM نفسه كان يستهدف RDS مرة أخرى، دون علم أي من فرق التطوير أو الفرق الهندسية. وبتتبع خطواتهم، وجد المحققون دليلاً على وجود هياكل عكسية جديدة على نفس خادم القفز الذي تم اختراقه سابقًا، ويتواصل هذه المرة مع عناوين IP الجديدة للمهاجم. تم تثبيت هذا الغلاف العكسي بعد وقت قصير من أنشطة الإزالة والمعالجة السابقة، مما يعني أنه هذه المرة كان بالتأكيد ضمن فترات الاحتفاظ بالسجل.
أثناء إجراء التحليلات الجنائية على خادم الانتقال، تمكن الفريق من ربط إنشاء الغلاف العكسي الجديد بجلسة RDP الخاصة بموظف عمليات التطوير من Citrix VDI. لسوء الحظ، فإن VDI سريع الزوال من حيث التصميم وقد اختفى منذ وقت طويل بحلول وقت التحقيق.
تعثر أعضاء فريق الأمن مرة أخرى بشأن كيفية المتابعة، فحاولوا السلام عليك وسألوا موظف التطوير إذا كان بإمكانهم التحقق من الكمبيوتر المنزلي الشخصي الذي كان يستخدمه للوصول إلى Citrix. كان الموظف المرتبك قليلاً سعيدًا في النهاية بالتعاون وقدم الجهاز لمراجعته من قبل الفريق.
بمجرد حصولهم على الكمبيوتر الشخصي الخاص بالموظف، كان كشف بقية القصة عملاً سهلاً بالنسبة للمستجيبين ذوي الخبرة للحوادث. وسرعان ما كشفت الأدلة الجنائية عن الحمولة الخبيثة الأولية التي لا تزال تعمل على الجهاز، وتتواصل مع عنوان IP نفسه الذي تم الكشف عنه من خلال تحليل استخبارات التهديدات الذي أجراه الفريق.
وبعد طلب إذن الموظف، تمكن المحققون أخيرًا من تحديد رسائل الهندسة الاجتماعية والتصيد الاحتيالي الأصلية التي حرضت على الهجوم بأكمله. وبعد عامين تقريبًا من بدايته، أدركت الشركة أخيرًا نطاق هذا الهجوم المتطور السحابي والمكاتب المنزلية. يصور الشكل 1 العملية رفيعة المستوى لكشف الهجوم التي قام بها المستجيبون للحادث.
خاتمة
وبمراقبة جهود التحقيق الكاملة، يصبح من الواضح تمامًا أن مثل هذه النتيجة الشاملة لم يكن من الممكن الحصول عليها إلا بسبب المزيج الفعال من تحليل السجل الكلاسيكي، والطب الشرعي، واستخبارات التهديدات العامة، وبيانات الاستخبارات الداخلية. تعمل دراسة الحالة هذه على تسليط الضوء على التأثيرات الهائلة المحتملة للاستفادة بشكل فعال من الاستجابة للحوادث المستندة إلى المعلومات الاستخبارية للتحقيق في الهجمات الإلكترونية السحابية المتطورة.
غالبًا ما يتطلب سطح الهجوم المحتمل الواسع للتسوية الأولية، إلى جانب السهولة التي يهيمن بها المهاجمون على البيئات الهجينة المحلية والسحابية، استخدام المعلومات الاستخبارية العامة والخاصة من أجل تحقيق تحقيق هادف. إن الجمع بين الحلول المركزية لإدارة الاستخبارات الداخلية مع الاستفادة من استخبارات التهديدات السيبرانية العامة، يمكن أن يحدث فرقًا بين النجاح والفشل في تحديد الأسباب الجذرية للهجوم والقضاء عليها.
عند تنفيذها بهذا الشكل الدؤوب، توفر الاستجابة للحوادث المستندة إلى المعلومات الاستخبارية لمحترفي الأمن فرصة القتال ضد مشهد التهديدات المتطور والسريع التطور.
