DSCourier BOF

यह Dylan Davis और Matthew Schramm के DSCourier प्रोजेक्ट का BOF कार्यान्वयन है। यह WinGet के COM इंटरफ़ेस का उपयोग करके Microsoft-हस्ताक्षरित और विश्वसनीय प्रक्रिया में मनमाना powershell कोड निष्पादित करता है। उनका पूरा शोध ब्लॉग यहाँ पाया जा सकता है।

मेरे द्वारा जारी अधिकांश परियोजनाओं के विपरीत, यह एक संचालनात्मक रूप से तैयार टूल नहीं है, बल्कि एक POC से अधिक है। मैंने कई समस्याओं की खोज के बाद इसे आगे बढ़ाने का निर्णय नहीं लिया जो इसे आसानी से तैनात करने योग्य BOF बनाने में बाधा उत्पन्न करती हैं। कोड लगभग पूरी तरह से "clanked" किया गया था। कई मुद्दे अनसुलझे हैं और नीचे चर्चा की गई है

उपयोग

अपना मनमाना powershell कोड dist/rev.yml फ़ाइल में रखें। डिफ़ॉल्ट रूप से इसमें मूल रिपॉजिटरी से एक सरल powershell रिवर्स शेल है। यदि आप इसका उपयोग करना चुनते हैं, तो मौजूदा उदाहरण में IP को अपने वांछित IP से बदलना सुनिश्चित करें।

powershell रिवर्स शेल का उपयोग करने का उदाहरण:

यह कैसे काम करता है / सीमाएँ

बिना किसी विशेष क्रम के, यहाँ इस टूल के कुछ मुद्दे/सीमाएँ हैं।

1. COM कॉल्स के सफल होने के लिए, Microsoft.Management.Configuration.winmd फ़ाइल उसी निर्देशिका में उपस्थित होनी चाहिए जहाँ COM कॉल्स करने वाला executable है। यह तुरंत एक समस्या उत्पन्न करता है जब कोई Beacon hollowed-out system32 प्रक्रिया से चलाया जाता है, जहाँ सामान्य उपयोगकर्ताओं के पास लिखने की अनुमति नहीं होती। इसके आसपास जाने के लिए, फ़ाइल को इसके बजाय %APPDATA%\temp में ड्रॉप किया जाता है और WinTypes!RoGetMetaDataFile फ़ंक्शन जो winmd फ़ाइलपथ प्राप्त करता है, को एक inline hook के साथ हुक किया जाता है ताकि हम temp पथ स्थान प्रदान कर सकें। इससे winmd फ़ाइल को पढ़ा जा सकता है / COM कॉल्स सफल हो सकती हैं, लेकिन इसका मतलब है कि VirtualProtect कॉल्स किए जाते हैं और DLL मेमोरी को ओवरराइट किया जाता है, जो IOCs बनाता है।
2. #1 के बाद, BOF चलाने के बाद winmd फ़ाइल डिस्क पर लॉक हो जाती है जब तक Beacon प्रक्रिया बाहर नहीं निकलती। मैंने इसे हल करने का प्रयास किया, जिसमें स्व-विलोपन कार्यक्षमता जोड़ना शामिल है जो इस बिंदु पर प्रसिद्ध है, लेकिन फ़ाइल डिस्क पर लॉक रही। हो सकता है कि इसके आसपास इंजीनियरिंग/समाधान किया जा सके, लेकिन यह किसी और के लिए है।
3. जैसा कि मूल शोध में उल्लेख किया गया है, क्योंकि यह WinGet के अंदर pwsh संसाधन का उपयोग करता है, ConfigurationRemotingServer.exe के अंतर्गत एक conhost.exe प्रक्रिया उत्पन्न होती है। Claude ने सुझाव दिया कि pwsh को लागू करने के बजाय एक कस्टम बाइनरी मॉड्यूल को संसाधन के रूप में लोड करना संभव हो सकता है, जिससे conhost समस्या हल हो जाएगी, लेकिन इसके लिए डिस्क पर अतिरिक्त फ़ाइलें ड्रॉप करने की आवश्यकता है और मैं इसे काम करने में असमर्थ रहा। यह संभव नहीं हो सकता है। यदि यह काम करता, तो यह एक सामान्य .NET dll को डिस्क पर ड्रॉप करने का द्वार खोलता, जिसे ConfigurationRemotingServer.exe द्वारा लोड किया जा सकता है और पारित शेलकोड/पैराम आदि निष्पादित कर सकता है।
4. यह BOF आवश्यक COM इंटरफ़ेस के Async संस्करणों को लागू करता है। Sync संस्करणों का उपयोग करने से Beacon हैंग हो जाता है / तब तक वापस कॉल नहीं करता जब तक ConfigurationRemotingServer.exe प्रक्रिया समाप्त नहीं हो जाती; सरल रिवर्स शेल उदाहरण के साथ, इसका मतलब होगा कि शेल मारे जाने तक Beacon दोबारा चेक-इन नहीं करेगा। Async इंटरफ़ेस पर स्विच करने से यह समस्या हल हो जाती है, लेकिन कुछ समय संबंधी समस्याएँ उत्पन्न होती हैं। विशिष्ट कॉलों के बीच देरी के लिए एक हार्डकोडेड 3 सेकंड की नींद है जो व्यवहार में काम करती है, लेकिन निश्चित रूप से इसे लागू करने का सही तरीका नहीं है।
5. COM इंटरफ़ेस परिभाषाएँ GitHub से winget-cli .msixbundle डाउनलोड करके, .msix निकालकर, और .winmd फ़ाइल ढूंढकर प्राप्त की गईं। फिर IDL फ़ाइलों को निकालने के लिए winmdidl.exe का उपयोग किया गया। उसके बाद IDL को हेडर/.c फ़ाइलों में बदलने के लिए midlrt.exe का उपयोग किया गया, जिसे Claude द्वारा आवश्यक परिभाषाओं तक सीमित करने के लिए पार्स किया गया। यह अभी भी कोड का एक गड़बड़ है। इस प्रक्रिया को बेहतर ढंग से समझने के लिए यह Microsoft लिंक संभवतः सहायक होगा।
6. कोड सामान्यतः एक गड़बड़ है क्योंकि यह POC चरण से बाहर नहीं आया।
7. लक्ष्य मशीन पर BOF सफल होने से पहले winget configure --enable कमांड को कम से कम एक बार चलाया जाना चाहिए। मैंने इसका कारण इस तथ्य पर खोजा कि ConfigurationRemotingServer.exe वाला DotNet निर्देशिका तब तक मौजूद नहीं होता जब तक कमांड नहीं चलाया जाता / बाइनरी डाउनलोड नहीं हो जाती। ये फ़ाइलें C:\Program files\WindowsApps\... में रहती हैं और इस प्रकार निचले विशेषाधिकार वाले उपयोगकर्ता द्वारा लिखने योग्य नहीं हैं, इसलिए हम BOF के साथ इन फ़ाइलों को स्वयं डिस्क पर ड्रॉप भी नहीं कर सकते और चीज़ों को काम नहीं कर सकते।
8. मैंने इसकी जाँच की, और जहाँ तक मैं बता सकता हूँ, ये DCOM इंटरफ़ेस नहीं हैं, केवल COM हैं। इसलिए यह दूसरी मशीनों पर पार्श्व गति के लिए कोई व्यवहार्य आदिम नहीं है।
9. #7 के कारण, मेरी राय में यह एक अच्छी/विश्वसनीय प्रारंभिक पहुँच विधि नहीं है। यदि आप WinGet अक्षम (मूल ब्लॉग पोस्ट देखें) वाली मशीन पर उतरते हैं, या configure --enable कमांड नहीं चलाया गया है, तो आप कठिन रुक जाते हैं। पोस्ट-एक्स उद्देश्यों के लिए, इसका कुछ मूल्य हो सकता है, लेकिन आप कुछ हद तक सीमित हैं क्योंकि यह एक निश्चित प्रक्रिया है जो आपके कोड को स्पॉन/चलाएगी, और यह pwsh होने के कारण AMSI सक्रिय होगा।

संकलन

यह टूल सामान्य BOF API घोषणाओं (जैसे bofdefs.h फ़ाइल) के उपयोग के बिना लिखा गया था। जैसा कि Matt Ehrnschwender द्वारा इस ब्लॉग पोस्ट में उल्लिखित है, objcopy का उपयोग करके BOF में संकलन के बाद DLL$API प्रारूप के उचित प्रतीकों को पैच करना संभव है।

मैंने BOFPatcher नामक एक टूल लिखा है जो इस प्रक्रिया को स्वचालित करता है। यह उपयोगकर्ताओं को बोझिल API घोषणाओं की चिंता किए बिना सामान्य C के रूप में BOF लिखने की अनुमति देता है:

यह टूल उन लोगों के लिए उपलब्ध है जो मेरा BOF Development and Tradecraft पाठ्यक्रम खरीदते हैं।

जबकि BOFPatcher टूल इस रिपॉजिटरी में शामिल नहीं है, इस टूल का Makefile objcopy को कॉल करता है, जो imports_dscourier64.txt फ़ाइल को पास करता है जिसमें उचित प्रतीक प्रतिस्थापन होते हैं, जो तब BOF को उपयोग योग्य बनाता है।

श्रेय

1. Dylan और Matt का शानदार काम। उनसे और अधिक देखने की आशा करता हूँ!
2. इस अधिकांश कोड को "clank" करने के लिए Claude।