lem0nsec/shellghostتقنية إخفاء قائمة على الذاكرة تجعل shellcode غير مرئي من بداية العملية إلى نهايتها.
تقنية تهرب قائمة على الذاكرة تجعل الشيل كود غير مرئي من بداية العملية إلى نهايتها.
أردت مشاركة هذا الإثبات النظري للحقن الذاتي للشيل كود لعرض بعض مفاهيم التهرب من برامج مكافحة الفيروسات وEDR التي قد تكون مفيدة للفريق الأحمر. قبل بضعة أسابيع فقط، توصلت إلى تقنية تهرب مخصصة في الذاكرة أسميتها ShellGhost. تنبع هذه التقنية من الحاجة إلى كود ينفذ شيل كود 'غير مرئي' من بداية العملية إلى نهايتها.
تعتمد ShellGhost على معالجة الاستثناءات الموجهة (VEH) بالاشتراك مع نقاط التوقف البرمجية لإيقاف تنفيذ الخيط بشكل دوري، واستبدال نقطة التوقف المنفذة بتعليمة شيل كود مشفرة بـ RC4، وفك تشفير التعليمية واستئناف التنفيذ بعد استعادة حماية الذاكرة إلى RX. عندما يتم إثارة EXCEPTION_BREAKPOINT التالي، يقوم معالج الاستثناء باستبدال تعليمة الشيل كود السابقة بنقطة توقف جديدة بحيث لا يكشف التخصيص أبدًا عن الشيل كود الكامل في حالة غير مشفرة. يحدث هذا داخل صفحة ذاكرة خاصة تم وضع علامة عليها مبدئيًا على أنها READ/WRITE. لن يعتبر وجود تخصيص RW PRV 'مؤشر اختراق' من قبل ماسحات الذاكرة مثل PE-Sieve و Moneta. عندما يصبح التخصيص RX ويتم مسح الصفحة، لن يتم العثور على شيء سوى نقاط التوقف. يحدث هذا أثناء تنفيذ الشيل كود فعليًا. تُظهر الصورة التالية أن شيل عكسي يعمل، ولكن لم يتم العثور على أي IOC بواسطة Moneta (بخلاف أن الملف الثنائي غير موقّع).
محاولة مسح العملية باستخدام Pe-Sieve تعطي نتيجة أفضل:
تعيين الشيل كود هو الوظيفة الأساسية لـ ShellGhost. تمكن هذه التكتيك الخيط من تنفيذ التعليمات بشكل متقطع مع عدم كشف الشيل كود بأكمله في الذاكرة أبدًا. هذا ممكن لأن موضع كل تعليمة شيل كود فردية ينفذها الخيط يتوافق مع موضع نقطة توقف معينة داخل صفحة الذاكرة المخصصة. تقوم ShellGhost بحل هذا الموضع عن طريق حساب العنوان الظاهري النسبي (RVA) من RIP للخيط إلى العنوان الأساسي لصفحة الذاكرة المخصصة وإضافته إلى العنوان الأساسي للشيل كود المشفر / التعليمات المشفرة. عدد نقاط التوقف التي سيتم استبدالها ليس ثابتًا دائمًا، ولكنه يختلف اعتمادًا على عدد الرموز التشغيلية التي تحتاجها كل تعليمة ليتم إنشاؤها وتفسيرها بشكل صحيح (QUOTA). على سبيل المثال، التعليمة 'POP RBP' تساوي '5D'، مما يعني أنه سيتم استبدال نقطة توقف واحدة فقط. في المقابل، تتطلب التعليمة 'JMP RAX' الرموز التشغيلية 'FF E0'، لذلك سيتم استبدال نقطتي توقف. لهذا السبب أنشأت بنية البيانات C التالية.
typedef struct CRYPT_BYTES_QUOTA {
DWORD RVA; // الإزاحة إلى التعليمة المشفرة
DWORD quota; // عدد الرموز التشغيلية التي تولد التعليمة
} CRYPT_BYTES_QUOTA, * PCRYPT_BYTES_QUOTA;
لا يتم استبدال نقاط التوقف فورًا بنظيراتها من التعليمات. وذلك لأن التعليمات تحتاج إلى الخضوع لروتين فك التشفير قبل تنفيذها. هنا يأتي دور DWORD quota. تعتمد ShellGhost على 'SystemFunction032' الشائعة الآن لإجراء فك تشفير RC4. على عكس XOR، فإن RC4 ليس مخطط تشفير أحادي البايت. هذا يعني أنه لا يمكن تشفير الشيل كود وفك تشفيره دفعة واحدة. هذا أيضًا سبب آخر لمعالجة كل تعليمة على حدة. بعد استبدال نقاط التوقف، سيكون طول المخزن المؤقت الذي تحتاجه SystemFunction032 مساويًا لـ 'حصة التعليمة'، والتي تمثل مرة أخرى عدد الرموز التشغيلية التي تتكون منها التعليمة المحددة. على سبيل المثال، ضع في اعتبارك المقتطف التالي.
CRYPT_BYTES_QUOTA instruction[200];
instruction[5].quota = 2
USTRING buf = { 0 }; // سيحتوي على المخزن المؤقت المراد فك تشفيره وطوله
USTRING key = { 0 }; // سيحتوي على مفتاح RC4 وطوله
buf.Length = 2 // طول المخزن المؤقت، أو طول التعليمة المراد فك تشفيرها
نعلم أن تعليمة الشيل كود رقم 5 تتكون من رمزين تشغيليين، لذلك سيتم تمرير طول مخزن مؤقت يساوي 2 إلى SystemFunction032. هذا مهم لأن محاولة فك تشفير الشيل كود بأكمله باستدعاء واحد لـ SystemFunction032 سوف يفسده بالكامل.
يحتاج الشيل كود إلى التعيين باستخدام ShellGhost_mapping.py قبل التجميع. يستخرج البرنامج النصي كل تعليمة فردية ويعاملها كشيل كود صغير ومستقل. يتم تشفير التعليمات واحدة تلو الأخرى وطباعتها بتنسيق C جميعًا كـ unsigned char. يمكن تضمين النتيجة بشكل ثابت داخل كود C. أدناه مثال على شكل تعليمات شيل كود MSF المشفرة لـ calc.exe.
يحتوي هذا الشيل كود على 98 تعليمة، لذلك يتم تعريف 98 هيكل CRYPT_BYTES_QUOTA. عند تنفيذ الكود، يجب ملء هذه الهياكل بـ RVAs و QUOTAs الصحيحة للتعليمات. يوجه المعامل '-1' البرنامج النصي للتعيين لطباعة جزء الكود الذي يقوم بذلك.
عادةً ما تحتوي شيل كودات Metasploit x64 على معلمات سلسلة winapi مخزنة بين التعليمات. بمعنى آخر، شيل كود MSF x64 الذي يستدعي Winexec لا يدفع سلسلة من البايتات مع بايت فارغ في النهاية للحصول على سلسلة المعامل الأولى على المكدس. بدلاً من ذلك، فإن سجل RCX (المعامل الأول) هو مؤشر داخل الشيل كود نفسه تمامًا مثل الصورة التالية.
هذا يعني أن نقاط التوقف التي يرتبط موضعها بالسلسلة لن يتم حلها أبدًا، لأن RIP لن يلمس هذا الموضع أبدًا. في الواقع، هذا الكود يحل تعليمات الشيل كود الفعلية التي يمر بها RIP، وليس المعاملات التي لن يتم تنفيذها أبدًا مثل التعليمات. لإصلاح هذا، لاحظت أن شيل كودات MSF تخزن دائمًا مؤشرًا إلى winapi التي يستدعيونها داخل سجل RAX، ثم تقوم بعمل قفزة إلى السجل نفسه. لذلك عندما يكتشف ShellGhost VEH أن نقطة التوقف التي تم حلها هي 'JMP RAX' وكان سجل RCX يحتوي على مؤشر إلى موقع داخل الشيل كود، فإنه يحاول أيضًا حل ما يشير إليه RCX. بعد ذلك، لا يتم إعادة التنفيذ إلى الذاكرة المخصصة. بدلاً من ذلك، يتم نسخ RAX (عنوان winapi) إلى RIP واستئناف تنفيذ الخيط من winapi، وبالتالي تجاوز 'JMP RAX' والحفاظ على الذاكرة المخصصة RW. هذا ضروري للشيلات العكسية التي تستدعي WaitForSingleObject، والتي قد تتسبب في نوم الخيط بعد 'JMP RAX' مع ترك الذاكرة RX طالما ظل الشيل على قيد الحياة. يحتوي مقتطف الكود التالي على الشرطين اللذين يجب تحقيقهما لكي تقوم ShellGhost بضبط سجل RCX عندما يحتوي على سلسلة معامل winapi والسماح لشيل كود MSF بإصدار استدعاء الدالة بشكل صحيح (WinExec في المثال هنا).
<اقتطاع>
if (*(PWORD)exceptionData->ContextRecord->Rip == 0xe0ff) // إذا كان RIP هو 'JMP RAX'
<اقتطاع>
if ((contextRecord->Rcx >= (DWORD_PTR)allocation_base) && (contextRecord->Rcx <= ((DWORD_PTR)allocation_base + sizeof(sh)))) // إذا كان RCX داخل التخصيص
<اقتطاع>
لم يتم تغطية RDX و R8 و R9 (المعاملات الثاني والثالث والرابع) بعد.
ShellcodeFluctuation هو مفهوم تهرب في الذاكرة مشابه جدًا. مثله تمامًا، الذاكرة المخصصة هنا 'تتقلب' من RW إلى RX. في المقابل، تقدم ShellGhost التحسينات التالية:
ومع ذلك، فإن ShellGhost بعيدة كل البعد عن كونها تقنية مثالية. لا تزال تعاني من أكبر عيب في كل هذه التقنيات، وهو الحاجة إلى وجود ذاكرة قابلة للتنفيذ خاصة في مرحلة ما أثناء التنفيذ. التقنيات الأكثر تقدمًا مثل Foliage وجدت بالفعل طريقة للالتفاف حول هذا. بالإضافة إلى ذلك، يمكن اكتشاف تخصيص الذاكرة المليء بنقاط التوقف البرمجية بواسطة قاعدة YARA. تُظهر الصورة التالية Moneta تكتشف بشكل صحيح IOC لتخصيص RX PRV.
عندما يتعلق الأمر بالتهرب من حل EDR، فإن مسح الذاكرة هو مجرد جزء من صورة أكبر. الغياب التام لـ IOCs لا يعني بالضرورة أن ملفًا ثنائيًا يستخدم هذه التقنية سيكون فعالاً ضد EDR معين. على حد علمي، واجهت مواقف حيث لا يسمح لك الحل حتى بتشغيل الملف الثنائي بالطريقة التي تفعلها. الوجه الآخر للعملة هو أن IOCs ليست دائمًا مؤشرات دقيقة، وقد يتبين أن بعضها إيجابيات كاذبة. مع ذلك، هذه مجرد تقنية خام وإلهام أتمنى أن يقدّرها القارئ. يعلم عضو الفريق الأحمر أنه تمامًا مثل مكونات EDR، فإن التهرب في الذاكرة هو مجرد مكون واحد من المحرك.
يتطلب التجميع تعطيل الربط التدريجي. يحتوي مشروع VS هذا على جميع خيارات المترجم/الرابط مضبوطة بالفعل.