kevoreilly/capev2استخراج تكوين البرامج الضارة والحمولة
يُستخدم صندوق الرمل لتنفيذ الملفات الضارة في بيئة معزولة مع تتبع سلوكها الديناميكي وجمع الأدلة الجنائية.
تم اشتقاق CAPE من Cuckoo v1 الذي يتميز بالقدرات الأساسية التالية على منصة Windows:
يكمل CAPE مخرجات صندوق رمل Cuckoo التقليدية بعدة إضافات رئيسية:
توجد نسخة تجريبية مجانية على الإنترنت يمكن لأي شخص استخدامها:
https://capesandbox.com - لتفعيل الحساب تواصل مع https://twitter.com/capesandbox
بدأ مشروع Cuckoo Sandbox كمشروع Google Summer of Code في عام 2010 ضمن The Honeynet Project. تم تصميمه وتطويره في الأصل بواسطة Claudio Guarnieri، وتم إصدار أول نسخة تجريبية في عام 2011. في يناير 2014، تم إصدار Cuckoo v1.0.
كان عام 2015 عامًا محوريًا، مع انشقاق كبير في تاريخ Cuckoo. توقف تطوير المراقب الأصلي وطريقة ربط API في مشروع Cuckoo الرئيسي. تم استبداله بـ مراقب بديل يستخدم تنسيق توقيع قائم على restructuredText تم تجميعه عبر سلسلة أدوات Linux، من إنشاء Jurriaan Bremer.
في نفس الوقت تقريبًا، تم إنشاء انشقاق يسمى Cuckoo-modified بواسطة Brad 'Spender' Spengler لمواصلة تطوير المراقب الأصلي مع تحسينات كبيرة بما في ذلك دعم 64 بت والأهم تقديم مترجم Microsoft Visual Studio.
خلال تلك السنة نفسها، بدأ تطوير أداة سطر أوامر ديناميكية لاستخراج التكوين والحمولة تسمى CAPE في Context Information Security بواسطة Kevin O'Reilly. تم صياغة الاسم كاختصار لـ 'Config And Payload Extraction' وركز البحث الأصلي على استخدام خطافات API التي توفرها مكتبة Detours الخاصة بشركة Microsoft لالتقاط حمولات وتكوين البرامج الضارة المفكوكة. ومع ذلك، أصبح من الواضح أن خطافات API وحدها لا توفر القوة والدقة الكافية للسماح بفك تغليف الحمولات أو التكوينات من أي برمجيات ضارة.
لهذا السبب بدأ البحث في مفهوم مصحح جديد للسماح بالتحكم الدقيق وتتبع البرامج الضارة مع تجنب استخدام واجهات تصحيح Microsoft، وذلك ليكون متخفيًا قدر الإمكان. تم دمج هذا المصحح في أداة سطر الأوامر الأولية القائمة على Detours، مما يجمع بين خطافات API وينتج عنه قدرات قوية جدًا.
عندما أظهر العمل الأولي أنه سيكون من الممكن استبدال Microsoft Detours بمحرك ربط API الخاص بـ Cuckoo-modified، وُلدت فكرة CAPE Sandbox. مع إضافة المصحح، وفك التغليف الآلي، والتصنيف القائم على YARA، واستخراج التكوين المتكامل، تم إصدار CAPE Sandbox لأول مرة في سبتمبر 2016 في 44con: CAPE الإصدار 1.
في صيف 2018، كان المشروع محظوظًا برؤية بداية مساهمات ضخمة من Andriy 'doomedraven' Brukhovetskyy، وهو مساهم طويل الأمد في Cuckoo. في عام 2019 بدأ المهمة الضخمة لنقل CAPE إلى Python 3 وفي أكتوبر من ذلك العام تم إصدار CAPEv2.
تم تطوير CAPE باستمرار وتحسينه لمواكبة التطورات في كل من البرامج الضارة وقدرات أنظمة التشغيل. في عام 2021، تمت إضافة القدرة على برمجة مصحح CAPE أثناء التفجير عبر فحوصات YARA الديناميكية، مما يسمح بإنشاء تجاوزات ديناميكية لتقنيات مكافحة صندوق الرمل. أصبح Windows 10 هو نظام التشغيل الافتراضي، وتشمل الإضافات الهامة الأخرى سطح المكتب التفاعلي، والتقاط الحمولة عبر AMSI (واجهة فحص البرامج الضارة)، و 'syscall hooking' بناءً على Microsoft Nirvana وإجراءات مضادة لاستدعاءات النظام المباشرة/غير المباشرة القائمة على المصحح.
يمكن تصنيف البرامج الضارة في CAPE عبر ثلاث آليات:
يمكن إجراء التحليل باستخدام إطار CAPE الخاص، بدلاً من ذلك يتم دعم الأطر التالية: RATDecoders، DC3-MWCP، MalDuck، أو MaCo
def extract_config(data): سيتم استدعاؤها بواسطة cape_utils.py وبدون تعقيدات.
يستفيد CAPE من العديد من تقنيات أو سلوكيات البرامج الضارة للسماح بالتقاط الحمولات المفكوكة:
ستؤدي هذه السلوكيات إلى التقاط الحمولات التي يتم حقنها أو استخراجها أو فك ضغطها لمزيد من التحليل. بالإضافة إلى ذلك، يقوم CAPE تلقائيًا بإنشاء تفريغ عملية لكل عملية، أو في حالة DLL، صورة وحدة DLL في الذاكرة. هذا مفيد للعينات المعبأة بأدوات تعبئة بسيطة، حيث غالبًا ما يكون تفريغ صورة الوحدة مفكوكًا بالكامل.
بالإضافة إلى آليات فك التغليف 'السلبية' الافتراضية لـ CAPE، من الممكن تمكين فك التغليف 'النشط' الذي يستخدم نقاط التوقف لاكتشاف الكتابة إلى مناطق ذاكرة مخصصة حديثًا أو محمية، من أجل التقاط الحمولات المفكوكة في أقرب وقت ممكن قبل التنفيذ. يتم تمكين ذلك عبر مربع اختيار الإرسال عبر الويب أو عن طريق تحديد الخيار unpacker=2 ويتم تركه معطلاً افتراضيًا لأنه قد يؤثر على جودة التفجير.
يمكن برمجة CAPE عبر توقيع YARA لفك تغليف أدوات تعبئة محددة. على سبيل المثال، أدوات التعبئة من نوع UPX شائعة جدًا، وعلى الرغم من أن هذه الأدوات في CAPE تؤدي إلى التقاط الحمولات المفكوكة بشكل سلبي، إلا أن الالتقاط الافتراضي يتم بعد أن تبدأ الحمولة المفكوكة في التنفيذ. لذلك من خلال اكتشاف أدوات التعبئة المشتقة من UPX ديناميكيًا عبر توقيع YARA مخصص وتعيين نقطة توقف على تعليمة التعبئة النهائية، من الممكن التقاط الحمولة عند نقطة الدخول الأصلية (OEP) قبل أن تبدأ في التنفيذ.
يسمح الخيار dump-on-api بتفريغ وحدة عند استدعائها لوظيفة API محددة يمكن تحديدها في الواجهة الويب (مثال: dump-on-api=DnsQuery_A).
سمح المصحح لـ CAPE بمواصلة التطور إلى ما بعد قدراته الأصلية، والتي تتضمن الآن تجاوزات ديناميكية لمكافحة التهرب. نظرًا لأن البرامج الضارة الحديثة تحاول عادةً التهرب من التحليل داخل صناديق الرمل، على سبيل المثال باستخدام مصائد زمنية للمحاكاة الافتراضية أو كشف خطافات API، يسمح CAPE بتطوير إجراءات مضادة ديناميكية تجمع بين إجراءات المصحح داخل توقيعات Yara لاكتشاف البرامج الضارة المراوغة أثناء تفجيرها، وإجراء تلاعب في تدفق التحكم لإجبار العينة على التفجير بالكامل أو تخطي الإجراءات المراوغة.
الوصول السريع إلى المصحح ممكن باستخدام خيارات الإرسال bp0 إلى bp3 التي تقبل قيم RVA أو VA لتعيين نقاط التوقف، حيث سيتم إخراج تتبع تعليمات قصير، محكوم بخيارات count و depth (مثال: bp0=0x1234,depth=1,count=100).
لتعيين نقطة توقف عند نقطة دخول الوحدة، يُستخدم ep بدلاً من عنوان (مثال: bp0=ep). بدلاً من ذلك، break-on-return يسمح بنقطة توقف على عنوان الإرجاع لوظيفة API تم ربطها (مثال: break-on-return=NtGetContextThread). المعامل الاختياري base-on-api يسمح بتعيين قاعدة الصورة لنقاط توقف RVA بواسطة استدعاء API (مثال: base-on-api=NtReadFile,bp0=0x2345).
الخيارات action0 إلى action3 تسمح بتنفيذ إجراءات عند الوصول إلى نقاط التوقف، مثل تفريغ مناطق الذاكرة (مثال: action0=dumpebx) أو تغيير تدفق التحكم في التنفيذ (مثال: action1=skip). تحتوي وثائق CAPE على أمثلة أخرى لهذه الإجراءات.
المستودع الذي يحتوي على كود مراقب CAPE منفصل.
يوجد مستودع مجتمع للتوقيعات يحتوي على عدة مئات من التوقيعات التي طورها مجتمع CAPE. يجب دفع جميع الميزات المجتمعية الجديدة إلى هذا المستودع. لاحقًا يمكن نقلها إلى النواة إذا كان المطورون قادرين وراغبين في صيانتها.
يرجى المساهمة في هذا المشروع من خلال المساعدة في إنشاء توقيعات جديدة، أو محللات، أو تجاوزات لعائلات برامج ضارة أخرى. هناك العديد منها قيد التطوير حاليًا، لذا ترقبوا.
شكر كبير لـ @D00m3dR4v3n على نقله الفردي لـ CAPE إلى Python 3.
Python3
يجب تنفيذ rooter فقط كجذر (root)، والباقي كمستخدم cape. تشغيله كجذر سيعبث بالأذونات.
conf!kvm-qemu.sh و cape2.sh يجب تنفيذهما من جلسة tmux لمنع أي مشاكل في نظام التشغيل إذا انقطع اتصال ssh.<username> بنمط حقيقي.<WOOT> في الداخل!sudo ./kvm-qemu.sh all <username> 2>&1 | tee kvm-qemu.logsudo ./cape2.sh base 2>&1 | tee cape.logconf.systemctl restart <service_name>journalctl -u <service_name>-h لقائمة المساعدة. يمكن أن يساعد تشغيل الخدمة في وضع التصحيح (-d) أيضًا.-h، ولكن يرجى التحقق من البرامج النصية لـ فهم ما تفعله.git pullpython3 utils/community.py -waf انظر -h قبل ذلك للتأكد من أنك تفهمgit add --all
git commit -m '[STASH]'
git pull --rebase origin master
# fix conflict (rebase) if needed
git reset HEAD~1
# make sure kevoreilly repo has been added as a remote (only needs to be done once)
git remote add kevoreilly https://github.com/kevoreilly/CAPEv2.git
# make sure all your changes are commited on the branch which you will be merging
git commit -a -m '<your commit message goes here>'
# fetch changes from kevoreilly repo
git fetch kevoreilly
# merge kevoreilly master branch into your current branch
git merge kevoreilly/master
# fix merge conflicts if needed
# push to your repo if desired
git push
إذا كنت تستخدم CAPEv2 في عملك، فيرجى الاستشهاد به كما هو محدد في قائمة "Cite this repository" على GitHub.
pefile حيث أن كل منها يثبت الإصدار الذي يريده.
pefile حيث أنك قمت بالفعل بتثبيتها. وفويلا، لا مزيد من الألم.