
CobaltStrike BOF का उपयोग करके DLL Application Directory Hijacking के माध्यम से Beacons उत्पन्न करना
DropSpawn एक CobaltStrike BOF है जिसका उपयोग DLL हाईजैकिंग की अपेक्षाकृत अज्ञात विधि के माध्यम से अतिरिक्त बीकन्स को स्पॉन करने के लिए किया जाता है। x86-x86, x64-x64, और x86-x64/विपरीत दिशा में काम करता है। प्रक्रिया इंजेक्शन के विकल्प के रूप में उपयोग करें।
Windows निष्पादन योग्य DLL खोज क्रम का पालन करेंगे जब उन DLL को लोड करने का प्रयास करेंगे जिनके निरपेक्ष पथ निर्दिष्ट नहीं किए गए थे:

DLL हाईजैकिंग के लिए आमतौर पर आवश्यकता होती है कि या तो:
A. एक उपयोगकर्ता के पास उस फ़ोल्डर में लिखने की अनुमति है जिसका खोज क्रम में वास्तविक DLL से अधिक प्राथमिकता है
या
B. कि प्रश्न में DLL सिस्टम पर कहीं भी मौजूद नहीं है, ऐसी स्थिति में इसे उपयोगकर्ता के %PATH% वेरिएबल में उपयोगकर्ता-लिखने योग्य फ़ोल्डर (जैसे %USERPROFILE%\appdata\local\microsoft\windowsapps) में रखा जा सकता है।
ये आवश्यकताएँ C:\Windows\System32 में स्थित निष्पादन योग्य फ़ाइलों के लिए DLL हाईजैकिंग को असंभव बना देती हैं क्योंकि लगभग सभी DLL जो ये निष्पादन योग्य फ़ाइलें लोड करती हैं, वे भी System32 में ही रहती हैं। System32 निष्पादन योग्य फ़ाइल को उपयोगकर्ता-लिखने योग्य स्थान पर कॉपी करना और वहाँ से निष्पादित करना एक विकल्प है, लेकिन यह OPSEC के लिहाज से सुरक्षित नहीं है क्योंकि वैकल्पिक स्थानों से चलने वाले System32 बाइनरी को पहचानना आसान है।
DropSpawn System32 निष्पादन योग्य फ़ाइलों (और अतिरिक्त गैर-उपयोगकर्ता-लिखने योग्य फ़ोल्डरों में पाए जाने वाले अन्य) का उपयोग करके DLL हाईजैकिंग को सक्षम बनाता है, "वह निर्देशिका जहाँ से एप्लिकेशन लोड किया गया है" को एक मनमाने उपयोगकर्ता-निर्दिष्ट निर्देशिका के रूप में स्पूफ करके।
DropSpawn का सार्वजनिक रिलीज़ गैर-सार्वजनिक रिलीज़ से थोड़ा भिन्न है। गैर-सार्वजनिक रिलीज़ एक स्वामित्व पेलोड जनरेटर का लाभ उठाता है, जिससे ऑपरेटर के लिए अनुभव बहुत अधिक सहज हो जाता है। सार्वजनिक रिलीज़ में इस तथ्य को ध्यान में रखते हुए थोड़ा बदलाव किया गया है कि उपयोगकर्ताओं के पास DLL हाईजैक-संगत पेलोड उत्पन्न करने के अपने तरीके होंगे। उपयोगकर्ताओं को dropspawn को एकीकृत और हथियारबंद करने में सहायता करने के लिए एक Python3 स्क्रिप्ट के साथ-साथ एक प्रदर्शन DLL का स्रोत कोड शामिल किया गया है।
कुछ लक्षित निष्पादन योग्य फ़ाइलों की पहचान करें जो अपने निरपेक्ष पथ निर्दिष्ट किए बिना DLL लोड करने का प्रयास करती हैं। आप ऐसा कर सकते हैं exe को उपयोगकर्ता-लिखने योग्य निर्देशिका में कॉपी करके और Procmon के साथ इसकी निगरानी करते हुए इसे निष्पादित करके। इस उदाहरण में हम WerFault.exe का उपयोग करेंगे जो सामान्यतः C:\Windows\System32\WerFault.exe पर स्थित होता है।

उपरोक्त उदाहरण में cryptsp.dll, wer.dll, dbghelp.dll, और bcrypt.dll सभी व्यवहार्य उम्मीदवार हैं क्योंकि WerFault के भीतर उनके निरपेक्ष पथ निर्दिष्ट नहीं किए गए थे; परिणामस्वरूप, WerFault पहले अपने एप्लिकेशन निर्देशिका से उन्हें लोड करने का प्रयास करेगा और फिर शेष DLL खोज क्रम का सहारा लेगा। ध्यान दें कि यह आमतौर पर चिंता का विषय नहीं है क्योंकि WerFault की एप्लिकेशन निर्देशिका System32 ही है।
लक्ष्य सिस्टम से एक हाईजैक करने योग्य DLL डाउनलोड करें।
यह आवश्यक है ताकि हम इसके एक्सपोर्ट निकाल सकें और उन्हें अपने पेलोड DLL में शामिल कर सकें। उसी मशीन से हाईजैक करने योग्य DLL लेना महत्वपूर्ण है जिस पर आप DropSpawn का उपयोग करना चाहते हैं, क्योंकि Windows संस्करणों के बीच DLL बदलते हैं। इसके अतिरिक्त, यदि आप x86 बीकन चला रहे हैं और DropSpawn का उपयोग करके x64 बीकन स्पॉन करना चाहते हैं, तो सुनिश्चित करें कि आप वास्तविक DLL का x64 संस्करण डाउनलोड करें, 'C:\windows\sysnative...' निर्दिष्ट करके, 'C:\windows\system32...' के बजाय।
generate_dll.py चलाएं, डाउनलोड किए गए DLL और वांछित पेलोड आर्किटेक्चर को पास करें। Generate_dll.py इस स्क्रिप्ट का एक संशोधित संस्करण है। यह प्रदान किए गए DLL को पार्स करेगा, DLL के एक्सपोर्ट वाली .def फ़ाइल बनाएगा, और हमारे प्रदर्शन पेलोड DLL को संकलित करने के लिए MingW को कॉल करेगा। जब स्पॉन की गई प्रक्रिया स्पूफ किए गए DLL के भीतर एक वास्तविक फ़ंक्शन को कॉल करने का प्रयास करती है, तो हमारा पेलोड DLL कॉल को System32 में स्थित वास्तविक DLL पर अग्रेषित करेगा ताकि होस्ट प्रक्रिया क्रैश न हो।

जनरेट किए गए पेलोड DLL का उपयोग करके dropspawn को कॉल करें।
dropspawn <पेलोड DLL> <x86|x64> <स्पॉन करने का प्रोग्राम> [लिखने योग्य लक्ष्य फ़ोल्डर] [पैरेंट]
पेलोड DLL - जनरेट किए गए DLL पेलोड का पूरा पथ।
आर्किटेक्चर - आप जिस प्रक्रिया को स्पॉन करना चाहते हैं उसका आर्किटेक्चर।
स्पॉन करने का प्रोग्राम - आप जिस प्रक्रिया को स्पॉन करना चाहते हैं उसका नाम/पथ। यदि यह प्रक्रिया System32 (या syswow64) में स्थित है, तो आप केवल नाम निर्दिष्ट कर सकते हैं। अन्यथा, पूरा पथ निर्दिष्ट करें। आप प्रक्रिया को कमांड लाइन तर्क भी प्रदान कर सकते हैं। यदि पथ में रिक्त स्थान हैं/यदि आप तर्कों का उपयोग करते हैं, तो पूरी चीज़ को उद्धरण चिह्नों में लपेटें।
लिखने योग्य लक्ष्य फ़ोल्डर - वैकल्पिक। यदि खाली छोड़ा जाता है, तो dropspawn बीकन के वर्तमान निर्देशिका का उपयोग करने का प्रयास करेगा। यदि पथ में रिक्त स्थान हैं तो उद्धरण चिह्नों का उपयोग करें।
पैरेंट - वैकल्पिक। नवनिर्मित प्रक्रिया के साथ PPID स्पूफिंग के लिए उपयोग करने के लिए प्रक्रिया का नाम। यदि कोई ऐसी प्रक्रिया निर्दिष्ट की गई है जिसके भिन्न विशेषाधिकार स्तरों के कई चल रहे उदाहरण हैं (जैसे svchost.exe), तो dropspawn एक ऐसी प्रक्रिया की पहचान करने का प्रयास करेगा जिसका उपयोग PPID स्पूफिंग के लिए किया जा सकता है।
उदाहरण: dropspawn /root/gitlab/DropSpawn_BOF/dist/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' और पैरेंट प्रक्रिया के रूप में explorer.exe के साथ x64 WerFault.exe प्रक्रिया स्पॉन करेगा।


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

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

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

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

दोनों मामलों में हम देखते हैं कि हमारी मूल बीकन प्रक्रिया (एक 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 का अपना यहाँ है