TrollDump

• يقوم بحقن DLL مُدار بنية 64 بت في عملية 64 بت مُدارة أو غير مُدارة (يجب أن تحتوي العملية على واجهة رسومية لأننا نحصل على مقبض نافذتها) باستخدام setwindowshook
• هنا كأداة ترفيهية (TROLL)، نقوم بالحقن في نافذة taskmgr المخفية لعمل تفريغ لـ lsass بدون اكتشاف (انظر قسم حالة الاختبار أدناه)
• إن DLL الحاقن وDLL المُحقن هما نفس DLL وبالتالي لا يلزم DLL إضافي
• يجب أن يكون مستوى السلامة (Integrity level) للعملية الهدف مساويًا أو أقل من مستوى عملية الحاقن

الاعتمادات (ترقية/إعادة كتابة للمشروع)

المشروع الأصلي: https://github.com/enkomio/ManagedInjector

• تم نقل الكود للحقن في ملفات ثنائية 64 بت ---> المشروع الأصلي يسمح فقط بحقن DLL في ملفات ثنائية 32 بت
• تمت إزالة منطق IPC لأنه كان مُرهقًا
• تم إنشاء كود أساسي (boilerplate) لتشغيل الحمولة مباشرة داخل الدالة RunOnRemoteProcess() بدلاً من الطريقة المعقدة السابقة
• المشروع لا يزال يستخدم DLLExport لجعل DLL من .NET يقوم بتصدير الدوال
  • ملاحظة: هذا ليس تبعية للمشروع بل هو معالجة لاحقة. DLLExport سيعدّل ملف DLL النهائي الخاص بـ .NET لتصدير دالة.
  • يمكنك القيام بتصدير الدالة يدويًا إذا أردت https://blog.xpnsec.com/rundll32-your-dotnet/

التجميع

• قم بتنزيل المشروع وقم بتجميع الحل بصيغة X64، Release
• لا حاجة لتبعيات خارجية

الاستخدام

> Requires High Integrity depending on use case
> [System.Reflection.Assembly]::LoadFrom("C:\Users\public\TrollDump.dll")
> [TrollDump.ForFun]::Main("C:\windows\system32\taskmgr.exe")

• في هذا المثال التجريبي (POC)، نقوم بتفريغ lsass، ويمكنك تشغيل أي "منطق دالة مُصدَّرة من DLL" تريده بتعديل الدالة RunOnRemoteProcess() وإعادة التجميع.
• كما ذُكر سابقًا، يعمل الكود كأساس (boilerplate) لحقن DLL، وما تختار فعله بعد ذلك يمكن كتابته بسهولة في كود مُدار بلغة C#.

حالة الاختبار

• نظام Win 2019 الإصدار 17763.737 مع أحدث تصحيحات Windows Defender
  • كل من حقن الـ DLL وتفريغ lsass يعملان
• برامج مكافحة فيروسات أخرى (بدون تسمية)
  • حقن الـ DLL يعمل بشكل جيد
  • من الواضح أن نجاح تفريغ lsass يعتمد على ما إذا كان برنامج مكافحة الفيروسات يسمح لـ taskmgr بتفريغ lsass أم لا
• لم يتم اختباره على أي EDRs -> أعتقد أن حقن الـ DLL يجب أن يعمل على بعض EDRs المحددة

OPSEC

• يجب أن يكون DLL على القرص لذا يجب أن يكون مشوّشًا (obfuscated)
• يجب استخدام DLL فقط لعملية الحقن، ولا ينبغي أبدًا تضمين الحمولة الفعلية داخل DLL ويجب تحميلها بشكل انعكاسي (reflectively)
• من الواضح أن حقن CLR في عملية غير مُدارة أمر مثير للشكوك، لكن مهلاً!
• setwindowshook على الرغم من أنها تقنية كلاسيكية وغالبًا ما ترتبط بتسجيل المفاتيح، إلا أنها ليست حالة استخدامنا
• يمكنك أن تكون مبدعًا للغاية مع أي عملية واجهة رسومية تريد حقنها (إذا كنت تعمل كحساب النظام، يمكنك الحقن في dwm.exe أيضًا)

قائمة الأماني - تم إنجاز المشروع في عطلة نهاية الأسبوع وليس لدي وقت/نية لمتابعة ما يلي:

• الحقن في عملية بدون واجهة رسومية
  • حاليًا بالنسبة لـ setwindowshook يستخدم WH_CALLWNDPROC، يمكنك تعديله لاستخدام WH_GETMESSAGE لكن يجب أن تشغّل العملية الهدف حلقة رسائل (GetMessage())
  • إذا تمكنت من العثور على ملف ثنائي غير واجهة رسومية ينفذ حلقة رسائل (أعتقد أنه غير مرجح) فيمكنك الحقن في الملفات الثنائية بدون واجهة رسومية أيضًا
  • من الشائع أن تقوم عمليات الواجهة الرسومية بتشغيل GetMessage()
• انعكاسي بالكامل وليس بحاجة إلى إنزاله على القرص
  • بناءً على setwindowshook، يبدو أن DLL يجب أن يكون على القرص؟
  • حاولت استخدام المفوضات (delegates) في C# لتمرير مؤشر دالة لتشغيله بدلاً من دالة DLL المُصدَّرة ولم ينجح ذلك (هذه هي تقنية keylogger الكلاسيكية لـ C# للعملية المحلية لكننا نعمل على عملية بعيدة)
  • يمكنك تجربة ذلك من خلال دمج تقنيات أخرى، أعتقد أنه قابل للتنفيذ
• سيقوم Taskmgr تلقائيًا بالظهور بمستوى سلامة عالٍ (High Integrity) حتى لو كانت العملية الحالية بمستوى Medium (لذا تقنيًا إذا حقنت DLL فيه، فهذا تجاوز لـ UAC)
  • يبدو أن الحقن يعمل بشكل جيد وفقًا لنتائج إرجاع Win API
    • على الرغم من أن sendMessage() تنجح، إلا أن الرسالة تُسقط بصمت. الشرح هنا https://stackoverflow.com/questions/40122964/cross-process-postmessage-uipi-restrictions-and-uiaccess-true
  • ومع ذلك، يفشل taskmgr في استدعاء الدالة المُصدَّرة

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

• يجب استخدامه فقط للأغراض التعليمية!