:Memory Forensics
Hunting Cobalt Strike in Memory
عمر العنزي
5/9/2023
5/9/2023
المقدمة:
تقريبًا كل عملية اختراق أو تسرب بيانات تدل على استخدام Cobalt Strike بطريقة أو بأخرى. على سبيل المثال لا الحصر، يعد هجوم HAFNIUMواختراق SolarWinds والعديد من هجمات Ransomware أمثلة جيدة على استخدام Cobalt Strike. كان اختيار Cobalt Strike كموضوعنا اختيارًا سهل جداً ، نظرًا لأن كل (APT) يستخدم Cobalt Strike في مجموعة الأدوات الخاصة بهم. تُظهر تقارير التهديدات الصادرة عن MITER Attack وCrowdStrike Threat Report وMicrosoft وTalos وغيرها دليلاً واضحًا على أن APT تستخدم Cobalt Strike بكثرة. Cobalt Strike عبارة عن مجموعة من Red Teaming & Adversary Simulation، توفر منصة Cobalt Strike ميزات متقدمة جدا. يتم استخدام Cobalt Strike بكثرة لأنها تتضمن كل ما يحلم به المهاجم، منصة مستقرة وقابلة للتخصيص للغاية ومصممة لدعم الاستغلال طويل المدى على نطاق واسع جدًا.
كما يقول Raphael Mudge مبرمج Cobalt Strike :
"قد يفحص منتج مكافحة الفيروسات التقليدي my payload عندما أقوم بتحميل ملف على القرص أو تحميل المحتوى في المتصفح. إذا هزمت ذلك، سأفوز. ليس كذلك اليوم! الآن ساحة المعركة هي functions التي نستخدمها للحصول على our payload في الذاكرة."
كما ذكر Raphael Mudge سابقاً ، يعمل Cobalt Strike بشكل اساسي في الذاكرة عند تشغيل initial Loader الخاص به. يشكل هذا النمط من Execution تحدياً جديداً للمختصين بالأمن السيبراني. ويمثل هذا ايضاُ تحديداً للعديد من منتجات مكافحة الفايروسات لأن Memory Scan ليس بالأمر السهل. لهذا السبب ، نرى حاجة متزايدة للتقنيات End Point Detection & Response نظراً لقدرتها على عمل Memory Scan والقدرة على اكتشاف الانشطة والسلوكيات الخاصة بالبرمجيات الخبيثة مثل Cobalt Strike.
المفهوم ان الذاكرة هي ساحة المعركة الاخيره بين المهاجم والمدافع يعد مفهوم دقيق جداً. لأنه ، كما نعرف ، ان الـCode يجب يتم تنفيذه في مكان ما ، ويعمل المخترقون باستمرار على تحسين اساليبهم للتخفي من كل انظمة الحماية. اصبحت عملية Detection عملية ومهمة صعبة. الفشل في تحديد او كشف المهاجم في هذه المرحلة بالذات لا يعني خسارة المعركة فقط بل الحرب. في هذه المقالة سوف نتطرق للتقنيات المستخدمة في Cobalt Strike وخصوصا في الذاكرة. ونركز اكثر على مايميز Cobalt Strike عن بقية الـ C2 Frameworks
التحليل الرقمي الجنائي للذاكرة: كيف تعرفت على Your Beacon
في عالم التحليل الجنائي الرقمي ، يعد اتباع نهج منظم أمراً ضرورياً جدا ، والتحليل الجنائي الرقمي للذاكرة ليس استثناءً هنا. باعتبارك محلل DFIR فأنت بحاجة الى نقطة بداية لبداية التحقيق. ينطبق نفس المفهوم على الذاكرة ايضاً – فأنت تحتاج الى سبب واضح او Hint للتعمق في تحليل الذاكرة. من غير هذا التوجه والشروع مباشرة في عمل تحليل جنائي رقمي للذاكرة يشبه تماماً Looking for a needle in a haystack وهي مهمة صعبة جداً وتستغرق وقتاً وجهد. تمثل هذه النقطة المحورية ارشاداً للمحللين حيث تقودهم خلال رحلة الاكتشاف عن الأدلة المهمه. وهذا يؤكد على ضرورة اتباع منهجية نظامية للكشف عن السلوكيات الضارة في الذاكرة.
قبل التعمق في تحليل الذاكرة ، قد يكون البحث عن Cobalt Strike مهمة صعبة ، فهناك ادوات يمكن ان تساعد في تسريع عملية اكتشاف Cobalt Strike. يمكن ان توفر هذه الادوات الكثير من الوقت والجهد مقارنة في عمل تحليل يدوي لكل الذاكرة وايضا تساعد في تحديد نقطة البداية للتحقيق كاملاً. على انه من الممكن عمل تحليل يدوي على كل الذاكرة والتعمق بالتحليل دون استخدام هذه الادوات ، نظراً لوجود بعض الـ Signature والسلوكيات الخاصه في Cobalt Strike. يتثمل استخدامنا للادوات للتأكد من ان Cobalt Strike موجود على النظام المراد فحصه اولاً ، ثم ننتقل الى تحليل الذاكره يدوياً. يمكن اكتشاف Cobalt Strike عن طريق مراقبة مايلي:
تقريبًا كل عملية اختراق أو تسرب بيانات تدل على استخدام Cobalt Strike بطريقة أو بأخرى. على سبيل المثال لا الحصر، يعد هجوم HAFNIUMواختراق SolarWinds والعديد من هجمات Ransomware أمثلة جيدة على استخدام Cobalt Strike. كان اختيار Cobalt Strike كموضوعنا اختيارًا سهل جداً ، نظرًا لأن كل (APT) يستخدم Cobalt Strike في مجموعة الأدوات الخاصة بهم. تُظهر تقارير التهديدات الصادرة عن MITER Attack وCrowdStrike Threat Report وMicrosoft وTalos وغيرها دليلاً واضحًا على أن APT تستخدم Cobalt Strike بكثرة. Cobalt Strike عبارة عن مجموعة من Red Teaming & Adversary Simulation، توفر منصة Cobalt Strike ميزات متقدمة جدا. يتم استخدام Cobalt Strike بكثرة لأنها تتضمن كل ما يحلم به المهاجم، منصة مستقرة وقابلة للتخصيص للغاية ومصممة لدعم الاستغلال طويل المدى على نطاق واسع جدًا.
كما يقول Raphael Mudge مبرمج Cobalt Strike :
"قد يفحص منتج مكافحة الفيروسات التقليدي my payload عندما أقوم بتحميل ملف على القرص أو تحميل المحتوى في المتصفح. إذا هزمت ذلك، سأفوز. ليس كذلك اليوم! الآن ساحة المعركة هي functions التي نستخدمها للحصول على our payload في الذاكرة."
كما ذكر Raphael Mudge سابقاً ، يعمل Cobalt Strike بشكل اساسي في الذاكرة عند تشغيل initial Loader الخاص به. يشكل هذا النمط من Execution تحدياً جديداً للمختصين بالأمن السيبراني. ويمثل هذا ايضاُ تحديداً للعديد من منتجات مكافحة الفايروسات لأن Memory Scan ليس بالأمر السهل. لهذا السبب ، نرى حاجة متزايدة للتقنيات End Point Detection & Response نظراً لقدرتها على عمل Memory Scan والقدرة على اكتشاف الانشطة والسلوكيات الخاصة بالبرمجيات الخبيثة مثل Cobalt Strike.
المفهوم ان الذاكرة هي ساحة المعركة الاخيره بين المهاجم والمدافع يعد مفهوم دقيق جداً. لأنه ، كما نعرف ، ان الـCode يجب يتم تنفيذه في مكان ما ، ويعمل المخترقون باستمرار على تحسين اساليبهم للتخفي من كل انظمة الحماية. اصبحت عملية Detection عملية ومهمة صعبة. الفشل في تحديد او كشف المهاجم في هذه المرحلة بالذات لا يعني خسارة المعركة فقط بل الحرب. في هذه المقالة سوف نتطرق للتقنيات المستخدمة في Cobalt Strike وخصوصا في الذاكرة. ونركز اكثر على مايميز Cobalt Strike عن بقية الـ C2 Frameworks
التحليل الرقمي الجنائي للذاكرة: كيف تعرفت على Your Beacon
في عالم التحليل الجنائي الرقمي ، يعد اتباع نهج منظم أمراً ضرورياً جدا ، والتحليل الجنائي الرقمي للذاكرة ليس استثناءً هنا. باعتبارك محلل DFIR فأنت بحاجة الى نقطة بداية لبداية التحقيق. ينطبق نفس المفهوم على الذاكرة ايضاً – فأنت تحتاج الى سبب واضح او Hint للتعمق في تحليل الذاكرة. من غير هذا التوجه والشروع مباشرة في عمل تحليل جنائي رقمي للذاكرة يشبه تماماً Looking for a needle in a haystack وهي مهمة صعبة جداً وتستغرق وقتاً وجهد. تمثل هذه النقطة المحورية ارشاداً للمحللين حيث تقودهم خلال رحلة الاكتشاف عن الأدلة المهمه. وهذا يؤكد على ضرورة اتباع منهجية نظامية للكشف عن السلوكيات الضارة في الذاكرة.
قبل التعمق في تحليل الذاكرة ، قد يكون البحث عن Cobalt Strike مهمة صعبة ، فهناك ادوات يمكن ان تساعد في تسريع عملية اكتشاف Cobalt Strike. يمكن ان توفر هذه الادوات الكثير من الوقت والجهد مقارنة في عمل تحليل يدوي لكل الذاكرة وايضا تساعد في تحديد نقطة البداية للتحقيق كاملاً. على انه من الممكن عمل تحليل يدوي على كل الذاكرة والتعمق بالتحليل دون استخدام هذه الادوات ، نظراً لوجود بعض الـ Signature والسلوكيات الخاصه في Cobalt Strike. يتثمل استخدامنا للادوات للتأكد من ان Cobalt Strike موجود على النظام المراد فحصه اولاً ، ثم ننتقل الى تحليل الذاكره يدوياً. يمكن اكتشاف Cobalt Strike عن طريق مراقبة مايلي:
كما ذكرنا اعلاه ، دعونا نتأكد من وجود Cobalt Strike اولا. احدى الادوات المفضلة التي استخدمها هي أداة كتبها:
Didier Stevens, 1768.py: https://didierstevens.com/files/software/1768_v0_0_18.zip
الاداة سهله الاستخدام كما هو موضح في الصورة:
كما يتضح ان الاداة تثبت قيمتها ليس فقط من خلال التحقق من وجود Cobalt Strike ولكن ايضاً بالتعمق والتعرف على المكونات الاساسية والاعدادات الخاصه بـ Cobalt Strike Beacon مثل: C2 payload, Sleeptime, Port, C2 Domain وغيرها من المعلومات والتفاصيل المهمة. هذه المعلومات تعتبر مهمه لكل محلل أمن سيبراني لأنها تساعد في عملية Scoping وتبسيط عملية التحقيق. تتجاوز الأداة كل التوقعات وتقوم بتخمين النسخة الخاصه بـ Cobalt Strike.
ملاحظة مهمة: تشير" Sacrificial Process" الى الممارسة لأستخدام احدى الـ Process على النظام الذي تم اختراقه لتنفيذ عمليات برمجيات ضارة. من الضروري الانتباه الى ان Default Configuration لأداة Cobalt Strike يستخدم rundll32.exe لهذا الغرض. ومع ذلك ، كمحلل DFIR يجب ان تعرف ان هذا Default Configuration وانه قابل للتغير من قبل المهاجم واستخدام Process بديلة مثل svchost.exe او غيرها. كما ذكرنا سابقاً ، Cobalt Strike منصة قابله للتعديل والتخصص على نطاق واسع جداً. كما ذكر مبرمج المنصة Raphael Mudge:
" لماذا rundll32.exe وليس اي شي اخر؟ بصراحة ، لا يهم ما سأختاره ، اي شي سأختاره سيكون هو Default نظراً لان الاشخاص نادراً ما يغيرون الاعدادات الافتراضية. والشي المهم هنا ، بالنسبة لكل الاطراف ، هو معرفة كيفية تغيير الاعدادات الافتراضية ولحسن الحظ ، فإن هذا ليس بالامر الصعب القيام به"
على الرغم من ان اغلب المهاجمون لا يغيرون الاعدادات الافتراضية ، الا انه من المهم الانتباه للاعدادات الاخرى للاداة لأكتشافها بفعالية عالية جداً.
تحليل الذاكره: Forensicating memory
الآن وبعد التأكد من وجود Cobalt Strike على النظام المخترق ، يمكننا الآن عمل التحليل اليدوي والتحقق من الذاكرة والعثور السلوكيات ومؤشرات الاختراق. سوف نستخدم Volatility Framework الخاص بتحليل الذاكره. لو بدأنا في تحليل الذاكرة مباشره فسنقضي الكثير من الوقت للبحث من خلال Processes و DLLs. ولكن بما اننا نعلم مسبقاً ان Cobalt Strike بالفعل موجود في النظام ويستخدم rundll32.exe سنركز على فحص هذه الـ Process.
" لماذا rundll32.exe وليس اي شي اخر؟ بصراحة ، لا يهم ما سأختاره ، اي شي سأختاره سيكون هو Default نظراً لان الاشخاص نادراً ما يغيرون الاعدادات الافتراضية. والشي المهم هنا ، بالنسبة لكل الاطراف ، هو معرفة كيفية تغيير الاعدادات الافتراضية ولحسن الحظ ، فإن هذا ليس بالامر الصعب القيام به"
على الرغم من ان اغلب المهاجمون لا يغيرون الاعدادات الافتراضية ، الا انه من المهم الانتباه للاعدادات الاخرى للاداة لأكتشافها بفعالية عالية جداً.
تحليل الذاكره: Forensicating memory
الآن وبعد التأكد من وجود Cobalt Strike على النظام المخترق ، يمكننا الآن عمل التحليل اليدوي والتحقق من الذاكرة والعثور السلوكيات ومؤشرات الاختراق. سوف نستخدم Volatility Framework الخاص بتحليل الذاكره. لو بدأنا في تحليل الذاكرة مباشره فسنقضي الكثير من الوقت للبحث من خلال Processes و DLLs. ولكن بما اننا نعلم مسبقاً ان Cobalt Strike بالفعل موجود في النظام ويستخدم rundll32.exe سنركز على فحص هذه الـ Process.
نظرة سريعة على المخرجات من اداة Volatility يمكننا ملاحظه الكثير من الـSuspicious Activity مثل WmiPriSE و PowerShell و rundll32.exe. هذا النمط يشير على وجود سلوك Malicious. من الافضل فحص شامل لـ Rundll32.exe حيث يبدو ان سلوكه ضار جداً ، اولاً سنقوم بفحض ملفات الـ DLLs الخاصه في Process المعنية باستخدام dlllist الخاصه في Volatility
من النظر في الصورة السابقه ، تعلم ان هناك شيئا غير عادي ، من المفترض ان تقوم rundll32.exe بتحميل ملفات DLLs ولكن من سطر الاوامر الخاص في Process لا نرى اي دليل على تحميل اي DLL او اي شي اخر على الاطلاق.
من خلال اعادة النظر وفحص Parent-Child Relationship والكشف عن سطر الاوامر المسؤول عن تشغيل Processes يمكننا بسهولة التعرف على Syswow64. لتحقيق ذلك ، يجب ان نستخدم CmdLine plugin في اداة Volatility
من خلال اعادة النظر وفحص Parent-Child Relationship والكشف عن سطر الاوامر المسؤول عن تشغيل Processes يمكننا بسهولة التعرف على Syswow64. لتحقيق ذلك ، يجب ان نستخدم CmdLine plugin في اداة Volatility
مانلاحظه هنا هو تنفيذ التعليمات البرمجية من SYSWOW64 مما يشير الى تشغيل Code على32-bit على غير العاده في الانظمه الحديثه ، حيث انه يتم تشغيل الاكواد من SYSTEM32 والذي يدل على وجود برمجيات64-bit. من المثير للاهتمام هو انه في الانظمه الحديثه ، مجلد system32 يشير الى تطبيقات64-bit ومجلد Syswow64 يشير الى تطبيقات32-bit. ولزيادة التعقيد ، قد تتساءل ، من الذي لا يزال يستخدم32-bit ولماذا؟. تفضل العديد من C2 Framework والبرمجيات الضارة على استخدام32-bit نظراً لتوافقها مع كل الانظمة 64 و 32 على حداً سواء. فهي تعمل بسلاسة على انظمة32-bit و64-bit. عند تشغيل PowerShell من إصدار32-bit فإنه يعمل من مجلد SYSWOW64 وهو نشاط نادر وsuspicious على النظام.
البحث عن Injected Beacons:
يسلط هذا الجزء من المقال الضوء على مايميز Cobalt Strike عن باقي C2 Frameworks الاخرى. نظراً لانه يعمل بشكل خفي جدا ، ويستخدم تقنيات وتكتيكات حقن متقدمة جداً وتقنيات Anti-Memory Forensics. للكشف عن عمليات الـ Injection يمكننا استخدام Malfind في اداة Volatility ، تستخدم Malfind عده خطوات للتحقق من الـ Injection ومن هذه الخطوات ، التالي:
1- فحص الصفحات في الذاكره التي تحتوي على Permission وربطها بالـ Process
a. فحص الصلاحيات لكل صفحه (Read_Write_Execute ).
2- التأكد مما اذا كان قسم الذاكرة مرتبطا بملف موجود على القرص.
3- التأكد مما اذا كان قسم الذاكره يحتوي على كود أم لا؟
عندما نقوم بتنفيذ Malfind على Process المستهدفه rundll32.exe نلاحظ انها تلبي شرطين من الشروط الثلاثه المذكورة.
البحث عن Injected Beacons:
يسلط هذا الجزء من المقال الضوء على مايميز Cobalt Strike عن باقي C2 Frameworks الاخرى. نظراً لانه يعمل بشكل خفي جدا ، ويستخدم تقنيات وتكتيكات حقن متقدمة جداً وتقنيات Anti-Memory Forensics. للكشف عن عمليات الـ Injection يمكننا استخدام Malfind في اداة Volatility ، تستخدم Malfind عده خطوات للتحقق من الـ Injection ومن هذه الخطوات ، التالي:
1- فحص الصفحات في الذاكره التي تحتوي على Permission وربطها بالـ Process
a. فحص الصلاحيات لكل صفحه (Read_Write_Execute ).
2- التأكد مما اذا كان قسم الذاكرة مرتبطا بملف موجود على القرص.
3- التأكد مما اذا كان قسم الذاكره يحتوي على كود أم لا؟
عندما نقوم بتنفيذ Malfind على Process المستهدفه rundll32.exe نلاحظ انها تلبي شرطين من الشروط الثلاثه المذكورة.
بالفعل ، اكتشف Malfind قسم مشبوه بالذاكره مع صلاحيات Read_Write_execute ولا يرتبط بملف على القرص . في نظام تشغيل الويندز ، يتم الحصول على الكود والتعليمات من ملفات على القرص. يتضمن الفحص النهائي في قسم الذاكرة على تحديد ما اذا كان يحتوى القسم على كود ام لا ، هنا ، لا نرى اي كود!
لماذا لا يوجد اي كود؟ هناك سببان رئيسيان ، اولاً Malfind تبحث عن اول 64 بايت الخاص بالصفحه في الذاكره بينما حجم الصفحه في الذاكره هو 4096 بايت. والسبب الاخر ، هو ان هذا الاسلوب هو اسلوب دفاعي متقدم من Cobalt Strike ويسمى Portable Executable Header Stomping وكما يتضح انه بعد تشغيل البرمجيه الضاره بالذاكرة ، يصبح Header ليس مهما وغير ضروري وجوده ، ولتجنب الكشف والـ Detection تقوم Cobalt Strike باستبدال اول4096 بايت بالاصفار ، لمسح اي اثر في الذاكره. هذا التكنيك مشار إليه ايضا في دليل المستخدم في Cobalt Strike:
لماذا لا يوجد اي كود؟ هناك سببان رئيسيان ، اولاً Malfind تبحث عن اول 64 بايت الخاص بالصفحه في الذاكره بينما حجم الصفحه في الذاكره هو 4096 بايت. والسبب الاخر ، هو ان هذا الاسلوب هو اسلوب دفاعي متقدم من Cobalt Strike ويسمى Portable Executable Header Stomping وكما يتضح انه بعد تشغيل البرمجيه الضاره بالذاكرة ، يصبح Header ليس مهما وغير ضروري وجوده ، ولتجنب الكشف والـ Detection تقوم Cobalt Strike باستبدال اول4096 بايت بالاصفار ، لمسح اي اثر في الذاكره. هذا التكنيك مشار إليه ايضا في دليل المستخدم في Cobalt Strike:
في هذا السيناريو ، يمكننا معالجه الامر عن طريق عمل dump لكامل الـ Process واجراء عمليات التحليل عليها. لتحقيق ذلك ، سوف نستخدم Memdump الخاص في اداة Volatility وحفظه في ملف.dmp
في هذه المرحلة ، بامكاننا عمل String على الملف لقراءة المعلومات المهمه في الملف. نتوقع ان تكون النتائج مقاربه للنتائج الخاصه بإداة1768.py التي كشفت عن وجود Cobalt Strike.
في هذه المرحله ، كمحلل DFIR مهمتك الاساسية تقريبا اكتملت. اذا دعت الحاجه لتحليل اكثر ، يمكن تسليم الملف لـ Reverse Engineers او محللي البرمجيات الضارة Malware Analyst لعمل الفحص بدقه وعمق على الملف.
خلال هذا التحليل ، نجحنا في اكتشاف وجود Cobalt Strike. وحددنا المعلومات التي من الممكن ان تساعدنا في عمل Scoping على كامل البيئة وتحديد الانظمة المخترقه. من المهم الاشارة الى ان YARA تعتبر من افضل الادوات لمسح الذاكره باستخدام مؤشرات الاختراق التي تم اكتشافها خلال تحليل الذاكرة. يمكن استخدام العديد من YARA Signature للبحث عن Cobalt Strike. مثال على واحده من افضل الـ YARA Rules المستخدمه للتعرف على Cobalt Strike هي apt_leviathan.yar والتي يمكن الوصول اليها عن طريق الرابط التالي: https://github.com/Neo23x0/signature-base/blob/master/yara/apt_leviathan.yar
من الضروري ان تضع في اعتبارك ان Cobalt Strike قابله للتغيير والتخصيص بشكل كبير جداً ، وان الـ YARA Signature المتاحة قد تختلف عما هو موجود في بيئتك. لذلك ، من المهم بناء YARA Rule خاصة بك وقد تكون هي الافضل في اكتشاف Cobalt Strike.
تقنيات اخرى للكشف عن Cobalt Strike:
- الكشف عن طريق تحليل الـ Log الخاصة في Named Pipes:
إن مفهوم " البرمجيات الخبيثه يجب ان تتواصل" صحيح. بغض النظر عن مدى تخفيها ، فإن البرمجيات الضارة عاجلا ام اجلاً لابد لها باستخدام شكل من اشكال الاتصال. ومن المثير للاهتمام ان الكثير من C2 Frameworks تستخدم Named Pipes للاتصال بما في ذلك Cobalt Strike. يمكن الكشف عن Named Pipes عن طريق تحليل الـ Log الخاصه في SYSMON. يعد اكتشاف Cobalt Strike عن طريق SYSMON موضوع متميز ويستحق ان تكتب عنه مقالة اخرى كاملة. حيث ان Cobalt Strike تقوم بإنشاء Named Pipes بنمط معين يمكن اكتشافه بشكل فعال ، لمزيد من المعلومات عن Named pipes Cobalt Strike detection يرجى زيارة:
https://labs.withsecure.com/publications/detecting-cobalt-strike-default-modules-via-named-pipe-analysis
- الكشف عن طريق PowerShell Logs :
نظراً إلى ان Cobalt Strike يعتمد بشكل كبير على PowerShell مع العديد من ميزاته التي تستخدم PowerShell فإنه من الضروري التأكد من تفعيل سجلات PowerShell مثل: script block logging و PowerShell Logging وغيرها. تفعيل السجلات امراً ضرورياً لأكتشاف انشطة وسلوكيات Cobalt Strike داخل البيئة.
من خلال التحليل ، لوحظ ان Cobalt Strike تستخدم بعض من الـ PowerShell Commands التاليه:
DownloadString, EncodedCommand, FromBase64String, rundll32, IEX, Invoke-Expression, WebClient, Syswow64, Powershell -version, http://127.0.0.1 , Reflection, $DoIt, Start-Process, Invoke-WMIMethod, Invoke-Command
الخاتمة:
في الختام ، باعتبارك محلل DFIR فإن التحليل الجنائي الرقمي للذاكرة هو بمثابة ساحة المعركة النهائية ضد التهديدات مثل Cobalt Strike وغيرها. في هذا المقال ، بحثنا في بعض التكتيكات التي يستخدمها المهاجمون باستخدام Cobalt Strike واساليب Evasion Techniques الخاصة بهم. استعرضنا بعض الادوات الخاصة في كشف Cobalt Strike باستخدام أداة1768.py ونجحنا بالكشف عن اثار Cobalt Strike داخل الذاكرة. علاوة على ذلك ، كشفنا عن استراتيجات Evasion المستخدمه في Cobalt Strike مثل Portable Executable Header Stomping بالاضافة الى اكتشاف Cobalt Strike عن طريق تحليل السجلات الخاصة في PowerShell & Named Pipes/Sysmon نظراً لاعتماد Cobalt Strike عليها بشكل كبير.
خلال هذا التحليل ، نجحنا في اكتشاف وجود Cobalt Strike. وحددنا المعلومات التي من الممكن ان تساعدنا في عمل Scoping على كامل البيئة وتحديد الانظمة المخترقه. من المهم الاشارة الى ان YARA تعتبر من افضل الادوات لمسح الذاكره باستخدام مؤشرات الاختراق التي تم اكتشافها خلال تحليل الذاكرة. يمكن استخدام العديد من YARA Signature للبحث عن Cobalt Strike. مثال على واحده من افضل الـ YARA Rules المستخدمه للتعرف على Cobalt Strike هي apt_leviathan.yar والتي يمكن الوصول اليها عن طريق الرابط التالي: https://github.com/Neo23x0/signature-base/blob/master/yara/apt_leviathan.yar
من الضروري ان تضع في اعتبارك ان Cobalt Strike قابله للتغيير والتخصيص بشكل كبير جداً ، وان الـ YARA Signature المتاحة قد تختلف عما هو موجود في بيئتك. لذلك ، من المهم بناء YARA Rule خاصة بك وقد تكون هي الافضل في اكتشاف Cobalt Strike.
تقنيات اخرى للكشف عن Cobalt Strike:
- الكشف عن طريق تحليل الـ Log الخاصة في Named Pipes:
إن مفهوم " البرمجيات الخبيثه يجب ان تتواصل" صحيح. بغض النظر عن مدى تخفيها ، فإن البرمجيات الضارة عاجلا ام اجلاً لابد لها باستخدام شكل من اشكال الاتصال. ومن المثير للاهتمام ان الكثير من C2 Frameworks تستخدم Named Pipes للاتصال بما في ذلك Cobalt Strike. يمكن الكشف عن Named Pipes عن طريق تحليل الـ Log الخاصه في SYSMON. يعد اكتشاف Cobalt Strike عن طريق SYSMON موضوع متميز ويستحق ان تكتب عنه مقالة اخرى كاملة. حيث ان Cobalt Strike تقوم بإنشاء Named Pipes بنمط معين يمكن اكتشافه بشكل فعال ، لمزيد من المعلومات عن Named pipes Cobalt Strike detection يرجى زيارة:
https://labs.withsecure.com/publications/detecting-cobalt-strike-default-modules-via-named-pipe-analysis
- الكشف عن طريق PowerShell Logs :
نظراً إلى ان Cobalt Strike يعتمد بشكل كبير على PowerShell مع العديد من ميزاته التي تستخدم PowerShell فإنه من الضروري التأكد من تفعيل سجلات PowerShell مثل: script block logging و PowerShell Logging وغيرها. تفعيل السجلات امراً ضرورياً لأكتشاف انشطة وسلوكيات Cobalt Strike داخل البيئة.
من خلال التحليل ، لوحظ ان Cobalt Strike تستخدم بعض من الـ PowerShell Commands التاليه:
DownloadString, EncodedCommand, FromBase64String, rundll32, IEX, Invoke-Expression, WebClient, Syswow64, Powershell -version, http://127.0.0.1 , Reflection, $DoIt, Start-Process, Invoke-WMIMethod, Invoke-Command
الخاتمة:
في الختام ، باعتبارك محلل DFIR فإن التحليل الجنائي الرقمي للذاكرة هو بمثابة ساحة المعركة النهائية ضد التهديدات مثل Cobalt Strike وغيرها. في هذا المقال ، بحثنا في بعض التكتيكات التي يستخدمها المهاجمون باستخدام Cobalt Strike واساليب Evasion Techniques الخاصة بهم. استعرضنا بعض الادوات الخاصة في كشف Cobalt Strike باستخدام أداة1768.py ونجحنا بالكشف عن اثار Cobalt Strike داخل الذاكرة. علاوة على ذلك ، كشفنا عن استراتيجات Evasion المستخدمه في Cobalt Strike مثل Portable Executable Header Stomping بالاضافة الى اكتشاف Cobalt Strike عن طريق تحليل السجلات الخاصة في PowerShell & Named Pipes/Sysmon نظراً لاعتماد Cobalt Strike عليها بشكل كبير.
لمشاركة هذه المدونة
تابعنا
طور مهاراتك من خلال متابعة آخر منشورات فريقنا
مدونات آخرى