نواجه يوميًا في JSOC CERT أحداثًا من صناديق رمل متعددة تعمل كجزء من حلول AntiAPT لعملائنا وتسمح لآلاف الملفات من حركة مرور الويب والبريد الإلكتروني بالمرور عبرها. تجدر الإشارة إلى أن أنظمة Sandbox الحديثة في تطويرها ذهبت أبعد من مجرد اعتراض استدعاءات النظام في Kernel Mode و API في User Mode. على نحو متزايد ، يستخدمون برنامج Hypervisor الخاص بهم ، وهو نظام لمحاكاة نشاط المستخدم ، والأدوات الديناميكية ، والتجزئة والتكتل عبر أقسام الكود ، وتحليل تغطية الكود ، وما إلى ذلك. تخلق مثل هذه المجموعة المتنوعة من التقنيات وهم أنه إذا لم يعمل أحد الملفات في صندوق الحماية ولم يظهر "وجهه الحقيقي" ، فمن المحتمل أن يكون هذا APT أو تقنية مبتكرة لاكتشاف بيئة افتراضية ، لا يعرفها مجتمع IB بعد. لكن ...
نظرًا لأننا لا نعرف الميزات الداخلية لعمل صناديق الرمل التجارية ، فإننا نقوم في بعض الحالات بفحص مزدوج - تحليل العينات التي نجحت في الاختبار يدويًا. في الآونة الأخيرة ، صادفنا عدة مرات أن بعض صناديق الرمل التجارية (لأسباب موضوعية لا يمكننا تحديد أي منها) لم تكتشف بعض الملفات الخبيثة أثناء التحليل الديناميكي ، وإذا كان المحلل الثابت ثابتًا صامتًا ، فقد تم تخطي الملف تمامًا.
تمكن المسح الضوئي للرمل من تجاوز عائلات البرمجيات الخبيثة المعروفة مثل Pony و Loki و Hawkeye. وحدهم شيء واحد فقط - تم تغطيتهم بواسطة باكر مكتوب في Visual Basic.
بالنظر إلى أن هذه العائلات HPE لم تكن جديدة منذ فترة طويلة ، فإن الحكم "الإيجابي" للرمل هو محبط للغاية. لذلك ، قررنا وصف المبدأ العام لتشغيل هذا الرازم والملاحظات التي أبداها علينا خلال بعض الوقت.
ينقسم المخطط العام لعمل باكر بشروط إلى 4 مراحل ويظهر في الرسم البياني أدناه.
تبدو نقطة إدخال ملف ضار نموذجي لتطبيقات Visual Basic:
لقد صادفنا العديد من الخيارات لهذه الحزمة ، وتغير رمز التفاف VB بشكل متكرر ، لكن المهمة التي تم تنفيذها ظلت كما هي: نقل التحكم إلى رمز المرحلة 1. في العينات السابقة ، تم نقل التحكم باستخدام وظائف API لفئة Enum * (على سبيل المثال ، EnumWindows ، EnumCalendarInfo ، وما إلى ذلك). هـ) تم الإشارة إلى عنوان المرحلة 1 من الكود كمعلمة. في الآونة الأخيرة ، نلاحظ أن السيطرة يتم نقلها مباشرة.
المرحلة 1
تتلقى الإدارة الكود المرحلة 1. هذه الشفرة غير مشفرة ، لكنها مبهمة. تختلف طرق التعتيم من عينة إلى أخرى ، لكن خوارزمية التشغيل العامة لا تتغير:
- دورة بها العديد من الإرشادات (بما في ذلك البيانات المهملة) التي تنشئ المفتاح الضروري لفك تشفير كود المرحلة 2. خصوصية هذا الجزء من الكود هو أنه لا توجد وظائف سكون ، ولكن بسبب كثرة التكرار ، يستغرق تنفيذه ما متوسطه 1-2 دقائق.
- فك التشفير (العادية XOR) ونقل السيطرة على رمز المرحلة 2.
توضح لقطة الشاشة أدناه أمثلة لطرق التعتيم المستخدمة:
2 المرحلة
تتمثل المهمة الرئيسية للشفرة في المرحلة 2 في التحقق من البيئة وتطبيق أساليب مكافحة التصحيح. يتم تشفير بعض أجزاء الكود (فك تشفيرها قبل التنفيذ ، وبعد ذلك ، يتم تشفيرها مرة أخرى باستخدام نفس خوارزمية XOR) لتجعل من الصعب اكتشافها عن طريق التوقيعات. بعد فك التشفير ، تكون السمات المميزة مرئية ، والتي يمكن من خلالها التعرف على كود المرحلة 2 عن طريق التحليل اليدوي.
قائمة الشيكات كبيرة جدًا وتختلف في إصدارات مختلفة من باكر ، لذلك سنقدم عدة طرق تم العثور عليها في جميع الإصدارات ، مع لقطات شاشة ، وفي النهاية سنقوم بإدراج القائمة بأكملها في الجدول.
1) GetTickCount + النوم
يتم أخذ الطابع الزمني الحالي ، ويسمى النوم لمدة ثانيتين ، وبعد ذلك يتم أخذ طابع زمني آخر على الفور.
بعد ذلك ، يتم تحديد الفرق بين العلامات (سواء مرت ثانيتان فعليًا).
2) SetErrorMode
يتحقق العملية الصحيحة لاستدعاء SetErrorMode API. يتم استدعاء الدالة مرتين على التوالي مع المعلمات 0x800 و 0x0 ، وبعد ذلك يتم التحقق من نتيجة المكالمة الثانية: يجب أن تكون مساوية 0x800.
3) SetLastError
أولاً ، يتم استدعاء SetLastError مع المعلمة 0x5 ، وبعد ذلك يتم التحقق من أنه تم تعيين قيمة رمز الخطأ الأخير في TEB بشكل صحيح (أي ، هو 0x5).
4) فحص حركة المؤشر
يدخل الكود حلقة لا نهاية لها تنتظر تحرك الماوس.
5) DbgBreakPoint و DbgUiRemoteBreakin
يتم تعديل هذه الوظائف لمنع مصحح الأخطاء من الاتصال بالعملية.
معدات
| تعليق
|
GetTickCount + النوم
| التحقق من الطوابع الزمنية
|
SetErrorMode
| التحقق من وظيفة تعمل بشكل صحيح
|
SetLastError
| التحقق من وظيفة تعمل بشكل صحيح
|
GetCursorPos
| تحقق حركة المؤشر
|
DbgBreakPoint
| تعديل وظيفة لمنع مرفق المصحح
|
DbgUiRemoteBreakin
| تعديل وظيفة لمنع مرفق المصحح
|
ربط الحذف
| تتم استعادة أول 5 بايت من الوظائف في ntdll.dll في حالة وجود السنانير
|
NtSetInformationThread
| المعلمة 0x11 (ThreadHideFromDebugger)
|
GetThreadContext + تحقق DR
| يتم فحص سجلات التصحيح DR0-DR3 ، DR6 ، DR7.
|
تحقق نقاط التوقف
| يتم فحص الإرشادات INT3 (0xCC) و int 3 (0xCD 0x03) و ud2 (0x0F 0x0B) في بداية بعض الوظائف
|
وحدة المعالجة المركزية (EAX = 0x0)
| يتم فحص سجلات EAX ، ECX ، EDX
|
وحدة المعالجة المركزية (EAX = 0x40000000)
| يتم فحص سجلات EAX ، ECX ، EDX
|
وحدة المعالجة المركزية (EAX = 0x1)
| فحص 31 ECX بت
|
PEB (BeingDebugged)
| يتحقق القيمة 0x1
|
PEB (NtGlobalFlag)
| القيمة المحددة 0x70
|
NtQueryInformationProcess
| تم استدعاؤه بواسطة الإشارات ProcessDebugPort (0x7) و ProcessDebugFlags (0x1F) و ProcessDebugObjectHandle (0x1E)
|
التحقق من اسم العملية
| يتم فحص سلاسل "العينة" و "صندوق الحماية" و "الفيروس" و "البرامج الضارة" و "الذات"
|
إذا تم الانتهاء من جميع تقنيات المرحلة 2 ، يتم فحص سطر الأوامر للتأكد من توافقها مع التنسيق الخاص. في حالة فشل الفحص ، يتم تنفيذ الإجراءات التالية:
1) تسمى وظيفة CreateProcess مع علامة CREATE_SUSPENDED لإعادة تشغيل العملية الحالية. في هذه الحالة ، يحتوي سطر الأوامر على التنسيق المطلوب.
2) باستخدام الدالتين GetContextThread و SetContextThread ، يتم تغيير نقطة الإدخال إلى واحدة جديدة ، والتي تقع في رمز المرحلة 1.
3) كرر الخطوتين 1 و 2 (بما في ذلك دورة طويلة وجميع الاختبارات). هذه المرة ، يكون التحقق من سطر الأوامر ناجحًا وتستمر العملية إلى الخطوة التالية.
3 المرحلة
في هذه المرحلة ، يتم فك تشفير جسم الفيروس الرئيسي ويتم تنفيذ تقنية Process Hollowing على العملية الحالية ، وبعد ذلك يتم نقل التحكم إلى نقطة دخول الفيروس الرئيسي.
الدرس المستفاد
لا يمكننا تحديد سبب هذا الرمل أو هذا بالضبط في هذه الحالة ، لكنني أعتقد أن إمكانية استخدام التقنيات الموضحة في المقالة بواسطة البرامج الضارة تم توفيرها من قبل البائعين لفترة طويلة ، والمشكلة تكمن فقط في التأخير الزمني الطويل في المرحلة الأولى من عمل باكر .
على الرغم من حقيقة أن صناديق الرمل الحديثة يتم وضعها في معظمها كجزء من أنظمة الحماية ضد هجمات APT ، تشير ملاحظاتنا إلى أنه حتى الأسر الخبيثة المعروفة جيدًا في المجتمع تخترق البنية التحتية بثبات يحسد عليه. نظرًا لعدم وجود ضمانات بأن العينة التي تجاوزت صندوق الحماية لن تحتوي على بعض تقنيات تجاوز الحماية من الفيروسات في ترسانتها ، لا يمكنك الاعتماد على هذه المجموعة من الحلول الوقائية. في مثل هذه الحالات ، يمكن أن تضمن عملية المراقبة المبنية بشكل صحيح ، بما في ذلك أحداث أمن المعلومات من المضيفين النهائيين ، الاستجابة في الوقت المناسب وتقليل الضرر المحتمل.