spiralbl0ck/blacklotus-z2a-challengeBlackLotus-Z2A-Challenge, Nothing to see here 4 now , please move along
BlackLotus-Z2A-Challenge, यहाँ अभी के लिए देखने को कुछ नहीं है , कृपया आगे बढ़ें
सबसे पहले
केवल सौंदर्य प्रयोजनों के लिए, मैं @darthmaulware(Ryan “DM” Smith) के समाधान से yara डिटेक्शन नियम बेशर्मी से उधार(चुरा) लूँगा :)) ताकि इसे पेशेवर दिखाया जा सके। जाकर उनका ट्विटर देखिए वे बहुत ही शानदार इंसान हैं! Ps. Ryan कृपया नाराज़ न हों क्योंकि मैंने वो चुराया है :))) और Discord में समर्थन के लिए धन्यवाद :)
कृपया उनका काम भी देखें :)
https://gitlab.com/malre-rcs/zero2automated/-/blob/main/solutions/bi_weekly_challenge/BlackLotus_20230321/BlackLotus_HTTP_Downloader.ipynb``` rule Blacklotus_HTTP_Downloader { meta: description = "Rule to detect Blacklotus HTTP Downloader" author = "Darth Maulware" sha256 = "d68f668b4240f9518e4f80499d93d8c5a1eddece0771658c33ae916cc54f5a66"
strings:
$opcode1 = {48 89 4C 24 08 48 89 54 24 10 4C}
$opcode2 = {89 44 24 18 4C 89 4C 24 20 48 83}
$opcode3 = {EC 28 B9 31 62 D7 2E 90 90 E8 ??}
$opcode4 = {?? ?? ?? 48 83 C4 28 48 8B 4C 24}
$opcode5 = {08 48 8B 54 24 10 4C 8B 44 24 18}
$opcode6 = {4C 8B 4C 24 20 4C 8B D1 90 90}
condition:
(uint16(0) == 0x5a4d and filesize < 500KB and all of them)
}
इसके अलावा, सौंदर्य संबंधी कारणों से मैं इसे भी चुरा लूंगा क्योंकि यह अच्छा लगता है :) फिर से माफ़ करना रयान, कृपया मुझ पर गुस्सा मत करना :)```
C:\\Users\\REM\\Desktop>capa.exe -f pe -r capa-rules-5.0.0 d68f668b4240f9518e4f80499d93d8c5a1eddece0771658c33ae916cc54f5a66.exe
matching: 100%|████████| 124/124 [00:02<00:00, 46.96 functions/s, skipped 1 library functions (0%)]
+------------------------+------------------------------------------------------------------------------------+
| ATT&CK Tactic | ATT&CK Technique |
|------------------------+------------------------------------------------------------------------------------|
| DEFENSE EVASION | Obfuscated Files or Information T1027 |
| DISCOVERY | Process Discovery T1057 |
| EXECUTION | Shared Modules T1129 |
+------------------------+------------------------------------------------------------------------------------+
+-----------------------------+-------------------------------------------------------------------------------+
| MBC Objective | MBC Behavior |
|-----------------------------+-------------------------------------------------------------------------------|
| ANTI-BEHAVIORAL ANALYSIS | Debugger Detection::Process Environment Block BeingDebugged [B0001.035] |
| | Debugger Detection::Process Environment Block NtGlobalFlag [B0001.036] |
| CRYPTOGRAPHY | Encrypt Data::RC4 [C0027.009] |
| | Generate Pseudo-random Sequence::RC4 PRGA [C0021.004] |
| DATA | Encode Data::XOR [C0026.002] |
| DEFENSE EVASION | Obfuscated Files or Information::Encoding-Standard Algorithm [E1027.m02] |
+-----------------------------+-------------------------------------------------------------------------------+
+------------------------------------------------------+------------------------------------------------------+
| CAPABILITY | NAMESPACE |
|------------------------------------------------------+------------------------------------------------------|
| execute syscall instruction (35 matches) | anti-analysis |
| check for PEB BeingDebugged flag (2 matches) | anti-analysis/anti-debugging/debugger-detection |
| check for PEB NtGlobalFlag flag | anti-analysis/anti-debugging/debugger-detection |
| encode data using XOR (2 matches) | data-manipulation/encoding/xor |
| encrypt data using RC4 PRGA (2 matches) | data-manipulation/encryption/rc4 |
| get process heap flags | host-interaction/process |
| get ntdll base address (3 matches) | linking/runtime-linking |
| parse PE header (2 matches) | load-code/pe |
| resolve function by parsing PE exports (2 matches) | load-code/pe |
+------------------------------------------------------+------------------------------------------------------+
सच कहूँ तो अगर मैं तुम्हारी जगह होता तो मैं 100% capa पर भरोसा नहीं करता (कम से कम इस विशेष मामले में) क्योंकि यहाँ यह कहता है कि सैंपल rc4 इस्तेमाल करता है जबकि असल में सैंपल aes इस्तेमाल करता है लेकिन जो भी हो, जैसा कि बताया गया है यह पूरी तरह से सौंदर्य के लिए है :)
शुरू करने से पहले, इस रिपोर्ट के दौरान आपको बहुत सारे
कृपया इसे अनदेखा करें क्योंकि ida इसे असेंबली में ठीक से डिसअसेम्बल नहीं कर पाता, यह है
और यह डीबगर को क्रैश कर देता है? क्यों?
क्योंकि यह एड्रेस 0 पर लिखने की कोशिश करता है, जिसे हैकर लोककथा में नल पॉइंटर एड्रेस पर लिखना कहा जाता है, जिसका व्यापक रूप से CE (code execution) पाने के लिए शोषण किया जाता था, और इसे स्पष्ट रूप से mitigate कर दिया गया है।
और ऐसे में वर्तमान mitigation के साथ, यदि आप 0 पर लिखने की कोशिश करते हैं तो यह उस प्रक्रिया को क्रैश कर देगा, हमारे मामले में मालवेयर और परिणामस्वरूप डीबगर को।
अब यदि हम इसे ida में खोलते हैं
मैंने हर फ़ंक्शन का नाम बदल दिया है ताकि यह संकेत मिले कि वह कुछ लॉजिक करता है, चलिए पहले फ़ंक्शन do_syscall() से शुरू करते हैं।
हम तुरंत syscalls के उपयोग को नोटिस करते हैं, जो कि डायनेमिक विश्लेषण के दौरान एक विश्लेषक का जीवन कठिन बनाने का एक जाना-माना तरीका है।
जो लोग विंडोज़ में syscalls से परिचित नहीं हैं, उनके लिए oalabs द्वारा बनाया गया एक बढ़िया वीडियो यहाँ है (https://www.youtube.com/watch?v=Uba3SQH2jNE)। कृपया इसे देखें क्योंकि मैंने भी देखा था और इसने इस फ़ंक्शन में क्या होता है यह समझने में मेरी बहुत मदद की।
यदि हम ida द्वारा तैयार किए गए "pseudo-code" का निरीक्षण करें, तो हम देखते हैं कि यह ऐसा दिखता है
यदि हम statically solve_hash का निरीक्षण करें तो यह ऐसा दिखता है
pseudo-परिप्रेक्ष्य से यह ऐसा दिखता है
कृपया solve_hash.py देखें, जहाँ मेरी इसकी "emulation" है, यदि आप स्वचालन का एक टुकड़ा देखना चाहते हैं और जानना चाहते हैं कि syscalls hasing lookup algorithm द्वारा कैसे resolve होते हैं। लेकिन फिर भी, यह SysWhispers2 नामक प्रोजेक्ट का हिस्सा है या कम से कम मुझे लगता है कि मालवेयर के लेखकों ने इसे प्रेरणा के रूप में इस्तेमाल किया। फिर भी बेहतर समझ के लिए कृपया ऊपर दिए गए oalabs वीडियो क्लिप को देखें।
खैर, anti_debug फ़ंक्शन आसानी से बायपास करने योग्य है और यह अच्छी तरह से जाना जाता है (https://anti-debug.checkpoint.com/techniques/debug-flags.html#manual-checks-ntglobalflag)। इसे बायपास करने का तरीका है scyllahide इंस्टॉल होना और NtGlobalFlag चेक होना (जो कि आपके पास डिफ़ॉल्ट रूप से चालू होना चाहिए यदि आप x86dbg उपयोग करते हैं)। फिर भी यह है जो आपको जाँचना चाहिए
और इस तरह दिखता है anti-debug "pseudo-function"
मेरी राय में काफी सरल है।
Next we have check_inmemory_ldr function which looks like this
अब फ़ंक्शन विश्लेषण के प्रयोजन के लिए, यदि हम x86dbg से विनम्रता से पूछें, तो हम देख सकते हैं कि यदि हम syscall निर्देश तक चलाते हैं तो x86dbg हमें वह syscall लौटाने की कृपा करेगा जिसे निष्पादित किया जाने वाला है। हमारे मामले में
अब वर्तमान संदर्भ के आधार पर हम अनुमान लगा सकते हैं कि Ntsetinformationthread किसी प्रकार की anti-analysis चाल के रूप में उपयोग किया जा रहा है। निश्चित रूप से, यदि हम त्वरित Google खोज करते हैं तो हमें यह मिल जाता है https://ntquery.wordpress.com/tag/ntqueryinformationthread/
सौभाग्य से आसानी से बायपास करने योग्य, बस nop+ret से patch कर दो :)
=============================================================================
निष्पादन क्रम के अनुसार इसके बाद अगला फ़ंक्शन है
फिर से, यदि हम देखें कि यह क्या करता है
यह केवल teb में एक फ्लैग जाँचता है कि क्या वर्तमान प्रक्रिया (हमारे मामले में exe) को डीबग किया जा रहा है। यह फिर से आसानी से बायपास करने योग्य है क्योंकि यह एक ज्ञात तरीका है (https://anti-debug.checkpoint.com/techniques/debug-flags.html#manual-checks-peb-beingdebugged-flag), उसी तरह जैसे हमने scyllahide का उपयोग किया, इस बार आपको यह चेक किया होना चाहिए
जो डिफ़ॉल्ट रूप से चालू होना चाहिए
=============================================================================
अब custom_hash2_and_aplib_possible, जो ऐसा दिखता है
और ग्राफ़ के दृष्टिकोण से
कृपया इस फ़ंक्शन की "emulation" देखने के लिए decompress_aplib.py देखें।
get_ntdll_and_unhook2 का पता लगाने पर, यह ऐसा दिखता है
ग्राफ़ दृश्य से यह ऐसा दिखता है
काफी अच्छा है :))
थोड़ा पीछे जाएँ तो हमारे पास aplib_decompress है, अब यह ऐसा दिखता है
स्टैटिक कोड विश्लेषण से यह ऐसा दिखता है
हम्म, थोड़ा बड़ा है, लेकिन यहाँ चिंता की कोई बात नहीं दोस्तों, यह करने योग्य है :)
यदि आप aplib_decompress.py emulation स्क्रिप्ट का उपयोग करते हैं, तो आपको कुछ ऐसा मिलेगा
एक अच्छी बात जो मैंने अन्य ब्लॉग/विश्लेषणों में नहीं देखी थी, वह यह है: यदि हम ntdll_and_unhook2 के लिए ida के pseudo code पर फिर से नज़र डालें
आपको एक दिलचस्प memcpy दिखाई देगी
एक समय जब मैं डायनेमिक विश्लेषण कर रहा था, मैंने देखा कि एक और dll लोड हो रही थी, जो ntdll का एक और संस्करण थी
यदि हम डीबगर में देखें तो यह ऐसा दिखता है
मैं यह पता नहीं लगा सका कि क्या hook/पैच किया गया था, लेकिन यदि किसी को पता है तो कृपया एक pull request करें और इस दस्तावेज़ को संपादित करें। साथ ही, यह जानने के प्रयास में कि क्या hook होता है, मैंने दोनों ntdll के बीच bindiff करने की कोशिश की और दुर्भाग्य से मुझे कुछ नहीं मिला, लेकिन यह इसलिए हो सकता है क्योंकि मैं पहले से ही संक्रमित system dll पर diff कर रहा था, इसलिए एक स्वच्छ रन नहीं था, शायद इसलिए ¯_(ツ)_/¯
=============================================================================
विश्लेषण प्रक्रिया में आगे बढ़ते हुए, अस्पष्टीकृत फ़ंक्शनों में हमारे पास some_hasing और ntquertyinformationprocess_anti_debug हैं, जिन्हें समझाया नहीं गया है। check_if_being_debug_through_teb और anti_debug को पहले ही समझाया जा चुका है, सौभाग्य से, क्योंकि वे ऊपर वाले फ़ंक्शन/फ़ंक्शनों में उपयोग किए गए थे, इसलिए यदि आप उनके बारे में ज्ञान दोहराना चाहते हैं तो कृपया ऊपर के अनुभाग पढ़ें। मैं पहले ntquertyinformationprocess_anti_debug से शुरू करना चाहूँगा और बाद में some_hasing के साथ समाप्त करूँगा।
इसका निरीक्षण करने पर हम देखते हैं कि एक ही फ़ंक्शन को 3 बार कॉल किया गया है।
और असेंबली के दृष्टिकोण से
सुविधा के लिए मैंने पहले ही इसका नाम रख दिया है, जो ntquertyinformationprocess_ProcessDebugPort है। मुझे कैसे पता चला कि जो फ़ंक्शन कॉल किए गए थे वे ntquertyinformationprocess_ProcessDebugPort थे? उनका निरीक्षण करने पर एक पहले से देखा गया फ़ंक्शन कॉल/ज्ञात एल्गोरिदम हमें दिखाई देता है
ida में की गई टिप्पणियों के बारे में क्या? खैर, यदि आप Google पर ntqueryinformationprocess खोजते हैं तो हमें anti debugging के बारे में एक अच्छा संसाधन मिलता है (https://anti-debug.checkpoint.com/techniques/debug-flags.html)। यदि हम साथ चलें तो हम देख सकते हैं कि यह हमें समझाता है कि इस फ़ंक्शन में पैरामीटर के रूप में पारित कुछ मानों के आधार पर इसे anti-debugging विधि के रूप में उपयोग किया जा सकता है।
उदाहरण के लिए, पहले कॉल के लिए हम डीबगर में निम्नलिखित स्टैक तर्क देख सकते हैं
यदि हम अब ntqueryinformationprocess के लिए msdn पृष्ठ देखें
अगले दो syscalls के लिए भी यही प्रक्रिया दोहराई जाती है
जिसमें 0x1e ProcessDebugObjectHandle anti-debug विधि के लिए विशिष्ट है (https://www.apriorit.com/dev-blog/367-anti-reverse-engineering-protection-techniques-to-use-before-releasing-software)
और अंत में ProcessDebugFlags
तो हम इन्हें कैसे बायपास करें?! शांत हो जाओ दोस्तों, क्योंकि ScyllaHide का साथ है
जैसा कि आप देख सकते हैं
तो हम सुरक्षित हैं! काफी नहीं, जबकि ScyllaHide पहले 2 syscalls के लिए हमारी मदद करता है, आखिरी syscall के लिए हमें इसे मैन्युअल रूप से करना होगा! और मैं क्या करूँ??? खैर सरल समाधान! हम इस फ़ंक्शन से लौट आते हैं, यानी पूरे ntquertyinformationprocess_anti_debug से, और eax को 0 पर सेट कर देते हैं। तो सामान्य परिस्थितियों में यह ऐसा दिखता है
और हमारी "मदद" के साथ यह ऐसा दिखता है और हम सुरक्षित रूप से निष्पादन को आगे बढ़ने देते हैं :)
=============================================================================
अब some_hasing, आप तरीका पहले से जानते हैं
और अब pseudo-code
हम यहाँ एक अजीब चीज़ देखते हैं। ida का pseudo-code यहाँ विफल हो जाता है... क्योंकि यदि हम call_syscall के बाद ग्राफ़ का अनुसरण करते हैं, तो डिसअसेम्बल करने के लिए और भी निर्देश हैं। तो अब हम यहाँ क्या करें? खैर, हम इस कोड का डायनेमिक रूप से विश्लेषण करने के लिए यहाँ डीबगर पर भरोसा करेंगे...
तो हम देखते हैं कि यह जो syscall करता है वह है
अब यदि हम ntquerydefaultlocale देखें, Google दिखाता है कि यह एक अप्रलेखित (undocumented) api है जो 2 तर्क लेता है (http://undocumented.ntinternals.net/index.html?page=UserMode%2FUndocumented%20Functions%2FLocale%2FNtQueryDefaultLocale.html)। बढ़िया, तो यह क्या करता है? यह वर्तमान Locale Identifier लौटाता है। बढ़िया, तो Locale Identifier आखिर क्या है? msdn (https://learn.microsoft.com/en-us/windows/win32/intl/locale-identifiers) के अनुसार यह एक 32-बिट मान है जिसमें भाषा पहचानकर्ता और सॉर्ट ऑर्डर पहचानकर्ता होता है। tl;dr के तौर पर, आप उस पीसी पर कौन सी भाषा बोलते हैं :)
इसके बाद यह जाँचता है कि api निष्पादित करने में विफल तो नहीं हुई, और यदि यह विफल नहीं हुई तो यह ntquerydefaultlocale द्वारा लौटाए गए मान को लेता है, 0x419 घटाता है, और इसकी तुलना 0x26 (संभवतः एक स्थिरांक) से करता है, जैसा कि आप नीचे चित्र में देख सकते हैं।
यदि यह 0x26 से छोटा या उसके बराबर नहीं है, तो यह 0x818 से तुलना करता है, अन्यथा वही तुलना 0x819 के साथ करता है, जैसा कि आप स्पष्ट रूप से देख सकते हैं
तो यहाँ क्या हो रहा है? और ये विशेष स्थिरांक क्यों? खैर, मैं सीधे मुद्दे पर आता हूँ। विभिन्न स्थिरांकों की खोज करते समय मुझे यह लेख मिला (https://www.cnblogs.com/DirWang/p/17281690.html#autoid-8-0-0), एक शोधकर्ता जिसने blacklotus का विश्लेषण मुझसे बेहतर तरीके से किया है। और जैसा कि किसी ने एक बार कहा था: "आप मालवेयर विश्लेषण में धोखा नहीं दे सकते, आप केवल अपना काम आसान बना सकते हैं"। तो शोधकर्ता ने जो कहा वह यह है कि मूल रूप से यह फ़ंक्शन विशेष स्थिरांकों की जाँच करता है जो पहचानते हैं कि कंप्यूटर पर कौन सी भाषा बोली जाती है। अपने लेख में वह इसका लिंक प्रदान करता है (https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-LCID/[MS-LCID].pdf), जो माइक्रोसॉफ्ट से प्रत्येक भाषा पहचानकर्ता के साथ एक मानक दस्तावेज़ जैसा है।
अब अपने hax00r l33t तर्क का उपयोग करके हम अनुमान लगा सकते हैं कि संभवतः 0x26 एक ऑफसेट की तरह उपयोग किया जाता है, यानी 0x419 के बाद अगले 0x26 भाषा पहचानकर्ता, जो हैं
यदि हम उस दस्तावेज़ का भी निरीक्षण करें, तो हम देख सकते हैं कि 0x818 निम्न से मेल खाता है
और 0x819 निम्न से
और हम पिछली "जाँचों"/ऑनलाइन रिपोर्टों से जानते हैं कि यह मालवेयर दुनिया के कुछ क्षेत्रों के कुछ पीसी पर नहीं चलता था, इसलिए हम यह निष्कर्ष निकाल सकते हैं कि यह फ़ंक्शन यह देखने के लिए जाँच करता है कि संक्रमित मशीन किस क्षेत्र में है।
=============================================================================
अब तक काफी पागलपन है दोस्तों, आगे क्या? हम some_more_syscall फ़ंक्शन परोसते हैं। ठीक है! तो तुम्हारे पास क्या है! यह रहा
हमें और चाहिए! बिल्कुल दोस्त!
हम्म्म
तो जाँच करता है कि kerneldebugger मौजूद है या नहीं (https://www.geoffchappell.com/studies/windows/km/ntoskrnl/inc/api/ntexapi/system_information_class.htm) (0x23), चेकी चेकी!
तो क्या! हमें pcr मिल गया (piles and combinations party)
=============================================================================
अब यदि हम iterate_over_modules() फ़ंक्शन का निरीक्षण करें तो यह ऐसा दिखता है
"pseudo-code" परिप्रेक्ष्य से यह ऐसा दिखता है
एक स्वतंत्र दृष्टिकोण से ऐसा लगता है कि असेंबली और ida का pseudo-code मेल खाते हैं, तो इस फ़ंक्शन का तर्क क्या करता है? खैर बहुत सरल, यह मेमोरी में मौजूद मॉड्यूल (dll) पर पुनरावृति करता है और हैश की एक सूची के विरुद्ध जाँच करता है :) v4[0] = 0x1E7EACEF; v4[1] = 0x4468A620; v4[2] = 0x68536B95; v4[3] = 0x73EBBB53; v4[4] = 0xDA165168; v4[5] = 0xB24D33A7; v4[6] = 0xB1E2CEC6; v4[7] = 0x5136992; v4[8] = 0x98C500D9; v4[9] = 0x3E0169B6;
और यदि मेमोरी में कोई भी dll समान हैश के साथ नहीं मिलती है तो हम 0 लौटाते हैं, अन्यथा 1 और हम डीबगर को क्रैश कर देते हैं। और इस तरह हम कह सकते हैं कि यह एक और anti-analysis विधि है। सही है, लेकिन प्रत्येक हैश मान के बारे में क्या? खैर, मैं फिर से धोखा दूँगा (जैसा कि किसी ने कहा था कि आप मालवेयर विश्लेषण में धोखा नहीं दे सकते, केवल अपना जीवन आसान बना सकते हैं :) )। ऊपर उल्लिखित एशियाई शोधकर्ता ने हमें उन मानों की एक सूची प्रदान करने की कृपा की थी जिनसे ये मान निकाले गए थे
sbiedll.dll dbghelp.dll api_log.dll dir_watch.dll pstorec.dll vmcheck.dll wpespy.dll cmdvrt64.dll avghookx.dll snxhk.dll
अब गतिशील रूप से देखने के लिए कि क्या कोई मान उल्लिखित किसी dll से मेल खाता है
और निश्चित रूप से यह मेल खाता है :)
लेकिन मैं इस निष्कर्ष पर कैसे पहुँचा कि एल्गोरिदम इन मानों के विरुद्ध जाँच करता है? खैर, जब मैंने इस मालवेयर के एक हिस्से का emulation किया तो मुझे iterate_over_module_name_and_hash (solve_hash_syscalls.py फ़ाइल में) को फिर से लागू करना पड़ा और इस फ़ंक्शन में हमारे पास है
जहाँ x (पारित तर्क) इस मामले में v2 है, जो मानों की एक सरणी (एक पॉइंटर) है, जो तब तक बढ़ती रहती है (जहाँ यह सरणी में इंगित करता है) जब तक यह ऊपर पहले से उल्लिखित किसी भी मान से मेल नहीं खाती। वाह, यह एक मुँहफट बात है :P
मस्त! अगला
=============================================================================
iterate_over_modules2 लगभग वही कहानी है
और pseudo-code
लगभग वही कहानी, केवल अलग हैश :)
v5[0] = 0x7D73878E; v5[1] = 0xEF36424B; v5[2] = 0xAF64BC2B; v5[3] = 0x1DBBC879; v5[4] = 0xAE6D1D56; v5[5] = 0x7B3242F2; v5[6] = 0x14D922B9; v5[7] = 0x4C92DF53;
जो निम्न से मेल खाते हैं
sample.exe bot.exe sandbox.exe malware.exe test.exe klavme.exe myapp.exe testapp.exe
=============================================================================
iterate_over_modules3 यहाँ भी वही कहानी है
और pseudo-code
वही कहानी, अलग हैश :)v4[0] = 0x42D12D59; v4[1] = 0xEC5D7AA; v4[2] = 0x861E460F; v4[3] = 0x84BCC8DB; v4[4] = 0x6474D72B; v4[5] = 0xB8B9C504; v4[6] = 0x69A0620E; v4[7] = 0x6017EE43; v4[8] = 0xE93BE2E0; v4[9] = 0x149EFC55; v4[10] = 0xE3FA84A4; v4[11] = 0x7CFDD7AF; v4[12] = 0x5B098C67; v4[13] = 0x2F1FB18E; v4[14] = 0xFE8F2B18;
जो इनसे मेल खाते हैं
prl_cc.exe prl_tools.exe qemu-ga.exe vmtoolsd.exe vmwaretray.exe vmwareuser.exe VGAuthService.exe vmacthlp.exe vboxservice.exe vboxtray.exe VMSrvc.exe VMUSrvc.exe xenservice.exe
=============================================================================
Anti_debug_measure_1 मैंने इसका नाम बदलकर anti_debug_measure2_RtlAddVectoredExceptionHandler_int3 कर दिया। क्यों, आप एक मिनट में देखेंगे। तो यह ऐसा दिखता है
और स्यूडो-कोड के नज़रिए से यह ऐसा दिखता है
तो यह आखिर है क्या? खैर, यह मूल रूप से __debugbreak(int 3) के लिए एक exception handler बना रहा है, जो जब भी int3 उठाया जाता है तो कोड निष्पादित करेगा। मैंने और खोज की और मुझे यह मिला
(https://blog.lexfo.fr/dridex-malware.html) जो एक बढ़िया संसाधन है और हमें बताता है कि यह बस एक anti-debug तंत्र है, और हमारे मामले में हम बस इस फ़ंक्शन को चलाते हैं, हम sub_13F2820D0 को अनदेखा करते हैं जो
जब भी हम int3 निष्पादित करते हैं तो ट्रिगर होता है और eax को 0 पर पैच करता है :) तो मेमोरी निष्पादन में यह ऐसा दिखता है :)
पैच से पहले
पैच के बाद
उसके बाद आप फ़ंक्शन से बाहर निकलते हैं और rax/eax को भी 0 कर देते हैं, ताकि आप debugger को क्रैश करने वाली jne को स्किप कर दें
=============================================================================
Anti_debug_measure_2 जिसे मैंने बाद में बदलकर anti_debug_measure2_RtlAddVectoredExceptionHandler_int2 कर दिया
फिर से कुछ नया नहीं, वही चीज़ बस दूसरे int/syscall को हुक करना, इस बार int2, बायपास करने के लिए वही trick — return value को डाइनैमिक रूप से पैच करके इसे बायपास करें :)
अगर आप Google पर anti analysis 2dh खोजेंगे तो बहुत सारी चीज़ें मिलेंगी, तो हाँ, आप इसके बारे में और जानने के लिए उसे संदर्भ के रूप में इस्तेमाल कर सकते हैं, मैंने इस पर ज़्यादा समय नहीं बिताया :)
इसके लिए, भले ही आप step over करने की कोशिश करें, यह ret पर समाप्त होगा जैसा यहाँ है
और इसे बायपास करने के लिए बस return तक execute करें और आप ठीक हैं :)
=============================================================================
तो अब आता है anti_debug measure heap, जिसे मैंने बाद में rename करके iterate_over_current_process_and_check_again_hases कर दिया
और इस फ़ंक्शन की एक बढ़िया विशेषता यह है कि यह सभी चल रही प्रक्रियाओं को सूचीबद्ध करने के लिए iterate_over_current_process_and_hash_check के अंदर ntquerysysteminformation का उपयोग करता है। iterate_over_current_process_and_hash_check कुछ ऐसा दिखता है
Cool beans, लेकिन मैंने यह निष्कर्ष कैसे निकाला कि iterate_over_current_process_and_hash_check वही करता है जो नाम से पता चलता है? खैर, पहले यह ntquerysysteminformation कॉल है, जिसे अगर आप Google पर खोजेंगे तो दिखेगा कि इसका इस्तेमाल चल रही प्रक्रियाओं की सूची पाने के लिए होता है, और फिर मैंने नीचे दिए कोड snippet के आधार पर एक अनुमान लगाया LODWORD(v4) = RtlAllocateHeap(NtCurrentPeb()->ProcessHeap, 8u, v10); v3 = v4; v5 = ntquerysysteminformation(); v6 = v3; .... memcpy(v9, v6[8], *(v6 + 28)); v9[*(v6 + 28) >> 1] = 0; if ( some_hash_0x1003F(v9) == a1 ) कि यह प्रक्रियाओं की सूची कॉपी करेगा, हर एक को iterate करेगा और पिछले array के प्रत्येक hash की तुलना जो भी प्रक्रिया चल रही है उससे करेगा। अब फिर से उस एशियाई शोध ब्लॉग को श्रेय जाता है, क्योंकि मुझे नहीं पता कि उसने v4 array मानों का असली नाम कैसे निकाला। अगर आप देखना चाहें कि मैंने इसे कैसे emulate किया, तो कृपया iterate_over_modules.py देखें।
Ps. अगर आप इस फ़ंक्शन को डाइनैमिक रूप से debug करते हैं, तो आप फिर से int 2d पर पहुँचेंगे, और समाधान वही है जो ऊपर बताया गया है, बस आपको return तक 0xf बार execute करना है, जो मूल रूप से hev को walk करता है और उसके बाद अगर आप सुनिश्चित होना चाहते हैं कि आप iterate_over_current_process_and_check_again_hases से return पर पहुँच गए हैं, तो इस फ़ंक्शन के अंत में एक br लगा दें और आप सुरक्षित हैं :)
============================================================================= anti_debug_measure_heap
तो हाँ, हम भाग्यशाली हैं कि यह इतना बड़ा नहीं है, और सबसे अच्छी बात यह है कि हमने पहले ही demangle_strings लागू कर दिया है। अब मैंने इसे बड़े arrays के लिए फिर से लागू किया है, कृपया anti_debug_measure.py देखें।
यह मूल रूप से इसके विरुद्ध जाँच करता है``` \Registry\Machine\SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters \Registry\Machine\SYSTEM\ControlSet001\Services\vioscsi \Registry\Machine\SYSTEM\ControlSet001\Services\VirtIO-FS Service \Registry\Machine\SYSTEM\ControlSet001\Services\VirtioSerial \Registry\Machine\SYSTEM\ControlSet001\Services\BALLOON \Registry\Machine\SYSTEM\ControlSet001\Services\BalloonService \Registry\Machine\SYSTEM\ControlSet001\Services\netkvm \Registry\Machine\SOFTWARE\VMware, Inc.\VMware Tools \Registry\Machine\HARDWARE\ACPI\DSDT\VBOX__ \Registry\Machine\HARDWARE\ACPI\FADT\VBOX__ \Registry\Machine\HARDWARE\ACPI\RSDT\VBOX__ \Registry\Machine\SOFTWARE\Oracle\VirtualBox Guest Additions \Registry\Machine\SYSTEM\ControlSet001\Services\VBoxGuest \Registry\Machine\SYSTEM\ControlSet001\Services\VBoxMouse \Registry\Machine\SYSTEM\ControlSet001\Services\VBoxService \Registry\Machine\SYSTEM\ControlSet001\Services\VBoxSF \Registry\Machine\SYSTEM\ControlSet001\Services\VBoxVideo
अब get_oem_key
पहले यह स्ट्रिंग को डिमैंगल करता है```
\Registry\Machine\HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0
\Registry\Machine\SYSTEM\ControlSet001\Control\SystemInformation
\Registry\Machine\HARDWARE\Description\System
Identifier
SystemManufacturer
SystemBiosVersion
VMWARE
QEMU
VBOX
और फिर क्वेरी करता है
\Registry\Machine\HARDWARE\DEVICEMAP\Scsi\Scsi Port 0\Scsi Bus 0\Target Id 0\Logical Unit Id 0
\Registry\Machine\SYSTEM\ControlSet001\Control\SystemInformation
\Registry\Machine\HARDWARE\Description\System
और उनके मानों को qemu, vbox, VMWARE के विरुद्ध जाँचता है, जैसा कि ida स्निपेट और x86 विंडो में देखा जा सकता है :)
जैसा कि पहले स्निपेट में देखा जा सकता है, यह vmware को उन मानों के विरुद्ध जाँचता है जो विश्लेषण के समय मेरी vm में संग्रहीत थे :)
कोई बड़ी बात नहीं, बस इस फ़ंक्शन को ret तक चलाएँ और लौटते समय eax को 0 में बदल दें :) इस एंटी-विश्लेषण विधि को बायपास करने के लिए :)
=============================================================================
अब get_oem_from_firmware
अब कुछ दिलचस्प देखते हैं: यह फ़ंक्शन sub_13F267288() से शुरू होता है जिसमें 0x52534D42 पैरामीटर के रूप में पास किया जाता है। यदि आप इस मान को Google पर खोजते हैं, तो आपको विभिन्न फ़ोरमों पर बहुत सारे बढ़िया प्रश्न मिलेंगे, जैसे(https://ru.stackoverflow.com/questions/778618/c-%D0%9A%D0%B0%D0%BA-%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D1%82%D1%8C-%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D1%8E-%D0%BE%D0%B1-%D1%83%D1%81%D1%82%D1%80%D0%BE%D0%B9%D1%81%D1%82%D0%B2%D0%B0%D1%85-%D0%BA%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80%D0%B0-%D0%BD%D0%B5-%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D1%83%D1%8F-wmi) (https://msdn-whiteknight.github.io/answers/html/tools/html/ru.stackoverflow.com/posts/780170.html) (https://www.maldun.com/analysis/YXNkZmRzZmFkc2Y2NDEwNjlkc2Zhc2RmYXNkZg==/) या यह(https://github.com/digitalocean/go-smbios/blob/master/smbios/stream_windows.go)। लेकिन सबसे दिलचस्प: इसे पढ़ने और RSMB खोजने के बाद आपको यह मिल सकता है https://evasions.checkpoint.com/techniques/firmware-tables.html जो समझाता है कि यह एक एंटी-विश्लेषण विधि है :) अच्छा, तो यह क्या करता है?
पहले SMBIOS फर्मवेयर टेबल को डंप करता है, फिर एक स्ट्रिंग को डिमैंगल करता है (पहली स्ट्रिंग qemu है), फिर sub_13F2655E0 को डिमैंगल की गई स्ट्रिंग और फर्मवेयर टेबल के साथ कॉल करता है। स्थैतिक विश्लेषण से
विशेष रूप से, यदि ( v4 != v5) — मैंने निष्कर्ष निकाला कि यह लगभग strcmp जैसा कार्यान्वयन है, यह फर्मवेयर टेबल में जो कुछ भी है उसे डिमैंगल की गई स्ट्रिंग के साथ जाँचेगा। जैसा कि डीबगर में देखा जा सकता है
r8 फर्मवेयर टेबल का ptr है, और अधिक दिलचस्प बात यह है कि हम देख सकते हैं कि ... कुछ-कुछ ... virtualbox फर्मवेयर टेबल में पाया गया नाम है, और rcx qemu है, इसलिए हम सुरक्षित रूप से कह सकते हैं कि यह लगभग strcmp जैसा कार्यान्वयन है। और निश्चित रूप से जैसा कि देखा जा सकता है, हम इस जाँच के लिए सुरक्षित हैं :)
अब यह प्रक्रिया VirtualBox, vbox, VBOX, VMware स्ट्रिंग्स के लिए दोहराई जाती है :) सामान्यतः इस फ़ंक्शन की जाँच को बायपास करने का समाधान यह है कि इसे ret तक चलाएँ, eax पैच करें और विश्लेषण जारी रखें :)
============================================================================
अच्छा, अब check_oem_key ()
तो यह क्या करता है? वही चाल जो पहले समझाई गई थी, लेकिन इस बार acpi टेबल के साथ। मेरा यहाँ क्या मतलब है? बेहतर होगा कि इस 14 स्लाइड(https://dc4420.org/slides/2015-11-24/acpi_vm_detect.pdf) को पढ़ें — वे इसे बेहतर समझाते हैं, लेकिन वही सस्ती चाल है :)) इस बार BOCHS, BXPC, VMWARE के विरुद्ध
============================================================================
मैं anti_debug_processor_Timing() फ़ंक्शन से शुरू करना चाहता हूँ और फिर check_for_flags() के साथ समाप्त करूँगा। तो
यह कैसा दिखता है। तो यह क्या करता है? यह प्रोसेसर के टाइम-स्टैम्प का वर्तमान मान पढ़ता है, फिर प्रोसेसर का नाम लेता है (हमारे मामले में GenuineIntel), फिर प्राप्त टाइमस्टैम्प को प्रोसेसर के नाम से घटाता है, और फिर केवल यह जाँचता है कि परिणाम 19999 से बड़ा है या नहीं।
rdtsc के बाद
cpuid के बाद
जैसा कि देखा जा सकता है, स्ट्रिंग 3 रजिस्टरों में विभाजित है
और हमारे मामले में हम देखते हैं कि हम इस जाँच में "विफल" होते हैं और eax को 1 पर सेट करते हैं
इस एंटी-जाँच का समाधान: बस फ़ंक्शन से लौटें और eax को 0 पर पैच करें :)
============================================================================
अब entry_to_peb()
स्यूडो-कोड के नज़रिए से
तो if जाँच तक कुछ नया नहीं है, हम इस प्रकार का एल्गोरिद्म पहले ही देख चुके हैं — तो इसके बारे में क्या? यदि आप पहले से संदर्भित एशियाई research के write-up पर जाएँगे, तो आप देखेंगे कि वह कहता है कि यह जाँचता है कि Windows का संस्करण win7/server 2008 r2 से बड़ा है या नहीं। लेकिन वह इस विचार के साथ कैसे आया? यदि हम http://waleedassar.blogspot.com/2012/08/major-minorsubsystemversion.html पढ़ें, तो वह कहता है
इसके अलावा यदि आप यह भी पढ़ें :)
और यहाँ जो कहा गया है उसे लागू करें कि यह स्वतः KUSER_SHARED_DATA संरचना में डाल (cast) हो जाता है, लेकिन यहाँ विश्लेषण के दौरान मेरी ida में बग था, तो जो है वही है :)
ताकि आपको लगभग उसी एल्गोरिद्म की पुनरावृत्ति से ऊब न हो, यहाँ अंतिम फ़ंक्शन से प्राप्त और डिमैंगल की गई स्ट्रिंग्स हैं :) यह एक थकाऊ प्रक्रिया थी क्योंकि यह एक डीबगर के साथ की गई थी :) मैं इसे emulate करने में बहुत आलसी था``` user32.dll advapi32.dll Rpcrt4.dll bcrypt.dll ole32.dll Cabinet.dll
CreateWindowExW
ShutdownBlockReasonCreate
ShutdownBlockReasonDestroy
DestroyWindow
CloseHandle
CreateProcessW
InitializeProcThreadAttributeList
UpdateProcThreadAttribute
LoadAppInitDlls
Sleep
GetExitCodeProcess
MoveFileExW
OpenSCManagerW
OpenServiceW
QueryServiceStatus
StartServiceW
CloseServiceHandle
GetUserNameW
ConvertSidToStringSidW
LookupAccountNameW
CreateWellKnownSid
LookupPrivilegeValueW
ConvertStringSecurityDescriptorToSecurityDescriptorW
RpcStringBindingComposeW
RpcBindingFromStringBindingW
RpcStringFreeW
RpcBindingSetOption
RpcBindingSetAuthInfoExW
RpcBindingFree
NdrClientCall2
NdrClientCall3
BCryptOpenAlgorithmProvider
BCryptSetProperty
BCryptGenerateSymmetricKey
BCryptDecrypt
BCryptDestroyKey
BCryptCloseAlgorithmProvider
BCryptGetProperty
BCryptGenRandom
CoCreateInstance
CoInitializeEx
CoUninitialize
CoInitializeSecurity
CoSetProxyBlanket
if >win7/server 2008 r2
{
CreateDecompressor
CloseDecompressor
Decompress
}
और इसी के साथ blacklotus विश्लेषण चुनौती के पहले भाग का अंत होता है।
============================================================================
दूसरे भाग के लिए
असेंबली दृष्टिकोण
स्यूडो-कोड दृष्टिकोण
हम विच्छेदन की शुरुआत some_hash() फ़ंक्शन से करेंगे।
============================================================================
ग्राफ़ दृष्टिकोण
असेंबली दृष्टिकोण
स्यूडो-कोड दृष्टिकोण
