theflink/hunt-sleeping-beaconsماسح callstack يحدد مؤشرات الاختراق (IOCs) للعوامل C2 غير المعبأة أو المحقونة من خلال تحليل سلوك خمول الخيط، والذاكرة غير المدعومة، و stomping الوحدة، و APC، والمؤقتات، وتزييف عنوان الإرجاع.
هذا المشروع (في الغالب) هو ماسح لمكدس الاستدعاءات يحاول تحديد مؤشرات الاختراق (IOCs) التي تشير إلى وجود عميل C2 غير مُغلّف أو محقون.
تعتمد جميع الفحوصات على ملاحظة أن عملاء C2 ينتظرون بين استدعاءاتهم، مما يؤدي إلى خمول خيط الإشارة (beacon thread)، ويهدف هذا الأداة إلى تحليل ما قد تسبب في خمول الخيط.
يشمل ذلك مؤشرات الاختراق التقليدية، مثل الذاكرة غير المدعومة (unbacked memory) أو الوحدات المزورة (stomped modules)، ولكنها تحاول أيضًا اكتشاف عدة تطبيقات لأقنعة النوم (sleepmasks) باستخدام APCs أو المؤقتات. يتم ذلك عن طريق تحليل مكدس الاستدعاءات وكذلك تعداد المؤقتات واستدعاءاتها الدقيقة من وضع المستخدم.
(تقريبًا) لا يمكن اعتبار أي من مؤشرات الاختراق هذه إيجابية كاذبة بنسبة 100%، فاكتشاف تزوير الوحدة مثلًا عرضة للإيجابيات الكاذبة. ومع ذلك، قد تثير النتائج الشكوك حول سلوك عملية ما.
يتم تجاهل البرامج الثنائية الخاصة بـ DotNet و 32Bit.
قد تشير صفحة خاصة من نوع r(w)x في مكدس الاستدعاءات إلى إشارة (beacon) تم تفكيكها أو حقنها في وقت التشغيل.
تغير العديد من أقنعة النوم أذونات صفحة الإشارة إلى غير قابلة للتنفيذ. يؤدي ذلك إلى ظهور صفحة غير قابلة للتنفيذ مشبوهة في مكدس الاستدعاءات.
غالبًا، تتجنب الإشارات صفحات الذاكرة الخاصة عن طريق تحميل وحدة شرعية من القرص وكتابة بياناتها فوقها.
بفضل آلية النسخ عند الكتابة (copy on write)، يمكن تحديد الصور المعدلة عن طريق فحص الحقل VirtualAttributes.SharedOriginal من MEMORY_WORKING_SET_EX_INFORMATION. إذا كانت أي صفحة في مكدس الاستدعاءات ليست خاصة وكانت SharedOriginal == 0، فإنها تعتبر مؤشر اختراق.
ربما يكون هذا هو الاكتشاف الأكثر عرضة للإيجابيات الكاذبة. :'(
تقوم العديد من تطبيقات أقنعة النوم بإدراج سلسلة من استدعاءات APC إلى Ntdll!NtContinue، أحدها يؤدي إلى تنفيذ Ntdll!WaitForSingleObject. وبالتالي، إذا تم العثور على Ntdll!KiUserApcDispatcher في مكدس الاستدعاءات المؤدي إلى دالة حظر، يعتبر هذا الأداة مؤشر اختراق.
على غرار الاستخدام المشبوه لـ APCs، يتحقق هذا الأداة أيضًا من وجود ntdll!RtlpTpTimerCallback في مكدس الاستدعاءات المؤدي إلى دالة حظر لاكتشاف أقنعة النوم القائمة على المؤقتات.
على حد فهمي، تم بناء المؤقتات فوق مجموعات الخيوط (ThreadPools). كما أظهر Alon Leviev، يمكن تعدادها باستخدام NtQueryInformationWorkerFactory مع WorkerFactoryBasicInformation.
يحتوي الهيكل WORKER_FACTORY_BASIC_INFORMATION على FULL_TP_POOL الذي بدوره يشير إلى قائمة مرتبطة مزدوجة باسم TimerQueue. عند اجتياز هذه القائمة من PFULL_TP_TIMER، يمكن الوصول إلى كل استدعاء مسجل. إذا تم العثور على أي استدعاء يشير إلى مجموعة من استدعاءات API المشبوهة، مثل ntdll!ntcontinue، يمكن اعتباره مؤشر اختراق قويًا.
في الأصل، تم تقديم وكالة الوحدة كطريقة لتجاوز مكدسات الاستدعاءات المشبوهة. بينما ينجح التجاوز، فإنه يقدم مؤشر اختراق قويًا آخر، حيث يتم استخدام NTAPI لاستدعاء WINAPI. هذا أمر غريب، لأن WINAPI هو تجريد لـ NTAPI. وبالتالي، إذا لوحظ وجود مكدس استدعاءات به تسلسل ntdll.dll->kernel32.dll->ntdll.dll ينتهي باستدعاء دالة حظر، يمكن اعتباره مؤشر اختراق.
معظم تطبيقات تزوير عنوان العودة التي أعرفها تستخدم تقنية ترجع فيها الدالة المستدعاة إلى دالة صغيرة من نوع jmp [Nonvolatile-Register]. هذا المشروع ببساطة يكرر كل عناوين العودة في مكدسات الاستدعاءات ويبحث عن أنماط تشير إلى العودة إلى دالة صغيرة من نوع jmp.
_ _ _____ ______
| | | | / ___| | ___ \
| |_| | \ `--. | |_/ /
| _ | `--. \ | ___ \
| | | | /\__/ / | |_/ /
\_| |_/ \____/ \____/
Hunt-Sleeping-Beacons | @thefLinkk
-p / --pid {PID}
--dotnet | اضبط لتضمين عمليات DotNet أيضًا. (عرضة للإيجابيات الكاذبة)
--commandline | يتيح إخراج سطر الأوامر للعمليات المشبوهة
-h / --help | طباعة هذه الرسالة؟