ModuleShifting

تم تقديم هذه الأداة في محاضرة x33fcon 2023: "تحسين خفاء تقنيات حقن الذاكرة" [فيديو] [مقال]

ما هي

ModuleShifting هي نسخة أكثر خفاءً من تقنية حقن Module Stomping و Module Overloading. تم تنفيذها فعليًا باستخدام Python ctypes بحيث يمكن تنفيذها بالكامل في الذاكرة عبر مترجم Python و Pyramid، وبالتالي تجنب استخدام المحملات المترجمة.

يمكن استخدام التقنية مع حمولات PE أو شيلكود، ومع ذلك، فإن النسخة الأكثر خفاءً تُستخدم مع حمولات الشيلكود التي تحتاج إلى أن تكون مستقلة وظيفيًا عن الحمولة النهائية التي يقوم الشيلكود بتحميلها.

عند استخدام ModuleShifting مع حمولة شيلكود، فإنها تقوم بالعمليات التالية:

1. تحميل الـ dll المضيف الشرعي عبر LoadLibrary
2. تغيير صلاحيات الذاكرة لقسم محدد إلى RW
3. الكتابة فوق الشيلكود على القسم المستهدف
4. إضافة حشوة اختيارية للاندماج بشكل أفضل مع السلوك الإيجابي الكاذب (مزيد من المعلومات هنا)
5. تغيير الصلاحيات إلى RX
6. تنفيذ الشيلكود عبر مؤشر دالة - طرق تنفيذ إضافية: استدعاء دالة أو واجهة CreateThread API
7. كتابة محتوى الـ dll الأصلي فوق الشيلكود المنفذ - هذه الخطوة تتجنب ترك أثر ضار في مساحة ذاكرة الصورة للـ dll المضيف. يجب أن يكون الشيلكود مستقلاً وظيفيًا عن المراحل اللاحقة وإلا سينكسر التنفيذ.

عند استخدام حمولة PE، ستقوم ModuleShifting بالعملية التالية:

1. تحميل الـ dll المضيف الشرعي عبر LoadLibrary
2. تغيير صلاحيات الذاكرة لقسم محدد إلى RW
3. نسخ الـ PE فوق نقطة الهدف المحددة قسمًا بقسم
4. إضافة حشوة اختيارية للاندماج بشكل أفضل مع السلوك الإيجابي الكاذب
5. إجراء إعادة التوطين الأساسية
6. حل الواردات
7. إنهاء القسم عن طريق تعيين الصلاحيات إلى قيمها الأصلية (تجنب إنشاء منطقة ذاكرة RWX)
8. تنفيذ استدعاءات TLS
9. تنفيذ نقطة دخول الـ PE

لماذا هو مفيد

يمكن استخدام ModuleShifting لحقن حمولة دون تخصيص ذاكرة ديناميكيًا (أي VirtualAlloc)، وبالمقارنة مع Module Stomping و Module Overloading فهي أكثر خفاءً لأنها تقلل من عدد مؤشرات الاختراق (IoCs) الناتجة عن تقنية الحقن نفسها.

هناك 3 اختلافات رئيسية بين Module Shifting وبعض التطبيقات العامة لـ Module Stomping (واحد من Bobby Cooke و WithSecure)

1. الحشوة: عند كتابة شيلكود أو PE، يمكنك استخدام الحشوة للاندماج بشكل أفضل مع السلوك الإيجابي الكاذب الشائع (مثل تطبيقات الطرف الثالث أو ملفات .net dll التي تكتب x عدد من البايتات فوق قسم .text الخاص بها).
2. تنفيذ الشيلكود باستخدام مؤشر دالة. يساعد هذا في تجنب إنشاء مؤشر ترابط جديد أو استدعاء استدعاءات دالة غير معتادة.
3. استعادة محتوى الـ dll الأصلي فوق الشيلكود المنفذ. هذا فرق رئيسي.

الاختلافات بين Module Shifting و Module Overloading هي التالية:

1. يمكن كتابة الـ PE بدءًا من قسم محدد بدلاً من البدء من PE الخاص بـ dll المضيف. بمجرد اختيار القسم المستهدف بعناية، يمكن أن يقلل ذلك من عدد مؤشرات الاختراق (مثل عدم الكتابة فوق رأس PE الخاص بـ dll المضيف أو كتابة بايتات أقل على قسم .text إلخ.)
2. الحشوة التي يمكن إضافتها إلى حمولة PE نفسها للاندماج بشكل أفضل مع الإيجابيات الكاذبة.

باستخدام حمولة شيلكود مستقلة وظيفيًا مثل حمولة AceLdr Beacon Stageless Shellcode، تستطيع ModuleShifting الحقن محليًا دون تخصيص ذاكرة ديناميكيًا وفي الوقت الحالي تولد صفر مؤشر اختراق (IoC) في فحص Moneta و PE-Sieve. أنا على دراية بأن حمولات AceLdr النائمة يمكن اكتشافها بأدوات رائعة أخرى مثل Hunt-Sleeping-Beacon، لكن التركيز هنا على تقنية الحقن نفسها، وليس على الحمولة. في حالتنا، ما يتيح المزيد من الخفاء في الحقن هو الاستقلال الوظيفي للشيلكود، بحيث يمكن استعادة البايتات الضارة المكتوبة إلى محتواها الأصلي، مما يمحو آثار الحقن بشكل فعال.

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

جميع المعلومات والمحتوى مقدم لأغراض تعليمية فقط. اتبع التعليمات على مسؤوليتك الخاصة. لا يتحمل المؤلف ولا صاحب العمل أي مسؤولية عن أي ضرر أو خسارة مباشرة أو ناتجة تنشأ عن أي شخص أو منظمة.

الاعتمادات

هذا العمل أصبح ممكنًا بفضل المعرفة والأدوات التي شاركها أشخاص رائعون مثل Aleksandra Doniec @hasherezade، Forest Orr و Kyle Avery. لقد استخدمت بشكل مكثف Moneta، PeSieve، PE-Bear و AceLdr طوال عملية التعلم الخاصة بي، وقد كانت أساسية لفهمي لهذا الموضوع.

الاستخدام

يمكن استخدام ModuleShifting مع Pyramid ومترجم Python لتنفيذ الحقن المحلي للعملية بالكامل في الذاكرة، متجنبًا المحملات المترجمة.

1. استنساخ مستودع Pyramid:

git clone https://github.com/naksyn/Pyramid

2. قم بإنشاء حمولة شيلكود باستخدام C2 المفضل لديك وقم بإسقاطها في مجلد Delivery_files الخاص بـ Pyramid. راجع قسم التحذيرات لمتطلبات الحمولة.
3. قم بتعديل معلمات سكريبت moduleshifting.py داخل مجلد Modules الخاص بـ Pyramid.
4. ابدأ خادم Pyramid: python3 pyramid.py -u testuser -pass testpass -p 443 -enc chacha20 -passenc superpass -generate -server 192.168.1.2 -setcradle moduleshifting.py
5. قم بتنفيذ الكود الأساسي (cradle) الذي تم إنشاؤه على مترجم Python.

عرض توضيحي

https://github.com/naksyn/ModuleShifting/assets/59816245/67fcf888-3385-47da-b828-8a2dafeeb1e2

التحذيرات

لتنفيذ هذه التقنية بنجاح، يجب استخدام حمولة شيلكود قادرة على تحميل حمولة إضافية ذاتية الاستدامة في منطقة ذاكرة أخرى. تم اختبار ModuleShifting مع حمولة AceLdr، القادرة على تحميل نسخة كاملة من Beacon في الكومة (heap)، مما يكسر الاعتماد الوظيفي مع الشيلكود الأولي. ستعمل هذه التقنية مع أي حمولة شيلكود لها قدرات مماثلة. يصبح الشيلكود الأولي عديم الفائدة بمجرد تنفيذه، ولا يوجد سبب لإبقائه في الذاكرة كمؤشر اختراق (IoC).

يجب أيضًا اختيار dll مضيف يحتوي على مساحة كافية للشيلكود في القسم المستهدف، وإلا ستفشل التقنية.

فرص الكشف

تحتاج تقنيات Module Stomping و Module Shifting إلى كتابة شيلكود في مساحة ذاكرة dll شرعي. ستزيل ModuleShishing مؤشر الاختراق هذا بعد مرحلة التنظيف، ولكن يمكن للفاحصين ذوي قدرات الفحص في الوقت الفعلي اكتشاف المؤشرات.