InlineExecute-Assembly

InlineExecute-Assembly एक प्रूफ ऑफ कॉन्सेप्ट बीकन ऑब्जेक्ट फ़ाइल (BOF) है जो सुरक्षा पेशेवरों को प्रक्रिया में .NET असेंबली निष्पादन करने की अनुमति देता है, जो कोबाल्ट स्ट्राइक के पारंपरिक फोर्क और रन execute-assembly मॉड्यूल के विकल्प के रूप में काम करता है। InlineExecute-Assembly Main(string[] args) या Main() एंट्री पॉइंट वाली किसी भी असेंबली को निष्पादित करेगा। इससे आप अधिकांश जारी किए गए टूलिंग को बिना किसी पूर्व संशोधन के चला सकते हैं।

BOF स्वचालित रूप से यह निर्धारित करेगा कि आपकी असेंबली (v2.0.50727 या v4.0.30319) के लिए प्रक्रिया में कौन सा कॉमन लैंग्वेज रनटाइम (CLR) लोड करने की आवश्यकता है, और अधिकांश मामलों में, यदि कोई समस्या आती है तो यह सही ढंग से बाहर निकल जाना चाहिए। BOF कई फ्लैग का भी समर्थन करता है जो ऑपरेटर को .NET निष्पादन से पहले कई व्यवहार निर्धारित करने की अनुमति देते हैं, जिनमें शामिल हैं: मेमोरी पैचिंग के माध्यम से AMSI को अक्षम करना, मेमोरी पैचिंग के माध्यम से ETW को अक्षम और पुनर्स्थापित करना, बनाए जाने वाले CLR App Domain नाम का अनुकूलन, क्या आपकी असेंबली के कंसोल आउटपुट को नेम्ड पाइप या मेलस्लॉट पर निर्देशित करना है या नहीं, और ऑपरेटर को डिफ़ॉल्ट एंट्री पॉइंट Main(string[] args) को Main() पर स्विच करने की अनुमति देता है। उपयोग, उपयोग के मामलों और संभावित डिटेक्शन पर अधिक विवरण नीचे और https://securityintelligence.com/posts/net-execution-inlineexecute-assembly/ पर पाया जा सकता है।

अंत में, हमारे .NET असेंबली को हमारे बीकन इम्प्लांट के समान प्रक्रिया में निष्पादित करने का लाभ यह है कि हम Cobalt Strike के execute-assembly मॉड्यूल के डिफ़ॉल्ट व्यवहार से बचते हैं, जो CLR/.NET असेंबली को लोड/इंजेक्ट करने के लिए एक नई प्रक्रिया बनाता है। हालांकि, अन्य ऑप्सेक विचार अभी भी मौजूद हैं, उदाहरण के लिए, क्या जिस प्रक्रिया में हम निष्पादित कर रहे हैं वह सामान्य रूप से CLR लोड करती है या क्या हम जो .NET असेंबली निष्पादित कर रहे हैं उसके कोई ज्ञात सिग्नेचर हैं? इसलिए, नुकसान यह है कि यदि कुछ पकड़ा जाता है और मार दिया जाता है, उदाहरण के लिए AMSI द्वारा, तो आपका बीकन भी मारा जाता है।

विषय संदर्भ

यह उपकरण उस उत्कृष्ट शोध, उपकरणों और कोड के बिना अस्तित्व में नहीं आता जो सुरक्षा समुदाय के सदस्यों द्वारा पहले ही प्रकाशित किए जा चुके हैं। इसलिए धन्यवाद। अंत में, यदि आपको लगता है कि किसी को नीचे छोड़ दिया गया है, तो कृपया मुझे बताएं और मैं उन्हें जोड़ दूंगा।

• HostingCLR - यहाँ - CLR/असेंबली निष्पादन तर्क
• Dotnet-Loader-Shellcode - (@modexpblog द्वारा) - यहाँ - C में .NET निष्पादित करने के लिए COM इंटरफेस सहित सर्वांगीण उत्कृष्ट शोध -> असली MVP
• Donut - (@TheRealWover और @modexpblog द्वारा) - यहाँ - COM इंटरफेस हेडर
• Memory Patching AMSI Bypass - (@_RastaMouse द्वारा) - यहाँ - AMSI मेमोरी पैचिंग शोध
• Metasploit-Execute-Assembly - (@b4rtik द्वारा) - यहाँ - संशोधित AMSI पैचिंग और .NET संस्करण खोजने के लिए फ़ंक्शन का उपयोग
• ExecuteAssembly - (@med0x2e द्वारा) - यहाँ - संशोधित एग्रेसर स्क्रिप्ट
• Hiding Your .NET ETW - (@xpn द्वारा) - यहाँ - उत्कृष्ट ETW शोध
• ETW BOF - (@ajpc500 द्वारा) - यहाँ - संशोधित ETW पैचिंग
• ExecuteAssembly_Mailslot - (@N4k3dTurtl3 द्वारा) - यहाँ - कंसोल रीडायरेक्शन के लिए मेलस्लॉट का उपयोग (संशोधित)
• @freefirex2 - BOF के आंतरिक कार्य और चेतावनियाँ साझा करने के लिए पर्याप्त दयालु थे।

आरंभ करना

1. inlineExecute-Assembly फ़ोल्डर को उसकी सभी सामग्री सहित उस सिस्टम पर कॉपी करें जिससे आप Cobalt Strike GUI एप्लिकेशन के माध्यम से कनेक्ट करने की योजना बना रहे हैं।
2. inlineExecute-Assembly.cna एग्रेसर स्क्रिप्ट लोड करें
3. अधिकांश बुनियादी निष्पादन के लिए inlineExecute-Assembly --dotnetassembly /path/to/assembly.exe चलाएँ (विशिष्ट फ्लैग उदाहरणों के लिए नीचे उपयोग के मामले देखें)

स्वयं बनाएँ

src निर्देशिका के अंदर x64 नेटिव टूल्स कमांड प्रॉम्प्ट फ़ॉर VS 2019 के माध्यम से नीचे दिए गए कमांड को चलाएँ:

cl.exe /c inlineExecute-Assembly.c /GS- /FoinlineExecute-Assemblyx64.o

src निर्देशिका के अंदर x86 नेटिव टूल्स कमांड प्रॉम्प्ट फ़ॉर VS 2019 के माध्यम से नीचे दिए गए कमांड को चलाएँ:

cl.exe /c inlineExecute-Assembly.c /GS- /FoinlineExecute-Assemblyx86.o

फ्लैग

--dotnetassembly        आपकी असेंबली का निर्देशिका पथ **आवश्यक**
--assemblyargs          पास करने के लिए असेंबली आर्गुमेंट
--appdomain             भेजे गए AppDomain का डिफ़ॉल्ट नाम बदलें (डिफ़ॉल्ट मान totesLegit है और इसे शामिल एग्रेसर स्क्रिप्ट द्वारा सेट किया गया है) *डोमेन हमेशा अनलोड होता है*
--amsi                  मेमोरी पैचिंग के माध्यम से AMSI को अक्षम करने का प्रयास करता है (यदि सफल रहा, तो AMSI प्रक्रिया के पूरे जीवन के लिए अक्षम रहेगा)
--etw                   मेमोरी पैचिंग के माध्यम से ETW को अक्षम करने का प्रयास करता है (यदि सफल रहा, तो ETW प्रक्रिया के पूरे जीवन के लिए अक्षम रहेगा जब तक कि वापस न लाया जाए)
--revertetw             मेमोरी पैचिंग के माध्यम से ETW को अक्षम करने का प्रयास करता है और फिर इसे मूल स्थिति में वापस पैच करता है
--pipe                  नेम्ड पाइप का डिफ़ॉल्ट नाम बदलें (डिफ़ॉल्ट मान totesLegit है और इसे शामिल एग्रेसर स्क्रिप्ट द्वारा सेट किया गया है)
--mailslot              कंसोल आउटपुट को रीडायरेक्ट करने के लिए मेलस्लॉट का उपयोग करने के लिए स्विच करता है। मेलस्लॉट का डिफ़ॉल्ट नाम बदलता है (यदि खाली छोड़ा जाता है, तो डिफ़ॉल्ट मान totesLegit है और इसे शामिल एग्रेसर स्क्रिप्ट द्वारा सेट किया गया है)
--main                  एंट्री पॉइंट को Main() में बदलता है (डिफ़ॉल्ट मान Main(string[] args) है)

उपयोग के मामले

.NET असेंबली निष्पादित करें

सिंटैक्स

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe

उपयोग के मामले

.NET असेंबली को तर्कों के साथ निष्पादित करें

सिंटैक्स

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker

उपयोग के मामले

.NET असेंबली को तर्कों के साथ निष्पादित करें और AMSI अक्षम करें

सिंटैक्स

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --amsi

उपयोग के मामले

.NET असेंबली को तर्कों के साथ निष्पादित करें और ETW अक्षम करें

सिंटैक्स

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --etw

उपयोग के मामले

.NET असेंबली को तर्कों के साथ निष्पादित करें और आउटपुट को डिफ़ॉल्ट नेम्ड पाइप के बजाय मेलस्लॉट के माध्यम से रीडायरेक्ट करें

सिंटैक्स

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --mailslot

उपयोग के मामले

.NET असेंबली को तर्कों के साथ निष्पादित करें और एग्रेसर स्क्रिप्ट में सेट डिफ़ॉल्ट नेम्ड पाइप नाम बदलें

सिंटैक्स

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --pipe forRealLegit

उपयोग के मामले

.NET असेंबली निष्पादित करें और एग्रेसर स्क्रिप्ट में सेट डिफ़ॉल्ट एप डोमेन बदलें

सिंटैक्स

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --appdomain forRealLegit

उपयोग के मामले

.NET असेंबली को Main() एंट्री पॉइंट के साथ निष्पादित करें, डिफ़ॉल्ट Main(string[] args) के बजाय

सिंटैक्स

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/simpleMain.exe --main

उपयोग के मामले

पूरी ताकत से काम करें (Go HAM)

सिंटैक्स

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --amsi --etw --appdomain forRealLegit --mailslot forRealLegit

चेतावनियाँ

1. जबकि मैंने इसे यथासंभव स्थिर बनाने का प्रयास किया है, कोई गारंटी नहीं है कि चीज़ें कभी क्रैश नहीं होंगी और बीकन नहीं मरेंगे। हमारे पास फोर्क और रन की अतिरिक्त सुविधा नहीं है जहाँ यदि कुछ गलत होता है तो हमारा बीकन बच जाता है। BOF के साथ यही व्यापार-बंदी है। इसके साथ, मैं इस बात पर जोर नहीं दे सकता कि आपके लिए अपने असेंबली का पहले से परीक्षण करना कितना महत्वपूर्ण है ताकि यह सुनिश्चित हो सके कि वे उपकरण के साथ ठीक से काम करेंगे।
2. चूँकि BOF प्रक्रिया में निष्पादित होता है और चलने के दौरान बीकन को अपने कब्जे में ले लेता है, लंबे समय तक चलने वाले असेंबली के लिए उपयोग करने से पहले इसे ध्यान में रखा जाना चाहिए। यदि आप कुछ ऐसा चलाना चुनते हैं जिसके परिणाम वापस आने में लंबा समय लगेगा, तो आपका बीकन तब तक सक्रिय नहीं होगा जब तक परिणाम वापस नहीं आते और आपकी असेंबली समाप्त नहीं हो जाती। यह स्लीप सेट का भी पालन नहीं करता है। उदाहरण के लिए, यदि आपका स्लीप 10 मिनट पर सेट है और आप BOF चलाते हैं, तो आपको BOF के निष्पादन समाप्त होते ही परिणाम वापस मिल जाएंगे।
3. जब तक PE को मेमोरी में लोड करने वाले टूल (जैसे SafetyKatz) में संशोधन नहीं किया जाता, ये सबसे अधिक संभावना आपके बीकन को मार देंगे। इनमें से कई टूल एक्जीक्यूट असेंबली के साथ ठीक काम करते हैं क्योंकि वे बलि प्रक्रिया से बाहर निकलने से पहले अपना कंसोल आउटपुट भेजने में सक्षम होते हैं। जब वे हमारे इन-प्रोसेस BOF के माध्यम से बाहर निकलते हैं, तो वे हमारी प्रक्रिया को मार देते हैं, जो हमारे बीकन को मार देता है। इन्हें काम करने के लिए संशोधित किया जा सकता है लेकिन मैं इस प्रकार के असेंबली को एक्जीक्यूट असेंबली के माध्यम से चलाने की सलाह दूंगा क्योंकि अन्य गैर-ऑप्सेक-अनुकूल चीज़ें आपकी प्रक्रिया में लोड हो सकती हैं जो हटाई नहीं जाती हैं।
4. यदि आपकी असेंबली Environment.Exit का उपयोग करती है, तो इसे हटाना होगा क्योंकि यह प्रक्रिया और बीकन को मार देगा।
5. नेम्ड पाइप और मेल स्लॉट अद्वितीय होने चाहिए। यदि आपको डेटा वापस नहीं मिलता है और आपका बीकन अभी भी जीवित है, तो समस्या सबसे अधिक संभावना है कि आपको एक अलग नेम्ड पाइप या मेल स्लॉट नाम चुनने की आवश्यकता है।

डिटेक्शन

कुछ डिटेक्शन और शमन रणनीतियाँ जिनका उपयोग किया जा सकता है:

1. AMSI और ETW मेमोरी पैचिंग करते समय PAGE_EXECUTE_READWRITE का उपयोग करता है। यह जानबूझकर किया गया था और यह एक लाल झंडा होना चाहिए क्योंकि बहुत कम प्रोग्राम में PAGE_EXECUTE_READWRITE मेमोरी प्रोटेक्शन के साथ मेमोरी रेंज होती है।
2. बनाए गए नेम्ड पाइप का डिफ़ॉल्ट नाम totesLegit है। यह जानबूझकर किया गया था और सिग्नेचर डिटेक्शन का उपयोग इसे फ्लैग करने के लिए किया जा सकता है।
3. बनाए गए मेलस्लॉट का डिफ़ॉल्ट नाम totesLegit है। यह जानबूझकर किया गया था और सिग्नेचर डिटेक्शन का उपयोग इसे फ्लैग करने के लिए किया जा सकता है।
4. लोड किए गए AppDomain का डिफ़ॉल्ट नाम totesLegit है। यह जानबूझकर किया गया था और सिग्नेचर डिटेक्शन का उपयोग इसे फ्लैग करने के लिए किया जा सकता है।
5. .NET के दुर्भावनापूर्ण उपयोग का पता लगाने के लिए अच्छे सुझाव (@bohops द्वारा) यहाँ, (F-Secure द्वारा) यहाँ, और यहाँ
6. संदिग्ध प्रक्रियाओं में .NET CLR लोडिंग देखना, जैसे अप्रबंधित प्रक्रियाएँ जिनमें CLR कभी लोड नहीं होना चाहिए।
7. इवेंट ट्रेसिंग यहाँ
8. अन्य ज्ञात Cobalt Strike Beacon IOC या C2 egress/communication IOC देखना।