طريقة الاستخدام

1.

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

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

2.

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

هذا ضروري حتى نتمكن من استخراج صادراته وتضمينها في حمولة DLL الخاصة بنا. من المهم الحصول على DLL القابل للاختطاف من نفس الجهاز الذي ترغب في استخدام DropSpawn عليه، لأن DLL تتغير بين إصدارات 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 <payload DLL> <x86|x64> <program to spawn> [writable target folder] [parent]

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

مثال: dropspawn /root/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 يقوم فقط بإنشاء عملية جديدة؛ العملية المُنشأة حديثاً هي المسؤولة عن تخصيص وكتابة وتنفيذ الشيفرة البرمجية، لذا يمكننا تجنب الكثير من IOC المرتبطة عادةً بحقن العمليات عن بُعد.

هذه التقنية بالطبع تعتمد على جودة حمولات 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 يكاد يكون أكثر وضوحاً من القيام به بدونه. قد يختلف هذا اعتماداً على منتج الأمان.

القيود

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

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

الاعتمادات

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

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

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