शेलकोड फ्लक्चुएशन PoC

एक PoC इम्प्लीमेंटेशन एक अन्य इन-मेमोरी एवेज़न तकनीक के लिए जो शेलकोड की सामग्री को चक्रीय रूप से एन्क्रिप्ट और डिक्रिप्ट करती है ताकि यह RW (या NoAccess) और RX मेमोरी प्रोटेक्शन के बीच फ्लक्चुएट हो सके। जब हमारा शेलकोड RW या NoAccess मेमोरी पेजों में रहता है, तो Moneta या pe-sieve जैसे स्कैनर्स इसे ट्रैक करने और आगे के विश्लेषण के लिए डंप करने में असमर्थ होंगे।

परिचय

ThreadStackSpoofer रिलीज़ करने के बाद मुझे README के निम्नलिखित बिंदु के बारे में कुछ प्रश्न मिले:

अपने Beacon के मेमोरी पेजों की सुरक्षा को RX/RWX से RW में बदलें और सोने से पहले उनकी सामग्री को एन्क्रिप्ट करें (यह Moneta या pe-sieve जैसे स्कैनर्स को बायपास कर सकता है)

उससे पहले मुझे पूरा भरोसा था कि समुदाय पहले से ही जानता है कि अपने पेलोड को एन्क्रिप्ट/डिक्रिप्ट कैसे करना है और असामान्य एक्ज़ीक्यूटेबल क्षेत्रों की तलाश करने वाले मेमोरी स्कैनर्स को बायपास करने के लिए अपनी मेमोरी प्रोटेक्शन कैसे फ्लिप करनी है। प्रश्नों ने अन्यथा साबित किया इसलिए मैंने यह अनवेपनाइज़्ड PoC जारी करने का निर्णय लिया ताकि एक और एवेज़न रणनीति का दस्तावेजीकरण किया जा सके और समुदाय के काम करने के लिए नमूना इम्प्लीमेंटेशन पेश किया जा सके।

यह PoC एक अपेक्षाकृत सरल तकनीक का प्रदर्शन है, जो पहले से ही ऑफेंसिव समुदाय को ज्ञात है (इसलिए मैं यहाँ वास्तव में कुछ नया नहीं ला रहा हूँ) उम्मीद है कि कुछ व्यावसायिक फ्रेमवर्क द्वारा दिखाए गए जादू के पीछे की गोपनीयता को उजागर किया जा सके जो उपरोक्त दोनों मेमोरी स्कैनर्स को लक्षित करते हुए अपनी एवेज़न क्षमताओं का प्रदर्शन करते हैं।

यहाँ एक तुलना है जब RW में फ्लक्चुएट किया जाता है (दूसरा विकल्प PAGE_NOACCESS में फ्लक्चुएट करना है - नीचे वर्णित):

1. Beacon एन्क्रिप्टेड नहीं
2. Beacon एन्क्रिप्टेड (फ्लक्चुएटिंग)

यह इम्प्लीमेंटेशन मेरे ThreadStackSpoofer के साथ मिलकर ऑफेंसिव सिक्योरिटी समुदाय को व्यावसायिक C2 उत्पादों की पेशकश को पकड़ने के लिए नमूना इम्प्लीमेंटेशन प्रदान करता है, ताकि हम अपने Red Team टूलिंग में उनसे बदतर न हों। 💪

---

यह कैसे काम करता है?

यह प्रोग्राम सेल्फ-इंजेक्शन शेलकोड करता है (मोटे तौर पर क्लासिक VirtualAlloc + memcpy + CreateThread के माध्यम से)। जब शेलकोड चलता है (यह इम्प्लीमेंटेशन विशेष रूप से Cobalt Strike Beacon इम्प्लांट्स को लक्षित करता है) तो एक Windows फ़ंक्शन को हुक किया जाएगा जो उस क्षण को इंटरसेप्ट करता है जब Beacon सो जाता है kernel32!Sleep। जब भी हुक किया गया MySleep फ़ंक्शन आमंत्रित होता है, यह अपनी मेमोरी आवंटन सीमाओं का पता लगाएगा, उनकी सुरक्षा को RW में फ्लिप करेगा और वहाँ संग्रहीत सभी बाइट्स को xor32 करेगा। अपेक्षित समय की प्रतीक्षा करने के बाद, जब शेलकोड हमारे MySleep हैंडलर पर वापस आता है, तो हम शेलकोड के डेटा को डिक्रिप्ट करेंगे और सुरक्षा को वापस RX में फ्लिप करेंगे।

PAGE_READWRITE में फ्लक्चुएशन इस प्रकार काम करता है

1. शेलकोड की सामग्री को फ़ाइल से पढ़ें।
2. kernel32!Sleep को हुक करें जो हमारे कॉलबैक की ओर इशारा करता है।
3. शेलकोड को VirtualAlloc + memcpy + CreateThread के माध्यम से इंजेक्ट और लॉन्च करें। ThreadStackSpoofer में जो हमारे पास था उसके विपरीत, यहाँ हम अपने शेलकोड को लॉन्च करने के लिए ntdll में कुछ भी हुक नहीं कर रहे हैं बल्कि अपने स्वयं के फ़ंक्शन से उस पर कूदते हैं। यह संशोधित ntdll मेमोरी की ओर इशारा करने वाले सरल IOC को मेमोरी में छोड़ने से बचने का प्रयास करता है।
4. जैसे ही Beacon सोने का प्रयास करता है, हमारा MySleep कॉलबैक आमंत्रित होता है।
5. Beacon की मेमोरी आवंटन एन्क्रिप्ट हो जाती है और सुरक्षा RW में फ्लिप हो जाती है
6. फिर हम मूल kernel32!Sleep को अनहुक करते हैं ताकि मेमोरी में सरल IOC न छूटे जो यह दर्शाता हो कि Sleep को ट्रैम्पोलिन (इन-लाइन हुक) किया गया है।
7. Beacon को आगे के संचार की प्रतीक्षा करते हुए सोने देने के लिए मूल ::Sleep को कॉल किया जाता है।
8. Sleep समाप्त होने के बाद, हम अपने शेलकोड के डेटा को डिक्रिप्ट करते हैं, उसकी मेमोरी सुरक्षा को वापस RX में फ्लिप करते हैं और फिर बाद के स्लीप के इंटरसेप्शन को सुनिश्चित करने के लिए kernel32!Sleep को फिर से हुक करते हैं।

PAGE_NOACCESS में फ्लक्चुएशन इस प्रकार काम करता है

1. शेलकोड की सामग्री को फ़ाइल से पढ़ें।
2. kernel32!Sleep को हुक करें जो हमारे कॉलबैक की ओर इशारा करता है।
3. शेलकोड को VirtualAlloc + memcpy + CreateThread के माध्यम से इंजेक्ट और लॉन्च करें ...
4. Vectored Exception Handler (VEH) को इनिशियलाइज़ करें ताकि हमारा अपना हैंडलर सेट हो जो Access Violation अपवादों को पकड़ेगा।
5. जैसे ही Beacon सोने का प्रयास करता है, हमारा MySleep कॉलबैक आमंत्रित होता है।
6. Beacon की मेमोरी आवंटन एन्क्रिप्ट हो जाती है और सुरक्षा PAGE_NOACCESS में फ्लिप हो जाती है
7. फिर हम मूल kernel32!Sleep को अनहुक करते हैं ताकि मेमोरी में सरल IOC न छूटे जो यह दर्शाता हो कि Sleep को ट्रैम्पोलिन (इन-लाइन हुक) किया गया है।
8. Beacon को आगे के संचार की प्रतीक्षा करते हुए सोने देने के लिए मूल ::Sleep को कॉल किया जाता है।
9. Sleep समाप्त होने के बाद, हम बाद के स्लीप के इंटरसेप्शन को सुनिश्चित करने के लिए kernel32!Sleep को फिर से हुक करते हैं।
10. शेलकोड फिर अपना निष्पादन फिर से शुरू करने का प्रयास करता है जिसके परिणामस्वरूप Access Violation उत्पन्न होती है क्योंकि इसके पेज NoAccess के रूप में चिह्नित हैं।
11. हमारा VEH हैंडलर अपवाद को पकड़ता है, डिक्रिप्ट करता है और मेमोरी सुरक्षा को वापस RX में फ्लिप करता है और शेलकोड फिर से शुरू हो जाता है।

---

यह कोई नई तकनीक नहीं है

यह तकनीक बिल्कुल नई नहीं है, कुछ ऐसा नहीं जो मैंने स्वयं गढ़ा हो। यह केवल एक इम्प्लीमेंटेशन है जो अवधारणा और उसके व्यावहारिक उपयोग को दर्शाता है ताकि हमारा ऑफेंसिव सिक्योरिटी समुदाय व्यावसायिक C2 फ्रेमवर्क द्वारा की गई पेशकश को पकड़ सके।

वास्तव में, मुझे कुछ साल पहले Josh Lospinoso के अद्भुत Gargoyle के काम के माध्यम से शेलकोड की मेमोरी प्रोटेक्शन को फ्लिप करने के विचार से परिचित कराया गया था।

यहाँ और पृष्ठभूमि है:

• gargoyle, a memory scanning evasion technique
• Bypassing Memory Scanners with Cobalt Strike and Gargoyle

Gargoyle सेल्फ-अवेयर और सेल्फ-फ्लक्चुएटिंग शेलकोड की अवधारणा को और आगे ले जाता है, VirtualProtect को कॉल करने वाले ROP अनुक्रम का लाभ उठाकर। हालाँकि यह तकनीक प्रभावशाली है, फिर भी Cobalt Strike के Beacon के साथ इसका उपयोग करना उतना ही कठिन है जब तक कि इसके थ्रेड को मारकर और मेमोरी में रहते हुए Beacon को फिर से इनिशियलाइज़ न किया जाए।

यह आदर्श से बहुत दूर है, हालाँकि चूँकि हम पहले से ही अपने स्वयं के सेल्फ-इंजेक्शन लोडर प्रक्रिया के आधार से काम कर रहे हैं, हम उस वातावरण के साथ जो चाहें कर सकते हैं जिसमें शेलकोड संचालित होता है और उसे जैसे चाहें छिपा सकते हैं। यह तकनीक (और पिछली जो ThreadStackSpoofer है) इस तरह से अपने शेलकोड चलाने के फायदे दिखाती है।

PAGE_NOACCESS में फ्लक्चुएट करने का इम्प्लीमेंटेशन ORCA666 के उनके https://github.com/ORCA666/0x41 इंजेक्टर में प्रस्तुत कार्य से प्रेरित है। उन्होंने दिखाया कि:

1. हम एक vectored exception handler (VEH) इनिशियलाइज़ कर सकते हैं,
2. शेलकोड के पेजों को नो-एक्सेस में फ्लिप कर सकते हैं
3. और फिर Access Violation अपवादों को पकड़ सकते हैं जो शेलकोड के अपना निष्पादन फिर से शुरू करते ही उत्पन्न होंगे और उसके मेमोरी पेजों को डिक्रिप्ट करके वापस Read+Execute में फ्लिप कर सकते हैं।

इस इम्प्लीमेंटेशन में यह विचार लागू है, जो <fluctuate> में विकल्प 2 के साथ उपलब्ध है। उनके अन्य प्रोजेक्ट्स भी ज़रूर देखें।

---

डेमो