
XLL फिशिंग तकनीक
Microsoft के हालिया घोषणा के अनुसार इंटरनेट (ईमेल और वेब डाउनलोड) से आने वाले दस्तावेज़ों में मैक्रो को ब्लॉक करने के बाद, हमलावरों ने उपयोगकर्ता-संचालित पहुंच (UDA) प्राप्त करने के लिए अन्य विकल्पों को आक्रामक रूप से खोजना शुरू कर दिया है। फिशिंग के लिए एक व्यवहार्य पहुंच विधि की तलाश करते समय कई कारकों पर विचार और संतुलन बनाना होता है:
ये प्रमुख प्रश्न हैं, हालांकि निश्चित रूप से और भी हैं। चीजें और जटिल हो जाती हैं जब आप महसूस करते हैं कि ये कारक एक-दूसरे को प्रभावित करते हैं; उदाहरण के लिए, यदि किसी क्लाइंट के पास वेब प्रॉक्सी है जो एक्ज़ीक्यूटेबल या DLL के डाउनलोड को प्रतिबंधित करता है, तो आपको अपने पेलोड को किसी कंटेनर (ZIP, ISO, आदि) के अंदर रखने की आवश्यकता हो सकती है। ऐसा करने से आगे चलकर पहचान के मामले में और समस्याएं उत्पन्न हो सकती हैं। अधिक मजबूत रक्षा उपायों को हराने के लिए तकनीकों के अधिक जटिल संयोजनों की आवश्यकता होती है।
यह लेख एक काल्पनिक लक्ष्य संगठन को ध्यान में रखकर लिखा गया है; इस संगठन ने कई रक्षात्मक उपाय अपनाए हैं जिनमें ईमेल फ़िल्टरिंग नियम, कुछ फ़ाइल प्रकारों को डाउनलोड करने से प्रतिबंधित करना, एंडपॉइंट पर एप्लिकेशन व्हाइटलिस्टिंग, और EDR समाधान के रूप में Microsoft Defender for Endpoint शामिल हैं।
वास्तविक संगठन इनमें से कोई भी, कुछ, या और भी अधिक रक्षा उपाय अपना सकते हैं जो इस शोध में उल्लिखित तकनीकों को सरल या जटिल बना सकते हैं। हमेशा की तरह, अपने लक्ष्य को जानें।
XLL विशेष रूप से Microsoft Excel के लिए तैयार किए गए DLL होते हैं। अपरिचित आंखों के लिए वे सामान्य एक्सेल दस्तावेज़ों की तरह दिखते हैं।

XLL, UDA के लिए एक बहुत ही आकर्षक विकल्प प्रदान करते हैं क्योंकि उन्हें Microsoft Excel द्वारा निष्पादित किया जाता है, जो क्लाइंट नेटवर्क में एक बहुत ही सामान्य रूप से पाया जाने वाला सॉफ़्टवेयर है; एक अतिरिक्त लाभ के रूप में, क्योंकि वे Excel द्वारा निष्पादित होते हैं, हमारा पेलोड लगभग निश्चित रूप से एप्लिकेशन व्हाइटलिस्टिंग नियमों को बायपास करेगा क्योंकि एक विश्वसनीय एप्लिकेशन (Excel) इसे निष्पादित कर रहा है। XLL को C, C++, या C# में लिखा जा सकता है जो VBA मैक्रो की तुलना में कहीं अधिक लचीलापन और शक्ति (और समझदारी) प्रदान करता है, जो उन्हें और भी वांछनीय विकल्प बनाता है।
बेशक नकारात्मक पक्ष यह है कि XLL के बहुत कम वैध उपयोग हैं, इसलिए संगठनों के लिए ईमेल और वेब डाउनलोड दोनों के माध्यम से उस फ़ाइल एक्सटेंशन के डाउनलोड को ब्लॉक करना एक बहुत ही आसान काम होना चाहिए। दुख की बात है कि कई संगठन वक्र से वर्षों पीछे हैं और इस तरह XLL कुछ समय के लिए फिशिंग का एक व्यवहार्य तरीका बना रहेगा।
XLL के अंदर कोड निष्पादित करने के लिए घटनाओं की एक श्रृंखला का उपयोग किया जा सकता है, जिनमें से सबसे उल्लेखनीय xlAutoOpen है। पूरी सूची यहाँ देखी जा सकती है:

XLL पर डबल-क्लिक करने पर, उपयोगकर्ता को यह स्क्रीन दिखाई देती है:

यह एकमात्र डायलॉग बॉक्स है जो उपयोगकर्ता और कोड निष्पादन के बीच खड़ा है; काफी पतली सोशल इंजीनियरिंग के साथ, कोड निष्पादन लगभग निश्चित है।
एक बात जिसे ध्यान में रखना चाहिए वह यह है कि XLL, एक्ज़ीक्यूटेबल होने के कारण, आर्किटेक्चर-विशिष्ट होते हैं। इसका मतलब है कि आपको अपने लक्ष्य को जानना चाहिए; लक्ष्य संगठन जिस Microsoft Office/Excel संस्करण का उपयोग करता है वह (आमतौर पर) यह निर्धारित करेगा कि आपको अपना पेलोड किस आर्किटेक्चर के लिए बनाना चाहिए।
Office संस्करणों में एक काफी स्पष्ट विभाजन है जिसे एक सामान्य नियम के रूप में उपयोग किया जा सकता है:
Office 2016 या उससे पहले: x86
Office 2019 या बाद में: x64
यह ध्यान दिया जाना चाहिए कि प्रत्येक उत्पाद के लिए दूसरे आर्किटेक्चर को स्थापित करना संभव है, हालांकि ये स्थापित डिफ़ॉल्ट आर्किटेक्चर हैं और ज्यादातर मामलों में यह तय करने का एक विश्वसनीय तरीका होना चाहिए कि आपका XLL किस आर्किटेक्चर के लिए बनाया जाए। निश्चित रूप से फिशिंग अभियान के हिस्से के रूप में उपयोग की जाने वाली वितरण विधि और प्रीटेक्स्टिंग के आधार पर, दोनों संस्करण प्रदान करना और पीड़ित पर अपने सिस्टम के लिए उपयुक्त संस्करण का चयन करने का भरोसा करना संभव है।
इस शोध के दौरान बनाया गया XLL पेलोड edparcell द्वारा इस प्रोजेक्ट पर आधारित था। उनके रिपॉजिटरी में विज़ुअल स्टूडियो में XLL के साथ शुरुआत करने के अच्छे निर्देश हैं, और मैंने एक दुर्भावनापूर्ण XLL फ़ाइल विकसित करने के लिए उनके कोड को एक प्रारंभिक बिंदु के रूप में उपयोग किया।
उनके रिपॉजिटरी से एक उल्लेखनीय विचलन यह है कि यदि आप अपना स्वयं का XLL प्रोजेक्ट बनाना चाहते हैं, तो आपको नवीनतम Excel SDK डाउनलोड करना होगा और फिर पहले से जुड़े रिपो में दिए गए निर्देशों का पालन करना होगा, README में उल्लिखित SDK के 2010 संस्करण के बजाय इस संस्करण का उपयोग करते हुए।
UDA के संदर्भ में पेलोड का वितरण एक गंभीर विचार है। दो प्राथमिक विधियाँ हैं जिन पर हम ध्यान केंद्रित करेंगे:
या तो एक फ़ाइल संलग्न करके या किसी वेबसाइट के लिंक को शामिल करके जहां से फ़ाइल डाउनलोड की जा सकती है, ईमेल UDA प्रक्रिया का एक महत्वपूर्ण हिस्सा है। पिछले कुछ वर्षों में कई संगठनों (और ईमेल प्रदाताओं) ने उपयोगकर्ताओं और संगठनों को दुर्भावनापूर्ण अटैचमेंट से बचाने के लिए नियमों को परिपक्व और लागू किया है। परिणाम भिन्न हो सकते हैं, लेकिन संगठनों के पास अब यह क्षमता है:
किसी संगठन के ईमेल नियमों को फ़ज़ करना एक जुड़ाव का एक महत्वपूर्ण हिस्सा हो सकता है, हालांकि हमेशा सावधानी बरतनी चाहिए ताकि यह संकेत न दिया जाए कि रेड टीम ऑपरेशन चल रहा है और सक्रिय रूप से जानकारी एकत्र की जा रही है।
इस लेख के प्रयोजनों के लिए, यह मान लिया जाएगा कि लक्ष्य संगठन में मजबूत ईमेल अटैचमेंट नियम हैं जो XLL पेलोड की डिलीवरी को रोकते हैं। हम पिवट करेंगे और वेब वितरण को देखेंगे।
इस हमले वेक्टर में ईमेल का अभी भी उपयोग किया जाएगा, हालांकि अटैचमेंट भेजने के बजाय इसका उपयोग किसी वेबसाइट के लिंक भेजने के लिए किया जाएगा। अनुमत फ़ाइल डाउनलोड प्रकारों को नियंत्रित करने वाले वेब प्रॉक्सी नियम और नेटवर्क शमन ईमेल अटैचमेंट के संबंध में लागू किए गए नियमों से भिन्न हो सकते हैं। इस लेख के प्रयोजनों के लिए, यह मान लिया गया है कि संगठन वेब से एक्ज़ीक्यूटेबल फ़ाइलों (MZ हेडर) के डाउनलोड को रोकता है। ऐसी स्थिति में, पैकर/कंटेनर का पता लगाना सार्थक है।
मूल विचार यह है कि हम अपने एक्ज़ीक्यूटेबल को किसी अन्य फ़ाइल प्रकार के अंदर रखकर संगठन की नीतियों को बायपास कर सकते हैं। यहां एक प्रमुख विचार फ़ाइल प्रकार के लिए मूल समर्थन है; उदाहरण के लिए, 7Z फ़ाइलों को Windows द्वारा तृतीय-पक्ष सॉफ़्टवेयर स्थापित किए बिना नहीं खोला जा सकता, इसलिए वे एक अच्छा विकल्प नहीं हैं। ZIP, ISO, और IMG जैसे प्रारूप आकर्षक विकल्प हैं क्योंकि वे मूल रूप से Windows द्वारा समर्थित हैं, और एक अतिरिक्त लाभ के रूप में, वे पीड़ित के लिए बहुत कम अतिरिक्त कदम जोड़ते हैं।
दुर्भाग्य से संगठन ISO और IMG को वेब से डाउनलोड होने से रोकता है; इसके अतिरिक्त, क्योंकि वे डेटा लॉस प्रिवेंशन (DLP) का उपयोग करते हैं, उपयोगकर्ता बाहरी स्टोरेज डिवाइस माउंट करने में असमर्थ हैं, जो ISO और IMG माने जाते हैं।
हमारे लिए सौभाग्य से, भले ही संगठन MZ-हेडर वाली फ़ाइलों के डाउनलोड को रोकता है, यह एक्ज़ीक्यूटेबल वाली ज़िप फ़ाइलों के डाउनलोड की अनुमति देता है। इन ज़िप फ़ाइलों को सक्रिय रूप से मैलवेयर के लिए स्कैन किया जाता है, जिसमें पासवर्ड-संरक्षित ज़िप फ़ाइलों के लिए उपयोगकर्ता से पासवर्ड मांगना शामिल है; हालांकि क्योंकि एक्ज़ीक्यूटेबल ज़िप्ड है, यह अन्यथा MZ फ़ाइलों के लिए सामान्य इनकार द्वारा अवरुद्ध नहीं होता है।
ज़िप फ़ाइलों को हमारे XLL पेलोड के लिए कंटेनर के रूप में चुना गया क्योंकि:
सुविधाजनक रूप से, Windows पर ZIP फ़ाइल पर डबल-क्लिक करने से वह ज़िप फ़ाइल फ़ाइल एक्सप्लोरर में खुल जाती है:

कम सुविधाजनक रूप से, ज़िप किए गए स्थान से XLL फ़ाइल पर डबल-क्लिक करने से Windows Defender ट्रिगर हो जाता है; यहां तक कि edparcell के स्टॉक प्रोजेक्ट का उपयोग करने पर भी जिसमें किसी भी प्रकार का दुर्भावनापूर्ण कोड नहीं है।

Windows Defender अलर्ट को देखने पर यह केवल एक सामान्य "Wacatac" अलर्ट है:

हालांकि कुछ अजीब है; इसने जिस फ़ाइल को दुर्भावनापूर्ण के रूप में पहचाना वह c:\users\user\Appdata\Local\Temp\Temp1_ZippedXLL.zip\ में थी, न कि C:\users\user\Downloads\ZippedXLL\ में जहां हमने उस पर डबल-क्लिक किया था। ProcessExplorer में Excel इंस्टेंस को देखने पर पता चलता है कि Excel वास्तव में XLL को appdata\local\temp से चला रहा है, न कि ZIP फ़ाइल से जहां से वह आया था:

यह ZIP फ़ाइलों से जुड़ी एक समस्या प्रतीत होती है, XLL से नहीं। ज़िप के अंदर से notepad का उपयोग करके TXT फ़ाइल खोलने पर भी TXT फ़ाइल appdata\local\temp में कॉपी हो जाती है और वहां से खुलती है। जबकि इस स्थान से टेक्स्ट फ़ाइल खोलना ठीक है, Defender इस स्थान पर किसी भी प्रकार के वास्तविक कोड निष्पादन को दुर्भावनापूर्ण मानता है।
यदि उपयोगकर्ता XLL को ZIP फ़ाइल से निकालकर चलाता है, तो यह बिना किसी समस्या के निष्पादित होगा; हालांकि इस बात की कोई गारंटी नहीं है कि उपयोगकर्ता ऐसा करेगा, और यदि वे इसे निकालते नहीं हैं तो हम वास्तव में AV/EDR को पॉप करने का जोखिम नहीं उठा सकते। इसके अलावा, ZIP पर डबल-क्लिक करना और फिर XLL पर डबल-क्लिक करना कहीं अधिक सरल है और पीड़ित के इन सरल कार्यों को पूरा करने की अधिक संभावना है, बजाय ZIP को निकालने की परेशानी में पड़ने के।
इस समस्या ने मुझे XLL से भिन्न पेलोड प्रकार पर विचार करने के लिए प्रेरित किया; मैंने VSTO का पता लगाना शुरू किया, जो Office के लिए विज़ुअल स्टूडियो टेम्पलेट हैं। मैं आपको उस लेख को पढ़ने के लिए प्रोत्साहित करता हूं।
VSTO अंततः एक DLL को कॉल करते हैं जो या तो सब कुछ शुरू करने वाले .XLSX के साथ स्थानीय रूप से स्थित हो सकता है, या .XLSX द्वारा http/https के माध्यम से रिमोटली होस्ट और डाउनलोड किया जा सकता है। स्थानीय विकल्प कोई वास्तविक लाभ प्रदान नहीं करता (और वास्तव में कई नुकसान हैं क्योंकि VSTO हमले से जुड़ी कई और फ़ाइलें हैं), और रिमोट विकल्प को दुर्भाग्य से एक कोड साइनिंग प्रमाणपत्र या रिमोट स्थान के एक विश्वसनीय नेटवर्क होने की आवश्यकता होती है। वैध कोड साइनिंग प्रमाणपत्र न होने के कारण, VSTO इस परिदृश्य में किसी भी समस्या को कम नहीं करते हैं जो हमारे XLL पेलोड का सामना कर रहा है।
हम वास्तव में एक कोने में फंसे हुए प्रतीत होते हैं। XLL को चलाना अपने आप में ठीक है, हालांकि XLL को संगठन नीति के कारण ईमेल अटैचमेंट या वेब डाउनलोड के माध्यम से अकेले पीड़ित तक नहीं पहुंचाया जा सकता है। XLL को एक कंटेनर के अंदर पैकेज करने की आवश्यकता है, हालांकि DLP के कारण ISO, IMG, और VHD जैसे प्रारूप व्यवहार्य नहीं हैं। पीड़ित को किसी तृतीय-पक्ष सॉफ़्टवेयर के बिना मूल रूप से कंटेनर खोलने में सक्षम होना चाहिए, जो वास्तव में ZIP को एकमात्र विकल्प के रूप में छोड़ देता है; हालांकि जैसा कि चर्चा की गई, ज़िप किए गए फ़ोल्डर से XLL चलाने पर यह appdata\local\temp में कॉपी और चलाया जाता है जो AV को फ़्लैग करता है।
मैंने घंटों विचार-मंथन और परीक्षण किया, VSTO खरगोश के बिल में गया, सभी संभावित विकल्पों की खोज की जब तक कि अंततः मैंने कुछ इतना बेवकूफी भरा करने का फैसला नहीं किया कि यह काम कर सकता है।
इस बार मैंने एक फ़ोल्डर बनाया, उसके अंदर XLL रखा, और फिर फ़ोल्डर को ज़िप किया:

फ़ोल्डर पर क्लिक करने पर XLL फ़ाइल दिखाई देती है:

XLL पर डबल-क्लिक करने पर Excel से Add-In प्रॉम्प्ट दिखाई देता है। ध्यान दें कि XLL अभी भी appdata\local\temp में कॉपी होता है, हालांकि हमारे द्वारा बनाए गए अतिरिक्त फ़ोल्डर के कारण एक अतिरिक्त परत है:

सक्षम पर क्लिक करने पर बिना Defender को फ़्लैग किए हमारा कोड निष्पादित होता है:

बढ़िया! कोड निष्पादन। अब आगे क्या?
पीड़ित को XLL डाउनलोड और निष्पादित करने में शामिल प्रीटेक्स्टिंग संगठन और वितरण विधि के आधार पर बहुत भिन्न होगी; थीम में कर्मचारी वेतन डेटा, कौशल सेट के आधार पर मुआवजे के लिए कैलकुलेटर, किसी प्रोजेक्ट के बारे में जानकारी, किसी कार्यक्रम के लिए उपस्थिति रोस्टर आदि शामिल हो सकते हैं। लालच जो भी हो, हमारा हमला अधिक प्रभावी होगा यदि हम वास्तव में पीड़ित को वह प्रदान करते हैं जो उनसे वादा किया गया है। अनुवर्ती कार्रवाई के बिना, पीड़ित संदिग्ध हो सकते हैं और दस्तावेज़ को अपनी सुरक्षा टीमों को रिपोर्ट कर सकते हैं जो हमलावर को जल्दी से बेनकाब कर सकता है और लक्ष्य सिस्टम तक पहुंच को कम कर सकता है।
XLL अपने आप में हमारा कोड निष्पादित होने के बाद केवल एक खाली Excel विंडो छोड़ेगा; हमारे लिए बेहतर होगा कि हम वह Excel स्प्रेडशीट प्रदान करें जिसकी पीड़ित तलाश कर रहा है।
हम अपने XLSX को XLL के अंदर एक बाइट ऐरे के रूप में एम्बेड कर सकते हैं; जब XLL निष्पादित होता है, तो यह XLL के बगल में डिस्क पर XLSX ड्रॉप करेगा, जिसके बाद इसे खोला जाएगा। हम XLSX को XLL के समान नाम देंगे, केवल एक्सटेंशन में अंतर होगा।
यह देखते हुए कि हमारा XLL C में लिखा गया है, हम C में पेलोड क्षमताओं पर मेरे पिछले लेखन से कुछ क्षमताओं को ला सकते हैं, अर्थात् सेल्फ-डिलीशन। इन दो तकनीकों को मिलाकर XLL डिस्क से हटा दिया जाता है, और उसके स्थान पर उसी नाम का XLSX ड्रॉप किया जाता है। अप्रशिक्षित आंखों के लिए, ऐसा प्रतीत होगा कि XLSX हर समय वहीं था।
दुर्भाग्य से जहां XLL हटाया जाता है और XLSX ड्रॉप किया जाता है वह स्थान appdata\temp\local फ़ोल्डर है, मूल ZIP नहीं; इसे संबोधित करने के लिए हम अकेले XLSX वाला दूसरा ZIP बना सकते हैं और इसे XLL के अंदर एक बाइट ऐरे के रूप में भी पढ़ सकते हैं। निष्पादन पर उपरोक्त कार्यों के अतिरिक्त, XLL c:\users\victim\Downloads\ में मूल ZIP फ़ाइल का पता लगाने और उसे हटाने का प्रयास कर सकता है, इससे पहले कि वह अपने स्थान पर केवल XLSX वाला दूसरा ZIP ड्रॉप करे। यह निश्चित रूप से विफल हो सकता है यदि उपयोगकर्ता ने मूल ZIP को किसी भिन्न स्थान या अलग नाम से सहेजा है, हालांकि कई/अधिकांश मामलों में यह स्वचालित रूप से उपयोगकर्ता के डाउनलोड फ़ोल्डर में गिर जाना चाहिए।

यह स्क्रीनशॉट निचले फलक में appdata\local\temp में बनाए गए अस्थायी फ़ोल्डर को दिखाता है जिसमें XLL और ड्रॉप किया गया XLSX है, जबकि ऊपरी फलक मूल फ़ाइल एक्सप्लोरर विंडो दिखाता है जहां से XLL खोला गया था। निचले फलक में ध्यान दें कि XLL का आकार 0 है। ऐसा इसलिए है क्योंकि इसने निष्पादन के दौरान स्वयं को हटा दिया, हालांकि जब तक ऊपरी फलक बंद नहीं किया जाता, XLL फ़ाइल appdata\local\temp स्थान से पूरी तरह से गायब नहीं होगी। भले ही पीड़ित फिर से XLL पर क्लिक करे, यह अब निष्क्रिय है और वास्तव में मौजूद नहीं है।
इसी तरह, जैसे ही पीड़ित फ़ाइल एक्सप्लोरर में खुली ZIP से बाहर निकलता है (या तो इसे बंद करके या किसी भिन्न फ़ोल्डर में नेविगेट करके), यदि वे फिर से spreadsheet.zip पर क्लिक करते हैं तो उन्हें अब पता चलेगा कि test फ़ोल्डर में importantdoc.xlsx है; इसलिए XLL को डिस्क पर मौजूद दोनों स्थानों से हटा दिया गया है और हानिरहित XLSX द्वारा बदल दिया गया है।
यह GIF MDE ट्रायल VM पर XLL के डाउनलोड और निष्पादन को प्रदर्शित करता है। ध्यान दें कि किसी कारण से Excel यहां दो इंस्टेंस खोलता है; मेरे घरेलू कंप्यूटर पर इसने केवल एक खोला, इसलिए निश्चित नहीं कि यह क्यों भिन्न है।

हमेशा की तरह, हम पूछेंगे "MDE क्या देखता है?"
यह साबित करने के लिए एक त्वरित स्क्रीनशॉट डंप कि मैंने इसे लक्ष्य पर निष्पादित किया और TestMachine11 पर वापस एक बीकन पकड़ा:



सबसे पहले, शून्य अलर्ट:

टाइमलाइन/इवेंट लॉग क्या कैप्चर करता है?

ओह। सच कहूं तो मुझे नहीं पता कि कीलॉगिंग, एन्क्रिप्टिंग और डिक्रिप्टिंग क्रेडेंशियल्स अलर्ट कहां से आ रहे हैं क्योंकि मेरा कोड ऐसा कुछ नहीं करता है। जब इस तरह से बिछाया जाता है तो हमारी कार्रवाई निश्चित रूप से संदिग्ध लगती है, लेकिन मैं फिर से टिप्पणी करूंगा कि MDE द्वारा एक एकल एंडपॉइंट पर कितना डेटा एकत्र किया जाता है, अकेले सैकड़ों, हजारों, या सैकड़ों हजारों को छोड़ दें जो एक संगठन EDR में हुक कर सकता है। जब तक हम कोई वास्तविक अलर्ट नहीं फेंक रहे हैं, हम शायद ठीक हैं।
वह क्षण जिसका अधिकांश लोग शायद इंतजार कर रहे थे, मैं अपने विकसित XLL रनर का एक कोड नमूना प्रदान कर रहा हूं, जो केवल उन भागों तक सीमित है जिनकी चर्चा यहां ट्रेडक्राफ्ट अनुभाग में की गई है। पाठक को वास्तव में कोड को XLL में प्राप्त करना और इसे अपने शेष रनर के साथ संयोजन में लागू करना होगा। हमेशा की तरह, कोई नुकसान न करें, फिशिंग करने के लिए किसी संगठन से अनुमति लें, आदि।
मैंने एक प्रोग्राम का सोर्स कोड शामिल किया है जो एक फ़ाइल को इन्जेस्ट करेगा और हेक्स उत्पन्न करेगा जिसे स्निपेट में परिभाषित बाइट ऐरे में कॉपी किया जा सकता है। उपयोगकर्ता को प्रस्तुत करने के लिए XLSX और उसी XLSX वाले फ़ोल्डर वाली ZIP फ़ाइल पर इसका उपयोग करें और उन्हें उनके संबंधित बाइट ऐरे में संग्रहीत करें। इस कोड को संकलित करें:``` gcc -o ingestfile ingestfile.c
मुझे अपने XLL's को MingW का उपयोग करके kali मशीन पर संकलित करने में कुछ समस्याएँ आ रही थीं, इसलिए मैंने सोचा कि मैं यहाँ कमांड पोस्ट करूँगा:
**x64**```
x86_64-w64-mingw32-gcc snippet.c 2013_Office_System_Developer_Resources/Excel2013XLLSDK/LIB/x64/XLCALL32.LIB -o importantdoc.xll -s -Os -DUNICODE -shared -I 2013_Office_System_Developer_Resources/Excel2013XLLSDK/INCLUDE/
x86``` i686-w64-mingw32-gcc snippet.c 2013_Office_System_Developer_Resources/Excel2013XLLSDK/LIB/XLCALL32.LIB -o HelloWorldXll.xll -s -DUNICODE -Os -shared -I 2013_Office_System_Developer_Resources/Excel2013XLLSDK/INCLUDE/
संकलन के बाद आप एक नया फ़ोल्डर बनाना चाहेंगे और उस फ़ोल्डर में XLL को कॉपी करें। फिर इसे ज़िप करें:```
zip -r <myzipname>.zip <foldername>/
ध्यान दें कि इस पोस्ट में उल्लिखित ट्रेडक्राफ्ट को काम करने के लिए, आपको कोड स्निपेट में कुछ वेरिएबल्स को उस नाम से मेल करना होगा जो आप XLL और ज़िप फ़ाइल को देते हैं।
Office Macro's के प्रभुत्व के समाप्त होने के साथ, XLL's फ़िशिंग अभियानों के लिए एक आकर्षक विकल्प प्रस्तुत करते हैं। कुछ रचनात्मकता के साथ उनका उपयोग अन्य तकनीकों के साथ मिलकर संगठनों और सुरक्षा टीमों द्वारा लागू की गई रक्षा की कई परतों को बायपास करने के लिए किया जा सकता है। पढ़ने के लिए धन्यवाद और मुझे आशा है कि आपने कुछ उपयोगी सीखा!