Freeze هي مجموعة أدوات حمولة (Payload) لتجاوز أنظمة EDR عبر العمليات المعلّقة واستدعاءات النظام المباشرة وطرق التنفيذ البديلة.
لعرض أحدث إصدار من Freeze أو لتقديم مشكلة، راجع https://github.com/Tylous/Freeze.
إذا كنت ترغب في معرفة المزيد عن التقنيات المستخدمة في هذا الإطار، يرجى إلقاء نظرة على مدونة SourceZero
Freeze هي أداة لإنشاء الحمولات تُستخدم لتجاوز ضوابط أمان EDR لتنفيذ shellcode بطريقة متخفية. تستخدم Freeze تقنيات متعددة ليس فقط لإزالة خطافات EDR في مساحة المستخدم، ولكن أيضًا لتنفيذ shellcode بطريقة تتجاوز ضوابط مراقبة نقاط النهاية الأخرى.
عند إنشاء عملية، يتم تحميل Ntdll.dll كأول ملف DLL. يحدث هذا قبل تحميل أي ملفات DLL خاصة بـ EDR. وهذا يعني أن هناك تأخيرًا بسيطًا قبل أن يتم تحميل EDR والبدء في ربط وتعديل كود تجميع ملفات DLL النظامية. عند النظر إلى استدعاءات النظام الخاصة بـ Windows في Ntdll.dll، يمكننا رؤية أنه لم يتم ربط أي شيء بعد. إذا قمنا بإنشاء عملية في حالة معلقة (مجمدة زمنياً)، يمكننا رؤية أنه لم يتم تحميل أي ملفات DLL أخرى باستثناء Ntdll.dll. يمكنك أيضًا رؤية أنه لم يتم تحميل أي ملفات DLL خاصة بـ EDR، مما يعني أن استدعاءات النظام الموجودة في Ntdll.dll غير معدلة.
لاستخدام هذه العملية النظيفة المعلقة لإزالة الخطافات من محمل Freeze، نحتاج إلى طريقة للعثور على ذاكرة العملية النظيفة المعلقة وقراءتها برمجيًا. هذا هو المكان الذي تلعب فيه عشوائية تخطيط مساحة العنوان (ASLR). ASLR هي آلية أمان لمنع الثغرات القائمة على تلف ذاكرة المكدس. تقوم ASLR بعشوائية مساحة العنوان داخل العملية، لضمان أن جميع الكائنات المعينة في الذاكرة، المكدس، الكومة، والبرنامج القابل للتنفيذ نفسه، فريدة من نوعها. الآن، هذا هو المكان الذي يصبح فيه الأمر مثيرًا للاهتمام لأنه بينما تعمل ASLR، إلا أنها لا تعمل مع الكود المستقل عن الموقع مثل ملفات DLL. ما يحدث مع ملفات DLL (خاصة ملفات DLL النظامية المعروفة) هو أن مساحة العنوان يتم عشوائيتها مرة واحدة عند وقت الإقلاع. هذا يعني أننا لا نحتاج إلى تعداد معلومات عملية بعيدة للعثور على العنوان الأساسي لـ ntdll.dll الخاص بها لأنه هو نفسه في جميع العمليات بما في ذلك العملية التي نتحكم بها. نظرًا لأن عنوان كل ملف DLL هو نفسه في كل إقلاع، يمكننا سحب هذه المعلومات من عمليتنا الخاصة ولا نضطر أبدًا إلى تعداد العملية المعلقة للعثور على العنوان.
باستخدام هذه المعلومات، يمكننا استخدام API ReadProcessMemory لقراءة ذاكرة عملية. يرتبط استدعاء API هذا عادةً بقراءة LSASS كجزء من أي هجوم قائم على بيانات الاعتماد؛ ومع ذلك، فهو في حد ذاته ليس ضارًا بطبيعته، خاصة إذا كنا فقط نقرأ قسمًا عشوائيًا من الذاكرة. الوقت الوحيد الذي سيتم فيه وضع علامة على ReadProcessMemory كشيء مشبوه هو إذا كنت تقرأ شيئًا لا ينبغي لك (مثل محتويات LSASS). لا ينبغي لمنتجات EDR أبدًا وضع علامة على حقيقة أن ReadProcessMemory تم استدعاؤه، نظرًا لوجود استخدامات تشغيلية مشروعة لهذه الوظيفة والتي قد تؤدي إلى العديد من الإيجابيات الخاطئة.
يمكننا أن نأخذ هذا خطوة أخرى إلى الأمام بقراءة قسم واحد فقط من Ntdll.dll حيث يتم تخزين جميع استدعاءات النظام - قسم .text الخاص به، بدلاً من قراءة ملف DLL بالكامل.
من خلال الجمع بين هذه العناصر، يمكننا الحصول برمجيًا على نسخة من قسم .text الخاص بـ Ntdll.dll لاستبدال قسم .text المربوط الحالي قبل تنفيذ shellcode.
يستخدم ETW استدعاءات النظام المضمنة لتوليد هذه البيانات عن بعد. نظرًا لأن ETW أيضًا ميزة أصلية مدمجة في Windows، لا تحتاج منتجات الأمان إلى "ربط" استدعاءات النظام الخاصة بـ ETW للوصول إلى المعلومات. ونتيجة لذلك، لمنع ETW، يقوم Freeze بتصحيح العديد من استدعاءات النظام الخاصة بـ ETW، ومسح السجلات وإعادة تدفق التنفيذ إلى التعليمات التالية. أصبح تصحيح ETW الآن الافتراضي في جميع المحملات.
نظرًا لأنه يتم استعادة Ntdll.dll فقط، يجب أن توجد جميع الاستدعاءات اللاحقة لتنفيذ shellcode في Ntdll.dll. باستخدام Go (لاحظ أنه يمكنك القيام بذلك بلغات أخرى ولكن في Go، من السهل جدًا تنفيذه) يمكننا تعريف واستدعاء استدعاءات النظام الخاصة بـ NT اللازمة لتخصيص وكتابة وحماية shellcode، متجاوزين بذلك الاستدعاءات القياسية الموجودة في kernel32d.dll و Kernelbase.dll، حيث قد تكون هذه لا تزال مربوطة.
تم تطوير Freeze بلغة Golang.
لتثبيت Freeze، قم بتشغيل الأوامر التالية، أو استخدم الملف الثنائي المجمع:
go build Freeze.go
___________
\_ _____/______ ____ ____ ________ ____
| __) \_ __ \_/ __ \_/ __ \\___ // __ \
| \ | | \/\ ___/\ ___/ / /\ ___/
\___ / |__| \___ >\___ >_____ \\___ >
\/ \/ \/ \/ \/
(@Tyl0us)
Soon they will learn that revenge is a dish... best served COLD...
Usage of ./Freeze:
-I string
Path to the raw 64-bit shellcode.
-O string
Name of output file (e.g. loader.exe or loader.dll). Depending on what file extension defined will determine if Freeze makes a dll or exe.
-console
Only for Binary Payloads - Generates verbose console information when the payload is executed. This will disable the hidden window feature.
-encrypt
Encrypts the shellcode using AES 256 encryption
-export string
For DLL Loaders Only - Specify a specific Export function for a loader to have.
-process string
The name of process to spawn. This process has to exist in C:\Windows\System32\. Example 'notepad.exe' (default "notepad.exe")
-sandbox
Enables sandbox evasion by checking:
Is Endpoint joined to a domain?
Does the Endpoint have more than 2 CPUs?
Does the Endpoint have more than 4 gigs of RAM?
-sha256
Provides the SHA256 value of the loaders (This is useful for tracking)
يمكن لـ Freeze إنشاء ملف .exe أو .dll. لتحديد ذلك، تأكد من أن خيار سطر الأوامر -O ينتهي إما بـ .exe للثنائيات أو .dll للملفات DLL. لا يتم حاليًا دعم أنواع ملفات أخرى. في حالة ملفات DLL، يمكن لـ Freeze أيضًا إضافة وظائف تصدير إضافية. للقيام بذلك، استخدم -export مع اسم وظيفة تصدير محددة.
تستخدم Freeze تقنية لإنشاء العملية أولاً ثم نقلها إلى الخلفية. هذا يفعل شيئين - أولاً يساعد في إبقاء العملية مخفية، وثانيًا، يتجنب اكتشافها بواسطة أي منتج EDR. يمكن أن يكون إنشاء عملية فورًا في الخلفية مريبًا جدًا ومؤشرًا على الضرر. تقوم Freeze بذلك عن طريق استدعاء وظائف Windows GetConsoleWindow و ShowWindow بعد إنشاء العملية وتحميل خطافات EDR، ثم تغيير سمات النافذة إلى مخفية. تستخدم Freeze واجهات برمجة التطبيقات (APIs) هذه بدلاً من استخدام -ldflags -H=windowsgui التقليدي، حيث أن هذا الأخير موقّع بشكل كبير ويصنف في معظم منتجات الأمان كمؤشر اختراق.
إذا تم تحديد خيار سطر الأوامر -console، فلن تخفي Freeze العملية في الخلفية. بدلاً من ذلك، ستضيف Freeze العديد من رسائل التصحيح التي تظهر ما يفعله المحمل.
شكر خاص لـ aahmad097 لتطوير AlternativeShellcodeExec
شكر خاص لـ mvdan لتطوير Garble