nccgroup/async-pico-hubAsync PICO Hub is a work-in-progress framework to extend Cobalt Strike with custom event monitoring and in-process Asynchronous BOFs
إطار عمل Async PICOs هو إطار لتشغيل ملفات Beacon Object Files طويلة الأمد والقائمة على الأحداث داخل عملية Cobalt Strike Beacon. يوفر تنفيذًا غير متزامن، وتتبعًا للمهام، وإيقافًا آمنًا، وإخراجًا غير متزامن آمنًا من خلال الجمع بين Crystal Palace PICOs ونموذج تنفيذ جانب Beacon.
على عكس BOFs غير المتزامنة الأصلية في Cobalt Strike، تعمل Async PICOs داخل عملية Beacon ويمكنها إيقاظ Beacon لعرض الإخراج عند حدوث الأحداث.
BOFs غير المتزامنة الأصلية في Cobalt Strike تحل مشكلة مختلفة. صُممت Async PICOs للمهام طويلة الأمد والقائمة على الأحداث التي تعمل داخل Beacon ويمكنها توصيل النتائج بأمان مباشرة إلى المشغِّل.
لتفاصيل التنفيذ والأساس المنطقي للتصميم، راجع منشور المدونة المصاحب:
https://www.nccgroup.com/research/async-picos-and-custom-beacon-wakeups-in-cobalt-strike/
قبل البناء، المكونات التالية مطلوبة:
نسخة محلية من هذا المستودع
نسخة مبنية من Crystal Palace
Visual Studio مع دعم MSVC وCMake
Tradecraft Garden
استنساخ المستودع
git clone <repo-url>
cd async-pico-hub
تعتمد Async PICOs على Crystal Palace لتوليد PICO.
قم بتنزيل أحدث إصدار مضغوط من Crystal Palace وقم ببنائه وفقًا لتعليماته. بعد البناء، ضع ملفات Crystal Palace الثنائية داخل:
pico-tools/crystal-palace/
يجب أن يبدو التخطيط المتوقع مشابهًا لما يلي:
pico-tools/
└── crystal-palace/
├── src/
├── lib/
└── ...
قم بتنزيل أحدث إصدار من Tradecraft Garden وضعه في
pico-tools/tradecraftgarden
يجب أن يبدو التخطيط المتوقع مشابهًا لما يلي:
pico-tools/
└── tradecraftgarden/
├── libtcg/
├── simple_pic/
└── ...
تأكد من بناء libtcg ومثال simple_pic لتتمكن من بناء Async PICOs.
يستخدم المشروع CMake لتبسيط البناء باستخدام MSVC.
من جذر المستودع، انقر بزر الماوس الأيمن على المجلد واختر:
Open with Visual Studio
يؤدي هذا إلى تحميل مشروع CMake وعرض تكوينات البناء المتاحة.
تكوينات البناء التالية متاحة:
x64 Debug
يبني نسخًا محلية قابلة للتنفيذ من PICOs وBOFs لتصحيح الأخطاء.
استخدم هذا التكوين عند تصحيح سلوك محليًا أو التنقل خلال الكود في Visual Studio.
x64 Release
يبني نسخًا محلية قابلة للتنفيذ ومحسّنة من PICOs وBOFs.
استخدم هذا التكوين لاختبار سلوك الإصدار خارج Beacon.
x64 Release Objects
يبني نواتج النشر:
هذا هو التكوين المستخدم لإنتاج الكائنات لـ Cobalt Strike.
بمجرد اكتمال البناء، يمكن العثور على النواتج المُنشأة في:
build/x64-ReleaseObject/obj/
يحتوي هذا الدليل على PICOs وBOFs المجمّعة الجاهزة للاستخدام.
تتطلب Async PICOs استخدام Beacon لـ sleepmask مخصص.
في ملف التعريف القابل للتشكيل (malleable profile)، فعّل دعم sleepmask مخصص قبل محاولة استخدام Async PICOs.
البرنامج النصي
picos-cna/sleepmask.cnaيقوم بتحميلasync-sleepmask، وهو تنفيذ مرجعي بسيط يُستخدم لدعم الإخراج غير المتزامن وتنسيق إيقاظ Beacon.هذا sleepmask بسيط عن قصد ويأتي مع القيود الموصوفة في قسم القيود. تم توفيره لتوضيح الإطار وتبسيط الاختبار، وليس كمكوّن جاهز للإنتاج.
إذا كان لديك بالفعل sleepmask مخصص بتقنيات OPSEC، مثل معالجة المكدس أو غيرها، راجع تعديل sleepmask الموجود لديك ليكون Async sleepmask لدمج دعم Async PICO في تنفيذك الحالي.
بعد بناء المشروع باستخدام تكوين x64 Release Objects، قم بتحميل برنامجي Aggressor النصيين picos.cna وsleepmask.cna في Cobalt Strike:
Script Manager → Load → picos-cna/picos.cna
Script Manager → Load → picos-cna/sleepmask.cna
بمجرد التحميل، يمكن إدارة Async PICOs من خلال أمر picos.
لبدء PICO:
picos start [path to pico] [arguments]
على سبيل المثال:
picos start C:\temp\MonitorTGT.pico
أو مع وسائط:
picos start C:\temp\MonitorTGT.pico DOMAIN\serviceaccount
لعرض Async PICOs قيد التشغيل:
picos
يعرض هذا المهام قيد التشغيل حاليًا ومعرّفاتها.
لإيقاف Async PICO:
picos stop [pico id]
على سبيل المثال:
picos stop 3
يتلقى PICO إشارة إيقاف وينتهي بأمان بعد إجراء التنظيف.
معلومات استخدام إضافية متاحة مباشرة داخل Cobalt Strike من خلال قوائم المساعدة المدمجة لأوامر picos.
راجع docs/writing_custom_async_pico.md للتفاصيل.
راجع docs/modifying_existing_sleepmask.md للتفاصيل.
التنفيذ العام مُبقى بسيطًا عن قصد، دون تقنيات مراوغة متقدمة. إنه مُعد كأساس للتكييف وليس شيئًا يُنشر دون تغيير.
يتم تشغيل Async PICOs باستخدام CreateThread. هذا يُبقي نموذج التنفيذ بسيطًا وسهل الفهم، لكنه يُدخل أيضًا سطح اكتشاف. في التنفيذ العام، يبدأ الخيط التنفيذ من ذاكرة غير مدعومة بملف وحدة نمطية، وهو ما قد يكون قابلاً للاكتشاف بواسطة المنتجات أو الأساليب الإرشادية التي تفحص عناوين بداية الخيوط.
يجب على المستخدمين تقييم ما إذا كانت استراتيجيات إنشاء الخيوط أو التنفيذ البديلة أكثر ملاءمة لبيئتهم.
يعتمد الإطار على sleepmask معدَّل لنقل الإخراج غير المتزامن مرة أخرى إلى Beacon وتنسيق أحداث الاستيقاظ. التنفيذ المُرفق هنا بسيط عن قصد ويجب مراجعته قبل الاستخدام التشغيلي.
يعد sleepmask جزءًا من نموذج التنفيذ، وليس مجرد طبقة راحة. يجب تقييم أي تغييرات في كيفية وضع الإخراج في قائمة الانتظار، أو تفريغه، أو الإشارة إليه بعناية لتجنب إدخال مشكلات التزامن أو تفاعلات غير مدعومة مع دواخل Beacon.
يأتي التنفيذ العام مع العديد من القيود العملية التي يجب فهمها قبل استخدامه.
يجعل Crystal Palace من الممكن لـ PICOs استخدام متغيرات عامة، لكن التنفيذ العام يستخدم نموذج تخزين مشترك بسيط لتخزين الحالة العامة. نتيجة لذلك، لا يتم عزل المتغيرات العامة لكل خيط.
عمليًا، هذا يعني أن تشغيل عدة Async PICOs بالتزامن قد يتطلب عناية إضافية عندما تعتمد على المتغيرات العامة.
تعتمد Async PICOs على sleepmask معدَّل للإخراج غير المتزامن وتنسيق إيقاظ Beacon. لذلك فإن الإطار ليس مكتفيًا ذاتيًا بالكامل ولا يمكن التعامل معه كـ BOF جاهز للإدراج المباشر.
صُمم المستودع لتوضيح إطار عمل وأسلوب تنفيذ بدلاً من توفير مكوّن جاهز للإنتاج. الأمثلة المُرفقة مخصصة للتوسيع والتعديل والتكييف وفق حالات الاستخدام الفردية.