octoberfest7/beatrevमैलवेयर विश्लेषकों को निराश/हराने के लिए POC
नीचे दिया गया कार्य एक POC (प्रूफ ऑफ कॉन्सेप्ट) है जो मैलवेयर को किसी विशेष पीड़ित के लिए स्वयं को "की" करने में सक्षम बनाता है, ताकि मैलवेयर विश्लेषकों के प्रयासों को विफल किया जा सके।
मैं इस परियोजना में निहित किसी भी विचार या कोड के दुर्भावनापूर्ण उपयोग के लिए कोई जिम्मेदारी नहीं लेता हूँ। मैं यह शोध इन्फोसेक पेशेवरों को और शिक्षित करने तथा मैलवेयर विश्लेषकों, रिवर्स इंजीनियर्स और ब्लू टीमर्स के लिए अतिरिक्त प्रशिक्षण/विचारणीय विषय प्रदान करने के लिए प्रस्तुत कर रहा हूँ।
पहली बार जब मैलवेयर किसी पीड़ित पर चलता है, तो यह उस पीड़ित के पर्यावरणीय डेटा का उपयोग करके वास्तविक पेलोड (एक RDLL) को AES एन्क्रिप्ट करता है। हर बार जब मैलवेयर बाद में चलाया जाता है, तो यह वही पर्यावरणीय जानकारी एकत्र करता है, मैलवेयर के भीतर बाइट ऐरे के रूप में संग्रहीत पेलोड को AES डिक्रिप्ट करता है, और उसे चलाता है। यदि डिक्रिप्शन विफल हो जाता है/पेलोड चलने में विफल हो जाता है, तो मैलवेयर स्वयं को डिलीट कर देता है। रिवर्स इंजीनियर्स और मैलवेयर विश्लेषकों से सुरक्षा।
मुझे लगा कि यह परियोजना पूरी नहीं हुई है, इसलिए मैं वापस गया और काफी बड़ा पुनर्लेखन किया। मूल शोध और ट्रेडक्राफ्ट यहाँ पाया जा सकता है।
प्रमुख परिवर्तन इस प्रकार हैं:
इस परियोजना के स्रोत कोड से कई अलग-अलग चीजें ली जा सकती हैं जिनका उपयोग कहीं और किया जा सकता है। उम्मीद है कि यह किसी के लिए उपयोगी होगा।
BeatRev की मूल रिलीज़ में कुछ कमियाँ थीं जिन्हें मैंने हल करने का निर्णय लिया।
Stage2 पहले एक स्वतंत्र निष्पादन योग्य था जिसे Stage1 के वैकल्पिक डेटा स्ट्रीम (ADS) के रूप में संग्रहीत किया जाता था। पीड़ित-द्वारा AES एन्क्रिप्शन और उसके बाद डिक्रिप्शन और निष्पादन प्राप्त करने के लिए, हर बार Stage1 चलने पर यह ADS को पढ़ता, डिक्रिप्ट करता, ADS पर वापस लिखता, CreateProcess को कॉल करता, और फिर Stage2 को पुनः एन्क्रिप्ट करके ADS में डिस्क पर वापस लिखता। यह बहुत सारे I/O ऑपरेशन थे और निश्चित रूप से CreateProcess कॉल भी अच्छा नहीं था।
मैं संयोग से Steven Fewer के Reflective DLL पर शोध के पार आया और यह एक अच्छा फिट लगा। Stage2 अब एक RDLL है; हमारा मैलवेयर/शेलकोड रनर/जो कुछ भी हम सुरक्षित रखना चाहते हैं उसे RDLL प्रारूप में पोर्ट किया जा सकता है और Stage1 के भीतर एक बाइट ऐरे के रूप में संग्रहीत किया जा सकता है जो रनटाइम पर डिक्रिप्ट होता है और Stage1 द्वारा निष्पादित किया जाता है। यह संस्करण 1 से सभी I/O ऑपरेशन और CreateProcess कॉल को हटा देता है और एक स्वागत योग्य परिवर्तन है।
Stage1 में किसी भी प्रकार के वास्तविक AV एवेज़न उपाय प्रोग्राम नहीं किए गए थे; यह जानबूझकर किया गया था, क्योंकि यह अतिरिक्त काम है और वास्तव में इस शोध का उद्देश्य नहीं था। पुनर्लेखन के दौरान मैंने इसे एक अतिरिक्त चुनौती के रूप में लिया और Stage1 के इम्पोर्ट एड्रेस टेबल से फ़ंक्शन हटाने के लिए API-हैशिंग जोड़ी। इससे डिटेक्शन में मदद मिली है और VirusTotal पर Stage1 की डिटेक्शन दर 4/66 है। मैं Stage1 को अपलोड करने में सहज था क्योंकि यह पहले से ही उस मूल मशीन से keyed है जिस पर इसे चलाया गया था और होने वाले AES एन्क्रिप्शन के कारण फ़ाइल सिग्नेचर लगातार बदलता रहता है।
मैंने हाल ही में मैलवेयर का पता लगाने के साधन के रूप में एन्ट्रॉपी पर ध्यान देना शुरू किया; एक विशाल AES एन्क्रिप्टेड बाइनरी ब्लॉब के कारण अन्यथा बहुत अधिक एन्ट्रॉपी को कम करने के प्रयास के लिए मैंने UUID के रूप में संग्रहीत शेलकोड को एकीकृत करने पर विचार किया। चूंकि बाइनरी स्ट्रिंग प्रतिनिधित्व में संग्रहीत है, निष्पादन योग्य में समग्र एन्ट्रॉपी कम होती है। इस तकनीक का उपयोग करके Stage0 की एन्ट्रॉपी अब ~6.8 और Stage1 की ~4.5 (अधिकतम पैमाने 8 पर) है।
अंत में, उन सभी टुकड़ों को एकीकृत करना और एक पूर्ण Stage0 तैयार करना एक बहुत बड़ा काम है जिनमें हेरफेर किया जाना चाहिए। इसे आसान बनाने के लिए मैंने एक बिल्डर एप्लिकेशन बनाया है जो एक Stage0.c टेम्पलेट फ़ाइल, एक Stage1 स्टब, एक Stage2 स्टब और एक रॉ शेलकोड फ़ाइल (यह Stage2 के लिए CobaltStrike शेलकोड वाले शेलकोड रनर के आसपास बनाया गया था) को इन्जेस्ट करेगा और लक्ष्य पर उपयोग के लिए एक संकलित Stage0 पेलोड तैयार करेगा।
Stephen Fewer का Reflective DLL कोड कुछ Visual Studio कंपाइलर-विशिष्ट निर्देश शामिल करता है; मुझे यकीन है कि तकनीक को MingW पर पोर्ट करना संभव है लेकिन मेरे पास ऐसा करने का कौशल नहीं है। यहाँ मुख्य समस्या यह है कि CobaltStrike शेलकोड (स्टेजलेस ~265K है) को RDLL के अंदर जाना चाहिए और संकलित होना चाहिए। इससे निपटने और इसे बाकी प्रक्रिया के साथ अच्छी तरह से एकीकृत करने के लिए मैंने अपना Stage2 RDLL लिखा ताकि इसमें CS शेलकोड के आकार की मेमोरी का एक ग्लोबल वेरिएबल चंक हो; मेमोरी के इस ~265K चंक में एक छोटा प्लेसहोल्डर है जिसे संकलित बाइनरी में स्थित किया जा सकता है। src/Stage2 में कोड में यह पहले से ही जोड़ा गया है।
एक बार संकलित होने के बाद, इस Stage2stub को kali में स्थानांतरित किया जाता है जहाँ वास्तविक CS शेलकोड को उस स्थान पर चिपकाने के लिए एक बाइनरी पैच किया जा सकता है जहाँ यह संबंधित है। यह पूर्ण Stage2 तैयार करता है।
पहले वर्णित I/O और CreateProcess फियास्को से बचने के लिए, पूर्ण Stage2 को Stage0 द्वारा संकलित Stage1 में भी पैच किया जाना चाहिए; यह Stage2 को एक बार लक्ष्य पर एन्क्रिप्ट करने की अनुमति देने के अलावा Stage2 को डिस्क पर अलग से संग्रहीत होने से रोकने के लिए आवश्यक है। प्रत्येक स्टब के भीतर प्लेसहोल्डर का पता लगाने के लिए memmem फ़ंक्शन का उपयोग किया जाता है; यह फ़ंक्शन विंडोज़ पर उपलब्ध नहीं है, इसलिए एक कस्टम कार्यान्वयन का उपयोग किया गया था। Foxik384 उनके कोड के लिए धन्यवाद।
बाइनरी पैच करने के लिए, हमें आवश्यक मेमोरी पहले से आवंटित करनी होगी; इसका एक संयुक्त प्रभाव होता है, क्योंकि Stage1 को अब Stage2 को भी शामिल करने के लिए पर्याप्त बड़ा होना चाहिए। Stage2 को UUID स्ट्रिंग में बदलने के अतिरिक्त चरण के साथ, Stage2 आकार में बढ़ जाता है और इसे धारण करने के लिए Stage1 भी बढ़ जाता है। ~290K के संकलित आकार वाला एक Stage2 RDLL ~1.38M के Stage0 पेलोड और ~700K के Stage1 पेलोड में परिणत होता है।
बिल्डर एप्लिकेशन केवल x64 EXE बनाने का समर्थन करता है। हालांकि थोड़ा और काम करके आप सिद्धांत रूप में Stage0 को DLL बना सकते हैं, साथ ही Stage1 को भी, और पूरे जीवनचक्र को एक स्वतंत्र निष्पादन योग्य के बजाय DLL हाइजैक के रूप में मौजूद कर सकते हैं।
ये निर्देश आपको इस POC का उपयोग करने के लिए मार्गदर्शन करेंगे।
लगभग 6 महीने पहले मुझे यह अहसास हुआ कि जबकि मैंने AV/EDR एवेज़न के संबंध में मैलवेयर के साथ बहुत कुछ सीखा और किया था, मैंने रिवर्स इंजीनियरिंग/मैलवेयर विश्लेषण को चकमा देने या हराने की कोशिश करने के बारे में बहुत कम समय बिताया था। इसके कुछ अच्छे कारण थे:
फिर भी यह एक दिलचस्प विचार प्रयोग था और मेरे कुछ सहयोगी थे जो मैलवेयर विश्लेषण के बारे में जानते हैं जिनके साथ मैं विचारों का आदान-प्रदान कर सकता था। यह AV/EDR एवेज़न की तुलना में एक पूरी तरह से अलग परिमाण की चुनौती लग रही थी और मैंने इसे आजमाने का फैसला किया।
मेरा प्रारंभिक आधार यह था कि मैलवेयर, पहली बार चलाए जाने पर, किसी तरह उस पीड़ित मशीन के लिए स्वयं को "की" करेगा; इसे चलाने के किसी भी बाद के प्रयास में लक्ष्य वातावरण में किसी चीज़ का मूल्यांकन किया जाएगा और मैलवेयर में मौजूद मिलान के लिए इसकी तुलना की जाएगी। यदि ये दो कारक मेल खाते हैं, तो यह अपेक्षित रूप से निष्पादित होता है। यदि वे मेल नहीं खाते (जैसा कि उस स्थिति में जहाँ नमूना किसी मैलवेयर विश्लेषक के सैंडबॉक्स में स्थानांतरित कर दिया गया है), तो मैलवेयर स्वयं को डिलीट कर देता है (एक बार फिर LloydLabs और उनके delete-self-poc के काम पर भारी रूप से निर्भर करते हुए)।
यह "की" पीड़ित कंप्यूटर के लिए कुछ "अद्वितीय" होना चाहिए। आदर्श रूप से यह जानकारी के कई टुकड़ों का संयोजन होगा, और फिर आगे अस्पष्ट किया जाएगा। उदाहरण के तौर पर, हम कंप्यूटर के होस्टनाम के साथ-साथ स्थापित RAM की मात्रा एकत्र कर सकते हैं; इन दो मानों को फिर जोड़ा जा सकता है (जैसे Client018192MB) और फिर एक उपयोग-परिभाषित फ़ंक्शन का उपयोग करके हैश करके एक संख्या (जैसे 5343823956) उत्पन्न की जा सकती है।
जानकारी एकत्र करने में बहुत सारे विकल्प हैं, लेकिन इस बात पर विचार किया जाना चाहिए कि ब्लू टीमर किन मानों को आसानी से स्पूफ कर सकता है; उदाहरण के लिए एक MAC पता पीड़ित के लिए एक आकर्षक "अद्वितीय" पहचानकर्ता लग सकता है, हालांकि MAC पतों को आसानी से मैन्युअल रूप से सेट किया जा सकता है ताकि एक रिवर्स इंजीनियर अपने सैंडबॉक्स को मूल पीड़ित से मिला सके। आदर्श रूप से चुने गए और गणना किए गए मान वे होंगे जिन्हें रिवर्स इंजीनियर के लिए अपने वातावरण में दोहराना मुश्किल हो।
स्व-विलोपन जादू के साथ, मैलवेयर स्वयं को एक बफर में पढ़ सकता है, एक प्लेसहोल्डर वेरिएबल का पता लगा सकता है और इसे इस संख्या से बदल सकता है, स्वयं को डिलीट कर सकता है, और फिर संशोधित मैलवेयर को उसी स्थान पर डिस्क पर वापस लिख सकता है। Main में if/else स्टेटमेंट के साथ संयुक्त, अगली बार जब मैलवेयर चलेगा तो यह पता लगाएगा कि इसे पहले चलाया जा चुका है और फिर हैशेड संख्या उत्पन्न करने के लिए फिर से होस्टनाम और RAM की मात्रा एकत्र करेगा। इसका मूल्यांकन पहले रन के दौरान मैलवेयर में संग्रहीत संख्या (5343823956) के विरुद्ध किया जाएगा। यदि यह मेल खाता है (जैसा कि उस स्थिति में जहाँ मैलवेयर उसी मशीन पर चल रहा है जैसा कि उसने मूल रूप से किया था), तो यह अपेक्षित रूप से निष्पादित होता है, हालांकि यदि कोई भिन्न मान वापस आता है तो यह मैलवेयर विश्लेषक से लेखक की रक्षा के लिए स्वयं को डिस्क से हटाने के लिए फिर से स्व-विलोपन फ़ंक्शन को कॉल करेगा।
यह सिद्धांत में एक अच्छा विचार था जब तक कि मैंने एक सहयोगी से बात नहीं की जिसके पास वास्तविक मैलवेयर विश्लेषण और रिवर्स इंजीनियरिंग का अनुभव है। मुझे बताया गया कि एक रिवर्स इंजीनियर मैलवेयर में सशर्त स्टेटमेंट (यदि ValueFromFirstRun != GetHostnameAndRAM()) का निरीक्षण करने में सक्षम होगा, और यह देखते हुए कि अपेक्षित मान सशर्त स्टेटमेंट के एक तरफ हार्ड-कोडेड है, केवल अपेक्षित मान शामिल करने के लिए रजिस्टरों को संशोधित कर सकता है, जिससे संपूर्ण सुरक्षा तंत्र पूरी तरह से बायपास हो जाता है।
इस नए ज्ञान ने विचार प्रयोग को पूरी तरह से पटरी से उतार दिया और यह देखते हुए कि मेरे पास वैसे भी पहले स्थान पर इस तरह की क्षमता का उपयोग करने का कोई कारण नहीं था, यह वह जगह है जहाँ परियोजना ~6 महीने के लिए रुक गई।
यह परियोजना बीच के 6 महीनों में कुछ बार फिर से उभरी, लेकिन हर बार एक क्षणभंगुर विचार से अधिक कुछ नहीं थी, क्योंकि मैंने रिवर्सिंग/मैलवेयर विश्लेषण का कोई नया ज्ञान प्राप्त नहीं किया था और फिर से ऐसी क्षमता की कोई आवश्यकता नहीं थी। कुछ दिन पहले यह विचार फिर से उठा और जबकि इनमें से कोई भी कारक वास्तव में नहीं बदला है, मुझे लगता है कि मेरे पास थोड़ा और ज्ञान था और इस बार इस विचार को जाने नहीं दे सका।
मानों को हार्ड-कोडिंग से संबंधित पूर्वोक्त समस्या को ध्यान में रखते हुए, मैंने अंततः एक बहु-चरणीय डिज़ाइन के लिए जाने का निर्णय लिया। मैं उन्हें Stage0, Stage1 और Stage2 के रूप में संदर्भित करूंगा।
Stage0: सेटअप। प्रारंभिक संक्रमण पर चलाया जाता है और बाद में हटा दिया जाता है
Stage1: रनर। मैलवेयर के प्रत्येक बाद के निष्पादन पर चलाया जाता है
Stage2: पेलोड। वह मैलवेयर जिसकी सुरक्षा के बारे में आप परवाह करते हैं। एक प्रक्रिया बनाता है और बीकन लौटाने के लिए शेलकोड इंजेक्ट करता है।
Stage0 ताज़ा निष्पादन योग्य है जिसे हमलावर द्वारा लक्ष्य तक पहुँचाया जाता है। इसमें Stage1 और Stage2 AES एन्क्रिप्टेड बाइट ऐरे के रूप में होते हैं; यह पारगमन में मैलवेयर की सुरक्षा के लिए किया जाता है, या यदि किसी रक्षक को किसी तरह Stage0 की एक प्रति मिल जाती है (जो नहीं होना चाहिए)। AES कुंजी और IV Stage0 के भीतर निहित हैं, इसलिए वास्तव में यह किसी सक्षम ब्लू टीमर से Stage1 या Stage2 की रक्षा नहीं करेगा।
Stage0 निम्नलिखित कार्य करता है:
घटनाओं के इस क्रम के समापन पर, Stage0 बाहर निकल जाता है। क्योंकि इसे चरण 2 में डिस्क से हटा दिया गया था और यह अब मेमोरी में नहीं चल रहा है, Stage0 प्रभावी रूप से चला गया है; इस तकनीक के पूर्व ज्ञान के बिना, शेष मैलवेयर जीवनचक्र पहले से कहीं अधिक भ्रमित करने वाला होगा।
चरण 4 में प्रोसेसर का नाम और Microsoft ProductID एकत्र किए जाते हैं; ProductID रजिस्ट्री से प्राप्त किया जाता है, और इस मान को मैन्युअल रूप से संशोधित किया जा सकता है जो ब्लू टीमर के लिए अपने सैंडबॉक्स को लक्ष्य वातावरण से मिलाने का एक आसान अवसर प्रस्तुत करता है। किस पर्यावरणीय जानकारी को एकत्र किया जाता है, इसके आधार पर यह आसान या अधिक कठिन हो सकता है।
Stage1 को Stage0 द्वारा ड्रॉप किया गया था और उसी सटीक स्थान पर मौजूद है जहाँ Stage0 था (नाम सहित)। Stage2 Stage1 के ADS के रूप में संग्रहीत है। जब हमलावर/परसिस्टेंस बाद में मैलवेयर को निष्पादित करता है, तो वे Stage1 को निष्पादित कर रहे होते हैं।
Stage1 निम्नलिखित कार्य करता है:
ध्यान दें कि Stage2 को ओवरराइट करने में सक्षम होने के लिए बाहर निकलना होगा; स्व-विलोपन ट्रिक उन फ़ाइलों पर काम नहीं करती है जो पहले से ADS हैं, क्योंकि स्व-विलोपन तकनीक निष्पादन योग्य की प्राथमिक डेटा स्ट्रीम का नाम बदलने पर निर्भर करती है। Stage2 आदर्श रूप से एक इंजेक्ट या स्पॉन+इंजेक्ट निष्पादन योग्य होगा।
दो बिंदु हैं जहाँ Stage1 पता लगा सकता है कि इसे उसी पीड़ित से नहीं चलाया जा रहा है और खतरे के अभिनेता की रक्षा के लिए स्वयं/Stage2 को हटा सकता है। पहला एकत्रित पर्यावरणीय जानकारी का उपयोग करके Stage2 को डिक्रिप्ट करने के बाद निष्पादन योग्य हेडर की जाँच है; सिद्धांत रूप में इस चरण को एक रिवर्स इंजीनियर द्वारा बायपास किया जा सकता है, लेकिन यह एक पहली अच्छी जाँच है। दूसरा सुरक्षा बिंदु CreateProcess कॉल का परिणाम है- यदि यह Stage2 के ठीक से डिक्रिप्ट नहीं होने के कारण विफल होता है, तो मैलवेयर को समान रूप से हटा दिया जाता है। इस कॉल के परिणाम को रिवर्स इंजीनियर द्वारा विलोपन को रोकने के लिए भी संशोधित किया जा सकता है, हालांकि यह इस तथ्य को नहीं बदलता है कि Stage2 एन्क्रिप्टेड और दुर्गम है।
Stage2 मैलवेयर श्रृंखला का मुख्य भाग है; यह स्वयं एक पूर्ण विकसित शेलकोड रनर/मैलवेयर का टुकड़ा है। इसे जिस तरह से हमने एन्क्रिप्ट और संरक्षित किया है, उससे अंतिम-अवस्था मैलवेयर की क्रियाएं रिवर्स इंजीनियर्स और मैलवेयर विश्लेषकों से बहुत बेहतर ढंग से अस्पष्ट और संरक्षित होती हैं। विकास के दौरान मैंने CobaltStrike शेलकोड वाले अपने मौजूदा शेलकोड रनर में से एक का उपयोग किया, लेकिन यह कुछ भी हो सकता है जिसे हमलावर चलाना और सुरक्षित रखना चाहता है।
तो इस तरह के मैलवेयर जीवनचक्र के साथ वास्तव में क्या हासिल होता है? कुछ दिलचस्प विचित्रताएँ हैं जिनके बारे में बात की जा सकती है।
वैकल्पिक डेटा स्ट्रीम NTFS फ़ाइल सिस्टम के लिए अद्वितीय एक सुविधा है; इसका मतलब है कि प्रारंभिक संक्रमण के बाद मैलवेयर स्थानांतरित करने के अधिकांश तरीके Stage2 को हटा देंगे और खो देंगे क्योंकि यह Stage1 का एक ADS है। नमूने को स्थानांतरित करने के लिए Stage2 को संरक्षित करने के लिए विशेष देखभाल करनी होगी, क्योंकि इसके बिना बहुत सारे रिवर्स इंजीनियर और मैलवेयर विश्लेषक यह समझने में बहुत भ्रमित होंगे कि क्या हो रहा है। RAR आर्काइव ADS को संरक्षित करने में सक्षम हैं और 7Z और Peazip जैसे उपकरण फ़ाइलों और उनके ADS को निकाल सकते हैं।
जैसा कि पहले उल्लेख किया गया है, जब तक इस जीवनचक्र का उपयोग करने वाला मैलवेयर ब्लू टीमर तक पहुँचता है, तब तक यह Stage1 पर होना चाहिए; Stage0 आया और चला गया है, और Stage2 पहले से ही Stage0 द्वारा एकत्रित पर्यावरणीय जानकारी के साथ एन्क्रिप्ट किया गया है। Stage0 के अस्तित्व के बारे में न जानना जीवनचक्र को समझने और Stage2 को डिक्रिप्ट करने में काफी अनिश्चितता जोड़ देगा।
सिद्धांत में (क्योंकि फिर से मेरे पास कोई रिवर्सिंग अनुभव नहीं है), Stage1 को उलटा जाने में सक्षम होना चाहिए (ब्लू टीमर्स द्वारा इसकी कुछ प्रतियों को रोल करने के बाद क्योंकि यह स्वयं को हटाता रहता है) और Stage1 लक्ष्य प्रणाली से जो जानकारी एकत्र करता है, उसकी पहचान करने में सक्षम होना चाहिए। एक अच्छी तरह से समन्वित प्रतिक्रिया प्रदान करने पर, ब्लू टीम को उस पीड़ित की पहचान करने में सक्षम होना चाहिए जहाँ से मैलवेयर आया है और उससे वह जानकारी एकत्र करके प्रोग्राम में फीड करने में सक्षम होना चाहिए ताकि इसे उचित रूप से AES कुंजी/IV में बदला जा सके जो Stage2 को डिक्रिप्ट करता है। हालांकि इसमें बहुत सारे "ifs" हैं जो रिवर्स इंजीनियर के सापेक्ष कौशल के साथ-साथ पीड़ित मशीन के उस जानकारी को पुनर्प्राप्त करने के लिए उपलब्ध होने से संबंधित हैं।
एप्लिकेशन व्हाइटलिस्टिंग इस जीवनचक्र को काफी हद तक विफल कर देगी। Stage0/Stage1 को DLL के रूप में साइड लोड किया जा सकता है, हालांकि मुझे संदेह है कि ADS के रूप में Stage2 कुछ समस्याएं प्रस्तुत करेगा। मेरे पास AWL के विरुद्ध मैलवेयर का परीक्षण करने के लिए वातावरण नहीं है और न ही मैंने इसे DLL प्रारूप में पोर्ट करने की जहमत उठाई है, इसलिए मैं कुछ नहीं कह सकता। मुझे यकीन है कि इन मुद्दों के आसपास रचनात्मक तरीके हैं।
मुझे यह भी काफी विश्वास है कि Stage2 को चलाने के डिस्क पर ड्रॉप करने और CreateProcess कॉल करने से बेहतर तरीके हैं; या तो निष्पादन योग्य को मैन्युअल रूप से मैप करना या इसे शेलकोड में बदलने के लिए Donut जैसे टूल का उपयोग करना उचित विचार प्रतीत होते हैं।
विकास के दौरान मैंने एक बिल्डर एप्लिकेशन बनाया जिसमें Stage1 और Stage2 को एक कार्यात्मक Stage0 तैयार करने के लिए फीड किया जा सकता है; हालांकि यह प्रदान नहीं किया जाएगा, लेकिन मैं Stage1 के लिए अधिकांश स्रोत कोड प्रदान करूंगा क्योंकि यह वह टुकड़ा है जो ब्लू टीमर को सबसे अधिक दिखाई देगा। Stage0 को पाठक के लिए एक अभ्यास के रूप में बाहर रखा जाएगा, और Stage2 जो भी स्वतंत्र निष्पादन योग्य आप चलाना+सुरक्षित रखना चाहते हैं। इस POC पर सक्षम पाठकों के प्रयास और विवेक पर आगे शोध किया जा सकता है।मैं इस मैलवेयर की एक संकलित प्रति Dropper64.exe के रूप में प्रदान करूँगा। Dropper64.exe को x64 के लिए संकलित किया गया है। Dropper64.exe Stage0 है; इसमें Stage1 और Stage2 शामिल हैं। निष्पादन पर, Stage1 और Stage2 डिस्क पर गिरेंगे लेकिन स्वचालित रूप से निष्पादित नहीं होंगे, आपको Dropper64.exe (अब Stage1) को फिर से चलाना होगा। Stage2 calc.exe का x64 संस्करण है। मैं इसे किसी भी ब्लू टीमर के लिए शामिल कर रहा हूँ जो इसे देखना चाहता है, लेकिन ध्यान रखें कि घटना प्रतिक्रिया परिदृश्य में 99% समय आपको Stage1/Stage2 मिलेगा, Stage0 चला जाएगा।
यह एक दिलचस्प निजी प्रोजेक्ट था जिसने एक लंबा सप्ताहांत खा लिया। मुझे यकीन है कि यह और अधिक उन्नत/अधिक पूर्ण होता अगर मुझे डीबगर और डिस्सेम्बलर में अनुभव होता, लेकिन आप जो कुछ भी है उसके साथ सर्वश्रेष्ठ करते हैं। मैं ब्लू टीमर्स और अन्य मैलवेयर डेवलपर्स से यह सुनने के लिए उत्सुक हूँ कि वे क्या सोचते हैं। मुझे यकीन है कि वास्तविक APTs जो कर रहे हैं, उसे देखते हुए मैंने यहाँ पहिए का अत्यधिक जटिल पुनर्निमाण किया है, लेकिन मैंने रास्ते में कुछ चीजें सीखीं। पढ़ने के लिए धन्यवाद!
