DropSpawn का सार्वजनिक रिलीज़ गैर-सार्वजनिक संस्करण से थोड़ा भिन्न है। गैर-सार्वजनिक रिलीज़ एक स्वामित्व पेलोड जनरेटर का लाभ उठाता है, जिससे ऑपरेटर के लिए अनुभव अधिक सहज हो जाता है। सार्वजनिक रिलीज़ को इस तथ्य को ध्यान में रखते हुए थोड़ा संशोधित किया गया है कि उपयोगकर्ताओं के पास DLL हाईजैक संगत पेलोड उत्पन्न करने के अपने तरीके होंगे। उपयोगकर्ताओं को dropspawn को एकीकृत और हथियारबद्ध करने में सहायता करने के लिए एक Python3 स्क्रिप्ट के साथ-साथ एक प्रदर्शन DLL के लिए स्रोत कोड शामिल किया गया है।

उपयोग कैसे करें

1.

कुछ लक्षित निष्पादन योग्य फ़ाइलों की पहचान करें जो अपने पूर्ण पथ निर्दिष्ट किए बिना DLL लोड करने का प्रयास करती हैं। आप exe को उपयोगकर्ता-लेखन योग्य निर्देशिका में कॉपी करके और Procmon के साथ निगरानी करते हुए निष्पादित करके ऐसा कर सकते हैं। इस उदाहरण में हम WerFault.exe का उपयोग करेंगे जो सामान्यतः C:\Windows\System32\WerFault.exe पर स्थित होता है

उपरोक्त उदाहरण में cryptsp.dll, wer.dll, dbghelp.dll, और bcrypt.dll सभी व्यवहार्य उम्मीदवार हैं क्योंकि उनके पूर्ण पथ WerFault के भीतर निर्दिष्ट नहीं थे; परिणामस्वरूप, WerFault DLL खोज क्रम के बाकी हिस्सों का सहारा लेने से पहले उन्हें अपनी एप्लिकेशन निर्देशिका से लोड करने का प्रयास करेगा। ध्यान दें कि यह आमतौर पर चिंता का विषय नहीं है क्योंकि WerFault की एप्लिकेशन निर्देशिका System32 ही है।

2.

लक्षित सिस्टम से हाईजैक करने योग्य DLL में से एक डाउनलोड करें।

यह आवश्यक है ताकि हम इसके एक्सपोर्ट निकाल सकें और उन्हें अपने पेलोड DLL में शामिल कर सकें। हाईजैक करने योग्य DLL को उसी मशीन से प्राप्त करना महत्वपूर्ण है जिस पर आप DropSpawn का उपयोग करना चाहते हैं, क्योंकि DLL Windows संस्करणों के बीच बदलते हैं। इसके अतिरिक्त, यदि आप x86 beacon चला रहे हैं और DropSpawn का उपयोग करके x64 beacon स्पॉन करना चाहते हैं, तो सुनिश्चित करें कि आप 'C:\windows\system32...' के बजाय 'C:\windows\sysnative...' निर्दिष्ट करके वास्तविक DLL का x64 संस्करण डाउनलोड करें।

3.

generate_dll.py चलाएं, डाउनलोड किए गए DLL और वांछित पेलोड आर्किटेक्चर को पास करते हुए। Generate_dll.py इस स्क्रिप्ट का संशोधित संस्करण है। यह आपूर्ति किए गए DLL को पार्स करेगा, DLL के एक्सपोर्ट युक्त एक .def फ़ाइल बनाएगा, और हमारे प्रदर्शन पेलोड DLL को संकलित करने के लिए MingW को कॉल करेगा। जब स्पॉन की गई प्रक्रिया स्पूफ किए गए DLL के भीतर एक वास्तविक फ़ंक्शन को कॉल करने का प्रयास करती है, तो हमारा पेलोड DLL कॉल को System32 में स्थित वास्तविक DLL को अग्रेषित करेगा ताकि होस्ट प्रक्रिया क्रैश न हो।

4.

उत्पन्न पेलोड DLL का उपयोग करके dropspawn को कॉल करें।

dropspawn <पेलोड DLL> <x86|x64> <स्पॉन करने के लिए प्रोग्राम> [लेखन योग्य लक्ष्य फ़ोल्डर] [पैरेंट]

पेलोड DLL - उत्पन्न DLL पेलोड का पूर्ण पथ। आर्किटेक्चर - उस प्रक्रिया का आर्किटेक्चर जिसे आप स्पॉन करना चाहते हैं स्पॉन करने के लिए प्रोग्राम - उस प्रक्रिया का नाम/पथ जिसे आप स्पॉन करना चाहते हैं। यदि यह प्रक्रिया System32 (या syswow64) में स्थित है, तो आप केवल नाम निर्दिष्ट कर सकते हैं। अन्यथा, पूर्ण पथ निर्दिष्ट करें। आप प्रक्रिया को कमांड लाइन तर्क भी प्रदान कर सकते हैं। यदि पथ में रिक्त स्थान हैं/यदि आप तर्कों का उपयोग करते हैं, तो पूरी चीज़ को उद्धरण चिह्नों में लपेटें। लेखन योग्य लक्ष्य फ़ोल्डर - वैकल्पिक। यदि खाली छोड़ दिया जाता है, तो dropspawn Beacon की वर्तमान निर्देशिका का उपयोग करने का प्रयास करेगा। यदि पथ में रिक्त स्थान हैं तो उद्धरण चिह्नों का उपयोग करें। पैरेंट - वैकल्पिक। नई स्पॉन की गई प्रक्रिया के साथ PPID स्पूफिंग के लिए उपयोग की जाने वाली प्रक्रिया का नाम। यदि कोई ऐसी प्रक्रिया निर्दिष्ट की गई है जिसके विभिन्न विशेषाधिकार स्तरों के कई चल रहे उदाहरण हैं (जैसे svchost.exe), तो dropspawn उसकी पहचान करने का प्रयास करेगा जिसका उपयोग PPID स्पूफिंग के लिए किया जा सकता है।

उदाहरण: dropspawn /root/dbgcore.dll x64 "WerFault.exe -u -p 4352 -s 160" C:\users\user\appdata\local\temp explorer.exe

यह पेलोड DLL 'dbgcore.dll' को 'c:\users\user\appdata\local\temp\dbgcore.dll' पर डिस्क पर ड्रॉप करेगा और कमांडलाइन तर्कों '-u -p 4352 -s 160' के साथ एक x64 WerFault.exe प्रक्रिया और पैरेंट प्रक्रिया के रूप में explorer.exe स्पॉन करेगा।

5.

सफाई आसान है। डिस्क पर ड्रॉप किए गए पेलोड DLL में Self-Deletion फ़ंक्शन शामिल करके, हमारी नई प्रक्रिया स्पॉन होते ही और इसे लोड करते ही यह हटा दिया जाएगा। यह एक गेम चेंजर है, क्योंकि आमतौर पर DLL तब तक डिस्क पर लॉक रहेगा जब तक हमारी प्रक्रिया जिसने इसे लोड किया है चलती रहती है। यदि Self-Deletion तकनीक किसी कारण से विफल हो जाती है (या प्रक्रिया स्पॉन होने में विफल हो जाती है), तो DropSpawn पेलोड DLL को डिस्क से हटाने का प्रयास करेगा और उपयोगकर्ता को ऑपरेशन के परिणाम के बारे में किसी भी तरह से सूचित करेगा।

पहचान

प्रोसेस इंजेक्शन आमतौर पर रिमोट प्रोसेस खोलें -> रिमोट मेमोरी आवंटित करें -> रिमोट मेमोरी लिखें -> रिमोट मेमोरी निष्पादित करें श्रृंखला का अनुसरण करता है, जिसमें मौजूदा प्रक्रिया का उपयोग करने के बजाय शुरुआत में एक नई प्रक्रिया स्पॉन करने का विकल्प होता है। DropSpawn केवल एक नई प्रक्रिया बनाता है; नई स्पॉन की गई प्रक्रिया शेलकोड को आवंटित करने, लिखने और निष्पादित करने के लिए जिम्मेदार है, इसलिए हम आमतौर पर रिमोट प्रोसेस इंजेक्शन से जुड़े कई IOC से बच सकते हैं।

यह तकनीक निश्चित रूप से इस बात पर निर्भर है कि आपके DLL पेलोड कितने अच्छे हैं। लेकिन हम देख सकते हैं कि Windows क्या देखता है (यह अगला भाग DropSpawn के निजी संस्करण और Beacons स्पॉन करने का उपयोग करता है)।

जहां तक Event Viewer का संबंध है, सब कुछ सामान्य दिखता है:

MDE में देखने के लिए बहुत कम है।

dropspawn चलाना:

MDE लॉग:

PPID स्पूफिंग के साथ:

PPID स्पूफिंग के बिना:

दोनों मामलों में हम देखते हैं कि हमारी मूल beacon प्रक्रिया (जो एक werfault भी है) dbgcore.dll को डिस्क पर ड्रॉप करती है, एक नई WerFault.exe प्रक्रिया बनाती है, नई स्पॉन की गई प्रक्रिया dbgcore.dll लोड करती है, और फिर इसे नाम बदलकर (हटाकर) हटा देती है। महत्वपूर्ण रूप से dbgcore.dll की कोई अतिरिक्त जांच नहीं होती जो अक्सर DLL हाईजैक के साथ आती है क्योंकि हम इसे किसी अक्सर हाईजैक किए जाने वाले स्थान पर नहीं लिख रहे हैं, और WerFault.exe (या जो भी प्रक्रिया आप उपयोग करना चुनते हैं) वास्तव में DLL हाईजैक से उस तरह से जुड़ा नहीं है जैसे WmiPrvSE.exe जैसी चीजें हैं।

दिलचस्प बात यह है कि PPID स्पूफिंग के साथ ऐसा करना लगभग अधिक दृश्यमान है। हालांकि, यह सुरक्षा उत्पाद के आधार पर भिन्न हो सकता है।

सीमाएं

जैसा कि उल्लेख किया गया है, यह आवश्यक है कि उपयोगकर्ता वास्तविक DLL को उस लक्ष्य मशीन से डाउनलोड करें जिस पर वे DropSpawn का उपयोग करने की योजना बना रहे हैं। DLL के गलत संस्करण का उपयोग करने से स्पॉन की गई प्रक्रिया क्रैश हो सकती है यदि यह किसी ऐसे फ़ंक्शन को कॉल करने का प्रयास करती है जो मौजूद नहीं है।

DropSpawn का उपयोग System32 के बाहर के निष्पादन योग्य फ़ाइलों के साथ किया जा सकता है; हालांकि सावधान रहें कि यदि प्रक्रिया प्रक्रिया की वास्तविक एप्लिकेशन निर्देशिका से अतिरिक्त DLL लोड करने का प्रयास करती है तो समस्याएं उत्पन्न हो सकती हैं। क्योंकि हमने एप्लिकेशन निर्देशिका को कहीं और स्पूफ किया है, यदि वास्तविक एप्लिकेशन निर्देशिका अन्यथा DLL खोज क्रम के माध्यम से पहुंच योग्य नहीं है, तो प्रक्रिया क्रैश हो जाएगी/शुरू होने में विफल हो जाएगी क्योंकि यह आवश्यक DLL का पता नहीं लगा सकती है। उत्पादन में उपयोग करने से पहले हमेशा विकास मशीनों पर संभावित हाईजैक का परीक्षण करें!

श्रेय

यह शोध तब शुरू हुआ जब मैं खोज रहा था कि प्रक्रियाएं अपने अंतिम DLL खोज क्रम को कैसे इकट्ठा करती हैं (क्योंकि विभिन्न निर्देशिकाओं में स्थित निष्पादन योग्य फ़ाइलों, वर्तमान निर्देशिका के खोज पथ का हिस्सा होने आदि के कारण इसे रनटाइम पर निर्धारित किया जाना चाहिए)। मेरे शोध ने मुझे इस फोरम पोस्ट तक पहुंचाया, जो इस तकनीक के केंद्र में दो महत्वपूर्ण अप्रलेखित API के मूल के रूप में कार्य करता था।

वे पहले ही लिंक किए जा चुके हैं, लेकिन लोडर लॉक से बचने के संबंध में यह पोस्ट, DLL प्रॉक्सिंग के लिए .def फ़ाइल उत्पन्न करने के लिए यह स्क्रिप्ट, और चल रहे निष्पादन योग्य फ़ाइलों के स्व-विलोपन को सक्षम करने पर यह शोध DropSpawn के लिए उपयुक्त प्रभावी, हथियारबद्ध DLL पेलोड उत्पन्न करने के लिए आवश्यक हैं।

जब मैंने पहली बार इस तकनीक को Twitter पर प्रकाशित किया, तो कई अन्य लोग बातचीत में शामिल हुए और POC उत्पन्न किए। SecurityAndStuff ने यह उत्पन्न किया, जबकि Snovvcrash का यह यहां है