CAPEv2
1.0.0
يتم استخدام صندوق الرمل لتنفيذ الملفات الخبيثة في بيئة معزولة مع توصيل سلوكها الديناميكي وجمع القطع الأثرية الجنائية.
تم اشتقاق Cape من Cuckoo V1 الذي يتميز بالقدرات الأساسية التالية على منصة Windows:
تكمل Cape إخراج صندوق الرمل التقليدي لـ Cuckoo مع عدة إضافات رئيسية:
هناك مثيل عرض مجاني على الإنترنت يمكن لأي شخص استخدامه:
https://capesandbox.com - للوصول إلى تنشيط الحساب إلى https://twitter.com/capesandbox
بدأ Cuckoo Sandbox كمشروع Google Summer of Code في عام 2010 ضمن مشروع Honeynet. تم تصميمه وتطويره في الأصل من قِبل Claudio Guarnieri ، تم نشر أول إصدار تجريبي في عام 2011. في يناير 2014 ، تم إصدار Cuckoo V1.0.
كان عام 2015 عامًا محوريًا ، مع شوكة كبيرة في تاريخ Cuckoo. تم إيقاف تطوير الشاشة الأصلية وطريقة التثبيت API في مشروع Cuckoo الرئيسي. تم استبداله بشاشة بديلة باستخدام تنسيق توقيع يعتمد restructuredText الذي تم تجميعه عبر أدوات Linux ، التي أنشأتها Jurriaan Bremer.
في نفس الوقت تقريبًا ، تم إنشاء شوكة تسمى Cuckoo المعدلة بواسطة Brad 'Spender' Spengler تطوير الشاشة الأصلية مع تحسينات كبيرة بما في ذلك الدعم 64 بت وإدخال برنامج التحويل البرمجي المرئي من Microsoft.
خلال نفس العام ، بدأ تطوير أداة تكوين سطر الأوامر والتحميل النافعة التي تسمى Cape في أمن المعلومات السياق بواسطة Kevin O'Reilly. تم صياغة الاسم باعتباره اختصارًا لـ "Config and Payload Extraction" والبحث الأصلي الذي يركز على استخدام خطافات API التي توفرها مكتبة Microsoft's Detours لالتقاط حمولات وتكوين البرامج الضارة غير المعبأة. ومع ذلك ، أصبح من الواضح أن خطافات API وحدها توفر قوة ودقة غير كافية للسماح بتفريغ الحمولات أو التكوينات من البرامج الضارة التعسفية.
لهذا السبب ، بدأت الأبحاث في مفهوم تصحيح الأخطاء الجديد للسماح بالتحكم في البرامج الضارة بدقة مع تجنب استخدام واجهات تصحيح الأخطاء في Microsoft ، من أجل أن تكون خلسة قدر الإمكان. تم دمج هذا التصحيح في أداة خط الأوامر المستندة إلى Proof-Of Concept-Ofours ، حيث يتم دمجها مع خطافات API وتسبب في قدرات قوية للغاية.
عندما أظهر العمل الأولي أنه سيكون من الممكن استبدال Microsoft Detours بمحرك API الخاص بـ Cuckoo-Modified Modized ، ولدت فكرة Cape Sandbox. مع إضافة مصحح الأخطاء ، والتفريغ الآلي ، والتصنيف المستند إلى YARA واستخراج التكوين المتكامل ، في سبتمبر 2016 في 44CON ، تم إصدار Cape Sandbox علنًا لأول مرة: Cape الإصدار 1.
في صيف عام 2018 ، كان المشروع محظوظًا لرؤية بداية مساهمات ضخمة من أندري دوميدرافن بروخوفيتسكي ، مساهم في الوقواق منذ فترة طويلة. في عام 2019 ، بدأ مهمة Mammoth المتمثلة في تنفيذ Cape إلى Python 3 وفي أكتوبر من ذلك العام تم إصدار CAPEV2.
تم تطوير Cape وتحسينه بشكل مستمر لمواكبة التطورات في كل من البرامج الضارة ونظام التشغيل. في عام 2021 ، تمت إضافة القدرة على برمجة مصحح الأخطاء في Cape أثناء التفجير عبر عمليات مسح YARA الديناميكية ، مما يتيح إنشاء ممرات ديناميكية لتقنيات مضادة لـ SANDBOX. أصبح نظام التشغيل Windows 10 هو نظام التشغيل الافتراضي ، وتشمل الإضافات المهمة الأخرى سطح المكتب التفاعلي ، و AMSI (واجهة مسح البرامج المضادة للبرامج) ، والتقاط "Syscall" بناءً على Microsoft Nirvana و Directive Direct-Syscall.
يمكن تصنيف البرامج الضارة في كيب عبر ثلاث آليات:
يمكن إجراء التحليل باستخدام إطار عمل Cape الخاص ، بدلاً من ذلك يتم دعم الأطر التالية: Ratdecoders ، DC3-MWCP ، Malduck ، أو Maco
def extract_config(data): سيتم استدعاؤها بواسطة cape_utils.py و 0 مضاعفات.
يستفيد Cape من العديد من تقنيات البرامج الضارة أو السلوكيات للسماح بتفريغ الحمولة النافعة:
ستؤدي هذه السلوكيات إلى حقن الأحمال التي يتم حقنها أو استخلاصها أو إلغاء الضغط عليها لمزيد من التحليل. بالإضافة إلى ذلك ، يقوم Cape تلقائيًا بإنشاء تفريغ العملية لكل عملية ، أو في حالة DLL ، صورة وحدة DLL في الذاكرة. يعد هذا مفيدًا للعينات المعبأة مع باكرات بسيطة ، حيث يتم تفريغ تفريغ صورة الوحدة في كثير من الأحيان بالكامل.
بالإضافة إلى آليات التفريغ "السلبية" الافتراضية لـ Cape ، من الممكن تمكين "التفريغ النشط" الذي يستخدم نقاط التوقف لاكتشاف الكتابة إلى مناطق الذاكرة المخصصة حديثًا أو المحمية ، من أجل التقاط حمولات غير معبأة في أقرب وقت ممكن قبل التنفيذ. يتم تمكين هذا عبر صندوق علامة إرسال الويب أو عن طريق تحديد خيار unpacker=2 ويتم إيقافه افتراضيًا لأنه قد يؤثر على جودة التفجير.
يمكن برمجة CAPE عبر توقيع Yara لتفريغ Packers معين. على سبيل المثال ، تعتبر Packers من النوع UPX شائعًا جدًا ، وعلى الرغم من أن هذه النتيجة في Cape يتم التقاطها بشكل سلبي ، إلا أن الالتقاط الافتراضي يتم بعد بدء التنفيذ. لذلك من خلال الكشف عن باكرات مستمدة من UPX ديناميكيًا عبر توقيع Yara المخصص وإعداد نقطة توقف على تعليمات Packer النهائية ، من الممكن التقاط الحمولة النافعة في نقطة الدخول الأصلية (OEP) قبل أن تبدأ في التنفيذ.
يسمح خيار dump-on-api بلقب الوحدة النمطية عندما يستدعي وظيفة API محددة يمكن تحديدها في واجهة الويب (على سبيل المثال dump-on-api=DnsQuery_A ).
سمح مصحح الأخطاء بتواصل كيب بالاستمرار في التطور إلى ما وراء قدراته الأصلية ، والتي تشمل الآن تجاوزات ديناميكية مضادة للتغوير. نظرًا لأن البرامج الضارة الحديثة عادة ما تحاول التهرب من التحليل داخل صناديق الرمل ، على سبيل المثال باستخدام مصائد التوقيت للاستمتاع الظاهري أو اكتشاف خطاف API ، فإن Cape يسمح بتطوير تدابير ديناميكية للدمج بين إجراءات التصحيح في توقيعات YARA للكشف عن البرامج الضارة المراوغة أثناء تفجيرها ، وتنفيذ معالجة تدفق التحكم في فرض العينة تمامًا على الإجراءات المنفصلة للانزلاق.
أصبح الوصول السريع إلى مصحح الأخطاء ممكنًا مع خيارات التقديم bp0 من خلال قبول قيم RVA أو bp3 لضبط نقاط التوقف ، حيث سيتم إخراج أثر تعليمي قصير ، يحكمه خيارات count depth (على سبيل المثال bp0=0x1234,depth=1,count=100 ). 
لتعيين نقطة توقف في نقطة إدخال الوحدة ، يتم استخدام ep بدلاً من العنوان (على سبيل المثال bp0=ep ). بدلاً من ذلك ، يتيح break-on-return نقطة توقف على عنوان الإرجاع لواجهة برمجة تطبيقات مدمن مخدرات (على سبيل المثال break-on-return=NtGetContextThread ). تتيح المعلمة اختيارية base-on-api لتعيين قاعدة صور RVA عن طريق استدعاء API (على سبيل المثال base-on-api=NtReadFile,bp0=0x2345 ).
Options action0 - action3 تتيح تنفيذ الإجراءات عندما يتم ضرب نقاط التوقف ، مثل إلقاء مناطق الذاكرة (على سبيل المثال action0=dumpebx ) أو تغيير تدفق التحكم في التنفيذ (على سبيل المثال action1=skip ). تحتوي وثائق Cape على أمثلة أخرى على هذه الإجراءات.
المستودع الذي يحتوي على رمز شاشة الرأس متميزة.
هناك مستودع مجتمعي للتوقيعات التي تحتوي على عدة مئات من التوقيعات التي طورها مجتمع كيب. يجب دفع جميع ميزة المجتمع الجديدة إلى هذا الريبو. في وقت لاحق يمكن نقلها إلى Core إذا كانت Devs قادرة وعلى استعداد للحفاظ عليها.
يرجى المساهمة في هذا المشروع من خلال المساعدة في إنشاء توقيعات جديدة أو محلات أو تجاوزات لمزيد من العائلات الخبيثة. هناك الكثير في الأعمال حاليًا ، لذا شاهد هذه المساحة.
شكراً جزيلاً لـ @d00m3dr4v3n على رأس النقل بمفرده إلى Python 3.
بيثون 3
يجب تنفيذ الجذر فقط كجذر ، والباقي كمستخدم 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 Folder.systemctl restart <service_name>journalctl -u <service_name>-h للحصول على قائمة المساعدة. يمكن أن يساعد تشغيل الخدمة في وضع التصحيح ( -d ) أيضًا.-h ، ولكن يرجى التحقق من البرامج النصية لفهم ما يفعلونه.git pullpython3 utils/community.py -waf see -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 في عملك ، فيرجى الاستشهاد به كما هو محدد في قائمة GitHub "استشهد بهذا المستودع".
pefile كإصدار دبابيس يريدون.pefile كما تم تثبيته بالفعل. VOLIA لا مزيد من الألم.
