تواصل الجهات الخبيثة استغلال الخدمات الشرعية لأغراض غير شرعية. استخدام نطاق عالي السمعة مثل graph.microsoft.com لاتصالات C2 فعال للغاية ومرغوب، ولكنه غالبًا ما يكون معقدًا ومثبطًا من حيث الوقت والجهد. معظم أطر عمل C2 لا تدعم طرق جلب أو تدوير رموز الوصول، مما يجعلها غير قادرة على استخدام واجهة برمجة تطبيقات جراف. هذا يمكن أن يجعل من الصعب على فرق الاختراق تكرار هذه التقنيات، ويحرم المدافعين من فرصة مراقبة وتطوير توقيعات لهذا النوع من النشاط. يسعى GraphStrike إلى تخفيف هذا العبء وتوفير عملية موثوقة وقابلة للتكرار لاستخدام واجهة برمجة تطبيقات مايكروسوفت جراف مع الحفاظ على الألفة والموثوقية لتجربة مستخدم Cobalt Strike.

هل هذا External C2؟

من الناحية الفنية، لا. بعد أن قمنا سابقًا ببناء External C2 حقيقي باستخدام واجهة برمجة تطبيقات جراف (والذي أرسل حركة مرور Beacon كرسائل Microsoft Teams)، فإن عبء تطوير وصيانة ودمج أداة مخصصة تلبي مواصفات External C2 وتنجز المهمة أصبح مألوفًا جدًا. بدلاً من ذلك، يستفيد GraphStrike من محمل انعكاسي محدد من قبل المستخدم (UDRL) مفتوح المصدر يُدعى AceLdr من كايل أفيري (تم تكييفه كـ 'GraphLdr' في هذا المشروع) لربط استدعاءات مكتبة WinINet التي يقوم بها Beacon عادةً والتعامل معها حسب الحاجة لاستخدام واجهة برمجة تطبيقات جراف. لا يوجد أداة مخصصة أو عملية إضافية تُذكر، فقط عملية Beacon مع عدد قليل من واجهات برمجة التطبيقات لنظام Windows التي تم ربطها. على جانب الخادم، يوجد برنامج Python3 يترجم حركة مرور خادم فريق Cobalt Strike إلى حركة مرور واجهة برمجة تطبيقات جراف والعكس.

الميزات

يدعم GraphStrike جميع أنشطة Cobalt Strike العادية تقريبًا بما في ذلك:

1. استخدام Proxychains عبر وكيل SOCKS في Cobalt Strike (على الرغم من أنه بطيء جدًا...)
2. رفع/تنزيل الملفات الكبيرة
3. BOFs، execute-assembly، إلخ.

يتضمن هذا أيضًا تكامل GraphStrike مع أوامر السكون والخروج والإزالة لمطابقة أوقات سكون خادم GraphStrike مع Beacon بالإضافة إلى حذف الملفات في SharePoint عند خروج أو إزالة Beacon.

بالإضافة إلى ذلك، يدمج GraphStrike جميع ميزات ووظائف AceLdr الأصلي، مع بعض واجهات برمجة التطبيقات الإضافية المصممة لاستخدام تزوير مكدس الاستدعاءات أيضًا.

المتطلبات

يتطلب GraphStrike ما يلي قبل البدء:

1. مستأجر Microsoft Azure مع ترخيص SharePoint/O365 معين + موقع تم إنشاؤه. الموقع الافتراضي جيد.
2. حساب Azure مع صلاحيات المسؤول العام في ذلك المستأجر.
3. Python 3.8-3.11^{ملاحظة #4} (والتبعيات الإضافية التي سيتم تثبيتها أثناء عملية الإعداد)

قواعد جدار الحماية

1. تأكد من أن كل جهاز يعمل عليه عميل Cobalt Strike قادر على الاتصال بجهاز خادم فريق Cobalt Strike على المنفذين 443 و5000.

الإعداد

لاحظ ما يلي قبل المتابعة في عملية الإعداد:

1. تستخدم بعض المكونات مسارات نسبية لتحديد موقع الأصول الأخرى. يرجى تغيير الدلائل كما هو موضح أدناه.
2. لا يمكن تعديل ملف تعريف Cobalt Strike إلا قبل الخطوة 5 في عملية الإعداد أدناه^{ملاحظة #1}.

على الجهاز الذي سيشغل خادم فريق Cobalt Strike:

1. استنساخ المستودع.
2. من دليل المستودع، قم بتشغيل sudo setup/install_dependencies.sh لتثبيت تبعيات النظام المطلوبة.
3. قم بتشغيل python3 -m venv virtual ثم source virtual/bin/activate لإنشاء البيئة الافتراضية ثم الدخول إليها.
4. انتقل إلى دليل الإعداد وقم بتشغيل pip3 install -r requirements.txt.
5. قم بتشغيل ./provisioner.py new وأكمل عملية الإعداد.
6. ابدأ تشغيل خادم فريق Cobalt Strike باستخدام graphstrike.profile كملف تعريف C2 القابل للتشكيل.
7. ابدأ تشغيل مثيل عميل Cobalt Strike (يمكنك القيام بذلك على جهاز عميل، أو على جهاز TS وقتله بعد ذلك) وقم بإنشاء مستمع HTTPS لـ Cobalt Strike على المنفذ 443 مع graph.microsoft.com كحقول HTTPS Hosts وHTTPS Host(Stager).
8. عد إلى دليل المستودع الرئيسي وقم بتشغيل خادم GraphStrike باستخدام ./GraphStrike.py.

على جميع الأجهزة التي ستعمل عميل Cobalt Strike:

9. انسخ دليل GraphStrike/client إلى جهاز العميل من جهاز TS. يجب القيام بذلك فقط بعد الانتهاء من التزويد!
10. استيراد GraphStrike.cna إلى Cobalt Strike باستخدام مدير البرامج النصية.
11. إنشاء حمولات Cobalt Strike، سواء كانت كود شيل خام أو قطع أثرية مجمعة باستخدام Artifact Kit أو إطار عمل بديل لتوليد الحمولات. مستخدمو Artifact Kit انظر أدناه!
12. الربح.

مستخدمو Artifact Kit

نظرًا لحجم GraphLdr، سيحتاج مستخدمو Artifact Kit إلى إعادة ترجمته بخيارات محددة لكي يكون GraphStrike متوافقًا مع الحمولات المولدة بواسطة Artifact Kit. على وجه التحديد، يجب تحديد حقلي 'Stage Size' و'RDLL Size' لاستخدام حجم RDLL 100K. فيما يلي مثالان على بناء الجملة الصحيح:

./build.sh pipe VirtualAlloc 505029 100 false false none /opt/cobaltstrike/artifacts
./build.sh peek HeapAlloc 492376 100 false true indirect /opt/cobaltstrike/artifacts

التنظيف

على الجهاز الذي يعمل عليه خادم TS + GraphStrike:

1. إيقاف خادم GraphStrike
2. العودة إلى دليل الإعداد وتشغيل ./provisioner.py delete لإزالة موارد Azure التي تم إنشاؤها.

ملاحظات

بدون ترتيب معين، إليك بعض الاقتراحات والملاحظات للمساعدة في استخدام GraphStrike بأقصى إمكاناته.

1. ملف التعريف المضمن مع GraphStrike بسيط جدًا؛ وهذا مقصود. تغيير أي من الحقول الموجودة في ملف التعريف قد/سيؤدي إلى تعطل GraphStrike! يجب أن تكون قادرًا على إضافة لغة/سلوك إضافي لملف التعريف إلى أقسام أخرى غير محددة بالفعل (مثل تخصيص اسم الأنبوب، سلوك الحقن، إلخ). يجب إجراء أي تعديلات على ملف التعريف قبل تشغيل المزوّد!
2. تطبيق Azure المستخدم لاتصالات C2 من قبل كل من Beacon وخادم GraphStrike مقيد بـ 1200 طلب/دقيقة. يستخدم خادم GraphStrike 120/دقيقة كخط أساس للعمل. كلما كان وقت سكون Beacon أقل، زاد عدد الطلبات التي سيقوم بها؛ بالإضافة إلى ذلك، سيستخدم كل Beacon تم إنشاؤه باستخدام GraphStrike جزءًا من حد 1200/دقيقة. التفاعل مع Beacon واحد ممكن، لكن التفاعل مع أكثر من Beacon واحد ربما ليس كذلك. إذا واجهت مشكلات في تحديد المعدل، فكر في زيادة وقت السكون لـ beacons الخاصة بك، أو تقليل عدد Beacons التي تعمل، أو كليهما.
3. بينما يتغير وقت سكون خادم GraphStrike على أساس كل Beacon وفقًا لأوامر السكون الصادرة، فإن ما يعنيه هذا حقًا هو أن خادم GraphStrike سوف ينام للوقت المحدد قبل تسجيل الدخول إلى TS للحصول على المهام. لا يعني هذا أن Beacon سيتلقى ويعالج المهام فور استرجاعها من TS بواسطة خادم GraphStrike. سوف ينام Beacon للوقت المحدد قبل الاتصال بـ SharePoint لاسترجاع مهام TS، ولكن نظرًا لطبيعة C2 غير المتزامنة، لن يكون هذا متزامنًا مع وقت تحميل خادم GraphStrike لها.
4. إذا مات Beacon دون الخروج بشكل أنيق (AV، تحطم، إلخ)، سيظهر Beacon وكأنه لا يزال يتصل بـ TS، وستظهر حقيقة أنه ميت فقط بمجرد إصدار أمر له. ما يتصل بالفعل بـ TS / يجعله يبدو أن Beacon لا يزال يتصل هو خادم GraphStrike، لذلك هذا ليس انعكاسًا حقيقيًا على صحة Beacon. هذه هي طبيعة C2 غير المتزامنة.
5. يعمل GraphStrike على نموذج 1:1:1؛ موقع SharePoint واحد مرتبط بخادم GraphStrike واحد مرتبط بـ TS واحد. ستواجه مشكلات إذا حاولت توصيل خادمي TS/GraphStrike بموقع SharePoint واحد. يمكنك بالطبع توصيل عدة عملاء Cobalt Strike بـ TS / خادم GraphStrike واحد، يحتاج كل عميل فقط إلى نسخة من مجلد 'client' الناتج عن عملية التزويد.
6. هناك مشكلة معروفة بخصوص توافق الأداة المساعدة az التي يستخدمها GraphStrike مع Python 3.12.
7. أوصي بمراجعة توثيق AceLdr، حيث أن جميع الملاحظات من ذلك المشروع تنطبق هنا أيضًا.

القيود

توجد القيود التالية في GraphStrike:

1. يتم دعم Beacons من نوع x64 فقط.
2. Beacons المرحلية غير مدعومة.
3. GraphStrike متوافق فقط مع مكتبة WinINet؛ خيار مكتبة WinHTTP الجديد لـ Beacons غير مدعوم.
4. لا يوجد دعم لإصدار أمر السكون عبر قائمة النقر بزر الماوس الأيمن في Beacon. استخدم خيار سطر الأوامر لإسبات Beacons بدلاً من ذلك.
5. GraphStrike مدعوم فقط على إصدارات Linux من Cobalt Strike. دعم Windows ممكن بالتأكيد تنفيذه، وهو مجرد مسألة تغيير بعض المسارات داخل ملفات Python وبرنامج Aggressor.

الاعتمادات

لما كان GraphStrike ممكنًا بدون مساهمات الأفراد التاليين:

1. كايل أفيري لـ AceLdr
2. ديدييه ستيفنز لـ cs-decrypt-metadata.py
3. مايك سوندرز، كوري أوفرستريت، كريس ترانسر، وجاستن بالك من فريق Red Siege الذين اختبروا جميعًا GraphStrike في مرحلة بيتا وحددوا العديد من المشكلات التي تم إصلاحها قبل الإصدار.