यह रिपॉजिटरी संग्रहीत कर दी गई है

Dent के नवीनतम संस्करण को देखने या कोई समस्या सबमिट करने के लिए, https://github.com/Tylous/Dent देखें।

Dent

अधिक जानकारी

यदि आप इस फ्रेमवर्क में उपयोग की गई तकनीकों के बारे में अधिक जानना चाहते हैं, तो कृपया इस लेख को देखें।

विवरण

यह फ्रेमवर्क Microsoft Defender Advanced Threat Protection के Attack Surface Reduction (ASR) नियमों में कमजोरियों का शोषण करने के लिए कोड उत्पन्न करता है ताकि पता लगने या रोके जाने के बिना शेलकोड निष्पादित किया जा सके। ASR को रक्षा की पहली पंक्ति के रूप में डिज़ाइन किया गया था, जो नियमों के एक सेट का उल्लंघन करने वाले कार्यों के आधार पर घटनाओं का पता लगाता है। ये नियम एंडपॉइंट पर विशिष्ट व्यवहार संकेतकों पर ध्यान केंद्रित करते हैं जो अक्सर हमलावर की सामरिकता, तकनीकों या प्रक्रियाओं (TTPs) से जुड़े होते हैं। इन नियमों का मुख्य फोकस Microsoft Office सुइट पर है, क्योंकि यह एंडपॉइंट पर दूरस्थ पैर जमाने के लिए एक सामान्य हमला वेक्टर है। नियम-आधारित नियंत्रणों का एक बड़ा हिस्सा नेटवर्क-आधारित या प्रक्रिया-आधारित व्यवहार संकेतकों पर केंद्रित है जो सामान्य व्यावसायिक संचालन से अलग होते हैं। ये नियम या तो सिस्टम के प्रारंभिक समझौते पर या ऐसी तकनीक पर ध्यान केंद्रित करते हैं जो किसी संगठन को गंभीर रूप से प्रभावित कर सकती है (जैसे, क्रेडेंशियल्स का खुलासा या रैनसमवेयर)। वे सामान्य आक्रमण सतह के एक बड़े हिस्से को कवर करते हैं और संपत्तियों से समझौता करने के लिए उपयोग की जाने वाली ज्ञात तकनीकों को बाधित करने पर ध्यान केंद्रित करते हैं।

Dent इन प्रतिबंधात्मक नियंत्रणों को दरकिनार करने के लिए कई कमजोरियों का लाभ उठाता है ताकि पेलोड को Microsoft Defender Advanced Threat Protection सेंसर द्वारा अवरुद्ध या प्रभावी रूप से पता लगाए बिना एंडपॉइंट पर निष्पादित किया जा सके। उपरोक्त लेख उन कमजोरियों का वर्णन करता है जो प्रकटीकरण के बाद भी Microsoft Defender Advanced Threat Protection में अभी भी मौजूद हैं।

इंस्टॉल करें

पहला कदम हमेशा की तरह रिपॉजिटरी को क्लोन करना है, फिर इसे बिल्ड करें

go build Dent.go

सहायता

./Dent -h
 
________                 __   
\______ \   ____   _____/  |_ 
 |    |  \_/ __ \ /    \   __\
 |    |   \  ___/|   |  \  |  
/_______  /\___  >___|  /__|  
        \/     \/     \/      
                (@Tyl0us)

"Call someone a hero long enough, and they'll believe it. They'll become it. 
They have no choice. Let them call you a monster, and you become a monster."


Usage of ./Dent:
  -C string
        Name of the COM object.
  -N string
        Name of the XLL playload when it's writen to disk.
  -O string
        Name of the output file. (default "output.txt")
  -P string
        Path of the DLL for your COM object. (Either use \\ or '' around the path)
  -U string
        URL where the base64 encoded XLL payload is hosted.
  -show
        Display the script in the terminal.

शस्त्रीकरण

यह फ्रेमवर्क Microsoft Defender Advanced Threat Protection में कमजोरियों और कमियों का शोषण करने के लिए है, इसलिए यह वास्तव में कोई पेलोड/इम्प्लांट उत्पन्न नहीं करता है। उन्हें उत्पन्न करने के लिए, आप सार्वजनिक रूप से उपलब्ध बड़ी संख्या में टूल का उपयोग कर सकते हैं, हालांकि सभी शोध, विकास और परीक्षण ScareCrow का उपयोग करके किए गए थे। Microsoft Defender Advanced Threat Protection टेलीमेट्री के लिए यूजरलैंड हुकिंग पर निर्भर नहीं करता है, बल्कि यह कर्नेल कॉलबैक जैसे विभिन्न अन्य तंत्रों का उपयोग करता है। परीक्षण से, यह फ्रेमवर्क शेलकोड निष्पादित करने के लिए Microsoft Defender Advanced Threat Protection को बायपास करने में बहुत अच्छा काम करता है।

तकनीकें

रिलीज़ के समय वर्तमान में दो तकनीकें हैं। मैं समय-समय पर अलग-अलग तकनीकें जोड़ता रहूँगा जो इन कमजोरियों का विभिन्न तरीकों से उपयोग करती हैं, कृपया और अधिक के लिए बने रहें।

नकली COM ऑब्जेक्ट मोड

जब कोई एप्लिकेशन सिस्टम पर इंस्टॉल किया जा रहा होता है तो अक्सर COM ऑब्जेक्ट बनाए जाते हैं। एक बार बनने के बाद, कोई भी एप्लिकेशन या स्क्रिप्ट उन्हें कॉल कर सकती है, हालांकि इन्हें बनाने का यही एकमात्र तरीका नहीं है। विंडोज़ रजिस्ट्री के HKEY_CLASSES_ROOT अनुभाग में रजिस्ट्री कुंजियों को संशोधित/बनाकर, हम एक COM ऑब्जेक्ट बना सकते हैं जो सिस्टम पर हमारे शेलकोड की ओर इशारा करता है। इसका मतलब है कि कोई भी एप्लिकेशन या स्क्रिप्ट जो COM का उपयोग कर सकती है, वह इसे कॉल कर सकती है, जिससे शेलकोड निष्पादित हो जाता है।

यह इसलिए काम करता है क्योंकि CoCreatInstance API फ़ंक्शन कैसे काम करता है। CoCreateInstance का उपयोग CLSID (एक वैश्विक रूप से अद्वितीय पहचानकर्ता जो किसी विशिष्ट COM क्लास ऑब्जेक्ट की पहचान करता है) के आधार पर COM ऑब्जेक्ट बनाने और प्रारंभ करने के लिए किया जाता है। यह फ़ंक्शन रजिस्ट्री कुंजियों में संग्रहीत मानों का उपयोग करके कॉल को निष्पादित करने के लिए जानकारी प्राप्त करता है। ये CLSID मान रजिस्ट्री के HKEY_CLASSES_ROOT\CLSID\ पथ में पाए जा सकते हैं। हालांकि, किसी प्रक्रिया द्वारा CLSID को कॉल करने से पहले, उसे उस CLSID का मान ज्ञात होना चाहिए। यह पहले HKEY_CLASSES_ROOT\<COM object name> में COM ऑब्जेक्ट को देखने के लिए एक रजिस्ट्री क्वेरी करके किया जाता है, और यदि यह मौजूद है, तो उपफ़ोल्डर में संग्रहीत CLSID मान प्राप्त करने के लिए दूसरी रजिस्ट्री क्वेरी की जाएगी।

रजिस्ट्री के उपफ़ोल्डरों की आगे की जाँच से पता चलता है कि CLSID मानों की अनुमति सुसंगत नहीं है। यहाँ संग्रहीत COM ऑब्जेक्ट्स का एक बड़ा हिस्सा केवल Trusted Installer को "Full Control" अनुमति देता है। Trusted Installer एक सेवा खाता है जो संसाधनों का मालिक होता है ताकि उन्हें प्रशासकों से भी सुरक्षित रखा जा सके। इसका उद्देश्य यह सुनिश्चित करना है कि भले ही कोई हमलावर प्रशासनिक विशेषाधिकार प्राप्त कर ले, संसाधनों में दुर्भावनापूर्ण तरीके से हेरफेर नहीं किया जा सकता। दुर्भाग्य से, बहुत सारे COM ऑब्जेक्ट्स प्रशासकों समूह के किसी भी व्यक्ति को "Full Control" अनुमति देते हैं। इसके अलावा, रूट कुंजी CLSID प्रशासकों समूह को "Full Control" अनुमति देती है, न कि NT AUTHORITY\System या Trusted Installer को। इसके कारण, एक उन्नत संदर्भ के तहत हम विशिष्ट COM ऑब्जेक्ट मान बना सकते हैं या उन्हें संशोधित भी कर सकते हैं।

महत्वपूर्ण

इन रजिस्ट्री कुंजियों का निर्माण केवल तभी काम करता है जब आप इसे एक उन्नत संदर्भ (elevated context) में चलाते हैं। GUI के माध्यम से डबल-क्लिक करने से .VBS फ़ाइल एक उन्नत संदर्भ में निष्पादित नहीं होगी, भले ही आप एक प्रशासक हों। यह अनुशंसा की जाती है कि आप इसे एक प्रशासनिक शेल या कमांड प्रॉम्प्ट से चलाएँ। हालांकि, एक बार कुंजियाँ बन जाने के बाद, कोई भी एप्लिकेशन किसी भी संदर्भ में इस COM ऑब्जेक्ट को कॉल कर सकता है।

ScareCrow शस्त्रीकरण

इस प्रकार के बायपास के साथ ScareCrow पेलोड का उपयोग करने के लिए, आप निम्न कमांड चला सकते हैं:

./ScareCrow -I <path to your raw stageless shellcode>  -domain <domain name> -Loader dll

उपयोग

एक बार जब आपके पास आपका पेलोड हो, तो डिस्क पर लिखे जाने पर पेलोड के नाम के लिए -N फ़्लैग, COM ऑब्जेक्ट के नाम के लिए -C फ़्लैग, इसे लिखने के स्थान के लिए -I फ़्लैग, और सामग्री संग्रहीत करने के लिए आउटपुट फ़ाइल के लिए -O फ़्लैग का उपयोग करें।

रिमोट .XLL पेलोड मोड

यह विकल्प ASR के कई नियमों को बायपास करने के लिए कोड का एक ब्लॉक उत्पन्न करता है ताकि शेलकोड को डाउनलोड, डिस्क पर लिखा, लोड और निष्पादित किया जा सके, ASR के निवारक नियंत्रणों को बायपास करते हुए। यह Excel.Application COM ऑब्जेक्ट का उपयोग करके किया जाता है जो संपूर्ण Excel एप्लिकेशन का प्रतिनिधित्व करता है, लेकिन एक स्वचालित रूप में, और इसके साथ प्रोग्रामेटिक रूप से बातचीत करने की अनुमति देता है। क्योंकि यह अभी भी Excel है, यह ASR नियम को ट्रिगर नहीं करता है। ऐसा इसलिए है क्योंकि जब हम Excel.Application को कॉल करते हैं, तो हम देख सकते हैं कि यह एक सेवा होस्ट प्रक्रिया (Svchost.exe) के तहत उत्पन्न होता है न कि WinWord.exe प्रक्रिया के तहत। जबकि Svchost.exe एक सिस्टम-स्तरीय प्रक्रिया है जिसका उपयोग कई विंडोज़-आधारित सेवाओं को होस्ट करने के लिए किया जाता है, बनाई गई चाइल्ड प्रक्रिया (Excel.exe) को सिस्टम-स्तरीय विशेषाधिकार नहीं मिले।

क्योंकि हमने एक COM ऑब्जेक्ट बनाया जो एक संपूर्ण एप्लिकेशन था, Excel प्रक्रिया Svchost.exe के तहत बनाई गई थी ताकि इसे ठीक से संभाला जा सके और WinWord.exe प्रक्रिया में किसी भी अस्थिरता को रोका जा सके। हालांकि यह प्रक्रिया Svchost.exe के तहत है, एक और चुनौती से निपटना है: शेलकोड निष्पादित करना। चूंकि बाइनरी निष्पादन या मैक्रो के अंदर WinAPI का उपयोग करने से अन्य ASR नियम ट्रिगर होंगे, यह सीमित करता है कि हम ASR नियम को ट्रिगर किए बिना या WDAPT के EDR घटक द्वारा पकड़े बिना क्या कर सकते हैं। यहीं पर DLLs चमकती हैं। यदि एक DLL-आधारित पेलोड को सही एक्सपोर्ट फ़ंक्शन के साथ संकलित किया गया है, तो इसका उपयोग Office प्लगइन के रूप में किया जा सकता है, जो लोड होने पर स्वचालित रूप से शेलकोड चलाएगा। ऐसा करने के लिए, हम Excel के RegisterXLL फ़ंक्शन का उपयोग कर सकते हैं। RegisterXLL फ़ंक्शन एक XLL प्लगइन को मेमोरी में लोड करता है, स्वचालित रूप से उसे पंजीकृत और निष्पादित करता है। XLL फ़ाइलें मूलतः Excel-आधारित DLLs हैं।

सिस्टम पर सामग्री प्राप्त करने के लिए, हम एक अन्य COM ऑब्जेक्ट (Microsoft.XMLHTTP) का उपयोग कर सकते हैं, जो एक HTTP अनुरोध (इस मामले में, एक URL पर एक HTTP GET अनुरोध) निष्पादित करने की क्षमता प्रदान करता है। दूसरा COM ऑब्जेक्ट (ADODB.stream) डेटा स्ट्रीम के बाइट्स को पढ़ने/लिखने की क्षमता प्रदान करता है। दोनों COM ऑब्जेक्ट्स को संयोजित करके, एक हमलावर HTTP GET अनुरोध के माध्यम से एक दूरस्थ संसाधन का अनुरोध कर सकता है और प्रतिक्रिया (इस मामले में, फ़ाइल स्वयं) को डिस्क पर लिख सकता है। यह डेटा स्ट्रीम के बाइट्स को संभालने के लिए फिर से COM ऑब्जेक्ट (ADODB.stream) का उपयोग करके किया जाता है। दूसरा COM ऑब्जेक्ट (Microsoft.XMLDOM) एक फ़ाइल में संग्रहीत डेटा को पढ़ने की अनुमति देता है। XMLDCOM ऑब्जेक्ट डेटा प्रकार सेट करने की अनुमति देता है (इस मामले में, base64) और एक बार उचित डेटाटाइप के साथ खोला और एक स्ट्रिंग में संग्रहीत किया जाता है, तो ADODB.stream ऑब्जेक्ट एक अलग डेटा प्रकार (इस मामले में, BinaryStreamType) का उपयोग करके कोड की स्ट्रिंग को डिस्क पर लिख सकता है, base64 स्ट्रिंग को वापस बाइनरी रूप में परिवर्तित करता है।

ScareCrow शस्त्रीकरण

इस प्रकार के बायपास के साथ ScareCrow पेलोड का उपयोग करने के लिए, आप निम्न कमांड चला सकते हैं:

./ScareCrow -I <path to your raw stageless shellcode>  -domain <domain name> -Loader excel  -O <Output filename>

एक बार उत्पन्न होने के बाद, आउटपुट फ़ाइल से पंक्ति 13 और 14 को कॉपी करें, और उन्हें एक साथ मर्ज करें, यह सुनिश्चित करते हुए कि निम्नलिखित हटा दें:

• var <variable name>
• प्रत्येक पंक्ति के अंत में ;
• प्रत्येक स्ट्रिंग के चारों ओर उद्धरण चिह्न

उपयोग

एक बार जब आपके पास आपका एन्कोडेड पेलोड हो, तो डिस्क पर लिखे जाने पर पेलोड के नाम के लिए -N फ़्लैग, एन्कोडेड पेलोड के होस्ट किए जाने वाले URL के लिए -U फ़्लैग (अर्थात https:///), और साइट द्वारा होस्ट की जा रही फ़ाइल के नाम के लिए -F फ़्लैग का उपयोग करें। आउटपुट कोड एक मैक्रो दस्तावेज़ में काम करने के लिए डिज़ाइन किया गया है।

WDAPT सेंसर रिकॉर्डिंग का अभाव

आगे की जाँच के माध्यम से, यह WDATP के सेंसर में एक अंतराल के रूप में नहीं, बल्कि यह देखा गया कि WDATP को इस गतिविधि में दृश्यता है, लेकिन इसे अनदेखा किया जाता है। WDATP के एंडपॉइंट की घटनाओं की समयरेखा के माध्यम से Appwiz.xll के किसी भी संदर्भ की खोज करने पर, हमने देखा कि जब Word ने फ़ाइल AppWiz.xll बनाई, तो WDAPT ने एक "फ़ाइल बनाई गई" घटना दर्ज की। यह ध्यान रखना महत्वपूर्ण है कि .XLL फ़ाइलें निष्पादन योग्य होती हैं।

प्रकटीकरण समय

11/20/2020 - अनुसंधान विकास और लेख लिखा गया।

03/14/2021 - Microsoft को एक प्रारंभिक प्रकटीकरण दस्तावेज़ प्रदान किया गया जिसमें पहचाने गए मुद्दों की रूपरेखा दी गई।

03/31/2021 - Microsoft ने माना और स्वीकार किया कि Office चाइल्ड प्रक्रिया को उत्पन्न करने और फ़ाइलों को डिस्क पर लिखने से संबंधित कमजोरियाँ वास्तविक कमजोरियाँ थीं और उन्होंने सुधार पर काम करना शुरू किया। हालांकि, रजिस्ट्री में अनुमतियों की असंगतियों को उन्नत विशेषाधिकारों की आवश्यकता के कारण कमजोरी नहीं माना गया।

04/21/2021 - Microsoft ने लेखक को सूचित किया कि 03/22/2021 को जारी सिग्नेचर बिल्ड 1.333.1055.0 और 04/21/2021 को जारी 1.335.1321.0 में Office एप्लिकेशन-आधारित कमजोरियों के लिए पहचान शामिल थी और मामला बंद कर दिया।

04/22/2021 - लेखक ने उन्हीं तकनीकों का पुनः परीक्षण किया और पाया कि कमजोरियाँ अभी भी मौजूद हैं।