oldkingcone/byosiتجنب EDR بالطريقة البسيطة، عن طريق عدم لمس أي من واجهات API التي يراقبونها.
تجاوز EDRs بالطريقة البسيطة، بعدم لمس أي واجهات برمجة تطبيقات (API) التي يراقبونها.
لاحظت أن معظم أنظمة EDR تفشل في فحص ملفات السكريبت، وتتعامل معها ببساطة كملفات نصية. قد يكون هذا أمرًا مؤسفًا لهم، لكنه فرصة لنا للاستفادة.
الطرق البرّاقة مثل البقاء في الذاكرة أو حقن الخيوط (thread injection) تتم مراقبتها بشدة. بدون وجود ملف ثنائي موقّع من مرجع تصديق (Certificate Authority) صالح، يكاد يكون التنفيذ مستحيلاً.
هنا يأتي دور BYOSI (اجلب مترجم السكريبت الخاص بك). كل مترجم سكريبت موقّع من منشئه، وكل شهادة صالحة. أظهر الاختبار في بيئة حية نتائج مدهشة: سكريبت PHP ذو توقيع عالٍ من هذا المستودع لم يعمل فقط على أنظمة مراقبة بواسطة CrowdStrike وTrellix، بل أنشأ أيضًا اتصالاً خارجيًا دون أن يؤدي إلى أي كشف من EDR. أنظمة EDR تتجاهل عادةً ملفات السكريبت، وتركز بدلاً من ذلك على الملفات الثنائية لتسليم الحمولة. فهي مهيأة للكشف عن الأنتروبيا العالية أو الأقسام المشبوهة في الملفات الثنائية، وليس السكريبتات البسيطة.
طريقة الهجوم هذه تستغل تلك الفجوة لتحقيق ربح كبير. خطوات سكريبت PowerShell تحاكي ما قد يفعله المطور عند دخوله بيئة جديدة لأول مرة. ومن اللافت للنظر أن أربعة أسطر فقط من كود PowerShell تتجنب تمامًا كشف EDR، كما أن Defender/AMSI عاجز عن رؤيته. ولزيادة الفعالية، يعمل GitHub كموزع موثوق.
يحقق سكريبت PowerShell التهرب من EDR/AV من خلال أربع خطوات بسيطة (تقنيًا ثلاث):
1.) يحصل على أرشيف PHP لنظام Windows ويستخرجها في مجلد جديد باسم 'php' داخل 'C:\Temp'.
2.) ثم يتابع السكريبت للحصول على سكريبت PHP الخاص بالحمولة أو الصدفة، ويحفظه في نفس الدليل 'C:\Temp\php'.
3.) بعد ذلك، ينفذ الحمولة أو الصدفة، مستخدمًا الملف الثنائي PHP المسموح به (والذي يعفي الملف الثنائي من معظم القيود المفروضة التي كانت ستمنع تشغيله من الأساس).
عند إتمام هذه الإجراءات، تهانينا: لديك الآن صدفة نشطة على نظام مراقب بواسطة Crowdstrike. والمثير للسخرية هو أن، إذا كانت ذاكرتي صحيحة، فإن Sentinel One غير قادر على فحص أنواع ملفات PHP. لذا، لا تتردد في إطلاق العنان لمخيلتك.
أنا لست مسؤولًا بأي حال من الأحوال عن سوء استخدام هذا الأمر. هذه المشكلة هي نقطة عمياء كبيرة في حماية EDR، أنا فقط ألفت انتباه الجميع إليها.
شكر كبير لـ @im4x5yn74x على تسميته بمودة BYOSI، ومساعدتي في البيئة للاختبار لإحياء طريقة الهجوم هذه.
يبدو أن MS Defender أصبح الآن يضع علامة على سكريبت PHP كخبيث، لكنه لا يزال يسمح بتشغيل سكريبت PowerShell بالكامل. لذا، قم بتعديل سكريبت PHP. المشكلة الآن أن موقع PHP أزال أرشيف zip الأولي، لذا ستحتاج إلى تعديل ذلك السطر من الكود، إنه السطر 1. ابحث عن إصدار تريد استخدامه، وانفجر، حصلت على صدفة، Defender لا يضع علامة على سكريبت PHP، لا يوجد بائع AV يحدد السكريبت بشكل صحيح، هذا لا يزال يعمل بمعدل نجاح 100%.
مرحبًا sentinel one :) ربما تأكد من أنك تجعل الروابط غير مضمنة.
مرحبًا فريق claude.