theflink/hunt-sleeping-beaconsकॉलस्टैक स्कैनर जो अनपैक्ड या इंजेक्ट किए गए C2 एजेंटों के IOCs की पहचान करता है, थ्रेड निष्क्रिय व्यवहार, असमर्थित मेमोरी, मॉड्यूल स्टॉम्पिंग, APCs, टाइमर और रिटर्न एड्रेस स्पूफिंग का विश्लेषण करके।
यह प्रोजेक्ट (अधिकतर) एक कॉलस्टैक स्कैनर है जो IOCs की पहचान करने का प्रयास करता है जो एक अनपैक या इंजेक्टेड C2 एजेंट का संकेत देते हैं।
सभी जाँचें इस अवलोकन पर आधारित हैं कि C2 एजेंट अपने कॉलबैक के बीच प्रतीक्षा करते हैं, जिससे बीकन थ्रेड निष्क्रिय हो जाता है और यह उपकरण यह विश्लेषण करने का लक्ष्य रखता है कि संभावित रूप से थ्रेड को निष्क्रिय करने का कारण क्या है।
इसमें पारंपरिक IOCs शामिल हैं, जैसे अनबैक्ड मेमोरी या स्टॉम्प्ड मॉड्यूल, लेकिन APCs या टाइमर का उपयोग करके स्लीपमास्क के कई कार्यान्वयन का पता लगाने का भी प्रयास करता है। यह दोनों किया जाता है: कॉलस्टैक का विश्लेषण करके लेकिन यूज़रलैंड से टाइमर और उनके सटीक कॉलबैक की गणना करके भी।
(लगभग) इनमें से कोई भी IOC 100% सही सकारात्मक नहीं माना जा सकता है, उदा., मॉड्यूल स्टॉम्पिंग डिटेक्शन झूठी सकारात्मकता के लिए बहुत प्रवण है। फिर भी, परिणाम किसी प्रक्रिया के व्यवहार के बारे में संदेह पैदा कर सकते हैं।
DotNet और 32Bit बाइनरी को अनदेखा किया जाता है।
कॉलस्टैक में एक निजी r(w)x पेज एक बीकन का संकेत दे सकता है जिसे रनटाइम पर अनपैक या इंजेक्ट किया गया था।
कई स्लीपमास्क बीकन के पेज की अनुमतियों को गैर-निष्पादनीय में बदल देते हैं। इससे कॉलस्टैक में एक संदिग्ध गैर-निष्पादनीय पेज दिखाई देता है।
अक्सर, बीकन निजी मेमोरी पेजों से बचने के लिए डिस्क से वैध मॉड्यूल लोड और ओवरराइट करते हैं।
कॉपी ऑन राइट तंत्र के लिए धन्यवाद, MEMORY_WORKING_SET_EX_INFORMATION के फ़ील्ड VirtualAttributes.SharedOriginal की जाँच करके हेरफेर किए गए इमेज की पहचान की जा सकती है। यदि कॉलस्टैक में कोई भी पेज निजी नहीं है और SharedOriginal == 0 है, तो इसे IOC माना जाता है।
यह संभवतः सबसे अधिक झूठी सकारात्मकता वाली डिटेक्शन है। :'(
स्लीपमास्क के कई कार्यान्वयन Ntdll!NtContinue पर APCs की एक श्रृंखला को कतारबद्ध करते हैं, जिनमें से एक Ntdll!WaitForSingleObject के निष्पादन को ट्रिगर करता है। इस प्रकार, यदि Ntdll!KiUserApcDispatcher ब्लॉकिंग फ़ंक्शन के कॉलस्टैक पर पाया जा सकता है, तो यह उपकरण इसे IOC मानता है।
APCs के संदिग्ध उपयोग के समान, यह उपकरण ब्लॉकिंग फ़ंक्शन के कॉलस्टैक पर टाइमर-आधारित स्लीपमास्क का पता लगाने के लिए ntdll!RtlpTpTimerCallback की भी जाँच करता है।
मेरी समझ के अनुसार, टाइमर थ्रेडपूल के ऊपर कार्यान्वित किए जाते हैं। जैसा कि Alon Leviev ने प्रदर्शित किया है, इन्हें NtQueryInformationWorkerFactory के साथ WorkerFactoryBasicInformation का उपयोग करके गिना जा सकता है।
WORKER_FACTORY_BASIC_INFORMATION संरचना एक FULL_TP_POOL एम्बेड करती है, जो बदले में एक TimerQueue डबल लिंक्ड लिस्ट से जुड़ती है। उस PFULL_TP_TIMER की सूची को ट्रैवर्स करने से प्रत्येक पंजीकृत कॉलबैक तक पहुँचा जा सकता है। यदि कोई कॉलबैक संदिग्ध API कॉल्स के एक सेट की ओर इशारा करता हुआ पाया जाता है, जैसे ntdll!ntcontinue, तो इसे एक मजबूत IOC माना जा सकता है।
मूल रूप से मॉड्यूल प्रॉक्सीिंग को संदिग्ध कॉलस्टैक को बायपास करने की एक विधि के रूप में पेश किया गया था। जबकि बायपास काम करता है, यह एक और मजबूत IOC प्रस्तुत करता है, क्योंकि WINAPI को कॉल करने के लिए NTAPI का उपयोग किया जाता है। यह अजीब है, क्योंकि WINAPI NTAPI के लिए एक एब्स्ट्रैक्शन है। इस प्रकार, यदि एक कॉलस्टैक देखा जाता है जिसमें ntdll.dll->kernel32.dll->ntdll.dll का क्रम ब्लॉकिंग फ़ंक्शन को कॉल करते हुए समाप्त होता है, तो इसे IOC माना जा सकता है।
अधिकांश रिटर्न एड्रेस स्पूफिंग कार्यान्वयन जिनसे मैं परिचित हूँ, एक तकनीक का उपयोग करते हैं जिसमें कॉल किया गया फ़ंक्शन एक jmp [Nonvolatile-Register] गैजेट पर लौटता है। यह प्रोजेक्ट बस कॉलस्टैक में प्रत्येक रिटर्न एड्रेस पर पुनरावृत्त करता है और एक jmp गैजेट पर लौटने का संकेत देने वाले पैटर्न की खोज करता है।
_ _ _____ ______
| | | | / ___| | ___ \
| |_| | \ `--. | |_/ /
| _ | `--. \ | ___ \
| | | | /\__/ / | |_/ /
\_| |_/ \____/ \____/
Hunt-Sleeping-Beacons | @thefLinkk
-p / --pid {PID}
--dotnet | डॉटनेट प्रक्रियाओं को भी शामिल करने के लिए सेट करें। (झूठी सकारात्मकता के लिए प्रवण)
--commandline | संदिग्ध प्रक्रियाओं के लिए cmdline आउटपुट सक्षम करता है
-h / --help | यह संदेश प्रिंट करता है?