DropSpawn

مقدمة

DropSpawn هو BOF من CobaltStrike يُستخدم لتشغيل Beacons إضافية عبر طريقة غير معروفة نسبيًا لاختطاف DLL. يعمل مع x86-x86 و x64-x64 و x86-x64/العكس. استخدمه كبديل لحقن العمليات.

ستتبع الملفات التنفيذية لنظام Windows ترتيب البحث عن DLL عند محاولة تحميل DLLs التي لم يتم تحديد مساراتها المطلقة:

يتطلب اختطاف DLL عادةً أحد الشرطين التاليين:

أ. أن يكون لدى المستخدم أذونات كتابة في مجلد له أولوية ترتيب بحث أعلى من المجلد الذي يوجد فيه DLL الحقيقي

أو

ب. ألا يكون DLL المعني موجودًا في أي مكان على النظام، وفي هذه الحالة يمكن وضعه في مجلد قابل للكتابة من قبل المستخدم في متغير %PATH% الخاص بالمستخدم (مثل %USERPROFILE%\appdata\local\microsoft\windowsapps).

هذه المتطلبات تستبعد اختطاف DLL للملفات التنفيذية الموجودة في C:\Windows\System32 لأن جميع DLLs التي تحملها هذه الملفات التنفيذية موجودة أيضًا في System32. نسخ ملف تنفيذي من System32 إلى موقع قابل للكتابة من قبل المستخدم وتشغيله هناك هو خيار، لكنه ليس آمنًا جدًا من حيث OPSEC لأن الملفات التنفيذية System32 التي تعمل من مواقع بديلة يسهل التعرف عليها.

يمكّن DropSpawn اختطاف DLL باستخدام الملفات التنفيذية System32 (وأخرى موجودة في مجلدات إضافية غير قابلة للكتابة من قبل المستخدم) عن طريق تزوير "الدليل الذي يتم تحميل التطبيق منه" إلى دليل عشوائي يحدده المستخدم.

ملاحظة:

يختلف الإصدار العام من DropSpawn قليلاً عن الإصدار غير العام. يستخدم الإصدار غير العام أداة إنشاء حمولة خاصة، مما يجعل التجربة أكثر سلاسة للمشغل. تم تعديل الإصدار العام قليلاً لمراعاة حقيقة أن المستخدمين سيكون لديهم طرقهم الخاصة لإنشاء حمولات متوافقة مع اختطاف DLL. تم تضمين برنامج Python3 بالإضافة إلى الكود المصدري لـ DLL توضيحي لمساعدة المستخدمين في دمج واستخدام dropspawn.

كيفية الاستخدام

1.

حدد بعض الملفات التنفيذية المستهدفة التي تحاول تحميل DLLs دون تحديد مساراتها المطلقة. يمكنك القيام بذلك عن طريق نسخ الملف التنفيذي إلى دليل قابل للكتابة من قبل المستخدم وتشغيله مع مراقبته باستخدام Procmon. في هذا المثال سنستخدم WerFault.exe الذي يوجد عادةً في C:\Windows\System32\WerFault.exe

في المثال أعلاه، cryptsp.dll و wer.dll و dbghelp.dll و bcrypt.dll كلها مرشحة قابلة للتطبيق لأن مساراتها المطلقة لم يتم تحديدها داخل WerFault؛ نتيجة لذلك، سيحاول WerFault تحميلها من دليل التطبيق الخاص به أولاً قبل اللجوء إلى باقي ترتيب بحث DLL. لاحظ أن هذا ليس مصدر قلق عادةً لأن دليل تطبيق WerFault هو System32.

2.

قم بتنزيل أحد DLLs القابلة للاختطاف من النظام المستهدف.

هذا ضروري حتى نتمكن من استخراج صادراته وتضمينها في حمولة DLL الخاصة بنا. من المهم الحصول على DLL القابل للاختطاف من نفس الجهاز الذي ترغب في استخدام DropSpawn عليه، لأن DLLs تتغير بين إصدارات Windows. بالإضافة إلى ذلك، إذا كنت تستخدم beacon من طراز x86 وتريد تشغيل beacon من طراز x64 باستخدام DropSpawn، فتأكد من تنزيل النسخة x64 من DLL الحقيقي عن طريق تحديد 'C:\windows\sysnative...' بدلاً من 'C:\windows\system32...'.

3.

قم بتشغيل generate_dll.py، مع تمرير DLL الذي تم تنزيله وبنية الحمولة المطلوبة. Generate_dll.py هو نسخة معدلة من هذا البرنامج النصي. سيقوم بتحليل DLL المقدم، وإنشاء ملف .def يحتوي على صادرات DLL، واستدعاء MingW لتجميع حمولة DLL التوضيحية الخاصة بنا. عندما يحاول العملية المشغلة استدعاء دالة حقيقية داخل DLL المزيف، ستقوم حمولة DLL الخاصة بنا بإعادة توجيه الاستدعاء إلى DLL الحقيقي الموجود في System32 حتى لا يتعطل العملية المضيفة.

4.

استدعِ dropspawn باستخدام حمولة DLL المُنشأة.

dropspawn <حمولة DLL> <x86|x64> <برنامج للتشغيل> [مجلد هدف قابل للكتابة] [الأصل]

حمولة DLL - المسار الكامل لحمولة DLL المُنشأة.
البنية - بنية العملية التي ترغب في تشغيلها
برنامج للتشغيل - اسم/مسار العملية التي ترغب في تشغيلها. إذا كانت هذه العملية موجودة في System32 (أو syswow64)، يمكنك فقط تحديد الاسم. بخلاف ذلك، حدد المسار الكامل. يمكنك أيضًا تقديم وسائط سطر أوامر للعملية. إذا كانت هناك مسافات في المسار/إذا كنت تستخدم وسائط، فضع كل شيء بين علامتي اقتباس.
مجلد هدف قابل للكتابة - اختياري. إذا تم تركه فارغًا، سيحاول dropspawn استخدام الدليل الحالي لـ Beacon. استخدم علامات الاقتباس إذا كانت هناك مسافات في المسار.
الأصل - اختياري. اسم العملية التي سيتم استخدامها لتزوير PPID مع العملية المنشأة حديثًا. إذا تم تحديد عملية بها عدة مثيلات قيد التشغيل بمستويات امتياز مختلفة (مثل svchost.exe)، سيحاول dropspawn تحديد واحدة يمكن استخدامها لتزوير PPID.

مثال: dropspawn /root/gitlab/DropSpawn_BOF/dist/dbgcore.dll x64 "WerFault.exe -u -p 4352 -s 160" C:\users\user\appdata\local\temp explorer.exe

سيؤدي ذلك إلى إسقاط حمولة DLL 'dbgcore.dll' على القرص في 'c:\users\user\appdata\local\temp\dbgcore.dll' وتشغيل عملية WerFault.exe من طراز x64 مع وسائط سطر الأوامر '-u -p 4352 -s 160' و explorer.exe كعملية أصل.

5.

التنظيف سهل. من خلال تضمين وظيفة الحذف الذاتي في حمولة DLL التي يتم إسقاطها على القرص، سيتم حذفها بمجرد أن تبدأ عمليتنا الجديدة وتقوم بتحميلها. هذا هو تغيير قواعد اللعبة، حيث عادةً ما يكون DLL مقفلاً على القرص طالما أن عمليتنا التي حملته لا تزال قيد التشغيل. إذا فشلت تقنية الحذف الذاتي لسبب ما (أو فشلت العملية في التشغيل)، سيحاول DropSpawn حذف حمولة DLL من القرص وسيبلغ المستخدم بنتيجة العملية في كلتا الحالتين.

الكشف

عادةً ما يتبع حقن العمليات سلسلة: فتح عملية عن بعد -> تخصيص ذاكرة عن بعد -> كتابة ذاكرة عن بعد -> تنفيذ ذاكرة عن بعد، مع خيار تشغيل عملية جديدة في البداية بدلاً من استخدام عملية موجودة. يقوم DropSpawn فقط بإنشاء عملية جديدة؛ العملية المنشأة حديثًا هي المسؤولة عن تخصيص وكتابة وتنفيذ شيل كود، لذا يمكننا تجنب الكثير من مؤشرات الاختراق (IOCs) المرتبطة عادةً بحقن العمليات عن بعد.

هذه التقنية بالطبع مرهونة بمدى جودة حمولات DLL الخاصة بك. لكن يمكننا إلقاء نظرة على ما يراه Windows (هذا القسم التالي يستخدم الإصدار الخاص من DropSpawn وتشغيل Beacons).

بقدر ما يهتم Event Viewer، كل شيء يبدو طبيعيًا:

في MDE هناك القليل جدًا يمكن رؤيته.

تشغيل dropspawn:

سجلات MDE:

مع تزوير PPID:

بدون تزوير PPID:

في كلتا الحالتين نرى عملية beacon الأصلية الخاصة بنا (أيضًا werfault) تسقط dbgcore.dll على القرص، وتنشئ عملية WerFault.exe جديدة، وتقوم العملية المنشأة حديثًا بتحميل dbgcore.dll، ثم إعادة تسميته (حذفه). من المهم عدم وجود تدقيق إضافي لـ dbgcore.dll الذي غالبًا ما يأتي مع اختطاف DLL لأننا لا نكتبه في أي موقع يتم اختطافه غالبًا، و WerFault.exe (أو أي عملية تختار استخدامها) ليس مرتبطًا حقًا باختطاف DLL بالطريقة التي ترتبط بها أشياء مثل WmiPrvSE.exe.

من المثير للاهتمام أنه يكاد يكون من الأكثر وضوحًا القيام بذلك باستخدام تزوير PPID بدلاً من بدونه. قد يختلف هذا اعتمادًا على منتج الأمان.

القيود

كما ذُكر، من الضروري أن يقوم المستخدمون بتنزيل DLLs الحقيقية من الجهاز المستهدف الذي يخططون لاستخدام DropSpawn عليه. استخدام إصدار خاطئ من DLL يمكن أن يتسبب في تعطل العملية المشغلة إذا حاولت استدعاء دالة غير موجودة.

يمكن استخدام DropSpawn مع الملفات التنفيذية خارج System32؛ كن محذرًا مع ذلك من أن المشاكل يمكن أن تنشأ إذا حاولت العملية تحميل DLLs إضافية من دليل التطبيق الحقيقي للعملية. لأننا قمنا بتزوير دليل التطبيق في مكان آخر، إذا لم يكن دليل التطبيق الحقيقي قابلًا للوصول أيضًا عبر ترتيب بحث DLL بطريقة أخرى، فستتعطل العملية أو تفشل في البدء لأنها لا تستطيع تحديد موقع DLLs الأساسية. اختبر دائمًا الاختطافات المحتملة على أجهزة التطوير قبل استخدامها في الإنتاج!

الإسناد

جاء هذا البحث أولاً بينما كنت أستكشف كيفية قيام العمليات بتجميع ترتيب بحث DLL النهائي الخاص بها (حيث يجب تحديده في وقت التشغيل بسبب وجود الملفات التنفيذية في أدلة مختلفة، والدليل الحالي جزء من مسار البحث، وما إلى ذلك). قادني بحثي إلى منشور المنتدى هذا، والذي كان بمثابة أصل واجهتي API غير الموثقتين الحاسمتين اللتين تشكلان جوهر هذه التقنية.

لقد تم ربطهما سابقًا بالفعل، لكن هذا المنشور بخصوص تجنب قفل المُحمل و هذا البرنامج النصي لإنشاء ملف .def لوكالة DLL و هذا البحث حول تمكين الحذف الذاتي للملفات التنفيذية قيد التشغيل ضرورية لإنتاج حمولات DLL فعالة وجاهزة للاستخدام مناسبة لـ DropSpawn.

عندما نشرت هذه التقنية لأول مرة على Twitter، انضم العديد من الآخرين إلى المحادثة وأنتجوا براهين مفهوم. أنتج SecurityAndStuff هذا، بينما لدى Snovvcrash خاصته هنا