external_c2 framework

Python फ्रेमवर्क जो फ्रेमवर्क्स के बीच डेटा स्थानांतरित करने के लिए इंटरफेस बनाने और उपयोग करने हेतु है, जिसका विशेष ध्यान Command and Control फ्रेमवर्क्स के विस्तार के रूप में कार्य करने पर है।

वर्तमान में, यह केवल इस स्पेक दस्तावेज़ में वर्णित Cobalt Strike की External C2 विनिर्देशन के कार्यान्वयन के रूप में अभिप्रेत है, लेकिन परियोजना के परिपक्व होने के साथ इसमें बदलाव संभव है।

श्रेय

बहुत बड़ा श्रेय xychix को जाता है। उनके मूल्यवान योगदान के बिना यह परियोजना बिल्कुल भी संभव नहीं हो पाती। मूल रूप से यह परियोजना Outflank की External C2 परियोजना का पुनर्निर्माण और विस्तार है।

आर्किटेक्चर

इस परियोजना में निम्नलिखित मुख्य भाग शामिल हैं:

• बिल्डर
• स्केलेटन
• फ्रेमवर्क्स
• ट्रांसपोर्ट्स
• एन्कोडर्स
• मैनेजर (अभी लागू नहीं किया गया)

बिल्डर

बिल्डर एक कॉन्फ़िग फ़ाइल पढ़ता है, और skeletons के भीतर markers को प्रतिस्थापित करके एक बिल्ड उत्पन्न करने के लिए कॉन्फ़िगर किए गए विकल्पों का उपयोग करता है।

बिल्डर का उपयोग build_files.py के साथ किया जा सकता है। एक नमूना बिल्डर कॉन्फ़िगरेशन sample_builder_config.config.sample के रूप में प्रदान किया गया है।

स्केलेटन

skeletons कोड के विभिन्न "स्केलेटन" होते हैं जिन्हें builder पूर्ण रूप से उपयोग योग्य बिल्ड उत्पन्न करने के लिए गतिशील रूप से भरता है। skeletons में markers होते हैं जिन्हें builder द्वारा उपयोग योग्य मानों से प्रतिस्थापित किया जाएगा। स्केलेटन के तीन अलग-अलग 'प्रकार' हैं:

स्केलेटन मार्कर

एक मार्कर को skeleton में किसी भी फ़ाइल के अंदर रखा जा सकता है, जिसे बिल्डर कॉन्फ़िग में निर्दिष्ट मान से प्रतिस्थापित किया जाएगा। सर्वोत्तम अभ्यास में, मार्कर का उपयोग कभी भी सीधे वेरिएबल लिखने के लिए नहीं किया जाना चाहिए, और केवल मान सेट करने के लिए ही किया जाना चाहिए। यदि किसी मार्कर के मान का पुनः उपयोग करना हो, तो मान को एक वेरिएबल में संग्रहीत करके उसी तरह संदर्भित करना चाहिए, न कि उसी मार्कर का पुनः उपयोग करना चाहिए।

मार्कर प्रारूप है: ```[var:::identifier_for_the_marker]```

स्ट्रिंग्स को स्केलेटन में सीधे सिंगल कोट्स में लपेटकर लिखा जाएगा, और संख्याओं को यथावत लिखा जाएगा।

यदि कॉन्फ़िग में कोई स्ट्रिंग डबल कोट्स में लपेटी गई है, तो स्ट्रिंग को फ़ाइल में सीधे डबल कोट्स में लपेटकर लिखा जाएगा, और लपेटे गए सिंगल कोट्स हटा दिए जाएंगे।

यह संबंध इस प्रकार प्रदर्शित किया जा सकता है:

#################
# Skeleton Code #
#################

# Skeleton contains the following line of code:
foo = ```[var:::bar]```

##############
# End Result #
##############

# Stored in config as:
#   foo = bar
# Written as:
foo = 'bar'

# Stored in config as:
#   foo = "bar"
# Written as:
foo = "bar"

# Stored in config as:
#   foo = 2
# Written as:
foo = 2

# Stored in config as:
#  foo = "2"
# Written as:
foo = "2"

फ्रेमवर्क्स

फ्रेमवर्क्स मूल अनुप्रयोग होते हैं जो यह निर्धारित करते हैं कि transport और encoder द्वारा कौन सा डेटा उपयोग किया जा रहा है, और उस डेटा का उपयोग कैसे किया जाता है। कोई विशिष्ट framework वास्तव में क्या करता है, यह अधिक मायने नहीं रखता, जब तक कि encoder और transport को आयात और उपयोग करने की तर्क मौजूद है। किसी फ्रेमवर्क के अधिकांश आवश्यक भाग (मुख्य रूप से client तर्क) एक skeleton के रूप में संग्रहीत किए जाएंगे, जिसमें उसके सर्वर भाग के साथ इंटरैक्ट करने का इंटरफ़ेस एक आधार framework ऑब्जेक्ट के रूप में संग्रहीत किया जाएगा।

सामान्यतः, एक फ्रेमवर्क में एक server और client होता है, और उनके बीच डेटा रिले करने के लिए encoders और transports का उपयोग करता है।

framework बनाते समय विचार करने के लिए कुछ मूलभूत बातें हैं:

• framework यह सुनिश्चित करने के लिए जिम्मेदार है कि encoder को उपयोग के लिए transport को उपलब्ध कराया जाए।
• यदि framework क्लाइंट-सर्वर संबंध का उपयोग करता है, तो उन्हें उसी रूप में उचित रूप से व्यवस्थित किया जाना चाहिए।
• समझें कि अधिकांश मामलों में, अंतिम-उपयोगकर्ता कभी भी किसी फ्रेमवर्क के client के साथ सीधे इंटरैक्ट नहीं करेगा, इसलिए यदि आप client पर चीज़ों को पुनः कॉन्फ़िगर करने योग्य बनाना चाहते हैं, तो उसे बिना किसी सीधे इंटरैक्शन के रनटाइम के दौरान ऐसा करने में सक्षम होना चाहिए।
• एक server skeleton बनाने की आवश्यकता बहुत कम होनी चाहिए क्योंकि अंतिम-उपयोगकर्ता सीधे किसी फ्रेमवर्क के server के साथ इंटरैक्ट करने जा रहा है। इसके बजाय, कॉन्फ़िगरेशन से विकल्प पढ़ने और अंतिम-उपयोगकर्ता को रनटाइम के दौरान विकल्पों (जैसे ब्लॉक टाइमर या वर्बोसिटी) को संशोधित करने की क्षमता देने, दोनों का विकल्प चुनें।
• एक framework skeleton को बिल्डर द्वारा संसाधित किया जाएगा, जो उसमें मौजूद हर फ़ाइल को देखेगा, इसलिए यदि किसी विशेष तर्क को बिल्ड समय पर कॉन्फ़िगर करने योग्य बनाना हो, तो यह आसानी से किया जा सकता है।
• एक framework server को एक सामान्य framework_manager द्वारा इंटरफ़ेस किए जाने में सक्षम होना चाहिए।

फ्रेमवर्क सर्वर

सर्वर वह अनुप्रयोग है जो client और c2 server के बीच संचार की मध्यस्थता करता है। सर्वर तर्क मुख्य रूप से स्थिर होता है। cobalt_strike फ्रेमवर्क के लिए सर्वर का तर्क, जिसे स्पेक के भीतर third-party Client Controller कहा जाता है, नीचे दिखाया गया है:

1. कॉन्फ़िगरेशन पार्स करें
2. निर्दिष्ट एन्कोडिंग मॉड्यूल आयात करें
3. निर्दिष्ट ट्रांसपोर्ट मॉड्यूल आयात करें
4. c2 सर्वर से कनेक्शन स्थापित करें
5. c2 सर्वर से एक स्टेजर का अनुरोध करें
6. स्टेजर को encoder मॉड्यूल के साथ एन्कोड करें
7. स्टेजर को transport मॉड्यूल के साथ ट्रांसपोर्ट करें
8. transport के माध्यम से क्लाइंट से मेटाडेटा प्रतिक्रिया की प्रतीक्षा करें
9. मेटाडेटा को encoder मॉड्यूल के साथ डिकोड करें
10. मेटाडेटा को c2 सर्वर तक रिले करें
11. c2 सर्वर से एक नया कार्य प्राप्त करें
12. नए कार्य को एन्कोड करें
13. नए कार्य को transport के माध्यम से क्लाइंट तक रिले करें
14. transport के माध्यम से क्लाइंट से प्रतिक्रिया प्राप्त करें
15. प्रतिक्रिया को encoder मॉड्यूल के माध्यम से डिकोड करें
16. प्रतिक्रिया को c2 सर्वर तक रिले करें
17. चरण 11-16 दोहराएं

एक server को कई क्लाइंट्स को संभालने की क्षमता (अभी लागू नहीं) का समर्थन करना चाहिए, और एक framework_manager द्वारा इंटरफ़ेस किए जाने में सक्षम होना चाहिए।

फ्रेमवर्क क्लाइंट

क्लाइंट अनिवार्य रूप से वह पेलोड है जो एंडपॉइंट पर चलता है। cobalt_strike फ्रेमवर्क के लिए क्लाइंट का तर्क मुख्य रूप से स्थिर है, और नीचे दिखाया गया है:

1. transport का उपयोग करने हेतु आवश्यक कोई भी तैयारी चलाएं
2. स्टेजर प्राप्त करें
3. स्टेजर इंजेक्ट करें और बीकन का हैंडल खोलें
4. बीकन से मेटाडेटा प्राप्त करें
5. बीकन से मेटाडेटा को transport के माध्यम से C2 सर्वर तक रिले करें
6. नए कार्यों के लिए transport की निगरानी करें
7. नए कार्यों को बीकन तक रिले करें
8. बीकन से प्रतिक्रियाओं को transport के माध्यम से रिले करें
9. चरण 6-8 दोहराएं

क्लाइंट अपने और अपने संबंधित server के बीच डेटा रिले करने के लिए निर्दिष्ट encoder और transport का उपयोग करता है।

एन्कोडर्स

एन्कोडर्स डेटा प्राप्त करते हैं, फिर उस डेटा को संशोधित करते हैं ताकि या तो इसे ट्रांसपोर्ट के माध्यम से भेजे जाने के लिए तैयार किया जा सके, या ट्रांसपोर्ट के माध्यम से प्राप्त डेटा को उसके कच्चे रूप में डिकोड किया जा सके, ताकि जो भी framework घटक इसका उपयोग कर रहा है उसके द्वारा व्याख्या की जा सके।

एन्कोडर्स को ट्रांसपोर्ट द्वारा सीधे इंटरफ़ेस किए जाने की अपेक्षा करनी चाहिए, और डेटा को फ्रेमवर्क और घटक-एग्नोस्टिक तरीके से संभालना चाहिए।

ट्रांसपोर्ट्स

ट्रांसपोर्ट्स एक संचार चैनल के माध्यम से डेटा भेजने और प्राप्त करने की भूमिका निभाते हैं, और एन्कोडर के साथ इंटरफ़ेस करके यह सुनिश्चित करते हैं कि डेटा आवश्यक किसी भी प्रारूप में रूपांतरित हो। ट्रांसपोर्ट्स को किसी फ्रेमवर्क घटक से, या संचार चैनल के माध्यम से डेटा प्राप्त करने की अपेक्षा करनी चाहिए, और संचार चैनल के माध्यम से डेटा रिले करने की क्षमता रखनी चाहिए। ट्रांसपोर्ट्स की जिम्मेदारी है कि वे आवश्यकतानुसार डेटा को एन्कोड या डिकोड करने हेतु encoder को कॉल करें।

ट्रांसपोर्ट्स को framework घटक द्वारा सीधे इंटरफ़ेस किए जाने की अपेक्षा करनी चाहिए, और डेटा को फ्रेमवर्क और घटक-एग्नोस्टिक तरीके से संभालना चाहिए।

इसका उपयोग कैसे करें

1. पहले, निर्धारित करें कि आप कौन सा ट्रांसपोर्ट और एन्कोडिंग मॉड्यूल उपयोग करना चाहते हैं। निम्नलिखित उदाहरण के लिए हम transport_imgur और encoder_lsbjpg का उपयोग करेंगे।