Skip to content
KitploitKITPLOIT
أدواتعمليات الاستغلالالمدونة
Log in
إرسال
أدواتعمليات الاستغلالالمدونة
إرسال

أدوات الاختراق واختبار الاختراق والأمن السيبراني لترسانتك الأمنية!

Kitploit هو دليل لأدوات الاختراق والأمن السيبراني واختبار الاختراق. اكتشف آخر تحديثات المشاريع للعثور على الثغرات وتحليل الأنظمة وأتمتة الاختبارات وتعزيز أمنك.

··الخلاصات·اتصال·الخصوصية·© 2026 Kitploit

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
BeatRev — POC لإحباط/هزيمة محللي البرامج الضارة | Kitploit
أدوات/GitHubGitHub/octoberfest7/beatrev
الهندسة العكسيةتحليل البرمجيات الخبيثةالتعلم والتعليمتطوير الحمولات
GitHuboctoberfest7/beatrev

BeatRev

POC لإحباط/هزيمة محللي البرامج الضارة

عرض المستودع
1542213منذ 4 سنواتتمت المراجعة من قبل Kitploit

الأكثر شعبية

عرض الكل →

اكتشف الأدوات الأكثر استخدامًا من قبل مجتمعنا.

استكشف جميع الأدوات

تصفح مجموعتنا من الأدوات

عرض جميع الأدوات →
مشاركة

BeatRev الإصدار 2

إخلاء المسؤولية/المسؤولية

العمل التالي عبارة عن إثبات مفهوم (POC) لتمكين البرامج الضارة من "تقييد" نفسها بضحية معينة من أجل إعاقة جهود محللي البرامج الضارة.

أنا لا أتحمل أي مسؤولية عن الاستخدام الخبيث لأي أفكار أو كود موجود داخل هذا المشروع. أقدم هذا البحث لتثقيف المتخصصين في أمن المعلومات بشكل أكبر وتوفير تدريب إضافي/مادة للتفكير لمحللي البرامج الضارة، ومهندسي الهندسة العكسية، وفرق الدفاع بشكل عام.

خلاصة

في المرة الأولى التي يتم فيها تشغيل البرنامج الضار على ضحية، يقوم بتشفير الحمولة الفعلية (RDLL) باستخدام AES باستخدام بيانات بيئية من تلك الضحية. في كل مرة لاحقة يتم فيها تشغيل البرنامج الضار، يقوم بجمع نفس المعلومات البيئية، وفك تشفير الحمولة المخزنة كمصفوفة بايت داخل البرنامج الضار باستخدام AES، وتشغيلها. إذا فشل فك التشفير/فشلت الحمولة في العمل، يقوم البرنامج الضار بحذف نفسه. حماية ضد مهندسي الهندسة العكسية ومحللي البرامج الضارة.

تم التحديث في 6 يونيو 2022

image

لم أشعر أن هذا المشروع قد اكتمل، لذا عدت وقمت بإعادة كتابة كبيرة إلى حد ما. يمكن العثور على البحث الأصلي والتقنيات هنا.

التغييرات الرئيسية هي كما يلي:

  1. قمت بنشر جميع كود المصدر
  2. قمت بدمج ReflectiveDLL الخاص بـ Stephen Fewer في المشروع لاستبدال Stage2
  3. قمت بتنسيق بعض مصفوفات البايت في هذا المشروع إلى تنسيق سلسلة وتحليلها باستخدام UuidFromStringA. تم استخدام هذا المستودع كقالب. تم ذلك لتقليل الانتروبيا في Stage0 و Stage1
  4. تم بناء Stage0 بقدر كبير من التهرب من برامج مكافحة الفيروسات. شكرًا لمشروع Project Ares الخاص بـ Cerbersec للإلهام
  5. تم تضمين تطبيق البناء لإنتاج Stage0

هناك العديد من الأشياء المختلفة التي يمكن أخذها من كود المصدر لهذا المشروع لاستخدامها في أماكن أخرى. نأمل أن يكون مفيدًا لشخص ما.

مشاكل الإصدار الأصلي والحلول

كانت هناك بعض القصور في الإصدار الأصلي من BeatRev التي قررت محاولة معالجتها.

كان Stage2 سابقًا ملفًا تنفيذيًا مستقلاً يتم تخزينه كتيار بيانات بديل (ADS) لـ Stage1. لتحقيق التشفير باستخدام AES حسب الضحية ثم فك التشفير والتنفيذ، في كل مرة يتم تشغيل Stage1 كان يقرأ ADS، ويفك تشفيره، ويكتب مرة أخرى إلى ADS، ويستدعي CreateProcess، ثم يعيد تشفير Stage2 ويكتبه مرة أخرى إلى القرص في ADS. كان هذا الكثير من عمليات الإدخال/الإخراج وبالطبع لم يكن استدعاء CreateProcess جيدًا.

صادفت بحث Steven Fewer حول DLLs الانعكاسية وبدا مناسبًا. Stage2 الآن هو RDLL؛ يمكن نقل برنامجنا الضار/مشغل الشيل كود/أي شيء نريد حمايته إلى تنسيق RDLL وتخزينه كمصفوفة بايت داخل Stage1 يتم فك تشفيرها عند وقت التشغيل وتنفيذها بواسطة Stage1. هذا يزيل جميع عمليات الإدخال/الإخراج واستدعاء CreateProcess من الإصدار 1 وهو تغيير مرحب به.

لم يكن لدى Stage1 أي إجراءات حقيقية للتهرب من برامج مكافحة الفيروسات مبرمجة؛ كان هذا متعمدًا، حيث إنه عمل إضافي ولم يكن هدف هذا البحث حقًا. أثناء إعادة الكتابة، أخذتها كتحدٍ إضافي وأضفت تجزئة API لإزالة الوظائف من جدول عناوين الاستيراد (IAT) لـ Stage1. وقد ساعد هذا في الاكتشاف وأصبح لدى Stage1 معدل اكتشاف 4/66 على VirusTotal. كنت مرتاحًا لتحميل Stage1 نظرًا لأنه مقيد بالفعل بالجهاز الأصلي الذي تم تشغيله عليه وتتغير بصمة الملف باستمرار بسبب تشفير AES الذي يحدث.

بدأت مؤخرًا في الانتباه إلى الانتروبيا كوسيلة لاكتشاف البرامج الضارة؛ لمحاولة خفض الانتروبيا العالية جدًا التي يعطيها blob ثنائي مشفر بـ AES ضخم لملف تنفيذي، بحثت في دمج شيل كود مخزن كـ UUIDs. نظرًا لأن الثنائي مخزن في تمثيل سلسلة، فهناك انتروبيا أقل بشكل عام في الملف التنفيذي. باستخدام هذه التقنية، أصبحت انتروبيا Stage0 الآن ~6.8 و Stage1 ~4.5 (على مقياس أقصى 8).

أخيرًا، إنها مهمة ضخمة لدمج وإنتاج Stage0 كامل بسبب جميع القطع التي يجب التلاعب بها. لتسهيل ذلك، قمت بإنشاء تطبيق بناء يمكنه استيعاب ملف قالب Stage0.c، و stub Stage1، و stub Stage2، وملف شيل كود خام (تم بناء هذا حول Stage2 كمشغل شيل كود يحتوي على شيل كود CobaltStrike) وإنتاج حمولة Stage0 مترجمة للاستخدام على الهدف.

تفاصيل تقنية

يحتوي كود DLL الانعكاسي من Stephen Fewer على بعض التعليمات الخاصة بمترجم Visual Studio؛ أنا متأكد من أنه من الممكن نقل التقنية إلى MingW ولكن ليس لدي المهارات للقيام بذلك. المشكلة الرئيسية هنا هي أن شيل كود CobaltStrike (بدون حالة ~265K) يجب أن يوضع داخل RDLL ويتم ترجمته. للتغلب على هذا ودمجه بشكل جيد مع بقية العملية، كتبت Stage2 RDLL الخاص بي ليحتوي على كتلة ذاكرة متغيرة عامة بحجم شيل كود CS؛ تحتوي كتلة الذاكرة ~265K هذه على عنصر نائب صغير يمكن تحديده في الثنائي المترجم. تمت إضافة هذا بالفعل في الكود في src/Stage2.

بمجرد الترجمة، يتم نقل هذا Stage2stub إلى kali حيث يمكن إجراء تصحيح ثنائي لوضع شيل كود CS الحقيقي في المكان المناسب في الذاكرة. ينتج عن هذا Stage2 الكامل.

لتجنب كارثة الإدخال/الإخراج و CreateProcess الموصوفة سابقًا، يجب أيضًا تصحيح Stage2 الكامل في Stage1 المترجم بواسطة Stage0؛ هذا ضروري للسماح بتشفير Stage2 مرة واحدة على الهدف بالإضافة إلى منع تخزين Stage2 بشكل منفصل على القرص. يتم تنفيذ نفس المفهوم الموصوف سابقًا لـ Stage2 بواسطة Stage0 على الهدف لتجميع حمولة Stage1 النهائية. يجب ملاحظة أن وظيفة memmem تُستخدم لتحديد العنصر النائب داخل كل stub؛ هذه الوظيفة غير متوفرة على Windows، لذا تم استخدام تطبيق مخصص. شكرًا لـ Foxik384 على كوده.

لإجراء تصحيح ثنائي، يجب تخصيص الذاكرة المطلوبة مسبقًا؛ هذا له تأثير تراكمي، حيث يجب أن يكون Stage1 كبيرًا بما يكفي لاحتواء Stage2 أيضًا. مع الخطوة الإضافية لتحويل Stage2 إلى سلسلة UUID، يتضخم حجم Stage2 وكذلك Stage1 لاستيعابه. ينتج عن Stage2 RDLL بحجم مترجم ~290K حمولة Stage0 ~1.38M، وحمولة Stage1 ~700K.

يدعم تطبيق البناء فقط إنشاء ملفات EXE x64. ومع ذلك، مع القليل من العمل الإضافي، من الناحية النظرية يمكنك جعل Stage0 DLL، وكذلك Stage1، وجعل دورة الحياة بأكملها موجودة كاختراق DLL بدلاً من ملف تنفيذي مستقل.

التعليمات

ستساعدك هذه التعليمات على البدء في استخدام هذا POC.

  1. قم بترجمة Builder باستخدام gcc -o builder src/Builder/BeatRevV2Builder.c
  2. قم بتعديل متغير sc_length في src/Stage2/dll/src/ReflectiveDLL.c ليتطابق مع طول ملف الشيل كود الخام المستخدم مع builder (لقد أدرجت fakesc.bin كمثال)
  3. قم بترجمة Stage2 (في Visual Studio، يستخدم مشروع ReflectiveDLL بعض التعليمات الخاصة بمترجم VS)
  4. انقل stage2stub.dll المترجم مرة أخرى إلى kali، وقم بتعديل src/Stage1/newstage1.c وحدد stage2size كحجم stage2stub
  5. قم بترجمة stage1stub باستخدام x86_64-w64-mingw32-gcc newstage1.c -o stage1stub.exe -s -DUNICODE -Os -L /usr/x86_64-w64-mingw32/lib -l:librpcrt4.a
  6. قم بتشغيل builder باستخدام الصيغة: ./builder src/Stage0/newstage0_exe.c x64 stage1stub.exe stage2stub.dll shellcode.bin
  7. سينتج builder ملف dropper.exe. هذه حمولة Stage0 منسقة ومترجمة للاستخدام على الهدف.

BeatRev الإصدار الأصلي

مقدمة

منذ حوالي 6 أشهر، خطر ببالي أنه بينما تعلمت وفعلت الكثير مع البرامج الضارة فيما يتعلق بالتهرب من برامج مكافحة الفيروسات / EDR، فقد أمضيت القليل من الوقت في محاولة التهرب أو هزيمة الهندسة العكسية / تحليل البرامج الضارة. كان ذلك لعدة أسباب وجيهة:

  1. لا أعرف أي شيء عن تحليل البرامج الضارة أو الهندسة العكسية
  2. عندما نتحدث عن عمل الفريق الأحمر القانوني والمصرح به، لا توجد حاجة حقيقية لمحاولة إحباط أو هزيمة مهندس عكسي لأن النشاط يجب أن يكون قد تم تسوية النزاعات بشأنه قبل فترة طويلة من الوصول إلى تلك المرحلة.

ومع ذلك، كانت تجربة فكرية مثيرة للاهتمام وكان لدي بعض الزملاء الذين يعرفون بالفعل عن تحليل البرامج الضارة الذين يمكنني تبادل الأفكار معهم. بدا الأمر تحديًا بحجم مختلف تمامًا مقارنة بالتهرب من برامج مكافحة الفيروسات / EDR وقررت أن أحاوله.

الفرضية

تنزيل الأداة