DSCourier BOF

هذا تنفيذ BOF لمشروع Dylan Davis وMatthew Schramm's DSCourier. يستخدم واجهة COM الخاصة بـ WinGet لتنفيذ كود powershell عشوائي في عملية موقعة وموثوقة من Microsoft. يمكن العثور على مدونة البحث الكاملة هنا.

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

الاستخدام

ضع كود powershell العشوائي الخاص بك في ملف dist/rev.yml. افتراضيًا، يحتوي على شيل عكسي بسيط لـ powershell من المستودع الأصلي. إذا اخترت استخدام ذلك، تأكد من استبدال عنوان IP الموجود في المثال بعنوان IP المطلوب.

مثال باستخدام شيل عكسي لـ powershell:

كيفية العمل / القيود

بدون ترتيب معين، فيما يلي بعض المشكلات/القيود المتعلقة بهذه الأداة.

1. لكي تنجح استدعاءات COM، يجب أن يكون ملف Microsoft.Management.Configuration.winmd موجودًا في نفس الدليل الذي يوجد به الملف التنفيذي الذي يقوم باستدعاءات COM. يشكل هذا مشكلة فورية عند تشغيل Beacon من عملية system32 مجوفة على سبيل المثال، حيث لا يملك المستخدمون العاديون أذونات الكتابة. للتغلب على ذلك، يتم إسقاط الملف بدلاً من ذلك إلى %APPDATA%\temp ويتم ربط دالة WinTypes!RoGetMetaDataFile التي تسترجع مسار ملف winmd بربط داخلي (inline hook) بحيث يمكننا توفير موقع المسار المؤقت. يسمح هذا بقراءة ملف winmd / نجاح استدعاءات COM، ولكنه يعني وجود استدعاءات VirtualProtect وكتابة فوق ذاكرة DLL مما ينشئ مؤشرات اختراق (IOCs).
2. تبعًا للنقطة الأولى، يتم قفل ملف winmd على القرص بعد تشغيل BOF حتى يخرج عملية Beacon. قمت ببعض المحاولات لحل هذه المشكلة، بما في ذلك إضافة وظيفة الحذف الذاتي المعروفة جيدًا، لكن الملف بقي مقفلاً على القرص. قد يكون من الممكن هندسة حل حول ذلك، لكن هذا متروك لشخص آخر لمتابعته.
3. كما ذُكر في البحث الأصلي، نظرًا لاستخدام مورد pwsh داخل WinGet، يتم إنشاء عملية conhost.exe تحت ConfigurationRemotingServer.exe. اقترح Claude أنه سيكون من الممكن تحميل وحدة ثنائية مخصصة كمورد بدلاً من استدعاء pwsh، مما قد يحل مشكلة conhost، لكن هذا يتطلب إسقاط ملفات إضافية على القرص ولم أتمكن من جعلها تعمل. قد لا يكون ذلك ممكنًا. إذا كان ممكنا، فإنه يفتح الباب لإسقاط ملف .NET عام على القرص يمكن تحميله بواسطة ConfigurationRemotingServer.exe وتنفيد شيل كود/معاملات/إلخ.
4. ينفذ هذا BOF الإصدارات غير المتزامنة (Async) من واجهات COM المطلوبة. استخدام الإصدارات المتزامنة (Sync) يؤدي إلى تعليق Beacon / عدم استدعائه مرة أخرى حتى تنتهي عملية ConfigurationRemotingServer.exe؛ مع مثال الشيل العكسي البسيط، هذا يعني أن Beacon لن يتصل مرة أخرى حتى يتم قتل الشيل. التبديل إلى الواجهات غير المتزامنة يمنع هذه المشكلة، ولكنه يقدم بعض مشكلات التوقيت. هناك نوم ثابت لمدة 3 ثوانٍ يعمل عمليًا لتأخير بين استدعاءات محددة، لكن هذا بالطبع ليس الطريقة الصحيحة لتطبيقه.
5. تم الحصول على تعريفات واجهات COM عن طريق تنزيل حزمة .msixbundle الخاصة بـ winget-cli من Github، واستخراجها، واستخراج ملف .msix، والعثور على ملف .winmd. تم استخدام winmdidl.exe لاستخراج ملفات IDL. ثم تم استخدام midlrt.exe لتحويل IDL إلى ملفات رؤوس/.c، ثم تم تحليلها بواسطة Claude لتحتوي فقط على التعريفات المطلوبة. لا يزال فوضى من الكود. رابط Microsoft هذا سيكون مفيدًا على الأرجح لفهم هذه العملية بشكل أفضل.
6. الكود بشكل عام نوع من الفوضى لأنه لم يتجاوز مرحلة إثبات المفهوم.
7. يجب تشغيل الأمر winget configure --enable مرة واحدة على الأقل على الجهاز الهدف قبل أن ينجح BOF. تتبعت سبب ذلك إلى حقيقة أن دليل DotNet الذي يحتوي على ConfigurationremotingServer.exe غير موجود حتى يتم تشغيل الأمر / تنزيل الثنائي. توجد هذه الملفات في C:\Program files\WindowsApps\... وبالتالي لا يمكن الكتابة فيها من قبل مستخدم ذي صلاحيات منخفضة، لذا لا يمكننا حتى إسقاط هذه الملفات بأنفسنا باستخدام BOF وجعل الأمور تعمل.
8. نظرت في الأمر، وبقدر ما أعرف، هذه ليست واجهات DCOM، بل COM فقط. لذا هذه ليست بدائية قابلة للاستخدام للحركة الجانبية إلى أجهزة أخرى.
9. بسبب النقطة رقم 7، هذا لا يجعلها طريقة جيدة/موثوقة للوصول الأولي في رأيي. إذا وصلت إلى جهاز مع تعطيل WinGet (راجع التدوينة الأصلية)، أو إذا لم يتم تشغيل الأمر configure --enable، ستتوقف تمامًا. لأغراض ما بعد الاستغلال، قد يكون له قيمة، لكنك مقيد إلى حد ما بأنها عملية ثابتة ستقوم بتوليد/تشغيل الكود الخاص بك، وبما أنها pwsh، سيكون هناك AMSI في اللعبة.

التجميع

تمت كتابة هذه الأداة دون استخدام تعريفات API المعتادة لـ BOF (مثل ملف bofdefs.h). كما هو موضح في منشور المدونة هذا بواسطة Matt Ehrnschwender، من الممكن استخدام objcopy لتصحيح الرموز المناسبة بالتنسيق DLL$API في BOF بعد التجميع.

لقد كتبت أداة تسمى BOFPatcher تقوم بأتمتة هذه العملية. يسمح هذا للمستخدمين بكتابة BOFs كـ C عادي دون القلق بشأن تعريفات API المرهقة:

هذه الأداة متاحة لمن يشترون دورتي BOF Development and Tradecraft.

بينما أداة BOFPatcher غير مضمنة في هذا المستودع، فإن ملف Makefile لهذه الأداة يستدعي objcopy، ويمرر ملف imports_dscourier64.txt الذي يحتوي على استبدالات الرموز المناسبة مما يجعل BOF قابلاً للاستخدام.

الاعتمادات

1. عمل رائع من Dylan وMatt. أتمنى رؤية المزيد منهم!
2. Claude لكتابة معظم هذا الكود بشكل تقريبي.