octoberfest7/xll_phishing
فنيات التصيد عبر XLL
مع الإعلان الأخير من مايكروسوفت بشأن حظر وحدات الماكرو في المستندات القادمة من الإنترنت (البريد الإلكتروني والتنزيل من الويب)، بدأ المهاجمون في استكشاف خيارات أخرى بقوة لتحقيق الوصول بمساعدة المستخدم (UDA). هناك عدة اعتبارات يجب موازنتها عند البحث عن طريقة تصيد قابلة للتطبيق للوصول:
هذه هي الأسئلة الرئيسية، ولكن هناك بالتأكيد المزيد. تزداد الأمور تعقيدًا عندما تدرك أن هذه العوامل تتراكم على بعضها؛ على سبيل المثال، إذا كان لدى العميل وكيل ويب يمنع تنزيل الملفات القابلة للتنفيذ أو ملفات DLL، فقد تحتاج إلى وضع حمولتك داخل حاوية (ZIP، ISO، إلخ). القيام بذلك قد يسبب مشاكل إضافية في المستقبل فيما يتعلق بالكشف. تتطلب الدفاعات الأكثر قوة مجموعات أكثر تعقيدًا من التقنيات لهزيمتها.
ستتم كتابة هذه المقالة مع افتراض وجود مؤسسة مستهدفة خيالية؛ وقد وظفت هذه المؤسسة العديد من التدابير الدفاعية بما في ذلك قواعد تصفية البريد الإلكتروني، وحظر أنواع معينة من الملفات من التنزيل، وقوائم التطبيقات المسموح بها على نقاط النهاية، وبرنامج Microsoft Defender for Endpoint كحل EDR.
قد لا تستخدم المؤسسات الحقيقية أيًا من هذه، أو بعضها، أو حتى دفاعات أكثر مما يمكن أن يبسط أو يعقد التقنيات الموضحة في هذا البحث. كما هو الحال دائمًا، اعرف هدفك.
ملفات XLL هي ملفات DLL، مصممة خصيصًا لبرنامج Microsoft Excel. بالنسبة للعين غير المدربة، تبدو كثيرًا مثل مستندات Excel العادية.
توفر ملفات XLL خيارًا جذابًا للغاية لـ UDA نظرًا لأنها تُنفذ بواسطة Microsoft Excel، وهو برنامج شائع جدًا في شبكات العملاء؛ وكعلاوة إضافية، نظرًا لأنها تُنفذ بواسطة Excel، فإن حمولتنا ستتجاوز بالتأكيد تقريبًا قواعد قوائم التطبيقات المسموح بها لأن تطبيقًا موثوقًا (Excel) هو الذي ينفذها. يمكن كتابة ملفات XLL بلغة C أو C++ أو C# مما يوفر مرونة وقوة (وعقلانية) أكبر بكثير من وحدات VBA الكبيرة مما يجعلها خيارًا مرغوبًا أكثر.
الجانب السلبي بالطبع هو أن هناك استخدامات شرعية قليلة جدًا لملفات XLL، لذا يجب أن يكون من السهل جدًا على المؤسسات حظر تنزيل هذا الامتداد للملفات عبر البريد الإلكتروني وتنزيل الويب. للأسف، العديد من المؤسسات متخلفة عن الركب لسنوات، وبالتالي تظل ملفات XLL طريقة قابلة للتطبيق للتصيد لبعض الوقت.
هناك سلسلة من الأحداث المختلفة التي يمكن استخدامها لتنفيذ التعليمات البرمجية داخل ملف XLL، وأبرزها هو xlAutoOpen. يمكن رؤية القائمة الكاملة هنا:
عند النقر المزدوج على ملف XLL، يتم الترحيب بالمستخدم بهذه الشاشة:
هذا المربع الحواري الوحيد هو كل ما يفصل المستخدم عن تنفيذ التعليمات البرمجية؛ مع هندسة اجتماعية رقيقة إلى حد ما، يكون تنفيذ التعليمات البرمجية شبه مضمون.
شيء يجب أن نضعه في الاعتبار هو أن ملفات XLL، كونها قابلة للتنفيذ، خاصة بالبنية المعمارية. هذا يعني أنك يجب أن تعرف هدفك؛ إصدار Microsoft Office/Excel الذي تستخدمه المؤسسة المستهدفة سيحدد (عادةً) البنية المعمارية التي تحتاج إلى بناء حمولتك من أجلها.
هناك انفصال واضح في إصدارات Office يمكن استخدامه كقاعدة عامة:
Office 2016 أو أقدم: x86
Office 2019 أو أحدث: x64
يجب ملاحظة أنه من الممكن تثبيت البنية المعمارية الأخرى لكل منتج، لكن هذه هي البنى الافتراضية المثبتة وفي معظم الحالات يجب أن تكون هذه طريقة موثوقة لاتخاذ قرار بشأن البنية المعمارية التي ستستخدمها لملف XLL. بالطبع اعتمادًا على طريقة التسليم والحجة المستخدمة كجزء من حملة التصيد، من الممكن تقديم كلا الإصدارين والاعتماد على الضحية لاختيار الإصدار المناسب لنظامه.
تم بناء حمولة XLL التي تم تطويرها خلال هذا البحث بناءً على هذا المشروع بواسطة edparcell. يحتوي مستودعه على تعليمات جيدة للبدء مع ملفات XLL في Visual Studio، وقد استخدمت كوده كنقطة انطلاق لتطوير ملف XLL ضار.
انحراف ملحوظ عن مستودعه هو أنه إذا كنت ترغب في إنشاء مشروع XLL خاص بك، فستحتاج إلى تنزيل أحدث إصدار من Excel SDK ثم اتباع التعليمات في المستودع المرتبط سابقًا باستخدام هذا الإصدار بدلاً من إصدار 2010 من SDK المذكور في README.
تسليم الحمولة هو اعتبار مهم في سياق UDA. هناك طريقتان رئيسيتان سنركز عليهما:
إما عن طريق إرفاق ملف أو تضمين رابط لموقع ويب يمكن من خلاله تنزيل ملف، فإن البريد الإلكتروني هو جزء حاسم من عملية UDA. على مر السنين، نضجت العديد من المؤسسات (ومزودي البريد الإلكتروني) وفرضت قواعد لحماية المستخدمين والمؤسسات من المرفقات الضارة. يختلف الأداء، لكن المؤسسات لديها الآن القدرة على:
يمكن أن يكون اختبار قواعد البريد الإلكتروني لمؤسسة ما جزءًا مهمًا من المهمة، ومع ذلك يجب دائمًا توخي الحذر حتى لا يتم الكشف عن أن عملية الفريق الأحمر جارية وأن المعلومات يتم جمعها بنشاط.
لأغراض هذه المقالة، سنفترض أن المؤسسة المستهدفة لديها قواعد قوية لمرفقات البريد الإلكتروني تمنع تسليم حمولة XLL. سنتحول وننظر إلى التسليم عبر الويب.
سيظل البريد الإلكتروني مستخدمًا في هذا المتجه الهجومي، ولكن بدلاً من إرسال مرفق، سيتم استخدامه لإرسال رابط إلى موقع ويب. يمكن أن تختلف قواعد الوكيل على الويب وإجراءات الشبكة التخفيفية التي تتحكم في أنواع الملفات المسموح بتنزيلها عن تلك المفروضة فيما يتعلق بمرفقات البريد الإلكتروني. لأغراض هذه المقالة، من المفترض أن المؤسسة تمنع تنزيل الملفات القابلة للتنفيذ (رؤوس MZ) من الويب. في هذه الحالة، من الجدير استكشاف أدوات التعبئة/الحاويات.
المبدأ هو أننا قد نتمكن من وضع ملفنا القابل للتنفيذ داخل نوع ملف آخر وتهريبه عبر سياسات المؤسسة. الاعتبار الرئيسي هنا هو الدعم الأصلي لنوع الملف؛ على سبيل المثال، لا يمكن فتح ملفات 7Z بواسطة Windows دون تثبيت برامج طرف ثالث، لذا فهي ليست خيارًا رائعًا. التنسيقات مثل ZIP و ISO و IMG هي خيارات جذابة لأنها مدعومة أصلاً بواسطة Windows، وكإضافة إضافية، تضيف خطوات إضافية قليلة جدًا للضحية.
للأسف، تمنع المؤسسة تنزيل ISO و IMG من الويب؛ بالإضافة إلى ذلك، نظرًا لأنها تستخدم منع فقدان البيانات (DLP)، لا يمكن للمستخدمين تركيب أجهزة تخزين خارجية، والتي تعتبر ISO و IMG منها.
لحسن الحظ بالنسبة لنا، على الرغم من أن المؤسسة تمنع تنزيل الملفات ذات رؤوس MZ، إلا أنها تسمح بتنزيل ملفات zip التي تحتوي على ملفات قابلة للتنفيذ. يتم فحص ملفات zip هذه بنشاط بحثًا عن البرامج الضارة، بما في ذلك مطالبة المستخدم بكلمة المرور لملفات zip المحمية بكلمة مرور؛ ولكن نظرًا لأن الملف القابل للتنفيذ مضغوط، فإنه لا يتم حظره بواسطة الحظر الشامل لملفات MZ.
تم اختيار ملفات Zip كحاوية لحمولة XLL الخاصة بنا للأسباب التالية:
بشكل ملائم، يؤدي النقر المزدوج على ملف ZIP في Windows إلى فتح هذا الملف المضغوط في مستكشف الملفات:
بشكل أقل ملاءمة، يؤدي النقر المزدوج على ملف XLL من الموقع المضغوط إلى تشغيل Windows Defender؛ حتى عند استخدام المشروع الأساسي من edparcell الذي لا يحتوي على أي نوع من التعليمات البرمجية الضارة.
بالنظر إلى تنبيه Windows Defender، نرى أنه مجرد تنبيه عام "Wacatac":
ومع ذلك، هناك شيء غريب؛ الملف الذي تم تحديده على أنه ضار كان في c:\users\user\Appdata\Local\Temp\Temp1_ZippedXLL.zip\، وليس C:\users\user\Downloads\ZippedXLL\ حيث نقرنا عليه نقرًا مزدوجًا. بالنظر إلى نسخة Excel في ProcessExplorer، نرى أن Excel يقوم بالفعل بتشغيل XLL من appdata\local\temp، وليس من ملف ZIP الذي جاء منه:
يبدو أن هذه مشكلة مرتبطة بملفات ZIP، وليس بملفات XLL. فتح ملف TXT من داخل zip باستخدام notepad يؤدي أيضًا إلى نسخ ملف TXT إلى appdata\local\temp وفتحه من هناك. بينما فتح ملف نصي من هذا الموقع لا بأس به، يبدو أن Defender يحدد أي نوع من تنفيذ التعليمات البرمجية في هذا الموقع على أنه ضار.
إذا قام مستخدم باستخراج XLL من ملف ZIP ثم تشغيله، فسيتم تنفيذه دون أي مشكلة؛ ومع ذلك، لا توجد طريقة لضمان قيام المستخدم بذلك، ولا يمكننا حقًا المخاطرة بإطلاق AV/EDR إذا لم يستخرجوه. إلى جانب ذلك، فإن النقر المزدوج على ZIP ثم النقر المزدوج على XLL هو أبسط بكثير والضحية أكثر عرضة لإكمال تلك الإجراءات البسيطة من عناء استخراج ZIP.
جعلتني هذه المشكلة أفكر في نوع حمولة مختلف عن XLL؛ بدأت في استكشاف VSTO، وهي قوالب Visual Studio لـ Office. أشجعك بشدة على قراءة تلك المقالة.
تقوم ملفات VSTO في النهاية باستدعاء DLL يمكن أن يكون موجودًا محليًا مع ملف .XLSX الذي يبدأ كل شيء، أو يتم استضافته عن بعد وتنزيله بواسطة ملف .XLSX عبر http/https. لا يوفر الخيار المحلي أي مزايا حقيقية (وفي الواقع لديه عدة عيوب حيث أن هناك العديد من الملفات الإضافية المرتبطة بهجوم VSTO)، والخيار البعيد يتطلب للأسف شهادة توقيع تعليمات برمجية أو أن يكون الموقع البعيد شبكة موثوقة. بدون وجود شهادة توقيع تعليمات برمجية صالحة، لا تخفف ملفات VSTO أيًا من المشكلات في هذا السيناريو التي تواجهها حمولة XLL الخاصة بنا.
يبدو أننا حقًا محاصرون في زاوية هنا. تشغيل XLL نفسه أمر جيد، ومع ذلك لا يمكن تسليم XLL بمفرده للضحية إما عبر مرفق البريد الإلكتروني أو تنزيل الويب بسبب سياسة المؤسسة. يجب تعبئة XLL داخل حاوية، ومع ذلك بسبب تنسيقات DLP مثل ISO و IMG و VHD غير قابلة للتطبيق. يحتاج الضحية إلى أن يكون قادرًا على فتح الحاوية أصلاً دون أي برنامج طرف ثالث، مما يترك ZIP كخيار؛ ولكن كما نوقش، يؤدي تشغيل XLL من مجلد مضغوط إلى نسخه وتشغيله من appdata\local\temp مما يؤدي إلى إطلاق AV.
قضيت ساعات طويلة في العصف الذهني واختبار الأشياء، والنزول في جحر الأرانب VSTO، واستكشاف جميع الخيارات الممكنة حتى قررت أخيرًا تجربة شيء غبي جدًا لدرجة أنه قد ينجح فقط.
هذه المرة قمت بإنشاء مجلد، ووضعت XLL بداخله، ثم ضغطت المجلد:
النقر على المجلد يكشف عن ملف XLL:
النقر المزدوج على XLL يعرض موجه الإضافة من Excel. لاحظ أن XLL لا يزال منسوخًا إلى appdata\local\temp، ومع ذلك هناك طبقة إضافية بسبب المجلد الإضافي الذي أنشأناه:
النقر على "تمكين" ينفذ تعليماتنا البرمجية دون إطلاق Defender:
رائع! تنفيذ التعليمات البرمجية. ماذا الآن؟
ستختلف الحجة المستخدمة لإقناع الضحية بتنزيل وتنفيذ XLL بشكل كبير بناءً على المؤسسة وطريقة التسليم؛ قد تشمل المواضيع بيانات رواتب الموظفين، أو حاسبات التعويضات بناءً على مجموعة المهارات، أو معلومات حول مشروع، أو قائمة حضور لحدث، إلخ. مهما كان الإغراء، سيكون هجومنا أكثر فعالية إذا قدمنا للضحية بالفعل ما وعدوا به. بدون متابعة، قد يصبح الضحايا مشبوهين ويبلغون فرق الأمن الخاصة بهم، مما يمكن أن يكشف المهاجم بسرعة ويحد من الوصول إلى النظام المستهدف.
XLL بمفرده سيترك نافذة Excel فارغة بعد انتهاء تنفيذ تعليماتنا البرمجية؛ سيكون من الأفضل بكثير لنا أن نقدم جدول بيانات Excel الذي يبحث عنه الضحية.
يمكننا تضمين ملف XLSX الخاص بنا كمصفوفة بايت داخل XLL؛ عندما يتم تنفيذ XLL، سيقوم بإسقاط ملف XLSX على القرص بجوار XLL وبعد ذلك سيتم فتحه. سنقوم بتسمية ملف XLSX بنفس اسم XLL، والفرق الوحيد هو الامتداد.
نظرًا لأن XLL الخاص بنا مكتوب بلغة C، يمكننا جلب بعض القدرات من مقالة سابقة كتبتها عن قدرات الحمولة في لغة C، وهي الحذف الذاتي. يؤدي الجمع بين هاتين التقنيتين إلى حذف XLL من القرص، وإسقاط XLSX بنفس الاسم مكانه. بالنسبة للعين غير المدركة، سيبدو أن XLSX كان موجودًا طوال الوقت.
لسوء الحظ، فإن الموقع الذي يتم فيه حذف XLL وإسقاط XLSX هو مجلد appdata\temp\local، وليس ZIP الأصلي؛ لمعالجة هذا يمكننا إنشاء ZIP ثانٍ يحتوي على XLSX بمفرده وقراءته أيضًا كمصفوفة بايت داخل XLL. عند التنفيذ بالإضافة إلى الإجراءات المذكورة أعلاه، يمكن لـ XLL محاولة تحديد موقع ملف ZIP الأصلي في c:\users\victim\Downloads\ وحذفه قبل إسقاط ZIP الثاني الذي يحتوي فقط على XLSX في مكانه. يمكن أن يفشل هذا بالطبع إذا قام المستخدم بحفظ ZIP الأصلي في موقع مختلف أو باسم مختلف، ولكن في كثير من الحالات / معظمها يجب أن يتم إسقاطه تلقائيًا في مجلد تنزيلات المستخدم.
توضح لقطة الشاشة هذه في الجزء السفلي المجلد المؤقت الذي تم إنشاؤه في appdata\local\temp الذي يحتوي على XLL و XLSX الذي تم إسقاطه، بينما يظهر الجزء العلوي نافذة مستكشف الملفات الأصلية التي تم فتح XLL منها. لاحظ في الجزء السفلي أن حجم XLL يساوي 0. هذا لأنه قام بحذف نفسه أثناء التنفيذ، ومع ذلك حتى يتم إغلاق الجزء العلوي، لن يختفي ملف XLL تمامًا من موقع appdata\local\temp. حتى إذا قام الضحية بالنقر على XLL مرة أخرى، فهو الآن خامل ولا وجود له حقًا.
وبالمثل، بمجرد أن يخرج الضحية من ZIP المفتوح في مستكشف الملفات (إما عن طريق إغلاقه أو الانتقال إلى مجلد مختلف)، إذا نقر على spreadsheet.zip مرة أخرى، سيجد الآن أن مجلد الاختبار يحتوي على importantdoc.xlsx؛ لذلك تمت إزالة XLL واستبداله بـ XLSX غير الضار في كلا الموقعين الموجودين على القرص.
يوضح هذا GIF تنزيل وتنفيذ XLL على جهاز افتراضي تجريبي لـ MDE. لاحظ أنه لسبب ما يفتح Excel مثيلين هنا؛ على جهاز الكمبيوتر المنزلي الخاص بي، فتح مثيلًا واحدًا فقط، لذلك لست متأكدًا تمامًا من سبب الاختلاف.
كما هو الحال دائمًا، سنسأل "ماذا يرى MDE؟"
إغراق لقطة شاشة سريع لإثبات أنني قمت بتنفيذ هذا على الهدف والتقطت إشارة عودة على TestMachine11:
أولاً، لا توجد تنبيهات:
ماذا يلتقط الجدول الزمني/سجل الأحداث؟
يا للهول. الحقيقة أنني لا أعرف من أين تأتي تنبيهات تسجيل المفاتيح وتشفير وفك تشفير بيانات الاعتماد لأن تعليماتي البرمجية لا تفعل أيًا من ذلك. تبدو أفعالنا بالتأكيد مشبوهة عند عرضها بهذه الطريقة، لكنني سأعلق مرة أخرى على مقدار البيانات التي يتم جمعها بواسطة MDE على نقطة نهاية واحدة، ناهيك عن المئات أو الآلاف أو مئات الآلاف التي قد تكون المؤسسة قد ربطتها بـ EDR. طالما أننا لا نطلق أي تنبيهات فعلية، فمن المحتمل أننا بخير.
اللحظة التي كان معظمكم ينتظرها على الأرجح، أنا أقدم نموذجًا تعليمات برمجية لمشغل XLL الذي طورته، مقتصرًا فقط على الأجزاء التي تمت مناقشتها هنا في قسم فنيات العمل. سيكون على القارئ أن يقوم بالفعل بإدخال التعليمات البرمجية في XLL وتنفيذها بالتزامن مع بقية مشغله. كما هو الحال دائمًا، لا تسبب أي ضرر، واحصل على إذن لصيد المؤسسة، إلخ.
لقد أدرجت الكود المصدري لبرنامج يقوم بقراءة ملف وإنتاج سلسلة سداسية عشرية يمكن نسخها في مصفوفات البايت المحددة في المقتطف. استخدم هذا على ملف XLSX الذي ترغب في تقديمه للمستخدم، وكذلك على ملف ZIP الذي يحتوي على المجلد الذي يحتوي على نفس ملف XLSX وقم بتخزينهما في مصفوفات البايت الخاصة بهما. قم بتجميع هذا الكود باستخدام:``` gcc -o ingestfile ingestfile.c
واجهت بعض المشكلات في تجميع ملفات XLL الخاصة بي باستخدام MingW على جهاز kali، لذا فكرت في نشر الأوامر هنا:
**x64**```
x86_64-w64-mingw32-gcc snippet.c 2013_Office_System_Developer_Resources/Excel2013XLLSDK/LIB/x64/XLCALL32.LIB -o importantdoc.xll -s -Os -DUNICODE -shared -I 2013_Office_System_Developer_Resources/Excel2013XLLSDK/INCLUDE/
x86``` i686-w64-mingw32-gcc snippet.c 2013_Office_System_Developer_Resources/Excel2013XLLSDK/LIB/XLCALL32.LIB -o HelloWorldXll.xll -s -DUNICODE -Os -shared -I 2013_Office_System_Developer_Resources/Excel2013XLLSDK/INCLUDE/
بعد التجميع، ستحتاج إلى إنشاء مجلد جديد ونسخ ملف XLL إلى ذلك المجلد. ثم قم بضغطه باستخدام:```
zip -r <myzipname>.zip <foldername>/
لاحظ أنه لكي تعمل التقنيات الموضحة في هذا المنشور، ستحتاج إلى مطابقة بعض المتغيرات في مقتطف الشيفرة مع ما تسميه ملف XLL والملف المضغوط.
مع اقتراب نهاية هيمنة وحدات الماكرو الخاصة بـ Office، تقدم ملفات XLL خيارًا جذابًا لحملات التصيد. مع بعض الإبداع، يمكن استخدامها بالتزامن مع تقنيات أخرى لتجاوز العديد من طبقات الدفاعات التي تنفذها المؤسسات وفرق الأمن. شكرًا لك على القراءة، وآمل أن تكون قد تعلمت شيئًا مفيدًا!