codextf2/customc2channeltemplateरिफ्लेक्टिव लोडर द्वारा लागू किए गए IAT हुक का उपयोग करके Cobalt Strike के लिए कस्टम C2 चैनल विकसित करने का टेम्पलेट।
यह Cobalt Strike के लिए कस्टम C2 चैनल विकसित करने हेतु एक सरल PoC और टेम्पलेट है, जिसमें रिफ्लेक्टिव लोडर द्वारा लगाए गए IAT हुक का उपयोग किया जाता है।
ब्लॉग पोस्ट: https://codex-7.gitbook.io/codexs-terminal-window/red-team/cobalt-strike/building-custom-c2-channels-by-hooking-wininet
TCP चैनल का डेमो gif
customCallback.h, hook.c, hash.h और hook.h फ़ाइलें मोटे-मोटे टेम्पलेट हैं, लेकिन इन्हें Crystal kit में डालकर ज्यों-का-त्यों PoC के रूप में उपयोग किया जा सकता है। इन्हें udrl/src फ़ोल्डर में रखें, मौजूदा प्रतियों को बदलते हुए। tcg.h अपरिवर्तित है (Raphael Mudge के tradecraft garden से)।
examples/ फ़ोल्डर के उदाहरण ज्यों-के-त्यों उपयोग किए जा सकते हैं, लेकिन वे उदाहरण मात्र हैं और इन्हें लिखते समय परिचालन संबंधी बातों पर ध्यान नहीं दिया गया है। सावधानी से उपयोग करें।
वर्तमान उदाहरण हैं:
ध्यान दें कि Crystal kit की मूल एवेज़न क्षमताएँ जैसे Draugr इम्प्लीमेंटेशन और स्लीप मास्किंग को hook.c से हटा दिया गया है ताकि यह कोडबेस साफ और पोर्टेबल बना रहे। यदि आप उन सुविधाओं को बनाए रखना चाहते हैं, तो आप उन्हें Crystal kit की मूल प्रतियों से वापस जोड़ सकते हैं।
बीकन dll जनरेट करते समय आपको उपयुक्त http लाइब्रेरी winhttp/wininet को http लाइब्रेरी के रूप में चुनना होगा।
जिस malleable प्रोफ़ाइल के साथ इसका परीक्षण किया गया है वह रिपॉजिटरी में दी गई है - सिद्धांततः (अधिकांश) अन्य malleable प्रोफ़ाइल भी काम करनी चाहिए, लेकिन इस टेम्पलेट का परीक्षण इसी प्रोफ़ाइल (GraphStrike से ली गई) के साथ किया गया था।
आधिकारिक ExternalC2 इंटरफ़ेस उपयोग करने में कष्टदायक है - इसमें externalc2 चैनल के ऊपर SMB बीकन का स्टेजिंग करना आवश्यक होता है, और (4.10 तक) पहले externalc2 एजेंट के माध्यम से स्टेजिंग किए बिना पहले से तैयार SMB बीकन के साथ संचार का समर्थन नहीं करता था। अपनी वर्तमान स्थिति में भी, यह अब भी इस आर्किटेक्चर से बंधा है:
smb beacon --named pipe--> externalc2 agent --custom channel--> externalc2 handler --> teamserver
हाँ, मुझे पता है कि UDC2 को Cobalt Strike 4.12 में जोड़ा गया था। यह वैसे भी UDRL में उस क्षमता को दोहराने का एक मज़ेदार प्रयोग मात्र है।
अवधारणा सरल है - यदि आप कॉलबैक के लिए उपयोग होने वाले WinAPIs को हुक कर सकते हैं, तो आपके पास पहले से ही कॉलबैक के लिए आवश्यक सारा डेटा मौजूद है। कस्टम C2 चैनल लागू करने की यह विधि पहले भी की जा चुकी है, जैसा कि GraphStrike में देखा गया है।
हालाँकि, GraphStrike का इम्प्लीमेंटेशन अभी भी HTTP प्रोटोकॉल से काफी जुड़ा हुआ है। इस रिपो का लक्ष्य किसी भी कस्टम चैनल को लागू करने के लिए एक आसान उपयोग, संशोधन और विस्तार योग्य टेम्पलेट प्रदान करना है, चाहे वह HTTP हो या कुछ और, आस-पास के कोड में न्यूनतम बदलाव के साथ।
यह टेम्पलेट स्पष्ट रूप से अपनी डिफ़ॉल्ट अवस्था में उपयोग के लिए नहीं है, इसलिए अपनी पसंद का C2 चैनल लागू करने के लिए आपको निम्नलिखित को संशोधित करना होगा:
customCallback फ़ंक्शन को निम्न कार्य करने के लिए:
आप args के माध्यम से http अनुरोध के मूल होस्ट और पोर्ट (जो आपने cobalt से सेट किया है) का उपयोग कर सकते हैं:
const char *host
INTERNET_PORT port
और broker.py में handleCallback() फ़ंक्शन को निम्न कार्य करने के लिए संशोधित करें:
बस इतना ही।
उदाहरण के तौर पर, customCallback.h में customCallback() फ़ंक्शन का PoC वर्तमान में निम्न कार्य करता है:
broker.py में handleCallback फ़ंक्शन का PoC वर्तमान में निम्न कार्य करता है:
process_encoded_request(encoded_request) को कॉल करता हैusage: broker.py [-h] --host HOST --port PORT
जहाँ host और port आपके टीमसर्वर पर http लिसनर को इंगित करते हैं। ब्रोकर http अनुरोध को पार्स करके उसे वास्तविक लिसनर को भेजता है।
यह शायद इसे करने का सबसे "आलसी" तरीका है, लेकिन सबसे स्थिर तरीकों में से एक भी है। यह मूल रूप से पूरे HTTP अनुरोध को लपेटकर आपकी इच्छानुसार ब्रोकर को भेज देता है, जो फिर उसे वास्तव में टीमसर्वर को भेजता है, ताकि वह HTTP बीकन के रूप में चले, और यह टीमसर्वर के लिए पूरी तरह पारदर्शी हो।
मैंने एक (तकनीकी रूप से) स्वच्छ इम्प्लीमेंटेशन भी आज़माया था जिसमें एक बेयरबोन्स Malleable C2 प्रोफ़ाइल का उपयोग शामिल था (मैंने वास्तव में graphstrike वाली का उपयोग किया) और wininet हुकों के भीतर ही malleable स्पेक के अनुसार विभिन्न बीकन डेटा घटकों (id, metadata, output आदि) को पार्स करना शामिल था। इससे कॉलबैक ब्लॉब का आकार थोड़ा छोटा हो जाता, लेकिन वह इम्प्लीमेंटेशन छोड़ दिया गया क्योंकि अनुरोध पार्सिंग के कारण कोडबेस अनावश्यक रूप से गड़बड़ हो गया और उस विशिष्ट प्रोफ़ाइल के उपयोग की भी आवश्यकता थी (जो बहुत बड़ी बात नहीं है लेकिन काफी हैकी है)।
मुझे लगा कि यह इम्प्लीमेंटेशन बेहतर है क्योंकि यह हैकी malleable प्रोफ़ाइल पर कम निर्भर है (तकनीकी रूप से, इसमें अब भी बीकन प्रतिक्रिया आउटपुट को प्रतिक्रिया बॉडी में भेजा जाना आवश्यक है, लेकिन यही एकमात्र आवश्यकता है) और कोड पढ़ने में 10 गुना आसान था।
यह भी ध्यान देने योग्य है कि http अनुरोध json पर base64 एन्कोडिंग के अलावा कोई ऑब्सफस्केशन या एन्क्रिप्शन नहीं है - आप अपना खुद का जोड़ने के लिए स्वतंत्र हैं, लेकिन चूँकि Beacon कॉलबैक पहले से ही एन्क्रिप्टेड हैं, तकनीकी रूप से कोई भी डेटा डिक्रिप्ट होने के जोखिम में नहीं है। सबसे बुरा जो हो सकता है वह यह है कि यदि base64 ब्लॉब प्राप्त हो जाए तो उसे HTTP अनुरोध के रूप में पहचाना जा सकता है। उस जानकारी के साथ जो चाहें करें।
हाँ, मैंने कुछ कोड और टिप्पणियाँ लिखने के लिए LLM का उपयोग किया, किसी को भी दस्तावेज़ लिखना या C में स्क्रैच से बॉयलरप्लेट json पार्सिंग लिखना पसंद नहीं है। मुझ पर मुकद्दमा कर लें।
सामान्य अस्वीकरण, मैं किसी भी मानवता के विरुद्ध अपराध या परमाणु क्षति के लिए ज़िम्मेदार नहीं हूँ जो आप इस खराब तरीके से लिखे कोड के उपयोग से कर सकते हैं।