octoberfest7/eventvieweruac_bofتطبيق Beacon Object File لإلغاء تسلسل عارض الأحداث لتجاوز UAC
هذا تطبيق Beacon Object File لاختراق UAC عن طريق إلغاء التسلسل (Deserialization) في Event Viewer، اكتشفها @orange_8361 وقام بتجميع الإثبات بواسطة CsEnox.
تم اختباره على Win10/Win11 بنية x64.
يقوم هذا الاختراق لـ UAC بتنفيذ الإجراءات التالية التي يجب مراعاتها بخصوص OPSEC:
-1. كتابة ملف ثنائي إلى %LOCALAPPDATA%\Microsoft\Event Viewer\RecentViews
-2. استدعاء ShellExecute() لبدء mmc.exe / Event Viewer
--A. سيفتح Event Viewer بواجهة رسومية!
--B. سيقوم Event Viewer باستدعاء cmd.exe
---a. سيقوم cmd.exe باستدعاء Taskkill لإغلاق mmc.exe
---b. سيقوم cmd.exe بطباعة رسالة خطأ على نافذة الكونسول التي قد تبقى مفتوحة، بقصد خداع المستخدم ليظن أنه لا يوجد خطأ
---c. سيقوم cmd.exe بتنفيذ أي أوامر أخرى يقدمها المستخدم
-3. يتم حذف الملف الثنائي من %LOCALAPPDATA%\Microsoft\Event Viewer\RecentViews
اتباعًا للعرض الأصلي وإثبات CsEnox، تم استخدام ysoserial لإنشاء حمولة أولية:
ysoserial.exe -o raw -f BinaryFormatter -g TextFormattingRunProperties -c "taskkill /f /im mmc.exe >nul && echo Windows has Recovered from an Unexpected Error. You may Close this Window. &&" > cmd.bin
يعمل هذا الاختراق لـ UAC عن طريق استدعاء mmc.exe، الذي يفتح على الشاشة ويجب إغلاقه. للأسف لم أجد طريقة لبدء mmc.exe دون فتح الواجهة الرسومية؛ لقد جربت CreateProcess() وعلامة CREATE_NO_WINDOW، لكن CreateProcess() لا تتعامل بشكل جيد مع UAC. منشورات StackOverflow في هذا الموضوع وجهتني إلى API ShellExecuteA() التي تحتوي على علامة SW_HIDE (وغيرها)، لكن ذلك لم ينجح. يبدو أن ظهور mmc.exe على الشاشة أمر لا مفر منه.
Ysoerial يستدعي cmd.exe /c، لذا نستخدمه لاستدعاء taskkill من أجل إغلاق mmc.exe. ويستخدم && لربط الأوامر معًا بحيث يمكن تنفيذ الإجراء المطلوب كمسؤول. لقد وجدت أثناء الاختبار أنه في بعض الحالات يؤدي هذا الإجراء إلى إبقاء موجه cmd.exe الذي تم إنشاؤه بواسطة mmc.exe مفتوحًا؛ وهذا يحدث عند استدعاء حمولات Local Injector (العادية)، مثل الحمولة التنفيذية الافتراضية لـ Cobalt Strike. لمعالجة ذلك، قمت بتوجيه إخراج أمر taskkill (الذي كان يطبع سابقًا على cmd.exe المفتوح) إلى /dev/null، وطبعت على الشاشة رسالة بخصوص خطأ تمت معالجته، محاولًا جعل هذا السلوك المشبوه لا يثير قلق مستخدم غير ملم.
الحمولات التي تُنشئ عملية، تحقن فيها، ثم تخرج، لن تبقي نافذة cmd.exe مفتوحة، وبالتالي تكون الرسالة غير ضرورية. وبالمثل، الأوامر التي تُنفذ وتخرج (مثل net user Administrator newpassword) لن تبقي النافذة مفتوحة.
يمكنك تنفيذ أوامر مشفرة بـ PowerShell عبر هذا BOF:
أمر taskkill والرسالة للمستخدم مدمجان في أمر ysoserial. إذا أردت تغيير هذا السلوك، فستحتاج إلى تشغيل أمر ysoserial الخاص بك واتباع العرض أدناه حول كيفية إنشاء الكود.
باستخدام أداة مخصصة، تم استيعاب الملف الثنائي وطباعته بصيغة الهيكس (hex):
بنسخ هذا إلى المفكرة والبحث عن '&' في الهيكس، نحدد البايتات المطلوبة (لاحظ أن هناك عدة مجموعات منها، نحتاج إلى المجموعة الأخيرة):
يتم تقسيم الحمولة إلى جزئين فورًا بعد هذه البايتات:
يتم حساب طول كل جزء وتسجيله لاحقًا.
هنا تتعقد الأمور.
بصراحة، لا أعرف الكثير عن إلغاء التسلسل أو ysoserial، لكنني اكتشفت أن هناك مجموعة من البايتات في الحمولة تمثل طول الجزء "المهم" من الحمولة، بما في ذلك الأمر المعرف من المستخدم. يمكن رؤية ذلك في لقطة الشاشة التالية لتفريغ هيكس جنبًا إلى جنب لحمولتين مختلفتين تم إنشاؤهما بواسطة ysoserial، كل منهما تحتوي على أمر مختلف لتنفيذه:
لأسباب لا أستطيع تفسيرها، تعكس هذه البايتات طول الحمولة بالنظام الأساسي 128 (base-128)؛ يتم ضرب 0x05 في 128 لينتج 640؛ ويتم إضافة ذلك إلى قيمة البايت الآخر (0xb0 أو 0xd4) ناقص 128؛ لاحظت أنه عندما يفيض البايت الثاني (0x05 إلى 0x06)، يبدأ البايت الأول من جديد عند 0x80 بدلاً من 0x00 كما قد يُتوقع.
تبدو الحمولة المستخدمة في هذه الأداة كما يلي:
بتحويل جميع القيم إلى النظام العشري، تبدو العملية الحسابية كالتالي:
(6 × 128) + (180−128) = 820
حجم الملف هو 1042؛ لقد وجدت في الاختبار أنه (مع هذه الأداة من ysoserial على أي حال) يوجد دائمًا فرق 222 بايت بين حجم الملف والطول المعكوس في هذه المجموعة من البايتات. يبدو أن هذه الـ 222 بايت تمثل "رأس الحمولة".
يتم نسخ كلا جزئي الحمولة إلى main.c، حيث يتم تعيين الطول الأصلي 820 كمتغير أيضًا. يتم حساب طول الأمر المعرف من المستخدم، ويتم إضافة هذه القيمة إلى 820 الأصلية (بالإضافة إلى بايت إضافي واحد للمسافة التي يجب إدراجها) من أجل حساب القيمة النهائية التي يجب تمثيلها في هذه المجموعة من البايتات. يتم حساب البايت الثاني بقسمة LenBytes على 128، ويتم حساب البايت الأول بإيجاد باقي LenBytes وإضافة 128 (لاستيعاب كيف يبدأ من 0x80).
بمجرد تعيين هذه البايتات، يتم نسخها إلى المخزن المؤقت Before في المكان المناسب لتعيين طول الحمولة إلى القيمة الصحيحة بناءً على المحتوى. ثم يتم تجميع المخزن المؤقت النهائي:
ثم يتم كتابة الحمولة النهائية إلى القرص واستدعاء mmc.exe لتنفيذها. بعد ذلك يتم تنظيف الحمولة.
x86_64-w64-mingw32-gcc -o EventViewerUAC.x64.o -Os -c main.c -DBOF
يقدم ysoserial خيار --rawcmd حيث يمكنك استدعاء ملف تنفيذي مختلف بدلاً من cmd.exe، لكن لا يمكنك تقديم أي وسائط له. يفتح هذا الباب لاستدعاء حمولتك مباشرة دون استدعاء cmd.exe وبالتالي عدم ترك نافذة الكونسول مفتوحة؛ ومع ذلك لن يكون هناك ما يغلق mmc.exe في هذه الحالة. يمكن للمرء كتابة حمولاته لتحديد العملية الأم للحمولة، وإذا كانت mmc.exe، قتل mmc.exe لتنظيف هذا الاختراق. هذا ممكن جدًا، لكنني لم أتكبد عناء القيام بذلك لأن هذا واحد من عدة اختراقات لـ UAC، وليس الجميع ينشئون حمولاتهم المخصصة بهذا الشكل. قد أدمجها في المشغلات الشخصية الخاصة بي.