शेलकोड फ्लक्चुएशन 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 में फ्लिप करते हैं और फिर बाद के स्लीप के इंटरसेप्शन को सुनिश्चित करने के लिए को फिर से हुक करते हैं।

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 के रूप में चिह्नित हैं।

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

यह तकनीक बिल्कुल नई नहीं है, कुछ ऐसा नहीं जो मैंने स्वयं गढ़ा हो। यह केवल एक इम्प्लीमेंटेशन है जो अवधारणा और उसके व्यावहारिक उपयोग को दर्शाता है ताकि हमारा ऑफेंसिव सिक्योरिटी समुदाय व्यावसायिक 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 के साथ उपलब्ध है। उनके अन्य प्रोजेक्ट्स भी ज़रूर देखें।

डेमो

टूल ShellcodeFluctuation तीन पैरामीटर स्वीकार करता है: पहला शेलकोड का पथ और दूसरा हमारी कार्यक्षमता का संशोधक।``` Usage: ShellcodeFluctuation.exe : -1 - Read shellcode but dont inject it. Run in an infinite loop. 0 - Inject the shellcode but don't hook kernel32!Sleep and don't encrypt anything 1 - Inject shellcode and start fluctuating its memory with standard PAGE_READWRITE. 2 - Inject shellcode and start fluctuating its memory with ORCA666's PAGE_NOACCESS.

### Moneta (जाहिरा तौर पर) गलत सकारात्मक```
C:\> ShellcodeFluctuation.exe beacon64.bin -1

तो सबसे पहले हम देखेंगे कि Moneta64 स्कैनर उस प्रोसेस के बारे में क्या सोचता है जो कुछ भी संदिग्ध नहीं करता और केवल एक अनंत लूप चलाने का सहारा लेता है:

जैसा कि हम देख सकते हैं, कुछ गलत सकारात्मक (कम से कम जैसा मैं इसे मानता हूँ) है जो कथित तौर पर Mismatching PEB module / Phantom image का पता लगा रहा है। मेमोरी सीमाएँ स्वयं ShellcodeFluctuate.exe मॉड्यूल की ओर इंगित करती हैं और यह संकेत दे सकती हैं कि यह मॉड्यूल, हालाँकि MEM_IMAGE प्रकार का है, प्रोसेस के PEB में लिंक नहीं है - जो असामान्य है और काफी अजीब लगता है। इस IOC का कारण मुझे ज्ञात नहीं है और मैंने इसे बेहतर ढंग से समझने का प्रयास नहीं किया, फिर भी यह वास्तव में ऐसी चीज़ नहीं है जिसके बारे में हमें चिंतित होना चाहिए।

अगर किसी को इस डिटेक्शन का कारण पता है, तो मैं सुनने के लिए बहुत उत्सुक रहूँगा! कृपया ज़रूर संपर्क करें।

अनएन्क्रिप्टेड बीकन```

C:> ShellcodeFluctuation.exe beacon64.bin 0

दूसरा उपयोग मामला हमारी प्रक्रिया के भीतर कार्यरत एक Beacon के Memory IOCs प्रस्तुत करता है, जो किसी भी प्रकार के अनुकूलित `Artifact Kits`, `User-Defined Reflective Loaders` (जैसे मेरा [`ElusiveMice`](https://github.com/mgeeky/ElusiveMice)) का उपयोग नहीं करता, न ही कोई प्रारंभिक क्रिया जो हमारे परिणामों को खराब करे।

![moneta not encrypted](https://assets.kitploit.com/production/public/readmes/50718/6a4e3a230a362c25da6f4aa6955b822d2a83215848c1bc09566a27ea9db653c9/dd2e0560a688886c0fe06debe92f153e129daa6654cb17c2976edee8661e3bd3-display-v1.webp)

हम देख सकते हैं कि `Moneta64` सही ढंग से `Abnormal private executable memory` को पहचानता है, जो हमारे shellcode के स्थान की ओर इंगित करता है।
यह वास्तव में मजबूत Memory IOC है जो हमारे shellcode को उजागर करता है ताकि स्वचालित स्कैनर्स द्वारा इसे dump और विश्लेषित किया जा सके। अच्छी बात नहीं है।

### RW सुरक्षा के साथ एन्क्रिप्टेड Beacon```
C:\> ShellcodeFluctuation.exe beacon64.bin 1

अब तीसरा उपयोग-मामला, जो इस कार्यान्वयन के परिप्रेक्ष्य से सबसे दिलचस्प है, उतार-चढ़ाव वाला Beacon है।

पहले IOC के अलावा, जिसे कुछ हद तक false positive माना गया था, हम एक नया देखते हैं जो इंगित करता है कि kernel32.dll की मेमोरी संशोधित की गई थी। हालाँकि, इस बार कोई Abnormal private executable memory IOC नहीं है। हमारा उतार-चढ़ाव (बार-बार एन्क्रिप्शन/डिक्रिप्शन और मेमोरी प्रोटेक्शन्स का फ्लिप होना) सक्रिय है।

और रिकॉर्ड के लिए, pe-sieve /data 3 विकल्प के साथ उपयोग किए जाने पर प्रत्यारोपित PE का भी पता लगाता है (जब तक यह विकल्प न दिया जाए, कोई पहचान नहीं की जाएगी):

मेरी वर्तमान धारणा यह है कि PE-Sieve उन्हीं लक्षणों को पहचान रहा है जिन्हें Moneta पहचानता है (नीचे kernel32.dll में संशोधित कोड में वर्णित है) - यह तथ्य कि PE मैप्ड मॉड्यूल का Working set खाली नहीं है, किसी प्रकार के कोड इंजेक्शन का स्पष्ट प्रमाण है। इसे Implanted PE / Implanted के रूप में लेबल किया गया है। यदि ऐसा है, तो निष्कर्ष Moneta के अवलोकन के समान है। मुझे नहीं लगता कि हमें डिटेक्शन के लिहाज से उस IOC के बारे में ज्यादा चिंता करनी चाहिए।

फिलहाल मुझे शेलकोड के निष्पादन को बीच में रोकने के लिए (अब Cobalt Strike की बात कर रहे हैं) kernel32!Sleep को हुक करने के अलावा कोई बेहतर विकल्प नहीं सूझा। इस प्रकार, हम इस तरह के IOC छोड़ने के लिए बाध्य हैं।

लेकिन अरे, फ़ाइलसिस्टम पर पड़े (C:\Windows\System32\kernel32.dll) की तुलना में फिर भी कोई भी बाइट अलग नहीं है और कोई फ़ंक्शन हुक नहीं किया गया है, तो मामला क्या है? 😉

PAGE_NOACCESS प्रोटेक्शन के साथ एन्क्रिप्टेड Beacon```

C:> ShellcodeFluctuation.exe beacon64.bin 2

![no-access](https://assets.kitploit.com/production/public/readmes/50718/03f80df765f37efb3242dce12c613091ab79896e584fbfc2a309a1295c4544c6/327fe5cc3e3ebe6db8277bd091361f7ae42ee4925e21aa87cfa9287b404a1ab5-display-v1.webp)

यह शेलकोड को प्रभावी रूप से `RX` और `NA` पेजों के बीच उतार-चढ़ाव करने का कारण बनेगा।

फिलहाल मुझे यकीन नहीं है कि `PAGE_READWRITE` के बजाय `PAGE_NOACCESS` में फ्लिप करने के क्या लाभ हैं। 


### kernel32.dll में संशोधित कोड

तो उस संशोधित `kernel32` IOC के बारे में क्या?

अब, आइए इस IOC की तह तक जाने की कोशिश करें और देखें कि यहाँ मामला क्या है।

सबसे पहले, हम उल्लिखित मेमोरी क्षेत्र को डंप करेंगे - जो `kernel32.dll` का `.text` (कोड) सेक्शन है। इस उद्देश्य के लिए आइए `ProcessHacker` का उपयोग करें ताकि सार्वजनिक रूप से ज्ञात और स्थिर टूलिंग का लाभ उठा सकें:

![dump-kernel](https://assets.kitploit.com/production/public/readmes/50718/0b1a4700514b15ec5199ead8f09ccd7c4e5fefc2302a9a9eee0d4e6d77ea48b4/bae9be0ce4bdcede99f235f42431b159bbbf35539f36fe58906fe991e4aacdb4-display-v1.webp)

हम कथित रूप से संशोधित kernel32 के कोड सेक्शन को डंप करते हैं और फिर उस प्रक्रिया में चल रहे kernel32 के लिए भी ऐसा ही करते हैं जिसने उस क्षेत्र को संशोधित नहीं किया।

दो डंप प्राप्त करने के बाद, हम उनकी तुलना बाइट-वार (मेरे [expdevBadChars](https://github.com/mgeeky/expdevBadChars) का उपयोग करके) कर सकते हैं ताकि कोई असंगतियाँ पता चल सकें:

![bindiff](https://assets.kitploit.com/production/public/readmes/50718/4df33e426c7d23554953e2117e3706ee9af1b53b3dd4a60f7b05bcabb988bc85/3db05a8375ded834d576d29083dab9b646cbd83b791a591717fbe0e56ca9a64e-display-v1.webp)

बस यह देखने के लिए कि वे एक-दूसरे से मेल खाते हैं। स्पष्ट रूप से `kernel32.dll` में एक भी बाइट संशोधित नहीं है और इसका कारण यह है कि हम `kernel32!Sleep` को कॉल करने से पहले उसे अनहुक (unhook) कर रहे हैं:

`main.cpp:31:````
    HookTrampolineBuffers buffers = { 0 };
    buffers.originalBytes = g_hookedSleep.sleepStub;
    buffers.originalBytesSize = sizeof(g_hookedSleep.sleepStub);

    //
    // Unhook kernel32!Sleep to evade hooked Sleep IOC. 
    // We leverage the fact that the return address left on the stack will make the thread
    // get back to our handler anyway.
    //
    fastTrampoline(false, (BYTE*)::Sleep, &MySleep, &buffers);

    // Perform sleep emulating originally hooked functionality.
    ::Sleep(dwMilliseconds);

तो IOC ट्रिगर होने का कारण क्या है? आइए Moneta का और करीब से निरीक्षण करें:

Moneta के Ioc.cpp में लगभग 104वीं पंक्ति के आसपास, जहाँ यह MODIFIED_CODE IOC रिपोर्ट करता है, हम कोड में थोड़ा बदलाव कर सकते हैं ताकि kernel32 पूल का विश्लेषण करते समय का सटीक क्षण बेहतर ढंग से उजागर हो सके। अब:

1. यह जाँच की जाती है कि kernel32 का क्षेत्र executable है। हम देखते हैं कि वास्तव में वह क्षेत्र executable है a = true
2. उस मॉड्यूल की private मेमोरी की मात्रा प्राप्त की जाती है। यहाँ हम देखते हैं कि kernel32 के पास b = 0x1000 private बाइट्स हैं। यह कैसे? इनकी संख्या 0 होनी चाहिए।
3. यदि executable आवंटन में 0 से अधिक बाइट्स private मेमोरी हैं (a && b), तो IOC रिपोर्ट किया जाता है
4. और यही प्रमाण है कि हम उस समय kernel32 की जाँच कर रहे थे।

जब Windows Image Loader किसी DLL मॉड्यूल को प्रोसेस की मेमोरी स्पेस में मैप करता है, तो अंतर्निहित मेमोरी पेजों को परिदृश्य के आधार पर MEM_MAPPED या MEM_IMAGE के रूप में लेबल किया जाएगा। जब भी हम MEM_MAPPED/MEM_IMAGE आवंटन के एक भी बाइट को संशोधित करते हैं, सिस्टम एक एकल मेमोरी पेज को अलग कर देगा (यह मानते हुए कि हमने PAGE_SIZE बाइट्स से कम संशोधित किया है और पेज सीमा पार नहीं की है) ताकि उस खंड को इंगित किया जा सके जो मूल इमेज में वापस मैप नहीं होता है।

इस अवलोकन को फिर एक IOC के रूप में उपयोग किया जाता है - एक इमेज के मेमोरी क्षेत्र के भीतर MEM_PRIVATE आवंटन नहीं होने चाहिए, क्योंकि यह संकेत देगा कि उस क्षेत्र में कुछ बाइट्स कभी संशोधित की गई थीं। Moneta कोड संशोधन को सही ढंग से पकड़ रहा है, भले ही तुलना के समय बाइट्स मूल मॉड्यूल के बाइट्स से मेल खा रहे हों।

Moneta, प्रोसेस इंजेक्शन कार्यान्वयन और संबंधित IOC अंदरूनी रूप से कैसे काम करते हैं, इसकी व्यापक व्याख्या के लिए Forrest Orr द्वारा लिखे गए निम्नलिखित उच्च-गुणवत्ता वाले लेख पढ़ें:

1. Masking Malicious Memory Artifacts – Part I: Phantom DLL Hollowing
2. Masking Malicious Memory Artifacts – Part II: Blending in with False Positives
3. Masking Malicious Memory Artifacts – Part III: Bypassing Defensive Scanners

यह वास्तव में Forrest द्वारा किया गया उत्कृष्ट शोध और दस्तावेज़ीकरण है, शानदार काम दोस्त!

विशेष रूप से दूसरा लेख इस डिटेक्शन का औचित्य बताता है, जैसा कि हम पढ़ते हैं कि Forrest हमें क्या सिखाता है:

इस स्थिति में कि मॉड्यूल को वैध रूप से लोड करके PEB में जोड़ दिया गया होता, फिर भी shellcode इम्प्लांट का पता चल जाता, क्योंकि 0x1000 बाइट्स (1 पेज) मेमोरी निजी रूप से एड्रेस स्पेस में मैप की गई थी और Moneta द्वारा उसके वर्किंग सेट को क्वेरी करके प्राप्त की गई थी - जिसके परिणामस्वरूप ऊपर देखे गए modified code IOC जैसा ही संशोधित कोड IOC बना।

संक्षेप में, हम एक IOC पीछे छोड़ रहे हैं, लेकिन क्या हमें इसके बारे में चिंतित होना चाहिए? भले ही एक IOC मौजूद हो, वहाँ कोई चोरी हुई बाइट्स दिखाई नहीं देतीं, इसलिए हमारे shellcode की ओर इशारा करने वाला या हमारे shellcode की तकनीक को अन्य से अलग करने वाला कोई तत्काल संदर्भ नहीं है।

लंबी कहानी छोटी करके कहें तो - हमें वास्तव में उस IOC के बारे में चिंतित नहीं होना चाहिए। :-)

लेकिन व्यावसायिक फ्रेमवर्क कोई IOC नहीं छोड़ते

कोई कह सकता है कि यह कार्यान्वयन परिपूर्ण से बहुत दूर है क्योंकि यह कुछ छोड़ता है, फिर भी IOCs मौजूद हैं और व्यावसायिक उत्पाद दिखाते हैं कि उनमें समान विशेषताएँ नहीं हैं।

जब यह तर्क मेज़ पर आता है, मुझे याद दिलाना आवश्यक है कि व्यावसायिक फ्रेमवर्क के पास अपने implants और shellcode लोडर के स्रोत कोड पर पूर्ण नियंत्रण होता है, और इस प्रकार वे एक को दूसरे के साथ अच्छी तरह एकीकृत कर सकते हैं ताकि खुद अपने shellcode को हुक करने और उसके साथ छेड़छाड़ करने की आवश्यकता से बच सकें। यहाँ, हमें kernel32!Sleep को हुक करना आवश्यक है ताकि Cobalt Strike के Beacon के सोने से ठीक पहले उसके निष्पादन को रोका जा सके और हमारी housekeeping शुरू हो सके। यदि हमारे लिए sleep को हुक किए बिना काम शुरू करने का कोई बेहतर तंत्र होता - तो यह परिपूर्ण होता।

हालाँकि Cobalt Strike में Sleep Mask की अवधारणा पेश की गई है, आकार की सीमाएँ सैकड़ों बाइट्स होने के कारण हमें इस तर्क को स्वयं mask में शामिल करने से पूरी तरह असमर्थ बनाती हैं (अन्यथा हम Sleep को भी हुक न कर पाते, जैसे व्यावसायिक उत्पाद करते हैं, कोई IOC नहीं छोड़ते)।

एक और तर्क हो सकता है कि व्यावसायिक फ्रेमवर्क इस प्रकार के तर्क को अपने Reflective Loaders में एकीकृत करते हैं और यहाँ हम इसके बजाय इसे EXE हैर्नेस में छोड़ देते हैं। यह सच है, लेकिन इस निर्णय का कारण दोहरा है:

1. मुझे इस प्रकार की तकनीक को जारी करने में बहुत सावधानी बरतने की आवश्यकता है, ताकि वास्तविक दुनिया के अपराधियों को एक ऐसे कार्यान्वयन से हथियार बनाने में मदद करने का जोखिम न हो, जो किसी और Petya के रूप में हमारा पीछा करे। उसी तरह, मैंने कुछ रुग्ण विवरणों को छोड़ने का निर्णय लिया, जिनका उपयोग मैं अपने व्यावसायिक, अनुबंधित Adversary Simulation अभ्यासों को पहुँचाने के लिए उपयोग किए जाने वाले पेशेवर टूलिंग में करता हूँ। बीज को बाहर देने की उम्मीद है कि समुदाय के पेशेवर इसे अपने स्वयं के टूलिंग में विकसित करने में सक्षम होंगे, यह मानते हुए कि उनके पास उपयुक्त कौशल होगा।

2. मैं इस पूरे तर्क को Cobalt Strike के User-Defined Reflective Loader में स्थानांतरित करना कहीं अधिक पसंद करूँगा, जिससे Red Team समूहों को उनके डिलीवरी चरण में बढ़े हुए अवसर मिलेंगे। लेकिन पहले, बिंदु (1) देखें, दूसरे, वह तकनीक वर्तमान में उनके RDLL के लिए 5KB आकार तक सीमित है, जिससे मैं वहाँ भी इसे लागू करने में पूरी तरह असमर्थ हूँ। हममें से जो इन-हाउस Adversary Simulation परियोजनाओं के लिए कस्टम C2 और implants बनाते हैं - उन्हें अब एक नमूना कार्यान्वयन प्राप्त हुआ है जो निश्चित रूप से उनके टूलिंग को तदनुसार सुधारने में मदद करेगा।

मैं इसका उपयोग कैसे करूँ?

कोड और उसके कार्यान्वयन को देखें, अवधारणा को समझें और इस अवधारणा को अपने स्वयं के Shellcode Loaders के भीतर पुनः लागू करें, जिनका उपयोग आप अपने Red Team अभियानों को पहुँचाने के लिए करते हैं। यह उन्नत in-memory evasion की एक और तकनीक है जो आपकी टीमों की एंटी-वायरस, EDR और Malware Analysts द्वारा आपके implants की जाँच किए जाने से बचने की संभावनाओं को बढ़ाती है।

अपने उन्नत shellcode लोडर को विकसित करते समय, आप यह भी लागू करना चाह सकते हैं:

• Process Heap Encryption - इस ब्लॉग पोस्ट से प्रेरणा लें: Hook Heaps and Live Free - जो आपको BeaconEye जैसे Beacon कॉन्फ़िगरेशन निकालने वाले टूल से बचने में मदद कर सकता है
• सोने से पहले अपने थ्रेड के कॉल स्टैक को स्पूफ करें (यह उन स्कैनरों से बच सकता है जो प्रोसेस के थ्रेड्स और उनके कॉल स्टैक्स की जाँच करने का प्रयास करते हैं, ताकि इन थ्रेड्स द्वारा संदर्भित MEM_PRIVATE मेमोरी आवंटन की खोज की जा सके)
• Reflective Loader से बचे किसी भी अवशेष को साफ़ करें ताकि in-memory सिग्नेचर-आधारित डिटेक्शन से बचा जा सके
• सोने से पहले उन सभी चीज़ों को अनहुक करें जिन्हें आपने हुक किया हो सकता है (जैसे AMSI, ETW, WLDP) और बाद में फिर से हुक करें।

उदाहरण रन

उपयोग का मामला:``` Usage: ShellcodeFluctuation.exe : -1 - Read shellcode but dont inject it. Run in an infinite loop. 0 - Inject the shellcode but don't hook kernel32!Sleep and don't encrypt anything 1 - Inject shellcode and start fluctuating its memory with standard PAGE_READWRITE. 2 - Inject shellcode and start fluctuating its memory with ORCA666's PAGE_NOACCESS.

जहाँ:
- `<shellcode>` शेलकोड फ़ाइल का पथ है
- `<fluctuate>` जैसा ऊपर वर्णित है, `-1`, `0` या `1` लेता है


बीकन के थ्रेड कॉल स्टैक को स्पूफ करने वाला उदाहरण रन:```
C:\> ShellcodeFluctuation.exe ..\..\tests\beacon64.bin 1

[.] Reading shellcode bytes...
[.] Hooking kernel32!Sleep...
[.] Injecting shellcode...
[+] Shellcode is now running. PID = 9456
[+] Fluctuation initialized.
    Shellcode resides at 0x000002210C091000 and occupies 176128 bytes. XOR32 key: 0x1e602f0d
[>] Flipped to RW. Encoding...

===> MySleep(5000)

[.] Decoding...
[>] Flipped to RX.
[>] Flipped to RW. Encoding...

===> MySleep(5000)

सावधानी

यदि आप इस कार्यक्षमता को अपने स्वयं के शेलकोड लोडर / टूलिंग में जोड़ने की योजना बना रहे हैं, तो kernel32.dll को अनहुक करने से बचें। kernel32 को अनहुक करने का प्रयास मूल Sleep कार्यक्षमता को बहाल कर देगा, जिससे हमारा कॉलबैक कॉल नहीं हो पाएगा। यदि हमारा कॉलबैक कॉल नहीं होता है, तो थ्रेड स्वयं अपने कॉल स्टैक को स्पूफ नहीं कर पाएगा।

यदि आप वास्तव में यही चाहते हैं, तो आपको एक और वॉचडॉग थ्रेड चलाने की आवश्यकता हो सकती है, यह सुनिश्चित करते हुए कि जब भी Beacons थ्रेड सोता है, उसका कॉल स्टैक स्पूफ हो जाए।

यदि आप Cobalt Strike और Raphael's Mudge द्वारा बनाए गए BOF unhook-bof का उपयोग कर रहे हैं, तो मेरे Pull Request को ज़रूर देखें, जो BOF में एक वैकल्पिक पैरामीटर जोड़ता है, जो उन लाइब्रेरियों को निर्दिष्ट करता है जिन्हें अनहुक नहीं किया जाना चाहिए।

इस तरह आप kernel32 में अपने हुक को बनाए रख सकते हैं:

---``` beacon> unhook kernel32 [*] Running unhook. Will skip these modules: wmp.dll, kernel32.dll [+] host called home, sent: 9475 bytes [+] received output: ntdll.dll <.text> Unhook is done.

[संशोधित `unhook-bof` जिसमें निर्दिष्ट मॉड्यूल को अनदेखा करने का विकल्प है](https://github.com/mgeeky/unhook-bof)

---

## अंतिम टिप्पणी

यह PoC Cobalt Strike के Beacon shellcodes के साथ काम करने के लिए डिज़ाइन किया गया था। Beacon अपने C2 से आगे के निर्देशों की प्रतीक्षा करने के लिए `kernel32!Sleep` को कॉल करने के लिए जाना जाता है। 
यह loader इस तथ्य का लाभ उठाता है कि वह अपने housekeeping को करने के लिए `Sleep` को hook करता है।

यह कार्यान्वयन बाजार में मौजूद अन्य shellcodes (जैसे _Meterpreter_) के साथ काम नहीं कर सकता है यदि वे ठंडा होने के लिए `Sleep` का उपयोग नहीं करते हैं। 
चूँकि यह केवल एक _Proof of Concept_ है जो तकनीक को दर्शाता है, मैं किसी अन्य C2 framework के लिए समर्थन जोड़ने का इरादा नहीं रखता।

जब आप अवधारणा को समझ जाते हैं, तो निश्चित रूप से आप इसे अपनी shellcode आवश्यकताओं में ढालने और समाधान को अपने लाभ के लिए अनुकूलित करने में सक्षम होंगे।

कृपया Github issues न खोलें जो "यह कोड XYZ shellcode के साथ काम नहीं करता" से संबंधित हों, उन्हें तुरंत बंद कर दिया जाएगा।

---

### ☕ समर्थन दिखाएँ ☕

यह और अन्य प्रोजेक्ट नींद हीन रातों और **काफी मेहनत** का परिणाम हैं। अगर आपको मेरा काम पसंद है और आप सराहना करते हैं कि मैं हमेशा समुदाय को वापस देता हूँ,
[मुझे कॉफी खरीदने पर विचार करें](https://github.com/sponsors/mgeeky) _(या बेहतर होगा एक बियर)_ बस धन्यवाद कहने के लिए! 💪

---

## लेखक```   
   Mariusz Banach / mgeeky, 21
   <mb [at] binary-offensive.com>
   (https://github.com/mgeeky)