optiv/ivyIvy एक payload निर्माण framework है, जो arbitrary VBA (macro) source code को सीधे memory में execute करने के लिए है। Ivy का loader VBA object environment में programmatical access का उपयोग करके shellcode को load, decrypt और execute करता है।
Ivy के नवीनतम संस्करण को देखने या कोई समस्या सबमिट करने के लिए, https://github.com/Tylous/Ivy देखें।
यदि आप इस फ्रेमवर्क में उपयोग की गई तकनीकों के साथ-साथ इससे बचाव के लिए सुरक्षा उपायों के बारे में अधिक जानना चाहते हैं, तो कृपया लेख देखें।
Ivy एक पेलोड निर्माण फ्रेमवर्क है जो मेमोरी में मनमाने VBA (मैक्रो) स्रोत कोड के निष्पादन के लिए है। Ivy का लोडर ऐसा VBA ऑब्जेक्ट एनवायरनमेंट में प्रोग्रामेटिक एक्सेस का दुरुपयोग करके शेलकोड को लोड, डिक्रिप्ट और निष्पादित करने के लिए करता है। यह तकनीक वास्तव में फाइललेस होने के जितना संभव हो उतना करीब है, क्योंकि आजकल अधिकांश फाइललेस हमलों में डिस्क पर कुछ फाइलें ड्रॉप करने की आवश्यकता होती है, जिसके परिणामस्वरूप VBA कोड का पता लगाने के लिए मानक सिग्नेचर-आधारित नियमों को बायपास किया जाता है। सामान्य VBA पेलोड्स में निम्नलिखित विशेषताएं होती हैं:
पूरी तरह से मेमोरी में चलने से, ये व्यवहार विशेषताएँ EDRs द्वारा पता लगाए जाने को कठिन बना देती हैं।
Ivy के लोडर RC4 एन्क्रिप्शन का उपयोग करके एन्क्रिप्ट किए जाते हैं (AES एन्क्रिप्शन बहुत अधिक ब्लोट का कारण बनता है और VBA को डिक्रिप्ट करने में हमेशा लगता है) और फिर अलग-अलग स्ट्रिंग्स में तोड़ दिए जाते हैं, जिससे कोई भी सैंडबॉक्सिंग इन स्ट्रिंग्स को एन्क्रिप्टेड स्ट्रिंग्स के रूप में पहचानने से रोकता है जिनकी जांच की जानी चाहिए। यह किसी भी डिकोडिंग तंत्र को इन पेलोड्स को कचरे के अक्षरों के अलावा कुछ और पहचानने से भी रोकता है।
Ivy का लोडर पहले "Trust access to the VBA project object mode" को सक्षम करने के लिए एक रजिस्ट्री क्वेरी करता है। यह रजिस्ट्री कुंजी मान यूजर-मोड में संग्रहीत होता है जो उपयोगकर्ता को बिना किसी उन्नत अनुमति की आवश्यकता के मान को संशोधित करने की अनुमति देता है। रजिस्ट्री मान को शून्य से 1 पर सेट किया जाता है; यदि रजिस्ट्री कुंजी मौजूद नहीं है तो Ivy इसे "1" मान के साथ बनाएगा। इस मान को सक्षम करने पर, एक अलग प्रक्रिया से VBA ऑब्जेक्ट एनवायरनमेंट तक प्रोग्रामेटिक एक्सेस की अनुमति होती है।
एक बार यह हो जाने के बाद लोडर एक छिपी हुई Excel प्रक्रिया को स्पॉन करेगा और एन्क्रिप्टेड स्ट्रिंग्स को एक VBA फंक्शन में लोड करेगा। यह ActiveX का उपयोग करके उसी कार्य को करने के GUI क्रियाओं का अनुकरण करके किया जाता है। यह निष्पादन की निगरानी के लिए मौजूद कई पारंपरिक नियंत्रणों को बायपास करने में मदद करता है। परिणामस्वरूप, डिक्रिप्ट फंक्शन और शेलकोड एक मेमोरी बफर से दूसरे में स्थानांतरित होते हैं, कभी डिस्क को स्पर्श नहीं करते। अंत में, लोडर कमांड-GUI कॉल का उपयोग करता है और रन फंक्शन को निष्पादित करता है, जो VBA के GUI पैनल में रन मैक्रो बटन पर क्लिक करने की क्रिया का अनुकरण करता है, डिक्रिप्शन फंक्शन शुरू करता है, उसके बाद शेलकोड का वास्तविक निष्पादन होता है।
महत्वपूर्ण
लक्ष्य एंडपॉइंट पर Microsoft Office स्थापित और सक्रिय होना चाहिए, क्योंकि Ivy Microsoft Office के VBA एनवायरनमेंट तक प्रोग्रामेटिक एक्सेस के दुरुपयोग पर निर्भर करता है।
यह Ivy को निम्न-स्तरीय सिस्टम कॉल का उपयोग करके WriteProcessMemory विंडोज फंक्शन का अपना संस्करण बनाने की अनुमति देता है, जो प्रत्यक्ष मेमोरी पते और रजिस्टर मानों को अप्रत्यक्ष रूप से संदर्भित करता है। Ivy मेमोरी के उन अनुभागों को ओवरराइट कर सकता है जो बिना किसी मेमोरी चेंज API फंक्शन को कॉल किए लिखने योग्य नहीं हैं। यह WriteProcessMemory की एक विशेषता के कारण होता है जो अस्थायी रूप से मेमोरी क्षेत्र की अनुमतियों को लिखने योग्य में बदल देता है (यदि आपके पास पर्याप्त विशेषाधिकार हैं, जो हमारे पास हैं क्योंकि हम प्रक्रिया के मालिक हैं)। यह मान लिखता है और VirtualProtect फंक्शन को कॉल किए बिना मूल अनुमतियों को पुनर्स्थापित करता है, इसके बजाय यह स्वचालित रूप से संबंधित syscall (NtProtectVirtualMemory) को कॉल करता है।
Ivy NtWriteVirtualMemory का अपना संस्करण उपयोग नहीं करता क्योंकि मेमोरी अनुमतियों को अस्थायी रूप से बदलने की यह प्रक्रिया नहीं होगी, जिसका अर्थ है कि विशिष्ट मेमोरी पते की सुरक्षा संशोधित नहीं होगी और निष्पादन विफल हो जाएगा। यह एक "विशेषता" है जिसे Microsoft ने डीबगर्स को अधिक स्थिर बनाने के लिए जारी किया है। चूंकि डीबगर्स मेमोरी को मौके पर संशोधित करना चाहते हैं, वे कई कार्यों को करने की आवश्यकता के बिना एक अनुभाग को संशोधित कर सकते हैं। (जानकारी के लिए devblogs.microsoft.com देखें)
आइए उन घटनाओं की श्रृंखला पर एक नज़र डालें जो एक EDR देखेगा:
एक बार सभी EDR हुक हटा दिए जाने के बाद, लोडर फिर एक रिमोट सत्र स्थापित करने के लिए अपनी सामान्य कार्रवाई करता है।
Ivy इस समस्या को सामान्य सिस्टम DLLs के EDR के हुक को हटाकर संबोधित करता है, इनमें शामिल हैं:
जब unhook का उपयोग Inject पेलोड प्रकार के साथ किया जाता है, तो Ivy का लोडर पहले ऑफिस प्रक्रिया को अनहुक करेगा, उसमें से EDR को हटाकर, और फिर इंजेक्ट की गई प्रक्रिया में हुक हटाएगा। यह सुनिश्चित करता है कि दोनों प्रक्रियाएँ हुक-मुक्त हों, जिससे पैरेंट और चाइल्ड प्रक्रिया से EDR को कोई टेलीमेट्री न भेजी जाए।
अनहुक करने के लिए उसी तकनीक का उपयोग करते हुए, Ivy ETW फंक्शन्स को पैच कर सकता है, जिससे प्रक्रिया द्वारा कोई भी ईवेंट उत्पन्न होने से रोका जा सके। ETW इस टेलीमेट्री को उत्पन्न करने के लिए बिल्ट-इन Syscalls का उपयोग करता है। चूंकि ETW विंडोज में निर्मित एक मूल सुविधा है, सुरक्षा उत्पादों को जानकारी प्राप्त करने के लिए ETW syscalls को "हुक" करने की आवश्यकता नहीं है। परिणामस्वरूप, ETW को रोकने के लिए, Ivy कई ETW syscalls को पैच करता है, रजिस्टरों को फ्लश करता है और निष्पादन प्रवाह को अगले निर्देश पर लौटाता है। ETW पैचिंग अब सभी लोडर में डिफ़ॉल्ट है, यदि आप ETW को पैच नहीं करना चाहते हैं तो अपने लोडर में इसे अक्षम करने के लिए -noetw कमांड-लाइन विकल्प का उपयोग करें।
Ivy को go में विकसित किया गया था।
पहला कदम हमेशा की तरह रिपो को क्लोन करना है। Ivy को संकलित करने से पहले, आपको निर्भरताएँ स्थापित करनी होंगी। उन्हें स्थापित करने के लिए, निम्नलिखित कमांड चलाएँ:
go get github.com/fatih/color
go get github.com/KyleBanks/XOREncryption/Go
फिर इसे बनाएँ
go build Ivy.go
$ ./Ivy -h
___ ___ ___ ___ ___
|\ \ |\ \ / /||\ \ / /|
\ \ \\ \ \ / / /\ \ \/ / /
\ \ \\ \ \/ / / \ \ / /
\ \ \\ \ / / \/ / /
\ \__\\ \__/ / __/ / /
\|__| \|__|/ |\___/ /
\|___|/
(@Tyl0us)
The suffering. The pain. Can't you hear them?
Their cries for mercy?