
बुरे लोगों द्वारा बुरी चीज़ें
इस दस्तावेज़ में विश्लेषित और संदर्भित Hive सैंपल को @rivitna द्वारा बनाई गई इस सूची से यादृच्छिक रूप से चुना गया था, जिनके प्रति मेरा हार्दिक आभार है। आर्टिफैक्ट VirusTotal प्लेटफ़ॉर्म पर उपलब्ध हैं।
इस दस्तावेज़ में, a0h2uih3d2.exe फ़ाइल को संदर्भ के रूप में लिया गया है
MD5: 15CF5E0DA094ACDD751A513402A8C941
SHA-1: 72E15AC4473903C814E65E3C06F54EB0399580AA
SHA-256: 335D2E4A743D059955760ECF2EC25EE86D36AA60B096C9180E860C64EF78EE55
इस रैंसमवेयर की जटिलता का अंदाज़ा लगाने के लिए, कृपया Microsoft Threat Intelligence Center (MSTIC) द्वारा प्रकाशित इस विश्लेषण पर एक नज़र डालें।
कोड के साथ खिलवाड़ शुरू करने से पहले कृपया पूरे दस्तावेज़ को ध्यान से पढ़ें!
हाल के महीनों में, मैंने अपनी अधिकांश ऊर्जा Hive v5 एन्क्रिप्शन एल्गोरिदम के अध्ययन और रिवर्स इंजीनियरिंग में लगाई है। मुझे एक महान मैलवेयर विश्लेषक और रिवर्स इंजीनियर @rivitna के साथ सहयोग करने का सौभाग्य मिला, जिन्होंने अतीत में Hive के पिछले संस्करणों का विश्लेषण किया है और उनके एन्क्रिप्शन तंत्र से संबंधित कोड और PoC प्रकाशित किए हैं। उन्होंने Hive v5 की एन्क्रिप्शन प्रक्रियाओं में शामिल घटकों की पहचान करने में (थोड़ा नहीं) योगदान दिया है, जो RUST में लिखा जाने के कारण विश्लेषण करना अधिक कठिन हो गया है। मुझे Babuk के साथ कुछ समानताएँ मिलीं, जो एक और बहुत महत्वपूर्ण रैंसमवेयर है जिसके स्रोत जून 2021 में सार्वजनिक किए गए थे:
किसी पीड़ित सिस्टम पर चलने वाला Hive ransomware v5, नीचे दिए गए प्रमाण में दिखाए गए एल्गोरिदम का उपयोग करके, QueryPerformanceCounter और QueryPerformanceFrequency Windows APIs पर आधारित, दो क्लियरटेक्स्ट कुंजियाँ उत्पन्न करता है।
कृपया QueryPerformanceCounter APIs के बारे में अधिक जानकारी के लिए इस Microsoft पेज को देखें, और QueryPerformanceFrequency के लिए यहाँ देखें।
QueryPerformanceCounter एक बहुत सटीक समय काउंटर है। कॉल किए जाने पर, यह पीसी के अंतिम बार चालू होने के बाद से बीता हुआ समय लौटाता है।
QueryPerformanceFrequency परफॉर्मेंस काउंटर का मान (आवृत्ति) लौटाता है। इसका एक निश्चित मान 0x989680 होता है। इसका मतलब है कि QueryPerformanceCounter मान प्रति सेकंड 0x989680 बार अपडेट होता है, जो 10,000,000 बार है।
दोनों क्लियरटेक्स्ट कुंजियों का आकार 0xCFFF00 बाइट्स है और वे एक समय में एक बाइट उत्पन्न होती हैं। नीचे वह स्निपेट है जो 0xA00000 बाइट्स की ऐरे बनाने की अनुमति देता है, जो तथाकथित क्लियरटेक्स्ट कुंजी का सबसे बड़ा हिस्सा है जिसके साथ Hive पीड़ित के पीसी पर फ़ाइलों को एन्क्रिप्ट करता है।

कुंजी का प्रत्येक बाइट AL रजिस्टर का मान लेकर प्राप्त किया जाता है। EAX रजिस्टर में 0044ADE0 फ़ंक्शन का परिणाम होता है जिसे createByte लेबल से पुनः नामित किया गया है, जो वर्तमान समय क्षण और प्रारंभिक सीड मान के बीच के अंतर को लागू करता है, जिसकी गणना 0044A850 फ़ंक्शन की पहली कॉल पर की जाती है जिसे call_to_QueryPerformanceCounter लेबल से पुनः नामित किया गया है।
नीचे क्लियरटेक्स्ट कुंजी उत्पन्न करने के लिए C++ में लिखा गया कोड है:

एल्गोरिदम बहुत सरल है, भले ही 0044ADE0 फ़ंक्शन के अंदर, ऐसे निर्देश डाले गए हैं जो अनावश्यक संचालन और विभिन्न सशर्त जंप करते हैं ताकि क्लियरटेक्स्ट कुंजी के निर्माण के दौरान कोड के निष्पादन समय में देरी करने की कोशिश की जा सके:

HiveRansomwareV5_custom_keygen_PoC फ़ोल्डर में आपको विश्लेषित Hive v5 सैंपल से रिवर्स किया गया रॉ कोड मिलेगा। यह मैलवेयर में पाए जाने वाले कोड जैसा अनुकूलित कोड नहीं है, क्योंकि मुझे संकलित संस्करण से कोड की एक भी पंक्ति नहीं छोड़नी थी।
HiveRansomwareV5_custom_keygen_PoC-optimized फ़ोल्डर में आपको उपर्युक्त रॉ कोड से व्युत्पन्न अनुकूलित कोड मिलेगा। इस संस्करण में कोड रॉ संस्करण की तुलना में पढ़ने में बहुत आसान है, ताकि यह समझा जा सके कि यह किस कार्यक्षमता को लागू करता है।
उत्पन्न क्लियरटेक्स्ट कुंजी को अपने डेस्कटॉप पर सहेजने के लिए दोनों संस्करणों को चलाने से पहले आपके उपयोगकर्ता नाम के साथ अनुकूलित करने की आवश्यकता है।
दोनों क्लियरटेक्स्ट कुंजियाँ एक ही एल्गोरिदम का उपयोग करके उत्पन्न की जाती हैं।
एक क्लियरटेक्स्ट कुंजी 0xA00000 सुरक्षित रूप से यादृच्छिक रूप से उत्पन्न बाइट्स से बनी होती है। फिर पहले 0x2FFF00 बाइट्स को अंत में कॉपी किया जाता है, जिससे अंतिम 0xCFFF00 बाइट्स की क्लियरटेक्स्ट कुंजी बनती है।

फिर Hive फ़ाइलों को एन्क्रिप्ट करने के लिए दो उत्पन्न कुंजियों का उपयोग करता है, लेकिन सबसे पहले Hive ransomware v5 उत्पन्न कुंजियों को कस्टम संरचना (जिसे आगे कीस्ट्रीम कहा जाएगा) में एन्क्रिप्ट करता है और उन्हें .key एक्सटेंशन का उपयोग करके प्रत्येक ड्राइव के रूट में रखता है जिसे वह एन्क्रिप्ट करता है। उदाहरण के लिए, यदि आपके सिस्टम पर C और D दोनों ड्राइव स्थापित हैं, तो एन्क्रिप्टेड कीस्ट्रीम प्रत्येक ड्राइव के रूट में मौजूद होंगी।

Hive ransomware v5 फ़ाइलों को एन्क्रिप्ट करने के लिए XOR निर्देश का उपयोग करके उत्पन्न क्लियरटेक्स्ट कुंजियों का उपयोग करता है, इसलिए हम आधुनिक x86/x64 CPUs पर बहुत तेज़ सिमेट्रिक एन्क्रिप्शन का सामना कर रहे हैं।
Hive ransomware v5 को उत्पन्न क्लियरटेक्स्ट कुंजी को सुरक्षित रखने की आवश्यकता होती है, इसे दो बार एन्क्रिप्ट करके, आगे हम इन्हें राउंड कहेंगे। अंतिम कीस्ट्रीम प्राप्त करने के लिए एन्क्रिप्शन के दो राउंड लगते हैं।
इसे पूरा करने के लिए, प्रत्येक राउंड में निम्नलिखित चरण किए जाते हैं:
चरण 3 एक ऐसी कीस्ट्रीम के निर्माण की गारंटी देता है जिसे निजी कुंजियों की दोहरी जोड़ी द्वारा खोला जा सकता है, वे जो Hive द्वारा एन्क्रिप्शन के दौरान उत्पन्न की जाती हैं और वे जो Hive एफिलिएट ने रैंसमवेयर को हमारे लिए संकलित करते समय उत्पन्न की थीं।

इस विवरण के अंत में एक विशेष बिंदु स्पष्ट है: क्लियरटेक्स्ट कुंजी, निजी कुंजी और एन्क्रिप्शन के दोनों राउंड के लिए उपयोग किया जाने वाला नॉन्स उपरोक्त उसी फ़ंक्शन (0044ADE0 उर्फ createByte) द्वारा उत्पन्न होते हैं। फ़ंक्शन 0044ADE0 उस समय से प्रभावित होता है जो CPU for लूप के अंदर कॉल किए गए कोड को निष्पादित करने में लेता है।
उपरोक्त आकृति पर एक नज़र डालें जो एन्क्रिप्शन के दो राउंड के बाद कीस्ट्रीम संरचना को उजागर करती है, यह स्पष्ट है कि हमारी केवल नॉन्स तक मुफ्त पहुँच है (अन्यथा Hive एफिलिएट नहीं जान पाते कि फ़ाइलों को कैसे डिक्रिप्ट किया जाए)।
तो आइए नॉन्स पर ध्यान केंद्रित करें, जो 24 बाइट्स लंबा है:
नॉन्स: 40 A4 08 6C D0 D0 34 98 FC 60 C4 28 8C F0 F0 54 B8 1C 80 E4 48 AC AC 10
नॉन्स के एक बाइट और अगले बाइट के बीच का अंतर (निरपेक्ष मान में) एक पुनरावृत्ति और अगले के बीच बीते समय को दर्शाता है। हम इस परिभाषा के साथ फिंगरप्रिंट की अवधारणा पेश करते हैं।
नॉन्स फिंगरप्रिंट: 64 9c 64 64 00 9c 64 64 9c 64 9c 64 64 00 9c 64 9c 64 64 9c 64 00 9c
यदि हम प्राप्त मानों का विश्लेषण करते हैं तो हम पाते हैं कि कोड का निष्पादन समय लगभग समान है, जिसमें मामूली भिन्नताएँ मुख्य रूप से उपयोग में आने वाले प्रोसेसर द्वारा उपयोग की जाने वाली तकनीक के कारण हैं (अपने परीक्षणों के लिए मैंने 10वीं पीढ़ी का i7 प्रोसेसर और 5वीं पीढ़ी का i5 इस्तेमाल किया, अन्य सिस्टम पर यह फिंगरप्रिंट भिन्न हो सकता है)।
यह खोज बहुत महत्वपूर्ण है अगर हम सोचें कि नॉन्स उसी फ़ंक्शन द्वारा उत्पन्न होता है जो क्लियरटेक्स्ट में कुंजी और सबसे बढ़कर निजी कुंजी उत्पन्न करता है। चूँकि ये उल्लिखित मान भी इस सिद्धांत का पालन करेंगे, अर्थात नॉन्स के व्यक्तिगत बाइट्स के बीच का अंतर पूर्वानुमानित है, तो निजी कुंजी और क्लियरटेक्स्ट कुंजी मान भी पूर्वानुमानित होंगे।
हालाँकि, विश्लेषणों ने दिखाया है कि Hive द्वारा गणना की गई मूल क्लियरटेक्स्ट कुंजी के समान मूल बाइट्स प्राप्त करने की उम्मीद में 0xA00000 वर्णों की एक ऐरे उत्पन्न करना बहुत कठिन है: CPU और मेमोरी लोड में भिन्नताएँ कोड के निष्पादन की गति को प्रभावित करती हैं और अक्सर Hive PE द्वारा गणना की गई मूल क्लियरटेक्स्ट कुंजी हमारे द्वारा गणना की गई कुंजी से भिन्न होती है (भले ही केवल कुछ बाइट्स के लिए)।
हम इस नॉन्स फिंगरप्रिंट का उपयोग 0xA00000 बाइट्स लंबे संभावित डिक्शनरी के निर्माण से प्राप्त फिंगरप्रिंट से तुलना करने के लिए करते हैं (यह संख्या अनुभवजन्य रूप से तय की गई है, परीक्षणों की एक श्रृंखला के बाद, यह देखा गया है कि सांख्यिकीय रूप से इस संख्या में बाइट्स में एन्क्रिप्शन के दोनों राउंड में आवश्यक 32 बाइट्स की दो निजी कुंजियाँ होती हैं)। यदि नॉन्स फिंगरप्रिंट डिक्शनरी फिंगरप्रिंट में समाहित है तो हमें दोनों निजी कुंजियों को ब्रूटफोर्स करना शुरू करने के लिए सही डिक्शनरी मिल गई है।
यह यहीं समाप्त नहीं होता है, क्योंकि नॉन्स, क्लियरटेक्स्ट कुंजी और निजी कुंजी के निर्माण पर किए गए गतिशील विश्लेषणों से, यह सत्यापित किया गया है कि पहले बाइट की दूसरे बाइट से औसत दूरी अलग होती है, अन्य सभी बाइट्स की तुलना में जिनके मान लगभग समरूप होते हैं। आइए विस्तार से देखें:

जैसा कि आप देख सकते हैं, पहले के बाद के फिंगरप्रिंट के मान न्यूनतम भिन्नताओं से गुजरते हैं, अर्थात निजी कुंजी के पहले और दूसरे बाइट के बीच निरपेक्ष मान में दूरी अधिकांश समय फिंगरप्रिंट के बाकी हिस्सों में मौजूद मानों के बाहर होती है।
संभवतः यह CPU में मौजूद कुछ अनुकूलन एल्गोरिदम के कारण है जो for लूप में पहली पुनरावृत्ति के बाद कोड के निष्पादन को तेज करते हैं।
प्रस्तावित कोड प्रत्येक कीस्ट्रीम एन्क्रिप्शन राउंड का नॉन्स पढ़ता है, उसका फिंगरप्रिंट निर्धारित करता है और संभावित निजी कुंजी वाले संभावित कुंजी डिक्शनरी की एक सूची उत्पन्न करता है।
फिंगरप्रिंट के पहले बाइट से संबंधित समस्या को हल करने के लिए जो हमेशा कुंजी के बाकी हिस्सों से अलग होता है, मैंने यह करने के बारे में सोचा:
जब दो सार्वजनिक कुंजियाँ मेल खाती हैं तो हमें वह निजी कुंजी मिल गई होगी जिसके साथ एन्क्रिप्शन का दूसरा (अंतिम) राउंड एन्क्रिप्ट किया गया था। अब तक वर्णित संचालन को फिर से दोहराकर हमारे पास पहले राउंड की एन्क्रिप्टेड कीस्ट्रीम को डिक्रिप्ट करने के लिए निजी कुंजी होगी और अंत में मूल क्लियरटेक्स्ट कुंजी निकाली जाएगी।
HiveRansomwareV5-keystream_decryptor फ़ोल्डर में आपको VS 2017 sln और एक monocypher अनुकूलित लाइब्रेरी मिलेगी। प्रोग्राम आपको यह चुनने देता है कि कौन सा ऑपरेशन करना है।

विकल्प "1" सबसे पहले चुना जाने वाला विकल्प है क्योंकि यह आपको आपके पीसी प्रोसेसर के लिए "टेलर-मेड" बाइट्स की एक डिक्शनरी बनाने की अनुमति देता है, इसलिए इसे एन्क्रिप्टेड मशीन पर किया जाना चाहिए, क्योंकि इसकी बहुत अधिक संभावना है कि आपको उसकी कीस्ट्रीम में मौजूद मानों के बराबर मान मिलेंगे।

या वैकल्पिक रूप से, यदि पहला विकल्प काम नहीं करता है, तो क्लियरटेक्स्ट कुंजी निर्माण के अंत तक (for लूप के ठीक बाहर) डिबगर में मैलवेयर चलाकर (उसी पहले से संक्रमित पीसी पर) अपनी खुद की डिक्शनरी उत्पन्न करें और उस मेमोरी की सामग्री को सहेजें जिसमें क्लियरटेक्स्ट कुंजी होती है। इस मामले में आप विकल्प "3" का उपयोग करके अपनी डिक्शनरी को मान्य कर सकते हैं:

एक बार जब आपके पास अपनी कीस्ट्रीम के लिए सही डिक्शनरी आ जाती है, तो विकल्प "2" अधिक शक्तिशाली कंप्यूटरों पर भी किया जा सकता है क्योंकि वे बाइट्स के संयोजन को ब्रूट करने के लिए आवश्यक समय को कम कर देंगे, बिना निजी कुंजी बाइट्स के मानों को किसी भी तरह से प्रभावित किए।

विकल्प 2 में मौजूद कार्यक्षमता को ठीक से करने के लिए, सार्वजनिक कुंजी निकाली जानी चाहिए। चूँकि सभी Hive सैंपल समान नहीं बनाए गए हैं, एक सार्वभौमिक सार्वजनिक कुंजी निकालने वाला उपकरण बनाना बहुत आसान नहीं है। हालाँकि, एक तरीका जो काम करने के लिए जाना जाता है, वह है नॉन्स के निर्माण के बाद डिसअसेंबल के इस हिस्से में एक ब्रेकपॉइंट सेट करना। नीचे दिए गए प्रमाण में, सार्वजनिक कुंजी को curve25519 का उपयोग करके साझा कुंजी व्युत्पन्न करने के लिए फ़ंक्शन 44E3D8 में पारित किया जाता है। यह एकमात्र स्थान है जहाँ मैलवेयर के पूरे निष्पादन के दौरान सार्वजनिक कुंजी प्रकट होती है।

कृपया Visual Studio विकल्पों के साथ व्यवहार करते समय ध्यान दें। यदि आप डिबग से रिलीज़ और इसके विपरीत स्विच करते हैं तो डिक्शनरी जनरेटेड बाइट्स जैसे प्रोग्राम आउटपुट बदल सकते हैं।
यदि आप ब्रूट प्रक्रिया को तेज करना चाहते हैं तो आप कोड में dictionary_dimension मान को संपादित कर सकते हैं, लेकिन कृपया ध्यान रखें कि डिक्शनरी आकार घटाने से निजी कुंजी खोजने की संभावना भी घट सकती है।
इसके अलावा यदि आप Hive चलाकर और उसे मेमोरी से डंप करके उत्पन्न क्लियरटेक्स्ट बाइट ऐरे का उपयोग करने का निर्णय लेते हैं, तो dictionary_dimension वेरिएबल में अपने डंप का आकार सेट करना याद रखें।
डिक्रिप्शन टूल का परीक्षण करने के लिए मैंने dummy_data_PoC फ़ोल्डर में उपयोग करने के लिए कुछ फ़ाइलें उपलब्ध कराई हैं:
शुभकामनाएँ!
https://github.com/rivitna/Malware/blob/main/Hive/Hive_samples.txt
https://www.virustotal.com/gui/file/335d2e4a743d059955760ecf2ec25ee86d36aa60b096c9180e860c64ef78ee55
https://www.microsoft.com/security/blog/2022/07/05/hive-ransomware-gets-upgrades-in-rust/
https://docs.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps
https://monocypher.org/manual/x25519
https://monocypher.org/manual/advanced/poly1305